Re: [PATCH] CONFIG_EISA note in Documentation/Configure.help
[Ouch, I tried to mail this to vger.rutgers.edu again, alan, sorry for the duplicate mail.] In article <[EMAIL PROTECTED]> you write: >Some clues here > >http://www.google.com/search?q=cache:www.korpse.freeserve.co.uk/hardware/pnp/html/escd.html+eisa+data+format=en > >but the original seems to have gone from korpse 8( > >Microsoft have escd.rtf that documents the escd in terms of eisa records thus >gives clues I have the EISA documentations on paper somewhere (I just moved house and things are still a mess), so if you have any specific questions about the EISA configuration formats, I can probably find the binder and look it up for you. /Christer -- "Just how much can I get away with and still go to heaven?" - 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: [PATCH] CONFIG_EISA note in Documentation/Configure.help
[Ouch, I tried to mail this to vger.rutgers.edu again, alan, sorry for the duplicate mail.] In article [EMAIL PROTECTED] you write: Some clues here http://www.google.com/search?q=cache:www.korpse.freeserve.co.uk/hardware/pnp/html/escd.html+eisa+data+formathl=en but the original seems to have gone from korpse 8( Microsoft have escd.rtf that documents the escd in terms of eisa records thus gives clues I have the EISA documentations on paper somewhere (I just moved house and things are still a mess), so if you have any specific questions about the EISA configuration formats, I can probably find the binder and look it up for you. /Christer -- "Just how much can I get away with and still go to heaven?" - 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: [PATCH] CONFIG_EISA note in Documentation/Configure.help
> Some clues here > ... escd.html ... escd.rtf Thanks! I already had the former (but it refers to the EISA spec for most details) will look for the latter. Andries - 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: [PATCH] CONFIG_EISA note in Documentation/Configure.help
> My code does something like
>
> /*
> * EISA board N has a 4-byte ID that can be read from 0xNc80-0xNc83
> * return 0 for success, -1 for failure (no EISA card in slot) and
> * 1 when a card is present but still needs to be configured.
> */
> static int
> get_eisa_id(int board, char *id) {
This is actually a lot like the MCA bus needs but with a slightly different
API.
Some clues here
http://www.google.com/search?q=cache:www.korpse.freeserve.co.uk/hardware/pnp/html/escd.html+eisa+data+format=en
but the original seems to have gone from korpse 8(
Microsoft have escd.rtf that documents the escd in terms of eisa records thus
gives clues
-
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: [PATCH] CONFIG_EISA note in Documentation/Configure.help
On Wed, Nov 15, 2000 at 06:16:00AM -0500, Paul Gortmaker wrote:
> > What use is knowing that a machine has EISA slots? As far as I can see
> > the only use is to ask for the EISA ID of the card.
> > Should we? I collected 1200 .cfg files and estimate that this is
> > less than 10% of what exists - we do not want a data base built
> > into the kernel, I think. But the kernel could collect these
> > EISA IDs at boot time, enabling drivers to inquire.
>
> There could have been an API for EISA card probes if there
> were enough drivers to demand it - but I guess there never was.
> Something like:
>
> if (ioaddr=probe_EISA_ID("abc1234") == 0) return -ENODEV;
I see how to make
if ((slot = probe_EISA_ID("abc1234")) == -1) return -ENODEV;
but have no idea how you want to find an ioaddr.
My code does something like
/*
* EISA board N has a 4-byte ID that can be read from 0xNc80-0xNc83
* return 0 for success, -1 for failure (no EISA card in slot) and
* 1 when a card is present but still needs to be configured.
*/
static int
get_eisa_id(int board, char *id) {
int idaddr = (board << 12) + 0x0c80;
char val;
outb(0xff, idaddr);
val = inb(idaddr);
if (val & 0x80)
return -1;
if ((val & 0xf0) == 0x70)
return 1;
id[0] = val;
id[1] = inb(idaddr+1);
id[2] = inb(idaddr+2);
id[3] = inb(idaddr+3);
return 0;
}
(I looked at this in order to get information in a situation
with several onboard chips. The EISA slot for them is 0,
but there is no obvious way to get at the ioaddr.)
> > (iv) Finally a question: does anyone know of a URL for the
> > EISA standard?
>
> I recall looking about several years ago when I was playing
> with some drivers for old EISA ethernet cards. Never found
> much of anything. A couple of html-docs on a Digital EISA
> box which I found collecting dust in my personal archive of
> junk. (see below)
Thanks! However, I had these same docs.
(Labeled AA-Q0R6C-TET1.)
> > [PS I would like to be mistaken about the impossibility of
> > parsing the EISA configuration area. There is useful info
> > there, e.g. about dma and irq. It would be nice if this info
> > were available.]
>
> I think you are mistaken - I have written several EISA drivers
> for network cards, and at least three of these I wrote having
> never seen the card at all - only the .cfg file - which was
> enough for me to get the card I/O IRQ and so on.
Yes, the file is fine. But I only gave you the EISA configuration area.
Now what do you do? I don't know. As far as I can see only very
machine-dependent things work.
Andries
-
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: [PATCH] CONFIG_EISA note in Documentation/Configure.help
On Wed, Nov 15, 2000 at 06:16:00AM -0500, Paul Gortmaker wrote:
What use is knowing that a machine has EISA slots? As far as I can see
the only use is to ask for the EISA ID of the card.
Should we? I collected 1200 .cfg files and estimate that this is
less than 10% of what exists - we do not want a data base built
into the kernel, I think. But the kernel could collect these
EISA IDs at boot time, enabling drivers to inquire.
There could have been an API for EISA card probes if there
were enough drivers to demand it - but I guess there never was.
Something like:
if (ioaddr=probe_EISA_ID("abc1234") == 0) return -ENODEV;
I see how to make
if ((slot = probe_EISA_ID("abc1234")) == -1) return -ENODEV;
but have no idea how you want to find an ioaddr.
My code does something like
/*
* EISA board N has a 4-byte ID that can be read from 0xNc80-0xNc83
* return 0 for success, -1 for failure (no EISA card in slot) and
* 1 when a card is present but still needs to be configured.
*/
static int
get_eisa_id(int board, char *id) {
int idaddr = (board 12) + 0x0c80;
char val;
outb(0xff, idaddr);
val = inb(idaddr);
if (val 0x80)
return -1;
if ((val 0xf0) == 0x70)
return 1;
id[0] = val;
id[1] = inb(idaddr+1);
id[2] = inb(idaddr+2);
id[3] = inb(idaddr+3);
return 0;
}
(I looked at this in order to get information in a situation
with several onboard chips. The EISA slot for them is 0,
but there is no obvious way to get at the ioaddr.)
(iv) Finally a question: does anyone know of a URL for the
EISA standard?
I recall looking about several years ago when I was playing
with some drivers for old EISA ethernet cards. Never found
much of anything. A couple of html-docs on a Digital EISA
box which I found collecting dust in my personal archive of
junk. (see below)
Thanks! However, I had these same docs.
(Labeled AA-Q0R6C-TET1.)
[PS I would like to be mistaken about the impossibility of
parsing the EISA configuration area. There is useful info
there, e.g. about dma and irq. It would be nice if this info
were available.]
I think you are mistaken - I have written several EISA drivers
for network cards, and at least three of these I wrote having
never seen the card at all - only the .cfg file - which was
enough for me to get the card I/O IRQ and so on.
Yes, the file is fine. But I only gave you the EISA configuration area.
Now what do you do? I don't know. As far as I can see only very
machine-dependent things work.
Andries
-
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: [PATCH] CONFIG_EISA note in Documentation/Configure.help
My code does something like
/*
* EISA board N has a 4-byte ID that can be read from 0xNc80-0xNc83
* return 0 for success, -1 for failure (no EISA card in slot) and
* 1 when a card is present but still needs to be configured.
*/
static int
get_eisa_id(int board, char *id) {
This is actually a lot like the MCA bus needs but with a slightly different
API.
Some clues here
http://www.google.com/search?q=cache:www.korpse.freeserve.co.uk/hardware/pnp/html/escd.html+eisa+data+formathl=en
but the original seems to have gone from korpse 8(
Microsoft have escd.rtf that documents the escd in terms of eisa records thus
gives clues
-
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: [PATCH] CONFIG_EISA note in Documentation/Configure.help
Some clues here ... escd.html ... escd.rtf Thanks! I already had the former (but it refers to the EISA spec for most details) will look for the latter. Andries - 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: [PATCH] CONFIG_EISA note in Documentation/Configure.help
Andries Brouwer wrote: > >(i) I am a bit unhappy about adding configuration options >like this. It regularly happens that I want to compile some kernel >for some machine and have to grep the source and look at the config >files how to enable something. A machine with RTL-8139? Let me see, I apologize: I did not specify that the patch for configure.help was for 2.4.0-test series only. Looking at 2.2.17, there is _no_ CONFIG_EISA. >However, CONFIG_EISA is almost completely superfluous, is not >required at compile time, can easily be tested at run time, >in other words adding such an option is a very stupid thing to do. Well, it got added sometime, and its there now for 2.4.0-testX. I am just trying to fill in the blanks so that the help buttons have something helpful to say. Steven - 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: [PATCH] CONFIG_EISA note in Documentation/Configure.help
Steven Cole wrote: > Well, the CONFIG_EISA option is there. My little patch was just intended to > slightly enlighten those prone to "lets see what this option does". I > compiled test11-pre4 both with and without CONFIG_EISA and the difference is > very slight. Of course, if you had more items with EISA code, this difference > would be bigger. > > 848 -rw-r--r--1 root root 868179 Nov 14 13:32 bzImage > 848 -rw-r--r--1 root root 867973 Nov 14 13:28 bzImage.no_eisa > > The difference probably comes from my 3c59x driver. > > I also uglied up the 3c59x.c code with #ifdef CONFIG_EISA around the > six sections relavant to EISA to see if that would save anything, and the > object file was only 318 bytes smaller, probably not worth the uglyness of > the six ifdefs. That modified code was not used in the above comparison. When !CONFIG_EISA, the global variable 'EISA_bus' is unconditionally zero. Therefore you merely need to test EISA_bus, as existing code already should be doing.. As for 3c59x patches, they should go to the maintainer, Andrew Morton.. Jeff -- Jeff Garzik | Building 1024 | The chief enemy of creativity is "good" sense MandrakeSoft| -- Picasso - 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: [PATCH] CONFIG_EISA note in Documentation/Configure.help
On Tue, Nov 14, 2000 at 03:23:05PM -0500, Jeff Garzik wrote:
> Andries Brouwer wrote:
> > However, CONFIG_EISA is almost completely superfluous, is not
> > required at compile time, can easily be tested at run time,
> > in other words adding such an option is a very stupid thing to do.
>
> Each driver's entry in Config.in should be dependent on its
> CONFIG_{ISA,EISA,PCI,SBUS,...} defines that indicate what buses are
> defined on this particular architecture.
No, it should not. I see no CONFIG_VLB in your list above.
CONFIG_EISA should not be there either.
I said that it is very stupid to pose this question to the user
who configures the kernel. There are far too many config variables
already, and nothing in the kernel needs to know the answer.
That EISA basically is ISA, as far as the kernel is concerned.
That zero code depends on the variable. That nothing is gained
by knowing that the system is supposed to be EISA rather than ISA.
[I discussed the very little that we do not do yet, but might do.]
Andries
-
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: [PATCH] CONFIG_EISA note in Documentation/Configure.help
Jeff Garzik wrote: > >Agreed, for the most part. If you know for sure you don't have an EISA >machine, you can now disable CONFIG_EISA. IMHO ideally one should be >able to eliminate code that is useless on all but a small subset of >working machines. Well, the CONFIG_EISA option is there. My little patch was just intended to slightly enlighten those prone to "lets see what this option does". I compiled test11-pre4 both with and without CONFIG_EISA and the difference is very slight. Of course, if you had more items with EISA code, this difference would be bigger. 848 -rw-r--r--1 root root 868179 Nov 14 13:32 bzImage 848 -rw-r--r--1 root root 867973 Nov 14 13:28 bzImage.no_eisa The difference probably comes from my 3c59x driver. I also uglied up the 3c59x.c code with #ifdef CONFIG_EISA around the six sections relavant to EISA to see if that would save anything, and the object file was only 318 bytes smaller, probably not worth the uglyness of the six ifdefs. That modified code was not used in the above comparison. I am running that modified code right now, BTW. Jeff, I can send you the patch for the hacked up 3c59x.c if you're at all interested. Steven - 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: [PATCH] CONFIG_EISA note in Documentation/Configure.help
Andries Brouwer wrote:
> However, CONFIG_EISA is almost completely superfluous, is not
> required at compile time, can easily be tested at run time,
> in other words adding such an option is a very stupid thing to do.
Each driver's entry in Config.in should be dependent on its
CONFIG_{ISA,EISA,PCI,SBUS,...} defines that indicate what buses are
defined on this particular architecture. Eventually, DaveM and other
Sparc users will be able to directly source drivers/net/Config.in, and
be presented with the correct list of net drivers given their selected
bus(es). Ditto for ARM. Ditto for x86. Etc.
Disabling code by making global var 'EISA_bus' unconditionally zero was
just an added bonus. Helps a tiny bit with embedded platforms.
> [Steven, you understand that I would have written under CONFIG_EISA:
> say Y here - there is never any reason to say N, unless there exists
> hardware where the canonical probing hangs the machine.]
Agreed, for the most part. If you know for sure you don't have an EISA
machine, you can now disable CONFIG_EISA. IMHO ideally one should be
able to eliminate code that is useless on all but a small subset of
working machines.
Jeff
--
Jeff Garzik |
Building 1024 | The chief enemy of creativity is "good" sense
MandrakeSoft| -- Picasso
-
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: [PATCH] CONFIG_EISA note in Documentation/Configure.help
On Mon, Nov 13, 2000 at 05:07:22PM -0700, Steven Cole wrote: > +EISA support > +CONFIG_EISA > + The Extended Industry Standard Architecture (EISA) bus was > + developed as an open alternative to the IBM MicroChannel bus. > + > + The EISA bus provided some of the features of the IBM MicroChannel > + bus while maintaining backward compatibility with cards made for > + the older ISA bus. The EISA bus saw limited use between 1988 and 1995 > + when it was made obsolete by the PCI bus. > + > + Say Y here if you are building a kernel for an EISA-based machine. > + > + Otherwise, say N. Hmm. (i) I am a bit unhappy about adding configuration options like this. It regularly happens that I want to compile some kernel for some machine and have to grep the source and look at the config files how to enable something. A machine with RTL-8139? Let me see, that requires CONFIG_EXPERIMENTAL. (Not today, but until recently.) How do I get FireWire? Also requires CONFIG_EXPERIMENTAL. This CONFIG_EXPERIMENTAL is a very strange option. I know about my hardware, perhaps, but there is no reason to suppose that I know about the progress in development of Linux drivers for this hardware. Instead of having a global CONFIG_EXPERIMENTAL we should have a warning at each place that the driver is alpha. If one does "make xconfig" then one sees a greyed out area, and the sometimes nontrivial puzzle is how to enable it. But with "make menuconfig" one never even sees the option, making configuration even more troublesome: where would FireWire be? Not in the global menu. In what subcategory should I search for it? Again a grep on the kernel source is easier. (ii) In particular about this CONFIG_EISA and the given explanation. I have a computer, yes, several. But do I know whether it has an EISA bus? A week ago I hardly knew what EISA was, and would have been unable to answer. Today I know the answer for a handful of them but have not yet investigated the others. Now, if this knowledge was of major importance for the kernel then perhaps I had to learn about such details. However, CONFIG_EISA is almost completely superfluous, is not required at compile time, can easily be tested at run time, in other words adding such an option is a very stupid thing to do. [Steven, you understand that I would have written under CONFIG_EISA: say Y here - there is never any reason to say N, unless there exists hardware where the canonical probing hangs the machine.] The number of configuration options should be minimized. That is good for the user - fewer questions to answer. That is good for the kernel programmer - fewer boolean combinations of options to worry about. (iii) Now about EISA itself. Recently I worked on the lp486e.c driver for the on board ethernet of some machine with Intel Panther motherboard. The driver is fine, but how do I find the ethernet address? Somewhere in the EISA configuration area. Is it possible to parse this area? Maybe not really - it looks like there are only two places with knowledge about the location and structure of this area: the BIOS and the ECU program, and the details are different for each machine. What use is knowing that a machine has EISA slots? As far as I can see the only use is to ask for the EISA ID of the card. Should we? I collected 600 .cfg files and estimate that this is less than 5% of what exists - we do not want a data base built into the kernel, I think. But the kernel could collect these EISA IDs at boot time, enabling drivers to inquire. Right now there are a few drivers that look at this info privately. (iv) Finally a question: does anyone know of a URL for the EISA standard? Andries [PS I would like to be mistaken about the impossibility of parsing the EISA configuration area. There is useful info there, e.g. about dma and irq. It would be nice if this info were available.] - 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: [PATCH] CONFIG_EISA note in Documentation/Configure.help
On Mon, Nov 13, 2000 at 05:07:22PM -0700, Steven Cole wrote: +EISA support +CONFIG_EISA + The Extended Industry Standard Architecture (EISA) bus was + developed as an open alternative to the IBM MicroChannel bus. + + The EISA bus provided some of the features of the IBM MicroChannel + bus while maintaining backward compatibility with cards made for + the older ISA bus. The EISA bus saw limited use between 1988 and 1995 + when it was made obsolete by the PCI bus. + + Say Y here if you are building a kernel for an EISA-based machine. + + Otherwise, say N. Hmm. (i) I am a bit unhappy about adding configuration options like this. It regularly happens that I want to compile some kernel for some machine and have to grep the source and look at the config files how to enable something. A machine with RTL-8139? Let me see, that requires CONFIG_EXPERIMENTAL. (Not today, but until recently.) How do I get FireWire? Also requires CONFIG_EXPERIMENTAL. This CONFIG_EXPERIMENTAL is a very strange option. I know about my hardware, perhaps, but there is no reason to suppose that I know about the progress in development of Linux drivers for this hardware. Instead of having a global CONFIG_EXPERIMENTAL we should have a warning at each place that the driver is alpha. If one does "make xconfig" then one sees a greyed out area, and the sometimes nontrivial puzzle is how to enable it. But with "make menuconfig" one never even sees the option, making configuration even more troublesome: where would FireWire be? Not in the global menu. In what subcategory should I search for it? Again a grep on the kernel source is easier. (ii) In particular about this CONFIG_EISA and the given explanation. I have a computer, yes, several. But do I know whether it has an EISA bus? A week ago I hardly knew what EISA was, and would have been unable to answer. Today I know the answer for a handful of them but have not yet investigated the others. Now, if this knowledge was of major importance for the kernel then perhaps I had to learn about such details. However, CONFIG_EISA is almost completely superfluous, is not required at compile time, can easily be tested at run time, in other words adding such an option is a very stupid thing to do. [Steven, you understand that I would have written under CONFIG_EISA: say Y here - there is never any reason to say N, unless there exists hardware where the canonical probing hangs the machine.] The number of configuration options should be minimized. That is good for the user - fewer questions to answer. That is good for the kernel programmer - fewer boolean combinations of options to worry about. (iii) Now about EISA itself. Recently I worked on the lp486e.c driver for the on board ethernet of some machine with Intel Panther motherboard. The driver is fine, but how do I find the ethernet address? Somewhere in the EISA configuration area. Is it possible to parse this area? Maybe not really - it looks like there are only two places with knowledge about the location and structure of this area: the BIOS and the ECU program, and the details are different for each machine. What use is knowing that a machine has EISA slots? As far as I can see the only use is to ask for the EISA ID of the card. Should we? I collected 600 .cfg files and estimate that this is less than 5% of what exists - we do not want a data base built into the kernel, I think. But the kernel could collect these EISA IDs at boot time, enabling drivers to inquire. Right now there are a few drivers that look at this info privately. (iv) Finally a question: does anyone know of a URL for the EISA standard? Andries [PS I would like to be mistaken about the impossibility of parsing the EISA configuration area. There is useful info there, e.g. about dma and irq. It would be nice if this info were available.] - 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: [PATCH] CONFIG_EISA note in Documentation/Configure.help
Andries Brouwer wrote:
However, CONFIG_EISA is almost completely superfluous, is not
required at compile time, can easily be tested at run time,
in other words adding such an option is a very stupid thing to do.
Each driver's entry in Config.in should be dependent on its
CONFIG_{ISA,EISA,PCI,SBUS,...} defines that indicate what buses are
defined on this particular architecture. Eventually, DaveM and other
Sparc users will be able to directly source drivers/net/Config.in, and
be presented with the correct list of net drivers given their selected
bus(es). Ditto for ARM. Ditto for x86. Etc.
Disabling code by making global var 'EISA_bus' unconditionally zero was
just an added bonus. Helps a tiny bit with embedded platforms.
[Steven, you understand that I would have written under CONFIG_EISA:
say Y here - there is never any reason to say N, unless there exists
hardware where the canonical probing hangs the machine.]
Agreed, for the most part. If you know for sure you don't have an EISA
machine, you can now disable CONFIG_EISA. IMHO ideally one should be
able to eliminate code that is useless on all but a small subset of
working machines.
Jeff
--
Jeff Garzik |
Building 1024 | The chief enemy of creativity is "good" sense
MandrakeSoft| -- Picasso
-
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: [PATCH] CONFIG_EISA note in Documentation/Configure.help
Jeff Garzik wrote: Agreed, for the most part. If you know for sure you don't have an EISA machine, you can now disable CONFIG_EISA. IMHO ideally one should be able to eliminate code that is useless on all but a small subset of working machines. Well, the CONFIG_EISA option is there. My little patch was just intended to slightly enlighten those prone to "lets see what this option does". I compiled test11-pre4 both with and without CONFIG_EISA and the difference is very slight. Of course, if you had more items with EISA code, this difference would be bigger. 848 -rw-r--r--1 root root 868179 Nov 14 13:32 bzImage 848 -rw-r--r--1 root root 867973 Nov 14 13:28 bzImage.no_eisa The difference probably comes from my 3c59x driver. I also uglied up the 3c59x.c code with #ifdef CONFIG_EISA around the six sections relavant to EISA to see if that would save anything, and the object file was only 318 bytes smaller, probably not worth the uglyness of the six ifdefs. That modified code was not used in the above comparison. I am running that modified code right now, BTW. Jeff, I can send you the patch for the hacked up 3c59x.c if you're at all interested. Steven - 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: [PATCH] CONFIG_EISA note in Documentation/Configure.help
On Tue, Nov 14, 2000 at 03:23:05PM -0500, Jeff Garzik wrote:
Andries Brouwer wrote:
However, CONFIG_EISA is almost completely superfluous, is not
required at compile time, can easily be tested at run time,
in other words adding such an option is a very stupid thing to do.
Each driver's entry in Config.in should be dependent on its
CONFIG_{ISA,EISA,PCI,SBUS,...} defines that indicate what buses are
defined on this particular architecture.
No, it should not. I see no CONFIG_VLB in your list above.
CONFIG_EISA should not be there either.
I said that it is very stupid to pose this question to the user
who configures the kernel. There are far too many config variables
already, and nothing in the kernel needs to know the answer.
That EISA basically is ISA, as far as the kernel is concerned.
That zero code depends on the variable. That nothing is gained
by knowing that the system is supposed to be EISA rather than ISA.
[I discussed the very little that we do not do yet, but might do.]
Andries
-
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: [PATCH] CONFIG_EISA note in Documentation/Configure.help
Steven Cole wrote: Well, the CONFIG_EISA option is there. My little patch was just intended to slightly enlighten those prone to "lets see what this option does". I compiled test11-pre4 both with and without CONFIG_EISA and the difference is very slight. Of course, if you had more items with EISA code, this difference would be bigger. 848 -rw-r--r--1 root root 868179 Nov 14 13:32 bzImage 848 -rw-r--r--1 root root 867973 Nov 14 13:28 bzImage.no_eisa The difference probably comes from my 3c59x driver. I also uglied up the 3c59x.c code with #ifdef CONFIG_EISA around the six sections relavant to EISA to see if that would save anything, and the object file was only 318 bytes smaller, probably not worth the uglyness of the six ifdefs. That modified code was not used in the above comparison. When !CONFIG_EISA, the global variable 'EISA_bus' is unconditionally zero. Therefore you merely need to test EISA_bus, as existing code already should be doing.. As for 3c59x patches, they should go to the maintainer, Andrew Morton.. Jeff -- Jeff Garzik | Building 1024 | The chief enemy of creativity is "good" sense MandrakeSoft| -- Picasso - 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: [PATCH] CONFIG_EISA note in Documentation/Configure.help
Andries Brouwer wrote: (i) I am a bit unhappy about adding configuration options like this. It regularly happens that I want to compile some kernel for some machine and have to grep the source and look at the config files how to enable something. A machine with RTL-8139? Let me see, I apologize: I did not specify that the patch for configure.help was for 2.4.0-test series only. Looking at 2.2.17, there is _no_ CONFIG_EISA. However, CONFIG_EISA is almost completely superfluous, is not required at compile time, can easily be tested at run time, in other words adding such an option is a very stupid thing to do. Well, it got added sometime, and its there now for 2.4.0-testX. I am just trying to fill in the blanks so that the help buttons have something helpful to say. Steven - 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/
