From: Willem Riede <wrlk@riede.org>
To: Patrick Mansfield <patmans@us.ibm.com>
Cc: Mikael Pettersson <mikpe@csd.uu.se>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Selective attach for ide-scsi
Date: Sat, 14 Feb 2004 17:06:47 -0500 [thread overview]
Message-ID: <20040214220647.GE4957@serve.riede.org> (raw)
In-Reply-To: <20040211121120.A24289@beaverton.ibm.com> (from patmans@us.ibm.com on Wed, Feb 11, 2004 at 15:11:20 -0500)
On 2004.02.11 15:11, Patrick Mansfield wrote:
> On Mon, Feb 09, 2004 at 07:02:05PM -0500, Willem Riede wrote:
> > On 2004.02.09 03:24, Mikael Pettersson wrote:
> > > Willem Riede writes:
>
> > > The patch I posted, which you apparently didn't like, doesn't
> > > require the use of boot-only options: it instead adds a module_param
> > > to ide-scsi which allows for greater flexibility.
> > >
> > > Personally I never liked that butt-ugly hdX=ide-scsi hack.
> >
> > I hear you. There are certainly advantages to use a module parameter rather
> > than a boot argument.
>
> But module_param allows module arguments when built as a module, and boot
> arguments when built into the kernel.
>
> > However, there should not be two mechanisms to achieve the same goal. For
> > better or for worse, the hdX=<driver> construction exists, and people are
> > using it. Its use is not limited to ide-scsi.
>
> So does module_param not work because the usage is across modules? That
> seems odd.
I wasn't making myself clear, it seems.
The hdX= construct applies to the entire ide subsystem, which for the vast
majority of people means it has to be specified at boot time, as ide is
compiled in.
If we were to have an ide-scsi module option to tell it which hdX units to
attach to, that would be more flexible than having to tell ide, since I can
then rmmod/insmod ide-scsi if I want to change my mind, whereas I must reboot
if I need to change what I tell ide.
The advantage of the hdX ide parameter is that it applies to the entire ide
subsystem, and therefor influences ide-cd, ide-scsi, ide-tape.
The main reason I see for sticking with the hdX= construct is that I think
that introducing competing mechanisms that achieve much the same objective
is a bad thing.
Regards, Willem Riede.
next prev parent reply other threads:[~2004-02-14 22:06 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-08 22:42 [PATCH] Selective attach for ide-scsi Willem Riede
2004-02-09 8:24 ` Mikael Pettersson
2004-02-10 0:02 ` Willem Riede
2004-02-11 20:11 ` Patrick Mansfield
2004-02-14 22:06 ` Willem Riede [this message]
2004-02-14 22:54 ` Bartlomiej Zolnierkiewicz
2004-02-14 23:03 ` Willem Riede
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=20040214220647.GE4957@serve.riede.org \
--to=wrlk@riede.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mikpe@csd.uu.se \
--cc=patmans@us.ibm.com \
/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