udev and DBUS

udev and DBUS

[Marco d'Itri]

I'd like to know if anybody is using the DBUS support in udev for real
or if it's still considered just a toy.

Nobody commented on my report of a major delay introduced at boot time,
nor discussed the issue of a DBUS-enabled udev needing at least the dbus
libraries in /lib/.
Should distributions build a plain udevd for /sbin (initramfs?) and a
DBUS-enabled one for /usr/sbin, and patch udevsend to spawn the
appropriate daemon?

-- 
ciao, |
Marco | [4648 riP09z8ivbK2M]


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id\x1356&alloc_id438&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev and DBUS

[Marco d'Itri]

On Feb 26, David Zeuthen <david@fubar.dk> wrote:

 >Maybe we should remove dbus support from udev and distributions and/or
 >hardware/hotplug abstractions like HAL can install their own callout
 >scripts (side-question: is it now as easy to install a callout as with
 >hotplug e.g. place an executable in /etc/hotplug.d/default/) which sends
 >a dbus message to a well-defined service (in HAL's case this would be
 >org.freedesktop.Hal.Manager).
I'm not sure if this would work, because I think HAL wants to know which
name has just been created by udev.

 >What do you think?

Last week I added this to README.Debian:

D-BUS support
~~~~~~~~~~~~~
It has been temporarily disabled for many reasons, among them it needing
libraries in /usr/lib and introducing a pause of many seconds at boot time.
A possible solution could be to build two versions of the daemon, start
the bare one in the init script[1] and patch it to exit when SIGUSR1 has
been received and the queue is empty.


[1] or initrd or initramfs.

-- 
ciao, |
Marco | [4766 amIGt4mgevPnk]


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id\x1356&alloc_id438&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev and DBUS

[David Zeuthen]

(for some reason it seems that linux-hotplug-devel rejects my mail once
in a while so if you reply, please quote in full)

On Thu, 2004-02-26 at 18:00, Marco d'Itri wrote:
> On Feb 26, David Zeuthen <david@fubar.dk> wrote:
> 
>  >Maybe we should remove dbus support from udev and distributions and/or
>  >hardware/hotplug abstractions like HAL can install their own callout
>  >scripts (side-question: is it now as easy to install a callout as with
>  >hotplug e.g. place an executable in /etc/hotplug.d/default/) which sends
>  >a dbus message to a well-defined service (in HAL's case this would be
>  >org.freedesktop.Hal.Manager).
> I'm not sure if this would work, because I think HAL wants to know which
> name has just been created by udev.
> 

Right - my suggestion was for HAL to install a callout in udev, a script
really, that sends a D-BUS message to the HAL service.

>  >What do you think?
> 
> Last week I added this to README.Debian:
> 
> D-BUS support
> ~~~~~~~~~~~~~
> It has been temporarily disabled for many reasons, among them it needing
> libraries in /usr/lib and introducing a pause of many seconds at boot time.
> A possible solution could be to build two versions of the daemon, start
> the bare one in the init script[1] and patch it to exit when SIGUSR1 has
> been received and the queue is empty.
> 
> 
> [1] or initrd or initramfs.

This could work as well, but it's really up to Greg to answer this one I
think. Since udev is now a daemon we should probably revisit D-BUS
support and add support for queries, I'll look into this.

Thanks,
David


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id\x1356&alloc_id438&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

udev and dbus

[David Zeuthen]

Hi Greg and Kay,

As far as I can tell there are still issues with the dbus support in
udev due to the fact that udev needs to be available in early boot -
this issue have been raised a few times with little or response. 

I'm willing to make a patch to fix it (unless someone beats me to it),
but before I go ahead I'd like some input on how we want it to look
like. I can see at least the following three scenarios:

 1. Remove dbus support from udev and make udev call /sbin/hotplug with
    a single positional parameter, 'udev', and the environment variables
    DEVPATH pointing to the appropriate directory in sysfs, ACTION
    assuming 'add' respectively 'remove' and DEVICE_FILE pointing to
    the created / removed special device file.

    This way, applications, like HAL, interested in the event can simply
    install a small program in /etc/hotplug.d/[udev,default] to do
    whatever they want with the event, like sending it to a daemon
    possibly through what may be the IPC-flavour of the month :-)

    (yes, this might be abusing the hotplug multiplexor)

 2. Move dbus support from udev to udevd, make sure udevd never
    exits, and let udevd own the org.kernel.udev service. I guess
    this would imply building two udevd binaries; one with
    dbus support and one without (for early boot) and make the small
    one load the big one upon receiving SIGUSR1. I think Marco
    d'Itri came up with this approach.

    I'm not too familiar with udevd, but I seem to recall that it
    spawns udev copies to do the work so it may require more tweaking
    to do this.

    However, using this approach, we can also offer queries on the
    udev database using dbus instead of using udevinfo. That would
    be nice.

 3. Remove dbus support and if applications are interested in sending
    out events using IPC like dbus, they just install a udev callout.

    I'm not sure this is easy today as all the callout rules are in
    a single file instead of a directory with rule files. I may be
    wrong on this though.

Of course, there might be other ways of acheiving sending out events
through e.g. dbus, but I can't think of any.

Let me know what you think - I'd really like to resolve this issue.

Take care,
David 


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev and dbus

[Kay Sievers]

On Wed, 2004-03-10 at 17:31, David Zeuthen wrote:
> Hi Greg and Kay,
> 
> As far as I can tell there are still issues with the dbus support in
> udev due to the fact that udev needs to be available in early boot -
> this issue have been raised a few times with little or response. 
> 
> I'm willing to make a patch to fix it (unless someone beats me to it),
> but before I go ahead I'd like some input on how we want it to look
> like. I can see at least the following three scenarios:
> 
>  1. Remove dbus support from udev and make udev call /sbin/hotplug with
>     a single positional parameter, 'udev', and the environment variables
>     DEVPATH pointing to the appropriate directory in sysfs, ACTION
>     assuming 'add' respectively 'remove' and DEVICE_FILE pointing to
>     the created / removed special device file.

How will you know what file is created?


>     This way, applications, like HAL, interested in the event can simply
>     install a small program in /etc/hotplug.d/[udev,default] to do
>     whatever they want with the event, like sending it to a daemon
>     possibly through what may be the IPC-flavour of the month :-)
> 
>     (yes, this might be abusing the hotplug multiplexor)
> 
>  2. Move dbus support from udev to udevd, make sure udevd never
>     exits, and let udevd own the org.kernel.udev service. I guess
>     this would imply building two udevd binaries; one with
>     dbus support and one without (for early boot) and make the small
>     one load the big one upon receiving SIGUSR1. I think Marco
>     d'Itri came up with this approach.
> 
>     I'm not too familiar with udevd, but I seem to recall that it
>     spawns udev copies to do the work so it may require more tweaking
>     to do this.

Sounds fragile, we multiplex with datagrams and fork in the background
to get the SIGCHLDS later.
I don't think you can send anything like a dbus-message without blocking
the whole thing to dead.


>     However, using this approach, we can also offer queries on the
>     udev database using dbus instead of using udevinfo. That would
>     be nice.
> 
>  3. Remove dbus support and if applications are interested in sending
>     out events using IPC like dbus, they just install a udev callout.
> 
>     I'm not sure this is easy today as all the callout rules are in
>     a single file instead of a directory with rule files. I may be
>     wrong on this though.

Sure, you can specify a whole directory in udev.conf (man udev).


Hmm, don't know what's the best...

thanks,
Kay



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev and dbus

[Greg KH]

On Wed, Mar 10, 2004 at 05:31:09PM +0100, David Zeuthen wrote:
> 
>  1. Remove dbus support from udev and make udev call /sbin/hotplug with
>     a single positional parameter, 'udev', and the environment variables
>     DEVPATH pointing to the appropriate directory in sysfs, ACTION
>     assuming 'add' respectively 'remove' and DEVICE_FILE pointing to
>     the created / removed special device file.
> 
>     This way, applications, like HAL, interested in the event can simply
>     install a small program in /etc/hotplug.d/[udev,default] to do
>     whatever they want with the event, like sending it to a daemon
>     possibly through what may be the IPC-flavour of the month :-)
> 
>     (yes, this might be abusing the hotplug multiplexor)

Yes, that is abusing the hotplug multiplexor.  I don't like it :)

>  2. Move dbus support from udev to udevd, make sure udevd never
>     exits, and let udevd own the org.kernel.udev service. I guess
>     this would imply building two udevd binaries; one with
>     dbus support and one without (for early boot) and make the small
>     one load the big one upon receiving SIGUSR1. I think Marco
>     d'Itri came up with this approach.

But then udevd would have to know the name that udev created for the
device.  Not good.

>     However, using this approach, we can also offer queries on the
>     udev database using dbus instead of using udevinfo. That would
>     be nice.

How would you do this?  udevinfo does queries, not udevd.

>  3. Remove dbus support and if applications are interested in sending
>     out events using IPC like dbus, they just install a udev callout.
> 
>     I'm not sure this is easy today as all the callout rules are in
>     a single file instead of a directory with rule files. I may be
>     wrong on this though.

Yeah, that would be a "post" type callout.  Again not nice.

