On 01/29/2018 06:30 PM, Duncan Hare wrote: >> The patch is trying to put everything into net.c. This is a mess and >> not where we should head to. > > Not at all. I tried that and it was correctly rejected. The TCP > functions are in tcp.c, and the wget functions in wget.c > > There is no socket. There is no socket analogue. There is no > widespread correct re-ordering of packets, because in a kernel download > the relative address of each block is derived for the tcp sequence > number, and the kernel image in memory itself is in the correct order, > as defined by tcp sequence number.
You wouldn't implement a TCP protocol that cannot be reused to implement other higher protocols? TCP packets are not expected to arrive in sequence. And the length of packets may vary. You need a buffer for a few packets to put them into the right sequence again. > >> >> We should have have one driver per protocol. >> >> The IP driver should enumerate all drivers protocols like TCP and UDP >> that want to listen to it using a Linux list. This way we get rid of >> all those needless #ifdef CONFIGs. Using the list the IP driver will >> hand out packets to the respective higher protocol driver. > > The choice was to make minimal changes to the > current net.c, in consultation with other in the u-boot realm. > >> >> A separate driver shall implement the TCP protocol and provide methods >> to open a socket, to read and write to the socket and to close the >> socket. >> > "shall"? Please do not use the imperative, unless you are approaching > me with money. > >> Next we want a driver for the HTTP protocol. It should have function >> to open a connection, to send a request, to receive a response, and to >> close the connection. If this driver is requested to open a connection >> it shall call the TCP driver to open a socket. It will then receive >> all packets from the relevant IP address on the relevant port until it >> closes the socket. >> > The http protocol is very simple, and consists of a TCP connection and a > header, both for request and response. For first use implementing GET is sufficient. But the structure of the driver should allow to easily add POST and CONNECT. > >> The wget command should be in a separate file. It will call the >> appropriate functions of the HTTP driver to open a connection, post >> the request, receive the response, and finally close the connection. > > It is and it does. It also include the http headers, becâ€ause of their > simplicity. > >> >> The work should start with refactoring the existing coding into >> separate drivers for the existing protocols. When that is completed >> you can start adding TCP relevant code. > > Will you pay for that work? The only thing that needs to be factored out of net.c is the IP protocol. > >> Please, do not send single patches but complete patch series. > > I do the best I can with my limited knowledge of the tools. I have sent > a series. My understand of both git and patman is limited. This is how I send a patch series: git format-patch HEAD~5 -ns --cover-letter --subject-prefix='PATCH v5' Edit the cover letter. Add in each patch after the first --- the changes relative to the prior version of the patch. Add another ---. Put only these files into a directory (let's assume it is named 'patches'). git send-email \ --from="author <aut...@example.com>" \ --to="maintainer <mantai...@example.com" \ --cc="interested <interes...@example.com>" \ --cc=u-boot@lists.denx.de \ patches\* Best regards Heinrich > >> >> Best regards >> >> Heinrich > > > > _______________________________________________ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
