Ralph Metzler wrote:
Marcel Siegert writes:
> i also did talk to manu yesterday alot, and i think his idea,
> moving frontend stuff to userspace and just implement a
> simple read/write register within the kernel, is a nice thing.
> it should be forced to become reality imho. i do know there
> will be a lot of work todo, but with having this interface, we could
> even do a migration to a different api version for those lib users,
> without having to change the client application at all.
> we were talking about some stuff to implement so that from end users
> view everything will be a stable and consistent interface.
> you may read on the irc log of #linutx from yesterday at linuxtv.org
While I agree that some of the more generic frontend stuff (probably
most of dvb_frontend.c) could be handled in user space I am still
wondering how you want to handle very card specific features/quirks
(also after reading the IRC logs) if you move all the frontend drivers
into userspace.
The user space library will not only have to know about things like
specific GPIO controls (like mentioned in IRC) but things like
necessary locking between busses of different logical frontends which
belong to the same card. This can not only be necessary for one I2C
transfer but around specific command sequences going to different devices.
Can't we use a state machine to handle this ? We don't use the RAW i2c
bus as it is, but we use another interface (which fits in the
requirements) that interfaces to the i2c bus.
This part of the state machine does exist in kernel space as well as
user space. The state machine can be included in this interface in both
kernelspace and userspace. and the relevant functions does the necessary
translation depending upon the state. In any case a semaphore is in a
way a state machine.
Some of the quirks, are basically from the bridge device, we can solve
some parts of the issues there. At present almost all frontends do
attach with an xx_attach function, and communicate through the i2c
interface. Some do use the GPIO also for handling things in between
alongwith i2c, and some even a pseudo i2c interface. anyhow i2c
communications are quite slow and do not exceed 400kHz, so this can be
really handled in userspace.
I have a link to my original idea here.
http://www.thadathil.net/dvb/msg_transfer_interface/interface_desc.txt
So, would the library have to know those details about each card!?
Yes, another one of the advantages would be that even the board
specifications, all those larger arrays can be moved out to userspace.
For this the library will even need to know PCI ID's etc. The interface
has to export information like this and more to userspace for the
library for identifying the boards etc, and even for doing a similar
attach routine also.
Looking at the large number of card database structures, another
advantage of moving things to userspace is that even cards can easily be
forced to use a specific board type as this is easier in userspace
compared to kernel. Lesser bloat in the kernel too.
The good thing would be that we can do whatever frontend operations
necessary, without any limitations.
Regards,
Manu
_______________________________________________
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
