Hello Christoph, Linus,
>>The code does not behave differently. If DVB_DEVFS_ONLY is set, then the
>>old chardev register interface is omitted.
> Which is a different behaviour, now you can't create a device node
> manually anymor.
I won't insist on keeping code that I haven't written. My only point is
that we use the code in set-top-boxes, where every byte is valuable. But
I suspect that there are numerous other places where we could safe
bytes... 8-)
> Also note that the feature you rely on here (devfs
> presetting file->private_data) will go away in the next round of
> patches,
> see Al Viro's patchit for a generic replacement that works with or
> without devfs.
Ok.
>>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.
> Okay, you're right I should have read more of the code to get the global
> picture. You still wan't an owner field for at least struct dvb_device
> device, though - but the try_module_get must go into dvb_generic_open
> and maybe in more other places where you use the "backend" modules.
I don't get that, sorry. The backend modules have functional
dependencies and register/deregister upon loading/unloading. There is
never a call from the dvb-core to the backend modules. Do I really need
an owner field then?
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/
This archive was generated by hypermail 2b29 : Wed May 07 2003 - 22:00:31 EST