Peter Memishian wrote:
> > Indeed, I'd say what we have right now is also a bug. I can understand
> > (based on inherent limits in the dev_t) why a given device could only have
> > a certain number of open instances, but the only global limit I'd expect
> > on the number of open instances would be memory.
>
> Yes, its the 32-bit dev_t that creates the problem. (18 bit minor numbers.)
I'm confused by that answer. I would expect the 32-bit dev_t to be the
limit on the number of simultaneous opens on a given self-cloning device.
I would not expect it to be the limit on the number of simultaneous opens
of all network devices on the system.
For GLDv3, there is a single allocation that assumes all minor numbers
are shared across all devices. So all network devices share the same 18
bit minor space. (This isn't precisely true... the lower 1000 minor
numbers are not part of this pool, and are not shared... these are the
numbers assigned for advertising nodes in the device tree, and for the
DLPI style 2 node.)
Note that (at least before the days of Clearview) non-GLDv3 devices
don't draw from the same pool.
I've always felt that its unfortunate that all GLDv3 devices draw from
this global pool for their dynamic opens, and I have some ideas for how
to fix that, but I wasn't planning on tackling that problem right now.
In a system with a lhuge number of vnics and zones, eliminating the
global pool really isn't going to help all that much because most of the
minors are going to be allocated against the same driver (vnic).
Remember also that the dev_t's even in a well designed driver without
the GLDv3 bug are always shared for the same major number (i.e. all
instances of a given driver). Each *instance* does not get its own pool
dev_t's.
- Garrett
_______________________________________________
networking-discuss mailing list
[email protected]
