In message <87g1exoji1.fsf@netbsd1.cygnus.com>  Chris G. Demetriou wrote:
> 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-)

I don't mind :-)

> 
> 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.

I think they are not completly independend, what the whole thread was about
is a bandaid for installation, so using the stuff above you could
do a:
 - detach		(if attached in wrong place)
 - fiddle with configuration
 - attach                again

This would allow easy adjustments while installing. BTW With manual
config I mean a driver is compiled into the kernel, but the config-entry
tells the system not to probe it unless told by the user. This avoids
the problems where device-probes screw other devices.

[...]

> 
> 
> >     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.

Well and figure out what has changed, thats were the unique ID is handy ...

> 
> >     3) We can't manually configure devices      [at least config]
> 
> What does this mean?

Compile them in but don't automaticly probe.
Really useful if user has a way of changing parameters before doing so.

> 
> >     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.

This is broken :-) 

Two scenarios:
    1) On my Libretto I've only one PCMCIA slot.
       What I want to do is:
	Remove the Ethernet card,
	Insert the Flashdisk from eletronic still camera
	Remove the Flashdisk
	Insert the Ethernet card
	Remove the Ethernet card
	Insert the Flashdisk from eletronic still camera ..

	etc.

    Today I would end up with smc99 and wd180, after some
    iterations, which is completly bogus. With devices realy gone 
    I would have to redo all the network configuration every time.

  2) Scsi:
    If you rescan the SCSI bus and the user has switched the scsi-id of
    two devices what do you do? 
    Assume it's to tape drives? 
    I know you shouldn't do it, but Joe blow will do it and scream if
    his date goes south.

    More common: you turn of one of your disks/tapedrives. 
    Are you going to renumber the remaining ones?

The problem is that there may be device information kept at places where
you don't expect it (May be implicitly in some daemon process). You can't  
delete it all when the kernel wants to unconfigure the drive. (It would
be a major effor I fear doing it on the kernel level only).
I tried that a long time ago (for my old pcmcia code).

> 
> 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.

But you can delete all 'secondary' knowledge of the device. That get nasty 
if you do a bud-rescan.

[...]

> 
> > Solutition idea:

[...]

> 
> 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.)

Maybe as a pseudo filesystem (eg /dev/config/pcmcia ...)
(dodging tomatoes ... oops that was a pumpkin ...)

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

Yes, or on a external scsi-reset ...

> 
> >     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.

Why not all the time? With detaching/removal inplace there is nothing
special to boottime anymore.

> 
> 
> >     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.

It is I can identify my devices during a rescan ...

> 
> 
> > 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).

The kernel calls a function to take down the device, calls a bus specific
function to reclaim io-space/interrupts.
Than switches all entry points to error returns.
This can be hidden in specfs and the generic network interface code.
This gets reversed when the devices is reattached. The device has to be 
able to handle reattchent on a different port/interupt, to be able to 
take advantage of the feature.

There should be an option where the user can say this device is really
gone.

> 
> 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.

I aggree, but 
	1) LKM is not in a state to really allow that (only for the basic
	    driver)
	2) If we go down that path, we should introduce 'virtual devices'
	    like eth[0-n]  etc. in which case the real hardware id of
	    the device is never exported to a real 'user'-process.
> 
> 
> > 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.

Well if I've two identical modems, the CIS may contain a manufacturer 
serial number. 
It would work on ethernetcards, most scsi-devices and can be made to work
with removable devices (Floppy, Zip etc).
The advantage is you prevent a loss if you have to do a rescan.
If a device doesn't have a unique ID you can either use the current time,
which results in a new devices everytime, or a constant number for a 
certain position (pcmcia slot-id).

Incorrect matches are _still_ possible, but without that they are 
guranteed.

> 
> 
> 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.

Ok, but I still vote for 'pseudo' detachment ...

> 
> 	* 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."

I would make that passive, eg. have process asking which devices are in 
which state (up-and-running, unprobed, probe-failed). The daemon would
come in to late anyway.

> 
> 	* 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*

Most SVR4 descands have this already, with different approaches. 
I must say the I would prefer it too. It's so much easier to load/unload
drivers instead of rebooting all the time ...

Stefan
 
> 
> 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/

--
Stefan Grefen                                Tandem Computers Europe Inc.
grefen@hprc.tandem.com                       High Performance Research Center
 --- Hacking's just another word for nothing left to kludge. ---