CONFIG_EISA note in Documentation/Configure.help
PATCH 1/1 CONFIG_EISA note in Documentation/Configure.help
I noticed there was no help section for CONFIG_EISA in Configure.help. Here is a micro patch. Hope this is not "really superfluous" this time.
Steven
diff -urN linux/Documentation/Configure.help.orig
linux/DocumentationConfigure.help
Documentation/Configure.help Mon Nov 13 16:53:45 2000 renamed from Documentation/Configure.help.orig Sat Nov 11 21:41:55 2000 +14 -0
@@ -2482,6 +2482,20 @@ Documentation/mca.txt (and especially the web page given there) before attempting to build an MCA bus kernel. +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. + SGI Visual Workstation support CONFIG_VISWS The SGI Visual Workstation series is an IA32-based workstation
-
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/
Documentation/Configure.help Mon Nov 13 16:53:45 2000 line 2497
Quoted 13 lines · Steven Cole
Documentation/Configure.help Mon Nov 13 16:53:45 2000 renamed from Documentation/Configure.help.orig Sat Nov 11 21:41:55 2000 +13
-0+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/
Quoted 3 lines · Andries Brouwer
However,
CONFIG_EISAis 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.
Quoted 3 lines
[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
Signature · 7 lines
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/
Quoted 8 lines · Jeff Garzik
Quoted 3 lines · Andries Brouwer
However,
CONFIG_EISAis 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/
Quoted 7 lines · Paul Gortmaker
Quoted 6 lines
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.
Quoted 5 lines
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.)
Quoted 8 lines
Quoted 2 lines
(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.)
Quoted 9 lines
Quoted 4 lines
[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/
Quoted 9 lines
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 intget_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
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/
[Ouch, I tried to mail this to vger.rutgers.edu again, alan, sorry for the duplicate mail.]
In article <[email protected]> you write:
Quoted 8 lines
Some clues here
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
Signature · 5 lines
"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/