public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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


  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