Johannes Stezenbach <js@xxxxxxxxxxx> writes: > > Whats the status on the cx22702 driver btw.? > > Well, you know my position. If you send me what I asked for > it would be in CVS immediately. Now, I tried to get Michael > and Andrew to back up either your or my position so we > could reach a decision, but it seems they are not willing > to say something. Michael askd me to send him the files, I did, but never heared back from him since. Maybe he is just busy, I've also havn't seen anything on the list from him recently. But I through I'll ask for the status while I'm submitting patches anyway ... > Just in case you forgot: My problem is not that your code sucks, but > simply that it is different from all other frontend drivers. Well, the _interface_ to the other modules (drivers + dvb core) and is exactly the same now. The only minor difference are new entries in the cx22702_config struct due to the switchover to dvb-pll. The _internals_ are slightly different, yes. I still think that it is better register within the i2c core. But whenever I do or not doesn't change the module behavior at all. IMHO it's just nicer for some things, for example for being visible in sysfs. Or -- just found that today -- not needing ugly hacks for firmware loading like the one in tda1004x.c currently. You could just use i2c_client->dev and call request_firmware() directly. > I see maintainability issues, Just because I'm registering my i2c clients within the i2c core? Thats the _only_ difference remaining. > but also social problems with the people who were involved in the > discussions that led to the current frontend design. The discussion was about the frontend _interface_ design, i.e. how the modules talk to each other, how they are configured and so on. I can't remember having discussed any strict coding guidelines for the driver internals. My cx22702 module has the same interface like all others, I think I've explained that already. At least I've tried ... > An easy way out: You could get a CVS account and commit it > yourself. That way you would take direct responsibility for > your deeds. I don't see how that makes a difference. Either I care about that baby or I don't, whenever I do by mailing patches or by commiting myself doesn't really matter I think. Well, committing directly would bypass peer review, I don't think that is good (look at the mt352 discussion for example ...), you guys know the dvb internals much better than I do. Gerd -- #define printk(args...) fprintf(stderr, ## args)
