[RFC] [WIP] incorporate picotcp into barebox: a small demo

[Antony Pavlov]

On Mon, 26 May 2014 11:45:57 +0200
Lucas Stach <l.stach at pengutronix.de> wrote:

> Am Sonntag, den 25.05.2014, 13:58 +0400 schrieb Antony Pavlov:
> > Hi all!
> > 
> > I have adapted barebox for work with picotcp network stack.
> > 
> > Picotcp is not a small piece of code so I can't easyly send
> > a patch to the barebox maillist. I have put results of my work on github,
> > see mini-howto below.
> > 
> > This picotcp integration is a dirty hack in many ways.
> > We need additional effors for adapting barebox and picotcp
> > for more easy joint operation.
> > 
> > Please express your opinion on my work. I'm awaiting your comments.
> > 
> You forgot to mention one important thing: Why is this change beneficial
> to barebox?

1. For end user barebox in many ways behave like linux shell console

   We have files, standard shell commands, environment etc. It is very convenient!

   But current network code breaks this illusion (e.g. you can't ping a barebox running board).
   The details of network subsystem realisation shape barebox user network modus operandi.

   Adding full-grown but tiny network stack to barebox makes barebox' behaviour
   (from user's point of view) more close to linux shell console.

2. tcp

   IMHO __optional__ TCP support can be beneficial for bootloader.
   E.g. I would like to use widely used telnet protocol for network console.

   See also U-boot mod (https://forum.openwrt.org/viewtopic.php?id=43237),
   http-server enabled U-Boot, less than 64K!

3. ipv6

   Current IPv4 address space is near totaly exhausted
   (see https://www.icann.org/news/announcement-2-2014-05-20-en).
   I suppose with the lapse of time IPv6 will be used even in bootloaders :)
   picotcp gives you IPv6 just now.

4. several simultaneously running network interfaces support

   Imagine a small cluster system.
   The processors of this cluster are connected via special interconnect, and only one
   "master" processor has ethernet connection to the surrounding world. with current
   "single active network device" conception you can't use barebox for connecting "slave" cluster'
   processors to the surrounding world using "master" processor as a gateway.

> Please don't 4get me wrong this is in no way a criticism on your work.

My current picotcp integration is a quick-and-dirty hack. It is below criticism!

> I only skimmed through the branch as of now and can't really comment on
> the change. So please help me out: do you feel the code is
> leaner/cleaner than the existing barebox network support?

It is very difficult to compare existing barebox (u-boot) network code and picotcp.
Picotcp is much more capable!

Picotcp need some work for cleaning. I think that on average barebox code is more clean
that picotcp code (there are too many #ifdefs, some compiler warnings, formatting),
but IMHO it is not very difficult to make it cleaner.

> Or what's your motivation for this?

See my points above. In the end adding full-grown network stack will make barebox
more favourable for users:

  1. new barebox users with linux shell experience will be happy to see habitual 'ifconfig',
'route' commands instead of manipulations with environment variables.

  2. new network stack eventually can result in new applications for barebox.

-- 
Best regards,
  Antony Pavlov