cvs commit: src/sys/dev/io iodev.c

[Kostik Belousov]

On Sat, Aug 09, 2008 at 11:27:58AM +0100, Robert Watson wrote:
> 
> On Sat, 9 Aug 2008, Peter Jeremy wrote:
> 
> >On 2008-Aug-08 12:26:31 -0400, John Baldwin <jhb at freebsd.org> wrote:
> >>It should be setting D_TRACKCLOSE though so that close() reliably clears 
> >>the flag even in single-threaded processes.  You can still get odd 
> >>behavior if you explicitly open it twice in an app and then close one of 
> >>the two fd's. You will no longer have IO permission even though you still 
> >>have one fd open. However, if you do that I think you deserve what you 
> >>asked for. :)
> >
> >That behaviour may be legitimate:  Your code links with libraries foo and 
> >bar that each independently open /dev/io so they can frob different things 
> >in IO space.  libfoo needs ongoing access to device foo and so keeps its 
> >descriptor open.  libbar only needs once-off access to device bar and so 
> >closes /dev/io once it's finished its initialisation.  Libraries foo and 
> >bar are completely independent and shouldn't need to know anything about 
> >each other and your app shouldn't need to know that libraries it's using 
> >frob around in IO space.
> 
> If that's the view, there should probably be a per-process counter, 
> although this is all a bit tricky anyway since file descriptors and 
> processes have a tenuous relationship.

Another interesting issue is the close on exec, esp. for /dev/io.

It seems that Linux recently grown full new API to handle FD_CLOEXEC races,
see http://udrepper.livejournal.com/20407.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/cvs-src/attachments/20080809/6a21f982/attachment.pgp