daptec SCSI HBA device driver for the Linux Operating System
To: [email protected]
cc:
Fcc: +outbox
Subject: Adaptec AIC7XXX v6.0.6 BETA Released
-------
After several months of testing and refinement, the Adaptec
sponsored aic7xxx driver is now entering Beta testing. Although
still missing domain validation and the last bits of cardbus
support, there are no known issues with the driver. I would
encourage all users of card supported by this driver to try the
new code and submit feedback. Patches for late 2.2.X, 2.3.99
and 2.4.0 are provided in the driver distribution. For those
of you building the driver as a module, take note that the module
name is now "aic7xxx_mod" rather than "aic7xxx".
As always, the most recent distribution is available here:
http://people.FreeBSD.org/~gibbs/linux/
--
Justin
On Wed, 13 Dec 2000, Justin T. Gibbs wrote:
> Subject: Adaptec AIC7XXX v6.0.6 BETA Released
> -------
> After several months of testing and refinement, the Adaptec
> sponsored aic7xxx driver is now entering Beta testing. Although
> still missing domain validation and the last bits of cardbus
> support, there are no known issues with the driver. I would
> encourage all users of card supported by this driver to try the
> new code and submit feedback. Patches for late 2.2.X, 2.3.99
> and 2.4.0 are provided in the driver distribution. For those
> of you building the driver as a module, take note that the module
> name is now "aic7xxx_mod" rather than "aic7xxx".
>
> As always, the most recent distribution is available here:
>
> http://people.FreeBSD.org/~gibbs/linux/
Justin,
Thanks for posting this. Unfortunately, the kernel won't build unless you
restore this macro to the namespace after aic7xxx_linux.h blows it away:
--- linux-2.2.18/drivers/scsi/hosts.c.orig Wed Dec 13 20:27:34 2000
+++ linux-2.2.18/drivers/scsi/hosts.c Wed Dec 13 20:26:22 2000
@@ -137,6 +137,7 @@
#ifdef CONFIG_SCSI_AIC7XXX
#include "aic7xxx/aic7xxx_linux.h"
+#define current get_current()
#endif
#ifdef CONFIG_SCSI_IPS
Steve
>Thanks for posting this. Unfortunately, the kernel won't build unless you
>restore this macro to the namespace after aic7xxx_linux.h blows it away:
>
>--- linux-2.2.18/drivers/scsi/hosts.c.orig Wed Dec 13 20:27:34 2000
>+++ linux-2.2.18/drivers/scsi/hosts.c Wed Dec 13 20:26:22 2000
>@@ -137,6 +137,7 @@
>
> #ifdef CONFIG_SCSI_AIC7XXX
> #include "aic7xxx/aic7xxx_linux.h"
>+#define current get_current()
> #endif
>
> #ifdef CONFIG_SCSI_IPS
>
>
>Steve
I take it you had other controllers enabled? I tested this against
2.2.18-pre24 and didn't see any problems. I didn't enable anything
other than the aic7xxx driver.
Luckily, in newer kernels, the per-controller includes are no longer
required in hosts.c. None-the-less, it seems to me that spamming
the kernel namespace with "current" in at least the way that the
2.2 kernels do (does this occur in later kernels?) should be corrected.
As you can see from my comment in aic7xxx_linux.h, I was very surprised
to see this occur.
I'll update my patch tomorrow to restore the definition of current.
I do fear, however, that this will perpetuate the polution of the
namespace should "current" ever get cleaned up.
--
Justin
Date: Wed, 13 Dec 2000 20:56:08 -0700
From: "Justin T. Gibbs" <[email protected]>
None-the-less, it seems to me that spamming the kernel namespace
with "current" in at least the way that the 2.2 kernels do (does
this occur in later kernels?) should be corrected.
Justin, "current" is a pointer to the current thread executing on the
current processor under Linux. It has existed since day one of the
Linux kernel and probably will exist till the end of it's life.
I'm sure the BSD kernel has some similar bogosity :-)
Later,
David S. Miller
[email protected]
> Date: Wed, 13 Dec 2000 20:56:08 -0700
> From: "Justin T. Gibbs" <[email protected]>
>
> None-the-less, it seems to me that spamming the kernel namespace
> with "current" in at least the way that the 2.2 kernels do (does
> this occur in later kernels?) should be corrected.
>
>Justin, "current" is a pointer to the current thread executing on the
>current processor under Linux. It has existed since day one of the
>Linux kernel and probably will exist till the end of it's life.
>
>I'm sure the BSD kernel has some similar bogosity :-)
BSD has curproc, but that is considerably less likely to be
used in "inoccent code" than "current". I mean, "current what?".
It could be anything, current privledges, current process, current
thread, the current time...
--
Justin
> I'll update my patch tomorrow to restore the definition of current.
> I do fear, however, that this will perpetuate the polution of the
> namespace should "current" ever get cleaned up.
It can probably get cleaned up after 2.4 by making current() the actual
inline. For 2.2 it won't change. Consider it a feature.
It was done originally because the 2.0 code using #define based current
generated better code than using inline functions. 2.2 upwards use a different
(far nicer) method to find current.
Note also that you cannot rely on 'get_current()'. The only way to find
current is to use current. get_current() the inline is an x86ism.
Alan
> BSD has curproc, but that is considerably less likely to be
> used in "inoccent code" than "current". I mean, "current what?".
> It could be anything, current privledges, current process, current
> thread, the current time...
I see and I assume calling a random collection of data
u.something
in BSD was even more logical 8)
current is a completely rational name. The problem with current on some of
our ports right now is that its a #define. That is a trap for the unwary and
one day wants fixing.
curproc would be incorrect for linux since its the current task, and a task and
unix process are not the same thing
Alan
On Wed, 13 Dec 2000 23:15:36 Justin T. Gibbs wrote:
> daptec SCSI HBA device driver for the Linux Operating System
> To: [email protected]
> cc:
> Fcc: +outbox
> Subject: Adaptec AIC7XXX v6.0.6 BETA Released
> -------
> After several months of testing and refinement, the Adaptec
> sponsored aic7xxx driver is now entering Beta testing. Although
> still missing domain validation and the last bits of cardbus
> support, there are no known issues with the driver. I would
> encourage all users of card supported by this driver to try the
> new code and submit feedback. Patches for late 2.2.X, 2.3.99
> and 2.4.0 are provided in the driver distribution. For those
> of you building the driver as a module, take note that the module
> name is now "aic7xxx_mod" rather than "aic7xxx".
>
> As always, the most recent distribution is available here:
>
I tried it against clean 2.2.18 and patches did not work.
Some drawbacks:
- the patch adds config info for AIX7XXX in the top level Makefile, instead
of in the Makefile in the scsi dir.
- The subdir for aic7xxx has not a Makefile, or at least it is not created
with the patches for 2.2.18.
- The structure of the driver (all files inside a subdir) has changed, so
you get the old files still there.
I am going to try to clean up the thigs to make the driver easily updated:
- First thing is to move all files in the actual 5.1.31 to INSIDE the dir
and change the scsi/Makefile to build it as a SUB_DIR.
- Change names of files: aic7xxx.o has to be built from many *.c, so you
should rename the aic7xxx.c to something like aic7xxx_main.c.
- Then you have the aic7xxx subdir and you can add a similar aic7xxx-6 subdir
and even add an exclusive option to build one or the other, the second
marked EXPERIMENTAL.
Couple o' questions:
- Is there any easy way to move/rename files with a diff, or just diff
from /dev/null or empty files .org and patch with -E ?
- Is there any keywork for Config.in files to do exclusion between
drivers or just if's ? Have to look for similar drivers. Any hint ?
Thanks.
--
Juan Antonio Magallon Lacarta #> cd /pub
mailto:[email protected] #> more beer
Linux werewolf 2.2.18-aa1 #1 SMP Mon Dec 11 21:26:28 CET 2000 i686
On Wed, 13 Dec 2000, Justin T. Gibbs wrote:
> >Thanks for posting this. Unfortunately, the kernel won't build unless you
> >restore this macro to the namespace after aic7xxx_linux.h blows it away:
> >
> >--- linux-2.2.18/drivers/scsi/hosts.c.orig Wed Dec 13 20:27:34 2000
> >+++ linux-2.2.18/drivers/scsi/hosts.c Wed Dec 13 20:26:22 2000
> >@@ -137,6 +137,7 @@
> >
> > #ifdef CONFIG_SCSI_AIC7XXX
> > #include "aic7xxx/aic7xxx_linux.h"
> >+#define current get_current()
> > #endif
> >
> > #ifdef CONFIG_SCSI_IPS
> >
> >
> >Steve
>
> I take it you had other controllers enabled? I tested this against
> 2.2.18-pre24 and didn't see any problems. I didn't enable anything
> other than the aic7xxx driver.
Yes, I have an IBM ServeRaid controller in addition to the on-board
7890. Any includes which lexically follow your new aic7xxx driver in
hosts.c will be similarly affected.
> Luckily, in newer kernels, the per-controller includes are no longer
> required in hosts.c. None-the-less, it seems to me that spamming
> the kernel namespace with "current" in at least the way that the
> 2.2 kernels do (does this occur in later kernels?) should be corrected.
> As you can see from my comment in aic7xxx_linux.h, I was very surprised
> to see this occur.
>
> I'll update my patch tomorrow to restore the definition of current.
> I do fear, however, that this will perpetuate the polution of the
> namespace should "current" ever get cleaned up.
I won't wade into this controversy (sick of dimpled chads, I guess).
Steve
>I tried it against clean 2.2.18 and patches did not work.
>Some drawbacks:
>- the patch adds config info for AIX7XXX in the top level Makefile, instead
>of in the Makefile in the scsi dir.
Yes, this will be fixed today. The aic7xx directory will build the module
or main driver file into the scsi directory so that no files need to be
renamed. This also means that the module name can remain the same.
>- The subdir for aic7xxx has not a Makefile, or at least it is not created
>with the patches for 2.2.18.
It was supposed to be part of the patches for 2.2.18 (each kernel version
requires a slightly different Makefile which is why it is not included
in the main source ball).
>- The structure of the driver (all files inside a subdir) has changed, so
>you get the old files still there.
There is no way to remove those files other than instructing the user to
do so or to execute a script.
>I am going to try to clean up the thigs to make the driver easily updated:
>- First thing is to move all files in the actual 5.1.31 to INSIDE the dir
> and change the scsi/Makefile to build it as a SUB_DIR.
>- Change names of files: aic7xxx.o has to be built from many *.c, so you
> should rename the aic7xxx.c to something like aic7xxx_main.c.
>- Then you have the aic7xxx subdir and you can add a similar aic7xxx-6 subdir
>and even add an exclusive option to build one or the other, the second
>marked EXPERIMENTAL.
Blah. I'd rather prove the utility of the new driver prior to having
it incorporated into the kernel tree and at that point have it as a
full replacement. Otherwise there is just too much room for confusion.
--
Justin
>> I'll update my patch tomorrow to restore the definition of current.
>> I do fear, however, that this will perpetuate the polution of the
>> namespace should "current" ever get cleaned up.
>
>It can probably get cleaned up after 2.4 by making current() the actual
>inline. For 2.2 it won't change. Consider it a feature.
>
>It was done originally because the 2.0 code using #define based current
>generated better code than using inline functions. 2.2 upwards use a different
>(far nicer) method to find current.
>
>Note also that you cannot rely on 'get_current()'. The only way to find
>current is to use current. get_current() the inline is an x86ism.
I figured as much. I will test for the #define, stash it in a #define
unique within my namespace, and #define it back in hosts.c should my
local define exist.
--
Justin
>> BSD has curproc, but that is considerably less likely to be
>> used in "inoccent code" than "current". I mean, "current what?".
>> It could be anything, current privledges, current process, current
>> thread, the current time...
>
>I see and I assume calling a random collection of data
>
> u.something
>
>in BSD was even more logical 8)
The only place I've seen this in BSD is for defining a "union" of
data within a structure. I don't think its ever been #defined into
a namespace.
>current is a completely rational name. The problem with current on some of
>our ports right now is that its a #define. That is a trap for the unwary and
>one day wants fixing.
Exactly.
>curproc would be incorrect for linux since its the current task,
>and a task and unix process are not the same thing
I'm aware of the difference. I only mentioned "curproc" as an example of
similar brokeness that has less of a chance of catching the uninitiated.
What about "curtask" or "curthread"?
--
Justin
On Thu, 14 Dec 2000 14:45:53 Justin T. Gibbs wrote:
> >- The subdir for aic7xxx has not a Makefile, or at least it is not created
> >with the patches for 2.2.18.
>
> It was supposed to be part of the patches for 2.2.18 (each kernel version
> requires a slightly different Makefile which is why it is not included
> in the main source ball).
>
My fault. Moved old aic* to aic7xxx.O, patched before untaring so
aic7xxx/Makefile did not create.
--
Juan Antonio Magallon Lacarta #> cd /pub
mailto:[email protected] #> more beer
Linux werewolf 2.2.18-aa1 #1 SMP Mon Dec 11 21:26:28 CET 2000 i686
On Thu, 14 Dec 2000, Justin T. Gibbs wrote:
> >> I'll update my patch tomorrow to restore the definition of current.
> >> I do fear, however, that this will perpetuate the polution of the
> >> namespace should "current" ever get cleaned up.
> >
> >It can probably get cleaned up after 2.4 by making current() the actual
> >inline. For 2.2 it won't change. Consider it a feature.
> >
> >It was done originally because the 2.0 code using #define based current
> >generated better code than using inline functions. 2.2 upwards use a different
> >(far nicer) method to find current.
> >
> >Note also that you cannot rely on 'get_current()'. The only way to find
> >current is to use current. get_current() the inline is an x86ism.
>
> I figured as much. I will test for the #define, stash it in a #define
> unique within my namespace, and #define it back in hosts.c should my
> local define exist.
Justin,
While you're at it, can you have the new driver provide status information
under /proc/scsi/aic7xxx? There is simply an empty pseudo-file called '0'
instead of the display provided by the current driver.
Steve
"Justin T. Gibbs" wrote:
>
> >> BSD has curproc, but that is considerably less likely to be
> >> used in "inoccent code" than "current". I mean, "current what?".
> >> It could be anything, current privledges, current process, current
> >> thread, the current time...
> >
> >I see and I assume calling a random collection of data
> >
> > u.something
> >
> >in BSD was even more logical 8)
>
> The only place I've seen this in BSD is for defining a "union" of
> data within a structure. I don't think its ever been #defined into
> a namespace.
>
> >current is a completely rational name. The problem with current on some of
> >our ports right now is that its a #define. That is a trap for the unwary and
> >one day wants fixing.
>
> Exactly.
>
> >curproc would be incorrect for linux since its the current task,
> >and a task and unix process are not the same thing
>
> I'm aware of the difference. I only mentioned "curproc" as an example of
> similar brokeness that has less of a chance of catching the uninitiated.
> What about "curtask" or "curthread"?
What's wrong with current? It's perfectly fine, since it's the main data
context entity you are working with during it's usage... Just remember
it as
CURRENT MAIN PROBLEM the kernel is struggling with at time.
>> I figured as much. I will test for the #define, stash it in a #define
>> unique within my namespace, and #define it back in hosts.c should my
>> local define exist.
>
>Justin,
>
>While you're at it, can you have the new driver provide status information
>under /proc/scsi/aic7xxx? There is simply an empty pseudo-file called '0'
>instead of the display provided by the current driver.
>
>Steve
I don't know when the /proc stuff will return or what data will be
provided there.
--
Justin
>
>What's wrong with current? It's perfectly fine, since it's the main data
>context entity you are working with during it's usage... Just remember
>it as
>CURRENT MAIN PROBLEM the kernel is struggling with at time.
What's wrong with the aic7xxx driver storing the "user", "goal", and
"current" transfer negotiation settings for a device in a structure
with fields by those names? Nothing save the fact that "current" is
a #define in linux.
Anyway, I've said my peace. The driver will properly work around
the namespace problem.
--
Justin
"Justin T. Gibbs" wrote:
>
> >
> >What's wrong with current? It's perfectly fine, since it's the main data
> >context entity you are working with during it's usage... Just remember
> >it as
> >CURRENT MAIN PROBLEM the kernel is struggling with at time.
>
> What's wrong with the aic7xxx driver storing the "user", "goal", and
> "current" transfer negotiation settings for a device in a structure
> with fields by those names? Nothing save the fact that "current" is
> a #define in linux.
>
> Anyway, I've said my peace. The driver will properly work around
> the namespace problem.
Just save space and call it curr instead ;-).
In article <[email protected]> you wrote:
> For those
> of you building the driver as a module, take note that the module
> name is now "aic7xxx_mod" rather than "aic7xxx".
Could you please undo that change?
Postfixing a module name with _mod does not make sense.
Yes, some modules use it - but that's just because they have older source
files that are called like the multi-object module.
Christoph
--
Whip me. Beat me. Make me maintain AIX.
>In article <[email protected]> you wrote:
>> For those
>> of you building the driver as a module, take note that the module
>> name is now "aic7xxx_mod" rather than "aic7xxx".
>
>Could you please undo that change?
>Postfixing a module name with _mod does not make sense.
>Yes, some modules use it - but that's just because they have older source
>files that are called like the multi-object module.
It will change today assuming I can get the build to work consistently.
The change occurred because the driver now is composed of multiple
objects.
--
Justin
>
> I don't know when the /proc stuff will return or what data will be
> provided there.
At the risk of tooting my own horn, you might put there that which I do for my
Qlogic driver- it lists current perio/offset values per target and a list of
currently running commands. It's very easy to support and very very useful.
The old linux aic driver also had a bunch of stats (binned to size)- I believe
I wrote that some years back- but that's not needed if you get Steve Tweedie's
sar package.
On Thu, Dec 14, 2000 at 10:14:51AM +0000, Alan Cox wrote:
> > I'll update my patch tomorrow to restore the definition of current.
> > I do fear, however, that this will perpetuate the polution of the
> > namespace should "current" ever get cleaned up.
>
> It can probably get cleaned up after 2.4 by making current() the actual
> inline. For 2.2 it won't change. Consider it a feature.
>
> It was done originally because the 2.0 code using #define based current
> generated better code than using inline functions. 2.2 upwards use a different
> (far nicer) method to find current.
The macro is still likely to generate better code. All released
gcc versions have the "inline penalty" causing bad register allocation
(maybe it'll be fixed with gcc 3's tree inliner)
-Andi
> I figured as much. I will test for the #define, stash it in a #define
> unique within my namespace, and #define it back in hosts.c should my
> local define exist.
If that driver hits a tree I maintain be aware that the first thing I will do
is rip that out and rename the 'current' variables in it 8)
> I'm aware of the difference. I only mentioned "curproc" as an example of
> similar brokeness that has less of a chance of catching the uninitiated.
> What about "curtask" or "curthread"?
Its called current. We write a lot of current->state type things where it makes
a lot of sense. Being a define is ugly because it hits struct fields. Being a
global is sane. Its also something that is inbuilt into every driver and every
book or article on linux driver/kernel stuff. Changing it would be extremely
bad.
Alan
>> I figured as much. I will test for the #define, stash it in a #define
>> unique within my namespace, and #define it back in hosts.c should my
>> local define exist.
>
>If that driver hits a tree I maintain be aware that the first thing I will do
>is rip that out and rename the 'current' variables in it 8)
The only reason "namespace restoration" is an issue at all is due to the
poor design of hosts.c in 2.2.X kernels. A better solution would be to
bring in the build hooks from 2.4 so modules and compiled in drivers are
handled the same way - a way that lets drivers do what they want with
their namespace without touching that of any other portion of the kernel.
--
Justin
> I figured as much. I will test for the #define, stash it in a #define
> unique within my namespace, and #define it back in hosts.c should my
> local define exist.
I think its pretty much x86 only that has the define problem. For 2.2 its
stuck and one or two folks depend on it. For 2.4 I cannot see why we don't
change the inline function to be current() not get_current() thereby cleaning
up the struct problem you see.
On the other platforms current is general a gcc register global and so wont
interfere with struct namespace
Alan
> > generated better code than using inline functions. 2.2 upwards use a different
> > (far nicer) method to find current.
>
> The macro is still likely to generate better code. All released
> gcc versions have the "inline penalty" causing bad register allocation
> (maybe it'll be fixed with gcc 3's tree inliner)
Given that the 2.4 source does
blan inline get_curent()
#define curret get_current()
I feel safe in believing that we can fix the 2.4 tree with no noticable
change in performance. Justin is simply providing a reminder that the work
has actually all been done
> The only reason "namespace restoration" is an issue at all is due to the
> poor design of hosts.c in 2.2.X kernels. A better solution would be to
> bring in the build hooks from 2.4 so modules and compiled in drivers are
I agree entirely. 2.2.18 has the build hooks in. Switching the hosts file to
use them in 2.2.19 is an option if someone wants to do it.
On Wed, 13 Dec 2000, Justin T. Gibbs wrote:
> > Date: Wed, 13 Dec 2000 20:56:08 -0700
> > From: "Justin T. Gibbs" <[email protected]>
> >
> > None-the-less, it seems to me that spamming the kernel namespace
> > with "current" in at least the way that the 2.2 kernels do (does
> > this occur in later kernels?) should be corrected.
> >
> >Justin, "current" is a pointer to the current thread executing on the
> >current processor under Linux. It has existed since day one of the
> >Linux kernel and probably will exist till the end of it's life.
> >
> >I'm sure the BSD kernel has some similar bogosity :-)
>
> BSD has curproc, but that is considerably less likely to be
> used in "inoccent code" than "current". I mean, "current what?".
> It could be anything, current privledges, current process, current
> thread, the current time...
"buf, buffers, type, version" (of what ?) with FreeBSD kernel (if they
still exist), but they are global variables, not macros.
By the way, SYM-2, that is "FreeBSD sym back to Linux but still in
FreeBSD":), clashed on Linux "current" as well. Reason is that the
corresponding code was based on yours :) (as indicated in the sym driver
source). I have changed "current" by "curr". This is as clear and has the
advantage of scaling better with "user" and "goal" (4 characters each).
tinfo.goal
tinfo.user
tinfo.curr
Just a suggestion.
G?rard.
On Wed, 13 Dec 2000, Justin T. Gibbs wrote:
> daptec SCSI HBA device driver for the Linux Operating System
> To: [email protected]
> cc:
> Fcc: +outbox
> Subject: Adaptec AIC7XXX v6.0.6 BETA Released
> -------
> After several months of testing and refinement, the Adaptec
> sponsored aic7xxx driver is now entering Beta testing. Although
> still missing domain validation and the last bits of cardbus
> support, there are no known issues with the driver. I would
> encourage all users of card supported by this driver to try the
> new code and submit feedback. Patches for late 2.2.X, 2.3.99
> and 2.4.0 are provided in the driver distribution. For those
> of you building the driver as a module, take note that the module
> name is now "aic7xxx_mod" rather than "aic7xxx".
>
> As always, the most recent distribution is available here:
>
> http://people.FreeBSD.org/~gibbs/linux/
Justin,
Although your driver has worked fine otherwise, I discovered today that it
renders my Seagate/Conner DDS-2 drive inoperative. Any and all attempts
at accessing the device (e.g. making tar archive, 'mt -f /dev/st0 status',
etc.) result in:
st0: Error 10000 (sugg. bt 0x0, driver bt 0x0, host bt 0x1).
The platform is a Pentium 166 with on-board aic7880 controller.
If I revert back to Doug Ledford's 5.1.31 driver, everything is fine.
Any insights or things you'd like me to try?
Steve