Re: [patch] turning devctl into a "multiple openable" device

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,
> > > 
> > > With the help of cognet, I wrote a patch to turn devctl into a multiple 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 from the
> > > device won't need to depend on haveing devd running.
> > > 
> > > here is the patch: 
> > > http://people.freebsd.org/~bapt/devctl_multi_open.diff
> > 
> > Shouldn't devctl_queue_data_f() use the requested malloc() flags instead 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.
> 
> Having n readers causes the patch to queue each message n times, that looks
> like a waste.
> 
> 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.
> 
> > 
> > Also, I know that it was an intentional design decisison by Warner to have
> > the multiplexing of devctl data done in userland via devd rather than in 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 approach.
> 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 run
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