> > 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.
Whoa, stop -- let's sort these things:
- P persistence and slot time are MAC sub-layer parameters. Of course they
need to be set there (/proc/sys/net/ax25/<device>/mac/ for example)
Likewise bitrate and different duplex modes -- duplex mode is also a
medium access method, needed for interlinks. There are different IDLE
timeout schemes, BTW. Does someone really need different tx- and rx
bitrates?
- Clock settings and clock modes are highly device and MODEM specific.
This should be done by the device driver, adding this to the DDI would
bloat the interface.
- Similar for tx tail: it is device and MODEM specific. Tx delay is
MODEM and TRX specific, has absolutely nothing to do with MAC, hence:
not part of DDI.
Matthias' DDI implementation has been thoroughly discussed with Jonathan,
Alan and others, BTW. It is important to keep out non-MAC issues from the
DDI, otherwise we'll have an unmaintainable and bloated interface that
nobody understands and bloats the device drivers.
I want to get rid of the whole MAC issues in the device drivers, not
get it back in through the back door.
> That way we would also automagically have our desired unified name scheme.
You are trying to put policy into the kernel. As much as I'd like to
see an unified name scheme -- this will not happen. Furthermore, what
is right for one device is likely inappropriate for another.
[Please take your time to read the flame wa.. threads about GGI and ISDN
subsystem rewrites in the linux-kernel mailing list archives. Especially
read closely what Linus has to say on the subject.]
> It could also provide reasonable default settings.
The MAC layer _cannot_ know reasonable default settings for tx delay and
tx tail.
> Channel access timings could be (should? I donīt know....) made dependent
> on the txdelay parameter like in flexnet.
Um, what? How is this supposed to work? Details?
> And the number of daemons the user has to run high.
Pardon me, you were talking about displaying P-Persistence and other
data somewhere for automated stations by passing down that information
to the device driver. This wouldn't help a user (uid != 0) interested
in this data in any way.
Anyway: what's the big deal to start a small TCL/TK script that parses
the content of /proc/sys/net/ax25/<device>/mac/current_ppersistence
once a second?
> Didnīt you just say that a linux packet-radio setup needs to be easy
> to administrate by the end user? ;)
No, I didn't. I said API changes should not break user applications.
> We could also do the channel access parameter calculation in user space.
This could be done via the netlink interface, sure. And thinking of it,
I like the idea...
> That would then make 3 daemons (including a routing daemon) altogether.
> Or maybe *one* ax25-super-daemon?
Nope, not one huge daemon. The Unix way is to have many little tools
who do exactly one thing, but this thing in a highly configurable and
reliable way. The distribution providers can pick it up and provide a
way to easily install these services with reasonable defaults.
I've written the worst example _not_ how to do it myself (ax25rtd).
That thing is bloated, does it the wrong way and doesn't work reliably.
Matthias' patch does it the right way: provides some information through
the netlink interface and letting the real work done by a simple
(to be written) daemon.
> 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.
I know. But dumb devices like KISS TNCs don't have *rtsfunc(), if
(and make that a big if) we are going to support DAMA slave for those,
we at least need to switch them to full duplex mode to meet the
DAMA spec. [Another issue is that the latency of a frame from the
PC to the TNC is too high in most cases, that's why I'm not sure
if we should support this at all.]
> Yes, it does, since it does channel access timing.
Any MAC scheme that fails without knowing these paramaters
either uses questionable heuristics or the user has a non-working
setup.
> 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).
I know these crappy trx. It simply doesn't work with this configuration.
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
