From: Willy Tarreau <willy@w.ods.org>
To: Eric Valette <eric.valette@free.fr>
Cc: Greg KH <greg@kroah.com>, Linus Torvalds <torvalds@osdl.org>,
linux-kernel@vger.kernel.org
Subject: Re: updating kernel to 2.6.13-rc1 from 2.6.12 + CONFIG_DEVFS_FS + empty /dev
Date: Sat, 2 Jul 2005 12:03:49 +0200 [thread overview]
Message-ID: <20050702100349.GA25749@alpha.home.local> (raw)
In-Reply-To: <42C659B2.8010002@free.fr>
On Sat, Jul 02, 2005 at 11:09:06AM +0200, Eric Valette wrote:
> Willy Tarreau wrote:
> > Well, although I've never used udev because I've been using sort of an
> > equivalent called "preinit" for 4 years now, I don't totally agree with
> > you about the firmware upgrade : when you package your systems to allow
> > the customer to perform "firmware" upgrades, your image is already very
> > specific to a hardware model, and I don't see why you would need to
> > create /dev entries independantly from the kernel or rootfs.
>
> I beg to disagree. More and more devices have generic connectivity plug
> (USB, 1394, ...) and you may update your firmware because you support a
> new device connected to this plug that is not a generic device (specific
> driver needed) but you may also have provisionned generic devices
> drivers for the plug and want devices created only when device is
> plugged (usb mass storage comes in mind). If I make a static /dev
> provision for a USB disk how many useless partition will I need to
> create,
They cost almost nothing, and in all cases, far less than the required code
to autodetect them. You just need to create /dev/sda{,0-15} for an USB disk,
and you may need to to this for sdb and/or sdc if you plan to support multiple
USB storage devices simultaneously plugged. And if your embedded system already
carries SCSI disks (which is very rare, except for example external arrays),
then you're in trouble already. Maybe sysfs can help you, I don't know.
> and how will I mount the correct number of partition without
> hotplug like feature and analysing by hand the partition table?
"analysing by hand" is a bit excessive. I don't think the difference between
for part in /dev/sda*; do
mkdir -p /mnt/${part#/dev/}
mount $part /mnt/${part#/dev/}
done
and :
while read maj min blo part; do
case $part in sda[1-9]*)
mkdir -p /mnt/$part
mount /dev/$part /mnt/$part
esac
done </proc/partitions
is so important.
Now I agree that devfs might have made it easier to find the sd* devices
associated to the usb-storage device, but it is totally independant on
your problem of creating lots of /dev entries in advance.
Regards,
Willy
next prev parent reply other threads:[~2005-07-02 10:04 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-06-29 21:03 Eric Valette
2005-06-29 22:40 ` Greg KH
2005-06-30 13:12 ` eric.valette
2005-06-30 15:54 ` Greg KH
2005-06-30 20:27 ` Eric Valette
2005-07-02 5:37 ` Greg KH
2005-07-02 7:22 ` Eric Valette
2005-07-02 8:22 ` Willy Tarreau
2005-07-02 9:09 ` Eric Valette
2005-07-02 10:03 ` Willy Tarreau [this message]
2005-07-02 20:13 ` Mike Bell
2005-07-02 23:03 ` Willy Tarreau
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=20050702100349.GA25749@alpha.home.local \
--to=willy@w.ods.org \
--cc=eric.valette@free.fr \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@osdl.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®