Subject: Re: Locator values and usage
To: Martin Husemann <email@example.com>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 07/30/1997 16:30:15
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
>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,
>(b) how should that data given in the config file be looked up when the
>driver needs it?
> 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