[NILO-discuss] s/nilo/gpxe/g
Brought to you by:
marty_connor,
stefanhajnoczi
|
From: Marty C. <md...@en...> - 2005-03-22 22:19:54
|
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
|