Date: Thu, 07 Mar 1996 10:05:55 -0800 From: "Justin T. Gibbs" <gibbs@freefall.freebsd.org> To: Terry Lambert <terry@lambert.org> Cc: imb@scgt.oz.au, stable@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: 2842 and the disappearing file-system :-( Message-ID: <199603071805.KAA26152@freefall.freebsd.org> In-Reply-To: Your message of "Thu, 07 Mar 1996 09:41:16 MST." <199603071641.JAA14037@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>> 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). Perhaps you read it last night, but you certainly acted as if you thought eisaconf worked just like isa_configure() in all of your mail yesturday. > >> >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. An eisa and isa stub routine to what? The routine that collects the IDs? The routine that matches drivers to ids? The routinesx for irq/ioport, etc registration? It sounds like you want me to duplicate the probe in aic7770.c, but prepend everything with isa_ instead of eisa_. All for one card that acts just like an eisa card? What a waste of code and effort. Most isa cards don't care about the eisa ids, so why create yet another interface to them for the few isa cards that do. No matter your aversion to looking for eisa ids in a non eisa machine, it will have to happen regardless if you have a 2842 in your machine. If you don't like it, or don't need it, disable eisa0. >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. I know of one person who has a conceptual problem with this approach(you). Show me one person experiencing actual failures after appling the patch I posted yesturday. > >> >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. You claim it doesn't add more code by saying I can call the same functions. I'm saying I can't. How am I 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. I think everyone who finds a bug and fixes it should get such treatment. >1) The ISA code, unless it's PnP, can't distinguish slots, so it > would have a damn hard time requiring looping through them. You know as well as I do that the eisa slot locations are fixed at 0xz000 for z 0-16. How do you think the eisaconf code finds the eisa ids? I don't see how this is relevent (again). >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. What features does VLB have that make it of any use to differentiate between VLB and ISA probes? >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. It does need to create nodes, but does that mean that the ISA code bperforms a PNP probe and then scans the eisa slot space just to satisfy the 2842? >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. What probe routine? Eisa_match? >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. > I disagree. > > Regards, > Terry Lambert > terry@lambert.org >--- >Any opinions in this posting are my own and not those of my present >or previous employers. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations ===========================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199603071805.KAA26152>