From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kay Sievers Date: Thu, 18 Aug 2005 20:49:46 +0000 Subject: Re: general hotplug/udev questions Message-Id: <20050818204946.GA11197@vrfy.org> List-Id: References: <1124394814.4483.46.camel@rich> In-Reply-To: <1124394814.4483.46.camel@rich> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable To: linux-hotplug@vger.kernel.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. >=20 > 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. >=20 > 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. >=20 > > it is important that our process remain generic across all distributions > > because we need to support many other distributions. >=20 > 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? >=20 > Is there ever a "standard" for Linux? :) >=20 > 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? >=20 > http://www.kernel.org/git/?p=3Dlinux/hotplug/udev.git;a=3Dblob;h=9A3c3e19= 7c6cf3972c0f9d910ac206aed3df66e7;hb=8C11a2f0ff27264513033691bb818262f009fe4= e;f=3Dudeveventrecorder.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? >=20 > 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? >=20 > Both. udev can handle network devices just fine, has for years. Yes, udev can rename network interfaces with the same rule logic, it can na= me 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