Roland Mainz wrote:
Darren Reed wrote:
Garrett D'Amore wrote:
...
We'd like to propose that the GLDv3 change to start numbering minor
numbers
at 10001, to leave more room for other kinds of minor numbers.
Rather than use a decimal range, does reserving n low order bits seem
worthwhile? Decimal is human friendly... how often does a human
need to see the minor number?
IMO it would be better to follow the design of the POSIX realtime
signals (SIGRT*) - they use functions to determinate the
minimum/maxmimum signal values instead of using fixed ones...
... the same could be done here: Add a new system _tuneable_ which
defines the lower/upper bounds for the minor numbers (with a guranteed
amount of "upper-lower > minimum").
That's IMO overdesigning the problem. The allocation of minor numbers is
pretty device-specific, in most situations, and there is little reason
to need more than 1000 or even 1000 minor numbers for a device, *except*
for cloneable device opens. (And those would be the "rest" of the opens.)
Note that NBITSMINOR == 18. So for all intents and purposes we'd be
supporting a *huge* number of clone opens. (Each clone represents an
open file. That would correspond to ~250,000 concurrent opens against
NIC drivers. I don't see that number needing to increase any time soon.)
Note also that the number isn't really exposed to anything except
drivers. (And in this, really only NIC drivers.)
- Garrett
----
Bye,
Roland
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