My main question is, what is the problem with udev and dbus today?  What
is causing problems?  Is it only on pathilogical systems that don't have
their dbus libraries mounted before udev wants to run?  If so, then tell
those users to fix their systems :)

thanks,

greg k-h


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev and dbus

[Greg KH]

On Wed, Mar 10, 2004 at 08:43:23PM +0100, David Zeuthen wrote:
> On Wed, Mar 10, 2004 at 11:18:06AM -0800, Greg KH wrote:
> > My main question is, what is the problem with udev and dbus today?  What
> > is causing problems?  Is it only on pathilogical systems that don't have
> > their dbus libraries mounted before udev wants to run?  If so, then tell
> > those users to fix their systems :)
> 
> I recall two problems: 1) various copies of udev races to acquire the 
> org.kernel.udev service so they can emit a signal that listening apps
> can intercept; and 2) if the dbus message bus daemon isn't running the
> dbus init script takes a long time to run.
> 
> Supposedly 2. is an easy fix - that's just checking a file in /var/run,
> but I never got to find out how to solve 1. - it *could* be an easy
> fix as well. Let me look into it again.

Great, I'd rather not have to change the udev model in order to support
dbus if we can help it :)

thanks,

greg k-h


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev and dbus

[Marco d'Itri]

On Mar 10, David Zeuthen <david@fubar.dk> wrote:

>  2. Move dbus support from udev to udevd, make sure udevd never
>     exits, and let udevd own the org.kernel.udev service. I guess
>     this would imply building two udevd binaries; one with
>     dbus support and one without (for early boot) and make the small
>     one load the big one upon receiving SIGUSR1. I think Marco
>     d'Itri came up with this approach.
No, wait... I proposed using two different udevd's because I tought that
dbus support was in udevd. After checking the code I think that a much
simpler solution to implement would be to make udev_run() in udevd first
try to spawn /usr/sbin/udev and then /sbin/udev.

-- 
ciao, |
Marco | [5012 us9kjrPq4d9vM]


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev and dbus

[Marco d'Itri]

On Mar 10, Greg KH <greg@kroah.com> wrote:

> My main question is, what is the problem with udev and dbus today?  What
> is causing problems?  Is it only on pathilogical systems that don't have
> their dbus libraries mounted before udev wants to run?  If so, then tell
> those users to fix their systems :)
I don't think these systems are so pathological... I agree that the dbus
and glib libraries could be moved, but I feel it would be premature to
do it now while D-BUS is not being used by many programs (and by no
program which has to be executed before /usr is available).

The other major problem is that, at least with older udev releases,
enabling D-BUS support would introduce a very long delay at boot while
udevd was waiting for all udev childs to exit.

-- 
ciao, |
Marco | [5013 pe9ltM9oDO/C.]


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev and dbus

[Greg KH]

On Wed, Mar 10, 2004 at 09:00:41PM +0100, Marco d'Itri wrote:
> 
> The other major problem is that, at least with older udev releases,
> enabling D-BUS support would introduce a very long delay at boot while
> udevd was waiting for all udev childs to exit.

As has already been reported, this is a dbus issue, and looks to be
fixed already, and is not a udev issue.

thanks,

greg k-h


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev and dbus

[Patrick Mansfield]

On Wed, Mar 10, 2004 at 11:18:06AM -0800, Greg KH wrote:
> On Wed, Mar 10, 2004 at 05:31:09PM +0100, David Zeuthen wrote:
> > 
> >  1. Remove dbus support from udev and make udev call /sbin/hotplug with
> >     a single positional parameter, 'udev', and the environment variables
> >     DEVPATH pointing to the appropriate directory in sysfs, ACTION
> >     assuming 'add' respectively 'remove' and DEVICE_FILE pointing to
> >     the created / removed special device file.
> > 
> >     This way, applications, like HAL, interested in the event can simply
> >     install a small program in /etc/hotplug.d/[udev,default] to do
> >     whatever they want with the event, like sending it to a daemon
> >     possibly through what may be the IPC-flavour of the month :-)
> > 
> >     (yes, this might be abusing the hotplug multiplexor)
> 
> Yes, that is abusing the hotplug multiplexor.  I don't like it :)

I like it. Why does the kernel get to abuse it but not user space ;-)

Then dbus or anyone can create an agent. And those wanting to
automatically mount devices, start applications, or setup dm have a nice
place to put their scripts. In a initrd/initramfs, you could even mount
and start init based on the root device showing up.

We should have a simple "your /dev/foo has arrived" interface.

-- Patrick Mansfield


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev and dbus

[Kay Sievers]

On Wed, 2004-03-10 at 19:49, David Zeuthen wrote:
> On Wed, Mar 10, 2004 at 06:52:59PM +0100, Kay Sievers wrote:
> > >  1. Remove dbus support from udev and make udev call /sbin/hotplug with
> > >     a single positional parameter, 'udev', and the environment variables
> > >     DEVPATH pointing to the appropriate directory in sysfs, ACTION
> > >     assuming 'add' respectively 'remove' and DEVICE_FILE pointing to
> > >     the created / removed special device file.
> > 
> > How will you know what file is created?
> > 
> 
> udev forks, creates a minimal environment, sets ACTION, DEVPATH and
> DEVICE_FILE (surely udev will know what to put in DEVICE_FILE since
> it created / removed the file, yes?) and then exec's /sbin/hotplug
> (or whatever the /proc/... file designates as the hotplug helper)
> with a single parameter udev.

This sounds like a nice loop :)

Kay



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev and dbus

[Greg KH]

On Wed, Mar 10, 2004 at 02:25:27PM -0800, Patrick Mansfield wrote:
> On Wed, Mar 10, 2004 at 11:18:06AM -0800, Greg KH wrote:
> > On Wed, Mar 10, 2004 at 05:31:09PM +0100, David Zeuthen wrote:
> > > 
> > >  1. Remove dbus support from udev and make udev call /sbin/hotplug with
> > >     a single positional parameter, 'udev', and the environment variables
> > >     DEVPATH pointing to the appropriate directory in sysfs, ACTION
> > >     assuming 'add' respectively 'remove' and DEVICE_FILE pointing to
> > >     the created / removed special device file.
> > > 
> > >     This way, applications, like HAL, interested in the event can simply
> > >     install a small program in /etc/hotplug.d/[udev,default] to do
> > >     whatever they want with the event, like sending it to a daemon
> > >     possibly through what may be the IPC-flavour of the month :-)
> > > 
> > >     (yes, this might be abusing the hotplug multiplexor)
> > 
> > Yes, that is abusing the hotplug multiplexor.  I don't like it :)
> 
> I like it. Why does the kernel get to abuse it but not user space ;-)
> 
> Then dbus or anyone can create an agent. And those wanting to
> automatically mount devices, start applications, or setup dm have a nice
> place to put their scripts. In a initrd/initramfs, you could even mount
> and start init based on the root device showing up.
> 
> We should have a simple "your /dev/foo has arrived" interface.

Ok, I have no problem with something like /etc/udev.d/ for when udev is
finished creating or removing a device that works the same way that
/etc/hotplug.d/ does for kernel hotplug events.  I just would not want
to overload the hotplug interface, as that would get quite messy very
quickly :)

Then we could drop a udevdbusd program that would catch all of the udev
messages and send them to the DBUS.  Heh, layers on top of layers...
But it would solve the org.kernel namespace issues for DBUS, right?

Sound reasonable?

thanks,

greg k-h


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev and dbus

[Greg KH]

On Wed, Mar 10, 2004 at 08:57:54PM +0100, Marco d'Itri wrote:
> On Mar 10, David Zeuthen <david@fubar.dk> wrote:
> 
> >  2. Move dbus support from udev to udevd, make sure udevd never
> >     exits, and let udevd own the org.kernel.udev service. I guess
> >     this would imply building two udevd binaries; one with
> >     dbus support and one without (for early boot) and make the small
> >     one load the big one upon receiving SIGUSR1. I think Marco
> >     d'Itri came up with this approach.
> No, wait... I proposed using two different udevd's because I tought that
> dbus support was in udevd. After checking the code I think that a much
> simpler solution to implement would be to make udev_run() in udevd first
> try to spawn /usr/sbin/udev and then /sbin/udev.

Why "/usr/sbin/udev" first?  According to the LSB, everything in
/sbin/ is needed for boot, not /usr/sbin, right?

thanks,

greg k-h


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev and dbus

[Kay Sievers]

