[linux-dvb] Five dvb cards linux 2.6.11 + UDEV 053

Kenneth Aafløy lists at kenneth.aafloy.net
Wed Mar 9 21:53:28 CET 2005

On Wednesday 09 March 2005 19:11, Anssi Hannula wrote:
> Johannes Stezenbach wrote:
> > On Tue, Mar 08, 2005 at 03:20:55AM +0100, gnu-braice wrote:
> > 
> >>Johannes Stezenbach wrote:
> >>
> >>>Hm, I was wrong on this one. 2.6.11 should support up to six cards.
> >>>If not, something is broken...
> >>
> >>I'll try with another kind or cards
> >>I've tried the CVS version but it didn't compile
> >>Where can I found the right nodes number in order to try to forcr them 
> >>to good values?
> > 
> > 
> > We use 64 minor numbers per card. The new code in dvbdev.c should
> > allocate minor numbers > 255 for the 5th and 6th card, but it
> > maybe it doesn't. I don't have enough hardware to test, and
> > currently don't have the time to do a simulation.
> Isn't there only 256 minor numbers?
> Or did I understand something wrong?

I did some snooping around on this, and the there is only 256 minor numbers
visible from userspace, the extra bits allocated in the kernel is for internal
use only:


I have a solution to the problem though, but it requires that the minor
device numbers are reordered a bit, and everyone without udev/devfs will
need to recreate their device nodes.

If we drop support for the DVB_DEVICE_SEC type, the type bits of the minor
number can be dropped to 3, which will free up a bit for the adapter
number, and voila, we have support for 8 cards with four frontends each.

However how often does one come across adapters with multiple frontends?

What if the notion of multiple frontends could be changed a bit, so that
if an adapter has more than one frontend it will reserve an extra adapter
for it's own use. I'm not talking about new struct adapter here, just the
adapter number itself. If this scheme was there, a user could have any
combination of 32 frontends hooked to x adapters. But at the user side
it would be visible as 32 single frontend adapters. As a bonus we
would be able to move away from the adapterX/frontendY, and use
adapterX/frontend instead.

Any problems with this scheme?

Anyways, I've attached a patch that does the first solution..

-------------- next part --------------
A non-text attachment was scrubbed...
Name: cards.patch
Type: text/x-diff
Size: 4068 bytes
Desc: not available
Url : http://www.linuxtv.org/pipermail/linux-dvb/attachments/20050309/002331ba/cards.bin

More information about the linux-dvb mailing list