demo stuff

[Francis Dupont]

> > => I have to dig in Francisco's file to get the picture of the demo
> > but for a CPE the software is proved to work on MIPS/ARM/etc,
> 
> "a version of" the software is proved to work

=> it is used at > 99% on cheap CPEs so we should not have too bad
surprises. I am more afraid of packaging issues.
(PS: BTW please add ip (iproute2) in the default software list).

> > for the AFTR I resisted to put some assembly to speedup IP checksum.
> > So you should get no issue from the processor itself.
> 
> If it isn't obvious by now, I am a pessimist by nature!

=> so you can only get good surprises...

> I am rather scarred by all the bugs I've hit regarding ipv6 this year,
> and there has been a recent flurry of ipv6 related fixes hitting the
> netdev list for the 3.3 release, that don't seem critical, but as
> we touch several areas of the kernel that are not well maintained
> (encapsulation in particular) I will worry until after I see it work...

=> the AFTR uses the tun interface/tunnel so until someone manages
to break it the code has minimum dependencies with the kernel
(hopefully according to you :-).

> and keep working... for days. weeks. months!

=> I have one bug per year in the AFTR code.

> when it comes to complex software...
> I believe in comprehensive all-up testing, and very little else.

=> in fact you can prove some software, even big, for instance
a C optimizing compiler. So it is not impossible to write bug free
code.

Regards

Francis Dupont <fdupont at isc.org>

PS: sorry but I was a bit busy trying to recover my old iMac
(the hard disk is not sane, I am doing a recover from the time
machine (on a second disk on Firewire) to a new disk I got this
morning (on Firewire too) booted from my laptop in (Firewire again
but I have enough cables) "target mode" as I was not enable to get
a working Lion recovery partition (but my laptop is Snow-Leopard /
Lion so has one).
PPS: it should be fine to identify all the involved hardware
in the schema/picture.