On Wed, 2004-03-10 at 23:48, Greg KH wrote:
> On Wed, Mar 10, 2004 at 02:25:27PM -0800, Patrick Mansfield wrote:
> > On Wed, Mar 10, 2004 at 11:18:06AM -0800, Greg KH wrote:
> > > On Wed, Mar 10, 2004 at 05:31:09PM +0100, David Zeuthen wrote:
> > > > 
> > > >  1. Remove dbus support from udev and make udev call /sbin/hotplug with
> > > >     a single positional parameter, 'udev', and the environment variables
> > > >     DEVPATH pointing to the appropriate directory in sysfs, ACTION
> > > >     assuming 'add' respectively 'remove' and DEVICE_FILE pointing to
> > > >     the created / removed special device file.
> > > > 
> > > >     This way, applications, like HAL, interested in the event can simply
> > > >     install a small program in /etc/hotplug.d/[udev,default] to do
> > > >     whatever they want with the event, like sending it to a daemon
> > > >     possibly through what may be the IPC-flavour of the month :-)
> > > > 
> > > >     (yes, this might be abusing the hotplug multiplexor)
> > > 
> > > Yes, that is abusing the hotplug multiplexor.  I don't like it :)
> > 
> > I like it. Why does the kernel get to abuse it but not user space ;-)
> > 
> > Then dbus or anyone can create an agent. And those wanting to
> > automatically mount devices, start applications, or setup dm have a nice
> > place to put their scripts. In a initrd/initramfs, you could even mount
> > and start init based on the root device showing up.
> > 
> > We should have a simple "your /dev/foo has arrived" interface.
> 
> Ok, I have no problem with something like /etc/udev.d/ for when udev is
> finished creating or removing a device that works the same way that
> /etc/hotplug.d/ does for kernel hotplug events.  I just would not want
> to overload the hotplug interface, as that would get quite messy very
> quickly :)
> 
> Then we could drop a udevdbusd program that would catch all of the udev
> messages and send them to the DBUS.  Heh, layers on top of layers...
> But it would solve the org.kernel namespace issues for DBUS, right?

I prefer changing dbus to be able to receive messages from multiple
senders with the same origin at the same time.

What about sending dbus-messages with udev, depending on a environment
variable.

If called by udevd and we can toggle the state of the environment
variable udevd passes down. So after dbus is able to receive, it can
toggle on the switch for udev to send?

Kay



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev and dbus

[Martin Waitz]

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

hi :)

On Wed, Mar 10, 2004 at 05:28:05PM -0800, Greg KH wrote:
> Why "/usr/sbin/udev" first?  According to the LSB, everything in
> /sbin/ is needed for boot, not /usr/sbin, right?

then it will execute the big version if it is available and
will use the small boot-only from /sbin otherwise.

-- 
CU,		  / Friedrich-Alexander University Erlangen, Germany
Martin Waitz	//  Department of Computer Science 12      _________
______________/// - - - - - - - - - - - - - - - - - - - - ///
dies ist eine manuell generierte mail, sie beinhaltet    //
tippfehler und ist auch ohne grossbuchstaben gueltig.   /

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: udev and dbus

[Kay Sievers]

On Thu, 2004-03-11 at 11:48, David Zeuthen wrote:
> On Wed, Mar 10, 2004 at 02:48:16PM -0800, Greg KH wrote:
> > Ok, I have no problem with something like /etc/udev.d/ for when udev is
> > finished creating or removing a device that works the same way that
> > /etc/hotplug.d/ does for kernel hotplug events.  I just would not want
> > to overload the hotplug interface, as that would get quite messy very
> > quickly :)
> > 
> 
> Great, I'll start writing a patch!
> 
> > Then we could drop a udevdbusd program that would catch all of the udev
> > messages and send them to the DBUS.  Heh, layers on top of layers...
> 
> Right - this program udevdbus (shouldn't be a daemon though, yes?) would
> just do what udev did before:
> 
>  1. acquire the org.kernel.udev service from the system bus
>  2. emit a signal with saying this node added/removed
>  3. release the org.kernel.udev service
> 
> Any program can then subscribe to the org.kernel.udev service on the
> system message bus to pickup the signal and do it's thing. 
> 
> Of course the whole point of having the org.kernel.udev service in the 
> first place (in my mind at least) was that it would allow you to do
> fancy things like the queries you use udevinfo for, by only using
> dbus as the IPC. (Hmm, maybe this can even be done through dbus activation
> at some point).
> 
> So, I kind of question the merit of having udevdbus, since applications
> interested in udev events, like HAL, can just install a program to
> 
>  1. connect to the org.foobar.something service
>  2. send a message to that service
>  3. disconnect from the org.foobar.something service
> 
> But I can go ahead and write udevdbus anyway if you want to - conceptually
> it's nice that *any* program can pickup the fact that a new device node
> have been created.

Sorry, but are you guys getting completely crazy? :)

Why you want a stacked hotplug.d/udev.d forking hell or a "serializer"
for the dbus daemon? This is simply unmaintainable and _nobody_ will
understand this. We have enough problems to teach the /sbin/hotplug and
udev/udevsend/udevd logic.

We can rip dbus out and make a external dbus caller, yes that's fine.
But dbus should use the /sbin/hotplug multiplexer. Just get the needed
information with udevinfo and then fire up the dbus-client.

We can also keep udev's dbus-send as it is and just make it switchable.
If dbus is finally running, you can simply switch it on. But yes,
ripping it out seems cleaner.

So, please please remember the goal of udev :)

thanks,
Kay




-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev and dbus

[David Zeuthen]

On Thu, 2004-03-11 at 15:30, Kay Sievers wrote:
> Sorry, but are you guys getting completely crazy? :)
> 
> Why you want a stacked hotplug.d/udev.d forking hell or a "serializer"
> for the dbus daemon? This is simply unmaintainable and _nobody_ will
> understand this. 

What's so difficult with understanding that udev calls a series of
programs in /etc/udev.d when it add/remove device nodes?

> We have enough problems to teach the /sbin/hotplug and
> udev/udevsend/udevd logic.
> 
> We can rip dbus out and make a external dbus caller, yes that's fine.
> But dbus should use the /sbin/hotplug multiplexer. Just get the needed
> information with udevinfo and then fire up the dbus-client.

This I would recommend against - not every hotplug event makes udev
create/remove a device node; networking devices are one example. 

Oh, and wouldn't there be a potential race with udev, so you'd need to
poll with udevinfo until you get the device file from udevinfo?

> We can also keep udev's dbus-send as it is and just make it switchable.
> If dbus is finally running, you can simply switch it on. But yes,
> ripping it out seems cleaner.
> 

As someone mentioned in another mail, you will still have the potential
problem of the libdbus.so being on /usr which could be a separate
partition from / and, blam, udev can't run to create the device node for
the disk that /usr is on. 

Hence I would argue that it's desirable to keep the code sending the
dbus event in a binary separate from udev. Do you agree?

> So, please please remember the goal of udev :)
> 

I think the proposal is really simple:

 1. Rip out dbus-sender from udev
 2. Make udev call all executables in /etc/udev.d
 3. *optionally* provide a udevdbus program and place it in /etc/udev.d

and I argue this will udev simpler and not depend on dbus at all, while
still maintaining the dbus functionality. Oh, and solving the problem
with 'dbus support is disabled because of...'.

(For the udevdbus program, we could place this in /usr/libexec and
symlink it to /etc/udev.d - udev can then, upon traversing /etc/udev.d,
check if the link is stale or not)

People can even use whatever IPC they may like to use the information
from udev, write custom shell scripts or whatever.

Friendly,
David




-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev and dbus

[Kay Sievers]

On Thu, 2004-03-11 at 16:06, David Zeuthen wrote:
> On Thu, 2004-03-11 at 15:30, Kay Sievers wrote:
> > Sorry, but are you guys getting completely crazy? :)
> > 
> > Why you want a stacked hotplug.d/udev.d forking hell or a "serializer"
> > for the dbus daemon? This is simply unmaintainable and _nobody_ will
> > understand this. 
> 
> What's so difficult with understanding that udev calls a series of
> programs in /etc/udev.d when it add/remove device nodes?

Oh, it's not as easy as you might think. Just read this list or
_your_ yesterdays mail, where you propose that udev should call
/sbin/hotplug, which is a nice loop, right :)

> > We have enough problems to teach the /sbin/hotplug and
> > udev/udevsend/udevd logic.
> > 
> > We can rip dbus out and make a external dbus caller, yes that's fine.
> > But dbus should use the /sbin/hotplug multiplexer. Just get the needed
> > information with udevinfo and then fire up the dbus-client.
> 
> This I would recommend against - not every hotplug event makes udev
> create/remove a device node; networking devices are one example. 

Zero argument! You want udev to call scripts for a device it doesn't
handle itself, with a empty NODES environment? That's definitely nothing
more than misuse of infrastructure.

> Oh, and wouldn't there be a potential race with udev, so you'd need to
> poll with udevinfo until you get the device file from udevinfo?

Just make udevsend wait until the nodes are created (we already have a
patch for it from Chris) and execute udevsend as the first program with
/sbin/hotplug. All the following programs are sure that the nodes on
it's place and can query the node names with udevinfo. Easy, clean, nice
transparent and understandable.

> > We can also keep udev's dbus-send as it is and just make it switchable.
> > If dbus is finally running, you can simply switch it on. But yes,
> > ripping it out seems cleaner.
> > 
> 
> As someone mentioned in another mail, you will still have the potential
> problem of the libdbus.so being on /usr which could be a separate
> partition from / and, blam, udev can't run to create the device node for
> the disk that /usr is on. 
> 
> Hence I would argue that it's desirable to keep the code sending the
> dbus event in a binary separate from udev. Do you agree?

Yes, I agree completely.

