public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Erik Mouw <erik@harddisk-recovery.com>
To: Matthew Wilcox <willy@debian.org>
Cc: Marcelo Tosatti <marcelo.tosatti@cyclades.com>,
	Xose Vazquez Perez <xose@wanadoo.es>,
	linux-scsi <linux-scsi@vger.kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: two sym53c8xx.o modules
Date: Thu, 9 Oct 2003 16:04:30 +0200	[thread overview]
Message-ID: <20031009140430.GI11525@bitwizard.nl> (raw)
In-Reply-To: <20031009132141.GF27861@parcelfarce.linux.theplanet.co.uk>

On Thu, Oct 09, 2003 at 02:21:41PM +0100, Matthew Wilcox wrote:
> On Thu, Oct 09, 2003 at 03:11:52PM +0200, Erik Mouw wrote:
> > Yes it is. The _2 driver supports newer hardware (or better: can do
> > faster speeds on newer hardware), while the old driver doesn't. The old
> > driver, however, is more reliable in case of hardware errors. It's very
> > nice to be able to change drivers on the fly without having to figure
> > out the full path to the correct module.
> 
> No, that's not the point.  For people who are already using either driver,
> there's no need to change anything between 2.4 and 2.6.  It's only the
> foolish people who compile both as modules that have a problem.

It's not foolish to compile both modules. The 53c895 works faster with
the sym538cxxx_2 driver, the 53c810 can do with the sym53cxxx driver.
For otherwise the same machines, it's nice to compile a single kernel
for all of them and have the sym58cxxx drivers as modules, so you can
specify in modules.conf which driver to use. (also think about fully
modular distribution kernels).

> If you change the sym2 driver to have a different module name, now people
> have to change when they switch between 2.4 and 2.6.  That's bad.

Upgrading major kernel versions usually breaks things. That has never
been a problem in the past, so I don't see why it should be one in this
particular case. There were other modules with completely different
names, like usb-uhci --> uhci-hcd.

> We've had this problem all through 2.4 and it's never been an issue
> until now.  I really think this is one problem which shouldn't be fixed.

It hasn't been an issue until now simply because nobody has actually
seen it going wrong. If you load sym53cxxx, you get the old driver, and
hey, it works well with all sym53cxxx SCSI cards. The old driver simply
masks the new driver and I think the new driver didn't get as much
real-life testing as it should have had.

Selecting everything as a module never was a problem in Linux, you can
load any driver just by name. The sym53cxxx is an exception to this:
the old driver masks the new one. It's a namespace collision. That's
bad and it should be fixed.

> > I haven't figured out what it could be yet, scsiinfo works perfectly
> > well with the old sym58xxx driver (and the aic7xxx driver, FWIW).
> 
> It works perfectly fine with the drives I have access to under 2.6 ...

I know (I think you even told me). The fact that I only recently
figured out about this bug proves my point: in linux-2.4 the sym53cxx_2
driver didn't get as much testing as it should have had. Apply my
patch, and the driver might even get real use.


Erik

-- 
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
| Data lost? Stay calm and contact Harddisk-recovery.com

  reply	other threads:[~2003-10-09 14:04 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-09  0:43 two sym53c8xx.o modules Xose Vazquez Perez
2003-10-09 11:41 ` Marcelo Tosatti
2003-10-09 12:24   ` Erik Mouw
2003-10-09 12:38     ` Matthew Wilcox
2003-10-09 13:11       ` Erik Mouw
2003-10-09 13:21         ` Matthew Wilcox
2003-10-09 14:04           ` Erik Mouw [this message]
2003-10-09 15:44             ` Xose Vazquez Perez
2003-10-09 13:00     ` Marcelo Tosatti
2003-10-09 16:05   ` Xose Vazquez Perez

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=20031009140430.GI11525@bitwizard.nl \
    --to=erik@harddisk-recovery.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=marcelo.tosatti@cyclades.com \
    --cc=willy@debian.org \
    --cc=xose@wanadoo.es \
    /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