Date: Thu, 7 Dec 1995 11:55:18 -0500 From: "Garrett A. Wollman" <wollman@lcs.mit.edu> To: Julian Elischer <julian@ref.tfs.com> Cc: current@freebsd.org Subject: Re: sysctl status right now, and plea for testing. Message-ID: <9512071655.AA11802@halloran-eldar.lcs.mit.edu> In-Reply-To: <199512071135.DAA18582@ref.tfs.com> References: <2653.818329287@critter.tfs.com> <199512071135.DAA18582@ref.tfs.com>
next in thread | previous in thread | raw e-mail | index | archive | help
<<On Thu, 7 Dec 1995 03:35:22 -0800 (PST), Julian Elischer <julian@ref.tfs.com> said: > This brings up the point.. > Should we have a single time drivers are called for initialisation, etc.? > I can see the driver being called once on loading or booting > to add devsw entried > once to probe > once to put sysctl stuff in > etc.. My conceptual model right now is the following: early init - create devsw entries and other things that need to point to valid code for the system to work, even if all the code does is return an error devconf registration - tell the user that the device loaded; needs to be done after the memory allocator is working, but doesn't depend on much else probe - see if the device is actually there attach - finish any other setup Currently, the devconf registration stuff is done in the probe stage because the sysinit stuff didn't exist when I was originally writing this thing. Actually, I originally did it in the attach stage, until I realized that we needed a multiuser equivalent of userconfig, so devices which were not found at the pre-configured location could be relocated with the correct parameters. That in turn led me to implement the `state' feature (a la AIX), so that the user and the generic devconf code would know when it was safe to modify the device parameters. (It's also useful tourist information.) Now, here is a list of the things that are broken about my current devconf implementation, and which I plan to fix as soon as I have a whole weekend free to sit down and modify all the drivers: - It's really bogus to transfer everything together by glomming two or three structs of unknown length together. (Bad design decision on my part.) - There's no way for devices to implement individul MIB variables because of the above. - There is no way to distinguish between a ``real device'' that needs to be configured, and a device that, while it represents real hardware, does not require any configuration. The PCI code in particular has this problem; on my system: chip0 Unknown Intel 82434LX (Mercury) PCI cache memory controller chip1 Unknown Intel 82378IB PCI-ISA bridge vga0 Unknown VGA-compatible display device Not only is the state wrong, but there is no `chip' driver, so there needs to be some indication that this doesn't represent something that you would configure in your config file. Even worse, the `vga0' device doesn't belong there at all, since it represents a piece of hardware that belongs to another driver entirely. (That said, it would be nice if there were hooks for PCI VGA and IDE cards in their respective drivers to access the more advanced features which are available to PCI cards. Even then, though, the devices would be registered under the name of the actual configuration-file driver.) > I was thinking of having an 'info' page for each device in devfs > # cat /dev/fd0.info > Floppy Disk > IRQ=6 > DMA=4 > capacity=1.44MB > driver version 1.45 Ick. > I don't quite understand how devconf and sysctl go together.. > do they? Well, they do and they don't. Poul-Henning doesn't like the way I designed devconf, and if I don't do something quickly he'll probably break it completely and add his own thing. This is a needless duplication of effort. -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9512071655.AA11802>