> > So, please please remember the goal of udev :)
> > 
> 
> I think the proposal is really simple:
> 
>  1. Rip out dbus-sender from udev
>  2. Make udev call all executables in /etc/udev.d
>  3. *optionally* provide a udevdbus program and place it in /etc/udev.d
> 
> and I argue this will udev simpler and not depend on dbus at all, while
> still maintaining the dbus functionality. Oh, and solving the problem
> with 'dbus support is disabled because of...'.

Yes, you are right. I see the problem.

> (For the udevdbus program, we could place this in /usr/libexec and
> symlink it to /etc/udev.d - udev can then, upon traversing /etc/udev.d,
> check if the link is stale or not)

Yes, but with /sbin/hotplug!

> People can even use whatever IPC they may like to use the information
> from udev, write custom shell scripts or whatever.

udev is a device node manager, nothing more. I _strongly_ disagree on
making udev a arbitrary hotplug script engine. Please solve the problem
on it's source not on the first comfortable place :)

thanks,
Kay



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev and dbus

[Kay Sievers]

On Thu, 2004-03-11 at 18:14, Kay Sievers wrote:
> On Thu, 2004-03-11 at 16:06, David Zeuthen wrote:
> > > We can rip dbus out and make a external dbus caller, yes that's fine.
> > > But dbus should use the /sbin/hotplug multiplexer. Just get the needed
> > > information with udevinfo and then fire up the dbus-client.
> > 
> > This I would recommend against - not every hotplug event makes udev
> > create/remove a device node; networking devices are one example. 
> 
> Zero argument! You want udev to call scripts for a device it doesn't
> handle itself, with a empty NODES environment? That's definitely nothing
> more than misuse of infrastructure.

Oh, seems like I did get you wrong? Sorry.
Nevermind, dbus installs it's own hotplug script independend of the udev
dbus connection. So maybe these both scripts may be combined into one?

Just look at Rob's presentation:
http://tech9.net/rml/talks/rml_fosdem_2004.sxi

Kay



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev and dbus

[David Zeuthen]

On Thu, 2004-03-11 at 18:23, Kay Sievers wrote:
> > > This I would recommend against - not every hotplug event makes udev
> > > create/remove a device node; networking devices are one example. 
> > 
> > Zero argument! You want udev to call scripts for a device it doesn't
> > handle itself, with a empty NODES environment? That's definitely nothing
> > more than misuse of infrastructure.
> 
> Oh, seems like I did get you wrong? Sorry.
> Nevermind, dbus installs it's own hotplug script independend of the udev
> dbus connection. 

Actually it's hal that installs a hotplug script of it's own and hal
just happens to use dbus as the transport; this could be another IPC
construct.

> So maybe these both scripts may be combined into one?
> 

This would require that the udev hotplug script runs before the hal
hotplug script which a) isn't the case today; and b) I'm not sure that
it's wise to rely on which order the scripts run in; that would, for
instance, make it hard to parallelize hotplug events sometime in the
future.

Thanks,
David




-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev and dbus

[David Zeuthen]

On Thu, 2004-03-11 at 18:14, Kay Sievers wrote:
> On Thu, 2004-03-11 at 16:06, David Zeuthen wrote:
> > On Thu, 2004-03-11 at 15:30, Kay Sievers wrote:
> > > Sorry, but are you guys getting completely crazy? :)
> > > 
> > > Why you want a stacked hotplug.d/udev.d forking hell or a "serializer"
> > > for the dbus daemon? This is simply unmaintainable and _nobody_ will
> > > understand this. 
> > 
> > What's so difficult with understanding that udev calls a series of
> > programs in /etc/udev.d when it add/remove device nodes?
> 
> Oh, it's not as easy as you might think. Just read this list or
> _your_ yesterdays mail, where you propose that udev should call
> /sbin/hotplug, which is a nice loop, right :)
> 

Oh, come on - it's not like udev should create/remove device nodes on
getting a hotplug event with the single positional parameter being
'udev', right? That would be quite stupid.

I was merely suggesting to use an existing multiplexor mechanishm so
people only need to care about /etc/hotplug.d and not both
/etc/hotplug.d and /etc/udev.d.

> Just make udevsend wait until the nodes are created (we already have a
> patch for it from Chris) and execute udevsend as the first program with
> /sbin/hotplug. All the following programs are sure that the nodes on
> it's place and can query the node names with udevinfo. Easy, clean, nice
> transparent and understandable.
> 

Wearing a purist-hat, I would consider this a bad hack - so you want to
hardcode the requirement that udevinfo needs to run before anything into
whatever hotplug multiplexor is running? 

What if I want to write a hotplug multiplexor that runs a number of
programs in parallel in response to a hotplug event? What if I want to
write another implementation of a device node manager to replace udev? 
(not that I want to at, I really like udev, but I'm against setting
requirements on how a hotplug multiplexor should work).

> udev is a device node manager, nothing more. I _strongly_ disagree on
> making udev a arbitrary hotplug script engine. Please solve the problem
> on it's source not on the first comfortable place :)

No. I'm simply asking that udev executes a program when it add/removes
device nodes, that's all - calling this an arbritary hotplug script
engine is simply not representative of what I ask for. I've said I'm
even willing to write the patch myself :-)

Thanks,
David


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev and dbus

[Kay Sievers]

On Thu, 2004-03-11 at 18:30, David Zeuthen wrote:
> On Thu, 2004-03-11 at 18:23, Kay Sievers wrote:
> > > > This I would recommend against - not every hotplug event makes udev
> > > > create/remove a device node; networking devices are one example. 
> > > 
> > > Zero argument! You want udev to call scripts for a device it doesn't
> > > handle itself, with a empty NODES environment? That's definitely nothing
> > > more than misuse of infrastructure.
> > 
> > Oh, seems like I did get you wrong? Sorry.
> > Nevermind, dbus installs it's own hotplug script independend of the udev
> > dbus connection. 
> 
> Actually it's hal that installs a hotplug script of it's own and hal
> just happens to use dbus as the transport; this could be another IPC
> construct.
> 
> > So maybe these both scripts may be combined into one?
> > 
> 
> This would require that the udev hotplug script runs before the hal
> hotplug script which a) isn't the case today; and b) I'm not sure that
> it's wise to rely on which order the scripts run in; that would, for
> instance, make it hard to parallelize hotplug events sometime in the
> future.

Sure, you can execute events for different devpathes in parallel, like
we do today. But you should have control over the order of script
execution for a single event.

Kay



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev and dbus

[Kay Sievers]

On Thu, 2004-03-11 at 18:41, David Zeuthen wrote:
> On Thu, 2004-03-11 at 18:14, Kay Sievers wrote:
> > On Thu, 2004-03-11 at 16:06, David Zeuthen wrote:
> > > On Thu, 2004-03-11 at 15:30, Kay Sievers wrote:
> > Just make udevsend wait until the nodes are created (we already have a
> > patch for it from Chris) and execute udevsend as the first program with
> > /sbin/hotplug. All the following programs are sure that the nodes on
> > it's place and can query the node names with udevinfo. Easy, clean, nice
> > transparent and understandable.
> > 
> 
> Wearing a purist-hat, I would consider this a bad hack - so you want to
> hardcode the requirement that udevinfo needs to run before anything into
> whatever hotplug multiplexor is running? 

Why? If you don't need the node names don't wait for udevsend and don't
call udevinfo.

> What if I want to write a hotplug multiplexor that runs a number of
> programs in parallel in response to a hotplug event? What if I want to
> write another implementation of a device node manager to replace udev? 
> (not that I want to at, I really like udev, but I'm against setting
> requirements on how a hotplug multiplexor should work).

What do you think of?
There are no requirements. If your script rely on the dynamically
nodes,  you need to wait for udev anyway. If not, just go ahead.

> > udev is a device node manager, nothing more. I _strongly_ disagree on
> > making udev a arbitrary hotplug script engine. Please solve the problem
> > on it's source not on the first comfortable place :)
> 
> No. I'm simply asking that udev executes a program when it add/removes
> device nodes, that's all - calling this an arbritary hotplug script
> engine is simply not representative of what I ask for. I've said I'm
> even willing to write the patch myself :-)

I expect lot of lazy people to put their scripts in there, cause it's so
comfortable to live inside the serialized hotplug events.

Something like this:
"Nice, I can mount my USB-stick with udev.d/ right after udev has
created my partition node, cause the scsi.agent was too fast..."

So I still vote for not doing this.

thanks,
Kay



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev and dbus

[David Zeuthen]

On Thu, 2004-03-11 at 19:12, Kay Sievers wrote:
> > > Just make udevsend wait until the nodes are created (we already have a
> > > patch for it from Chris) and execute udevsend as the first program with
> > > /sbin/hotplug. All the following programs are sure that the nodes on
> > > it's place and can query the node names with udevinfo. Easy, clean, nice
> > > transparent and understandable.
> > > 
> > 
> > Wearing a purist-hat, I would consider this a bad hack - so you want to
> > hardcode the requirement that udevinfo needs to run before anything into
> > whatever hotplug multiplexor is running? 
> 
> Why? If you don't need the node names don't wait for udevsend and don't
> call udevinfo.
> 

I may have misunderstood you - are you suggesting that I in my own
script for, e.g. hal, invoke udevsend even though /sbin/hotplug invoked
it? That might work, however, I guess (but dunno) it's double the work
for udev.

