Hi list,
since the mentioned driver interfaces with the drivers/ieee1394
subsystem, I had a brief look at it today. There is a number of
stylistic issues and kernel API issues to work on, like
- use of a semaphore,
- struct types with bitfields for what appears to be on-the-wire data,
- camel case names,
- "#define BYTE unsigned char" and friends,
- stale duplicated code like "BUG_ON(in_interrupt())" or all
references to ohci1394 which seem unnecessary,
- homebrewed down_timeout,
- comment style not as in linux kernel.
So there is a number of small things that even people who don't have
respective hardware _could_ work on. But read on before you start
cleaning those up:
A bigger issue is the interfacing with drivers/ieee1394. As most of the
subscribers probably know, Linux now contains two IEEE 1394 stacks which
are entirely independent of each other. The newer one is
drivers/firewire and is meant to replace drivers/ieee1394 once it is
stable enough and has all the necessary features.
This means that firesat needs to be ported to the new stack eventually.
The question remains if that should be done before mainline submission
or after. I tend to the latter, even if merely because ieee1394 and
firewire subsystem maintenance and development is chronically
under-staffed, hence bandwidth for mentoring and review of new additions
like firesat is low. (It looks like an IEC 61883 implementation, one of
the FireWire areas I myself am less familiar with. Therefore I also
didn't pressure Ben to look into the firewire stack when he discussed
ieee1394 API issues on linux1394-devel.)
So, because of the need to port it to a different in-kernel API
eventually, current firesat's ieee1394 interfacing code does not have to
be brought to perfection anymore. Instead, work on it should either
have the goal of later gradual movement to the firewire stack (i.e. make
it possible to build firesat for ieee1394 or for firewire) _or_ should
port it over to firewire right away (something which obviously nobody
else wanted to undertake so far).
I suppose which way to proceed depends a lot on what is going on at the
DVB side and on who is picking up the work.
--
Stefan Richter
-=====-==--- -==- -===-
http://arcgraph.de/sr/
