Stefan Grefen <grefen@hprc.tandem.com> writes:
> Triggert by the discussion of config issues on port-i386 and the various
> arguments pro and contra for the various hacks/kludges that came up,
> I thought about the problem and think we should make a short-Term relief
> for now (sonthing to set interupt and port-masks, even if it means patching
> through /dev/mem (ugly ...).
> For the real fix we should look at the reason for the poblem and not
> only at one symptom.

Yah.  However, i have some issues with some of your solutions.  8-)

Actually, it seems like you're mixing several issues here which really
don't go together:

* dynamic detach
* device 'unique identification', e.g. disk volume identification
* changing device configurations when booting
* changing (adding, removing) device configurations after booted.


> We do have various problems with the existing config framework.
>     1) We can't dynamicly remove devices(besides pcmcia) [ usb and scsi]

There are several 'component issues' that need to be solved here:

* the parent detecting that the device is gone

* the parent detaching the child.

More on this later.


>     2) We can't rescan buses (besides pcmcia)   [usb,scsi and config]

This is mostly a matter of implementing hooks so that devices can be
'kicked' to rescan themselves.

>     3) We can't manually configure devices      [at least config]

What does this mean?

>     4) We don't have a 'device identification system' 
> 	    means reattching a device generates a new one, and does not 
> 	    revive a deconfigured one		[so far only PCMCIA]

So, i'd say that this is Wrong.

If you detach a device, it should go away.  Completely gone.  Not
'flagged inactive', not 'kinda-sorta there.' Gone.  detached.  no
longer a valid device.

In order to do that correctly for busy devices, you need to be able to
block the 'detaching' thread to allow other threads using the device
to wake up and unwind themselves.  We currently have no way to do this, for detachments which are triggered by device removal (e.g. pcmcia).


> Solutition idea:
>     a) Change config-framework so that it can handle 'removing' devices
>        by flagging them offline. 

No.  add code to the config framework so that i removes devices.  I
gave various people involved in the PCMCIA effort code to implement a
'config_detach()' which does the right thing.  Doesn't look like it's
ever made it into the tree, though.


>     b) Add a method to rescan certain devices/buses

Right.  I'd like to see some user-land configuration program that you
could use to generally cause devices to rescan their children, or
something.  basically, each bus which supports scanning becomes a
device node in /dev, and the rescan command is just an ioctl.  (Or,
perhaps maybe more sane, a /dev/config comes into existence and you
specify device names like you do if names to the net code.)

Internal system events should also be able to cause rescans to happen
("hey, you, you've been attached to the docking station now!").


>     c) add a method to interactivly change device-parameters

this should be possible when booting, but after running something else
is in order, e.g. something which allows you to effectively 'add a few
config file device specs' to a kernel, via a module load or something
similar.  "partial" configuration, if you will.


>     d) add a function to the devicetable, where the device generates a
>        n-bit device-ID (n=32 or 64 or 128).

I don't think this is so useful, at least in the context of generic device
handling.


> a) would add a bit in the generic device strutucre and the device will
>    be handled as non existent.
>    Add a function to the devicetable to tell the drive its dormant/restarted.

what does that mean, exactly?  you turn the device switch entry points
into something which handles 'dormant' devices automatically?  Given
that you have to extensively modify most drivers to cope with
'detachment' (be it real detachment, or being made 'dormant', most
aren't written so the _hardware_ device can be removed arbitrarily).

it's cleaner if you just _remove_ the device from the system,
i.e. unconfigure it.  That has several advantages:

	* all of the existing semantics around "is a device there?"
	  are preserved.

	* it allows for dynamic _unloading_ of device drivers, etc.
	  For instance, say you pop in a SCSI pcmcia card.  The 'right
	  thing' is to have it configure itself, loading a driver if
	  necessary, function for a while, then unconfigure itself when
	  you pop it out and unload the driver.


> d) add a function to the devicetable and call this during eg.
>     the probe-face to get a uniqe device-id (eg. md5 hash over
>     CIS, disk patition-name, ...).
>    This helps putting a device back to the same, device-entry if its
>    removed reattached.
>    Add a flag to config to not enable certain devices automaticly.

How do you know that the modem card you just popped in which happens
to be _identical_ is actually the right modem?  etc.  Exact, incorrect
matches _are_ possible, which means that this method is bogus.


In a nutshell, the functionality that i'd like to see is:

	* config_detach() along the lines of the one i've given people
	  in the past.  Complete removal of devices.  (In the
	  cfattach.)  Some fake solution could probably be had, for the
	  fact that we don't have kernel threads.

	* device entry point which says "rescan for children."  This
	  belongs in the cfdriver struct.)

	* method for direct-config bus device drivers to say to a daemon
	  "I have this device here, that i've not a clue about.  What can
	  you do for me."

	* a way to load and unload configuration table entries from user-land.
	  In a perfect world, even be able to 'unload' driver config
	  lines 'hard-coded in' when the kernel was compiled, even if it's
	  not possible to get rid of the drivers themselves.

Taking a more long-term pie-in-the-sky view of kernel building and
configuration, I think i'd like to see a lot more modularity.  Recent
hacking has introduced me to the OpenFirmware 'dropin module' format,
and i'm kind-of wondering if something like that is possible for a
kernel.  You compile a base kernel which has minimal functionality,
and you compile various driver modules, and basically cat them all
together to produce a complete kernel.  It should be relatively easy
then load (or even unload/reclaim the space of) those modules at
run-time, easy to add drivers or similar stuff to an existing kernel.
Or even easy to change/add to the device configuration in an existing
kernel, if the 'kernel configuration data' were its own drop-in
module.  Just an idea that i'll never have time to explore.  *sigh*


cgd
-- 
Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.
Plug: Get your official NetBSD-1.3.2 CDROM set today! http://www.netbsd.com/