[Still catching up on e-mail]
> 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?
I'd like to be able to add and remove static routes through procfs.
> 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.
Yes, that's one concept I've been thinking about for quite a while,
but we still need static routes in case the daemon is not running and
surely we want to cache routes for a while (think of datagram mode:
asking for the AX.25 path for every datagram will hurt performance
quite badly).
The concept, in one sentence, is: do jobs like this in user space,
but remain operational without the daemon.
> The user
> space program can gather its information from all sorts of sources as
> static (user) entry, listening to traffic
^^^^^^^^^^^^^^^^^^^
"static to the daemon"
> (also via netlink interface, not via AF_PACKET socket monitoring;
*nods*
> however, we need to do some filtering
> in kernel space to avoid performance problems
Latency is the word here. AFAIK the netlink code drops events
on congestion, but I'd need to read the code again to be sure.
> flexnet internode protocol routing information.
Definately one of the most interesting uses. And an interface
for other applications to request routes directly from the daemon
rather than requesting the table from the kernel.
> As I said, listen is already done, but net2kiss really puzzles me.
> Maybe AF_AX25, SOCK_DGRAM orientated?
The problem is that the MAC is now performed by the kernel AX.25.
We probably need a kernel module that just does some basic CDMA
and emulate a KISS TNC to the application.
> You were the one to tell me that the unix way is to have little small
> programs rather than big ones.
Programs, not configuration files. Many small programs can share one
configuration file. BTW, XML can help to avoid conflicts caused by
additions.
> 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?
As I wrote, it's mainly for a startup script. In this regard it is not
much different than /etc/rc.config on SuSE. Of course no tool
(especially basic ones like kissattach) should _depend_ on any configuration
file -- think of embeded systems. I made this proposal to get the ball
rolling for a distribution-independend and flexible start script.
> I know of none. Take slattach for example,
> it allows to specify all relevant pieces of information on the command line.
Indeed -- I wish kissattach would allow that.
> 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.
It isn't.
> As I see it, itīs the task of the distros to centralize the configuration
> information (compare IP interface setup on RedHat for example).
It would make life much easier if we were able to do this independend
of the distribution. For example, every distrib has its own way to
implement IP interface setup, routing and firewalling. It is a pain in
the *rse if you have to administrate a lot of boxes with different
distributions installed (unless you're using DHCP).
> 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.
With XML you have a tree structure -- and it is an open standard, even
a good one. XML support for perl, python, etc exist and only those who
_do_ understand XML will edit that thing by hand.
> Because I do not have the time to maintain everything on my own.
You don't have to. We will see what needs adjustments and what not.
The library will need some tweaks to make use of the new features, but
if you need to change it in a way it breaks operability with existing
applications you are doing something wrong.
> I do not yet understand why an application programmer (e.g. terminal program
> writer) has to access the axports file at all.
For the symbolic port name / device mapping. We can tweak axlib in
a way that it returns the real name instead of the symbolic one by
completely ignoring axports -- but this needs further investigation
and isn't *that* important right now.
> As I understood it the axports file was created to give kernel-ax25 a little
> bit the touch of a NOS-app?
Yes.
73,
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
