From owner-freebsd-hackers Thu Jan 11 11:35:12 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA13407 for hackers-outgoing; Thu, 11 Jan 1996 11:35:12 -0800 (PST) Received: from Sysiphos (Sysiphos.MI.Uni-Koeln.DE [134.95.212.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA13396 for ; Thu, 11 Jan 1996 11:35:04 -0800 (PST) Received: by Sysiphos id AA10845 (5.67b/IDA-1.5 for freebsd-hackers@FreeBSD.ORG); Thu, 11 Jan 1996 20:34:12 +0100 Message-Id: <199601111934.AA10845@Sysiphos> From: se@zpr.uni-koeln.de (Stefan Esser) Date: Thu, 11 Jan 1996 20:34:11 +0100 In-Reply-To: Sujal Patel "Re: PnP problem..." (Jan 10, 21:22) X-Mailer: Mail User's Shell (7.2.6 alpha(2) 7/9/95) To: Sujal Patel Subject: Re: PnP problem... Cc: "Amancio Hasty Jr." , freebsd-hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk On Jan 10, 21:22, Sujal Patel wrote: } Subject: Re: PnP problem... } On Wed, 10 Jan 1996, Justin T. Gibbs wrote: } } > Yes, it would require a lot of work in the ISA area, but the PCI and EISA } > code could be changed to work this way rather easily. My init order } > is slightly different though: } [...] } > The listing is not complete, but you get the idea. You should keep this } > in mind while doing your PnP work since I think this is the approach } > we should be shooting for. First regarding Justin's message: Of course the probe and attach should be seperated, and I intend to change the PCI code accordingly. If I only had time to do it now ... } I have been keeping this in mind while I was coding. To change over to } a scheme that you described would be very simple. Right now, I just } gather the PnP configuration information from the kernel configuration; } this would simply change to information from PCI/EISA/ISA probes, after } the ISA code was cleaned up. } } A couple of quick questions: Is there a unified structure where one can } access the information from PCI/EISA/ISA probes? How well can the ISA } code non-invasively probe devices (currently)? I've been thinking about such a structure, and have written sown some first concepts. PCI seems to be a superset of the features required by EISA or ISA (it can need multiple memory and/or port regions). The data structure does either contain many pointers to arrays (e.g. containing bases, sizes, types of PCI memory mapped I/O regions), or there is an upper limit on the number of such regions, say 4 (which I'd strongly prefer). Don't have my notes here, but I was thinking about something like: struct memmap { unsigned long base; unsigned long size; unsigned long type; } struct iomap { unsigned long base; unsigned long size; unsigned long type; } struct intmap { inthand_t handler; unsigned char irq; unsigned char mode; unsigned char state; } struct devres { struct memmap[4]; struct iomap[4]; struct intmap; }; Regards, STefan -- Stefan Esser, Zentrum fuer Paralleles Rechnen Tel: +49 221 4706021 Universitaet zu Koeln, Weyertal 80, 50931 Koeln FAX: +49 221 4705160 ============================================================================== http://www.zpr.uni-koeln.de/~se