avr-libc-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[avr-libc-dev] Re: Ethernet & IP networking support?


From: Ivan Shmakov
Subject: [avr-libc-dev] Re: Ethernet & IP networking support?
Date: Mon, 26 Apr 2010 10:33:25 +0700
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)

>>>>> Joerg Wunsch <address@hidden> writes:
>>>>> As Ivan Shmakov wrote:

 >> So, what's about having, say, htonX () and ntohX () functions
 >> in AVR Libc?  These are standard [Posix], ...

 > Well, avr-libc doesn't aim to be a subset of Posix, but rather wants
 > to be a C standard library.  Anyway, I wouldn't mind adding those to
 > the library,

        Great!

 > albeit creating a subdirectory "arpa" just for the purpose of keeping
 > these two macros/inline functions in <arpa/inet.h> looks a little
 > strange.

        Actually, per [1], <arpa/inet.h> should make visible at least
        some of the <netinet/in.h>-defined [2] types (like: in_port_t,
        in_addr_t) and macros.

        And I think that some parts of <netinet/in.h> could be added to
        avr-libc as well (like struct in6addr and the in6addr_*
        constants.)

[1] http://www.opengroup.org/onlinepubs/000095399/basedefs/arpa/inet.h.html
[2] http://www.opengroup.org/onlinepubs/000095399/basedefs/netinet/in.h.html

 > However, that makes less than one percent of a functional IP stack
 > ;-), and as Eric already explained, the remainder of an IP stack
 > wouldn't belong into avr-libc.

        Since there could be different approaches at implementing such a
        stack for 8-bit AVR's, it makes sense for the code to be
        developed as part of separate libraries.  However, the notion of
        the network byte order [3] doesn't depend on the particular IP
        stack implementation and the conversion routines should probably
        be provided by a “standard” library.

        I'm not sure about other related types, macros and functions,
        since while the compatible (IOW, duplicate) versions of these
        are likely to be supplied by the particular IP stack
        implementations, a single embedded IP stack implementation may
        just as well supply a single version to be used on different
        platforms.

        Still, I would expect “standard” services from a “standard”
        library, unless these are proved to be infeasible to implement.
        And the bits of <arpa/inet.h> and <netinet/in.h> mentioned above
        are not.

[3] 
http://www.opengroup.org/onlinepubs/000095399/basedefs/xbd_chap04.html#tag_04_08

 > At best, it could be more on-topic for the companion project
 > avr-corelib, but I think they are still lacking much more basic
 > things than an IP stack.

        Huh?  Google is silent about that project's home page?

 > Btw., SLIP is dead.  PPP replaced it very successfully, and nobody
 > sheds a tear anymore for SLIP.

        Still, I won't try my luck in developing a decent PPP
        implementation for 8-bit AVR.

        Technically, SLIP isn't possible on most of them, too, because
        of a requirement to handle packet lengths up to 1500 bytes or
        so.  However, small-buffer SLIP is clearly possible, and could
        be useful, at least for prototyping purposes and for amateurs.

-- 
FSF associate member #7257

Attachment: pgpG44reDf7nC.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]