public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* DEVFS_FS
@ 2004-11-10 20:46 linux-os
  2004-11-10 21:03 ` DEVFS_FS Alexandre Costa
  0 siblings, 1 reply; 7+ messages in thread
From: linux-os @ 2004-11-10 20:46 UTC (permalink / raw)
  To: Linux kernel


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.

^ permalink raw reply	[flat|nested] 7+ messages in thread
* Re: DEVFS_FS
@ 2004-11-11 19:53 Adam J. Richter
  0 siblings, 0 replies; 7+ messages in thread
From: Adam J. Richter @ 2004-11-11 19:53 UTC (permalink / raw)
  To: linux-kernel, linux-os; +Cc: akpm, alebyte, gene.haskett, linux-fsdevel

>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        \ /
adam@yggdrasil.com      | g g d r a s i l

^ permalink raw reply	[flat|nested] 7+ messages in thread
* Re: DEVFS_FS
@ 2004-11-11 20:24 Adam J. Richter
  0 siblings, 0 replies; 7+ messages in thread
From: Adam J. Richter @ 2004-11-11 20:24 UTC (permalink / raw)
  To: gene.haskett; +Cc: alebyte, linux-kernel, linux-os

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
>>
>><linux-os@chaos.analogic.com> 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        \ /
adam@yggdrasil.com      | g g d r a s i l

^ permalink raw reply	[flat|nested] 7+ messages in thread
end of thread, other threads:[~2004-11-11  6:01 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-11-10 20:46 DEVFS_FS linux-os
2004-11-10 21:03 ` DEVFS_FS Alexandre Costa
2004-11-11  0:06   ` DEVFS_FS Gene Heskett
2004-11-11  0:19     ` DEVFS_FS Greg KH
2004-11-11  6:01       ` DEVFS_FS Gene Heskett
  -- strict thread matches above, loose matches on Subject: below --
2004-11-11 19:53 DEVFS_FS Adam J. Richter
2004-11-11 20:24 DEVFS_FS Adam J. Richter

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox