[Etherboot-developers] URI-schemes (was: Patch for TFTP-multicast released)

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

Hi list,

for me it seems as if the usage of either "next-server" or the server name 
inside URIs is more or less dshihad. Why not give them both a try? It won't 
do the great deal in codesize.

Even if you harshly dislike any server names in URI, you should keep to the 
standard

proto: / / <servername> : <port> / <path> / <filename>

so don't please use just two slashes followed by the filename. That could be 
annoying to users, esp if the first directory in path is called "boot.net"....
You wouldn't know what tftp://boot.net/vmlinuz.ltsp really means!

Eric had the idea to generally implement a URI parser which wouldn't break 
anything - nice idea. That could even - if supplied - override the 
"next-server" option from dhcp. Imagine the following situation:

I have a dumb terminal in the kitchen (P133-based) without disk. As my 
desktop is not powered 24/7 (but my server is, mostly), on the server there 
is dhcpd and tftpd and tftpd-mcast and so on. But when I test my things, I 
want to have the client get the image from my desktop pc, with menu enabled:

1: Boot LTSP from server.hoffmeister.augustinnetz.de  => /vmlinuz.ltsp (TFTM)
2: Boot Doze from server.hoffmeister.augustinnetz.de   => /doze.img (TFTM)
3: Boot testfile from anselm.hoffmeister.augustinnetz.de => /test/image (NFS)

How could I do this with option "next-server" ? Not at all. And having the 
server name in the URI is the trivial config, and most intuitive, too.

OK, I know that menuing is taken out. (saves code size, so good idea :-) and 
external menu programs could handle that better. But why should they have to 
manipulate two dhcp fields, filename as well as next-server?

Does anyone know a case when there are two succedent slashes inside a 
filename? I don't, so one could easily specify strings containing "//" as 
"reserved" aka "used for URI filename scheme". This would not break the 
default behaviour (no surprises, Ken? said) and offer us URIs. So any string 
of the form

<proto> <colon> <slash> <slash> <rest>

<proto> := 1-6 * [A-Za-z0-9 "-" "_"]

has to be treated as URI. Rest is of the form

<rest> := [ <servername> [ <colon> <portnumber> ]] <path>

with <servername>, <portnumber> optional; <portnumber> support not required.
<servername> must be in IP-dotted-quad (no DNS available) and would simply 
override the next-server; <path> MUST start with a <slash>.

The only exception may happen with <proto> = "FILE", where servername doesn't 
make sense. For that special purpose, we MUST supply the
FILE : / / / disk / 0    format, but as few filenames begin with FILE 
<colon>, we could also allow (anti-standard! but KDE does that too)
FILE : / disk / 0
what my code yet does.

Is this specification enough?

BTW1 {
<portnumber> is something not really needed, except possibly by TFTM, as 
there is a portnumber for that, but if you want to use your TFTP-server with 
multicast capability, why should that proggie also listen on another port, it 
runs on port 69 or so anyway!
}

Of course, my code is really buggy still, but I said that. Released early.
The URI_SUPPORT stuff was a quick hack. Monge that yourselves, I won't resist 
to download some more usable main.c then my own. Eric's idea to be 
implemented... or ask me and I just do it - no priority for me for now. 
Mainly tftm can be tested here :-)

I believe you cannot compile in nfs, tftp, slam and tftm at the same time. 
That would blow up too much... ok, time to search the old 32k EEPROMs.
But it COULD make sense to want to have NFS and TFTP at once. You cannot 
specify DOWNLOAD_PROTO_{NFS|TFTP} at the same time, can you? Which one would 
be default? Should we start some new option naming scheme like this:

DOWNLOAD_PROTO_DEFAULT = {NFS|TFTP|SLAM|TFTM}  sets the fallback case if no 
<proto> is given, cause no URI but a simple filename
DOWNLOAD_PROTO_{NFS|TFTP|SLAM|TFTM} enables support for that specific proto
SUPPORT_URI enables the URI parsing mechanism. 

So something like (I'm not firm in preprocessing directives...)

#if DOWNLOAD_PROTO_DEFAULT = "NFS"
	#define DOWNLOAD_PROTO_NFS
#elif DOWNLOAD_PROTO_DEFAULT = "TFTP"
	[...]
#else
	#define DOWNLOAD_PROTO_DEFAULT="TFTP"
	#define DOWNLOAD_PROTO_TFTP
#endif
#define PROTO_COUNT = 0
#ifdef DOWNLOAD_PROTO_NFS
	#redefine PROTO_COUNT = PROTO_COUNT + 1
#endif
	[similar 3 lines for TFTP... each]

#if (PROTO_COUNT > 1) || defined (CAN_BOOT_DISK)
	// URI support needed anyway
	#define SUPPORT_URI
#endif

could care for consistency.

Again, comments welcome. I have to stress-test my mailbox anyway.

BTW2 {
TFTM tested with LANCE code only. That's what VMware uses, I think, so many 
people could use it. RTL8139 (compushack fastline), NS8390 (ne2k-isa) and 
Via-Rhine (d-link, will be thrown away afterwards, replaced by RTL) to come 
this weekend.
}

Anselm