Re: [patch] turning devctl into a "multiple openable" device
--KFztAG8eRSV9hGtP
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
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 multip=
le openable
> > > device, that mean that it will allow to open /dev/devctl in multiple =
programs,
> > > for example hald and everythings that want to receive notification fr=
om 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 instea=
d 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 loo=
ks
> like a waste.
>=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_wait
> call in cdevpriv data destructor ? You cannot have a thread doing e.g.
> read on the file descriptor while destructor is run.
>=20
> >=20
> > Also, I know that it was an intentional design decisison by Warner to h=
ave
> > the multiplexing of devctl data done in userland via devd rather than i=
n the
> > kernel. (I think he envisioned devd providing a UNIX domain socket or =
some
> > such for other daemons to use to listen to events.) Have you asked him=
about
> > this change?
> And I fully agree that doing multiplexing in user mode is the right appro=
ach.
> Not least because you could apply some advanced access control and provide
> filtering for the consumers.
I agree that in most cases this is better, but being able to have multiple
readers is anyway useful, having the futur libudev or alike not depends on =
devd
running would be great imho.
I have boxes that do not have devd and won't have it would be useless but r=
un
programs that needs to get notification for some hardware. I would love to
remove devd on those boxes (they are boxes where the FS size is limited)
regards,
Bapt
--KFztAG8eRSV9hGtP
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)
iEYEARECAAYFAk7WUsoACgkQ8kTtMUmk6EzkwACfUTu9h2FY/9WFnxMH1wk4iKrm
9ecAnReKgkHD10fwKhd6EvDsUOguuIl7
=e8tO
-----END PGP SIGNATURE-----
--KFztAG8eRSV9hGtP--
討論串 (同標題文章)
完整討論串 (本文為第 8 之 12 篇)：