Re: DEVFS_FS

[Mike Waychison <Michael.Waychison@Sun.COM>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Adam J. Richter wrote:
> On Mon Nov 15 11:27:50 2004, Bryan Henderson wrote:
> 
> 
>>>>So it sounds like you're talking about the feature of devfs in which the 
> 
> 
>>>>driver doesn't get loaded until someone refers to the /dev directory 
>>
>>that 
>>
>>>>refers to it.  But that's not a characteristic of devfs -- that's just 
>>>>devfs keeping up with the classic mknod system.  In the classic system 
>>
>>(if 
>>
>>>>you choose to set it up that way), the device driver doesn't get loaded 
>>>>until someone refers to its major number.  That's part of the general 
>>>>module autoloading function.
>>>
>>>               Only with lookup trapping (either built into the old 
>>
>>devfs
>>
>>>or as a separate facility), can you autoload on a reference to
>>>/dev/cdroms/cdrom0, because you do not know the device number,
>>>in turn, you do not know if it is scsi, iSCSI, IDE, or
>>>proprietary dinosaur. 
> 
> 
>>I don't get what example you're envisioning.  I do know that my cdrom 
>>device is scsi and I know (because I'm careful, of course) that its device 
>>number is (11,0).
> 
> 
> 	But you cannot in general.  For example, you cannot ship a
> general Linux distribution this way, because you do not know that
> the user's cdrom the scsi device.
> 
> 
>>[...] (Remember 
>>the assertion that's in question: that only devfs lets you defer occupying 
>>memory with a device driver until the device is used).
> 
> 
> 	No, and I resent your attempt to try to change what I said
> by removing qualifiers from it.  I was clearly talking about the
> cases where the major and minor device numbers are not necessarily
> known in advance.  In the future, if you want to try to quote my own
> statements back to me, please use quotation.  I said:
> 
> |        Only with lookup trapping (either built into the old devfs
> | or as a separate facility), can you autoload on a reference to
> | /dev/cdroms/cdrom0, because you do not know the device number,
> | because, in turn, you do not know if it is scsi, iSCSI, IDE, or
> | proprietary dinosaur.
> 
> 	This is a real advatnage of devfs-style lookup trapping.
> 

What is the advantage of autoloading on access to hardware backed device
files though?  As Bryan points out, the only apparent advantage is
saving a couple K in memory while the driver isn't loaded.

Claiming that trapping+autoloading will resolve device number issues is
a straw man.  You still have to walk the hardware, and apply policy for
which piece of hardware is 'cdrom0'.  The udev model does this very
effectively: where there is hardware backing the device files, there is
no good reason to not load the drivers and have policy set once and for
all on udevstart.

The only need for trapping that I can see is for modules that don't have
hardware backing them, such as tun and loop.

> 
> 
>>>>Taking SCSI 
>>>>as an example, a reasonable driver for a single parallel SCSI bus with 
>>
>>one 
>>
>>>>LU per target could simply assign minor number = target ID
>>>
>>>Your statement about SCSI and device numbers is factually
>>>wrong...  There are four different major numbers for SCSI devices:...
> 
> 
>>Well, not my statement but rather your interpretation of it.  When I said 
>>"a reasonable driver..." I didn't mean the one people use today, which 
>>doesn't do anything like what I described.  I was trying to make a simple 
>>hypothetical case to show the underlying concept that load-on-demand is 
>>harder in devfs than in classic mknod --
> 
> 
> 	First of all, there are likely to be more ways to access
> CD or DVD images in the future rather than fewer.  It may be more
> common, for example, for people to want to access these drivers
> over the net, or to have completely virtual drives in
> the form of .iso files.  Requiring all of this to be done under
> a single device number would just add extra cycles, increase
> kernel code complexity, and further obscure potentially useful
> hardware information from the user.  I am confident that the
> lines of code involved in implementing this would exceed that
> of my implementations of lookup traps plus devfs, and be harder
> to compile out for users who don't want it.
> 

Regardless of the 'four different major numbers for SCSI devices',
nobody claimed the solution was to have a unified major.

In fact, the opposite is true: userspace should not care at all about
major/minor.  Userspace should care about the semantics of the available
device nodes available in /dev.  With hardware, I want to _see_ the
device nodes created when I _add_ hardware.  udev handles this semantic
very well.  Where it fails is solely in the added devfs semantic of
modprobing on lookups of non-existing device nodes.  _This_ is the case
where some form of trapping would help very much.

For the time being though, I'm more than happy doing "echo tun >>
/etc/modules".

> 	Secondly, you are now describing what I suspect would be
> programmer-weeks if not months of development, integration,
> documentation and other migration support, all for a system
> that would make it harder for a user program to match devices
> to hardware.  So, you are comparing apples to oranges if you want
> to compare existing patches to a redefinition of major device numbers.
> 
> 	In comparison, my smaller and more modular (not as in "kernel
> module") devfs and lookup trapping mechanism makes it easier to do
> further improvements.  So, it's likely that a similar effor to the
> kind you describe could result in a much better system if one
> started with devfs and lookup trapping (for example, one could
> get modules to export their default /dev mappings statically, something
> I was going to mention in that response to your first posting that I
> should finally clean up and send).
> 
> 
>>and furthermore that it's because devfs is expected to do better naming.
> 
> 
>>(Technically, you could set up 
>>devfs so that the device special file name is as meaningless as it is with 
>>classic mknod, and then it would be as easy to do autoload.  But that 
>>wouldn't really be in the spirit of devfs).
> 
> 
> 	"is expected to" and "spirit of devfs" are your own psychological
> problems impeding your objectivity in technical evaluation.  A double
> standard will not result in a clearer cost / benefit comparison.
> 
> 	What it boils down to is this, you described some scenarios.
> In the realistic interpretation of those scenarios, lookup trapping
> can be somewhat helpful.  Interpreting those scenarios to be just the
> narrow case of where it assumed that the first CD-ROM drive is a scsi
> drive (an assumption most distrubtions cannot make) and where the
> function of major device numbers has been substantially changed
> would results in a special case where it might be worth the kernel
> memory savings of not using compiling in lookup trapping if you're
> not going to do anything else that would benefit from it.
> 
> 	So, realistically, it seems to me that including lookup
> trapping and devfs is potentially useful in common enough cases (for
> example, general Linux distributions) that it should be worth
> integrating into the kernel as an option.
> 
>                     __     ______________
> Adam J. Richter        \ /
> adam@yggdrasil.com      | g g d r a s i l
> -
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


- --
Mike Waychison
Sun Microsystems, Inc.
1 (650) 352-5299 voice
1 (416) 202-8336 voice

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE:  The opinions expressed in this email are held by me,
and may not represent the views of Sun Microsystems, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBmlApdQs4kOxk3/MRAmkSAJwOoJYgWSIBzi6Gls4EwT/L/pRhfQCfWBGJ
tCIW8tmsYVQCkqtv4Kz/g6Y=
=s84Q
-----END PGP SIGNATURE-----