Yes; these are good points. I planned on commenting on exactly these
points when we (the two or so people who currently work on the driver
and I) have it cleaned up so that we can post code for pre-merge review.
Anyway, this is what I think:
Indeed, this driver interfaces with the ieee1394 stack. That's because
it lived out of tree for actually a few years already. And of course it
needs to be ported over to the firewire stack. But in my opinion, this
port is easier to do _after_ the driver came into mainline. The
firewire stack is still evolving, hence driver development on top of it
outside of mainline would involve avoidable churn.
As to whether this should or could be a userland driver: This is an
AV/C driver, hence taking this into the kernel means that we partially
duplicate the already existing userland library code in this area, which
saw a lot of development and usage with a considerable range of AV/C
devices. It also means that we go against what has been the trend so
far, i.e. that AV/C related code is removed from the kernel (amdtp and
cmp long gone, dv1394 bitrotting). So from the FireWire side,
everything speaks against a kernel implementation of this driver. But
from the DVB side, there is one good reason to do it in-kernel: That
way it can interface with all existing DVB related userland just like
PCI DVB cards and USB DVB cards.
A DVB loopback driver does not exist to my knowledge, nor am I aware of
solid plans in this direction. v4l-dvb people, please correct me if I
missed something.
Is there interest to come up with a loopback driver for other DVB device
types? I presume it wouldn't make a lot of sense for PCI devices, and I
understood that it is not feasible for USB devices for the time being.
In the past, there were also latency issues speaking against a userland
implementation of firesat/firedtv. These issues may be only partly
relevant today, or maybe not at all. An -rt kernel would surely allow
for a low ...
