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
--- linux/Documentation/Configure.help.orig Sat Nov 11 21:41:55 2000
+++ linux/Documentation/Configure.help Mon Nov 13 16:53:45 2000
@@ -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
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.]
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
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
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
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
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
> 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
>
> (i) I am a bit unhappy about adding configuration options
> like this. It regularly happens that I want to compile some kernel
You are unhappy, I am happy.
Now I can disable some drivers, which I am sure I don't need setting a single
option instead of few.
Also it anables better separation of architecture specyfic drivers:
do you know of Amiga with EISA ? Does my mips support it ?
# grep drivers/net/Config.in arch/*/config.in
arch/alpha/config.in: source drivers/net/Config.in
arch/arm/config.in: source drivers/net/Config.in
arch/i386/config.in: source drivers/net/Config.in
arch/ia64/config.in: source drivers/net/Config.in
arch/mips/config.in: source drivers/net/Config.in
arch/mips64/config.in: source drivers/net/Config.in
arch/ppc/config.in: source drivers/net/Config.in
arch/sh/config.in: source drivers/net/Config.in
> 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.
Look at CML2 project. It supports a function showing all possible options,
if you choose... But it is project for Linux 2.5.
> 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,
But in "make config" you see much more than you want...
> (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.
OK. I tried to build an universal kernel, which supports every hardware &
software kernel drivers I ever needed on i386. It was much too big to
boot... (6 MB compressed)
> 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.
If you have too much memory, you can always choose CONFIG_EISA=y by default.
> [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.
Note, that "number of configuration options should be minimized"
and "fewer questions to answer" are not equivalent.
BTW, CONFIG_MCA needs some cleaning, also.
Andrzej
--
=======================================================================
Andrzej M. Krzysztofowicz [email protected]
tel. (0-58) 347 14 61
Wydz.Fizyki Technicznej i Matematyki Stosowanej Politechniki Gdanskiej
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
> 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&hl=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
> 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
[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&hl=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?"