> Yes, I'm working around the current 16 device limit issue. Yes I push
> that limit out to 256, but that's a workable limit for today. If I
I agree. Unless you go for something more radical, you have gone
to the limit.
> wanted to abolish minor numbers all together, I could get an unlimited
> number of devices, but this tiny little patch does not do that, nor
> attempt to do that. It is working within today's system.
What I do question is whether it is worth the trouble.
You get a lot of trouble, like a completly new, unproven,
supporting infrastructure for relatively little gain.
> If you have a better solution for the original (16 devices) problem,
> please let me know.
Without devfs ? I see no way.
> Ah, good point. How's the patch attached to this message? It documents
> the different return values, and shows how to handle the return values
> properly.
That should do it :-)
> > > Remember, devfs does not remove our need for minor numbers. It just
> >
> > But it handles them dynamically. Which is the best you can do
> > with the present architecture. I repeat, a dynamic minor makes
> > the concept of a minor meaningless and reduces it to feature
> > of backwards compatibility.
>
> devfs does not handle the existing USB numbers dynamically. Or am I
> missing something? I still see the 16 devices limitation in the USB
> core.
Yes, you are right. I thought about this this morning.
To me the obvious solution would have been to use devfs
and request a dynamic _major_ for every driver that implements
a char device.
In fact would you like an API change to move the devfs stuff into
usbcore ? I see no reason every driver registers itself with devfs.
> > > imposes a naming scheme on the kernel for the major/minor pairs that
> > > happen to be present in the system at a moment in time. This patch
> > > is still needed to extend our usage of the USB minor range.
> >
> > If you did use devfs to the extent it can be used, you could have 256
> > devices of all types.
>
> Please explain. How could this be done within today's framework? And
> remember, 99.9% of all machines do not use devfs today :) This patch
> solves a real problem for all machines, without requiring people to use
> devfs.
It requires them to use something new totally unproven.
I somehow fail to see the advantage ;-)
Regards
Oliver
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
