linux-kernel - Re: new driver staged in linux1394-2.6.git

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Thu, 21 Aug 2008 00:28:02 +0200
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	David Moore <dcm@....EDU>
CC:	Greg KH <greg@...ah.com>, v4l-dvb-maintainer@...uxtv.org,
	linux1394-devel@...ts.sourceforge.net, linux-kernel@...r.kernel.org
Subject: Re: new driver staged in linux1394-2.6.git

David Moore wrote:
> On Wed, 2008-08-20 at 22:41 +0200, Stefan Richter wrote:
>> Greg KH wrote:
>>> This assumes that it will not be dropped by you :)
>> I'll carry it until mainline merge, unless bigger subsystem changes 
>> happen on the v4l-dbv front that make it necessary to move it to their repo.
> 
> If I understand correctly, this driver is based on the legacy ieee1394
> subsystem.  I'm curious, is there a plan to migrate it to juju, where
> presumably it could be a lot cleaner and might not even have to live in
> the kernel at all (except for the need for some sort of dvb loopback
> device which might not yet exist)?

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 latency userspace driver; I don't know how well stock kernels 
currently do.
-- 
Stefan Richter
-=====-==--- =--- =-=--
http://arcgraph.de/sr/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/