Re: [Etherboot-developers] [COMMIT] Multicast & more.

[Anselm M. H. <an...@ho...>]

On Thursday, 13. June 2002 21:40, Anselm Martin Hoffmeister wrote:
> On Wednesday, 12. June 2002 05:02, Eric W. Biederman wrote:
> > have only included the good bits but I have only tested the merge with
> > my tree to see if it compiles.  Holler if it breaks, something for you/
>
> Image_menu cannot compile, complains about something double defined....
> Just saw it, I will hunt for mknbi-menu instead :-)

OK, I tracked it down to two forward-definitions inside etherboot.c:
There are (lines 550, 551) two function definitions with a char* argument. It 
should be an unsigned char* and everythings works fine, compare bootmenu.c 
definitions. Patch in attachment solves this problem (for me at least...)

> I used the chance of the moment and changed the code to accept the
> following URIs:
>
> "file:"  (0,1 or 3 times "/")  "disk/" (devicenumber, 0..3 allowed only)
> to boot the MBR of a harddrive

[...]

> FILE:
> TFTP:
> NFS:
> X-SLAM: probably for the moment only
> SLAM: probably in the near future, when it's no longer experimental
> TFTM:

OK, I extended this a bit. If you apply the patches (attached), then your 
"Config" knows some more options.

-DURI_SUPPORT
	general support for any uri-like activites. Not needed by the code right 
	know, but who knows. Set it if you want ANY uri support.
To have the URIs for a specific protocol supported, use
-DURI_SUPPORT_<proto>
where <proto> is one of { FILE TFTP NFS SLAM TFTM }
Note that inclusion of URI_SUPPORT_TFTP enables the TFTP code and compiles it 
in, no matter wether the default download proto is NFS (and vice versa). If 
no known string at the beginning of the filename is detected, etherboot will 
fallback to either DOWNLOAD_PROTO_TFTP or .._NFS, which ever you specified. 
So it doesn't break anything to running installations (I hope. Correct me if 
wrong).
Note also that URI_SUPPORT_FILE will only work if CAN_BOOT_DISK is activated.
So if "file:" URI support is activated, "/dev/hda1" will always work. Perhaps 
this can move out in the future, as I dislike this filenames for special 
purpose.
Note further that DOWNLOAD_PROTO_SLAM requires URI_SUPPORT_SLAM and vice 
versa, as SLAM in the moment cannot be default protocol and needs to be 
started with "x-slam:" URI. Same applies to TFTM, which didn't leave my home 
network yet anyway.

For convenience, I allowed using a tilde ~ instead of the colon, as menu 
entries in dhcp.conf are separated by colons. Looks a bit ridiculous, but 
works. I will not mention it further down, just remember "tftp~/filename" is 
valid too.

Perhaps in the future there will be a feature to use different servers inside 
a bootmenu, so I would like to specify the URI syntax open to extension for 
support for an included servername (default the next-server, if given, or the 
computer DHCP/BOOTP replies came from):


URI types <proto> = {NFS, TFTP], <filename> starts with exactly ONE slash.
	<proto> : <filename>
	<proto> : / / <filename>

	loads the same file as you would get with DOWNLOAD_PROTO_<proto> and
	specifying <filename>.

	Example:	nfs:/tftpboot/vmlinuz.ltsp

	<proto> : / / <servername> <filename>   [ Not implemented yet ]

	could in some future load <filename> with <proto> from <server>

	Example:	nfs://chymaere.augustinnetz.de/tftpboot/vmlinuz.ltsp

URI type <proto> = SLAM
	This is (not yet) standard protocol, so it must be called (conformantly)
	x-slam : / / <filename>

	It's Eric's job to document this. He will surely when releasing the server 	
	so that anyone can use SLAM.

URI type <proto> = TFTM
	This protocol name is not standardized, although tftp-multicast is in an RFC.
	Documentation will follow on release date.
	x-tftm : / / <servername> <filename>

URI type <proto> = FILE
	file : <device type> / <device id>
	file : / <device type> / <device id>
	file : / / / <device type> / <device id>

	<device type> may currently be one of { disk, floppy }
	For floppy, <device id> may be 0...3 selecting one drive to boot from.
	For harddisk, <device id> may be of the form
	<drive no>
	<drive no> / <partition number>
	where first form loads the MBR of the specified disk.
	Partition number 1..4 select the primary partitions and so on.
	Specifying parition number 0 is not allowed. To have the MBR, just
	omit that partition number stuff.
	Same limits apply to <drive no> and <partition number> as do with
	CAN_BOOT_DISK: max. disk 0..3, partition 1...8 or MBR.

Hope I didn't forget to much. As I have no real CVS access (it behaves too 
strange! Perhaps I should change to debian one day...), Eric you will surely 
be so nice to enter it into CVS to me.

Comments welcome.

Anselm