Date: Sat, 9 Aug 2008 12:08:42 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Kostik Belousov <kostikbel@gmail.com> Cc: src-committers@freebsd.org, John Baldwin <jhb@freebsd.org>, Peter Jeremy <peterjeremy@optushome.com.au>, Ed Schouten <ed@freebsd.org>, cvs-all@freebsd.org, cvs-src@freebsd.org Subject: Re: cvs commit: src/sys/dev/io iodev.c Message-ID: <alpine.BSF.1.10.0808091207350.16028@fledge.watson.org> In-Reply-To: <20080809103338.GN97161@deviant.kiev.zoral.com.ua> References: <200808081343.m78DhwYE068477@repoman.freebsd.org> <200808081226.32089.jhb@freebsd.org> <20080809001256.GL64458@server.vk2pj.dyndns.org> <alpine.BSF.1.10.0808091127170.36489@fledge.watson.org> <20080809103338.GN97161@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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 Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.1.10.0808091207350.16028>