Subject: UFS inodes as device descriptors
To: Paul A Vixie <email@example.com>
From: Lucio de Re <firstname.lastname@example.org>
Date: 01/14/1998 06:49:34
This entire discussion strikes me as a sad instance of "backward
compatibility at all costs". Whereas I'm beginning to understand the
need to provide NFS clients with a consistent view, from the server
side, of what is in fact the local configuration <sigh!>, I also think
that the legacy of something totally alien in the UFS is going to be a
high price to pay.
I would far rather see a devfs that serves the local needs properly,
possibly mapped, where necessary, to an exportable entity in a client
I also have my doubts as to whether constraining the format of dev_t
entries to a fixed length numeric value is necessary. Using an opaque
structure and possibly an index into a table of such structures with
appropriate tools to represent them externally (as in the case of the
much vaunted "ls -l") should not really impact kernel performance (it
may create some bloat, I admit, but perhaps device management will
shrink in return) and may slow down "ls -l" a touch, but I doubt that
it will bring it down to intolerable drag.
Fixed length of such structures may be an asset, in which case we may
want to think of 64 bits plus a descriptor, but I fail to see why any
application other than the associated device driver needs to know how
the various portions in the structure are utilised.
And in such instance, a 16-bit (by all means make it 32) index is all
the (hopefully virtual) filesystem needs to return.
Far fetched? Possibly. But I agree with the sentiment that device
inodes were a compromise that is no longer sustainable.
Lucio de Re (email@example.com)
Disclaimer: I'm working at getting my opinions to agree with me.