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]

Date:	Wed, 02 May 2007 20:51:59 +0200
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	Gene Heskett <gene.heskett@...il.com>
CC:	Adrian Bunk <bunk@...sta.de>, Olaf Hering <olh@...e.de>,
	Kristian Høgsberg <krh@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	linux1394-devel <linux1394-devel@...ts.sourceforge.net>
Subject: Re: [git pull] New firewire stack

Gene Heskett wrote:
> On Wednesday 02 May 2007, Stefan Richter wrote:
>> Olaf Hering wrote:
>>> NACK.
>>> Upgrade the current drivers/ieee1394/ with the new code,
>>> and keep all existing module names.
>> I'm impartial to that.  Using same names might ease the transition from
>> the userspace side, as far as there is userland which relies on module
>> names.
>>
>> A certain drawback of same names would be that geeks cannot install both
>> stacks at once during the transition period.
[...]
> So I'd vote unconditionally to have 2 trees to select 
> from at module load time until the shakeout has produced usable code in the 
> 2nd tree.
[...]

Adrian Bunk wrote:
> An advantage of changing the names is that they are now prefixed.
> But looking at them, there will again be the point whether everyone will 
> think that "fw" is firmware, and perhaps switching to the (although 
> longer) prefix "firewire" might make sense?


Whatever names the FireWire modules will get, we shouldn't change the
names anymore _after_ the new code appears in mainline.

Anyway, if the same names really should be used, as Olaf demands, then
it affects at most ohci1394, sbp2, eth1394, ieee1394.  However, ieee1394
is probably never loaded explicitly by scripts (only auto-loaded per
dependency of the others), and the other three all have proper module
aliases.

If the new modules are meant to look like the old ones, then there is
also the problem with module parameters.  Many of the old stack's module
parameters are merely there as hacks or workarounds though;  therefore
they shouldn't appear in shipped scripts and shipped configurations anyway.
-- 
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/