From: Greg KH <greg@kroah.com>
To: linux-hotplug@vger.kernel.org
Subject: Re: general hotplug/udev questions
Date: Thu, 18 Aug 2005 20:14:36 +0000 [thread overview]
Message-ID: <20050818201436.GA31814@kroah.com> (raw)
In-Reply-To: <1124394814.4483.46.camel@rich>
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.
> 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 :)
> 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.)
> it appears that udevstart.static creates events but /sbin/udevstart does
> not. why is that?
>
> 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?
> 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.
Note, a lot of this has changed recently in suse's kernel. Take a look
at opensuse beta 2 for examples of this.
> 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.
thanks,
greg k-h
-------------------------------------------------------
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
next prev parent reply other threads:[~2005-08-18 20:14 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-18 19:53 general hotplug/udev questions rich turner
2005-08-18 20:14 ` Greg KH [this message]
2005-08-18 20:49 ` Kay Sievers
2005-08-19 9:09 ` Alexander E. Patrakov
2005-08-19 11:10 ` Marco d'Itri
2005-08-19 16:23 ` Greg KH
2005-08-19 16:33 ` Alexander E. Patrakov
2005-08-19 16:35 ` Kay Sievers
2005-08-19 16:38 ` Marco d'Itri
2005-08-19 16:47 ` Greg KH
2005-08-19 16:56 ` Kay Sievers
2005-08-19 17:11 ` Greg KH
2005-08-19 17:18 ` Kay Sievers
2005-08-21 7:16 ` Alexander E. Patrakov
2005-08-24 19:43 ` Kay Sievers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050818201436.GA31814@kroah.com \
--to=greg@kroah.com \
--cc=linux-hotplug@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.