Adaptec AIC7XXX v 6.0.6 BETA Released

Adaptec AIC7XXX v 6.0.6 BETA Released

[Justin T. Gibbs]

daptec SCSI HBA device driver for the Linux Operating System
To: linux-scsi@vger.kernel.org
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Adaptec AIC7XXX v 6.0.6 BETA Released

[Steven N. Hirsch]

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


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Adaptec AIC7XXX v 6.0.6 BETA Released

[Justin T. Gibbs]

>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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Adaptec AIC7XXX v 6.0.6 BETA Released

[David S. Miller]

   Date: 	Wed, 13 Dec 2000 20:56:08 -0700
   From: "Justin T. Gibbs" <gibbs@scsiguy.com>

   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
davem@redhat.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Adaptec AIC7XXX v 6.0.6 BETA Released

[Justin T. Gibbs]

>   Date: 	Wed, 13 Dec 2000 20:56:08 -0700
>   From: "Justin T. Gibbs" <gibbs@scsiguy.com>
>
>   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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Adaptec AIC7XXX v 6.0.6 BETA Released

[Alan Cox]

> 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





-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Adaptec AIC7XXX v 6.0.6 BETA Released

[Justin T. Gibbs]

>> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Adaptec AIC7XXX v 6.0.6 BETA Released

[Martin Dalecki]

"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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Adaptec AIC7XXX v 6.0.6 BETA Released

[Justin T. Gibbs]

>
>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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Adaptec AIC7XXX v 6.0.6 BETA Released

[Martin Dalecki]

"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 ;-).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Adaptec AIC7XXX v 6.0.6 BETA Released

[Alan Cox]

> 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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Adaptec AIC7XXX v 6.0.6 BETA Released

[Gérard Roudier]

On Wed, 13 Dec 2000, Justin T. Gibbs wrote:

> >   Date: 	Wed, 13 Dec 2000 20:56:08 -0700
> >   From: "Justin T. Gibbs" <gibbs@scsiguy.com>
> >
> >   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.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Adaptec AIC7XXX v 6.0.6 BETA Released

[Alan Cox]

> 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


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Adaptec AIC7XXX v 6.0.6 BETA Released

[Justin T. Gibbs]

>> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Adaptec AIC7XXX v 6.0.6 BETA Released

[Steven N. Hirsch]

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


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Adaptec AIC7XXX v 6.0.6 BETA Released

[Justin T. Gibbs]

>> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Adaptec AIC7XXX v 6.0.6 BETA Released

[Matthew Jacob]

> 
> 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.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Adaptec AIC7XXX v 6.0.6 BETA Released

[Alan Cox]

> 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)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Adaptec AIC7XXX v 6.0.6 BETA Released

[Justin T. Gibbs]

>> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Adaptec AIC7XXX v 6.0.6 BETA Released

[Alan Cox]

> 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.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Adaptec AIC7XXX v 6.0.6 BETA Released

[Alan Cox]

> 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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Adaptec AIC7XXX v 6.0.6 BETA Released

[Andi Kleen]

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Adaptec AIC7XXX v 6.0.6 BETA Released

[Alan Cox]

> > 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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Adaptec AIC7XXX v 6.0.6 BETA Released

[Steven N. Hirsch]

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Adaptec AIC7XXX v 6.0.6 BETA Released

[J . A . Magallon]

On Wed, 13 Dec 2000 23:15:36 Justin T. Gibbs wrote:
> daptec SCSI HBA device driver for the Linux Operating System
> To: linux-scsi@vger.kernel.org
> 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:jamagallon@able.es                                     #> more beer

Linux werewolf 2.2.18-aa1 #1 SMP Mon Dec 11 21:26:28 CET 2000 i686

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Adaptec AIC7XXX v 6.0.6 BETA Released

[Justin T. Gibbs]

>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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Adaptec AIC7XXX v 6.0.6 BETA Released

[J . A . Magallon]

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:jamagallon@able.es                                     #> more beer

Linux werewolf 2.2.18-aa1 #1 SMP Mon Dec 11 21:26:28 CET 2000 i686

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Adaptec AIC7XXX v 6.0.6 BETA Released

[Christoph Hellwig]

In article <200012132215.eBDMFas35908@aslan.scsiguy.com> 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Adaptec AIC7XXX v 6.0.6 BETA Released

[Justin T. Gibbs]

>In article <200012132215.eBDMFas35908@aslan.scsiguy.com> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Adaptec AIC7XXX v 6.0.6 BETA Released

[Steven N. Hirsch]

On Wed, 13 Dec 2000, Justin T. Gibbs wrote:

> daptec SCSI HBA device driver for the Linux Operating System
> To: linux-scsi@vger.kernel.org
> 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



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/