> > No. I'm simply asking that udev executes a program when it add/removes
> > device nodes, that's all - calling this an arbritary hotplug script
> > engine is simply not representative of what I ask for. I've said I'm
> > even willing to write the patch myself :-)
> 
> I expect lot of lazy people to put their scripts in there, cause it's so
> comfortable to live inside the serialized hotplug events.
> 
> Something like this:
> "Nice, I can mount my USB-stick with udev.d/ right after udev has
> created my partition node, cause the scsi.agent was too fast..."
> 

Well, part of the grand scheme that Robert Love calls Project Utopia
(which includes hal and udev) aims to solve this problem (and world
hunger, see [1]) so people don't need to learn to write scripts just to
use an USB-stick. 

Seriously, having to write a script to use an USB-stick is just, uhmm,
so 90-ish ;-) and I think that Linux distributions need to move away
from this. Anyway...

> So I still vote for not doing this.
> 

Thanks for a good discussion.

Cheers,
David

[1] : http://www.cafeshops.com/tarnished.9454841


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev and dbus

[Greg KH]

On Thu, Mar 11, 2004 at 07:12:55PM +0100, Kay Sievers wrote:
> 
> I expect lot of lazy people to put their scripts in there, cause it's so
> comfortable to live inside the serialized hotplug events.

But people want to know about the device node creation and removal, they
don't care about the "raw" hotplug events.  They want udev to handle the
raw hotplug events for them.

> Something like this:
> "Nice, I can mount my USB-stick with udev.d/ right after udev has
> created my partition node, cause the scsi.agent was too fast..."

No, how can scsi.agent know about what the device node name was?  It
can't.

Lots of people have been asking me about the ability to run "post" type
scripts after udev has named the device (or removed it.)  With this
proposal, people could get those udev messages easily (actually multiple
people could, which is even better.)  It would also allow us to rip out
both the SELinux and DBUS code from udev itself and implement those with
/etc/udev.d/ programs instead.

Which, in the end, would make udev itself simpler, and more resilient
over time for new requests from new programs/system notification
buses/security models/etc...

Does that make more sense?

thanks,

greg k-h


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev and dbus

[Greg KH]

On Thu, Mar 11, 2004 at 09:55:54AM +0100, Martin Waitz wrote:
> hi :)
> 
> On Wed, Mar 10, 2004 at 05:28:05PM -0800, Greg KH wrote:
> > Why "/usr/sbin/udev" first?  According to the LSB, everything in
> > /sbin/ is needed for boot, not /usr/sbin, right?
> 
> then it will execute the big version if it is available and
> will use the small boot-only from /sbin otherwise.

But again, why?  What about my /etc/udev.d/ proposal instead?

thanks,

greg k-h


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev and dbus

[Greg KH]

On Thu, Mar 11, 2004 at 03:35:19AM +0100, Kay Sievers wrote:
> 
> What about sending dbus-messages with udev, depending on a environment
> variable.

One of the problems is that the dbus or selinux shared libraries aren't
present at the moment in time, so udev itself does not load at all :(

thanks,

greg k-h


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev and dbus

[Kay Sievers]

On Thu, 2004-03-11 at 19:32, Greg KH wrote:
> On Thu, Mar 11, 2004 at 07:12:55PM +0100, Kay Sievers wrote:
> > 
> > I expect lot of lazy people to put their scripts in there, cause it's so
> > comfortable to live inside the serialized hotplug events.
> 
> But people want to know about the device node creation and removal, they
> don't care about the "raw" hotplug events.  They want udev to handle the
> raw hotplug events for them.

I don't agree.

> > Something like this:
> > "Nice, I can mount my USB-stick with udev.d/ right after udev has
> > created my partition node, cause the scsi.agent was too fast..."
> 
> No, how can scsi.agent know about what the device node name was?  It
> can't.

udevinfo! That's what it's made for :)

> Lots of people have been asking me about the ability to run "post" type
> scripts after udev has named the device (or removed it.)  With this
> proposal, people could get those udev messages easily (actually multiple
> people could, which is even better.)  It would also allow us to rip out
> both the SELinux and DBUS code from udev itself and implement those with
> /etc/udev.d/ programs instead.

Yes, perfectly right, but we can do it with /sbin/hotplug.
Just make udevsend not return until the nodes are created.
And then call anything you like.

> Which, in the end, would make udev itself simpler, and more resilient
> over time for new requests from new programs/system notification
> buses/security models/etc...
> 
> Does that make more sense?

No. :)

thanks,
Kay



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev and dbus

[Kay Sievers]

On Thu, 2004-03-11 at 19:22, David Zeuthen wrote:
> On Thu, 2004-03-11 at 19:12, Kay Sievers wrote:
> > > > Just make udevsend wait until the nodes are created (we already have a
> > > > patch for it from Chris) and execute udevsend as the first program with
> > > > /sbin/hotplug. All the following programs are sure that the nodes on
> > > > it's place and can query the node names with udevinfo. Easy, clean, nice
> > > > transparent and understandable.
> > > > 
> > > 
> > > Wearing a purist-hat, I would consider this a bad hack - so you want to
> > > hardcode the requirement that udevinfo needs to run before anything into
> > > whatever hotplug multiplexor is running? 
> > 
> > Why? If you don't need the node names don't wait for udevsend and don't
> > call udevinfo.
> > 
> 
> I may have misunderstood you - are you suggesting that I in my own
> script for, e.g. hal, invoke udevsend even though /sbin/hotplug invoked
> it? That might work, however, I guess (but dunno) it's double the work
> for udev.

Noooo :)
1. we change udevsend not to return until the nodes are created.

2. we ensure that udevsend is the first program called for the
   scripts that need the nodes

3. any following script can be sure to have all nodes on its place
   dbus-sender can ask udevinfo with the DEVPATH to get the names
   of the nodes.


> Thanks for a good discussion.

Yes, thanks too, it's getting hotter :)

Kay



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev and dbus

[Kay Sievers]

On Thu, 2004-03-11 at 19:36, Greg KH wrote:
> On Thu, Mar 11, 2004 at 03:35:19AM +0100, Kay Sievers wrote:
> > 
> > What about sending dbus-messages with udev, depending on a environment
> > variable.
> 
> One of the problems is that the dbus or selinux shared libraries aren't
> present at the moment in time, so udev itself does not load at all :(

Right, I got the picture already.
This idea is dead :)

thanks,
Kay



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev and dbus

[Greg KH]

On Thu, Mar 11, 2004 at 07:37:16PM +0100, Kay Sievers wrote:
> On Thu, 2004-03-11 at 19:32, Greg KH wrote:
> > On Thu, Mar 11, 2004 at 07:12:55PM +0100, Kay Sievers wrote:
> > > Something like this:
> > > "Nice, I can mount my USB-stick with udev.d/ right after udev has
> > > created my partition node, cause the scsi.agent was too fast..."
> > 
> > No, how can scsi.agent know about what the device node name was?  It
> > can't.
> 
> udevinfo! That's what it's made for :)

