Date: Thu, 7 Mar 1996 09:41:16 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: gibbs@freefall.freebsd.org (Justin T. Gibbs) Cc: terry@lambert.org, imb@scgt.oz.au, stable@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: 2842 and the disappearing file-system :-( Message-ID: <199603071641.JAA14037@phaeton.artisoft.com> In-Reply-To: <199603062342.PAA10384@freefall.freebsd.org> from "Justin T. Gibbs" at Mar 6, 96 03:42:39 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >> How are they kludged? I haven't seen a single report of eisaconf > >> without detected devices causing problems in a system. Furthermore, > >> if you don't have a 2842 or and eisa machine, you can disable the > >> eisa0 device in your config file. If you do have a 2842, you'd > >> have to read the same bytes of the I/O address space, so it buys > >> you nothing to have a separate probe for it. > > > >Maybe I'm missing something. > > I would guess you didn't even look. Have you looked at eisaconf.c? > or aic7770.c? You have guessed wrong (don't worry, this is the usual guess, and it's usually wrong). > >Why do you have to have a seperate probe? > > RTSL The *WORST* you would *POSSIBLY* need is an EISA nad an ISA stub routine. I *STILL* do not think EISA ID's should be looked for if the system doesn't claim to be an EISA bus. We have *one* example if an EISA/VLB driver where this, through the savings in code necessary to abstract the differences between the EISA and ISA configurations (which should be the same interface anyway). And that example is causing problems for people. > >Why can't you use the same probe routine address in two "driver instances"? > > Eisaconf doesn't work that way at all. You are (intentionally?) missing the point. > >And wouldn't this fix the interrrupt attach problem introduced by the > >eisaconf code in the VLB Adaptec case? > > Because the bug wasn't even in eisaconf. It was in i386/isa/isa.c. 8-P. > >You keep saying you need to duplicate cade -- I don't see it. I see > >that there is a need to duplicate ~32 bytes of data structure to get > >an EISA and non-EISA device instance. Tell me why Im wrong... > > Right now the code for dealing with the 2842 and the 2742 is one > and the same. To do what you propose would mean adding an isa probe > and doing the same looping through the slots that the eisaconf code does > already, although the 2842 probe would have to do it once for each > card probe instead of just creating the device nodes once like the > eisaconf code does. There is simply no reason to break the probe up. > It only adds complexity and code. 1) The ISA code, unless it's PnP, can't distinguish slots, so it would have a damn hard time requiring looping through them. 2) This is a VLB card, not an ISA card. I would not suggest calling the probe from ISA any more than I would suggest calling it from EISA. It is *NOT* an EISA device. 3) The ISA code needs to "create device nodes" in a similar fashion to EISA for PnP. This is a case of confusing ISA devices that can be mapped by a configuration manager with those that can't. Read the Microsoft PnP document. What I suggest is calling the probe in multiple locations with two stub routines: one EISA for eisaconf and one VLB (ISA, barring a fixed handling of VLB). If you want to call this "adding an ISA probe", fine. It's nowhere near the same order of effort as doing that, IMO. I can't fault you on the complexity argument: it will add a bit of logical complexity in the process of providing a logical abstraction. On the other hand, the abstraction can be made orthoganal so that it is easier to document and program to for other devices that can then seperate PnP mapping from driver attachment (substituting ISA PnP for probing in the same way eisaconf substitutes slot iteration for probing), so it seems like an acceptable tradeoff to me. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199603071641.JAA14037>