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
|