On Sun, 9 Jul 2000, Chuck Silvers wrote:

> On Fri, Jul 07, 2000 at 01:33:26PM -0700, Bill Studenmund wrote:
> > On Thu, 6 Jul 2000, Chuck Silvers wrote:
> > 
> > > this sounds like a fine thing to me.  making devices less tied to
> > > dev_t internally in the kernel is a good thing, since dev_t is really
> > > just a kludgy way of representing a device in a filesystem.
> > 
> > Uhm, how is it kludgy? Hasn't it been that all unix has needed to
> > represent/specify a device has been is the dev_t? I mean, hasn't it been
> > that that's been the canonical specifier? :-) If dev_t is the canonical
> > specifier, how is using dev_t in the kernle a kludge? :-)
> 
> it's not dev_t in the kernel that I'm complaining about, it's dev_t in
> general as a way to uniquely identify a device.  I mean, originally dev_t
> was a 16-bit value, and expanding it to 32 bits was a source of much
> discontent when that happened in netbsd a while back.  your example of
> changing the number of paritions in a scsi device is another case where
> the limitations of dev_t cause strife.  some devices also chop up the
> minor number in funny ways, like tapes have no-rewind bits, etc.
> the whole thing just seems very clunky.
> 
> however, since dev_t is part of various standard unix APIs, we're stuck
> with it in interfaces.  but internally we can try to minimize the impact.

dev_t may be part of various unix APIs, but the interpretation of dev_t,
especially the interpretation of the minor number, is not.  

If we has some other method of associating a vnode with a device driver's
concept of a device instance we could dynamically allocate dev_t values
assigned to vnodes.

Were we to ever decide to go with a real devfs that's created dynamically
based on device discovery, the dev_t value could be relegated completely
to the vfs layer.

For instance, if you had a machine on a SAN with 1000s of disk and tape
devices, you wouldn't want to have a static set of device nodes to
identify all of them.  That's 1000 disks * 8 partitions * 2 (raw, block),
or 16000 device nodes and dev_t's.  You could have a scheme where the
device nodes don't really exist, rather when an open is attempted, devfs
would not attempt a lookup but pass the string directly to the device
driver, which would parse it and attempt to locate that particular device
(by WWN encoded in the filename).  The driver would instantiate the device
node and pass a pointer to it to the vfs layer which would allocate an
unused dev_t.

Eduardo Horvath