udevinfo will not work for a device node that has just gone away :(

> > Lots of people have been asking me about the ability to run "post" type
> > scripts after udev has named the device (or removed it.)  With this
> > proposal, people could get those udev messages easily (actually multiple
> > people could, which is even better.)  It would also allow us to rip out
> > both the SELinux and DBUS code from udev itself and implement those with
> > /etc/udev.d/ programs instead.
> 
> Yes, perfectly right, but we can do it with /sbin/hotplug.
> Just make udevsend not return until the nodes are created.
> And then call anything you like.

But this would involve changing the hotplug scripts to call udevsend
first, right?  That's a policy decision I can make as a developer of the
hotplug scripts, but one that I don't think is very fair to other
projects that use the hotplug scripts.

thanks,

greg k-h


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev and dbus

[Kay Sievers]

On Thu, 2004-03-11 at 19:47, Greg KH wrote:
> On Thu, Mar 11, 2004 at 07:37:16PM +0100, Kay Sievers wrote:
> > On Thu, 2004-03-11 at 19:32, Greg KH wrote:
> > > On Thu, Mar 11, 2004 at 07:12:55PM +0100, Kay Sievers wrote:
> > > > Something like this:
> > > > "Nice, I can mount my USB-stick with udev.d/ right after udev has
> > > > created my partition node, cause the scsi.agent was too fast..."
> > > 
> > > No, how can scsi.agent know about what the device node name was?  It
> > > can't.
> > 
> > udevinfo! That's what it's made for :)
> 
> udevinfo will not work for a device node that has just gone away :(

Why should scsi.agent ask for names on 'remove' events? 

> > > Lots of people have been asking me about the ability to run "post" type
> > > scripts after udev has named the device (or removed it.)  With this
> > > proposal, people could get those udev messages easily (actually multiple
> > > people could, which is even better.)  It would also allow us to rip out
> > > both the SELinux and DBUS code from udev itself and implement those with
> > > /etc/udev.d/ programs instead.
> > 
> > Yes, perfectly right, but we can do it with /sbin/hotplug.
> > Just make udevsend not return until the nodes are created.
> > And then call anything you like.
> 
> But this would involve changing the hotplug scripts to call udevsend
> first, right?  That's a policy decision I can make as a developer of the
> hotplug scripts, but one that I don't think is very fair to other
> projects that use the hotplug scripts.

The /etc/hotplug.d/* is almost empty so it isn't really unfair. Only the
old hotplug.default and udevsend is in there. And this change is only
needed if you actually use udev.

thanks,
Kay



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev and dbus

[Greg KH]

On Thu, Mar 11, 2004 at 07:56:33PM +0100, Kay Sievers wrote:
> On Thu, 2004-03-11 at 19:47, Greg KH wrote:
> > On Thu, Mar 11, 2004 at 07:37:16PM +0100, Kay Sievers wrote:
> > > On Thu, 2004-03-11 at 19:32, Greg KH wrote:
> > > > On Thu, Mar 11, 2004 at 07:12:55PM +0100, Kay Sievers wrote:
> > > > > Something like this:
> > > > > "Nice, I can mount my USB-stick with udev.d/ right after udev has
> > > > > created my partition node, cause the scsi.agent was too fast..."
> > > > 
> > > > No, how can scsi.agent know about what the device node name was?  It
> > > > can't.
> > > 
> > > udevinfo! That's what it's made for :)
> > 
> > udevinfo will not work for a device node that has just gone away :(
> 
> Why should scsi.agent ask for names on 'remove' events? 

scsi.agent wouldn't care.  But programs that want to watch all scsi
devices coming and going would care.

I think the dbus people need to work on their "issues" a bit first
before we go and start changing udev.  Sound ok?

thanks,

greg k-h


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev and dbus

[David Zeuthen]

> I think the dbus people need to work on their "issues" a bit first
> before we go and start changing udev.  Sound ok?
> 

Erh, what "issues" are you talking about? With both proposed changes
dbus support would be removed from udev proper which I think is sane.

What we're really arguing about is where projects higher in the stack
than udev (like hal) should place their scripts. I'm saying /etc/udev.d
and Kay is saying /etc/hotplug.d. FWIW, I can live with both proposals,
though I think it's conceptually clearer to use /etc/udev.d. But let's
not dicsuss the merits of these proposals again.

In either case the situation today is not acceptable. Today, there is no
sane way (e.g. without polling) for projects above udev to get the
information that a device node is created/removed. This is because that
udev ships with dbus support turned off for the various reasons
discussed earlier.

So, Greg, as the udev and hotplug maintainer I think you need to make a
decision on what to do, so we can remedy this situation and udev can
continue to own the world :-)

Anyway, I'm flexible.

Many thanks,
David



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev and dbus

[Kay Sievers]

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

On Fri, Mar 12, 2004 at 12:37:05PM +0100, David Zeuthen wrote:
> > I think the dbus people need to work on their "issues" a bit first
> > before we go and start changing udev.  Sound ok?
> > 
> 
> What we're really arguing about is where projects higher in the stack
> than udev (like hal) should place their scripts. I'm saying /etc/udev.d
> and Kay is saying /etc/hotplug.d. FWIW, I can live with both proposals,
> though I think it's conceptually clearer to use /etc/udev.d. But let's
> not dicsuss the merits of these proposals again.

Here is my proposed version. :) 
udevsend is changed to wait until the real udev comes back from
execution by udevd. udevsend now returns the exit code of udev itself.

If udevsend is the first program executed by /sbin/hotplug, by introducing
a folder in /etc/hotplug.d/ in which to look first, or something similar,
all following programs are executed after the device nodes are created.
Which seems very nice, not only for a dbus-script. And we keep _all_
scripts in /etc/hotplug.d/.

Any script, like the dbus-sender can easily get any value from udev's db,
with udevinfo:


  #!/bin/sh
  if [ "$ACTION" = "add" ]; then
          NODE=`udevinfo -q name -p $DEVPATH`
          logger "node=${NODE}"
  fi
  exit 0


The patch for udevsend/udevd is attached. It's based on Chris Friesen's
"ack msg" patch.

thanks,
Kay

[-- Attachment #2: 90-udevsend-wait.patch --]
[-- Type: text/plain, Size: 6847 bytes --]

===== udevd.c 1.23 vs edited =====
--- 1.23/udevd.c	Wed Mar  3 22:05:10 2004
+++ edited/udevd.c	Fri Mar 12 15:49:10 2004
@@ -222,6 +222,15 @@
 	}
 }
 
+static void send_ack_msg(int sock, struct hotplug_msg *msg)
+{
+	int retval;
+	dbg("sending ack msg for seq %i", msg->seqnum);
+	retval = sendto(sock, msg, sizeof(struct hotplug_msg), 0, (struct sockaddr*) &msg->addr, msg->addrlen);
+	if (retval == -1)
+		dbg("error sending ack msg");
+}
+
 /* receive the msg, do some basic sanity checks, and queue it */
 static void handle_msg(int sock)
 {
@@ -232,6 +241,7 @@
 	struct iovec iov;
 	struct ucred *cred;
 	char cred_msg[CMSG_SPACE(sizeof(struct ucred))];
+	struct sockaddr_un addr;
 
 	msg = msg_create();
 	if (msg == NULL) {
@@ -247,29 +257,39 @@
 	smsg.msg_iovlen = 1;
 	smsg.msg_control = cred_msg;
 	smsg.msg_controllen = sizeof(cred_msg);
+	smsg.msg_name = &addr;
+	smsg.msg_namelen = sizeof(addr);
 
 	retval = recvmsg(sock, &smsg, 0);
 	if (retval <  0) {
 		if (errno != EINTR)
 			dbg("unable to receive message");
-		return;
+		goto skip;
 	}
+
+	if (retval != sizeof(struct hotplug_msg)) {
+		dbg("wrong message size");
+		goto skip;
+	}
+
 	cmsg = CMSG_FIRSTHDR(&smsg);
 	cred = (struct ucred *) CMSG_DATA(cmsg);
+	memcpy(&msg->addr, smsg.msg_name, smsg.msg_namelen);
+	msg->addrlen = smsg.msg_namelen;
+
+	if (strncmp(msg->magic, UDEV_MAGIC, sizeof(UDEV_MAGIC)) != 0 ) {
+		dbg("message magic '%s' doesn't match, ignore it", msg->magic);
+		goto skip;
+	}
 
 	if (cmsg == NULL || cmsg->cmsg_type != SCM_CREDENTIALS) {
 		dbg("no sender credentials received, message ignored");
-		goto skip;
+		goto refuse;
 	}
 
 	if (cred->uid != 0) {
 		dbg("sender uid=%i, message ignored", cred->uid);
-		goto skip;
-	}
-
-	if (strncmp(msg->magic, UDEV_MAGIC, sizeof(UDEV_MAGIC)) != 0 ) {
-		dbg("message magic '%s' doesn't match, ignore it", msg->magic);
-		goto skip;
+		goto refuse;
 	}
 
 	/* if no seqnum is given, we move straight to exec queue */
@@ -281,6 +301,10 @@
 	}
 	return;
 
+refuse:
+	msg->rc = EMSG_REFUSED;
+	send_ack_msg(sock, msg);
+
 skip:
 	free(msg);
 	return;
@@ -304,7 +328,7 @@
 	}
 }
 
-static void udev_done(int pid)
+static void udev_done(int pid, int rc, int sock)
 {
 	/* find msg associated with pid and delete it */
 	struct hotplug_msg *msg;
@@ -312,6 +336,9 @@
 	list_for_each_entry(msg, &running_list, list) {
 		if (msg->pid == pid) {
 			dbg("<== exec seq %d came back", msg->seqnum);
+			msg->rc = rc;
+			send_ack_msg(sock, msg);
+
 			run_queue_delete(msg);
 			return;
 		}
@@ -326,6 +353,8 @@
 	int retval;
 	const int on = 1;
 	struct sigaction act;
+	int status;
+	int rc;
 
 	init_logging("udevd");
 	dbg("version %s", UDEV_VERSION);
@@ -381,10 +410,16 @@
 			children_waiting = 0;
 			/* reap all dead children */
 			while(1) {
-				int pid = waitpid(-1, 0, WNOHANG);
+				int pid = waitpid(-1, &status, WNOHANG);
 				if ((pid == -1) || (pid == 0))
 					break;
-				udev_done(pid);
+
+				if (WIFEXITED(status))
+					rc = WEXITSTATUS(status);
+				else
+					rc = 0;
+
+				udev_done(pid, rc, ssock);
 			}
 		}
 	}
===== udevd.h 1.8 vs edited =====
--- 1.8/udevd.h	Thu Feb 26 04:09:18 2004
+++ edited/udevd.h	Fri Mar 12 16:09:17 2004
@@ -25,16 +25,26 @@
 #include "list.h"
 
 #define UDEV_MAGIC			"udevd_" UDEV_VERSION
-#define EVENT_TIMEOUT_SEC		5
 #define UDEVSEND_CONNECT_RETRY		20 /* x 100 millisec */
 #define UDEVD_SOCK_PATH			"udevd"
 
