Re: [Etherboot-developers] NBP Help

[Peter L. <P.L...@sy...>]

> "Rajesh Shantaram Patharkar" <raj...@ta...> writes:
> >    I have gone through some part of this Etherboot docs. For me it seems
> > that(Looking at documents) etherboot and PXE are same.
> >    Is it true? if not what are the difference between Etherboot and PXE.

Rajesh, could you tell us what you are trying to achieve? Your questions
imply that you are interested in working on PXE, but you don't have a
great deal of experience. It would help a great deal if you could give
us background - I am certainly happy to help with pointers to
information if that result will be a contribution to Etherboot or
another open source package which can help.

When you refer to "PXE", do you mean specifically Intel's PXE spec, or
network booting in general? I have heard people say "PXE" when they just
mean network booting via DHCP / TFTP.

PXE is Intel's specification of an environment which provides network
support in a way somewhat resembling "traditional" BIOS functions. It
uses the existing DHCP and TFTP protocols. The design is, by common
consent, clunky, but then it was intended to retrofit network booting
for the benefit of firmware vendors used to writing a traditional BIOS
and to support of operating systems which used a traditional BIOS.

I cannot imagine anyone *wanting* to use PXE where a better alternative
exists, just in the same way that Linux is a better alternative to
Windows. In the open source community, Etherboot is that better
alternative for firmware and Linux is the better alternative OS. But
most of the world's network boot firmware is PXE, and Microsoft OSs boot
via PXE, so in practise Etherboot must play nicely to gain wider
acceptance. It turned out to be fairly easy for PXE firmware to chain
Etherboot - there has been some progress in getting Etherboot to provide
a PXE environment to an NBP.

To expand on Eric's comments...

> Mostly etherboot implements  standard DHCP and TFTP and handles any
> image size.  In particular I can load a whole image in one pass.
> Resulting in subsecond boot times.  

It's worth pointing out that PXE, and it's uses of NBPs *requires* a 2
stage boot. You'd have to ask Intel why they decided on this.

> PXE has some embrace and extend going on, above standard DHCP && TFTP,
> as well as complicated a set of API for the NBP.  etherboot doesn't
> limit the initial image.  

Etherboot's hardware driver library is used by other code (e.g. GRUB);
the rest of it is the network support, the front end and the loader
which actually starts the new OS (much of this code is embodied in NBI).
A PXE implementation does all this - but in the PXE way.

> Extending etherboot to be a PXE a server would be o.k. as long as it
> didn't mess up the code.  

I see no reason why it would - pxe support should sit on top of the
Etherboot code as a thin compatibility layer, and might be loaded as
part of an NBI image or another chainable module.

> That is the other big difference etherboot as an open source project
> and be extended and fixed, and is generally not buggy.

Most commercial PXE firmware seems to be based on a buggy Intel
implementation. My biggest problem with pxelinux is not of Peter Anvin's
good work in extending syslinux to use PXE, but in the fact that it
relies on PXE, and PXE is usually broken. Actually, it's not just PXE -
recent syslinux work unrelated to network booting has had many problems,
due to broken commercial firmware. Ever tried getting a bugfix to your
system BIOS or nic firmware?

Bugs in Etherboot are rare, and are quickly fixed. Etherboot is an
active project and functionality is being extended. A PXE layer based on
Etherboot would *be* PXE - remember that PXE is an environment, not a
specific vendor's firmware. When Etherboot fully supports PXE it will
without doubt be *better* than any of the commercial vendors!