[linux-dvb] Re: More than 4 DVB cards - again

[Holger Waechtler <holger@qanu.de>]

Michael Hunold wrote:
> Hello Irek,
>
> On 06/25/04 08:56, Irek Defee wrote:
>
> > It is strange that this issue has been downgraded comparing to kernel
> > 2.4. For me it’s a huge factor not to upgrade to 2.6:). 
>
> The "problem" is that devfs in 2.4 has the "feature" that a device node 
> is not tightly coupled to a major/minor pair. So if you select 
> devfs-only support for DVB, then you can register as many adapters as 
> you want.
>
> This feature of devfs has been considered to be broken,  so in 2.6 this
> has been removed.
not exactly correct, you can still let the kernel automatically generate 
free major/minor pairs by passing major 0 to the registration routine.


> Because of this, we now only have 1 major and 256 
> minor numbers, limiting the number of DVB adapters with our current 
> numbering scheme to 4 adapters.
wrong, too.

well -- the problem is that it's not possible to set the private data 
field in the file struct from the registration function anymore.

Thus you need to implement the dirty major/minor -> private_data 
matching table and look up there. In order to do so you have to know the 
major/minor pair in advance and can't let the kernel allocate them 
automatically.

Basically it's the usual problem that the guy who 'cleaned up' the 
source tree did not really knew what he's doing and it's not always that 
easy to communicate with NERDs when you encounter the problem a while 
later and want to tell his work causes some -- ermm... -- troubles?


> So this is not the fault of the DVB developers.
:) not of all of them...


> > But I would suggest to developers to  take this into account and provide
> > direct plug-and-play support for more than 4 cards. 6 PCI slots is the
> > maximum amount in PC motherboards which also have on-board network
> > adapter. Thus, it is natural to think that high-end installations
> > may include 6 cards. Then, there are also more exotic server boards
> > with several PCI buses and they could take more than 6 cards which
> > could also be considered.    
>
> There are several possible solutions:
> 1) dev_t in 2.6 has now 32 bit (12 bit for the major and 20 bit for the 
> minor number). See http://lwn.net/Articles/49684/. If we use this, users 
> need to have an up-to-date glibc probably, at least they need a new 
> mknod to create the device nodes properly.
this would mean changing the public API due to major/minor reallocation 
and would require an entirely new API version, so that's probably better 
left for v4.

> 2) Re-organize the device numbering, so that more adapters fit into 256 
> minor numbers. This would require non-devfs users to re-create their 
> device nodes and would probably confuse many users.
dito.

> 3) Allocate another major number and handle adapters 5-8 there.
sounds like a dirty hack and may introduce another couple of some 
hundret lines of hardly readable code in the dvbdev.[hc] files which are 
basically obsolete and don't do anything more than working around design 
flaws in the public device allocation APIs.

What about another try to push the fs guys, most namely probably 
Christoph Hellwig, to reintroduce a convenient way to set the private 
file struct pointer at registration time using a proper API again?

Holger



btw: the DVB driver is still using major 250 from the 240-254 
LOCAL/EXPERIMENTAL USE area (/usr/src/linux/Documentation/devices.txt), 
so all the major/minor discussion is kind of bogus and meaningless - we 
assumed those days that all this major/minor lookup crap can vanish and 
2.6 would get a clean and proper fs API rewrite instead of just 
crippling the 2.4 one and thus did not cared about requesting an 
'officially allocated major number'...

unfortunally the fact that this numbering scheme has been used for such 
a long time would cause all DVB users out there to manually fix up their 
device nodes at the next kernel update when this changes and they can't 
easily switch between different kernel versions anymore...

And then there is still the question why thousands of users should get 
forced to fix up their working systems manually just because some 
'maintainers' are not able to confess their wrong decisions and revise them.