> >>>selects the LIB_RAND feature since it is required.
> >
> > Thanks: will be in u-boot/cmd/Kconfig
> >
> >>Are we lookin at a series of patches, or a concurrent set?
> >
> > At this time a series of three, but I'd take advice on the preferred
> > procedure.
>
> Remember that the goal is to be atomic.
>
> You should be able to build and use U-Boot after each patch.
>
> Also, any changes to existing code that is not changing behavior but
> simply making way for new functionality should be done separately.
> Thanks
> -Joe
A note on this TCP implementation. In TCP the transmitting TCP
guarantees delivery of a stream, and the receiving TCP guarantees
ordered of delivery of the stream. In this implementation The
kernel memory buffer and the TCP sequence number is used to order the stream.
for the application, and the application is the kernel itself. wget is
not considered the application, and does receive packets "out of order."
This places a constraint on the incoming data stream. All
(disordered) packets received before the HTTP header are
ignored, which means the sending TCP will re-transmit them. This forced
re-transmission could be avoided with a change to reprocess the
incoming packet stream back to the first packet received, directly
following processing the TCP header.
This behavior was detected and failed downloads fixed in tests
downloading Linux kernels from the cloud.
Advice on the reset buffer approach are invited. It requires an
interface between the wget application to reset the buffer index.
Joe Thanks, Good advice, based on that the order of 3 patches is:
(1) Prepares the interfaces, no new behavior, CONFIG-TCP is introduced.
net/Kconfig
net/net.c
net/ping.c
include/net.h
(2) Introduces TCP
net/tcp.c
net/tcp.h
net/Makefile
(3) Introduces wget, CONFIG-WGET introduced
cmd/Kconfig
cmd/net.c
net/wget.c
net/wget.h
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
