In the new year, 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? > If there are timing-sensitive events, kernelspace might traditionally be more appropriate. If most of the work is with kernel driver structures, kernel might be a good place to go. Take alsa, for example. IT has the user space bits and the kernel/driver bits. > Can we: > - guarantee that all frontends behave the same, so we had a real, > device independent, API? probably not > - define an API which covers all possibilities (input ranges, ...), so > we don't need additional, private IOCTLs? > - 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? > > Felix > Without fully understanding what the new requirements are, maybe this would be a good idea for the next revision of the api (version 4 is it?) that way people will have a need to use the newer api. _J > _______________________________________________ > > linux-dvb@xxxxxxxxxxx > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb >
