[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE : [lwip-users] BSD API tcp echo server port
From: |
Pettinato, Jim |
Subject: |
RE : [lwip-users] BSD API tcp echo server port |
Date: |
Thu, 26 Apr 2007 15:38:15 -0400 |
Hello
Kieran,
Do you have a
planned timetable on the previously discussed Savannah code repository
structure changes? I've got some stuff that might be interesting to raw API
users... I
hope to soon be able to provide some well tested raw-API sample apps but
don't want to do anything until the new structure is in
place.
Also, a suggestion
on the 'contrib/ports' area... it would be nice if the port entries specified
the platform more completely - i.e. processor + OS (if any)
+ toolchain used. I can envision multiple 68K ports or ARM ports for
example using different OSes or compilers being made
available.
i.e. /lwip/contrib/ports/<processor>/<OS>/<toolchain>
e.g.
/ports/Intel/Win32/VS60/... or ports/Intel/suse/gnu/...
Network interface
drivers are another question in my mind - I've not fully thought out
where they might fit best in this scenario. Perhaps something like
lwip/contrib/drivers/<device>/<os>?
FYI.... I also have recently finished
porting the uIP resolver code to lwIP so it is usable with the raw interface...
I've asked around here before and nobody seems to have missed it or known why it
wasn't included in the original port, but I needed a simple DNS
resolver client so I just did it myself. I looked the full-blown ARES port
that Marc Boucher did and thought it was easier to start with uIP than pare
ARES down to just a resolver that would work with the raw
interface.
Thanks!
-
Jim
On Thu, 2007-04-12 at 08:41 -0400, Pettinato, Jim wrote:
>
Actually, Frederic has suggested something here that I have
previously
> considered recommending... I think it would be much
easier for new
> users to adopt lwIP and much more useful for all
of us when
> adding/maintaining applications if we split the
'contrib' area into
> separate subsections: 1)Ports (os/platform
specific), 2)Apps-raw, and
> 3)Apps-socket.
Thoughts?
That sounds like a good layout.
I intend to as a
first step create an "old" or "archive" directory in
the top of the contrib
module, move everything into that, and then set
up something like you
describe. Maintainers can then move things back
from this old/archive
directory into the new directory structure when
they are brought up to the
new spec. This should mean we only have
things in there that are
maintained. I also intend to create a FILES
readme sort of document
that will list who is maintaining what, so it is
at least a bit more
traceable.
I suspect though that maintainers will be very thin on the
ground,
despite it not being a particularly arduous job, and that the
vast
majority will stay in the old archive. Volunteers
welcome!
I'd also like to assemble a list of externally distributed
ports, as
they would also be of use to others, particularly if they
are
maintained. Any suggestions for this would be welcome
too.
Kieran