On Wed, 6 Jan 2016, Christos Zoulas wrote:
As a temporary hack it is probably good enough. Longer term filemon
should be removed/rewritten, and the close ordering problem should
be handled.
I think that a "better" approach here is probably to remove filemon(4)'s
SET_FD ioctl (for the log_file
Date: Wed, 6 Jan 2016 12:00:32 +0800 (PHT)
From: Paul Goyette
On Wed, 6 Jan 2016, Paul Goyette wrote:
> Hmmm. I'm looking at the filemon_open() code. It seems to have a "fd"
> variable that gets set by fd_allocfile(). The value is later passed to
> fd_clone() (NOT fd_clone
In article ,
Christos Zoulas wrote:
>
>As a temporary hack it is probably good enough. Longer term filemon
>should be removed/rewritten, and the close ordering problem should
>be handled.
I changed my mind; it does not help because one can always dup2
that file descriptor later to a lower fd and
The memory leak in fdtbus_intr_establish that I pointed out when you sent
me this change for review has not been addressed.
Both get_entry_from_map and get_specifier_by_index allocate memory for the
specifier buffer and pass the buffer to the interrupt controller's
"establish" callback. This b
In article ,
Paul Goyette wrote:
>
>Yeah, this is workable, even if it is a HACK ! :)
>
>The attached patch borrows extensively from fd_free() routine in
>kern/kern_descrip.c
>
>Let me know if this looks "good enough" and I will commit it. (I'll
>also update the BUGS section of the man-page t
