>>- partly reintroduced the DVB_DEVFS_ONLY switch, which was previously
>>wiped out by Alan Cox: if enabled, some really obscure code is not
>>compiled into the kernel that is necessary to xxx
>
>
> No, this is wrong. I did remove it not Alan Cox and I removed it because
> kernel 2.5/2.6 should not behave differently whether devfs is used or
> not except nodes showing up in devfs.
The code does not behave differently. If DVB_DEVFS_ONLY is set, then the
old chardev register interface is omitted.
We use the dvb subsystem on set-top-boxes where devfs is present only.
The DVB_DEVFS_ONLY switch then lets us save some bytes and skips the
"map-minor-to-actual-device" function stuff.
>>- /* fixme: is this correct? */
>>- try_module_get(THIS_MODULE);
>>+
>
>
> Just removing this makes the code even more incorrect. You need to
> add a ->owner member and call try_module_get on it before calling into
> the module (and handle the return value..)
There is a functional dependency between the dvb-core and the actual dvb
driver. So there is no need to increase the module count of the dvb-core
if a new adapter is registered IMHO, because you cannot unload the
dvb-core before the driver anyway.
>>-typedef struct dmxdev_dvr_s {
>>+typedef struct dmxdev_dvr {
>> int state;
>>- struct dmxdev_s *dev;
>>+ struct dmxdev *dev;
>> dmxdev_buffer_t buffer;
>> } dmxdev_dvr_t;
>
>
> Once you rename everything you can nuke the typedef crap aswel..
Thanks, added to the TODO list.
CU
Michael.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/