+#define EVENT_TIMEOUT_SEC		5
+#define ACK_TIMEOUT_SEC			(EVENT_TIMEOUT_SEC + 5)
+
+#define ETIMEOUT_RCV_ACK		16
+#define EMSG_REFUSED			17
+#define EMSG_SEND			18
+
+
 struct hotplug_msg {
-	char magic[20];
 	struct list_head list;
 	pid_t pid;
-	int seqnum;
 	time_t queue_time;
+	struct sockaddr_un addr;
+	socklen_t addrlen;
+	char magic[20];
+	int seqnum;
+	int rc;
 	char action[ACTION_SIZE];
 	char devpath[DEVPATH_SIZE];
 	char subsystem[SUBSYSTEM_SIZE];
===== udevsend.c 1.27 vs edited =====
--- 1.27/udevsend.c	Wed Mar  3 22:07:05 2004
+++ edited/udevsend.c	Fri Mar 12 16:05:43 2004
@@ -22,6 +22,7 @@
  *
  */
 
+#include <sys/select.h>
 #include <sys/types.h>
 #include <sys/socket.h>
 #include <sys/wait.h>
@@ -95,6 +96,7 @@
 	default:
 		wait(NULL);
 	}
+
 	return 0;
 }
 
@@ -106,7 +108,7 @@
 	char *subsystem;
 	char *seqnum;
 	int seq;
-	int retval = 1;
+	int retval;
 	int size;
 	int loop;
 	struct timespec tspec;
@@ -114,6 +116,7 @@
 	struct sockaddr_un saddr;
 	socklen_t addrlen;
 	int started_daemon = 0;
+	int rc = EMSG_SEND;
 
 #ifdef DEBUG
 	init_logging("udevsend");
@@ -156,6 +159,14 @@
 
 	memset(&saddr, 0x00, sizeof(saddr));
 	saddr.sun_family = AF_LOCAL;
+	sprintf(&saddr.sun_path[1], "%d", getpid());
+	addrlen = offsetof(struct sockaddr_un, sun_path) + strlen(saddr.sun_path+1) + 1;
+	
+	if (bind(sock, (struct sockaddr*)&saddr, addrlen) < 0) {
+		dbg("error binding socket");
+		goto exit;
+	}
+		
 	/* use abstract namespace for socket path */
 	strcpy(&saddr.sun_path[1], UDEVD_SOCK_PATH);
 	addrlen = offsetof(struct sockaddr_un, sun_path) + strlen(saddr.sun_path+1) + 1;
@@ -164,11 +175,54 @@
 
 	/* If we can't send, try to start daemon and resend message */
 	loop = UDEVSEND_CONNECT_RETRY;
+
 	while (loop--) {
+		dbg("sending message for seq %i", msg.seqnum);
 		retval = sendto(sock, &msg, size, 0, (struct sockaddr *)&saddr, addrlen);
 		if (retval != -1) {
-			retval = 0;
-			goto close_and_exit;
+			/* wait for ack */
+			fd_set rdset;
+			int count;
+			struct timeval tv = {ACK_TIMEOUT_SEC, 0};
+
+			while(1) {
+				FD_ZERO(&rdset);
+				FD_SET(sock, &rdset);
+				count = select(sock+1, &rdset, NULL, NULL, &tv);
+				if (count == 0) {
+					dbg("timeout waiting for ack msg");
+					rc = ETIMEOUT_RCV_ACK;
+					goto close_and_exit;
+					
+				}
+
+				if (FD_ISSET(sock, &rdset)) {
+					struct hotplug_msg ack;
+
+					retval = recv(sock, &ack, sizeof(ack), MSG_DONTWAIT);
+					if (retval <= 0) {
+						dbg("no ack msg received");
+						continue;
+					}
+
+					if (strncmp(ack.magic, msg.magic, sizeof(UDEV_MAGIC)) != 0 ) {
+						dbg("wrong ack msg magic '%s'", ack.magic);
+						continue;
+					}
+
+					if (ack.rc == EMSG_REFUSED) {
+						dbg("seq %i is refused", ack.seqnum);
+						rc = EMSG_REFUSED;
+						goto close_and_exit;
+					}
+
+					if (ack.seqnum == msg.seqnum) {
+						dbg("seq %i returned with %i", ack.seqnum, ack.rc);
+						rc = ack.rc;
+						goto close_and_exit;
+					}
+				}
+			}
 		}
 		
 		if (errno != ECONNREFUSED) {
@@ -179,11 +233,10 @@
 		if (!started_daemon) {
 			dbg("connect failed, try starting daemon...");
 			retval = start_daemon();
-			if (retval) {
+			if (retval != 0) {
 				dbg("error starting daemon");
 				goto exit;
 			}
-			
 			dbg("daemon started");
 			started_daemon = 1;
 		} else {
@@ -193,9 +246,9 @@
 			nanosleep(&tspec, NULL);
 		}
 	}
-	
+
 close_and_exit:
 	close(sock);
 exit:
-	return retval;
+	return rc;
 }

Re: udev and dbus

[Daniel Stekloff]

On Friday 12 March 2004 03:37 am, David Zeuthen wrote:
> > I think the dbus people need to work on their "issues" a bit first
> > before we go and start changing udev.  Sound ok?
>
> Erh, what "issues" are you talking about? With both proposed changes
> dbus support would be removed from udev proper which I think is sane.
>
> What we're really arguing about is where projects higher in the stack
> than udev (like hal) should place their scripts. I'm saying /etc/udev.d
> and Kay is saying /etc/hotplug.d. FWIW, I can live with both proposals,
> though I think it's conceptually clearer to use /etc/udev.d. But let's
> not dicsuss the merits of these proposals again.


Hi, I'm curious - are the projects higher in the stack like hal only concerned 
with those devices named by udev? Or, are they interested in all system 
devices? The two sets aren't the same, udev is only concerned with a subset 
of system devices and doesn't manage or name all devices represented in /sys. 
I'd imagine that hal would be interested in all devices reported through /sys 
and if this is the case, shouldn't those projects then place their scripts in 
/etc/hotplug.d? 


Thanks,

Dan


> In either case the situation today is not acceptable. Today, there is no
> sane way (e.g. without polling) for projects above udev to get the
> information that a device node is created/removed. This is because that
> udev ships with dbus support turned off for the various reasons
> discussed earlier.
>
> So, Greg, as the udev and hotplug maintainer I think you need to make a
> decision on what to do, so we can remedy this situation and udev can
> continue to own the world :-)
>
> Anyway, I'm flexible.
>
> Many thanks,
> David
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click
> _______________________________________________
> Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
> Linux-hotplug-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&opÌk
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev and dbus

