On Thu, 27 Apr 2000, Jens David wrote:
> > 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?
Umm.. What is it that is difficult with net2kiss? Taking a quick look it
receives a packet from a network interface, KISS encapsulates it and
writes to a pty. Definitely a PF_PACKET thing, (PF_AX25, SOCK_DGRAM) won't
give you enough of the received packet. Am I missing something here?
Oh, BTW, rxecho also needs to be fixed.
> > 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?
I have understood so but at least node doesn't use them in a way that
would cause any performance issues.
> 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?
The original reason for axports was that interfaces could only be
differentiated by the interface callsign. There was no way to tell the
kernel to "open a connection through device ax0". It needed to be done
by telling the kernel to "open a connection through the interface having
hardware address N0CALL". And this still is the default method.
This would obviously have been very cumbersome to the users without an
abstraction layer of some sort and as long as that was needed, symbolic
names were easy to add.
Now we have bind-to-device and settable interface names so we can start
thinking whether all this is needed. (This btw raises another question:
with the current state of things do we still need unique interface
HW-addresses? If we could get rid of that restriction, it would help a
lot.)
The question is how will the old functionality be phased out and whether
the [ax|nr|rs]ports files still have a place for some other reason. That
needs to be discussed.
--
Tomi Manninen Internet: [EMAIL PROTECTED]
OH2BNS AX.25: [EMAIL PROTECTED]
KP20ME04 Amprnet: [EMAIL PROTECTED]
