astlinux-users

[Astlinux-users] udev vs. hotplug

[Kristian K. <kri...@gm...>]

Hello everyone,

  Darrick recently brought up a good point...  Hotplugging firmware
for devices (/lib/firmware).  I've been looking into this myself and I
have determined that the best route would be to add the full
linux-hotplug package.  This really isn't that big of a deal, the size
increase is minimal because it's really just a bunch of shell scripts.
 It ads a level of complexity that I would otherwise not have, but
that's why it would be run-time optional.

  However, looking at hotplug made me think about the entire
management of devices, firmware, etc.  Hotplug has been succeeded in
most 2.6-based distributions by udev for complete management of
devices, device nodes, and firmware.

  I'd rather not implement udev at this stage.  While it seems to be
much more reliable than devfs+hotplug, it still doesn't seem as simple
or reliable as static device nodes.

  Then again maybe I'm wrong.  What do you think?  Should we start
with hotplug as an option and move to udev later?  Or is udev worth a
shot now?

-- 
Kristian Kielhofner

Re: [Astlinux-users] udev vs. hotplug

[Darrick H. (lists) <dha...@dj...>]

Kristian Kielhofner wrote:
> Hello everyone,
> 
>   Darrick recently brought up a good point...  Hotplugging firmware
> for devices (/lib/firmware).  I've been looking into this myself and I
> have determined that the best route would be to add the full
> linux-hotplug package.  This really isn't that big of a deal, the size
> increase is minimal because it's really just a bunch of shell scripts.
>  It ads a level of complexity that I would otherwise not have, but
> that's why it would be run-time optional.
> 
>   However, looking at hotplug made me think about the entire
> management of devices, firmware, etc.  Hotplug has been succeeded in
> most 2.6-based distributions by udev for complete management of
> devices, device nodes, and firmware.
> 
>   I'd rather not implement udev at this stage.  While it seems to be
> much more reliable than devfs+hotplug, it still doesn't seem as simple
> or reliable as static device nodes.

devfs was a nightmare.  udev is much better, but still needs to be 
tested for our use.  There were bugs early on.  Most of that (if not all 
of that) has been worked out.

>   Then again maybe I'm wrong.  What do you think?  Should we start
> with hotplug as an option and move to udev later?  Or is udev worth a
> shot now?

If you're looking at this to support firmware, we need to go all the way 
with udev.  The "hotplug" binary is NOT required with the new kernels 
(2.6.14 and higher).  That stuff was a hack.  This page explains the 
details farther:

http://vrfy.org/log/recent-state-of-udev.html

The so called "hotplug" package that is currently in trunk should be 
removed.  It's based on something so old that it does nothing but cause 
confusion/harm.

I'd say we move on getting udev implemented in trunk after immediately 
creating a 0.5 branch.  udev would then become part of 0.6.  It's a big 
change so we should allow some time to work out the kinks.

Darrick
-- 
Darrick Hartman
DJH Solutions, LLC
http://www.djhsolutions.com

Re: [Astlinux-users] udev vs. hotplug

[Kristian K. <kri...@gm...>]

On 9/10/07, Darrick Hartman (lists) <dha...@dj...> wrote:
>
> devfs was a nightmare.  udev is much better, but still needs to be
> tested for our use.  There were bugs early on.  Most of that (if not all
> of that) has been worked out.
>

  devfs was never an option for AstLinux.  No way!

> If you're looking at this to support firmware, we need to go all the way
> with udev.  The "hotplug" binary is NOT required with the new kernels
> (2.6.14 and higher).  That stuff was a hack.  This page explains the
> details farther:
>
> http://vrfy.org/log/recent-state-of-udev.html
>
> The so called "hotplug" package that is currently in trunk should be
> removed.  It's based on something so old that it does nothing but cause
> confusion/harm.

  I'm a little confused by this...  I am unable to find anything (nor
