So, for a long time now Solaris has had definitions to support
NBITSMINOR == 32 in a 64-bit environment. (Allowing a 64-bit dev_t to
be constructed.) However, I've always assumed that this was rather
pointless since we have to support 32-bit userland programs.
But it occurs to me that one could reasonably have larger dev_t's in
some systems, and I'd like to hear thoughts:
1) clone nodes -- that is those systems that do things like open() a
style 2 node, or use the clone device, could easily construct a minor_t
that is larger than 32-bits. This would alleviate some of the
limitations on drivers that create lots of ephemeral dev_t's.
2) nodes that aren't normally accessed by administrative tools using a
dev_t -- particularly nodes for things like streams end points, etc.
(anything that doesn't house a filesystem!). Since mknod isn't normally
used to access the node, it won't matter that it can't be represented by
32-bit tools.
My worry is that some tools which might e.g. try fstat() or somesuch
would break. Certainly it seems like anything to do with block devices
should restrict itself to 32-bit dev_ts (to avoid breakage in tools that
look at the dev_t the filesystem is mounted on). But other uses seem
like they would be OK.
Am I missing something? Can ufs and zfs represent a 64-bit dev_t? (I
would *hope* that the /devices filesystem could do this!)
If I could eliminate the reliance on NBITSMINOR32 and use NBITSMINOR
instead, it might mean that for 64-bit systems using my subsystem, at
least one more artificial limit could be removed.
-- Garrett
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
