Felix Domke wrote: >Manu Abraham wrote: > > >>Initially we thought it would be best to do it in userspace, but the >>addition of ioctls to the API, made that thought a bit diminished .. >>This is applicable for most of the frontends though .. >> >> >Hm, let's ask the other way around: > >What is the advantage of doing this in kernelspace? > >Can we: > - guarantee that all frontends behave the same, so we had a real, >device independent, API? > > More or less that's the idea. That was Andrew's proposal as well. But utilize the Hardware specific features too. > - define an API which covers all possibilities (input ranges, ...), so >we don't need additional, private IOCTLs? > > That is one of the thoughts, that i had been discussing with Andrew, such that we don't use IOCTL's privately, but rather in a more generic way. > - pass results in a good way to the userspace? For example, a blocking >read of a "frontend parameter" structure which returns new found >transponders? Is this flexible enough? > > I am not yet through with this. But the idea is to manintain compatibility as much as possible. But saying compatibility for devices which doesn't have those features doesn't make sense, but a common interface for all these specific devices in some way or the other. Eventhough this would be considered "experimental" for a while. What i suggested to Andrew was that probably we can have a branch in CVS to do this experimental stuff. This is not limited to the mb86a15 alone , but also to chips like the STV0299 and others as well. I think it might need a bit of experiments though, to get things straight. The current way i started up with is without all the algo's but a generic way of doing it for the moment. Maybe some suggestions would be helpful, i will get the code out as soon as it is almost done, so that i can get some feedback on this .. ? Manu
