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: http://linux.bkbits.net:8080/linux-2.6/hist/include/linux/kdev_t.h?nav=index.html|src/.|src/include|src/include/linux 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.. Kenneth -------------- 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
