What is the approved substitute for DEVFS_FS that is marked
obsolete?
Cheers,
Dick Johnson
Penguin : Linux version 2.6.9 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by John Ashcroft.
98.36% of all statistics are fiction.
On Wed, 10 Nov 2004 15:46:06 -0500 (EST), linux-os
<[email protected]> wrote:
> What is the approved substitute for DEVFS_FS that is marked
> obsolete?
udev
http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html
--
Alexandre Costa
Linux Reg. User: 129596
alebyte at gmail dot com
ICQ UIN n?: 19607379
On Wednesday 10 November 2004 16:03, Alexandre Costa wrote:
>On Wed, 10 Nov 2004 15:46:06 -0500 (EST), linux-os
>
><[email protected]> wrote:
>> What is the approved substitute for DEVFS_FS that is marked
>> obsolete?
>
>udev
>http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html
Humm, I'm not sure I'm entirely happy with that choice. I have an
FC3RC5 install on an old P-II running at 233mhz, and the udev start
in the bootup is the slowest single thing to get started by an order
of magnitude.
Can someone tell me a good reason udev wastes as much time as the post
does checking 383 megs of memory, which is very nearly a minute even
just for udev?
If its to be used, its got to speed itself up, a LOT!.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.28% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.
On Wed, Nov 10, 2004 at 07:06:37PM -0500, Gene Heskett wrote:
> On Wednesday 10 November 2004 16:03, Alexandre Costa wrote:
> >On Wed, 10 Nov 2004 15:46:06 -0500 (EST), linux-os
> >
> ><[email protected]> wrote:
> >> What is the approved substitute for DEVFS_FS that is marked
> >> obsolete?
> >
> >udev
> >http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html
>
> Humm, I'm not sure I'm entirely happy with that choice. I have an
> FC3RC5 install on an old P-II running at 233mhz, and the udev start
> in the bootup is the slowest single thing to get started by an order
> of magnitude.
>
> Can someone tell me a good reason udev wastes as much time as the post
> does checking 383 megs of memory, which is very nearly a minute even
> just for udev?
It's all up to the rules you are using for udev. If you have udev rules
that call out to scripts for every device (like I think the SuSE default
install does), udevstart can take a long time.
If you don't have any external dependancies, udevstart is fast.
> If its to be used, its got to speed itself up, a LOT!.
Please post what version of udev you are using, and what your udev rules
file looks like.
thanks,
greg k-h
>What is the approved substitute for DEVFS_FS that is marked
>obsolete?
DEVFS_FS is not obsolete. Rather, this is a case of misstatements
being repeated so many times that people start to believe it.
1. Only devfs (or the lookup trapping facility used in my remake
of it) can configure new devices on demand based on accesses to files
missing from /dev, which allows for faster boot time (no need
to initialize device you won't use during this session), easier fixing
of device driver bugs, and potentially less memory utilization (the new
devfs implementation plus lookup traps have a code size of about 5kB combined;
the inode+dname utilization of devfs is less than sysfs due to there
being fewer nodes and you can run devfs without sysfs, and when
inode+dname memory utilization of both are fixed, the size of the
unnecessarily loaded kernel modules will dominate).
2. Only devfs allows a device driver to pass suggested names
for arbitrary minor device numbers (e.g., /dev/sound/mixer,
/dev/sound/dsp). Otherwise, a configuration file or a static /dev
has to know these things in advance.
3. Only devfs allows a device driver to pass suggested names
for arbitrary related facilities that do not fall under the same
major device number (e.g., CD-ROM's, tapes).
Fundamentally, the functionality of being able to trap accesses
to nonexistent devices and the ability to pass the additional string
information in #2 and #3 provide a more flexible user interface as
new kernel facilities are developed, and communicating the relevant
information through a virtual file system is useful for avoid
unnecessary serialization and deferring certain initializations (for
example, until later in a boot process).
By the way, with devfs, especially under the new implementation,
it is not particularly difficult to remap the names using {,UN}REGISTER
events from a shadow file system (or directly from /dev if you also
want the default names), without the underlying configuration having
any prior knowledge about device numbers. Many statements in Greg
Kroah-Hartmann's "udev and devfs - The final word" that seem to
contract this seem to me to be wrong or misleading when it would
be easy to be clearer (for example, "devfs does not handle the need
for dynamic major/minor numbers", when devfs does not care and not
know whether the major/minor device number passed to it were
dynamically allocated).
This is not to say that I am "against udev" by every possible
interpretation of that term. I think using sysfs or hotplug events to
create nodes in /dev (but usually not to load the corresponding kernel
modules) is a useful user interface improvement. I also hope to see
the devfs interface evolve to do things like be able to statically export
the default /dev file mappers from kernel modules, just as hardware
device ID tables are exported, and, if sysfs memory consumption were
to improve radically (the sysfs backing store patch would really help),
then the memory usage, the _requirement_ of a user level helper
program (instead of it just being an option) and the loss of ability
to select devfs and sysfs independently _might_ be offset by
simplification of other user level helper code (by making /dev
maintenance one of multiple duties of a sysfs watching facility).
I think that Linux users would be much better served by allowing
the devfs functionality to be actively maintained, improved and exported
to "non-devfs" systems (for example the tmpfs lookup trapping) in general,
and, in particular, by integrating my devfs rewrite instead of
refusing it (and I have offered to arrange it so that the kernel can
be configured with either the old or the new devfs implementation).
Whether this functionality is called "devfs" in the future is not
important, but providing its functionality for those who want it is,
and that is what is being undermined by not integrating the new devfs
implementation.
__ ______________
Adam J. Richter \ /
[email protected] | g g d r a s i l
On 2004-11-11 0:06:37, Gene Heskett wrote:
>On Wednesday 10 November 2004 16:03, Alexandre Costa wrote:
>>On Wed, 10 Nov 2004 15:46:06 -0500 (EST), linux-os
>>
>><[email protected]> wrote:
>>> What is the approved substitute for DEVFS_FS that is marked
>>> obsolete?
>>
>>udev
>>http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html
>
>Humm, I'm not sure I'm entirely happy with that choice. I have an
>FC3RC5 install on an old P-II running at 233mhz, and the udev start
>in the bootup is the slowest single thing to get started by an order
>of magnitude.
>
>Can someone tell me a good reason udev wastes as much time as the post
>does checking 383 megs of memory, which is very nearly a minute even
>just for udev?
>
>If its to be used, its got to speed itself up, a LOT!.
Gene,
I do not know what kind of device you are using or what kind
of inialization it really needs, but your situation _might_ be a good
example of the benefits of being able configure devices on demand with
devfs if this is a device that you do not use every time you boot
your system and that initialization process is not something that
can easily be deferred to the first device open() call.
As you may know, in the recent releases of my devfs rewrite,
I split the demand loading for missing device files into a separate
a separate facility (tmpfs "lookup traps"). That way, even if you
do not want to run the rest of devfs, you could avoid that
initilization and perhaps some kernel memory usage from the device
driver in the sessions that never use that device.
On the other hand, initialization on demand would make your
first access of the session to that device spend the same amount of
time that you are now spending at boot, whereas, you might instead
want to have that device driver loaded at boot time and stay in
kernel memory so that you can do the initialization in the background
if you can somehow ensure that access to the device will block until
the initialization completes if necessary.
__ ______________
Adam J. Richter \ /
[email protected] | g g d r a s i l
On Wednesday 10 November 2004 19:19, Greg KH wrote:
>On Wed, Nov 10, 2004 at 07:06:37PM -0500, Gene Heskett wrote:
>> On Wednesday 10 November 2004 16:03, Alexandre Costa wrote:
>> >On Wed, 10 Nov 2004 15:46:06 -0500 (EST), linux-os
>> >
>> ><[email protected]> wrote:
>> >> What is the approved substitute for DEVFS_FS that is marked
>> >> obsolete?
>> >
>> >udev
>> >http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html
>>
>> Humm, I'm not sure I'm entirely happy with that choice. I have an
>> FC3RC5 install on an old P-II running at 233mhz, and the udev
>> start in the bootup is the slowest single thing to get started by
>> an order of magnitude.
>>
>> Can someone tell me a good reason udev wastes as much time as the
>> post does checking 383 megs of memory, which is very nearly a
>> minute even just for udev?
>
>It's all up to the rules you are using for udev. If you have udev
> rules that call out to scripts for every device (like I think the
> SuSE default install does), udevstart can take a long time.
>
This is a box stock FC3RC5 install, Greg. I haven't touched a thing
in how it works because I don't know anything about it, other than
its about 1/3rd of the total boot time.
>If you don't have any external dependancies, udevstart is fast.
>
>> If its to be used, its got to speed itself up, a LOT!.
>
>Please post what version of udev you are using, and what your udev
> rules file looks like.
Probably see the FC3 release, but I don't know how much diff there is
between RC5 and the final, rsync is trying to convert mine to final
right now. Where is this rules file?
>thanks,
>
>greg k-h
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.28% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.