Re: Adaptec AIC7XXX v 6.0.6 BETA Released
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 1 (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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Adaptec AIC7XXX v 6.0.6 BETA Released
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 1 (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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Adaptec AIC7XXX v 6.0.6 BETA Released
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Adaptec AIC7XXX v 6.0.6 BETA Released
> 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Adaptec AIC7XXX v 6.0.6 BETA Released
> > 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Adaptec AIC7XXX v 6.0.6 BETA Released
> 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Adaptec AIC7XXX v 6.0.6 BETA Released
>> 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Adaptec AIC7XXX v 6.0.6 BETA Released
> 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Adaptec AIC7XXX v 6.0.6 BETA Released
> 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Adaptec AIC7XXX v 6.0.6 BETA Released
On Thu, Dec 14, 2000 at 10:14:51AM +, 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Adaptec AIC7XXX v 6.0.6 BETA Released
> > 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Adaptec AIC7XXX v 6.0.6 BETA Released
>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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Adaptec AIC7XXX v 6.0.6 BETA Released
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Adaptec AIC7XXX v 6.0.6 BETA Released
"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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Adaptec AIC7XXX v 6.0.6 BETA Released
> >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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Adaptec AIC7XXX v 6.0.6 BETA Released
>> 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Adaptec AIC7XXX v 6.0.6 BETA Released
"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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Adaptec AIC7XXX v 6.0.6 BETA Released
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Adaptec AIC7XXX v 6.0.6 BETA Released
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Adaptec AIC7XXX v 6.0.6 BETA Released
>> 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Adaptec AIC7XXX v 6.0.6 BETA Released
>> 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Adaptec AIC7XXX v 6.0.6 BETA Released
>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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Adaptec AIC7XXX v 6.0.6 BETA Released
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.cWed 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Adaptec AIC7XXX v 6.0.6 BETA Released
> 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Adaptec AIC7XXX v 6.0.6 BETA Released
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Adaptec AIC7XXX v 6.0.6 BETA Released
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.cWed 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Adaptec AIC7XXX v 6.0.6 BETA Released
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Adaptec AIC7XXX v 6.0.6 BETA Released
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Adaptec AIC7XXX v 6.0.6 BETA Released
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Adaptec AIC7XXX v 6.0.6 BETA Released
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Adaptec AIC7XXX v 6.0.6 BETA Released
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Adaptec AIC7XXX v 6.0.6 BETA Released
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Adaptec AIC7XXX v 6.0.6 BETA Released
"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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Adaptec AIC7XXX v 6.0.6 BETA Released
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Adaptec AIC7XXX v 6.0.6 BETA Released
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Adaptec AIC7XXX v 6.0.6 BETA Released
"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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Adaptec AIC7XXX v 6.0.6 BETA Released
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Adaptec AIC7XXX v 6.0.6 BETA Released
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Adaptec AIC7XXX v 6.0.6 BETA Released
On Thu, Dec 14, 2000 at 10:14:51AM +, 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Adaptec AIC7XXX v 6.0.6 BETA Released
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Adaptec AIC7XXX v 6.0.6 BETA Released
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Adaptec AIC7XXX v 6.0.6 BETA Released
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Adaptec AIC7XXX v 6.0.6 BETA Released
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Adaptec AIC7XXX v 6.0.6 BETA Released
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Adaptec AIC7XXX v 6.0.6 BETA Released
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Adaptec AIC7XXX v 6.0.6 BETA Released
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Adaptec AIC7XXX v 6.0.6 BETA Released
> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Adaptec AIC7XXX v 6.0.6 BETA Released
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] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Adaptec AIC7XXX v 6.0.6 BETA Released
>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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Adaptec AIC7XXX v 6.0.6 BETA Released
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Adaptec AIC7XXX v 6.0.6 BETA Released
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Adaptec AIC7XXX v 6.0.6 BETA Released
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] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