have I heard of anything) that suggests firmware loading is handled
any differently between 2.6.14 and any other kernel.  I also can't
find anything that says its handled by the kernel at all.

  Just last week I had to load the firmware for a USB DSL modem I was
playing with.  On 2.6.20 it wouldn't work with anything other than
hotplug.  Udev probably would've worked too, if I would have bothered.

  It looks like you still need either udev or hotplug to load firmware.

> I'd say we move on getting udev implemented in trunk after immediately
> creating a 0.5 branch.  udev would then become part of 0.6.  It's a big
> change so we should allow some time to work out the kinks.
>
> Darrick

  If we really need some form of hotplug for firmware loading, I'd
rather do that pre-0.5.  We already include diethotplug - it just
doesn't seem to actually work.  Changing from diethotplug to hotplug
pre-0.5 and then (maybe) moving to udev later sounds best UNLESS
firmware loading can be made to work without either.

-- 
Kristian Kielhofner

Re: [Astlinux-users] udev vs. hotplug

[Darrick H. (lists) <dha...@dj...>]

Kristian Kielhofner wrote:
>   devfs was never an option for AstLinux.  No way!

I never said it was.  It was a hack that needed to die sooner than it did.

>> If you're looking at this to support firmware, we need to go all the way
>> with udev.  The "hotplug" binary is NOT required with the new kernels
>> (2.6.14 and higher).  That stuff was a hack.  This page explains the
>> details farther:
>>
>> http://vrfy.org/log/recent-state-of-udev.html
>>
>> The so called "hotplug" package that is currently in trunk should be
>> removed.  It's based on something so old that it does nothing but cause
>> confusion/harm.
 >
>   I'm a little confused by this...  I am unable to find anything (nor
> have I heard of anything) that suggests firmware loading is handled
> any differently between 2.6.14 and any other kernel.  I also can't
> find anything that says its handled by the kernel at all.

I looked this up again.  I misread the comment related to 2.6.14.  The 
biggest milestone related in anyway to this discussion with that kernel 
release was the inclusion of the Intel wifi drivers.  So you are correct 
that the kernel version may not directly affect this discussion other 
than some of the events are triggered from sysfs and the way those 
triggers are created changed at some point in the kernel.

>   Just last week I had to load the firmware for a USB DSL modem I was
> playing with.  On 2.6.20 it wouldn't work with anything other than
> hotplug.  Udev probably would've worked too, if I would have bothered.
> 
>   It looks like you still need either udev or hotplug to load firmware.

Right.  udev is the more current of the two.  hotplug is no longer 
needed as udev implemented it's functionality within udev.  Look at udev 
closer.  You can (and should) have some static devices which are located 
temporarily in /lib/ then copied to /dev/ (which is mounted as tmpfs) on 
bootup.

>> I'd say we move on getting udev implemented in trunk after immediately
>> creating a 0.5 branch.  udev would then become part of 0.6.  It's a big
>> change so we should allow some time to work out the kinks.
>>
>> Darrick
> 
>   If we really need some form of hotplug for firmware loading, I'd
> rather do that pre-0.5.  We already include diethotplug - it just
> doesn't seem to actually work.  Changing from diethotplug to hotplug
> pre-0.5 and then (maybe) moving to udev later sounds best UNLESS
> firmware loading can be made to work without either.

We include diethotplug but it's not configured to do anything.  Someone 
correct me if I'm wrong, but I don't believe that the hotplug scripts 
can load the firmware without the use of udev but current releases of 
udev CAN operate without the use of the hotplug scripts.  Please note 
that the hotplug scripts are not the same as hotplug support in the 
kernel.  Hotplug support in the kernel provides the information to 
sysfs.  With current releases of udev, udevd listens for uevents sent to 
sysfs.  One of these events is the driver asking for firmware.

Darrick
-- 
Darrick Hartman
DJH Solutions, LLC
http://www.djhsolutions.com