linux-kernel - Re: [PATCH 0/4] 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, 20 Dec 2006 15:06:13 -0500
From:	Kristian Høgsberg <krh@...hat.com>
To:	Stefan Richter <stefanr@...6.in-berlin.de>
CC:	linux-kernel@...r.kernel.org, linux1394-devel@...ts.sourceforge.net
Subject: Re: [PATCH 0/4] New firewire stack - updated patches

Stefan Richter wrote:
...
>> And Windows Vista will drop the IP over 1394 functionality,
>> which is another data point about how widely used this standard is.
> 
> If we cared what Windows supports or does not support, we would have gap
> count optimization by now, but no support of IEEE 1394b-2002.

Yeah, my point wasn't that we need to drop it because Windows dropped it, it 
was just a data point backing up the claim that IP 1394 isn't very widely used.

And as for gap count optimization, I just added that to my git repo.  I 
thought about adding it before sending out these patches, but I was running 
late on getting them out -- I ended up spending too much time chasing down a 
stupid spinlock recursion.  It is pretty simple to implement in the new stack, 
since we have all the topology information available.  I did a quick, 
unscientific benchmark (md5summing 10 32M files) and the optimization is 
definitely noticable.  This is  a setup where the box and the disk are both 
connected to a hub so the max hops is 2, so we're using gap count 4:

	real    0m10.021s
	user    0m1.435s
	sys     0m0.356s

compared to no optimization, ie gap count 63:

	real    0m14.537s
	user    0m1.390s
	sys     0m0.402s

Though I see that Mac OS X uses a more conservative setting for a similiar 
topology, so maybe we need to add a bit or "margin" to the numbers from the 
table from 1394.

>> I'm not planning to port the pcilynx driver either.  I think it's a sore
>> point for the old stack as it is - nobody uses it or tests it and it's
>> continously bit-rotting.  So I'd rather not support it.
> 
> Here I agree.
> 
>> However, it can
>> perform as well as an OHCI card for SBP-2.  If you set up a
>> self-modifying DMA program it can read and write system memory without
>> CPU intervention too.
> 
> OK, I didn't know that although I suspected something like this might be
> possible. Of course this remains a potential feature as long as there is
> no manpower to actually implement it. (Nor is there a userbase to speak
> of to appreciate such an effort.)

Exactly.  It's a cool hack (it's mentioned briefly in appendix E.1 of the 
PCILynx functional specification) and it would be fun to make it work, but I 
don't really see a userbase here.  And if somebody has a PCILynx card and want 
to use the new stack, I'll trade them for a OHCI controller :)  I have a much 
more useful way to put PCILynx cards to work using my firewire sniffer 
(http://bitplanet.net/nosy).

cheers,
Kristian

-
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/