[linux-dvb] Re: Bug with frontend thread

[Andrew de Quincey <adq_dvb@lidskialf.net>]

On Friday 17 Dec 2004 21:16, Michael Hunold wrote:
> Hi,
>
> On 17.12.2004 02:33, Andrew de Quincey wrote:
> > This looks to be because the internal data structures for the frontend
> > are now in the public data structure, dvb_frontend - some of them are
> > being initalised, but theres no guarantee all of them are.
>
> I think this is due to my patch. I merged the "private" structure
> (dvb_frontend_data) into the global structure (dvb_frontend), which is
> used by the frontend drivers. In that turn I removed the global frontend
> lists alltogether.
>
> > Shouldn't the private stuff be, well private? I can see why it was moved
> > though, because then we can do away with that big internal list of
> > frontends.
>
> IMO there is no reason for that "private" data. I guess I have worked
> too much on the V4 API lately, where we tried to avoid this kind of
> separation at all places, because it only bloats the internal API.
>
> I admit that it's now harder to tell which data should be used by which
> parts, but it's an internal API and you should know what you are
> doing... ;-)
>
> > If no one minds, I'm going to change struct dvb_frontend to just have a
> > void* pointing to the private data structure - dvb_register_frontend()/
> > dvb_unregister_frontend() will be responsible for maintaining this data
> > structure. Oh - and I'll move the private data structure definition back
> > into dvb_frontend.c.
>
> I don't think that's a good idea. "dvb_frontend.h" is already a private,
> kernel header file, that's only used by the internal DVB driver API. So
> there is no need to hide the stuff that was in struct dvb_frontend_data
> before from the frontend drivers. In kernel-space, this separation via a
> void* pointer doesn't bring any profits. Or does it?

Its what we ended up doing in the demodulator drivers so that demod internal 
data wasn't exposed. After much persuasion by Gerd :), I decided it was a 
good idea not to expose the internals. What do you think?

If we hid the private stuff as above, we could then just memset() the entire 
private structure during initialisation. 

As it currently is, we'll have to have loads of individual lines clearing out 
each private field individually - we can't just memset() the whole thing, as 
it already contains data initialised by the card driver.