> > I think it would be very nice to have also unified API for drivers. Now
> > many drivers have own configuration utilities which is not wery good.
On the other hand, that way you can still use the drivers w/o procfs
compile. That leaves you without being able to set AX.25, IP and TCP
paramaters, though.
We have /proc/sys/dev/ for exactly these purposes. While it would
be nice to have somewhat standardized names, it is just policy
and depends of the driver. Z8530drv needs quite a lot of parameters,
for example. Thus the content of /proc/sys/dev/z8530drv/ would look
quite different from /proc/sys/dev/yam/.
> > Most of drivers just need irq/io/dma/number of channels (which in some
> > cases could be replaced by just com/lpt number).
Well, if you only need irq/io/dma you can also use module parameters,
can't you?
> > Plus baudrate, half/full-duplex, txd etc. which should be urgently
> > replaced by one configuration utility since all drivers need 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.
> This is the other thing. I would also like to implement another downcall
> for telling the device driver the channel status (i.e. if there are VCs
> running on the interface, current ppersistence etc.). This could
> be used to drive some LEDs.
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.
We probably need a way to switch to a "ignore DCD" mode (KISS fullduplex)
for a DAMA slave implementation, though.
> This is especially important for use as node system.
s/important/desirable/
> Another thing is interface setup - currently it�s possible to insert
> a device driver module, up an interface and load the ax25 module after-
> wards.
Yup, you've got a race condition, probably a bit tricky to resolve.
There was an article on this matter on linux-kernel by Keith Owens
a couple of days ago.
> As far as unifying configuration tools in concerned, I don�t think we
> can get rid of seperate configuration tools completely. Just think of
> for example the smdiag tool for soundmodem monitoring.
Agreed.
> Parameters as ppersistence, baudrate, txdelay, txtail etc. should - however - really
> be controlled by a AX.25 ioctl() propagating the information down to
> the device driver by another downcall.
Um, are we still talking about DG2FEF's patch? ;-)
TxDelay and TxTail are parameters the DDI shouldn't know about. It is
entirely device specific. 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...
Passing down P-Persistence from the DDI doesn't make much sense even for
KISS TNCs, as the DDI doesn't get DCD status from it anyway, hence it
can't dynamically adjust P-Persistence. All other drivers don't need to
know anyway.
Joerg Reuter http://poboxes.com/jreuter/
And I make my way to where the warm scent of soil fills the evening air.
Everything is waiting quietly out there.... (Anne Clark)
PGP signature
