From owner-freebsd-current Wed Dec 6 14:48:56 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA29113 for current-outgoing; Wed, 6 Dec 1995 14:48:56 -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 OAA29096 for ; Wed, 6 Dec 1995 14:48:47 -0800 (PST) Received: by Sysiphos id AA11948 (5.67b/IDA-1.5 for current@freebsd.org); Wed, 6 Dec 1995 23:44:40 +0100 Message-Id: <199512062244.AA11948@Sysiphos> From: se@zpr.uni-koeln.de (Stefan Esser) Date: Wed, 6 Dec 1995 23:44:40 +0100 In-Reply-To: Garrett A. Wollman "Re: sysctl status right now, and plea for testing." (Dec 6, 17:14) X-Mailer: Mail User's Shell (7.2.6 alpha(2) 7/9/95) To: "Garrett A. Wollman" Subject: Re: sysctl status right now, and plea for testing. Cc: current@freebsd.org Sender: owner-current@freebsd.org Precedence: bulk On Dec 6, 17:14, Garrett A. Wollman wrote: } Subject: Re: sysctl status right now, and plea for testing. } < Thanks a LOT ! } } > I've been waiting for this, since I want to make the PCI bus } > and NCR SCSI configuration available via sysctl ... } } devconf has been there as the intended mechanism for this purpose for } over a year now. Yes. But without a dynamic name space it was no use for my purposes. Can't predefine 65536 entries for all possible PCI devices in one system (bus=0..255,slot=0..31,func=0..7). } > hw.bus.pci.bus_0.slot_5.func_0.vendor_id: 0x8086 } > hw.bus.pci.bus_0.slot_5.func_0.device_id: 0x0483 } > hw.bus.pci.bus_0.slot_5.func_0.map.mem32: 0x80fff000 0x00001000 } > hw.bus.pci.bus_0.slot_5.func_0.map.io: 0xd0f0 0x0010 } } Ick. Try more like: } } hw.devconf.pci0.cardids: 0x80860483 0x12345678 .... And what do I do with these numbers ? There might be several memory mappings active at a time for a single chip. Or none at all. } where the actual representation is an array (no need for a separate } count since we know the size) or, perhaps, a string (for easy parsing } by shell programs). Hmm, no, we don't know the size ... } > Don't know which names to use for the NCR SCSI variables. } } hw.devconf.ncr0.whatever } } Unfortunately, in my original implementation of devconf, I made it } rather difficult to implement this. I intend to revisit the design of } devconf soon, so that every device will export at least two variables, } and in most cases probably more: } } hw.devconf.nameUNIT.self - structure giving current `struct } devconf' information } hw.devconf.nameUNIT.parent - structure identifying parent and } device's relationship to it } (i.e., struct isa_device etc.) } hw.devconf.nameUNIT.whatever_the_driver_wants_to_define Ok. Fine. Will wait and see ... } I believe that the second element, in particular, needs to be handled } as a structure because for many sorts of parent attachments, it does } not make any sense at all to separately modify the identity of the } parent or any of the parameters individually. (E.g., you might break } things by changing a device's port without also changing its IRQ, in } the ISA case.) The `self' information might be a structure (as I am } presently inclinde) or it might not; I am certain that it needs to be } segregated and in a well-defined location so that programs can easily } find it. True. } > There should be a way to look at synch. transfer rates, tags, ... } > of each controller, drive, LUN. } } Generic SCSI features should be controlled by a generic SCSI } interface, probably one which uses the present style of scsi(8). Well, if there is a user interface to query system configuration variables (i.e. sysctl), why not use it. I don't see, why the PCI bus configuration (i.e. IRQ mapping, this is NOT a device feature in a PCI system!) should be accessible by sysctl, but the SCSI bus configuration (available devices, device names, supported SCSI features, ...) not. But most important is to have a concept that is flexible enough to make the same user mode program query and possibly set parameters for all SCSI controllers or bus types, IMHO. 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