On Mon, Apr 17, 2000, Richard Gooch <rgooch@xxxxxxxxxxxxxxx> wrote:
> Johannes Erdfelt writes:
> > Right now? major/minor issues.
> >
> > We don't have enough.
> >
> > The nodes I create are either too sparse or too many.
>
> Is it possible to have the USB subsystem pick an unused minor, pass
> that over a new usbd protocol, and have the usbd daemon mknod(2) using
> that number? So unless you have >256 USB "interfaces" hooked in at
> once, you'll be OK.
If you have one node per interface. The current patch I have is one node per
endpoint. An endpoint is a further set of pipes to talk to the device.
On the average device, there are 4 or 5 endpoints. Some have as little
as 2. Some have as many as a couple of dozen.
My development machine, which admitedly has more devices than the average
person, would overflow 256 minors.
Plus, there are different types of nodes. One which is for the main device,
to get all of the cached descriptors for the device. (Some devices don't
like being asked for the descriptors after being enumerated)
It gets further complicated (which minor points what kind of node on which
device, etc).
> > No one seems interested in actually following through in increasing
> > the major/minor for 2.4 and we need this working for 2.4.
>
> IIRC, a bigger dev_t is a 2.5 issue.
Could be. I do remember seeing discussions a while ago, I do not know the
current status, but this sounds accurate from people's attitudes towards
doing it.
> > Even increasing the major/minor would be a band-aid solution.
>
> In what way?
Run out of numbers, make it bigger?
I just have a fundamental problem with major/minor numbers. It's very
inefficient method of communicating to the kernel which device you want.
They are ill suited for today's OS' which handle Hot Swap devices. Back when
Unix was designed and created, you didn't have Hot Swap devices so this wasn't
a problem.
Unfortunately for Unix, times change. Thankfully, we can change with it.
Anything which increases major/minors, or dynamically assigned major/minors
increases the complexity of the code needed to determine which minor goes to
which device, and what part of the device.
devfs centralizes that and keeps me, the subsystem, out of it. This is
definately attractive to the lazy part of me :)
I just don't see why we should pass a static number/cookie from the kernel
to userspace. It's taking a step backwards. We already have a standard and
useful interface to select the device we want, open(2).
I think it's biggest piece of legacy baggage holding us back. Anything which
uses major/minors and/or dynamically assigns them is band aid solution.
> > I'm much more content using a solution which is here today and IMHO
> > a good solution.
>
> I agree that devfs is overall cleaner:-) I'm just playing devil's
> advocate here so that the pro-devfs argument can be refined and
> sharpened.
I understand. I'm just sick and tired of all of the arguments over it. So
many people feel that devfs is not the correct soltion, but they never offer
up what the correct solution may be.
It works, with minimal overhead. I never expected to get extra features
for free, but I think the ability to actually cope with Hot Swap
devices at all, more than makes up for any extra minimal amount of
memory used.
Plus, getting rid of legacy baggage like major/minor is a net win IMO.
No more worrying about changes in major/minor numbers. No more worrying about
the code to convert minors into devices and what part of the devices.
JE
|