Messages in this thread |  | | Date | Wed, 28 Mar 2001 23:09:53 +0200 | From | Martin Dalecki <> | Subject | Re: Larger dev_t |
| |
"H. Peter Anvin" wrote: > > Alan Cox wrote: > > > > > Another example: all the stupid pseudo-SCSI drivers that got their own > > > major numbers, and wanted their very own names in /dev. They are BAD for > > > the user. Install-scripts etc used to be able to just test /dev/hd[a-d] > > > and /dev/sd[0-x] and they'd get all the disks. Deficiencies in the SCSI > > > > Sorry here I have to disagree. This is _policy_ and does not belong in the > > kernel. I can call them all /dev/hdfoo or /dev/disc/blah regardless of > > major/minor encoding. If you dont mind kernel based policy then devfs > > with /dev/disc already sorts this out nicely. > > > > IMHO more procfs crud is also not the answer. procfs is already poorly > > managed with arbitary and semi-random namespace. Its a beautiful example of > > why adhoc naming is as broken as random dev_t allocations. Maybe Al Viro's > > per device file systems solve that. > > > > In some ways, they make matters worse -- now you have to effectively keep > a device list in /etc/fstab. Not exactly user friendly. > > devfs -- in the abstract -- really isn't that bad of an idea; after all,
Devfs is from a desing point of view the duplication for the bad /proc design for devices. If you need a good design for general device handling with names - network interfaces are the thing too look at. mount() should be more like a select()... accept()! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |