From: Adrian Bunk <bunk@stusta.de>
To: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: Olaf Hering <olh@suse.de>,
Jonathan Woithe <jwoithe@physics.adelaide.edu.au>,
linux1394-devel@lists.sourceforge.net, akpm@linux-foundation.org,
torvalds@linux-foundation.org, linux-kernel@vger.kernel.org,
krh@redhat.com
Subject: Re: [git pull] New firewire stack
Date: Thu, 3 May 2007 18:34:42 +0200 [thread overview]
Message-ID: <20070503163442.GK3531@stusta.de> (raw)
In-Reply-To: <4639E3FC.8060107@s5r6.in-berlin.de>
On Thu, May 03, 2007 at 03:30:36PM +0200, Stefan Richter wrote:
> Olaf Hering wrote:
> > On Thu, May 03, Stefan Richter wrote:
> >
> >> ieee1394-old
> >
> > Noone will seriously ship two firewire stacks, so that cant be the
> > issue (for distributors).
>
> I don't actively watch distributions, but I believe there are frequently
> alternative drivers shipped. How much sense that makes for FireWire is
> another question.
>
> > Once there is a way to easily switch between kernel releases, I'm ok
> > with whatever module names you pick.
>
> It may actually be easier to let problem reporters (who cannot or don't
> want to compile kernels) compare between different kernel releases,
> rather than to ask them to compare between different stacks on top of
> the same kernel. Still, it potentially reduces the testers base.
>
> Adrian wrote:
> | An advantage of changing the names is that they are now prefixed.
>
> Is the opportunity to clean up module names compelling enough, vs. (the
> wish for) minimized trouble with scripts which refer to module names?
>...
How big is the trouble actually?
We have never and cannot guarantee stable module names (think of e.g.
PATA, e100 or sky2/skge), so changed names are always possible when
upgrading kernels.
Module aliases can solve many issues.
And sometimes it might even be an advantage that different drivers for
the same hardware get different names (consider especially PATA).
Not changing the module names also has the problem that the old code
must be removed from the kernel tree before the new one can be added
since two different modules with the same names could easily cause
trouble - consider a user first compiling and installing the one
modular, and then compiling and installing the other one modular (e.g.
due to problems with the one he tried first). Which module will now be
loaded by modprobe?
> Stefan Richter
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
next prev parent reply other threads:[~2007-05-03 16:34 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.197656.1178135675.32383.linux1394-devel@lists.sourceforge.net>
2007-05-03 0:04 ` [git pull] New firewire stack Jonathan Woithe
2007-05-03 8:22 ` Stefan Richter
2007-05-03 11:48 ` Olaf Hering
2007-05-03 13:30 ` Stefan Richter
2007-05-03 16:34 ` Adrian Bunk [this message]
2007-05-03 17:33 ` Kristian Høgsberg
2007-05-04 5:54 ` Bill Fink
2007-05-05 21:17 ` Olaf Hering
2007-05-08 0:28 ` Kristian Høgsberg
2007-05-03 23:07 ` Jonathan Woithe
2007-05-01 20:27 Kristian Høgsberg
2007-05-01 21:34 ` Stefan Richter
2007-05-02 9:00 ` Christoph Hellwig
2007-05-02 12:13 ` Stefan Richter
2007-05-02 20:00 ` Kristian Høgsberg
2007-05-02 12:21 ` Olaf Hering
2007-05-02 12:48 ` Stefan Richter
2007-05-02 13:56 ` Gene Heskett
2007-05-02 18:51 ` Stefan Richter
2007-05-02 15:27 ` Adrian Bunk
2007-05-02 20:03 ` Kristian Høgsberg
2007-05-02 19:53 ` Kristian Høgsberg
2007-05-02 20:03 ` Olaf Hering
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070503163442.GK3531@stusta.de \
--to=bunk@stusta.de \
--cc=akpm@linux-foundation.org \
--cc=jwoithe@physics.adelaide.edu.au \
--cc=krh@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux1394-devel@lists.sourceforge.net \
--cc=olh@suse.de \
--cc=stefanr@s5r6.in-berlin.de \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox