updating kernel to 2.6.13-rc1 from 2.6.12 + CONFIG_DEVFS_FS + empty /dev

updating kernel to 2.6.13-rc1 from 2.6.12 + CONFIG_DEVFS_FS + empty /dev

[Eric Valette]

For years now my /dev has been empty. When upgrading to 2.6.13-rc1 from
2.6.12, and updating my kernel config file via "make oldconfig" I got no
visible warning about CONFIG_DEVFS_FS options being set (or at least did
no see it).

The result, however, was *for sure* a non functionnal system and adding
udev as a defvs replacement will of course not help as I understand this
kernel needs *anyway* a minimal filesystem to boot.

While I do not want to re-enter the endless devfs versus udev merit
(allthough I personnaly strongly believe udev is just too slow for
embedded system boot compared to devfs without devfsd) I think that this
potential problem should be clearly mentionned  in the release note for
2.6.13 or at least something like "a minimal devfs able to boot emty
/dev installation" be integrated as a replacement.

For the rest of the problem, I will just waste some inodes to have a
minimal /dev back (which I think is a clear regression).

This mail intend to point out that removing a feature in the stable
series can break existing "real life" installations which, by the way,
did not break as badly as that for years. It sometimes broke using -mm
stuffs but was just a matter of waiting for a patch. I will not get a
patch for my problem.

No flame intended just feed back from end-user experience.

-- eric

Re: updating kernel to 2.6.13-rc1 from 2.6.12 + CONFIG_DEVFS_FS + empty /dev

[Greg KH]

On Wed, Jun 29, 2005 at 11:03:56PM +0200, Eric Valette wrote:
> For years now my /dev has been empty. When upgrading to 2.6.13-rc1 from
> 2.6.12, and updating my kernel config file via "make oldconfig" I got no
> visible warning about CONFIG_DEVFS_FS options being set (or at least did
> no see it).

devfs has been marked OBSOLETE for a year now.  It has also been
documented as going away.  Because of this, you should not have been
supprised at all.

> While I do not want to re-enter the endless devfs versus udev merit
> (allthough I personnaly strongly believe udev is just too slow for
> embedded system boot compared to devfs without devfsd)

What are the speed differences that you see?  I've tested it and on a
slow old laptop, with a lot of devices, udev only takes 2 seconds to
initialize the whole device tree.  If you put it in initramfs, it will
take no additional time, as it will operate on all of the hotplug events
as they happen.  Can't get faster than "nothing" :)

> I think that this potential problem should be clearly mentionned  in
> the release note for 2.6.13

That's probably a good idea.

thanks,

greg k-h

Re: updating kernel to 2.6.13-rc1 from 2.6.12 + CONFIG_DEVFS_FS + empty /dev

[eric.valette]

Quoting Greg KH <greg@kroah.com>:

> On Wed, Jun 29, 2005 at 11:03:56PM +0200, Eric Valette wrote:
> > For years now my /dev has been empty. When upgrading to 2.6.13-rc1 from
> > 2.6.12, and updating my kernel config file via "make oldconfig" I got no
> > visible warning about CONFIG_DEVFS_FS options being set (or at least did
> > no see it).
>
> devfs has been marked OBSOLETE for a year now.  It has also been
> documented as going away.  Because of this, you should not have been
> supprised at all.

I knew it! I just the announce for 2.6.13-rc1 did not contain this fact and I
did not realize booting this new kernel will fail on my machine which is bad for
a stable serie.


> What are the speed differences that you see?  I've tested it and on a
> slow old laptop, with a lot of devices, udev only takes 2 seconds to
> initialize the whole device tree.  If you put it in initramfs, it will
> take no additional time, as it will operate on all of the hotplug events
> as they happen.  Can't get faster than "nothing" :)


If I already have every device in /dev, I do not need udev and yes it is fast
:-) This is exactly what I did to boot my system again. Just via devfs, I do
not need an initial filesystem nor need anything in user space to boot a full
system which I like.


-- eric

Re: updating kernel to 2.6.13-rc1 from 2.6.12 + CONFIG_DEVFS_FS + empty /dev

[Greg KH]

On Thu, Jun 30, 2005 at 03:12:41PM +0200, eric.valette@free.fr wrote:
> Quoting Greg KH <greg@kroah.com>:
> 
> > On Wed, Jun 29, 2005 at 11:03:56PM +0200, Eric Valette wrote:
> > > For years now my /dev has been empty. When upgrading to 2.6.13-rc1 from
> > > 2.6.12, and updating my kernel config file via "make oldconfig" I got no
> > > visible warning about CONFIG_DEVFS_FS options being set (or at least did
> > > no see it).
> >
> > devfs has been marked OBSOLETE for a year now.  It has also been
> > documented as going away.  Because of this, you should not have been
> > supprised at all.
> 
> I knew it! I just the announce for 2.6.13-rc1 did not contain this fact and I
> did not realize booting this new kernel will fail on my machine which is bad for
> a stable serie.

As there is no longer a "development series" calling 2.6 a "stable
series" isn't really true :)

thanks,

greg k-h

