public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Mike Frysinger <vapier@gentoo.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] RFC: Testing U-Boot Part 1
Date: Fri, 26 Aug 2011 16:55:17 -0400	[thread overview]
Message-ID: <201108261655.18688.vapier@gentoo.org> (raw)
In-Reply-To: <CAPnjgZ18AcXPkWpab3EphYb5Sa-OL3k96y=y59xig=DcnAR5NQ@mail.gmail.com>

On Thursday, August 25, 2011 23:32:38 Simon Glass wrote:
> 1. What should I call the architecture? I have so far called it 'native'.
> 2. What should I call the vendor (board/xxx)? 'test' or 'sandbox'?
> 3. What should I call the board? Is that 'sandbox'?

as Graeme said, just call them all "sandbox"

> 4. When I create a driver, like the serial test driver, should that be
> serial_test.c, test_serial.c, sandbox_serial or something else?

i think it depends on its function.  if the serial driver actually goes to 
std{in,err,out}, then perhaps "serial/sandbox_stdio.c".  let's not assume 
we'll only ever have one pseudo driver that we can use under the sandbox :).

> Wolfgang Denk: I'm not sure what you mean by "a mocked remote host".
> We should be
> able to send and receive packets from a real network interface as
> well.
> 
> - I mean that the tftp command will 'obtain' a file when it asks for
> one, although the actual Ethernet layer is mocked and doesn't actually
> go out on the wire. Imagine an Ethernet driver which has a half-baked
> tftp server in it. Yes I also see value in actually using machine
> interfaces since the testing can be more thorough.

why not just build on top of tun/tap ?  then we do get "real" network traffic, 
and you dont have to write your own tftp server because you can simply use the 
same exact one on your development machine that the board would connect to.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20110826/6fb86d74/attachment.pgp 

  parent reply	other threads:[~2011-08-26 20:55 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-25 12:58 [U-Boot] RFC: Testing U-Boot Part 1 Simon Glass
2011-08-25 13:56 ` Andreas Bießmann
2011-08-25 14:56   ` Mike Frysinger
2011-08-25 22:21     ` Marek Vasut
2011-08-25 14:45 ` Marek Vasut
2011-08-25 15:01 ` Mike Frysinger
2011-08-25 18:04   ` Anton Staaf
2011-08-25 23:35   ` Graeme Russ
2011-08-26  3:32     ` Simon Glass
2011-08-26  4:36       ` Graeme Russ
2011-08-26 20:59         ` Mike Frysinger
2011-08-27  0:29           ` Simon Glass
2011-08-26 20:55       ` Mike Frysinger [this message]
2011-08-27  0:25         ` Simon Glass
2011-08-27  2:23           ` Graeme Russ
2011-08-29 22:04             ` Simon Glass
2011-08-29 23:03               ` Graeme Russ
2011-08-25 20:21 ` Wolfgang Denk
2011-08-25 21:18   ` Mike Frysinger

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=201108261655.18688.vapier@gentoo.org \
    --to=vapier@gentoo.org \
    --cc=u-boot@lists.denx.de \
    /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