Skip site navigation (1)Skip section navigation (2)
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>