Hello people!
When I load a module (with modprobe) the relative device is too
slowly created with udev, so modprobe return before the device
is really created. Because of this my init.d script will
fail with modular microcode + udev
test case:
udev + modular microcode:
$ modprobe -r microcode
$ modprobe microcode ; microcode_ctl -u
=> microcode_ctl does NOT find the device
$ modprobe -r microcode
$ modprobe microcode ; sleep 3; microcode_ctl -u
=> microcode_ctl FIND the device
[without udev it is OK, so I assume no errors
in modprobe]
Is it a bug of udev?
Else what workaround I can use? (sleep is to slow for
an already to sloow system initialitation)
ciao
cate
On Tue, 2004-09-14 at 20:33 +0200, Giacomo A. Catenazzi wrote:
> Hello people!
>
> When I load a module (with modprobe) the relative device is too
> slowly created with udev, so modprobe return before the device
> is really created. Because of this my init.d script will
> fail with modular microcode + udev
>
> test case:
>
> udev + modular microcode:
> $ modprobe -r microcode
> $ modprobe microcode ; microcode_ctl -u
> => microcode_ctl does NOT find the device
>
> $ modprobe -r microcode
> $ modprobe microcode ; sleep 3; microcode_ctl -u
> => microcode_ctl FIND the device
>
> [without udev it is OK, so I assume no errors
> in modprobe]
>
> Is it a bug of udev?
> Else what workaround I can use? (sleep is to slow for
> an already to sloow system initialitation)
I don't know of a proper fix, but a better work around would be to
use...
while [ ! -c /dev/cpu/microcode ]; do sleep 0; done
...in place of your "sleep 3". Replacing the /dev/cpu/microcode with
the actual character device that microcode_ctl is looking for.
--
Chris
Giacomo A. Catenazzi wrote:
> udev + modular microcode:
> $ modprobe -r microcode
> $ modprobe microcode ; microcode_ctl -u
> => microcode_ctl does NOT find the device
The loading of the module triggers udev to run. There is no guarantee that udev
runs before microcode_ctl.
One workaround would be to have microcode_ctl use dnotify to get woken up
whenever /dev changes.
There may be other ways to do this as well, but Greg would be the guy for that.
Chris
On Tue, Sep 14, 2004 at 01:40:22PM -0600, Chris Friesen wrote:
> Giacomo A. Catenazzi wrote:
>
> >udev + modular microcode:
> >$ modprobe -r microcode
> >$ modprobe microcode ; microcode_ctl -u
> >=> microcode_ctl does NOT find the device
>
> The loading of the module triggers udev to run. There is no guarantee that
> udev runs before microcode_ctl.
>
> One workaround would be to have microcode_ctl use dnotify to get woken up
> whenever /dev changes.
Ick, no. Use the /etc/dev.d/ notify method I described. That is what
it is there for.
thanks,
greg k-h
Greg KH wrote:
> On Tue, Sep 14, 2004 at 01:40:22PM -0600, Chris Friesen wrote:
>>One workaround would be to have microcode_ctl use dnotify to get woken up
>>whenever /dev changes.
>
>
> Ick, no. Use the /etc/dev.d/ notify method I described. That is what
> it is there for.
Right. Sorry, it's been a while since I looked at udev.
Chris
Greg KH wrote:
> On Tue, Sep 14, 2004 at 01:40:22PM -0600, Chris Friesen wrote:
>
>>Giacomo A. Catenazzi wrote:
>>
>>
>>>udev + modular microcode:
>>>$ modprobe -r microcode
>>>$ modprobe microcode ; microcode_ctl -u
>>>=> microcode_ctl does NOT find the device
>>
>>The loading of the module triggers udev to run. There is no guarantee that
>>udev runs before microcode_ctl.
>>
>>One workaround would be to have microcode_ctl use dnotify to get woken up
>>whenever /dev changes.
>
>
> Ick, no. Use the /etc/dev.d/ notify method I described. That is what
> it is there for.
>
After a brief discussion with debian udev maintainer, I've an
other proposal/opinion.
The "bug" appear only in two places: at udev start and after
a modprobe, so IMHO we should correct these two place, so that:
- from a user side perspective it is the right thing!
(after a successful modprobe, I expect module and devices
are created sussesfully)
- there are not many special case:
with udev use dev.d, else do actions now!
Else every distribution should create a script for
every init.d script that would eventually use (also
indirectly) a kernel module.
ciao
cate
Chris Friesen wrote:
> Re: udev is too slow creating devices
Never noticed that all devices are created at the right time
and since udev know more device nodes it really great.
I went to udev for about 6month without big problems.
On Tue, Sep 14, 2004 at 08:33:22PM +0200, Giacomo A. Catenazzi wrote:
> Hello people!
>
> When I load a module (with modprobe) the relative device is too
> slowly created with udev, so modprobe return before the device
> is really created. Because of this my init.d script will
> fail with modular microcode + udev
>
> test case:
>
> udev + modular microcode:
> $ modprobe -r microcode
> $ modprobe microcode ; microcode_ctl -u
> => microcode_ctl does NOT find the device
>
> $ modprobe -r microcode
> $ modprobe microcode ; sleep 3; microcode_ctl -u
> => microcode_ctl FIND the device
>
> [without udev it is OK, so I assume no errors
> in modprobe]
>
> Is it a bug of udev?
No, it's just the way it now works.
> Else what workaround I can use? (sleep is to slow for
> an already to sloow system initialitation)
Run microcode_ctl from a script in /etc/dev.d/microcode/ See the file:
http://kernel.org/pub/linux/utils/kernel/hotplug/RFC-dev.d
for more information on now /etc/dev.d works.
thanks,
greg k-h
On Tue, Sep 14, 2004 at 10:43:41PM +0200, Giacomo A. Catenazzi wrote:
> The "bug" appear only in two places: at udev start and after
> a modprobe, so IMHO we should correct these two place, so that:
> - from a user side perspective it is the right thing!
> (after a successful modprobe, I expect module and devices
> are created sussesfully)
That "expectation" is incorrect. The device node will show up any time
after modprobe has started, just because modprobe returns does not mean
the device node is present.
> - there are not many special case:
> with udev use dev.d, else do actions now!
I don't understand what you are proposing.
> Else every distribution should create a script for
> every init.d script that would eventually use (also
> indirectly) a kernel module.
What's wrong with the /etc/dev.d/ location for any type of script that
you want to run after a device node has appeared? This is an
application specific issue, not a kernel issue.
thanks,
greg k-h
On Sep 14, Greg KH <[email protected]> wrote:
> What's wrong with the /etc/dev.d/ location for any type of script that
> you want to run after a device node has appeared? This is an
> application specific issue, not a kernel issue.
The problem is that since most distributions cannot make udev usage
mandatory, this would require duplicating in the init script and in the
dev.d script whatever needs to be done with the device.
Then there are the issues of scripts needing programs in /usr, which may
not be mounted when the module is loaded, or which are interactive and
need console access (think fsck).
Basically asyncronous creation of devices requires a ground up redesign
of the init scripts of a distribution. I'm not claiming that this is not
possible, but it's not going to happen soon.
--
ciao, |
Marco | [8002 aveHSeIFcnkpI]
On Tue, Sep 14, 2004 at 11:45:52PM +0200, Marco d'Itri wrote:
> On Sep 14, Greg KH <[email protected]> wrote:
>
> > What's wrong with the /etc/dev.d/ location for any type of script that
> > you want to run after a device node has appeared? This is an
> > application specific issue, not a kernel issue.
> The problem is that since most distributions cannot make udev usage
> mandatory, this would require duplicating in the init script and in the
> dev.d script whatever needs to be done with the device.
Well, that sounds like a distro problem then, not a kernel or udev one :)
> Then there are the issues of scripts needing programs in /usr, which may
> not be mounted when the module is loaded, or which are interactive and
> need console access (think fsck).
True, so sit and spin and sleep until you see the device node. That's
how a number of distros have fixed the fsck startup issue.
> Basically asyncronous creation of devices requires a ground up redesign
> of the init scripts of a distribution. I'm not claiming that this is not
> possible, but it's not going to happen soon.
Well, it needs to go that way, as the kernel moves toward not providing
the device node right when modprobe returns with the advent of
multi-threading device discovery and such. That's why the /etc/dev.d
heirachy was created, it's not dependant on udev to provide such a
solution. I suggest that distros that do not use udev (of which Debian
is slowly becoming a miniority) create a tool that causes /etc/dev.d
events for a static /dev tree.
thanks,
greg k-h
On Tue, 14 Sep 2004 22:43:41 +0200
"Giacomo A. Catenazzi" <[email protected]> wrote:
>
> After a brief discussion with debian udev maintainer, I've an
> other proposal/opinion.
>
> The "bug" appear only in two places: at udev start and after
> a modprobe, so IMHO we should correct these two place, so that:
This cannot be fixed easily and there would be little gain but great
risks. For example, I have a device where reading partition tables can
take up to two seconds. Other devices could be broken and modprobe would
never return. This would effectively freeze the system when it happens in
boot scripts.
> - from a user side perspective it is the right thing!
> (after a successful modprobe, I expect module and devices
> are created sussesfully)
This assumption is wrong, even with a completely static /dev.
Common example:
modprobe usb-storage / ppa / whatever
Now, for any reason the kernel is unable to read the partition table.
The script tries to access /dev/sda1 => boom
In fact, udev is even an improvement here. Instead of checking the device
node repeatedly you simply wait for udev to call you. When it does you can
be sure that the device node exists and is valid.
> Else every distribution should create a script for
> every init.d script that would eventually use (also
> indirectly) a kernel module.
Why not? This is the best way to achieve true and reliable hotplug
support.
Regards
On Tue, Sep 14, 2004 at 02:51:22PM -0700, Greg KH wrote:
> True, so sit and spin and sleep until you see the device node. That's
> how a number of distros have fixed the fsck startup issue.
that's more a band-aid than a fix (I can imagine a userspace hang if the
device isn't created for whatever reason), if there's no way to do
better than this if you've to run fsck (or if it's not the best to run
the fsck inside the dev.d scripts), then probably this needs better
fixing. is such a big problem to execute a sys_wait4 to wait the udev
userspace to return before returning from the insmod syscall?
On Wed, Sep 15, 2004 at 12:47:31AM +0200, Andrea Arcangeli wrote:
> On Tue, Sep 14, 2004 at 02:51:22PM -0700, Greg KH wrote:
> > True, so sit and spin and sleep until you see the device node. That's
> > how a number of distros have fixed the fsck startup issue.
>
> that's more a band-aid than a fix (I can imagine a userspace hang if the
> device isn't created for whatever reason), if there's no way to do
> better than this if you've to run fsck (or if it's not the best to run
> the fsck inside the dev.d scripts), then probably this needs better
> fixing. is such a big problem to execute a sys_wait4 to wait the udev
> userspace to return before returning from the insmod syscall?
But how do you know what to wait for?
If you modprobe a usb-storage driver, and the usb bus is not done
discovering devices, the insmod will instantly return, and only some
time later will the device node be created after the device is
discovered by the bus and then passed to the module you already loaded.
Sitting and waiting is a band-aid, I agree. That's why we created the
/etc/dev.d/ notifier system to fix this issue (that is there for systems
that don't even use udev.)
thanks,
greg k-h
On Tue, Sep 14, 2004 at 04:04:09PM -0700, Greg KH wrote:
> On Wed, Sep 15, 2004 at 12:47:31AM +0200, Andrea Arcangeli wrote:
> > On Tue, Sep 14, 2004 at 02:51:22PM -0700, Greg KH wrote:
> > > True, so sit and spin and sleep until you see the device node. That's
> > > how a number of distros have fixed the fsck startup issue.
> >
> > that's more a band-aid than a fix (I can imagine a userspace hang if the
> > device isn't created for whatever reason), if there's no way to do
> > better than this if you've to run fsck (or if it's not the best to run
> > the fsck inside the dev.d scripts), then probably this needs better
> > fixing. is such a big problem to execute a sys_wait4 to wait the udev
> > userspace to return before returning from the insmod syscall?
>
> But how do you know what to wait for?
the kernel sure can know about it, by passing a waitqueue into the
registration routine and calling wake_up once the discovery is over.
> Sitting and waiting is a band-aid, I agree. That's why we created the
> /etc/dev.d/ notifier system to fix this issue (that is there for systems
> that don't even use udev.)
if the fsck can run from there ok, if for some reason it's not feasible
to run it from there (like if it would create a bus congestion by
running all the fsck in parallel if you attach multiple devices at the
same time), and/or you need some other seriaization, then probably
having a way to run things serially without a
spin-and-sleep-and-risk-to-hang could be needed. I guess in the worst
case one could serialize things by using file locking in /var/run
and by creating an API between the dev.d and the init.d scripts, is that
how the long term is supposed to work?
So it's more a question if the current interface is complete for all
usages, and if the fsck spin-and-sleep is just a temporary band-aid, or
if the spin-and-sleep is supposed to last longer than a few month
release cycle.
(and I'm not a udev guru, just in listen mode ;)
On Wed, 2004-09-15 at 01:20 +0200, Andrea Arcangeli wrote:
> On Tue, Sep 14, 2004 at 04:04:09PM -0700, Greg KH wrote:
> > On Wed, Sep 15, 2004 at 12:47:31AM +0200, Andrea Arcangeli wrote:
> > > On Tue, Sep 14, 2004 at 02:51:22PM -0700, Greg KH wrote:
> > > > True, so sit and spin and sleep until you see the device node. That's
> > > > how a number of distros have fixed the fsck startup issue.
> > >
> > > that's more a band-aid than a fix (I can imagine a userspace hang if the
> > > device isn't created for whatever reason), if there's no way to do
> > > better than this if you've to run fsck (or if it's not the best to run
> > > the fsck inside the dev.d scripts), then probably this needs better
> > > fixing. is such a big problem to execute a sys_wait4 to wait the udev
> > > userspace to return before returning from the insmod syscall?
> >
> > But how do you know what to wait for?
>
> the kernel sure can know about it, by passing a waitqueue into the
> registration routine and calling wake_up once the discovery is over.
>
> > Sitting and waiting is a band-aid, I agree. That's why we created the
> > /etc/dev.d/ notifier system to fix this issue (that is there for systems
> > that don't even use udev.)
>
> if the fsck can run from there ok, if for some reason it's not feasible
> to run it from there (like if it would create a bus congestion by
> running all the fsck in parallel if you attach multiple devices at the
> same time), and/or you need some other seriaization, then probably
> having a way to run things serially without a
> spin-and-sleep-and-risk-to-hang could be needed. I guess in the worst
> case one could serialize things by using file locking in /var/run
> and by creating an API between the dev.d and the init.d scripts, is that
> how the long term is supposed to work?
>
> So it's more a question if the current interface is complete for all
> usages, and if the fsck spin-and-sleep is just a temporary band-aid, or
> if the spin-and-sleep is supposed to last longer than a few month
> release cycle.
Surely fsck can be done on top of /etc/dev.d/ by just writing to a FIFO?
That'll serialize up the fsck caller...
--
// Gianni Tedesco (gianni at scaramanga dot co dot uk)
lynx --source http://www.scaramanga.co.uk/scaramanga.asc | gpg --import
8646BE7D: 6D9F 2287 870E A2C9 8F60 3A3C 91B5 7669 8646 BE7D
On Wed, Sep 15, 2004 at 12:34:40AM +0100, Gianni Tedesco wrote:
> Surely fsck can be done on top of /etc/dev.d/ by just writing to a FIFO?
> That'll serialize up the fsck caller...
with file locking in /var/run I didn't necessairly meant to call
flock(2), the fifo in your example would act like a mutex lock, but more
than the fifo, we need a bit more of API, the dev.d script will have to
look for a certain file in /var/run and block on it to serialize. I just
hope the spin loops will go away soon from the userspace ;)
Greg KH wrote:
> Sitting and waiting is a band-aid, I agree. That's why we created the
> /etc/dev.d/ notifier system to fix this issue (that is there for systems
> that don't even use udev.)
Hello Greg!
[note that I really appreciate udev].
You said me to use dev.d, but really I don't see it as a working
solution. Maybe because I missinterpreted the documentation,
so maybe you can give me some hints.
Real case: distribution boot script.
It should work with non udev kernel, udev non modular kernel and
udev very modular kernel. The script load (directly or not) a module
and need the device impelmented by module.
Old behaviour (modprobe "waits" for the creation of device):
normal init.d script, with normal boot priorities.
New behaviour (dev.d). What I should do?
My init.d script is loaded with priority XX, so
I require that dev.d on my device is executed after
boot priority XX (else I don't have the needed
functionalities), also in case of non-udev or non modular kernel.
How should I implement script in dev.d/?
I see some design problems in dev.d/, or am I wrong?
ciao
cate
PS: - What are the best (on topic) mailing list?
- What do other distributions?
Hi Giacomo,
I use udev since its out..and haven't had any big problems.
The database of know and often needed device notes increases.
To your question which Distro do you use?
For the udev you also need so called udev-rules and perms. do you have
them in /etc/conf.d/ or etc/env? which version of udev you are using rn?
Greets Michael
On Wed, 2004-09-15 at 14:55, Giacomo A. Catenazzi wrote:
> Old behaviour (modprobe "waits" for the creation of device):
I wonder if it would be feasible for modprobe (or some other utility) to
have a new option: --wait-for=/dev/something which would wait for the
device node to appear. Perhaps by:
- some mechanism based on HAL, DBUS, whatever
- dnotify on /dev/?
- falling back to spinning and waiting.
The first two sound nice since they avoid spinning and sleeping for a
second at a time, which just adds to the delay.
In addition a timeout of some sort to give an upper bound would seem
like a good idea.
Ian.
--
Ian Campbell, Senior Design Engineer
Web: http://www.arcom.com
Arcom, Clifton Road, Direct: +44 (0)1223 403 465
Cambridge CB1 7EA, United Kingdom Phone: +44 (0)1223 411 200
Salut,
On Wed, Sep 15, 2004 at 03:36:06PM +0100, Ian Campbell wrote:
> I wonder if it would be feasible for modprobe (or some other utility) to
> have a new option: --wait-for=/dev/something which would wait for the
> device node to appear. Perhaps by:
> - some mechanism based on HAL, DBUS, whatever
> - dnotify on /dev/?
> - falling back to spinning and waiting.
This would end up as hideous misfeature as you can't guarantee the
device to show up *at* *all*.
The reason udev is there is that we can dynamically respond to created
device nodes and devices that show up. They might have changed since
the last boot. Maybe they don't show up at all.
Thus you should trigger your actions from /etc/dev.d.
Tonnerre
Tonnerre wrote:
>
> On Wed, Sep 15, 2004 at 03:36:06PM +0100, Ian Campbell wrote:
>
>>I wonder if it would be feasible for modprobe (or some other utility) to
>>have a new option: --wait-for=/dev/something which would wait for the
>>device node to appear. Perhaps by:
>> - some mechanism based on HAL, DBUS, whatever
>> - dnotify on /dev/?
>> - falling back to spinning and waiting.
>
>
> This would end up as hideous misfeature as you can't guarantee the
> device to show up *at* *all*.
>
> The reason udev is there is that we can dynamically respond to created
> device nodes and devices that show up. They might have changed since
> the last boot. Maybe they don't show up at all.
>
> Thus you should trigger your actions from /etc/dev.d.
It is right.
But an option --wait would be sufficient.
This option will require modprobe to wait (with a timeout of
x seconds) that hotplug event finish (so if device is created or
not is no more a problem).
Ideally this should be done modifing only hotplug and IMHO
should be enabled by default.
ciao
cate
On Wed, Sep 15, 2004 at 03:55:26PM +0200, Giacomo A. Catenazzi wrote:
>
> Real case: distribution boot script.
> It should work with non udev kernel, udev non modular kernel and
> udev very modular kernel.
That's a lot to ask for a simple script :)
Why not just pick one of those options and go with it?
> The script load (directly or not) a module
> and need the device impelmented by module.
Then do the 'sit and spin' method. That works for all of the above
options, right?
> Old behaviour (modprobe "waits" for the creation of device):
> normal init.d script, with normal boot priorities.
Please realize that this "behaviour" is not guaranteed at all. And in
fact will be changing in the future so that it is _not_ the way it will
work.
> New behaviour (dev.d). What I should do?
> My init.d script is loaded with priority XX, so
> I require that dev.d on my device is executed after
> boot priority XX (else I don't have the needed
> functionalities), also in case of non-udev or non modular kernel.
> How should I implement script in dev.d/?
dev.d is called by the kernel, not your script. You don't have to set a
priority of when dev.d runs at all, it's not necessary.
> I see some design problems in dev.d/, or am I wrong?
What problems?
> PS: - What are the best (on topic) mailing list?
linux-hotplug-devel
> - What do other distributions?
What do they do? They just work :)
thanks,
greg k-h
On Wed, Sep 15, 2004 at 01:20:11AM +0200, Andrea Arcangeli wrote:
> On Tue, Sep 14, 2004 at 04:04:09PM -0700, Greg KH wrote:
> > On Wed, Sep 15, 2004 at 12:47:31AM +0200, Andrea Arcangeli wrote:
> > > On Tue, Sep 14, 2004 at 02:51:22PM -0700, Greg KH wrote:
> > > > True, so sit and spin and sleep until you see the device node. That's
> > > > how a number of distros have fixed the fsck startup issue.
> > >
> > > that's more a band-aid than a fix (I can imagine a userspace hang if the
> > > device isn't created for whatever reason), if there's no way to do
> > > better than this if you've to run fsck (or if it's not the best to run
> > > the fsck inside the dev.d scripts), then probably this needs better
> > > fixing. is such a big problem to execute a sys_wait4 to wait the udev
> > > userspace to return before returning from the insmod syscall?
> >
> > But how do you know what to wait for?
>
> the kernel sure can know about it, by passing a waitqueue into the
> registration routine and calling wake_up once the discovery is over.
But the low level driver (like a USB driver for example), has no way of
knowing when the "device discovery" process is over. Actually the USB
core never knows this either, as devices come and go all the time.
That's why we had to move to the "probe" and "release" way of writing
drivers. The bus cores notify the driver when they find something, as
the driver never knows when a device is found.
So the kernel can not know what or when to wait for something it doesn't
know is going to ever happen in the future.
Does that make more sense now?
Remember, this isn't your old "static device tree" unix-like kernel that
people grew up with, anymore. :)
thanks,
greg k-h
On Wed, Sep 15, 2004 at 05:45:03PM +0200, Giacomo A. Catenazzi wrote:
>
>
> Tonnerre wrote:
> >
> >On Wed, Sep 15, 2004 at 03:36:06PM +0100, Ian Campbell wrote:
> >
> >>I wonder if it would be feasible for modprobe (or some other utility) to
> >>have a new option: --wait-for=/dev/something which would wait for the
> >>device node to appear. Perhaps by:
> >> - some mechanism based on HAL, DBUS, whatever
> >> - dnotify on /dev/?
> >> - falling back to spinning and waiting.
> >
> >
> >This would end up as hideous misfeature as you can't guarantee the
> >device to show up *at* *all*.
> >
> >The reason udev is there is that we can dynamically respond to created
> >device nodes and devices that show up. They might have changed since
> >the last boot. Maybe they don't show up at all.
> >
> >Thus you should trigger your actions from /etc/dev.d.
>
> It is right.
> But an option --wait would be sufficient.
> This option will require modprobe to wait (with a timeout of
> x seconds) that hotplug event finish (so if device is created or
> not is no more a problem).
> Ideally this should be done modifing only hotplug and IMHO
> should be enabled by default.
Um, I don't think this is posible to do at all. But hey, go ahead and
implement it to prove me wrong :)
good luck,
greg k-h
On Wed, Sep 15, 2004 at 03:36:06PM +0100, Ian Campbell wrote:
> On Wed, 2004-09-15 at 14:55, Giacomo A. Catenazzi wrote:
> > Old behaviour (modprobe "waits" for the creation of device):
>
> I wonder if it would be feasible for modprobe (or some other utility) to
> have a new option: --wait-for=/dev/something which would wait for the
> device node to appear.
Why? What's the point? You are asking to paper over the way the kernel
works (remember storage devices are on lots of different kinds of busses
today...)
The fact that a static /dev keeps these race conditions from showing up
as often as they really are there is no reason to keep trying to rely on
old, undefined behaviour :)
thanks,
greg k-h
On Wed, 15 Sep 2004 17:45:03 +0200
"Giacomo A. Catenazzi" <[email protected]> wrote:
> It is right.
> But an option --wait would be sufficient.
> This option will require modprobe to wait (with a timeout of
> x seconds) that hotplug event finish (so if device is created or
> not is no more a problem).
> Ideally this should be done modifing only hotplug and IMHO
> should be enabled by default.
At the moment th hotplug event finishes nothing is guaranteed. In fact,
the device node is never created at this point. All you know is that udev
will now *begin* to create the node. You don't know how long it will take
or if it will succeed at all.
As i understand, udev definitely has to be involved in this process. It
would need a way to inform modprobe of its state.
Maybe something like an udev state could be added. The script would
pass a cookie to modprobe, which would in turn pass it to the kernel (or
to udevd?), which would add it to the hotplug event. udev would then place
the cookie in a defined file that is checked by modprobe. If that cookie's
state is set to "done" modprobe would return and the script would
continue.
Example:
modprobe blah -c cookie-123
"cookie-123" is passed to the kernel and returned by all hotplug events
this modprobe triggers.
udev will then place something like "cookie-123=>processing" in
/dev/udev-state.
modprobe is still running and will poll this file until it contains
"cookie-123=>finished". When that happens modprobe will tell udevd to
remove this entry and return succesfully. If the timeout is reached
modprobe will return an error code instead.
(Of course, modprobe could handle the cookie generation internally.)
This sound complicated and requires changes in many places. Maybe there is
an easier solution.
Regards
On Wed, Sep 15, 2004 at 06:51:16PM +0200, Marc Ballarin wrote:
> On Wed, 15 Sep 2004 17:45:03 +0200
> "Giacomo A. Catenazzi" <[email protected]> wrote:
>
> > It is right.
> > But an option --wait would be sufficient.
> > This option will require modprobe to wait (with a timeout of
> > x seconds) that hotplug event finish (so if device is created or
> > not is no more a problem).
> > Ideally this should be done modifing only hotplug and IMHO
> > should be enabled by default.
>
> At the moment th hotplug event finishes nothing is guaranteed. In fact,
> the device node is never created at this point. All you know is that udev
> will now *begin* to create the node. You don't know how long it will take
> or if it will succeed at all.
> As i understand, udev definitely has to be involved in this process. It
> would need a way to inform modprobe of its state.
>
> Maybe something like an udev state could be added. The script would
> pass a cookie to modprobe, which would in turn pass it to the kernel (or
> to udevd?), which would add it to the hotplug event. udev would then place
> the cookie in a defined file that is checked by modprobe. If that cookie's
> state is set to "done" modprobe would return and the script would
> continue.
>
> Example:
> modprobe blah -c cookie-123
> "cookie-123" is passed to the kernel and returned by all hotplug events
> this modprobe triggers.
Again, such tracking is pretty much impossible.
> udev will then place something like "cookie-123=>processing" in
> /dev/udev-state.
> modprobe is still running and will poll this file until it contains
> "cookie-123=>finished". When that happens modprobe will tell udevd to
> remove this entry and return succesfully. If the timeout is reached
> modprobe will return an error code instead.
>
> (Of course, modprobe could handle the cookie generation internally.)
>
> This sound complicated and requires changes in many places. Maybe there is
> an easier solution.
There is, just run your stuff off of /etc/dev.d/ and stop relying on a
device node to be present after modprobe returns.
thanks,
greg k-h
On Wed, Sep 15, 2004 at 09:15:41AM -0700, Greg KH wrote:
> But the low level driver (like a USB driver for example), has no way of
> knowing when the "device discovery" process is over. Actually the USB
> core never knows this either, as devices come and go all the time.
eventually the discovery will end with a call into userspace, it'd be
enough to wait4 and wakeup a waitqueue when the wait4 returns.
> So the kernel can not know what or when to wait for something it doesn't
> know is going to ever happen in the future.
the kernel certainly knows when it's about time to fork an userspace
process to create the device, doesn't it? then just wait4 while the
process is running.
> Remember, this isn't your old "static device tree" unix-like kernel that
> people grew up with, anymore. :)
if you intentionally don't want to provide serialization and force into
/var/run locking, that's fine with me, but I don't buy your claim that
it's not feasible.
Andrea Arcangeli wrote:
> the kernel certainly knows when it's about time to fork an userspace
> process to create the device, doesn't it? then just wait4 while the
> process is running.
Last I checked, if using udevsend the process that gets forked is not the same
process that actually creates the device node.
Chris
On Wed, Sep 15, 2004 at 04:09:27PM -0600, Chris Friesen wrote:
> Andrea Arcangeli wrote:
>
> >the kernel certainly knows when it's about time to fork an userspace
> >process to create the device, doesn't it? then just wait4 while the
> >process is running.
>
> Last I checked, if using udevsend the process that gets forked is not the
> same process that actually creates the device node.
Good point, so wait4 wouldn't be enough, you'd need a bit more of API on
the udev side. But be sure, if dev.d can make it with a FIFO lock in
/var/run, then the kernel can make it too.
Also note the maybe usb is just completely async and when you load the
device driver you've no idea of when you'll get the signal and it's
impossible to make it sync, fine. I'm really not talking about hotplug,
hotplug basically has to be async by design.
But the microcode driver has nothing to do with hotplug or usb, and
waiting for the device creation in the insmod syscall is sure natural
and doable. Now if we don't want to create a little bit of API in udev
to let insmod provide a sync behaviour and force people into the dev.d
scripts and file locking in /var/run that it's one issue (you can aruge
about higher perf), but there is a whole large class of devices that are
not hot-pluggable and where the discovery is definitely synchronous,
even common pci is fully sync in its discovery when you call
pci_find_device/get_device.
On Wed, Sep 15, 2004 at 09:21:34PM +0200, Andrea Arcangeli wrote:
> On Wed, Sep 15, 2004 at 09:15:41AM -0700, Greg KH wrote:
> > But the low level driver (like a USB driver for example), has no way of
> > knowing when the "device discovery" process is over. Actually the USB
> > core never knows this either, as devices come and go all the time.
>
> eventually the discovery will end with a call into userspace, it'd be
> enough to wait4 and wakeup a waitqueue when the wait4 returns.
But to wait for what? That's the point. The individual driver doesn't
know what it should be waiting for, if anything at all. That's why we
have the "probe" and "release" model for device drivers now.
> > So the kernel can not know what or when to wait for something it doesn't
> > know is going to ever happen in the future.
>
> the kernel certainly knows when it's about time to fork an userspace
> process to create the device, doesn't it? then just wait4 while the
> process is running.
Yes and no. You see there's a lot of hotplug events that get kicked off
when a device (such as a USB device) is discovered. We have the "here's
a device", "here's an interface on that device", "here's a scsi-host
controller that got bound to the interface", "here's a scsi device on
that host controller that got added", "here's a sg interface bound to
that scsi device", "here's a sd interface bound to that device", "here's
a block device attached to that sd interface", "here's a partition
belonging to that block device".
And all of those get kicked off by different kernel threads at different
times, all for one possible modprobe. And odds are that modprobe has
long returned by the time that last "block device" and "partition"
hotplug events get emitted by the kernel.
And different modprobe events all caused that end result (modprobing of
the bus, host controller, usb driver, scsi core, scsi disk, and scsi
generic modules.) Which modprobe will you want to wait for?
> > Remember, this isn't your old "static device tree" unix-like kernel that
> > people grew up with, anymore. :)
>
> if you intentionally don't want to provide serialization and force into
> /var/run locking, that's fine with me, but I don't buy your claim that
> it's not feasible.
I think it's not feasible. But feel free to dig through the
usb/scsi/driver core/block code to prove me wrong :)
In the meantime, the rest of us over here will be using the /etc/dev.d
interface...
thanks,
greg k-h
On Wed, Sep 15, 2004 at 03:23:36PM -0700, Greg KH wrote:
> generic modules.) Which modprobe will you want to wait for?
all the ones triggered by the modprobe? It's really a matter of sync and
async. if the discovery can be synchronous, then waiting for it is
doable. It's like when you call find_pci_device, you will sure know that
you will get either a definitive answer when the function returns, this
is not the case for USB it seems.
For scsi as well after the timeout triggers you know no device is
supposed to showup (and that's why boot has to be so slow, of course we
really should wait only for the root device and to scan all hosts in
parallel, but that's quite orthogonal, the issue is to get a synchronous
answer after a definite number of operations). if we hit an async path,
then I agree it doesn't even worth to wait and we should wakeup
immediatly.
> In the meantime, the rest of us over here will be using the /etc/dev.d
> interface...
I did aruge just because you said some of us is running a spin-and-sleep
instead of the /etc/dev.d interface, which contraddicts your statement
that everyone is using /etc/dev.d, which make it quite obvious using the
dev.d is more tricky than the old way. I have scripts myself insmodding
a device and then doing some I/O on it in /etc/init.d/boot.local, mixed
with other stuff, which is quite simple and works right now.
But I do certainly agree about your point in the other email that
sync-discovery could become a thing of the past, even if so far usb and
pci hotplug has been the exception ;). So sounds like we may just go
complicated for everything.
On Thu, Sep 16, 2004 at 12:15:23AM +0200, Andrea Arcangeli wrote:
>
> But the microcode driver has nothing to do with hotplug or usb, and
> waiting for the device creation in the insmod syscall is sure natural
> and doable. Now if we don't want to create a little bit of API in udev
> to let insmod provide a sync behaviour and force people into the dev.d
> scripts and file locking in /var/run that it's one issue (you can aruge
> about higher perf), but there is a whole large class of devices that are
> not hot-pluggable and where the discovery is definitely synchronous,
> even common pci is fully sync in its discovery when you call
> pci_find_device/get_device.
That will be soon going away with my multi-threaded device discovery
work. And I run pci hotplug boxes (and so do all of the PCMCIA/CardBus
users), so don't discard PCI from being a async bus type :)
Async is now the norm, and drivers like the microcode module are the
exception.
thanks,
greg k-h
Greg KH wrote:
> On Tue, Sep 14, 2004 at 11:45:52PM +0200, Marco d'Itri wrote:
>
>>On Sep 14, Greg KH <[email protected]> wrote:
>>
>>
>>>What's wrong with the /etc/dev.d/ location for any type of script that
>>>you want to run after a device node has appeared? This is an
>>>application specific issue, not a kernel issue.
>>
>>The problem is that since most distributions cannot make udev usage
>>mandatory, this would require duplicating in the init script and in the
>>dev.d script whatever needs to be done with the device.
>
>
> Well, that sounds like a distro problem then, not a kernel or udev one :)
>
>
>>Then there are the issues of scripts needing programs in /usr, which may
>>not be mounted when the module is loaded, or which are interactive and
>>need console access (think fsck).
>
>
> True, so sit and spin and sleep until you see the device node. That's
> how a number of distros have fixed the fsck startup issue.
Hm, why should _I_ sleep and spin after modprobe, without even knowing
if the node will appear at all, when you can include the "modprobe"
wrapper script with udev source package.
This wrapper should call modprobe.orig with original arguments, and then
call udev for /sys entries that appeared (or just run udevstart), and
only then return. Yes, this will result in duplicate hotplug events
(synthetic + real) being delivered to udev, but it solves the problem
with modprobe once, for all programs, and in compatible way.
--
Alexander E. Patrakov
Marc Ballarin wrote:
> On Wed, 15 Sep 2004 17:45:03 +0200
> "Giacomo A. Catenazzi" <[email protected]> wrote:
>
>
>>It is right.
>>But an option --wait would be sufficient.
>>This option will require modprobe to wait (with a timeout of
>>x seconds) that hotplug event finish (so if device is created or
>>not is no more a problem).
>>Ideally this should be done modifing only hotplug and IMHO
>>should be enabled by default.
>
>
> At the moment th hotplug event finishes nothing is guaranteed. In fact,
> the device node is never created at this point. All you know is that udev
> will now *begin* to create the node. You don't know how long it will take
> or if it will succeed at all.
> As i understand, udev definitely has to be involved in this process. It
> would need a way to inform modprobe of its state.
>
> Maybe something like an udev state could be added. The script would
> pass a cookie to modprobe, which would in turn pass it to the kernel (or
> to udevd?), which would add it to the hotplug event. udev would then place
> the cookie in a defined file that is checked by modprobe. If that cookie's
> state is set to "done" modprobe would return and the script would
> continue.
>
> Example:
> modprobe blah -c cookie-123
> "cookie-123" is passed to the kernel and returned by all hotplug events
> this modprobe triggers.
> udev will then place something like "cookie-123=>processing" in
> /dev/udev-state.
> modprobe is still running and will poll this file until it contains
> "cookie-123=>finished". When that happens modprobe will tell udevd to
> remove this entry and return succesfully. If the timeout is reached
> modprobe will return an error code instead.
>
> (Of course, modprobe could handle the cookie generation internally.)
>
> This sound complicated and requires changes in many places. Maybe there is
> an easier solution.
Yes, there is, and it is a purely userspace one. Instead of waiting for
those hotplug events, synthetize their duplicates in the "modprobe"
binary, pass directly to udev, and wait for these duplicates.
--
Alexander E. Patrakov
> The fact that a static /dev keeps these race conditions from showing up
> as often as they really are there is no reason to keep trying to rely on
> old, undefined behaviour :)
[ I'm late to discussion, and do not have much time at all.
Just observation from aside by driver writer and OS builder. ]
You really do not solve problem - problem as I see it - but just move
it around.
When I did first release of device driver for some obscure device, I
used to wait in init script for "touch /dev/whatever" to be Ok. My
device was ok with dumb open()/close() sequence.
What I was really missing - is a way to tell user space that not only
driver loaded Ok, but that device was found, diagnosed and upped Ok.
Diagnostics was taking time - that's why I tryed to do it async. While
device does some inernal spinning, I can load up other drivers.
I haven't found any reasonable solution. module_init() is locking
everything - I cannot load any other module, while one module is
loading. But from user space point of view this is the only way to
return error from device driver.
IOW, mapping my experience to this discussion, we need to have a way
for user space to wait for discover process to end. After all user space
knows better than enyone in kernel what to expect from loaded driver.
We are not talking about hot-plug and preloading of modules. We are
talking more about the case where system cannot go on without requested
device & its device node. We need a way for modprobe to be able to wait
for driver initialization phases (we do not have them - make it sense to
have them?): driver initialization, device discovery, device
initialization, device node ready. So then user space will be able to
wait for driver to reach any of given phases. If init script needs
/dev/sda1 and after all phases completed Ok we failed to locate it - it
can mean only one thing - /dev/sda1 is not here. Since modprobe will
wait - it will mean that we will be able to return error, if any. IMHO
that what need to be implemented. Polling is crappy solution: we do not
need to poll for something we can reliably find out.
We have all info in kernel in drivers - we need a way to give it back
to user space for both play nice with each other.
My 0.02 Euro.
> That will be soon going away with my multi-threaded device discovery
> work. And I run pci hotplug boxes (and so do all of the PCMCIA/CardBus
> users), so don't discard PCI from being a async bus type :)
>
> Async is now the norm, and drivers like the microcode module are the
> exception.
I wanted you to say that.
That's wrong attitude. I'm working on workstation where 95% of
hardware plugged 100% of time. That's not exception. Not eerything is
hot-pluggable USB/FireWire/whatever.
Event-based hot-plug scripts are great thing. As an implementation.
But user cares about one thing: 'modprobe usb-storage; mount /whatever'
working reliably.
/etc/dev.d probably great thing - but I'm not going to implement FSM
into every shell script which does modprobe for sake being Ok with
dynamic /dev/.
You need to change your attitude for first. For second - come up with
a way for user space to block until device is here, and if it is not
here/error detected - fail.
As it was said before - /all/ we need, is to be able to tell
discovery phase from idle state of driver. "/All/" is quite much here -
but it must be a goal.
I'm absolutely sure, that for PCI devices it is implementable quite
easy - probing is already done outside of modules. And we know precisely
are we Ok, or are we not. And we know when we are done. If it is not so
for USB yet - then it is bug which must be fixed.
On Sat, 18 Sep 2004 21:44:03 +0200
Ihar 'Philips' Filipau <[email protected]> wrote:
>
> That's wrong attitude. I'm working on workstation where 95% of
> hardware plugged 100% of time. That's not exception. Not eerything is
> hot-pluggable USB/FireWire/whatever.
Even PCI devices are "attached" to the kernel at bootup. From an
abstracted POV they are plugged in.
>
> Event-based hot-plug scripts are great thing. As an implementation.
> But user cares about one thing: 'modprobe usb-storage; mount /whatever'
> working reliably.
That's actually something the user doesn't want to be bothered with.
modprobe is done automatically when the device is plugged in. Mounting is
done automatically when udev signals the script in dev.d (or your desktop
environment via D-BUS). This is what users care about.
Even uber-geeks don't enjoy unnecessary work.
>
> /etc/dev.d probably great thing - but I'm not going to implement FSM
> into every shell script which does modprobe for sake being Ok with
> dynamic /dev/.
Why not switch completely. Of course, there still is Kernel 2.4, but there
is little reason not to use udev on 2.6. We all know that open source is
about choice, but his may well mean that more work is needed (ie. two
versions of an init script)
>
> You need to change your attitude for first. For second - come up with
>
> a way for user space to block until device is here, and if it is not
> here/error detected - fail.
Already done. All userspace nees to do is wait in /etc/dev.d. The only
issue is error handling, but after some consideration I have to admit,
that this is not different than before.
In a situation where modprobe failed before, it will still do so. In a
situation where modprobe succeeded, but later phases failed (like
partition detection), the situation isn't any worse with udev.
Instead of a non-working device node and an error in dmesg you now get no
device node and an error in dmesg. Checking for such a condition is
equally hard in both cases.
>
> As it was said before - /all/ we need, is to be able to tell
> discovery phase from idle state of driver. "/All/" is quite much here -
> but it must be a goal.
Why? You couln't do so from userspace before, and there is little reason
to do so. Or am I missing something?
>
> I'm absolutely sure, that for PCI devices it is implementable quite
> easy - probing is already done outside of modules. And we know precisely
> are we Ok, or are we not. And we know when we are done.
Not really. modprobe may return sucessfully, but the hardware still might
fail to work - either silently or with error messages in kernel log. All
you really can rely on is that the module has been loaded. Nothin changes
with udev.
Regards
On Sat, Sep 18, 2004 at 09:25:56PM +0200, Ihar 'Philips' Filipau wrote:
> >The fact that a static /dev keeps these race conditions from showing up
> >as often as they really are there is no reason to keep trying to rely on
> >old, undefined behaviour :)
>
> [ I'm late to discussion, and do not have much time at all.
> Just observation from aside by driver writer and OS builder. ]
>
> You really do not solve problem - problem as I see it - but just move
> it around.
No, we solve it with the /etc/dev.d system. How is that not a solution?
> When I did first release of device driver for some obscure device, I
> used to wait in init script for "touch /dev/whatever" to be Ok. My
> device was ok with dumb open()/close() sequence.
>
> What I was really missing - is a way to tell user space that not only
> driver loaded Ok, but that device was found, diagnosed and upped Ok.
> Diagnostics was taking time - that's why I tryed to do it async. While
> device does some inernal spinning, I can load up other drivers.
That's exactly what /etc/dev.d is there for.
> I haven't found any reasonable solution. module_init() is locking
> everything - I cannot load any other module, while one module is
> loading. But from user space point of view this is the only way to
> return error from device driver.
No it isn't. A modprobe error means that the module couldn't load for
some reason. It doesn't mean that a device was not found, or that an
error happened when probing the device. And if you object otherwise,
think about what happens if you have more than 1 device controlled by a
module, how would you report an error that way? :)
> IOW, mapping my experience to this discussion, we need to have a way
> for user space to wait for discover process to end. After all user space
> knows better than enyone in kernel what to expect from loaded driver.
No it doesn't at all. userspace doesn't know that I really have 6
usb-storage devices plugged into my system, and that it needs to "wait"
after I run 'modprobe usb-storage'
However my system _does_ know that if it sees a specific type of
usb-storage device it should name it a specific unique name no matter
where it is plugged into the system, and that it needs to mount that
device at a specific mount point. That's what userspace is supposed to
know about, and do.
> We are not talking about hot-plug and preloading of modules. We are
> talking more about the case where system cannot go on without requested
> device & its device node.
Then just exit, and resume your "system startup" from the /etc/dev.d
notifier. That works properly.
> We need a way for modprobe to be able to wait
> for driver initialization phases (we do not have them - make it sense to
> have them?): driver initialization, device discovery, device
> initialization, device node ready.
Please explain how that will work for a device on a bus that is probed
quite slowly (like USB) when we do not know ahead of time how many
devices there are, and what type of driver will bind to them (think
scsi-generic or scsi-tape or scsi-disk...)
> So then user space will be able to
> wait for driver to reach any of given phases. If init script needs
> /dev/sda1 and after all phases completed Ok we failed to locate it - it
> can mean only one thing - /dev/sda1 is not here. Since modprobe will
> wait - it will mean that we will be able to return error, if any. IMHO
> that what need to be implemented. Polling is crappy solution: we do not
> need to poll for something we can reliably find out.
I agree polling is not the proper way. That's why /etc/dev.d exists.
> We have all info in kernel in drivers - we need a way to give it back
> to user space for both play nice with each other.
What information is in drivers that is not known by userspace?
userspace knows what kind of devices that are supported by all drivers,
and so userspace loads the proper driver when it is told by the kernel a
specific device has shown up. That works just fine and keeps users from
having to figure out what driver is needed for their new device.
thanks,
greg k-h
On Sat, Sep 18, 2004 at 09:44:03PM +0200, Ihar 'Philips' Filipau wrote:
> >That will be soon going away with my multi-threaded device discovery
> >work. And I run pci hotplug boxes (and so do all of the PCMCIA/CardBus
> >users), so don't discard PCI from being a async bus type :)
> >
> >Async is now the norm, and drivers like the microcode module are the
> >exception.
>
> I wanted you to say that.
>
> That's wrong attitude. I'm working on workstation where 95% of
> hardware plugged 100% of time. That's not exception. Not eerything is
> hot-pluggable USB/FireWire/whatever.
Do you have PCI devices? pnp-isa devices? Ok, those all are
"hotpluggable" as far as the kernel is concerned. They are loaded on
demand by userspace when the kernel sees the device.
If not, what kind of devices do you have? The only place the
"on-demand" loading of modules doesn't work is for embedded systems that
have no way of discovering their devices, and need to be hardcoded in
the kernel. But people are working on that :)
> Event-based hot-plug scripts are great thing. As an implementation.
> But user cares about one thing: 'modprobe usb-storage; mount /whatever'
> working reliably.
No, they want to plug in their device and have the proper module
automatically loaded, and then the device mounted and the icon show up
on their desktop all automatically. With hotplug and its helpers (udev,
/etc/dev.d/ and HAL) this all works just fine today.
> /etc/dev.d probably great thing - but I'm not going to implement FSM
> into every shell script which does modprobe for sake being Ok with
> dynamic /dev/.
Fine, I'm not forcing you to do anything you don't want to do. It
sounds like you like polling for your device nodes. Great, live with
that, it is one way to do this :)
> You need to change your attitude for first.
Change it to what? A combative one? Gladly :)
> For second - come up with a way for user space to block until device
> is here, and if it is not here/error detected - fail.
Please explain (with code) how to do that for something as "simple" as
the usb-storage driver. Then we can continue this discussion.
> As it was said before - /all/ we need, is to be able to tell
> discovery phase from idle state of driver. "/All/" is quite much here -
> but it must be a goal.
Wrong. Our goal is to make Linux "just work". And that is what is
happening today. This "wait for modprobe" stuff helps no one.
> I'm absolutely sure, that for PCI devices it is implementable quite
> easy - probing is already done outside of modules. And we know precisely
> are we Ok, or are we not. And we know when we are done. If it is not so
> for USB yet - then it is bug which must be fixed.
PCI and USB both use the same probe core code. So it works the same :)
You think you are grumpy now, just wait till I add threads to the probe
code...
thanks,
greg k-h
Well, I got your point.
I promise I will not use udev ;-)
For last embedded system where I have had external usb storage used
for firmware upgrade, I used preloading of usb-storage - and everything
worked well. Seems it worked better than udev will ever worked - with 0
user space calls and immediate accessibility of /dev/sda ;-)))
I will not try to argue, it is rather pointless for me at moment,
being unemployed and far from any of my systems.
P.S. Funny diversion from OpenBSD thinking. OpenBSD intentionally do not
support loadale modules, to prevent _any_ user space attempt to modify
running kernel.
P.P.S. Another day, I hope, you will understand that right system need
to provide people with two opposite ways of doing things. Sometimes it
is advantage to be event-based and asynchronous, sometimes it is very
convient to be dumb & synchronous. This two options are not mutually
exclusive. I/O subsystem does both ways: you can be dumb and synchronous
with read() (as most applications do - regardless of actual I/O being
event-driven), or asynchronous with aio_* stuff (sacrificing simplicity
of application). Giving a choice is right way to go.
Greg KH wrote:
> On Sat, Sep 18, 2004 at 09:44:03PM +0200, Ihar 'Philips' Filipau wrote:
>
>>>That will be soon going away with my multi-threaded device discovery
>>>work. And I run pci hotplug boxes (and so do all of the PCMCIA/CardBus
>>>users), so don't discard PCI from being a async bus type :)
>>>
>>>Async is now the norm, and drivers like the microcode module are the
>>>exception.
>>
>> I wanted you to say that.
>>
>> That's wrong attitude. I'm working on workstation where 95% of
>>hardware plugged 100% of time. That's not exception. Not eerything is
>>hot-pluggable USB/FireWire/whatever.
>
>
> Do you have PCI devices? pnp-isa devices? Ok, those all are
> "hotpluggable" as far as the kernel is concerned. They are loaded on
> demand by userspace when the kernel sees the device.
>
> If not, what kind of devices do you have? The only place the
> "on-demand" loading of modules doesn't work is for embedded systems that
> have no way of discovering their devices, and need to be hardcoded in
> the kernel. But people are working on that :)
>
>
>> Event-based hot-plug scripts are great thing. As an implementation.
>>But user cares about one thing: 'modprobe usb-storage; mount /whatever'
>>working reliably.
>
>
> No, they want to plug in their device and have the proper module
> automatically loaded, and then the device mounted and the icon show up
> on their desktop all automatically. With hotplug and its helpers (udev,
> /etc/dev.d/ and HAL) this all works just fine today.
>
>
>> /etc/dev.d probably great thing - but I'm not going to implement FSM
>>into every shell script which does modprobe for sake being Ok with
>>dynamic /dev/.
>
>
> Fine, I'm not forcing you to do anything you don't want to do. It
> sounds like you like polling for your device nodes. Great, live with
> that, it is one way to do this :)
>
>
>> You need to change your attitude for first.
>
>
> Change it to what? A combative one? Gladly :)
>
>
>>For second - come up with a way for user space to block until device
>>is here, and if it is not here/error detected - fail.
>
>
> Please explain (with code) how to do that for something as "simple" as
> the usb-storage driver. Then we can continue this discussion.
>
>
>> As it was said before - /all/ we need, is to be able to tell
>>discovery phase from idle state of driver. "/All/" is quite much here -
>>but it must be a goal.
>
>
> Wrong. Our goal is to make Linux "just work". And that is what is
> happening today. This "wait for modprobe" stuff helps no one.
>
>
>> I'm absolutely sure, that for PCI devices it is implementable quite
>>easy - probing is already done outside of modules. And we know precisely
>>are we Ok, or are we not. And we know when we are done. If it is not so
>>for USB yet - then it is bug which must be fixed.
>
>
> PCI and USB both use the same probe core code. So it works the same :)
>
> You think you are grumpy now, just wait till I add threads to the probe
> code...
>
If you are not yet threaded - so that must be done.
On Sun, Sep 19, 2004 at 02:06:32AM +0200, Ihar 'Philips' Filipau wrote:
>
> Well, I got your point.
> I promise I will not use udev ;-)
Heh.
> For last embedded system where I have had external usb storage used
> for firmware upgrade, I used preloading of usb-storage - and everything
> worked well. Seems it worked better than udev will ever worked - with 0
> user space calls and immediate accessibility of /dev/sda ;-)))
Great, that works for you. But what about when you have a slow usb hub
that the device is plugged into. It will take a while for the USB core
to recognize that device and set everything up properly (and who's to
say it will be called /dev/sda anyway?).
> P.P.S. Another day, I hope, you will understand that right system need
> to provide people with two opposite ways of doing things. Sometimes it
> is advantage to be event-based and asynchronous, sometimes it is very
> convient to be dumb & synchronous.
My point is we _can not_ be dumb and synchronous in this situation. It
just will not work with busses that have devices that can come and go as
the system is running. It is pretty much impossible to correctly do
what you are proposing. Just think about the different situations that
we have to handle properly.
thanks,
greg k-h
> You need to change your attitude for first. For second - come up with
> a way for user space to block until device is here, and if it is not
> here/error detected - fail.
>
> As it was said before - /all/ we need, is to be able to tell
> discovery phase from idle state of driver. "/All/" is quite much here -
> but it must be a goal.
>
> I'm absolutely sure, that for PCI devices it is implementable quite
> easy - probing is already done outside of modules. And we know precisely
> are we Ok, or are we not. And we know when we are done. If it is not so
> for USB yet - then it is bug which must be fixed.
Nope, Greg is right. Drivers themselves won't necessarily provide
you with the device interface in a synchronous way after they are
loaded, and some will certainly never. It is all an asynchronous process
and there is simply no way to ask for any kind of enforced synchronicity
here without major bloatage.
Ben.
Greg KH wrote:
>
>>P.P.S. Another day, I hope, you will understand that right system need
>>to provide people with two opposite ways of doing things. Sometimes it
>>is advantage to be event-based and asynchronous, sometimes it is very
>>convient to be dumb & synchronous.
>
> My point is we _can not_ be dumb and synchronous in this situation. It
> just will not work with busses that have devices that can come and go as
> the system is running. It is pretty much impossible to correctly do
> what you are proposing. Just think about the different situations that
> we have to handle properly.
>
Example? Your "we can not" sounds like "we not capable enough to
implement."
I thought that discovery deterministic process. What I'm missing?
For now, You haven't gave any example besides "slow USB hub" - but
this is rather example which supports me: you are not going to put
/variable/ delays into init scripts? aren't you?
Here we definitely need to hide asynchronousity of process -
handling this volatility in user space will never work reliably.
P.S. You do not need to reply, it seems like case of init scripts is not
interesting for you. What is for me about 90% of work I usually do
preparing new system. Number-wise, most of devices attached to system,
initialized by init scripts - and you just dumbly avoid answering that.
You have to modprobe/insmod harddrive & filesystem to be able run your
udev, after all. Think about it. And people have had problems with
discovery - one of the patches for usb-storage root fs is adding a delay
and retries for root fs mounting. Moving problem around is easier than
solving it, that's true.
Benjamin Herrenschmidt wrote:
>
> Nope, Greg is right. Drivers themselves won't necessarily provide
> you with the device interface in a synchronous way after they are
> loaded, and some will certainly never. It is all an asynchronous process
> and there is simply no way to ask for any kind of enforced synchronicity
> here without major bloatage.
>
Okay, okay. Let's spread delays and polling all over numerous init
scripts.
You might be ten thousands time right. It is asynchronous process.
But please listen to me: you are not going to handle that in _every_
system application which deals with modules.
If there is problem, it doesn't mean we just pass it over. Probably
we need to solve it?
Ihar 'Philips' Filipau wrote:
> Benjamin Herrenschmidt wrote:
>
>>
>> Nope, Greg is right. Drivers themselves won't necessarily provide
>> you with the device interface in a synchronous way after they are
>> loaded, and some will certainly never. It is all an asynchronous process
>> and there is simply no way to ask for any kind of enforced synchronicity
>> here without major bloatage.
>>
>
> Okay, okay. Let's spread delays and polling all over numerous init
> scripts.
I read it as "Let's bloat initscripts instead of the kernel". We
probably have to bloat something, but we don't want to bloat our
favourite kernel.
Maybe we should create a bash file with functions that implement it "the
right way" and distribute this file with udev as an example?
> You might be ten thousands time right. It is asynchronous process.
>
> But please listen to me: you are not going to handle that in _every_
> system application which deals with modules.
We should probably avoid code duplication and put this functionality
into a library (maybe even glibc?)
What we currently see is that distros either ignore the race or (like
LFS) say something like:
"Because of all those compilcations with Hotplug, Udev and modules, we
strongly recommend you to start with a completely non-modular kernel
configuration, especially if this is the first time you use Udev."
--
Alexander E. Patrakov
On Sun, 19 Sep 2004 10:27:34 +0200
Ihar 'Philips' Filipau <[email protected]> wrote:
> Okay, okay. Let's spread delays and polling all over numerous init
> scripts.
Just use /etc/dev.d. No delays, no polling. Everything is event based.
>
> You might be ten thousands time right. It is asynchronous process.
>
> But please listen to me: you are not going to handle that in _every_
> system application which deals with modules.
It would not be necessary if the module provides some pseudo-device
without device nodes and loading will *always* succeed.
If this is not the case (ie. always), your script is even unsuitable for a
static /dev.
(I know that many scripts make that assumption, including my own.
Nevertheless it is wrong, and has always been wrong.)
>
> If there is problem, it doesn't mean we just pass it over. Probably
> we need to solve it?
How do you want to solve it? We cannot look into the future, so how should
we know which device nodes "modprobe xyz" will or should create?
dev.d is a nice solution. If any device node is created, your script is
called. If it is the node you want, you perform your actions.
Regards
Marc Ballarin wrote:
>
>> If there is problem, it doesn't mean we just pass it over. Probably
>>we need to solve it?
>
> How do you want to solve it? We cannot look into the future, so how should
> we know which device nodes "modprobe xyz" will or should create?
> dev.d is a nice solution. If any device node is created, your script is
> called. If it is the node you want, you perform your actions.
>
Well, can then anyone explain by which mean (black magic?) kernel
mounts root file system? block device might appear any time, file system
might take ages to load.
Hu? How is init/do_mounts.c still works then? Or it is needs to be
fixed with messages a-la "root file system will be available shortly, we
do hope" and "please plug in again your hard-wired IDE drive"?
People, you must learn doing abstractions carefully. If device is
hard-wired - user *will* expect (as kernel itself does) that it is
available all the time after modprobe'ing driver.
On Sun, 19 Sep 2004 16:25:51 +0200
Ihar 'Philips' Filipau <[email protected]> wrote:
>
> Well, can then anyone explain by which mean (black magic?) kernel
> mounts root file system? block device might appear any time, file system
> might take ages to load.
The kernel doesn't use /dev.
Why do you think mounting the root device is such a "frail" process?
The kernel blindly ties all known filesystem on the specified device.
If the user specifies a wrong root device, or the device is broken or the
filesystem corrupted or unknown the kernel will panic.
The reason this is so is, that nothing else can be done. Userspace,
however, has more possibilities.
>
> People, you must learn doing abstractions carefully. If device is
> hard-wired - user *will* expect (as kernel itself does) that it is
> available all the time after modprobe'ing driver.
It is available as long as the device node is present. udev tells you (in
dev.d) when this is the case. If the device is hardwired (from a user's
point of view) the device node will be created early dring boot-up. If
this happens, udev will notify the scripts in dev.d.
Instead of:
modprobe ide-cd && mount /dev/hdc /mnt/cdrom
in /etc/init.d/your-script
you would now do:
if [ ACTION="add" ] && [ DEVNAME="/dev/hdc" ]; then
mount /dev/hdc /mnt/cdrom
fi
in /etc/dev.d/default/your-script.dev
This is even more reliable than the first solution on a static /dev,
since loading the driver might fail at any point *after* modprobe
returns.
For example, modprobe ide-cd will succeed even when no CD-ROMs are
present. The old script would break in this case, the new one wouldn't be
called at all.
Error reporting is very difficult. How should the kernel know what the
driver is supposed to do?
Obvious errors likes Oopses or I/O errors *could* be reported by hotplug.
(ACTION="error", DEVNAME="module-name" ???)
Anything else is impossible.
You just have to adopt your approach to device handling. Currently you
*assume* that after a succesfull modprobe the device nodes are available
(this was never true, however).
With hotplug/udev you *know* that the device node is available when your
script in dev.d is called with the appropriate environment variables.
Regards
Marc Ballarin wrote:
> On Sun, 19 Sep 2004 16:25:51 +0200
> Ihar 'Philips' Filipau <[email protected]> wrote:
>
>
>> Well, can then anyone explain by which mean (black magic?) kernel
>>mounts root file system? block device might appear any time, file system
>>might take ages to load.
>
>
> The kernel doesn't use /dev.
It creates a temporary device node in its rootfs. It does so by looking
into sysfs for major and minor numbers. So the question is whether the
information is in sysfs at the moment when the kernel requests it.
> Why do you think mounting the root device is such a "frail" process?
Because of your own words below that "loading the driver might fail at
any point *after* modprobe returns" (read: after module_init() finishes).
> The kernel blindly ties all known filesystem on the specified device.
yes, if it exists
> If the user specifies a wrong root device, or the device is broken or the
> filesystem corrupted or unknown the kernel will panic.
> The reason this is so is, that nothing else can be done. Userspace,
> however, has more possibilities.
OK. The fact is that, when mounting the root filesystem, the kernel can
(?) definitely say "there is no such device, and it's useless to wait
for it--so I panic". Is it possible to duplicate this logic in the case
with udev and modprobe? If so, it should be built into a common place
(either the kernel or into modprobe), but not into all apps.
> Instead of:
> modprobe ide-cd && mount /dev/hdc /mnt/cdrom
> in /etc/init.d/your-script
>
> you would now do:
> if [ ACTION="add" ] && [ DEVNAME="/dev/hdc" ]; then
> mount /dev/hdc /mnt/cdrom
> fi
> in /etc/dev.d/default/your-script.dev
>
> This is even more reliable than the first solution on a static /dev,
> since loading the driver might fail at any point *after* modprobe
> returns.
> For example, modprobe ide-cd will succeed even when no CD-ROMs are
> present. The old script would break in this case, the new one wouldn't be
> called at all.
<snip>
> You just have to adopt your approach to device handling. Currently you
> *assume* that after a succesfull modprobe the device nodes are available
> (this was never true, however).
Then the "char-major" aliases were always broken, do I understand
correctly? Once we realize that, isn't it the time to mark the
"Automatic kernel module loading" in the kernel configuration as BROKEN
or OBSOLETE?
> With hotplug/udev you *know* that the device node is available when your
> script in dev.d is called with the appropriate environment variables.
Yes. Now we have a lot of short scriptlets under /etc/dev.d. But I don't
yet see how these scriptlets interact with each other.
--
Alexander E. Patrakov
On Wed, 15 Sep 2004 11:00:57 -0700, Greg KH <[email protected]> wrote:
> On Wed, Sep 15, 2004 at 06:51:16PM +0200, Marc Ballarin wrote:
> > This sound complicated and requires changes in many places. Maybe there is
> > an easier solution.
> There is, just run your stuff off of /etc/dev.d/ and stop relying on a
> device node to be present after modprobe returns.
Indeed.
I don't see what is so far for distributions to overcome here - if you
want to avoid having two sets of alternative init scripts, why not
have a generic set of /etc/dev.d entries that are either called by
udev or if udev is not available run them in some predetermined order
on a static device tree. What's the hassle here? I can't see anything
world shattering.
Cheers,
Jon.
On Sun, 19 Sep 2004 22:00:52 +0600
"Alexander E. Patrakov" <[email protected]> wrote:
>
> OK. The fact is that, when mounting the root filesystem, the kernel can
> (?) definitely say "there is no such device, and it's useless to wait
> for it--so I panic". Is it possible to duplicate this logic in the case
> with udev and modprobe? If so, it should be built into a common place
> (either the kernel or into modprobe), but not into all apps.
Well, once the system is running, the device might appear any time, so
waiting is hardly useless then.
In the past you did modprobe and afterwards tried to access the device. If
this succeeded, the device was created successfully, if not, something
went wrong, and your script returned an error code.
This approach has some problems.
The device is plugged in later on: "su" to root, re-run script. Not nice.
The script doesn't check properly for later errors: something breaks.
Now, the device is either autodetected or - when this is not possible
("legacy" devices) you have to modprobe manually.
If this succeeds, you are informed in dev.d. If it fails you are
"informed" by not being called in dev.d.
If I understand correctly, you wish do modprobe for a legacy device and
then know if this succeeded completely.
Simply choose a state-file in /var and write something like "not detected"
inside. Then do modprobe.
The other part of your script will wait in dev.d for the event. If it
arrives, the script will change the state file to "found" and do its work.
So, as long as the state is "not detected" you treat the device as not
present - just as if your old, synchronous script had returned an error
code. The advantage is, that if the device appears later on everything
will work automatically.
>
> Then the "char-major" aliases were always broken, do I understand
> correctly? Once we realize that, isn't it the time to mark the
> "Automatic kernel module loading" in the kernel configuration as BROKEN
> or OBSOLETE?
IIRC this feature is intended primarily for loadable kernel features and
pseudo devices, not "real" device drivers.
>
> Yes. Now we have a lot of short scriptlets under /etc/dev.d. But I don't
> yet see how these scriptlets interact with each other.
You could use some state file if hotplug messages aren't enough, as
described above.
mfg
On Sun, Sep 19, 2004 at 10:00:52PM +0600, Alexander E. Patrakov wrote:
>
> OK. The fact is that, when mounting the root filesystem, the kernel can
> (?) definitely say "there is no such device, and it's useless to wait
> for it--so I panic". Is it possible to duplicate this logic in the case
> with udev and modprobe? If so, it should be built into a common place
> (either the kernel or into modprobe), but not into all apps.
No, we need to just change the kernel to sit and spin for a while if the
root partition is not found. This is the main problem right now for
booting off of a USB device (or any other "slow" to discover device.)
It's a known kernel issue, and there are patches for 2.4 for this, but
no one has taken the time to update them for 2.6.
> Then the "char-major" aliases were always broken, do I understand
> correctly?
Yes, for most drivers they are broken. Like sound, usb, and others.
> Once we realize that, isn't it the time to mark the
> "Automatic kernel module loading" in the kernel configuration as BROKEN
> or OBSOLETE?
Fine with me, I've been wanting to do that for years. Are you willing
to handle the fallout of such a patch though? :)
> >With hotplug/udev you *know* that the device node is available when your
> >script in dev.d is called with the appropriate environment variables.
>
> Yes. Now we have a lot of short scriptlets under /etc/dev.d. But I don't
> yet see how these scriptlets interact with each other.
What do you mean? What kind of relationship do you need explained about
them?
thanks,
greg k-h
On Sun, Sep 19, 2004 at 05:53:05PM +0600, Alexander E. Patrakov wrote:
>
> What we currently see is that distros either ignore the race or (like
> LFS) say something like:
I don't see distros ignoring the race issues. Look at Gentoo's init
scripts, it handles this properly (if not, please let me know.)
> "Because of all those compilcations with Hotplug, Udev and modules, we
> strongly recommend you to start with a completely non-modular kernel
> configuration, especially if this is the first time you use Udev."
Heh, no, you'll have the same "issues" with a static kernel and no
modules. Your devices will not get found any faster :)
thanks,
greg k-h
Hi,
I am fascinated about udev and others, but have some questions.
On Sun, 19 Sep 2004, Greg KH wrote:
> On Sun, Sep 19, 2004 at 05:53:05PM +0600, Alexander E. Patrakov wrote:
>>
>> What we currently see is that distros either ignore the race or (like
>> LFS) say something like:
>
> I don't see distros ignoring the race issues. Look at Gentoo's init
> scripts, it handles this properly (if not, please let me know.)
I have Gentoo with udev (with 100% modular kernel). And I have speedtouch
USB ADSL modem. I am using paralell startup scripts feature. And
speedtouch tries to initialize itself (load firmware and so on) before USB
bus (or how to call it) is discovered. I can imagine moving firmware
loader to udev.d scripts but where should I place pppd launching (for
example I might have pppd or ifconfig binary on nfs mounted /usr from
my LAN...).
I understand that for messages like "xxx was just plugged in" there is
(masked) HAL and DBUS. But don't we need something where we can check if
particular part of the system (not only device but also removable media or
filesystem mount or some daemon) was initialized (or is currently plugged
and initialized) or not? And we should be able to locate device file or
mount point or controll socket of this part of the system... And don't
we need some multi-event script launcher: "Launch this when xxx was
plugged and initialized but not before yyy was initialized"? Gentoo has
dependency-based startup scripts but dependiencies are resolved statically
not dynamically... There should be also some inteligent way to
shut down device _and_ all things that depend on it when device is
unplugged and then reinitialize _everything_ when device is plugged
back... Not only device itself as it is in udev.d. Script in udev.d should
not know about services that depend on this device and services that
depend on these services...
And how udev, hotlpug and the rest of the system should hadle SATA disk
unpluggged in the middle of writing? And what if it will be plugged back?
Thanks,
Grzegorz Kulewski
On Wed, 15 Sep 2004 18:17:02 +0000, Greg KH wrote:
> There is, just run your stuff off of /etc/dev.d/ and stop relying on a
> device node to be present after modprobe returns.
But installation scripts will need to sleep/loop after fdisk,
till the devices are created, right?
And I'm currently mknod'ing /dev/md* devices before creating
the kernel structures with mkraid (which needs the device inode).
Is there any other way to do this?
sure, in the long run designs like dm with a special control
device are a better than this hack for md.
Also I wonder how dm works: will dmsetup create the /dev inode
itself, or use udev to do that? would I need the sleep/loop
in a script creating device mappings to wait for the inode?
Regards, Andreas
Marc Ballarin wrote:
> On Sun, 19 Sep 2004 16:25:51 +0200
> Ihar 'Philips' Filipau <[email protected]> wrote:
>
>
>> Well, can then anyone explain by which mean (black magic?) kernel
>>mounts root file system? block device might appear any time, file system
>>might take ages to load.
>
>
> The kernel doesn't use /dev.
True. But udev together with new loadable modules model was
advertised as a /right/ replacement for devfs,
> Why do you think mounting the root device is such a "frail" process?
> The kernel blindly ties all known filesystem on the specified device.
> If the user specifies a wrong root device, or the device is broken or the
> filesystem corrupted or unknown the kernel will panic.
> The reason this is so is, that nothing else can be done. Userspace,
> however, has more possibilities.
>
You are right - kernel doesn't know.
It is driver knows, It is user of driver who does know it too.
>
>> People, you must learn doing abstractions carefully. If device is
>>hard-wired - user *will* expect (as kernel itself does) that it is
>>available all the time after modprobe'ing driver.
>
>
> It is available as long as the device node is present. udev tells you (in
> dev.d) when this is the case. If the device is hardwired (from a user's
> point of view) the device node will be created early dring boot-up. If
> this happens, udev will notify the scripts in dev.d.
>
> Instead of:
> modprobe ide-cd && mount /dev/hdc /mnt/cdrom
> in /etc/init.d/your-script
>
> you would now do:
> if [ ACTION="add" ] && [ DEVNAME="/dev/hdc" ]; then
> mount /dev/hdc /mnt/cdrom
> fi
> in /etc/dev.d/default/your-script.dev
Well, go to /etc/rc.d and try to integrate that with rest of system.
The only right way of handling of such stuff I know - is FSM.
Implementing FSMs in shell scripts - last thing I ever wanted. And I
still cannot get how you are going to safely serialize /etc/dev.d/
callbacks against /etc/rc.d/ without polling.
>
> This is even more reliable than the first solution on a static /dev,
> since loading the driver might fail at any point *after* modprobe
> returns.
Untrue. Driver if something fails have a chance to return error from
module_init() function, which will be passed to modprobe and then to callee.
> For example, modprobe ide-cd will succeed even when no CD-ROMs are
> present. The old script would break in this case, the new one wouldn't be
> called at all.
>
You are wrong. Hardware driver must fail, when hardware is not
present/not detected. Simple as that.
If ide-cd doesn't do that - it needs to be fixed.
> Error reporting is very difficult. How should the kernel know what the
> driver is supposed to do?
Yes. Driver is not loaded without need. Kernel doesn't need driver -
user need it to accomplish specific task.
User knows what driver is meant for, especially when it loads it
manually.
If user will be told when driver is ready - user can verify that
hardware in question is present.
> Obvious errors likes Oopses or I/O errors *could* be reported by hotplug.
> (ACTION="error", DEVNAME="module-name" ???)
> Anything else is impossible.
>
> You just have to adopt your approach to device handling. Currently you
> *assume* that after a succesfull modprobe the device nodes are available
> (this was never true, however).
> With hotplug/udev you *know* that the device node is available when your
> script in dev.d is called with the appropriate environment variables.
>
What about scripts outside of /etc/dev.d/?
If you ever mantained /etc/rc.d/rc - you will understand what I mean.
Splitting system boot-up procedure will have some funny consequences.
Debugging will be left as an execise for end-users. Running once fsck
simultaneously on several partitions will cool your temper down.
Again. FSM is no way to go for shell scripts. And shell scripts is
what is used to manage system. Even /etc/dev.d/ scripts - are shell
scripts, after all.
P.S. If you will add errors to /etc/dev.d/ scripts - than you will
really end up with FSMs in shell scripts. You are welcome to try. I did
once and failed.
P.P.S. Well, I will stop trolling. Honestly. Promise.
On Mon, 2004-09-20 at 00:25, Ihar 'Philips' Filipau wrote:
> Well, can then anyone explain by which mean (black magic?) kernel
> mounts root file system? block device might appear any time, file system
> might take ages to load.
>
> Hu? How is init/do_mounts.c still works then? Or it is needs to be
> fixed with messages a-la "root file system will be available shortly, we
> do hope" and "please plug in again your hard-wired IDE drive"?
Mounting of the root device is a fragile process that happens to work
by chance on current setups, but there is a reason while distributions
are now moving to a model where an initrd/initramfs is loaded as the
root device first, which then can do the proper selection of a real
root device, eventually waiting for one to show up, and then pivot to
it. The kernel "built-in" root selection already fails most of the
time with usb-storage or sbp2 (ieee1394)
> People, you must learn doing abstractions carefully. If device is
> hard-wired - user *will* expect (as kernel itself does) that it is
> available all the time after modprobe'ing driver.
Arrogance will lead you nowhere here, so step down from your pedestal
and try accepting that your view on things might not be the right one.
Ben.
On Sep 19, 2004, at 15:40, Ihar 'Philips' Filipau wrote:
> You are wrong. Hardware driver must fail, when hardware is not
> present/not detected. Simple as that.
> If ide-cd doesn't do that - it needs to be fixed.
I have a USB CD burner, and during startup I make sure that the USB
and SCSI modules are already loaded to speed up the CD recognition.
With your procedure I _can't_ do that. First I try to modprobe the USB
stuff, which works. Then I try to modprobe the SCSI stuff, which
doesn't,
because the burner isn't plugged in yet and it sees no SCSI devices.
How does that make sense? Hardware is not serialized nicely the
way you seem to want it to be. I expect to be able to plug in my 2 USB
disks, my USB burner, and my USB scanner into the USB hub that I
just plugged in, either before turning on the computer, halfway through
startup, or after I've been working for 2 hours and not have the whole
damn mess fail because one of the devices is _only_ initialized in the
init scripts. The best way to handle this is /etc/dev.d. If some
system
is critical for startup, then just add a "touch
/var/run/criticalsystem" to
the specialized dev.d script and then have the init script poll for said
file to become more recent than system startup. It's not like polling
will hurt you in that case, if the device really is system-critical
then you
can't do anything _but_ poll and hope that the hardware isn't fubared.
Cheers,
Kyle Moffett
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a17 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r
!y?(-)
------END GEEK CODE BLOCK------
Andreas Jellinghaus wrote:
> Also I wonder how dm works: will dmsetup create the /dev inode
> itself, or use udev to do that? would I need the sleep/loop
> in a script creating device mappings to wait for the inode?
You can safely tell udev to ignore dm devices, if you use LVM or EVMS.
It almost always creates them under the wrong directory and with wrong
name anyway. Correcting this means just duplicating LVM/EVMS
configuration in udev rules. Better leave this task of dm node creation
to dmsetup and related tools.
--
Alexander E. Patrakov
Greg KH wrote:
> On Sun, Sep 19, 2004 at 10:00:52PM +0600, Alexander E. Patrakov wrote:
>
>>OK. The fact is that, when mounting the root filesystem, the kernel can
>>(?) definitely say "there is no such device, and it's useless to wait
>>for it--so I panic". Is it possible to duplicate this logic in the case
>>with udev and modprobe? If so, it should be built into a common place
>>(either the kernel or into modprobe), but not into all apps.
>
>
> No, we need to just change the kernel to sit and spin for a while if the
> root partition is not found. This is the main problem right now for
> booting off of a USB device (or any other "slow" to discover device.)
> It's a known kernel issue, and there are patches for 2.4 for this, but
> no one has taken the time to update them for 2.6.
>
>
>>Then the "char-major" aliases were always broken, do I understand
>>correctly?
>
>
> Yes, for most drivers they are broken. Like sound, usb, and others.
>
>
>>Once we realize that, isn't it the time to mark the
>>"Automatic kernel module loading" in the kernel configuration as BROKEN
>>or OBSOLETE?
>
>
> Fine with me, I've been wanting to do that for years. Are you willing
> to handle the fallout of such a patch though? :)
Many thanks for detailed explanation. And, since char-major aliases
don't work with udev anyway, and net-pf aliases are easy to enumerate
and preload by parsing /lib/modules/`uname -r`/modules.alias, I think
that udev users are ready to handle the fallout of this patch.
>>>With hotplug/udev you *know* that the device node is available when your
>>>script in dev.d is called with the appropriate environment variables.
>>
>>Yes. Now we have a lot of short scriptlets under /etc/dev.d. But I don't
>>yet see how these scriptlets interact with each other.
>
>
> What do you mean? What kind of relationship do you need explained about
> them?
Implementation of various logical primitives. E.g., I use GPRS and want
to start pppd during the boot process (i.e., an always-on link), but
after the following things:
1) /dev/ttyS0 has been created
2) /dev/ppp has been created
3) modules for line disciplines and PPP compression have been preloaded
(e.g. by grepping modules.alias for tty-ldisc and ppp-compress) and are
ready for use by pppd
4) firewall rules have been applied
How to "AND" these things together in a /etc/dev.d scriptlet?
--
Alexander E. Patrakov
On Sun, Sep 19, 2004 at 10:18:21AM +0200, Ihar 'Philips' Filipau wrote:
> Greg KH wrote:
> >
> >>P.P.S. Another day, I hope, you will understand that right system need
> >>to provide people with two opposite ways of doing things. Sometimes it
> >>is advantage to be event-based and asynchronous, sometimes it is very
> >>convient to be dumb & synchronous.
> >
> >My point is we _can not_ be dumb and synchronous in this situation. It
> >just will not work with busses that have devices that can come and go as
> >the system is running. It is pretty much impossible to correctly do
> >what you are proposing. Just think about the different situations that
> >we have to handle properly.
> >
>
> Example? Your "we can not" sounds like "we not capable enough to
> implement."
Ok, you've found me out. I'm too dumb to solve this problem, sorry.
So please send me your patch to implement this and we will take it from
there.
> I thought that discovery deterministic process. What I'm missing?
Hahaha, no way is it "deterministic"...
> For now, You haven't gave any example besides "slow USB hub" - but
> this is rather example which supports me: you are not going to put
> /variable/ delays into init scripts? aren't you?
Not at all. Again, for the last time, use /etc/dev.d to handle such
issues. That will work if the device is found during system init time
(when the init scripts are running) or later when the system has been
running for 42 days and a new device is plugged in.
> Here we definitely need to hide asynchronousity of process -
> handling this volatility in user space will never work reliably.
>
> P.S. You do not need to reply, it seems like case of init scripts is not
> interesting for you.
It is very interesting for me. Hence my /sbin/hotplug and udev and
/etc/dev.d development effort to solve real problems that users have
reported needing solved.
> What is for me about 90% of work I usually do
> preparing new system. Number-wise, most of devices attached to system,
> initialized by init scripts - and you just dumbly avoid answering that.
I must be missing some work that I need to do to my systems when I
prepare a new one. For some reason I don't spend any time, other than
deciding on where to mount a specific device that might possibly be
plugged in some time in the future.
> You have to modprobe/insmod harddrive & filesystem to be able run your
> udev, after all.
Sure, that's what initramfs/initrd is for. See the Gentoo and SuSE boot
processes for examples of how to add udev and modprobe together to get a
working system for a huge range of different platforms.
> Think about it. And people have had problems with discovery - one of
> the patches for usb-storage root fs is adding a delay and retries for
> root fs mounting. Moving problem around is easier than solving it,
> that's true.
Yes, the usb-storage root issue is a problem. Delaying for it is one
simple solution, I don't really have another one at the moment as I
haven't spent any time trying to get it to work (much to some people's
grumblings at me, but I don't have a box with a BIOS that can boot from
a USB device...)
After root is mounted is the real issue, which /etc/dev.d solves.
Good luck,
greg k-h
On Sun, Sep 19, 2004 at 09:40:09PM +0200, Ihar 'Philips' Filipau wrote:
> >For example, modprobe ide-cd will succeed even when no CD-ROMs are
> >present. The old script would break in this case, the new one wouldn't be
> >called at all.
> >
>
> You are wrong. Hardware driver must fail, when hardware is not
> present/not detected. Simple as that.
I'm sorry, but this is not how Linux device drivers work. It's been
this way for over 4 years, and hopefully we have fixed up almost all
drivers to be able to be loaded even if the hardware they are using
isn't currently present. Do you know of any we have missed?
thanks,
greg k-h
On Sun, Sep 19, 2004 at 08:43:50PM +0200, Grzegorz Kulewski wrote:
> I have Gentoo with udev (with 100% modular kernel). And I have speedtouch
> USB ADSL modem. I am using paralell startup scripts feature. And
> speedtouch tries to initialize itself (load firmware and so on) before USB
> bus (or how to call it) is discovered.
That's not good.
> I can imagine moving firmware loader to udev.d scripts but where
> should I place pppd launching (for example I might have pppd or
> ifconfig binary on nfs mounted /usr from my LAN...).
The firmware downloader should be in the usb hotplug agent notifier
location. See the linux-hotplug documentation for how to do this
properly (I thought the speedtouch driver package already did this
properly for some reason...)
Use the network scripts to start up the connection when it is seen by
the system. Gentoo currently does this already today.
> And how udev, hotlpug and the rest of the system should hadle SATA disk
> unpluggged in the middle of writing? And what if it will be plugged back?
udev will delete the device node. As for your data the user is screwed
as they did something very stupid :)
Plug the device back in, and it gets discovered, device node gets
created, and then mounted. That is if your SATA kernel driver supports
hotpluggable disks.
thanks,
greg k-h
On Sun, 19 Sep 2004 21:40:09 +0200
Ihar 'Philips' Filipau <[email protected]> wrote:
>
> Well, go to /etc/rc.d and try to integrate that with rest of system.
> The only right way of handling of such stuff I know - is FSM.
Yes. But this is just the nature of this problem. For reliable operation
and proper error reporting some state tracking is required even today.
> Implementing FSMs in shell scripts - last thing I ever wanted.
In most cases it should boil down to something like
while exists(lockfile)
sleep
> And I
> still cannot get how you are going to safely serialize /etc/dev.d/
> callbacks against /etc/rc.d/ without polling.
Spinlocking with lock-files could work.
> You are wrong. Hardware driver must fail, when hardware is not
> present/not detected. Simple as that.
Why?
> User knows what driver is meant for, especially when it loads it
> manually.
> If user will be told when driver is ready - user can verify that
> hardware in question is present.
This isn't even necessary. If the driver triggers a hotplug event an an
apropriate script is in dev.d everything will work automatically.
If it doesn't the user can check why.
> What about scripts outside of /etc/dev.d/?
>
They will have to spin on a lock file. See below.
>
> Splitting system boot-up procedure will have some funny consequences.
> Debugging will be left as an execise for end-users. Running once fsck
> simultaneously on several partitions will cool your temper down.
This is quite easy to solve in dev.d (Python-like pseudo-code):
if not(ACTION==add)
exit
parse(fstab)
if not(DEVNAME in fstab)
exit
if has_parents(mountpoint)
while not(parents in mtab)
if has_failed?(parents)
has_failed!(DEVNAME)
exit
sleep
while is_locked(parent(DEVNAME))
sleep
lock(parent(DEVNAME))
fsck DEVNAME
mount DEVNAME || has_failed!(DEVNAME)
unlock(parent(DEVNAME))
Most likely I missed some fine points, but this way fsck and mounts are
serialized when necessary and parallelized when possible (even across
different fsck binaries). Dependencies in the filesystem hierarchy are
satisfied and errors can be detected.
lock/unlock/has_failed! are simply "touch" and "rm -f"
is_locked and has_failed? are simply "test -e".
has_parents and parents are derived from fstab.
Of course, the init system needs some "cleverness". If /usr or /var are on
separate devices later scripts need to poll mtab and do "has_failed?"
checks. This is even needed today with a static /dev (but is not done). As a
result current scripts break in undeterministic ways if mounting fails.
>
> Again. FSM is no way to go for shell scripts. And shell scripts is
> what is used to manage system. Even /etc/dev.d/ scripts - are shell
> scripts, after all.
Well, if bash proves too cumbersome there is still spython...
Regards
On Sun, 19 Sep 2004 21:11:02 -0700, Greg KH <[email protected]> wrote:
> On Sun, Sep 19, 2004 at 08:43:50PM +0200, Grzegorz Kulewski wrote:
> > I can imagine moving firmware loader to udev.d scripts but where
> > should I place pppd launching (for example I might have pppd or
> > ifconfig binary on nfs mounted /usr from my LAN...).
> The firmware downloader should be in the usb hotplug agent notifier
> location. See the linux-hotplug documentation for how to do this
> properly (I thought the speedtouch driver package already did this
> properly for some reason...)
I set this up on a Debian box quite a while ago, before the packaged
stuff, but it's trivial to implement this in the hotplug scripts and
works fine - simply do a "pppd call adsl" after you've had the
firmware loader squirt down the firmware. The issue here is "what if I
have a weird setup where at init time the device is found but the
firmware loader or pppd are not available then" - well in that case
I'd argue that the system is broken because you can't expect something
to be available at init if you don't help it to be so.
Sticking pppd on an NFS volume in the original example is overly
contrived and unlikely - it'd be like me sticking fsck on an unmounted
NFS volume and expecting to be able to write some reasonbly generic
and portable initscripts. Let's have cool stuff like udev - but let's
also have some limits with potential startup headaches by having some
utilities fixed.
Cheers,
Jon.
> Use the network scripts to start up the connection when it is seen by
> the system. Gentoo currently does this already today.
>
> > And how udev, hotlpug and the rest of the system should hadle SATA disk
> > unpluggged in the middle of writing? And what if it will be plugged back?
>
> udev will delete the device node. As for your data the user is screwed
> as they did something very stupid :)
>
> Plug the device back in, and it gets discovered, device node gets
> created, and then mounted. That is if your SATA kernel driver supports
> hotpluggable disks.
>
> thanks,
>
> greg k-h
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Alexander E. Patrakov wrote:
>
> Implementation of various logical primitives. E.g., I use GPRS and want
> to start pppd during the boot process (i.e., an always-on link), but
> after the following things:
>
> 1) /dev/ttyS0 has been created
> 2) /dev/ppp has been created
> 3) modules for line disciplines and PPP compression have been preloaded
> (e.g. by grepping modules.alias for tty-ldisc and ppp-compress) and are
> ready for use by pppd
> 4) firewall rules have been applied
>
> How to "AND" these things together in a /etc/dev.d scriptlet?
and
5) /tmp is read-write
6) /var is mounted
7) log daemon is already running
but I think they can implemented with a waiting queue or other
user-space implementation.
Hmm wait, we will miss the event between udev loaded and
/var mounted and dev.d started!
ciao
cate
PS: I hope this discussion will start project of re-thinking the
boot/init.d method.
On Sun, 19 Sep 2004 10:30:35 -0700 Greg KH wrote:
| On Sun, Sep 19, 2004 at 10:00:52PM +0600, Alexander E. Patrakov wrote:
| >
| > OK. The fact is that, when mounting the root filesystem, the kernel can
| > (?) definitely say "there is no such device, and it's useless to wait
| > for it--so I panic". Is it possible to duplicate this logic in the case
| > with udev and modprobe? If so, it should be built into a common place
| > (either the kernel or into modprobe), but not into all apps.
|
| No, we need to just change the kernel to sit and spin for a while if the
| root partition is not found. This is the main problem right now for
| booting off of a USB device (or any other "slow" to discover device.)
| It's a known kernel issue, and there are patches for 2.4 for this, but
| no one has taken the time to update them for 2.6.
(I'm way behind, and I was hoping this thread would die, but:)
I've seen 2.6 patches for booting from USB or IEEE1394.
Is there a fair chance of getting something for USB/1394 booting
merged? (other than by using initrd)
I'd certainly like to see them merged.
[snip]
--
~Randy
MOTD: Always include version info.
(Again. Sometimes I think ln -s /usr/src/linux/.config .signature)
On Wed, Sep 29, 2004 at 04:38:28PM -0700, Randy.Dunlap wrote:
> On Sun, 19 Sep 2004 10:30:35 -0700 Greg KH wrote:
>
> | On Sun, Sep 19, 2004 at 10:00:52PM +0600, Alexander E. Patrakov wrote:
> | >
> | > OK. The fact is that, when mounting the root filesystem, the kernel can
> | > (?) definitely say "there is no such device, and it's useless to wait
> | > for it--so I panic". Is it possible to duplicate this logic in the case
> | > with udev and modprobe? If so, it should be built into a common place
> | > (either the kernel or into modprobe), but not into all apps.
> |
> | No, we need to just change the kernel to sit and spin for a while if the
> | root partition is not found. This is the main problem right now for
> | booting off of a USB device (or any other "slow" to discover device.)
> | It's a known kernel issue, and there are patches for 2.4 for this, but
> | no one has taken the time to update them for 2.6.
>
> (I'm way behind, and I was hoping this thread would die, but:)
>
> I've seen 2.6 patches for booting from USB or IEEE1394.
Where?
> Is there a fair chance of getting something for USB/1394 booting
> merged? (other than by using initrd)
I want to see this work, as lots of people bug me about this when I meet
them with the comment, "Oh, you're the USB maintainer, how come I can't
boot off of my USB flash key," which causes me to turn and run away very
fast...
thanks,
greg k-h