>>>>> Joerg Wunsch <j...@uriah.heep.sax.de> 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
pgpIb9J96KmcS.pgp
Description: PGP signature
_______________________________________________ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
