Date: Thu, 07 Dec 1995 10:28:50 -0800 From: "Justin T. Gibbs" <gibbs@freefall.freebsd.org> To: "Garrett A. Wollman" <wollman@lcs.mit.edu> Cc: Julian Elischer <julian@ref.tfs.com>, current@FreeBSD.org Subject: Re: sysctl status right now, and plea for testing. Message-ID: <199512071828.KAA05759@freefall.freebsd.org> In-Reply-To: Your message of "Thu, 07 Dec 1995 11:55:18 EST." <9512071655.AA11802@halloran-eldar.lcs.mit.edu>
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 Why does devconf come before probe? Does this mean we must have devconf information even for devices not installed in the system? How does this work in a world where everything is an LKM? I also prefer to think of the probe stage as either: Tell me where you are or if you can't do that safely Tell me where you could be. This all goes back to the configuration manager thread we had a couple months back. > > attach - finish any other setup Attaches must be able to return failure status and any devconf state for that device removed on failure. > >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.) I don't think this becomes an issue with a configuration manager and LKMs. The device driver won't even be loaded anymore if the device wasn't found and if it was, how does devconf give you the ability to reprobe at another location? > - 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.) This type of communcation between "smart busses" and drivers could be handled by the configuration manager. Say the PCI code finds a VGA card at X address, and registers it with the configuration manager so that sc0, when it probes, can find it and take ownership of it. There will still be other devices in the system that are usefull to know about, but won't have drivers attached to them. We have to deal with those too. >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. Agreed. We need a coherent vision of what we want to do and how to do it first. > >-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 peopl >e >MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations ===========================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199512071828.KAA05759>