Although I like GRUB and I like "minimized" IP plus all services
(NFS, TELNET, etc), I am not sure if this is a good idea to add
telnet and a complex NFS (more than etherboot does). We never should
forget, we are writing a boot loader here not a complete OS !!!
A bootload should be a small software which is even able to be promable
and to be used instead of the today silly BIOS (ok, I dream, but ....).
I think there are more important issues to talk about, concerning the
basic boot loader function:
For example should there be a possibility for paramter parsing in
special marked boot modules. If one module (loaded by GRUB) is used
as environment block, for example, it would be nice the have
possibilities to do following:
LOCAL_IP_ADDR=$$GRUB_BOOTP_IP
or similar things. '$$' is used to distinguish between 'normal' used
variables, and variables GRUB should fill in (this syntax is only an
example !!)
The `module' command, must have an option like `--parse' to define:
* the module is an ASCII text
* the module includes '$$' tokens, which have to be interpreted
and the values have to be filled in.
If the module is not an ASCII file, then -> error.
Another possibility is to define a environment in GRUB, which is used
inside GRUB and the OS. In this case a special way is needed to pass
it by the MultiBoot protocol, but this violates the standard used up
to now, so we can forget it.
A further extension is, that the parser of the command `module'
should also handle `if' statements.
Also the `menu.lst' file should be parsable.
The idea of all that is:
------------------------
There are many equal target machine (diskless clients) and they should
boot the same OS from the same server. Further the target machines
are not able to do a Auto-IP booting, so the machines must get there
IP address via environment file (module). So I have to write and
maintain `n' environment files for `n' machines. Otherwise I need one.
The same is true for config files.
I thinks there are some more important things than writing an OS to
boot another OS !!!
With friendly regards
Christoph Plattner
Olivier Galibert wrote:
>
> Now to I've finished building my sandbox computer, I'm going to add
> NFS support to grub. I mean complete nfs support, including multiple
> servers, automatic completion on mountpoints and filenames, and
> someday dns. I have several possible strategies, and I'm not
> completely sure which one to use:
>
> - move the netboot code to etherboot 4.6.7 (which has a minimal nfs
> support), forward port the changes there already is in grub, then
> extend what's there (and do the forward port dance again each time a
> new etherboot version comes out?).
>
> - split the existing netboot code into drivers (left unchanged) and
> protocols (splitting the humungus main.c in the process) and add the
> new ones. Maybe update the drivers to 4.6.7 while I'm at it (which
> should be easy, even in the future, given that there is no reason to
> change _them_).
>
> - trash what is there, and do a drivers/protocols splitted version
> using the oskit drivers (also known as, nicely wrapped freebsd 3.x
> drivers).
>
> - trash what is there, and do a drivers/protocols splitted version
> using the linux 2.4 drivers and maybe even part of its network stack
> we don't need tcp yet, do we? Otoh, it would be nice to be able to
> telnet to grub).
>
> The non-nice part about options 3 and 4 would be the move from a
> lightweight polling network infrastructure to a fully interrupt-driven
> system.
>
> Okuji, Gordon, others, your point of view?
>
> OG.
>
> _______________________________________________
> Bug-grub mailing list
> [EMAIL PROTECTED]
> http://mail.gnu.org/mailman/listinfo/bug-grub
--
-------------------------------------------------------------------------
private: [EMAIL PROTECTED]
company: [EMAIL PROTECTED]
_______________________________________________
Bug-grub mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-grub
