Ralph Metzler wrote:
Holger Waechtler writes:
> > IMO OSS frontends that are in the official kernel source should use
> > the official kernel facilities though.
>
> why are only closed-source driver writers free to use an elegant and
> easy-to-use API? why should we stuck to an useless API just because it
> is "OFFICIAL"?!?
>
> my definition of freedom is that everybody is free to choose the
> simplest and technically most elegant way.
>
> All this p.c.-conformity and obedience makes me just sick. Let's end
> this thread, everybody is free to write as elegant code as he likes.
This does not have anything to do with the problem at hand.
I see nowhere in the description of your API how you pass
card specific information more elegantly. You will also either have to
write extra code in the card driver and only use lower level functions
through your API or you will have to somehow pass information to the
frontend driver which tells it what to do in which case or a
combiantion of both.
The real question is to decide how to do this exactly. What I2C API is
used does not really matter that much.
I also wrote before that the only reason to use the kernel I2C API is to
use existing code for other non-DVB devices and to prevent having
duplicate code or additional locking in this case. If somebody does
not need existing I2C drivers or rewrites those he needs with
this new API, that's fine.
yes. I would avoid touching any working code -- the latest changes did
enough harm. It's time to get things as stable again as they were some
months ago and only apply slight bugfixes in the soon future.
But by no means a new-written driver should get forced to use the
kernel-i2c stuff, this would only increase the risk of new clashes like
the one we had now.