Date: Wed, 6 Dec 1995 23:44:40 +0100 From: se@zpr.uni-koeln.de (Stefan Esser) To: "Garrett A. Wollman" <wollman@lcs.mit.edu> Cc: current@freebsd.org Subject: Re: sysctl status right now, and plea for testing. Message-ID: <199512062244.AA11948@Sysiphos> In-Reply-To: Garrett A. Wollman <wollman@lcs.mit.edu> "Re: sysctl status right now, and plea for testing." (Dec 6, 17:14)
next in thread | previous in thread | raw e-mail | index | archive | help
On Dec 6, 17:14, Garrett A. Wollman wrote: } Subject: Re: sysctl status right now, and plea for testing. } <<On Wed, 6 Dec 1995 20:25:55 +0100, se@ZPR.Uni-Koeln.DE (Stefan Esser) said: } } > 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 <se@ZPR.Uni-Koeln.DE>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199512062244.AA11948>