cvs commit: src/sys/dev/io iodev.c
rwatson at FreeBSD.org
Sat Aug 9 11:08:43 UTC 2008
On Sat, 9 Aug 2008, Kostik Belousov wrote:
> 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
While /dev/io appeals to the UNIX "everything is a file" sensibility, I think
the system calls we have for this on i386 are more conceptually coherent.
Robert N M Watson
University of Cambridge
More information about the cvs-all