Re: updating kernel to 2.6.13-rc1 from 2.6.12 + CONFIG_DEVFS_FS + empty /dev

[Eric Valette]

Greg KH wrote:
> On Thu, Jun 30, 2005 at 03:12:41PM +0200, eric.valette@free.fr wrote:
> 
>>Quoting Greg KH <greg@kroah.com>:
>>
>>
>>>On Wed, Jun 29, 2005 at 11:03:56PM +0200, Eric Valette wrote:
>>>
>>>>For years now my /dev has been empty. When upgrading to 2.6.13-rc1 from
>>>>2.6.12, and updating my kernel config file via "make oldconfig" I got no
>>>>visible warning about CONFIG_DEVFS_FS options being set (or at least did
>>>>no see it).
>>>
>>>devfs has been marked OBSOLETE for a year now.  It has also been
>>>documented as going away.  Because of this, you should not have been
>>>supprised at all.
>>
>>I knew it! I just the announce for 2.6.13-rc1 did not contain this fact and I
>>did not realize booting this new kernel will fail on my machine which is bad for
>>a stable serie.
> 
> 
> As there is no longer a "development series" calling 2.6 a "stable
> series" isn't really true :)

Curious to wait until 2.6.13 pops up to see how much people will end up
having non working systems either because :
	1) They removed entries in their /dev
	2) Did not maintain their /dev for years because anyway it was not
directly accessed
	3) modified their /etc/fstab to put devfs names rather than FHS/LSB
compliant names...
	4) other weird /dev-devfs interaction I cannot imagine yet

BTW speaking of initramfs to hold the minimal /dev, in the embedded
world initramfs has to be stored in flash as udev binary and eventually
additionnal scripts, this represent flash memory (OK very little I have
to admit but when you need to find 10K of flash or change the flash
size...).

I hope someone will pick-up your nano defvs proposal and enhance it to
support a  version enabling to boot a system without anything in /dev.
Unfortunately no time yet on my side.

Thanks for all the things you have done in linux,

-- eric

Re: updating kernel to 2.6.13-rc1 from 2.6.12 + CONFIG_DEVFS_FS + empty /dev

[Greg KH]

On Thu, Jun 30, 2005 at 10:27:45PM +0200, Eric Valette wrote:
> 
> BTW speaking of initramfs to hold the minimal /dev, in the embedded
> world initramfs has to be stored in flash as udev binary and eventually
> additionnal scripts, this represent flash memory (OK very little I have
> to admit but when you need to find 10K of flash or change the flash
> size...).

Why?  Why not put it in ROM with your kernel image, look at how the
kernel build process does it with the "built-in" initramfs.

If that doesn't work, initrd still works just as well for udev, that's
what RH does.

> I hope someone will pick-up your nano defvs proposal and enhance it to
> support a  version enabling to boot a system without anything in /dev.

I boot my boxes with nothing in /dev and have been for almost a year
now.  udev works just fine for this, and so do some other programs that
work like udev does.

I hope everyone can just forget about my nano devfs proposal, and just
pass it off as a example of someone who went temporarily insane.

thanks,

greg k-h

Re: updating kernel to 2.6.13-rc1 from 2.6.12 + CONFIG_DEVFS_FS + empty /dev

[Eric Valette]

Greg KH wrote:

> Why?  Why not put it in ROM with your kernel image, look at how the
> kernel build process does it with the "built-in" initramfs.

Well, nowadays, most system have only flash because ROM does not enable
to do firmware upgrade. Second, putting it in the kernel or as a
separate flash section or in an initrd does not change the problem :
something has to be stored on non volatile memory whereas you do not
need that for devfs (except devfs code itself of course) but then you
have udev instead of devfs...

> I boot my boxes with nothing in /dev and have been for almost a year
> now.  udev works just fine for this, and so do some other programs that
> work like udev does.

Nothing in /dev but with initramfs. Same cost...

BTW : valette@tri-yann->df /dev
Filesystem           1K-blocks      Used Available Use% Mounted on
tmpfs                    10240      2876      7364  29% /dev


2 MB RAM on my PC???  I must be missing something.

Thanks for your time nayway.

-- eric

Re: updating kernel to 2.6.13-rc1 from 2.6.12 + CONFIG_DEVFS_FS + empty /dev

[Willy Tarreau]

Hi Eric,

On Sat, Jul 02, 2005 at 09:22:20AM +0200, Eric Valette wrote:
> Greg KH wrote:
> 
> > Why?  Why not put it in ROM with your kernel image, look at how the
> > kernel build process does it with the "built-in" initramfs.
> 
> Well, nowadays, most system have only flash because ROM does not enable
> to do firmware upgrade. Second, putting it in the kernel or as a
> separate flash section or in an initrd does not change the problem :
> something has to be stored on non volatile memory whereas you do not
> need that for devfs (except devfs code itself of course) but then you
> have udev instead of devfs...

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. Speaking
for myself, my .preinit script which describes how to fill /dev entries
is on the rootfs and does not need to change once packaged.

However, I agree that I encountered difficulties using this system on
more generic hardware, because sometimes the raid devices did not exist,
or things like this caused trouble.

