Order Tray | Contact Us | Home | SIG Lists

[ax25-layer2] "First Code"

Samuel A. Falvo II sam.falvo at gmail.com
Thu Aug 10 17:35:50 UTC 2006


On 8/10/06, Steve Sampson <k5okc at cox.net> wrote:
> Those whitespace expansions of function calls to make them look like
> structured code really make me dizzy:
>
> erc = bind
> (
>     s,
>     (struct sockaddr *)&lmBindingAddress,
>     sizeof( struct sockaddr_un )
> );

That's so the code can fit on an 80-column display.  However, I agree,
it's a "pretty hack" (I rather like how it looks, but would still
prefer everything to fit on a single line).

> I don't think calloc is very expensive, and initialization is always good:

Anything that relies on malloc() is inherently very slow compared to,
say, a slab allocator.  The problem is that you're allocating a large
number of very small objects.  Slab allocators work by allocating a
*huge* number of small objects all at once, then relying on your own
software to map out which objects are in use or not.  The problem is,
that's one more piece of code I have to write, explain how it works,
etc.

Premature optimiziation is the root of all evil, so I'm avoiding that
road for the time being.

> I don't see any free()'s, but it's something to think about for the shutdown
> code as it develops.

The reason there are no free() calls is because it was too early in
the development stage.  Notice how the code as posted lacks the
ability to detect when sockets die.  The code I have here now detects
this properly, and I feel confident in proceeding with the
implementation of the frame dispatch routines.

When those are done, I'll post a new copy.

> This, after just one cup of coffee.  But hey!  I like the socket interface, and
> while kernel space sounds groovy, I think even Linus has seen the error of
> his ways.  Tanenbaum's Minix became this great big NOS looking monolith.

Linus doesn't see his errors because he doesn't consider them to be
errors; his concern with userspace stuff has always been performance,
not methodological religion.  But CPUs today are so fast that putting
things in userspace no longer introduces *noticable* performance
degradation for most things, so he's slowly adopting more and more
userspace contributions.  Networking is the one great exception -- my
code absolutely won't stand up to 100Mbps AX.25 (e.g., trunking AX.25
frames over 100-base-T) unless you rate-control the packets at the
source, or you find a way to aggregate collected packets so as to
amortize the cost of IPC per frame.

>     "Can the LM be implemented in kernel-space in some way?"
>
>     "No."  :-)

Well, it can be used as the foundation for a kernel implementation,
but I certainly won't be the one to do it, nor do I have any desire
to.  Userspace AX.25 implementations will work just fine for most
applications I can think of.

Thanks for taking a look at the code.  I'm nearing the first
milestone, which is that of a dumb layer-2 software switch, which I
hope to have done by the end of today.  I will notify the group when
it's up.  Hopefully, I'll have some kind of documentation as to how it
all works as well.

-- 
Samuel A. Falvo II




More information about the ax25-layer2 mailing list