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 
dependent format.

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 (lucio@proxima.alt.za)
Disclaimer: I'm working at getting my opinions to agree with me.