[NILO-discuss] s/nilo/gpxe/g

[Marty C. <md...@en...>]

 From the

     "A rose by any other name would smell as sweet..."

department.

Michael and I have had a transatlantic phone conversation, and have 
come up with what we think is a good plan for continuing development.

To give some background, I've been having some concerns about the 
clarity of our vision for NILO, and as we have talked, we seemed to be 
coming to a convergence of thought, and this caused me think we should 
rename the project to be clearer about what we're doing.

So, I had the good folks of SourceForge create a new project called 
gpxe.

Here are two reasons why I think this is a good idea:

First, it better matches what I believe we are working to accomplish, 
which is to create  a GPL'ed PXE implementation.  gpxe will be easy for 
people to understand.  It follows a pattern of such things as gawk, 
gcc, gdb, etc.

Second, gpxe.org/net/com were available.  From the standpoint of making 
it easy for people to find us, I think it is good to have 
easy-to-remember domains. We have nilo.org, but nilo.com and nilo.net 
are not available.  It's nice to have control of the most obvious 
namespace.

Now, there will be a little bit of work involved in getting SourceForge 
to do some moving of CVS repositories, but I have agreed to get that 
done, since this name change thing is my idea.  It's worth the effort 
of a few emails.

I will also be happy to move everyone on the nilo-discuss mailing list 
to gpxe-discuss, once everything is set up over there, so that won't 
create extra work for people.

Alright, let's talk about the "vision thing".  I believe our merry band 
has come up with some basic things we agree on.  If I am mistaken, 
please speak up.

1. We will endeavor to follow the PXE specification where possible.

2. Divergences from the specification will be extensions that will only 
be
    available to loaders by explicit request from the user.

After talking to Michael, I believe we agree that implementing a GPL 
PXE is a Good Thing, and that we should work toward that goal as a 
first priority.

Michael wants to add a  specific extension that allows dynamic module 
loading, and for that extension to be in the core.  Personally, I am 
not particularly interested in module loading, but as long as the 
following conditions are met, I think it should be alright as an 
extension.

1. The code to load the modules is able to be a compile-time switch,
    such that the code can be omitted from the object files, as a way
    to save ROM space, and lessen code-path complexity.

2. Even if the code is compiled in, it will only be executed if the 
loader
    requested by the user is of a particular type.  This is to say that
    if the file is pxelinux.0, for example, no extensions would be 
allowed.
    if, however, the file is pxelinux.[z]elf, extensions would be 
enabled,
    because elf files are understood to require extensions.

Beyond those caveats, it is my hope that we can keep the core code 
small, modular, and reasonable uncomplicated.  I find a lot of #ifdefs 
to be distracting, and I'd really like for our code to be pleasant to 
read.

That's pretty much my understanding of where we are now.  Please speak 
up with any thoughts or corrections.  I appreciate your patience with 
the startup process.  I think it is good to get the foundation and 
vision right before trying to build on it, which is why I propose doing 
the name change now.

Comments?

Marty