Re: [Etherboot-developers] Etherboot codebase - alternate use

[<ebi...@ln...>]

ke...@us... (Ken Yap) writes:

> >How difficult would it be to hack memtest86 to use the etherboot codebase to
> >generate UDP packets to send to a syslog server?  The syslog service can be
> >setup to log to a different file based on IP address.  This would allow
> >testing of a large array of PCs, and logging of the test results for
> >record-keeping purposes.
> >
> >The syslog facility might also be of use to debug driver issues - ones that
> >did not prevent sending of UDP packets.
> 
> It would probably be easier to make memtest86 an optional piece of code
> that can be compiled in for Etherboot. Reason is because of the NIC
> driver and support routines. If you put those in memtest86, they have to
> be maintained and may diverge. Memtest86 is I think the simpler codebase
> and easier to absorb. I don't know how this will play with memtest86's
> author or licensing (I think it's GPL). Embrace and extend? Another
> compelling use for Etherboot? :-)

Yes memtest86 is GPL'd.

It would take some work but finding the infrastructure to do a merger is
an interesting feet.

memtets86 currently does relocation as well but of a different sort, 
and handling all of the issues the relocation creates could be an
interesting issue going in either direction.
 
> >The NIC.C file in the current tree seems a prime candidate for further
> >splitting to multiple files based on protocol (i.e., one for DHCP, one for
> >TFTP, one for UDP, etc.), this also affects the Makefiles, but the advantage
> >would be ease of (ab)use to implement etherboot routines for other purposes,
> >such as the memtest86 hack.
> 
> Have you had a look at 5.1? A lot has been cleaned up. Also 5.1 runs
> relocated from the top of memory and I'm guessing that it will be easy
> to exclude that area from testing.

memtest86 periodically relocates itself during testing so that all of
memory may be tested.

There may be some sense in splitting nic.c I have not thought about it.

For the most part I have come to a halt on working with memtest86.  It
works fairly well, and I find more problems by logging ECC errors
under Linux with a machine at high stress levels.

The prime advantage of merging memtest86 into etherboot would be a
portability increase.

Although if we go that direction we might wind up merging in GRUB
next.

Eric