Roland Mainz wrote:
Garrett D'Amore wrote:
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.)
Umpf... remeber the 640k barrier ? Or |ARG_MAX| (which is haunting shell
users since the dawn of Unix) ? =:-)
... the idea is to allow both shrinking or enlarging the minor numbers
on demand without requiring that someone has to recompile a driver (see
below) ...
For the most part, drivers won't care. The only ones that will are the
ones that are very very special.
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.)
Ok... but is this part of an API which may be used by 3rd party driver
developers somehow ?
Only NIC driver developers, and only those that have to "share" minor
number spaces between GLDv3 and other things. The vast vast majority of
drivers never even need to know about this.
Right now none of this is even accessible to 3rd party drivers. The
related interfaces are all consolidation private anyway.
- Garrett
----
Bye,
Roland
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
