linux-kernel - Re: [git pull] 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]

Message-Id: <200705032307.l43N7NOv032566@turbo.physics.adelaide.edu.au>
Date:	Fri, 4 May 2007 08:37:23 +0930 (CST)
From:	Jonathan Woithe <jwoithe@...sics.adelaide.edu.au>
To:	stefanr@...6.in-berlin.de (Stefan Richter)
Cc:	jwoithe@...sics.adelaide.edu.au (Jonathan Woithe),
	linux1394-devel@...ts.sourceforge.net, olh@...e.de,
	akpm@...ux-foundation.org, torvalds@...ux-foundation.org,
	linux-kernel@...r.kernel.org, krh@...hat.com
Subject: Re: [git pull] New firewire stack

> Jonathan Woithe wrote:
> >> Olaf Hering wrote:
> >>> NACK.
> >>> Upgrade the current drivers/ieee1394/ with the new code, and keep all
> >>> existing module names.
> [...]
> > However, as a compromise how about renaming the existing stack's modules and
> > then reusing the existing names for the new stack?  Messy I know, but this
> > way both stacks would still be available without recompilation for those who
> > needed them and the sbp2-as-root dilemma raised by Olaf would also be
> > covered.
> 
> I.e. new modules:
> 	ieee1394 (was fw-core)
> 	ohci1394 (was fw-ohci)
>       :

> old modules, for example:
> 	ieee1394-old
> 	ohci1394-old
>       :
> 
> Looks... weird.
> 
> On the other hand, a 1394 module compilation cycle in order to do the
> fallback is not such a huge issue, except that it requires the person to
> be able to compile modules.  That's probably the main issue.

True on all counts.  I guess it's a question of whether the lack of an easy
fallback path will significantly reduce the number of testers.  I don't have
enough of a feel to answer that.

> 	eth1394  (to be done) --- but that's a bad name anyway, it
>                                   implements IP over 1394, not Ethernet

So, when eth1394 is ported the name should be something like fw-ip, at least
if we are to remain consistent with the other 3 module names.

> > Oh yes, it would be nice to have working PCILynx support again (although I
> > acknowledge it's unlikely to happen).  Some of us do have these cards
> > installed for sniffing purposes (using nosy) but it would be nice to be able
> > to use them with libraw1394 as well.  It would for example save me having to
> > swap cards depending on what I needed to do (I have insufficient PCI slots
> > to have both the PCILynx and OHCI cards installed simultaneously).
> 
> But then, what is the actual utility of pcilynx?  (I mean the current
> driver, not the card or a future driver.)  Last time I checked, sbp2 was
> broken without OHCI's physical DMA, and AFAIK raw1394's newer iso API
> and video1394 and dv1394 don't work with pcilynx either.

It certainly doesn't support the raw1394 API so its current usefulness is
extremely limited.

> Porting pcilynx to the new low-level API would be quite resource
> demanding --- seen in relation to which resources we have, what the
> existing pcilynx driver's state of affairs is, and how rare the hardware
> is.  (For those who have the hardware, the stand-alone Nosy is
> undoubtedly the killer application, not pcilynx.)

Precisely.  As I said, I've probably got a corner case and it's certainly
not worth the effort just for that.  It would be nice though.  You're right
about nosy; so long as nosy (which is independent of the firewire stack)
keeps working I'll be happy. :)

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