Martin Husemann writes:

 >I'm a bit confused about the cf_loc values in struct cfdata.
 >I would like to use them for some special runtime configuration options
 >on ISDN devices. This could look like this:
 >
 >teles0 at isa? port 0xd80 irq 5         # the physical controller
 >isdnbus0 at teles0                      # the "line" (BRI)
 >ipp0 at isdnbus0 bchannel 1             # the "PPP over ISDN" device
 >
 >This would be usefull if ipp0 has a "leased line". The b-channel assignement
 >is usualy done dynamicaly by the exchange, but would be forced to the given
 >bchannel locator in the example. This value is used only at connection setup
 >time (a flag in the setup packet). It's got nothing todo with how to talk to
 >the hardware, it's not needed to identify, match or configure the device.
 >It's just a runtime option, that is not going to change during kernel runtime
 >- simmilar to SCSI target/lun <-> device mapping (yeah, we had that thread
 >several times).
 >
 >What I'm not sure about is: (a) should the cf_loc values be used for this

No, it  shouldn't be used for this.

Locators are for locating a child device on a bus.  If you wanted to
write autoconfig code to automagically attach ISDN devices based on
your kernel config, at *device-probe time*, then using locators on an
isdnbus would be a reasonable scheme.

In general, you don't, so it it isn't.

This is about as sensible has having an separate sub-bus on Ethernet
devices and attaching them via some locator (mapped onto ethertypes,
maybe??).


 >(b) how should that data given in the config file be looked up when the
 >driver needs it?

``see above''. 

 > An example of such a lookup could be found in 
 >sys/ipkdb/ipkdb_if.c, where the "disabled" locator is queried by searching
 >through the cfdata array looking for the right driver name and unit number.
 >The values are conveniently passed at match ("probe") time, where they can't
 >be used in my case. They are quite hard to find later (e.g.: at attach time),
 >when they could be easily copied to a flag in struct softc...

Uh, locators are intended for use at both match and attach time.
They're provided at match time via the third argument to your
device-attach routine.  Cast the void* argument to (in our example) a
``struct isdnbus_attach_args *''

The names and order of locators in the structure are of course derived
from the order you declare them in a config file.  But I find it hard
to see why you'd _ever_ want to configure a PPP link in the config
file, unless you had a PVC.


>If config file locators aren't the appreciated way to configure such options,
>they may end in a userland config file parsed by the isdn management daemon,
>which scatters the information but is not a realy problem (say: you wouldn't
>specify phone numbers and passwords in a kernel config file).

If it's not a problem, then Just Do It. Collect all the info in one
place, in a config file for the ISDN management daemon. It's not like
you can actually start PPP until you talk to the TelCo's exchange a
and place a ``call'', is it?

Your way, you'd have to recompile a kernel to switch between
B-channels, or to switch from using one to using two.  That would be
like having to recompile kernels to enable full-duplex on Ethernet