[driver configuration]
> We have /proc/sys/dev/ for exactly these purposes.
Quiet a nice idea I forgot about. I like that. :-)
> Changing the bitrate and duplex modes should be done by/through the DDI
> as the DDI has to be aware of changes to it.
As we are talking about proc/sysctl interface I think it would be nice
to have the DDI layer serve the options persistence, slottime, txdelay,
txtail, duplex, rx-bitrate (for use with devices which support DPLL
clock regeneration), tx-bitrate (for those who supply tx clock to the
modem from internal baud rate generator). It could propagate those
values down to the device driver which are needed by it (at least
txdelay, txtail, tx- and rx clock settings. That way we would also
automagically have our desired unified name scheme. It could also
provide reasonable default settings. Channel access timings could
be (should? I don�t know....) made dependent on the txdelay parameter
like in flexnet.
> For "normal" status (RTS, DCD) this is the job of the device driver
> anyway, for the anything else: implement an ioctl() or a procfs entry
> for the driver to display additional information on MODEM output and
> let a user space daemon do the job. More flexible and keeps the number
> of downcalls low.
And the number of daemons the user has to run high.
Didn�t you just say that a linux packet-radio setup needs to be easy
to administrate by the end user? ;)
We could also do the channel access parameter calculation in user space.
That would then make 3 daemons (including a routing daemon) altogether.
Or maybe *one* ax25-super-daemon?
> We probably need a way to switch to a "ignore DCD" mode (KISS fullduplex)
> for a DAMA slave implementation, though.
As channel access is done by the DDI layer now the driver does not need
to know about wheter it�s a full duplex channel or not. It simply *has to*
start transmission when rtsfunc is called (bottom of page 25). It�s DDI
module�s job then to make sure that the command to start transmission is
valid in the current channel state.
> TxDelay and TxTail are parameters the DDI shouldn't know about. It is
> entirely device specific.
Yes, it does, since it does channel access timing. Don�t forget that
depending on the transceiver in use txdelay could be up to 250 ms
(e.g. "9600Bd-ready" commercial mobile transceivers from japan).
> We need a way to switch baudrate, agreed,
> and a way to set the "ignore DCD" mode for KISS TNCs and their ilk for
> a DAMA slave implementation. Well, if we really want to support them for
> this mode. My idea is rather to printk() a rude message if someone tries
> to use a device like that on a DAMA master controlled channel...
Hmmm, are KISS TNCs still in use someplace (seriously)?
-- Jens
