fact #1:
SCSI devices do not currently have a one-to-one mapping like EIDE does. I
cannot rely on sda still being sda when a new device is added. dev_fs is
the _ONLY_ solution that has working code behind it today.
fact #2:
dev_fs provides a mechanism so that I can still use the sda name if I
choose to.
fact #2:
if the SCSI layer had a one-to-one mapping like EIDE does, then a
_portion_ of the problem that dev_fs solves would be negated, but only a
portion of it. dev_fs also provides solutions for USB, hot plug
devices, etc. Again dev_fs is the _ONLY_ solution that has working code
behind it today.
fact #3:
dev_fs is _OPTIONAL_. if you don't want it, don't use it. period.
Now, hopefully the only part of this message that is opinion:
dev_fs appears to show the difference between those who deal mainly with
IDE, serial and floppy devices that have a _static_ namespace and are not
hot swapable, and those who deal mainly with large SCSI installations and
hot swap devices. (and yes, there are exceptions to both of those
statements, based on personal the preferences of the authors.)
Many of us who do deal with the latter have embraced dev_fs a a "good
thing(tm)". Many who do not deal with IDE and hot plug (pcmcia excluded)
do not share this excitement because they ahve had a static namespace from
the start. Others have learned to deal with the quirks of the Linux SCSI
device naming in various ways and have accepted it.
That may be about to change.
Depending on how USB is implemented under Linux, it may require a dynamic
namespace that dev_fs can provide. Note that I did _not_ say that _only_
dev_fs can provide this, but that it _can_. Currently, however, it is the
_only_ solution that does provide this.
Now, when 2.2 is released I expect there to be at least a calendar year or
more before the next stable kernel comes along. A better way may be found
by then that will replace dev_fs, just like ipchains replaced ipfwadm. I
didn't hear any screams of pain when this happened, and it required not
just a different way of thinking, but a different set of tools to us.
Similarly, dev_fs may provide the groundwork for the next "great thing",
perhaps the idea that Ted came up with re: volume names (which being a
former NetWare admin *does* appeal to me greatly). But the simple fact is
that dev_fs is here today, Ted's idea is not.
Please, there is a great deal of intellegince on this list, let's use it
for rational discussion, not flaming. There have been some concerns
brought up about dev_fs:
* memory consumption
* setup/teardown on boot/reboot
* is it necessary for devices with static namespaces? (ide,floppy,serial)
And perhaps one or two more that I've forgotten. Can we focus the
discussion on the technical merits of dev_fs and the technical drawbacks?
I believe the spirit of Linux is to do what is technically correct. I
believe that the concept of dev_fs has alot of technical merit, and that
any reservations based on the above concerns can be addressed to everyones
satisfaction, but that will only happen when logical rational discussion
occurs, not flame wars and not name calling.
Sorry for the length of this, but I believe this to be a very important
issue and would like to see the discussion get back to the core issues.
Andrew
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Andrew Anderson http://amelia.db.erau.edu/~andrew/
if(!(family_tree=fork())){redneck=TRUE;}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html