Date: Wed, 30 Nov 2011 18:04:50 +0200 From: Kostik Belousov <kostikbel@gmail.com> To: Olivier Houchard <mlfbsd@kanar.ci0.org> Cc: Baptiste Daroussin <bapt@freebsd.org>, freebsd-current@freebsd.org Subject: Re: [patch] turning devctl into a "multiple openable" device Message-ID: <20111130160450.GY50300@deviant.kiev.zoral.com.ua> In-Reply-To: <20111130155521.GA52567@ci0.org> References: <20111130124320.GA1449@azathoth.lan> <201111301005.11938.jhb@freebsd.org> <20111130154636.GX50300@deviant.kiev.zoral.com.ua> <20111130155521.GA52567@ci0.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--3810kwpuvNap/nrH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 30, 2011 at 04:55:21PM +0100, Olivier Houchard wrote: > On Wed, Nov 30, 2011 at 05:46:36PM +0200, Kostik Belousov wrote: > > On Wed, Nov 30, 2011 at 10:05:11AM -0500, John Baldwin wrote: > > > On Wednesday, November 30, 2011 7:43:20 am Baptiste Daroussin wrote: > > > > Hi all, > > > >=20 > > > > With the help of cognet, I wrote a patch to turn devctl into a mult= iple openable > > > > device, that mean that it will allow to open /dev/devctl in multipl= e programs, > > > > for example hald and everythings that want to receive notification = from the > > > > device won't need to depend on haveing devd running. > > > >=20 > > > > here is the patch:=20 > > > > http://people.freebsd.org/~bapt/devctl_multi_open.diff > > >=20 > > > Shouldn't devctl_queue_data_f() use the requested malloc() flags inst= ead of > > > hardcoding M_NOWAIT? > > This is an obvious fallback of holding mutex around the call to > > per_devctl_queue_data_f(), which caused the author a trouble to use > > M_WAITOK. > >=20 > > Having n readers causes the patch to queue each message n times, that l= ooks > > like a waste. > >=20 >=20 > Queuing the message only one time would require to somehow keep a state, = to > know which thread read which message, and figuring out when to free a mes= sage > can be an headache. Given I don't think they'll be a lot of readers, I'm = not > sure it's worth the trouble. >=20 > > I wonder why the waiting_threads stuff is needed at all. The cv could > > be woken up unconditionally everytime. What is the reason for the cv_wa= it > > call in cdevpriv data destructor ? You cannot have a thread doing e.g. > > read on the file descriptor while destructor is run. > >=20 >=20 > What will prevent you from having a thread stuck in read(), while an anot= her=20 > one close() the fd ? >=20 Nothing, but file reference count goes to zero only after the thread stuck in read is unstuck. Cdevpriv destructor is run only when file reference count becomes zero, i.e. there can be no any accessing threads, and new accesses are impossible since file descriptors also own references on the file. --3810kwpuvNap/nrH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7WVCIACgkQC3+MBN1Mb4hToQCfVnR31uzSGbFP/jkmlKYJgtHX VJIAn12lAKr282i53O91iADdoWoeUW7l =WyJx -----END PGP SIGNATURE----- --3810kwpuvNap/nrH--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111130160450.GY50300>