Joerg Reuter wrote:
>
> Oh my, here we go again...
>
> > Of cause the new kernel needs new tools which will not work with
> > the old kernel.
>
> We need to differ between the tools, the applications and the library.
> My idea is to get rid of some programs altogether (axparms for example)
> and provide the functionality through procfs.
This is surely an interesting idea as long as things are concerned
which are not updated very frequently (i.e. not speed critical stuff).
But all routing stuff should be done via netlink interface, shouldn�t it?
Then we could do all routing stuff in user space with good performance.
If the kernel needs a route, it can ask the user space program. The user
space program can gather its information from all sorts of sources as
static (user) entry, listening to traffic (also via netlink interface,
not via AF_PACKET socket monitoring; however, we need to do some filtering
in kernel space to avoid performance problems with too many kernel/user space
transitions on high speed links, maybe some cache algorithm?), flexnet
internode protocol routing information.
> Some tools (those that
> use AF_PACKET to monitor traffic) need to get updated -- the DDI has
> changed, there is no prepending KISS command byte anymore. That's
> annoying, but only affects very few tools: AFAIK only listen, net2kiss
> and ax25rtd.
Because they are already fixed in my packages. But I think Mat�s decision
to do this was also right (note to avoid flamewar again: when I say "right"
I mean it complies with the rest of the linux kernel policies).
> The later will use the netlink interface, I don't know
> how to fix net2kiss for the new DDI, and listen can easily be tweaked
> to work with all kernels.
As I said, listen is already done, but net2kiss really puzzles me.
Maybe AF_AX25, SOCK_DGRAM orientated?
> > There is a lot of conceptionally
> > wrong stuff in there like dependencies on the stupid axports file and
> > /proc/*-Entries.
>
> That's not wrong stuff at all. /etc/ax25/{ax,nr,rs}ports isn't exactly
> the best solution (try adding new fields...)
You were the one to tell me that the unix way is to have little small
programs rather than big ones. One big central configuration file also differs
from most I have seen before on the network front. Does any other protocol
suite do something like this? I know of none. Take slattach for example,
it allows to specify all relevant pieces of information on the command line.
If I want to attach a simple KISS or 6pack port for test purposes I first
need to edit a configuration file? I do not know if this is right.
As I see it, it�s the task of the distros to centralize the configuration
information (compare IP interface setup on RedHat for example).
> But it has a purpose.
> Personally I'd like to substitute those with _one_ XML configuration
> file. Advantages:
>
> - easily expandable
> - a non-validating XML parser is small and fast
> - tools exist to manipulate it from within various programming
> languages and editors, even on different platforms
>
> And probably doing the same with /etc/ax25d.conf and /etc/node.conf
> (of course changing the name of the files to avoid confusion)
> The only disadvantage: XML can be hard to parse for the human
> reader, but that's the price of flexibility. The scheme bind8
> uses isn't better in this regard.
I really don�t know... In my opinion even the bind8 scheme is by
far too complex to be understood by the majority of people. I liked
more the /proc/sys-approach. This is more flexible. Then somebody
can implement a menu-based configuration program like HP did which
generates simple shell scripts for setup which are more transparent.
> > Also, I will remerge ax25-tools and -apps (I do not see the reason to have
> > two packages here)
>
> Makes life easier for the maintainers.
Why? Because the file size is smaller when a new release comes out? ;)
> > and call the resulting package ax25-utils again. The
> > library will have to be completely reworked, too.
>
> Why, for heaven's sake? You'll break _every_ application that uses
> the shared libraries -- that is a big no-no.
Because I do not have the time to maintain everything on my own. It
takes a lot of time to fit those functions to match the current kernels
capabilities. Do ifconfig or iproute2 use such a library that does ioctl()
calls or parses procfs entries?
> > I do not like those proc-scanning functions
>
> Well, those are for "node" and similar programs to view the
> connection status of other processes. What's wrong with that?
Even if they were always updated to match the current kernel
behaviour (i.e. formatting), or through libax25 I still think
this would be a performance issue. Doesn�t the kernel for example
disable all interrupts while a proc file is accessed (composed) or did
I get this wrong?
> > and axports stuff
>
> This _has_ to get discussed in detail with the application programmers and
> maintainers.
I do not yet understand why an application programmer (e.g. terminal program
writer) has to access the axports file at all. Why not use the socket interface
and ioctl()s as AF_INET applications do? They do not require a ipports file
either, don�t they?
As I understood it the axports file was created to give kernel-ax25 a little
bit the touch of a NOS-app?
> BTW, in what regard does /etc/ax25/axports hurt performance?
It does not hurt performance, but it introduces some additional unneccessary
error sources. And it is just annoying if you like to quickly add an interface
or something. You always have to edit the axports file first. For example
if you try call on an kernel-AX.25 interface that is not yet configured in
axports it simply rejects the attempt. Why? Doesn�t it get all information
it needs from the kernel? This is about further integrating the AX.25
address family into linux, away from the NOS concept.
> So what _is_ the right way? Flexnet surely isn't, it's still doctoring
> on a protocol rooted in a low-speed, low-noise cable-bound environment,
> hacked to work over radio.
It is not doctoring around, it is about trying to make the best of it. If you
like you can call AX.25 a historic mistake. It surely is, but it is one that
is _very_ difficult to correct by now, which is admittedly pretty frustrating.
Undoubtly, if you want to create something new it has to be more or less
compatible. Since deficiencies of AX.25 turn out to be worse on user access
channels the logical solution would be to develop a new user access system.
To be compatible, this system has to be able to "transport" (tunnel?) AX.25
as efficient as possible, to allow network access. Things as flexnet header
compression come in handy at this point.
But we are far from that. We can talk about this again when we have a
usable base (i.e. AX.25 implementation) to build on.
> Doing it the Right Way would be to develop
> something like Bluetooth, but for WANs.
I do not know bluetooth, but as I view it, it should be a mixture of GSM
and wireless ATM, with linear RF designs, channel equilization, ARQ/FEC-hybrid
(depending on operation mode (bulk data/realtime)), efficient TDMA channel
access.
That�s what I�d really like to work on, but I realized that I (sort of) have no
base to build on for this yet.
-- Jens