IMHO, a generic system should use a full /dev directory and an embedded
system should use just the strict minimum necessary for the specific
hardware to run.

> > I boot my boxes with nothing in /dev and have been for almost a year
> > now.  udev works just fine for this, and so do some other programs that
> > work like udev does.
> 
> Nothing in /dev but with initramfs. Same cost...
> 
> BTW : valette@tri-yann->df /dev
> Filesystem           1K-blocks      Used Available Use% Mounted on
> tmpfs                    10240      2876      7364  29% /dev
> 
> 
> 2 MB RAM on my PC???  I must be missing something.

I think something went wrong, perhaps something like

   # some_prog >/dev/null 

while null did not exist. My /dev is a tmpfs too, but mounted with size=0,
so that I can only create inodes into it, but cannot write any data. One
other advantage of using size=0 is that "df" does not show it by default.

Cheers,
Willy

Re: updating kernel to 2.6.13-rc1 from 2.6.12 + CONFIG_DEVFS_FS + empty /dev

[Eric Valette]

Willy Tarreau wrote:
> Hi Eric,

Hi willy,

> 
> On Sat, Jul 02, 2005 at 09:22:20AM +0200, Eric Valette wrote:
> 
>>Greg KH wrote:
>>
>>
>>>Why?  Why not put it in ROM with your kernel image, look at how the
>>>kernel build process does it with the "built-in" initramfs.
>>
>>Well, nowadays, most system have only flash because ROM does not enable
>>to do firmware upgrade. Second, putting it in the kernel or as a
>>separate flash section or in an initrd does not change the problem :
>>something has to be stored on non volatile memory whereas you do not
>>need that for devfs (except devfs code itself of course) but then you
>>have udev instead of devfs...
> 
> 
> 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, and how will I mount the correct number of partition without
hotplug like feature and analysing by hand the partition table?


>>BTW : valette@tri-yann->df /dev
>>Filesystem           1K-blocks      Used Available Use% Mounted on
>>tmpfs                    10240      2876      7364  29% /dev
>>
>>
>>2 MB RAM on my PC???  I must be missing something.
> 
> 
> I think something went wrong, perhaps something like
> 
>    # some_prog >/dev/null 
> 
> while null did not exist. My /dev is a tmpfs too, but mounted with size=0,
> so that I can only create inodes into it, but cannot write any data. One
> other advantage of using size=0 is that "df" does not show it by default.

Not sure. It is a debian sid install.

Thanks anyone who responded. I'll be unable to read mails for a while.


-- eric

Re: updating kernel to 2.6.13-rc1 from 2.6.12 + CONFIG_DEVFS_FS + empty /dev

[Willy Tarreau]

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

Re: updating kernel to 2.6.13-rc1 from 2.6.12 + CONFIG_DEVFS_FS + empty /dev

[Mike Bell]

On Sat, Jul 02, 2005 at 12:03:49PM +0200, Willy Tarreau wrote:
> They cost almost nothing, and in all cases, far less than the required code
> to autodetect them.

I beg to differ on that. As ndevfs has shown, the code required to
create a device node from kernel space is actually very minimal, when
you utilize all the infrastructure already available to you in the
kernel. libfs has most of what you need, the rest is easily stolen from
ramfs. Almost undoubtebly much less than all those device nodes,
especially when you consider the need to be able to perform chown/chmod
on nodes (thus they can't be stored in the read-only flash image, but
must instead be created at each boot on a kernel-generated filesystem
like ramfs)

devfs not utilizing it is perfectly explainable by the fact none of it
was around way back when devfs was created. Back then kernel generated
filesystems were proc, proc and proc. proc is pretty ugly too.

Re: updating kernel to 2.6.13-rc1 from 2.6.12 + CONFIG_DEVFS_FS + empty /dev

[Willy Tarreau]

On Sat, Jul 02, 2005 at 01:13:58PM -0700, Mike Bell wrote:
> On Sat, Jul 02, 2005 at 12:03:49PM +0200, Willy Tarreau wrote:
> > They cost almost nothing, and in all cases, far less than the required code
> > to autodetect them.
> 
> I beg to differ on that. As ndevfs has shown, the code required to
> create a device node from kernel space is actually very minimal, when
> you utilize all the infrastructure already available to you in the
> kernel. libfs has most of what you need, the rest is easily stolen from
> ramfs. Almost undoubtebly much less than all those device nodes,
> especially when you consider the need to be able to perform chown/chmod
> on nodes (thus they can't be stored in the read-only flash image, but
> must instead be created at each boot on a kernel-generated filesystem
> like ramfs)

Well, here on my firewall, the /.preinit script is 1.7 kB and the init
binary which does everything (mkdir,mknod,chmod,chown,mount,...) is 5.6 kB.
I doubt you can enable devfs in a kernel for less than 8 kB. One /tmpfs
entry consumes about 600 bytes of RAM, which is still fairly acceptable
IMHO.

> devfs not utilizing it is perfectly explainable by the fact none of it
> was around way back when devfs was created. Back then kernel generated
> filesystems were proc, proc and proc. proc is pretty ugly too.

Regards,
Willy