mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Sascha Hauer <s.hauer@pengutronix.de>
To: Antony Pavlov <antonynpavlov@gmail.com>
Cc: Kristof Roelants <kristof.roelants@tass.be>,
	barebox@lists.infradead.org,
	Daniele Lacamera <mlists@danielinux.net>,
	Daniele Lacamera <daniele.lacamera@tass.be>,
	Sam Van Den Berge <sam.van.den.berge@tass.be>
Subject: Re: [RFC] [WIP] incorporate picotcp into barebox: a small demo
Date: Tue, 27 May 2014 07:30:45 +0200	[thread overview]
Message-ID: <20140527053045.GL15686@pengutronix.de> (raw)
In-Reply-To: <20140526160933.db2250dd20bc4c385d56c747@gmail.com>

On Mon, May 26, 2014 at 04:09:33PM +0400, Antony Pavlov wrote:
> On Mon, 26 May 2014 11:45:57 +0200
> Lucas Stach <l.stach@pengutronix.de> wrote:
> 
> 
> 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.

These features sound very nice. I hope we can get the binary size
impacts within sensible limits. Is it possible to disable TCP support in
picotcp?

> 
> 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.

That sound more like you should start Linux earlier.

An integration of picotcp which allows to play with real hardware would
be great, even if it's quick and dirty. That would allow us to see the
size impact and the behaviour of the stack without interrupts.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

  reply	other threads:[~2014-05-27  5:31 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-25  9:58 Antony Pavlov
2014-05-26  9:35 ` Daniele Lacamera
2014-05-26  9:45 ` Lucas Stach
2014-05-26 12:09   ` Antony Pavlov
2014-05-27  5:30     ` Sascha Hauer [this message]
2014-05-27  7:52       ` Daniele Lacamera
2014-05-27  9:46     ` Daniele Lacamera
2014-05-27 14:04       ` Antony Pavlov
2014-05-27 17:26         ` Daniele Lacamera
2014-05-29  5:40           ` Antony Pavlov
2014-05-28  6:08         ` Sascha Hauer
2014-05-28  7:23         ` Juergen Borleis
2014-05-28 10:32           ` Antony Pavlov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140527053045.GL15686@pengutronix.de \
    --to=s.hauer@pengutronix.de \
    --cc=antonynpavlov@gmail.com \
    --cc=barebox@lists.infradead.org \
    --cc=daniele.lacamera@tass.be \
    --cc=kristof.roelants@tass.be \
    --cc=mlists@danielinux.net \
    --cc=sam.van.den.berge@tass.be \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox