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. 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. 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.
> I sent the patches to you,
> but did not get any response. I concluded that there was no interest. Thus
> I became quite sloppy about placing my #ifdefs during further changes.
Jens, don't give up too easily. Those patches aren't needed for the
current kernel, there is no need to include them into the mainstream
distribution yet.
> 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...) 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.
BTW, it be done completely transparent for any application that
uses ax25-lib.
> 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.
> 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.
> 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?
> and axports stuff
This _has_ to get discussed in detail with the application programmers and
maintainers.
> Comments?
You are free to do that -- but don't expect it will get accepted
widely. BTW, in what regard does /etc/ax25/axports hurt performance?
> Remember the flexnet slogan?: "Itīs like re-inventing the wheel, and doing
> it the right way this time."
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. Doing it the Right Way would be to develop
something like Bluetooth, but for WANs.
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
