Re: general hotplug/udev questions

[Kay Sievers <kay.sievers@vrfy.org>]

On Thu, Aug 18, 2005 at 01:14:36PM -0700, Greg KH wrote:
> On Thu, Aug 18, 2005 at 12:53:34PM -0700, rich turner wrote:
> > because my linuxrc does not create events or mount /lib/klibc/events in
> > the initrd, then boot.coldplug does not load the network modules.
> 
> That is correct.

If the bootup sequence does not find the directory with the events to
replay, it should fall back to the traditional "coldplug" with scanning
the buses and loading modules. Maybe that's not working in your setup.

> > i realize i can load the network modules in the initrd and everything
> > would be golden, but that is not the purpose of the initrd. in my
> > opinion we already do to much in the initrd because the distributions
> > dont do enough (or do it correctly) in their init scripts. we try to
> > keep the initrd's purpose to do only enough to mount the root
> > filesystem.
> 
> Sorry, but that's not the way we are all moving toward.  With initramfs
> and kinit we are pushing more and more of the early boot stuff into a
> initramfs/initrd image to get it out of the kernel itself.
> 
> > it is important that our process remain generic across all distributions
> > because we need to support many other distributions.
> 
> I wish you the best of luck.  Providing custom kernel images for
> different distros, while ignoring how they do their initrd/initramfs
> boot sequence seems like a futile way to go.  Not to mention breaking
> your customer's service contracts with their distro :)

My best wishes too. All the arch's SUSE supports is strange enough. And
looking at the distro's udev packages gives me the impression, that this
will be a tough road for you. :)

> > does anyone have an opinion as to whether suse's current method will
> > become the standard?
> 
> Is there ever a "standard" for Linux?  :)
> 
> Seriously, I think something like this will become more common as it
> solves a lot of problems people have with early boot processes.  Look at
> how Red Hat solves it (in a different way, but with the same results.)

SUSE's current "event replay from initramfs" works nice so far and is
a generic way to solve the boot sequencing problems. One other option
may be to crawl /sys and submit the events to udevd instead of getting
it from initramfs. That would also work with every kernel, not only
with a special prepared initramfs. We will need to test if this
option works "good enough" - for now it only sounds like a nice
alternative.

> > it appears that udevstart.static creates events but /sbin/udevstart does
> > not. why is that?

There should be no difference. The openSUSE package has only one single
patch to keep the udev rules in the udev daemon instead of parsing the
rules with every event. This patch is available on the hotplug list.

> > is /sbin/hotplugevenrecorder an executable being distributed by suse or
> > is it something that will be coming in the maintained udev?
> 
> http://www.kernel.org/git/?p=linux/hotplug/udev.git;a=blob;hš3c3e197c6cf3972c0f9d910ac206aed3df66e7;hbŒ11a2f0ff27264513033691bb818262f009fe4e;f=udeveventrecorder.c
> look like what you are looking for?

We put for now everything SUSE uses in the upstream udev package.
There is no documentation besides our package. If we find a better way
to do it (smarter coldplug), we may replace this.

> > even though we use udevstart in the initrd, is there any real purpose to
> > echoing something (/sbin/udev, /sbin/udevsend, /bin/true) out
> > to /proc/sys/kernel/hotplug while in the initrd?
> 
> Depends on how you want to catch hotplug events.

Yeah, at least /bin/true does not make any sense. :)

> > it is my experience that udev only handles devices that you would expect
> > to find in /dev. how could it have any effect on network interfaces? is
> > this a product of hotplug or udev?
> 
> Both.  udev can handle network devices just fine, has for years.

Yes, udev can rename network interfaces with the same rule logic, it can name
a device node.

Kay


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel