Date: Thu, 07 Dec 1995 10:41:27 +0100 From: Poul-Henning Kamp <phk@critter.tfs.com> To: se@ZPR.Uni-Koeln.DE (Stefan Esser) Cc: "Garrett A. Wollman" <wollman@lcs.mit.edu>, current@freebsd.org Subject: Re: sysctl status right now, and plea for testing. Message-ID: <2653.818329287@critter.tfs.com> In-Reply-To: Your message of "Wed, 06 Dec 1995 23:44:40 %2B0100." <199512062244.AA11948@Sysiphos>
next in thread | previous in thread | raw e-mail | index | archive | help
> } devconf has been there as the intended mechanism for this purpose for > } over a year now. It's not like it has ever been documented to a level where too many people would claim to know how it's supposed to work though... :-( > 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). exactly. > } 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: > } > } [...] > > Ok. Fine. Will wait and see ... I will note that I've given up on this attitude on this subject. I have time and time again asked Garrett for a short outline of his ideas. I couldn't even get it out of him when we met in CA last year. Unless he provides working code or docs, I disregard his complaints. > } 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. This is a valid and important point. I would like to point out that even though the same argument was made for SNMPv2 people was so thouroughly disgusted by the "composite variables" that it should make us think again before resorting to using a "struct" approach here. There are several other ways that could and should be used. In fact the row concept from SNMPv2 might be a very good candidate actually... > } > 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). I disagree. drv.ncr0.id4.lun0.sync=1 drv.ncr0.id4.lun0.wide=1 drv.ncr0.id5.lun0.rogue=129 or maybe just (I think I prefer this one): drv.ncr.0.4.0.sync=1 drv.ncr.0.4.0.wide=1 drv.ncr.0.5.0.rogue=129 I'm open to suggestions. > Well, if there is a user interface to query system configuration > variables (i.e. sysctl), why not use it. exactly. > 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. exactly. > 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. exactly. Stefan, do you want the title of "offcial spokesperson for the sysctl rearchitecting project" ? :-) -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2653.818329287>