[Marco d'Itri]

On Mar 10, Greg KH <greg@kroah.com> wrote:

> > The other major problem is that, at least with older udev releases,
> > enabling D-BUS support would introduce a very long delay at boot while
> > udevd was waiting for all udev childs to exit.
> As has already been reported, this is a dbus issue, and looks to be
> fixed already, and is not a udev issue.
It is a dbus issue (I just discovered that hal.hotplug has the same
problem, it reliably takes 1.5s to run) but it's not the same one
somebody else reported. The problem does not happen when the dbus daemon
has not been loaded (in this case connect(2) quickly fails), but when
it's active.

-- 
ciao, |
Marco | [5043 trjdAwZYVRluk]


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev and dbus

[Marco d'Itri]

On Mar 11, Greg KH <greg@kroah.com> wrote:

> On Thu, Mar 11, 2004 at 09:55:54AM +0100, Martin Waitz wrote:
> > hi :)
> > 
> > On Wed, Mar 10, 2004 at 05:28:05PM -0800, Greg KH wrote:
> > > Why "/usr/sbin/udev" first?  According to the LSB, everything in
> > > /sbin/ is needed for boot, not /usr/sbin, right?
> > 
> > then it will execute the big version if it is available and
> > will use the small boot-only from /sbin otherwise.
> 
> But again, why?  What about my /etc/udev.d/ proposal instead?

What else is supposed to use it? It looks a bit overdesigned to me.
Other applications can listen to the HAL message to know when the
device node has been created.

I proposed that I make a patch to try both /usr/sbin/udev and
/sbin/udev, try it in the debian package and see what happens.

-- 
ciao, |
Marco | [5044 mekCNRvCg3M.g]


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev and dbus

[David Zeuthen]

On Fri, 2004-03-12 at 17:40, Daniel Stekloff wrote:
> Hi, I'm curious - are the projects higher in the stack like hal only concerned 
> with those devices named by udev? Or, are they interested in all system 
> devices? The two sets aren't the same, udev is only concerned with a subset 
> of system devices and doesn't manage or name all devices represented in /sys. 
> I'd imagine that hal would be interested in all devices reported through /sys 
> and if this is the case, shouldn't those projects then place their scripts in 
> /etc/hotplug.d? 
> 

hal does care about bus devices (e.g. non-class devices like USB, PCI
etc.) and hal does install a symlink, hal.hotplug, in
/etc/hotplug.d/default to catch these and fire off messages to the hal
daemon.

Now, the problem today is that this script is invoked before
udev.hotplug, because, I guess, h is before u. 

What I want to do is to symlink another script into /etc/udev.d to fire
off a message to the hal daemon. That would give me two scripts, not
just one, which is fine and nice. 

The alternative Kay is suggesting isn't necessarily nice; I would invoke
udevinfo from hal.hotplug but I would have to apply some intelligence
because not every hotplug event corresponds to udev creating/removing
device nodes. Hotplug events and device node creation/destruction are
two conceptually different things and they should have separate
directories for callouts.

Thanks,
David


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev and dbus

[Kay Sievers]

On Sat, 2004-03-13 at 16:22 +0100, David Zeuthen wrote:
> On Fri, 2004-03-12 at 17:40, Daniel Stekloff wrote:
> > Hi, I'm curious - are the projects higher in the stack like hal only concerned 
> > with those devices named by udev? Or, are they interested in all system 
> > devices? The two sets aren't the same, udev is only concerned with a subset 
> > of system devices and doesn't manage or name all devices represented in /sys. 
> > I'd imagine that hal would be interested in all devices reported through /sys 
> > and if this is the case, shouldn't those projects then place their scripts in 
> > /etc/hotplug.d? 
> > 
> 
> hal does care about bus devices (e.g. non-class devices like USB, PCI
> etc.) and hal does install a symlink, hal.hotplug, in
> /etc/hotplug.d/default to catch these and fire off messages to the hal
> daemon.
> 
> Now, the problem today is that this script is invoked before
> udev.hotplug, because, I guess, h is before u. 
> 
> What I want to do is to symlink another script into /etc/udev.d to fire
> off a message to the hal daemon. That would give me two scripts, not
> just one, which is fine and nice. 

What is the nice part of two scripts, when you can live with one?

> The alternative Kay is suggesting isn't necessarily nice; I would invoke
> udevinfo from hal.hotplug but I would have to apply some intelligence
> because not every hotplug event corresponds to udev creating/removing
> device nodes.

Only if you need any info from the udevdb you _may_ ask for it with
udevinfo.

The creation an removal of the dynamic nodes are only the first part of
a hotplug handling  sequence, not a magic stack inside of any complex
event logic.

The kernel notifies you about a new device to use in _userspace_. So
it's natural to create the "gate" to this device first. Nobody needs to
know who creates the device nodes. And why put one script in some magic
udev.d/ script engine and the other in the hotplug.d/ script machinery?

What exactly is the problem to execute udevsend as the first program and
all following scripts can be sure to have all attribute and nodes
created? udev is so fast that you will not notice it, and every hotplug
event for a different devpth will run in parallel.

>  Hotplug events and device node creation/destruction are
> two conceptually different things and they should have separate
> directories for callouts.

There are _a_ sequence, not different things.
I still strongly disagree.

thanks,
Kay



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev and dbus

[Olaf Hering]

 On Thu, Mar 11, Kay Sievers wrote:

> On Thu, 2004-03-11 at 19:32, Greg KH wrote:
> > On Thu, Mar 11, 2004 at 07:12:55PM +0100, Kay Sievers wrote:
> > > 
> > > I expect lot of lazy people to put their scripts in there, cause it's so
> > > comfortable to live inside the serialized hotplug events.
> > 
> > But people want to know about the device node creation and removal, they
> > don't care about the "raw" hotplug events.  They want udev to handle the
> > raw hotplug events for them.
> 
> I don't agree.
> 
> > > Something like this:
> > > "Nice, I can mount my USB-stick with udev.d/ right after udev has
> > > created my partition node, cause the scsi.agent was too fast..."
> > 
> > No, how can scsi.agent know about what the device node name was?  It
> > can't.
> 
> udevinfo! That's what it's made for :)

what about nodes="`UDEV_PRINT_NODES=1 udev $1`"
which fills $nodes will the name and the symlinks for DEVPATH? This can
work for add and remove events.

diff -pur udev-klibc/udev-add.c udev-klibc-debug/udev-add.c
--- udev-klibc/udev-add.c	2004-03-14 20:01:19.000000000 +0100
+++ udev-klibc-debug/udev-add.c	2004-03-14 20:56:15.573334811 +0100
@@ -197,6 +197,7 @@ static int create_node(struct udevice *d
 	int tail;
 	char *pos;
 	int len;
+	char *printnodes;
 
 	strfieldcpy(filename, udev_root);
 	strfieldcat(filename, dev->name);
@@ -217,6 +218,8 @@ static int create_node(struct udevice *d
 		return -EINVAL;
 	}
 
+	printnodes = getenv(UDEV_PRINT_NODES);
+
 	/* create parent directories if needed */
 	if (strrchr(dev->name, '/'))
 		create_path(filename);
@@ -257,6 +260,8 @@ static int create_node(struct udevice *d
 		unlink_entry(filename);
 		info("creating device node '%s'", filename);
 		make_node(filename, dev->major, dev->minor, dev->mode, uid, gid);
+		if (printnodes)
+			fprintf(stdout, "%s", filename);
 	} else {
 		info("creating device node '%s', major = '%d', minor = '%d', "
 		     "mode = '%#o', uid = '%d', gid = '%d'", filename,
@@ -316,8 +321,13 @@ static int create_node(struct udevice *d
 			if (retval != 0)
 				dbg("symlink(%s, %s) failed with error '%s'",
 				    linktarget, filename, strerror(errno));
+			else 
+			if (printnodes)
+				fprintf(stdout, " %s", filename);
 		}
 	}
+	if (printnodes)
+		fprintf(stdout, "\n");
 
 	return retval;
 }
diff -pur udev-klibc/udev-remove.c udev-klibc-debug/udev-remove.c
--- udev-klibc/udev-remove.c	2004-03-14 20:01:19.000000000 +0100
+++ udev-klibc-debug/udev-remove.c	2004-03-14 20:56:20.710112187 +0100
@@ -73,11 +73,14 @@ static int delete_node(struct udevice *d
 	int retval;
 	int i;
 	char *pos;
+	char *printnodes;
 	int len;
 
 	strfieldcpy(filename, udev_root);
 	strfieldcat(filename, dev->name);
 
+	printnodes = getenv(UDEV_PRINT_NODES);
+
 	info("removing device node '%s'", filename);
 	retval = unlink(filename);
 	if (errno = ENOENT)
@@ -88,6 +91,9 @@ static int delete_node(struct udevice *d
 		return retval;
 	}
 
+	if (printnodes)
+		fprintf(stdout, "%s", filename);
+
 	/* remove partition nodes */
 	if (dev->partitions > 0) {
 		info("removing partitions '%s[1-%i]'", filename, dev->partitions);
@@ -116,10 +122,14 @@ static int delete_node(struct udevice *d
 				filename, strerror(errno));
 			return retval;
 		}
+		if (printnodes)
+			fprintf(stdout, " %s", filename);
 		if (strchr(dev->symlink, '/')) {
 			delete_path(filename);
 		}
 	}
+	if (printnodes)
+		fprintf(stdout, "\n");
 
 	return retval;
 }
diff -pur udev-klibc/udev.h udev-klibc-debug/udev.h
--- udev-klibc/udev.h	2004-03-14 20:01:19.000000000 +0100
+++ udev-klibc-debug/udev.h	2004-03-14 20:55:53.998269342 +0100
@@ -103,6 +103,8 @@ do { \
 	    pos = pos + len + strspn(pos, separator), len = strcspn(pos, separator)) \
 		if (len > 0)
 
+#define UDEV_PRINT_NODES "UDEV_PRINT_NODES"
+
 static inline char *get_action(void)
 {
 	char *action;
-- 
USB is for mice, FireWire is for men!

sUse lINUX ag, n√úRNBERG


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&opÃk
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev and dbus

[Kay Sievers]

On Sun, 2004-03-14 at 20:59, Olaf Hering wrote:
>  On Thu, Mar 11, Kay Sievers wrote:
> 
> > On Thu, 2004-03-11 at 19:32, Greg KH wrote:
> > > On Thu, Mar 11, 2004 at 07:12:55PM +0100, Kay Sievers wrote:
> > > > 
> > > > I expect lot of lazy people to put their scripts in there, cause it's so
> > > > comfortable to live inside the serialized hotplug events.
> > > 
> > > But people want to know about the device node creation and removal, they
> > > don't care about the "raw" hotplug events.  They want udev to handle the
> > > raw hotplug events for them.
> > 
> > I don't agree.
> > 
> > > > Something like this:
> > > > "Nice, I can mount my USB-stick with udev.d/ right after udev has
> > > > created my partition node, cause the scsi.agent was too fast..."
> > > 
> > > No, how can scsi.agent know about what the device node name was?  It
> > > can't.
> > 
> > udevinfo! That's what it's made for :)
> 
> what about nodes="`UDEV_PRINT_NODES=1 udev $1`"
> which fills $nodes will the name and the symlinks for DEVPATH? This can
> work for add and remove events.

It will not work. udev is executed by udevd after getting the message
from udevsend. What's the problem with asking the db if you need the
names?

thanks,
Kay



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev and dbus

[Olaf Hering]

 On Sun, Mar 14, Kay Sievers wrote:

> It will not work. udev is executed by udevd after getting the message
> from udevsend. What's the problem with asking the db if you need the
> names?

There is no hard requirement to run udev via udevd, I hope that will not
change?
I have seen races in db access where the symlinks field is empty,
usually in the block.agent. But its hard to reproduce.
Why call yet another app when udev can do it without overhead?

-- 
USB is for mice, FireWire is for men!

sUse lINUX ag, n√úRNBERG


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&opÃk
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel