linux-kernel - Re: [PATCH 0/3] New firewire stack

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] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 06 Dec 2006 13:38:36 +0100
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	Alexander Neundorf <a.neundorf-work@....net>
CC:	ben.collins@...ntu.com, linux-kernel@...r.kernel.org,
	adobriyan@...il.com, linux1394-devel@...ts.sourceforge.net,
	krh@...hat.com
Subject: Re: [PATCH 0/3] New firewire stack

Alexander Neundorf wrote:
> Von: Stefan Richter <stefanr@...6.in-berlin.de>
>> Mainline's FireWire stack lost a lot of trust
...
> For us it's working well, with no major problems (there was a problem with
> SMP kernels and the arm mapping, but my kernel is not recent and I didn't
> find the time yet to update to current versions, so I could not report the
> bug). We have customers and it works for them.

Perhaps the fix which was released in 2.6.19 is relevant. As always, you
can get it as part of my patchkits too which are currently available for
2.6.16.x and 2.6.18(.x). I had also patchkits for 2.6.1[457].x which I
could revive on request. If need be, I would also try to assist
distributors to identify and backport specific fixes. I am currently
wondering if I should take the time to pick out a collection of fixes
for Adrian's 2.6.16.x series.

> OTOH I heard from some people who wanted to use the 1394 stack for embedded
> devices without PCI and they didn't succeed to add support for their selected
> chipset. 

The ieee1394 core currently dependends on the PCI subsystem for no
obvious reason. The fix probably consists mostly of a rather trivial
conversion from the PCI DMA mapping API to generic DMA mapping. I
actually intend to do this conversion RSN.

Another question is whether the stack-internal APIs are really fit for
non-OHCI chips. There is an unfinished low-level driver for GP2Lynx
which worked to some degree at some point, but other than that I don't
remember positive or negative reports in this department. Maybe proper
documentation of the stack-internal APIs would already help embedded
developers a lot. Furthermore, there may be question marks WRT
interaction of the FireWire stack with architecture specific kernel code.

But back to the subject matter: Clearly, Kristian concentrates on
PCI/OHCI-1394 hardware at the moment. If embedded developers have
specific requirements on the FireWire stack's design, they should IMO
contribute with a list of requirements or maybe even with patches.
-- 
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/