It seems a new sym53c8xx was added in 2.4.17, and now there are 2 modules,
both named sym53c8xx.o (CONFIG_SCSI_SYM53C8XX and
CONFIG_SCSI_SYM53C8XX_2). This was noticed since my mkinitrd script isn't
smart enough to destinguish the two. Leading to the question how does
modprobe? Comparing this with the naming scheme used for the two aic7xxx
modules (aic7xxx.o and aic7xxx_old.o) it seems like its a bug to me, in
either case I'd appritiate some input from somebody clued in on the issue.
Thanks,
Andreas
On Fri, 11 Jan 2002 00:00:52 -0500,
Andreas Boman <[email protected]> wrote:
>It seems a new sym53c8xx was added in 2.4.17, and now there are 2 modules,
>both named sym53c8xx.o (CONFIG_SCSI_SYM53C8XX and
>CONFIG_SCSI_SYM53C8XX_2). This was noticed since my mkinitrd script isn't
>smart enough to destinguish the two. Leading to the question how does
>modprobe?
It does not. Two modules with the same name give undefined results for
modprobe, insmod, initrd etc.
On Fri, 11 Jan 2002, Andreas Boman wrote:
> It seems a new sym53c8xx was added in 2.4.17, and now there are 2 modules,
> both named sym53c8xx.o (CONFIG_SCSI_SYM53C8XX and
> CONFIG_SCSI_SYM53C8XX_2). This was noticed since my mkinitrd script isn't
> smart enough to destinguish the two. Leading to the question how does
> modprobe? Comparing this with the naming scheme used for the two aic7xxx
> modules (aic7xxx.o and aic7xxx_old.o) it seems like its a bug to me, in
> either case I'd appritiate some input from somebody clued in on the issue.
This is a compatibility feature. Just select _the_ driver you want to use
but not both. The bug is to build the both drivers without special needs
or goal.
Renaming a driver object module will break compatibility of old linux
installations depending of the driver selected, and also may break
flexibility for who knows what he is doing.
By the way, if it ever happens one of the two modules to be renamed in
2.4, it is the old version that will be. As a result, the patch you sent
me directly that renames the new version is exactly what I donnot want to
be done.
In kernel 2.5, SYM53C8XX_2 will replace SYM53C8XX. I already agreed with
the proposal to remove the old driver version, and I suggested so
implicitely, obviously, by providing SYM53C8XX_2. I hope this will also
happen in 2.4 series, but probably a bit later.
G?rard.
On Fri, 11 Jan 2002 21:01:27 +0100 (CET)
G?rard Roudier <[email protected]> wrote:
>
>
> On Fri, 11 Jan 2002, Andreas Boman wrote:
>
> > It seems a new sym53c8xx was added in 2.4.17, and now there are 2
modules,
> > both named sym53c8xx.o (CONFIG_SCSI_SYM53C8XX and
> > CONFIG_SCSI_SYM53C8XX_2). This was noticed since my mkinitrd script
isn't
> > smart enough to destinguish the two. Leading to the question how does
> > modprobe? Comparing this with the naming scheme used for the two
aic7xxx
> > modules (aic7xxx.o and aic7xxx_old.o) it seems like its a bug to me,
in
> > either case I'd appritiate some input from somebody clued in on the
issue.
>
> This is a compatibility feature. Just select _the_ driver you want to
use
> but not both. The bug is to build the both drivers without special needs
> or goal.
>
> Renaming a driver object module will break compatibility of old linux
> installations depending of the driver selected, and also may break
> flexibility for who knows what he is doing.
This is a fine argument, until you consider kernels that arent built
specifically for one platform. I am trying to build a generic kernel that
will work on any supported hardware its loaded on. The documentation for
the new sym53c8xx_2.o driver states: "If your system has problems using
this new major version of the SYM53C8XX driver, you may switch back to
driver version 1."
That one sentence makes me think that the old driver should be renamed
sym53c8xx_old so that both modules can be built and the _old driver loaded
if the new causes any problems.
Further, if you dont rename either of the modules, something should be
done to prevent build of both modules, and/or the documentation (help)
should include a blurb about the modules being named the same thing and
the problems this is bound to cause. As it is there is no indication that
theese modules will be named the same thing, unless you look in the
Makefiles.
>
> By the way, if it ever happens one of the two modules to be renamed in
> 2.4, it is the old version that will be. As a result, the patch you sent
> me directly that renames the new version is exactly what I donnot want
to
> be done.
Wich is as I suggested should be done. The reason I attached that patch
was just to show that this is an issue that I have had to deal with. And
as I stated, I renamed the new driver since it has the new config option,
and resides in the drivers/scsi/sym53c8xx_2 subdirectory (and was a much
quicker workaround).
>
> In kernel 2.5, SYM53C8XX_2 will replace SYM53C8XX. I already agreed with
> the proposal to remove the old driver version, and I suggested so
> implicitely, obviously, by providing SYM53C8XX_2. I hope this will also
> happen in 2.4 series, but probably a bit later.
Why rename it later (in the 2.4 series) instead of now? The problems
caused by a renaming would occur at that time as well as it would now.
Andreas
> G?rard.
On Fri, 11 Jan 2002, Andreas Boman wrote:
> On Fri, 11 Jan 2002 21:01:27 +0100 (CET)
> G?rard Roudier <[email protected]> wrote:
>
> >
> >
> > On Fri, 11 Jan 2002, Andreas Boman wrote:
> >
> > > It seems a new sym53c8xx was added in 2.4.17, and now there are 2
> modules,
> > > both named sym53c8xx.o (CONFIG_SCSI_SYM53C8XX and
> > > CONFIG_SCSI_SYM53C8XX_2). This was noticed since my mkinitrd script
> isn't
> > > smart enough to destinguish the two. Leading to the question how does
> > > modprobe? Comparing this with the naming scheme used for the two
> aic7xxx
> > > modules (aic7xxx.o and aic7xxx_old.o) it seems like its a bug to me,
> in
> > > either case I'd appritiate some input from somebody clued in on the
> issue.
> >
> > This is a compatibility feature. Just select _the_ driver you want to
> use
> > but not both. The bug is to build the both drivers without special needs
> > or goal.
> >
> > Renaming a driver object module will break compatibility of old linux
> > installations depending of the driver selected, and also may break
> > flexibility for who knows what he is doing.
>
> This is a fine argument, until you consider kernels that arent built
> specifically for one platform. I am trying to build a generic kernel that
> will work on any supported hardware its loaded on. The documentation for
> the new sym53c8xx_2.o driver states: "If your system has problems using
> this new major version of the SYM53C8XX driver, you may switch back to
> driver version 1."
What should I have written ?
What about : "you are required to persist using the new driver until all
your filesystems get definitely screwed". :-)
> That one sentence makes me think that the old driver should be renamed
> sym53c8xx_old so that both modules can be built and the _old driver loaded
> if the new causes any problems.
>
> Further, if you dont rename either of the modules, something should be
> done to prevent build of both modules, and/or the documentation (help)
> should include a blurb about the modules being named the same thing and
> the problems this is bound to cause. As it is there is no indication that
> theese modules will be named the same thing, unless you look in the
> Makefiles.
The old driver doesn't work that bad and the new one is already proven to
work at least as well as the old one. There is about no risk with using
either driver in my opinion. However, I can understand that using one when
beleiving that you are using the other one is not a pleasant situation.
> > By the way, if it ever happens one of the two modules to be renamed in
> > 2.4, it is the old version that will be. As a result, the patch you sent
> > me directly that renames the new version is exactly what I donnot want
> to
> > be done.
>
> Wich is as I suggested should be done. The reason I attached that patch
> was just to show that this is an issue that I have had to deal with. And
> as I stated, I renamed the new driver since it has the new config option,
> and resides in the drivers/scsi/sym53c8xx_2 subdirectory (and was a much
> quicker workaround).
The renaming of sym-1 does not require my intervention. This can be done
by kernel maintainer in a minute. It just would be kind to ask me for
before this to be done, but it is not required at all. If Marcello is
reading this mail, then let me say him that I am ok with the renaming of
the old driver, even if I donnot catch the real need for this.
> > In kernel 2.5, SYM53C8XX_2 will replace SYM53C8XX. I already agreed with
> > the proposal to remove the old driver version, and I suggested so
> > implicitely, obviously, by providing SYM53C8XX_2. I hope this will also
> > happen in 2.4 series, but probably a bit later.
>
> Why rename it later (in the 2.4 series) instead of now? The problems
> caused by a renaming would occur at that time as well as it would now.
I wasn't talking about the renaming but about the removing.
G?rard.