udevd [was: Re: [RFC/PATCH] input_id: add touchpad quirks rules

udevd [was: Re: [RFC/PATCH] input_id: add touchpad quirks rules

[Martin Pitt]

Hello Kay,

Kay Sievers [2010-05-13 15:29 +0200]:
> >  (2) I hear that udevd will eventually go away, and its probers will
> >     be fanned out to the subsystem daemons, therefore leaving the
> >     udev package as a relatively stable library only.
> 
> Oh, that's interesting news. :) What makes you think of that? 

Scott just gave a presentation about the plumbing layer, and mentioned
that. It came as quite a surprise to me, too, and that's why I wrote "I
hear", not "it is" :) I'll ask him about this.

> What would match on and deliver all the kernel events to subcribers?

As far as I understood it, libudev would stay for client-side programs
(reading events from netlink and enumerate from /sys), and the udev
database would stay for the properties, but the udev daemon
would/could go away.

Thanks,

Martin
-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

Re: udevd [was: Re: [RFC/PATCH] input_id: add touchpad quirks

[Lennart Poettering]

On Thu, 13.05.10 15:47, Martin Pitt (martin.pitt@ubuntu.com) wrote:

> Hello Kay,
> 
> Kay Sievers [2010-05-13 15:29 +0200]:
> > >  (2) I hear that udevd will eventually go away, and its probers will
> > >     be fanned out to the subsystem daemons, therefore leaving the
> > >     udev package as a relatively stable library only.
> > 
> > Oh, that's interesting news. :) What makes you think of that? 
> 
> Scott just gave a presentation about the plumbing layer, and mentioned
> that. It came as quite a surprise to me, too, and that's why I wrote "I
> hear", not "it is" :) I'll ask him about this.
> 
> > What would match on and deliver all the kernel events to subcribers?
> 
> As far as I understood it, libudev would stay for client-side programs
> (reading events from netlink and enumerate from /sys), and the udev
> database would stay for the properties, but the udev daemon
> would/could go away.

OMG! Ubuntu is forking udev! This is ... funny...

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

Re: udevd [was: Re: [RFC/PATCH] input_id: add touchpad quirks

[Scott James Remnant]

[-- Attachment #1: Type: text/plain, Size: 485 bytes --]

On Thu, 2010-05-13 at 16:06 +0200, Lennart Poettering wrote:

> OMG! Ubuntu is forking udev! This is ... funny...
> 
Wow, I've never seen anyone leap so far.  There was a veritable chasm
between you and those conclusions.

I consider myself an active member of udev upstream, and I think we've
taken a wrong turn with the design and implementation.  Any changes I
propose will be just as much upstream as any you propose.

Scott
-- 
Scott James Remnant
scott@ubuntu.com

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: udevd [was: Re: [RFC/PATCH] input_id: add touchpad quirks

[Greg KH]

On Sun, May 16, 2010 at 12:22:47PM +0100, Scott James Remnant wrote:
> I consider myself an active member of udev upstream, and I think we've
> taken a wrong turn with the design and implementation.

What specifically do you mean by this?

Is the current libudev not a good design for your needs?  What should it
be instead?

curious,

greg k-h

Re: udevd [was: Re: [RFC/PATCH] input_id: add touchpad quirks

[Scott James Remnant]

[-- Attachment #1: Type: text/plain, Size: 792 bytes --]

On Sun, 2010-05-16 at 09:04 -0700, Greg KH wrote:

> On Sun, May 16, 2010 at 12:22:47PM +0100, Scott James Remnant wrote:
> > I consider myself an active member of udev upstream, and I think we've
> > taken a wrong turn with the design and implementation.
> 
> What specifically do you mean by this?
> 
> Is the current libudev not a good design for your needs?  What should it
> be instead?
> 
Actually, quite the opposite!  I think that libudev is a great design.

I think that the wrong turn is that we rely on a massive "cold plug"
phase during boot, and we rely on probing every single piece of hardware
during that phase or on later insertion - whether or not anything on the
system actually cares about the result.

Scott
-- 
Scott James Remnant
scott@ubuntu.com

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: udevd [was: Re: [RFC/PATCH] input_id: add touchpad quirks

[Greg KH]

On Mon, May 17, 2010 at 12:10:06PM +0100, Scott James Remnant wrote:
> On Sun, 2010-05-16 at 09:04 -0700, Greg KH wrote:
> 
> > On Sun, May 16, 2010 at 12:22:47PM +0100, Scott James Remnant wrote:
> > > I consider myself an active member of udev upstream, and I think we've
> > > taken a wrong turn with the design and implementation.
> > 
> > What specifically do you mean by this?
> > 
> > Is the current libudev not a good design for your needs?  What should it
> > be instead?
> > 
> Actually, quite the opposite!  I think that libudev is a great design.
> 
> I think that the wrong turn is that we rely on a massive "cold plug"
> phase during boot, and we rely on probing every single piece of hardware
> during that phase or on later insertion - whether or not anything on the
> system actually cares about the result.

But how would we "know" if we care about a device until we actually
figure out what the device is, and load the driver for it?

This cold-plug phase doesn't seem to take a very large amount of time
these days at all, so I don't see the real savings that would be
possible here.

Or am I missing something?

thanks,

greg k-h