Kenneth Aafl?y writes: > 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. If you are going to do that at least just move the OSD to 2 instead of moving all the others. This way nothing changes for somebody with one card without OSD. This would of course still cause trouble for many Nexus card users with OSD. > However how often does one come across adapters with multiple frontends? More often than before ... > 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? How do you want to handle the other devices and the association between them and frontends? Not every frontend needs to have its own demux (if it is in hardware) and adapter0/frontend and adapter1/frontend might have to share one. Ralph