Re: [PATCH 0/3] New firewire stack

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Stefan Richter wrote:
...
Another point is the various streaming drivers.  There used to be 5 different
userspace streaming APIs in the linux1394: raw1394, video1394, amdtp, dv1394
and rawiso.  Recently, amdtp (audio streaming) has been removed, since with
the rawiso interface, this can be done in userspace.  However the remaining 4
interfaces have slightly disjoint feature sets and can't really be phased out.

The old iso API of (lib)raw1394 has been marked deprecated and
undocumented in libraw1394's documentation for some time, and will go
away in 2007.

Dv1394 might go away in 2007 too if there is enough effort to move
high-profile users over to rawiso a.k.a. the current iso API of
(lib)raw1394.

I suppose video1394 might get a viable migration path with your new
driver, if you and interested developers put effort into development
(and help with deployment) of a proper replacement.

As discussed on linux1394-devel, it may be possible to do a thin video1394 compatibility driver for this one, but since the biggest user of this interface is libdc1394, it is probably better to just write a new iso streaming backend for this library. libdc1394 already supports different streaming backends. For non-libdc1394 users of video1394, the interface I'm providing is very close to the video1394 ioctl interface, so porting should be easy enough.

 In the long run, supporting 4 different interfaces that does almost the same
thing isn't feasible.  The streaming interface in my new stack (only
transmission implemented at this point) can replace all of these interfaces.

You have to look at the matter not only from the POV of API design but
also of deployment and support.

My POV here *is* about deployment and support, but from the kernel side of things. If you commit yourself to long time support for the firewire stack, would you prefer 4 slightly different streaming drivers with different user space interfaces, or just one userspace driver with one userspace interface, that enables the 4 different types of streaming to be done in userspace? The design of the streaming interfaces have been focused on enabling all these ad-hoc, in-kernel drivers to move to userspace, to make it feasible to actually support the stack.

Kristian
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux