[lwip-users] Re: [lwip] eZ80 port

[David Haas]

I would agree that it would be good not to clutter up lwip with a lot of
ports that the official maintainers cannot verify work. Each port should
have a maintainer, whose responsibility it is to keep that port up to date
and working with the latest lwip. For an official release point, all ports
should be verified by someone. Whether the ports are in a separate CVS
repository or not is immaterial to me.

That being said, I think the unixsim port is too limiting. I think many
people are using or want to use lwip in embedded systems and the unixsim
port is not a good example. It is handy to verify some base functionality,
but as I am finding that in my embedded port I am running into some critical
region and protection issues which apparently did not come out very well.
Also, the driver is not at all a good example for an embedded system. The
group should decide which will be the "base" ports, but I do not think
unixsim can be the only one.

By the way, I think the port I am doing to the 5272 fec is a somewhat more
complete example of a dma-style driver which supports descriptor rings and
transmit cleanup. I also think it is a good example and the Motorola fec is
used in several other chips including some popular PowerPCs. (this was a
shameless plug ;-)

People doing ports often find things in the core which need to be changed. I
certainly did and am continuing to. Some of these might be considered bug
fixes (critical region issues) and some are real functionality improvements
(select in sockets). How is it decided what changes go back into the core? I
don't think you will see the critical region issues I found using unixsim.
Does that mean that the fixes can't go into the core?

I do agree with Jani, that we should not include changes for a specific
compiler bug. A working C compiler is a basic requirement for using lwip.
Changes for a specific architecture should be in the architecture-specific
files only. If an extra set of parenthesis works, I guess I don't have any
objection, but I draw the line at #ifdef for a compiler problem.

By the way, I would like to thank all the people who have worked so hard to
write and maintain lwip in the first place. It has been very useful for me
and my comments all along the line are just about improvements I would like
to make and is in no way a criticism of any work which has gone into lwip
already.

Thanks,
David.



----- Original Message -----
From: "Jani Monoses" <address@hidden>
To: <address@hidden>
Sent: Monday, December 16, 2002 9:38 AM
Subject: Re: [lwip] eZ80 port


> First of all I think that as more and more  ports and drivers are done
> it is necessary to put them in a separate package.lwip-ports or something
> Since no actual improvements are done to core functionality there is no
need
> to include it.
> As far as broken compilers go I am totally against cluterring the code
with even more ifdefs.
> The goal is to make lwip clean and separable of apps and arch dependent
code.
> Again this is my opinion and if somebody has another view let's discuss it
here.
> For working on lwIP it's better to have the clean sources:faster cvs
update and download time,
> relevant cscope or ctags database and grep results..
> so
> RFC: how about making a separate arch module in cvs where people can look
for implementation examples
> or get the desired paltform code, while the lwip module sould contain only
the original unixsim?
>
>
>
> >
> > The compiler error in this case was that the expression:
> >
> >            (u8_t *)seg->p->payload)
> >
> > Was actually compiled as if the following were written:
> >
> >            (u8_t *)seg->p)
> >
> Have you tried explicit casts or more parantheses instead of another var?
>
> > **Unless** TCP_OUT_DEBUG was turned on, in which case it compiled
> > correctly.  As you might imagine, it takes many hours to debug each
> > compiler bug like this. (There are rumors that new compilers, perhaps
> > better, will be available by January.)  In the mean time, I have a
project
> > to complete...:)
>
> Luckily your projects goal is probably about getting lwip to work and not
about getting
> these workarounds in public CVS ;)
>
> Jani.
> [This message was sent through the lwip discussion list.]

[This message was sent through the lwip discussion list.]