etherboot-developers — Discussion of developer issues

Re: [Etherboot-developers] Linux World Expo UK; 2-4 September

[Peter L. <P.L...@sy...>]

> I've signed up for a booth at the UK Linux World, but the show
> has been postponed until probably February.  It had previously
> been scheduled for early September.
> 
> So, there should be lots of time to arrange an Etherboot booth,
> assuming they still have room available.

Note that the venue is the Birmingham NEC, NOT in London, despite what
http://www.linuxworld.com/story/33815.htm might say. Amazingly enough,
not everything in Britain is in London... I'm in Oxford, which is an
hour away from the NEC by train. I'd be happy to help (e.g. lug a banner
up there), since I'll go anyway, but I don't know anything about booking
shows. Looking at the web page there is apparently a .org pavilion, but
no details.

BTW, the NEC is next to Birmingham Airport, which has quite a few cheap
European flights, but intercontental travellers still have to come up
from Heathrow or Gatwick.

URLs...
http://www.linuxworld2003.co.uk/
http://www.necgroup.co.uk/visitor/thenec/

Re: [Etherboot-developers] Linux World Expo UK; 2-4 September

[<ja...@Mc...>]

On Wed, 16 Jul 2003, Ken Yap wrote:

> >someone planned to exhibit on the UK Linux World Expo?
> >I could manage to be there and lend a hand wherever needed - San
> >Francisco is now definitively no-chance for me as it is a/ to
> >expensive and b/ just my exam's week.

I've signed up for a booth at the UK Linux World, but the show
has been postponed until probably February.  It had previously
been scheduled for early September.

So, there should be lots of time to arrange an Etherboot booth,
assuming they still have room available.

> 
> Maybe Marty can lend you the banner and you can organise it.
> Half-seriously.
> 
> Does UK LWE also offer a free .org pavillion? Etherboot (and LTSP, and a
> bunch of other OSS projects) could not afford to exhibit without this
> generosity of the sponsor (I think it's HP this coming SF LWE, Marty
> please correct me if I'm wrong).
> 
> LWE is a trade show though. They are necessary, but for me, if you've
> seen one you've seen them all. I'd much rather go to a technical
> conference like (shameless plug)
> 
> http://conf.linux.org.au/

Too bad it cost so damn much to fly from Detroit to Australia.

But, I see on the linux.conf website, they rate themselves up
there with the Ottawa Linux Symposium.  That takes place next
week, and I WILL be there :)


> 
> where half the acronyms being tossed around casually hurt my brain.

Yeah, hurts my brain too.  But, I figure eventually, some of it
will finally make some sense.

Jim McQuillan
ja...@Lt...

Re: [Etherboot-developers] Linux World Expo UK; 2-4 September

[<ke...@et...>]

>someone planned to exhibit on the UK Linux World Expo?
>I could manage to be there and lend a hand wherever needed - San
>Francisco is now definitively no-chance for me as it is a/ to
>expensive and b/ just my exam's week.

Maybe Marty can lend you the banner and you can organise it.
Half-seriously.

Does UK LWE also offer a free .org pavillion? Etherboot (and LTSP, and a
bunch of other OSS projects) could not afford to exhibit without this
generosity of the sponsor (I think it's HP this coming SF LWE, Marty
please correct me if I'm wrong).

LWE is a trade show though. They are necessary, but for me, if you've
seen one you've seen them all. I'd much rather go to a technical
conference like (shameless plug)

http://conf.linux.org.au/

where half the acronyms being tossed around casually hurt my brain.

[Etherboot-developers] Linux World Expo UK; 2-4 September

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

Hello list,

someone planned to exhibit on the UK Linux World Expo?
I could manage to be there and lend a hand wherever needed - San
Francisco is now definitively no-chance for me as it is a/ to
expensive and b/ just my exam's week.

Does someone on this list live "nearby" and organise?

Best regards,
  Anselm Martin Hoffmeister
  Stockholm Projekt Computer-Service
  <an...@ho...>

Re[4]: [Etherboot-developers] Re: Loading kernel over NFS fails (solved!) - FIXED CODE

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

Hello Eric,

> Hmm.  I wonder what would have triggered a stack overflow?  As I
> recall the kernel has a very similar limit for nested symlinks.  For
> the case of booting I have trouble seeing more than one symlink being
> needed so 16 should be plenty.

Quick google'ing gave mention of 5 or 15 as symlinks depth, I think Linus
didn't agree to upping the limit to 15 finally.
I just introduced a constant NFS_MAXLINKDEPTH into CVS (in
etherboot.h), set to 16 to go for sure. At least one thing we
definitively are "better" than the Linux kernel ;-)

I'm not sure it was a stack overflow, but it could have been surely
100 symlinks flying past, and our stack is somehow limited I think. No
matter, as we don't bump into it again. Endless recursion is evil
anyway.

Best regards,
 Anselm Martin Hoffmeister
 Stockholm Projekt Computer-Service
 <an...@ho...>

Re: *** GMX Spamverdacht *** [Etherboot-developers] Re: Loading kernel over NFS fails (solved!) - FIXED CODE

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

Hello Ken,

Tuesday, July 15, 2003, 6:28:42 PM, you wrote:

>>NFS-symlink support should now be in the 5.1 and in the 5.0 trees in
>>CVS. Please have a look also at 5.1. Testing with ".." inside the
>>path, multiple-level-symlinks e.g would be nice - obviously your nfs
>>server behaves different than mine as I got error 21 in the beginning
>>while you had 22 (or the other way round).

> In the interest of more readable code could you possibly use some enums
> or defines for magic values like 5, 21 and 22? You could steal the names
> from /usr/include/linux/nfs.h and add to etherboot.h.

I just commited changes, introducing the constants NFS_READLINK,
NFSERR_ISDIR and NFS_INVAL for 5/21/22 resp.
Error messages should now be able to state if the requested URL is a
directory, not a file. Same if the requested string is invalid.

Best regards,
 Anselm Martin Hoffmeister
 Stockholm Projekt Computer-Service
 <an...@ho...>

Re: Re[2]: [Etherboot-developers] Re: Loading kernel over NFS fails (solved!) - FIXED CODE

[<ebi...@ln...>]

Anselm Martin Hoffmeister <an...@ho...> writes:

> Hello ron,
> 
> >> >The case I am making is that normally you don't export your root
> >> >file system from the server.  Just like tftp where normally all that
> >> >is exported is /tftpboot.   With nfs usually it is some subset of
> >> >the filesystem that is exported.  Which is why I think handling absolute
> >> >paths in a way that gives a reasonable error message is much
> >> >preferable.
> 
> > symlinks are a big problem no matter what you do. I can make a symlink to 
> > another file system easily: 
> 
> > ../../../../../../../somewhere_else/file
> 
> > It can be the same as
> > /somewhere_file/file
> 
> > This is a perfectly valid relative link that can go somewhere else. 
> 
> > I guess I don't see the problem with absolute links that relative links 
> > really solves. Either way, if you talk to a server, and it can't resolve 
> > the link, you'll get an error. 
> 
> > And let us not forget things like:
> foo ->> foo
> 
> > A perfectly useless symlink, but relative and hence acceptable. 
> 
> > I'm not convinced that ruling out abs symlinks is really going to help you 
> > much.

My only thinking is that with relative links there was some extra
context that would help.  But if it is only a little bit of code to
handle absolute as well as relative links I remove all objections.
 
> One more question is user friendly intercaces. Is it intuitive
> interface if absolute symlinks are accepted? I think it is as the file
> requested would have had the exactly same address if given in
> dhcpd.conf in the first place. One thing that could need some
> polishing is the error messages in nfs.c, which I will care for later
> (this evening). If the error messages states clearly "file not found"
> or, resp., "invalid filename", the user should be able to fix his
> config files. Just a pity that distinction between file and directory
> and so on is not so easy without non-trivial changes in nfs.c which I
> not really wanted to do. I think a message if type "This is nor a
> valid file nor a link to a file" would be enough for most users to
> find out where the problems originate. The same is my motivation for
> the display of "Loading syslink:<filename>" when following symlinks:
> This makes finding errors easier.

I like the Loading symlink: message that makes it much clearing what 
is going on.
 
> Anybody disappointed because of the 16 symlinks link depth that I set
> arbitrarily? I had the case that in endless loop a->b->a after several
> dozens (I had no motivation to count them) of symlinks the system hung
> (stack overflow or so?) - so I decided to set an arbitrary limit.

Hmm.  I wonder what would have triggered a stack overflow?  As I
recall the kernel has a very similar limit for nested symlinks.  For
the case of booting I have trouble seeing more than one symlink being
needed so 16 should be plenty.

Eric

Re[2]: [Etherboot-developers] Re: Loading kernel over NFS fails (solved!) - FIXED CODE

[ron m. <rmi...@la...>]

On Tue, 15 Jul 2003, Anselm Martin Hoffmeister wrote:

> Anybody disappointed because of the 16 symlinks link depth that I set
> arbitrarily? I had the case that in endless loop a->b->a after several
> dozens (I had no motivation to count them) of symlinks the system hung
> (stack overflow or so?) - so I decided to set an arbitrary limit.

there's always got to be an arbitrary limit, and yours seems fair.

ron

Re[2]: [Etherboot-developers] Re: Loading kernel over NFS fails (solved!) - FIXED CODE

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

Hello ron,

>> >The case I am making is that normally you don't export your root
>> >file system from the server.  Just like tftp where normally all that
>> >is exported is /tftpboot.   With nfs usually it is some subset of
>> >the filesystem that is exported.  Which is why I think handling absolute
>> >paths in a way that gives a reasonable error message is much
>> >preferable.

> symlinks are a big problem no matter what you do. I can make a symlink to 
> another file system easily: 

> ../../../../../../../somewhere_else/file

> It can be the same as
> /somewhere_file/file

> This is a perfectly valid relative link that can go somewhere else. 

> I guess I don't see the problem with absolute links that relative links 
> really solves. Either way, if you talk to a server, and it can't resolve 
> the link, you'll get an error. 

> And let us not forget things like:
foo ->> foo

> A perfectly useless symlink, but relative and hence acceptable. 

> I'm not convinced that ruling out abs symlinks is really going to help you 
> much.

One more question is user friendly intercaces. Is it intuitive
interface if absolute symlinks are accepted? I think it is as the file
requested would have had the exactly same address if given in
dhcpd.conf in the first place. One thing that could need some
polishing is the error messages in nfs.c, which I will care for later
(this evening). If the error messages states clearly "file not found"
or, resp., "invalid filename", the user should be able to fix his
config files. Just a pity that distinction between file and directory
and so on is not so easy without non-trivial changes in nfs.c which I
not really wanted to do. I think a message if type "This is nor a
valid file nor a link to a file" would be enough for most users to
find out where the problems originate. The same is my motivation for
the display of "Loading syslink:<filename>" when following symlinks:
This makes finding errors easier.

Anybody disappointed because of the 16 symlinks link depth that I set
arbitrarily? I had the case that in endless loop a->b->a after several
dozens (I had no motivation to count them) of symlinks the system hung
(stack overflow or so?) - so I decided to set an arbitrary limit.

Best regards,
 Anselm Martin Hoffmeister
 Stockholm Projekt Computer-Service
 <an...@ho...>

Re: [Etherboot-developers] Re: Loading kernel over NFS fails (solved!) - FIXED CODE

[ron m. <rmi...@la...>]

On Wed, 16 Jul 2003, Ken Yap wrote:

> >The case I am making is that normally you don't export your root
> >file system from the server.  Just like tftp where normally all that
> >is exported is /tftpboot.   With nfs usually it is some subset of
> >the filesystem that is exported.  Which is why I think handling absolute
> >paths in a way that gives a reasonable error message is much
> >preferable.

symlinks are a big problem no matter what you do. I can make a symlink to 
another file system easily: 

../../../../../../../somewhere_else/file

It can be the same as
/somewhere_file/file

This is a perfectly valid relative link that can go somewhere else. 

I guess I don't see the problem with absolute links that relative links 
really solves. Either way, if you talk to a server, and it can't resolve 
the link, you'll get an error. 

And let us not forget things like:
foo -> foo

A perfectly useless symlink, but relative and hence acceptable. 

I'm not convinced that ruling out abs symlinks is really going to help you 
much.

ron

Re: *** GMX Spamverdacht *** [Etherboot-developers] Re: Loading kernel over NFS fails (solved!) - FIXED CODE

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

Hello Ken,

Tuesday, July 15, 2003, 6:28:42 PM, you wrote:

> In the interest of more readable code could you possibly use some enums
> or defines for magic values like 5, 21 and 22? You could steal the names
> from /usr/include/linux/nfs.h and add to etherboot.h.

Will do this later this afternoon.

Best regards,
 Anselm Martin Hoffmeister
 Stockholm Projekt Computer-Service
 <an...@ho...>

[Etherboot-developers] Re: Loading kernel over NFS fails (solved!) - FIXED CODE

[<ke...@et...>]

>NFS-symlink support should now be in the 5.1 and in the 5.0 trees in
>CVS. Please have a look also at 5.1. Testing with ".." inside the
>path, multiple-level-symlinks e.g would be nice - obviously your nfs
>server behaves different than mine as I got error 21 in the beginning
>while you had 22 (or the other way round).

In the interest of more readable code could you possibly use some enums
or defines for magic values like 5, 21 and 22? You could steal the names
from /usr/include/linux/nfs.h and add to etherboot.h.

Re: [Etherboot-developers] Re: Loading kernel over NFS fails (solved!) - FIXED CODE

[<ke...@et...>]

>The case I am making is that normally you don't export your root
>file system from the server.  Just like tftp where normally all that
>is exported is /tftpboot.   With nfs usually it is some subset of
>the filesystem that is exported.  Which is why I think handling absolute
>paths in a way that gives a reasonable error message is much
>preferable.

I think handling the absolute path in the normal way will give you the
error message you want anyway. It will fail when an open of the new
pathname is attempted.  You don't have to craft an error message for the
case where the link starts with /. Security is unchanged. And someone
might possibly have a use for it if they understand where the root of is
when viewed from the client (like in LTSP, which has dangling symlinks
when viewed from the server). ln -s /foo bar does work even if /foo
doesn't currently exist.

Re: Re[2]: *** GMX Spamverdacht *** [Etherboot-developers] Re: Loading kernel over NFS fails (solved!) - FIXED CODE

[<ebi...@ln...>]

Anselm Martin Hoffmeister <an...@ho...> writes:

> Hello Eric,
> 
> Tuesday, July 15, 2003, 2:00:35 PM, you wrote:
> 
> > I would suggest that we error on an absolute symlink.  I have
> > a very hard time seeing how an absolute symlink could be used properly
> > in this context.  I guess in an nfs-root situation it might work.
> 
> > But I keep having visions of absolute symlinks pointing to a different
> > location on the server than on exported nfs subtree.
> 
> My knowledge about NFS is not so great (it just grew yesterday...),
> but AFAIK the absolute symlink to any file in the server tree will
> always be accessible (if it is exported at all) as
> nfs://server/<path>
> This is especially true if it points to a file in the same directory
> in which it lives.

The case I am making is that normally you don't export your root
file system from the server.  Just like tftp where normally all that
is exported is /tftpboot.   With nfs usually it is some subset of
the filesystem that is exported.  Which is why I think handling absolute
paths in a way that gives a reasonable error message is much
preferable.
 
> However making absolute errors go ooops is no great deal, just enter a
> return -22; in the right line in the if-statement, around lines 340
> iirc. This is kind of policy, not necessarily technical decision.

Totally.

> Decide as you like, I'm fine without absolute symlinks anyway. Just in
> response to Ken's mail I though about them at all, previously there
> were only relative links implemented.

I am fine with absolute symlink if someone can make a reasonable case
for them.  But until then I just want to say no.

Eric

Re: [Etherboot-developers] Documentation

[<ke...@et...>]

>I just had a first look into the documentation from CVS.
>I don't understand wether it should reflect etherboot 5.0 or 5.1
>options/usage/... Or is it for the upcoming 5.2 tree?
>May I just change anything to reflect current 5.1 (~coming 5.2) behaviour?

There are two doc trees. You should modify the 5.2 doc tree. Leave the
5.0 doc tree as is.

[Etherboot-developers] Documentation

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

Dear list,

I just had a first look into the documentation from CVS.
I don't understand wether it should reflect etherboot 5.0 or 5.1
options/usage/... Or is it for the upcoming 5.2 tree?
May I just change anything to reflect current 5.1 (~coming 5.2) behaviour?

Best regards,
  Anselm Martin Hoffmeister
  Stockholm Projekt Computer-Service
  <an...@ho...>

Re[2]: *** GMX Spamverdacht *** [Etherboot-developers] Re: Loading kernel over NFS fails (solved!) - FIXED CODE

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

Hello Eric,

Tuesday, July 15, 2003, 2:00:35 PM, you wrote:

> I would suggest that we error on an absolute symlink.  I have
> a very hard time seeing how an absolute symlink could be used properly
> in this context.  I guess in an nfs-root situation it might work.

> But I keep having visions of absolute symlinks pointing to a different
> location on the server than on exported nfs subtree.

My knowledge about NFS is not so great (it just grew yesterday...),
but AFAIK the absolute symlink to any file in the server tree will
always be accessible (if it is exported at all) as
nfs://server/<path>
This is especially true if it points to a file in the same directory
in which it lives.

However making absolute errors go ooops is no great deal, just enter a
return -22; in the right line in the if-statement, around lines 340
iirc. This is kind of policy, not necessarily technical decision.
Decide as you like, I'm fine without absolute symlinks anyway. Just in
response to Ken's mail I though about them at all, previously there
were only relative links implemented.

Best regards,
 Anselm Martin Hoffmeister
 Stockholm Projekt Computer-Service
 <an...@ho...>

Re: *** GMX Spamverdacht *** [Etherboot-developers] Re: Loading kernel over NFS fails (solved!) - FIXED CODE

[<ebi...@ln...>]

"Anselm Martin Hoffmeister" <an...@ho...> writes:

> > I looked at your code.  I think your implementation isn't quite correct.
> > The semantics of a symlink are:
> >
> > If the link starts with / then it's an absolute path and replaces the
> > filename and the operation is retried.
> >
> > Otherwise it's relative and appended to the current directory and the
> > operation is retried.
> 
> Correct. I'm going to fix this immediately.
> The relative part is ok, isn't it? SO I'll just insert an if-statement for
> the absolute path part.

I would suggest that we error on an absolute symlink.  I have
a very hard time seeing how an absolute symlink could be used properly
in this context.  I guess in an nfs-root situation it might work.

But I keep having visions of absolute symlinks pointing to a different
location on the server than on exported nfs subtree.

Eric

Re: *** GMX Spamverdacht *** [Etherboot-developers] Re: Loading kernel over NFS fails (solved!) - FIXED CODE

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

> I looked at your code.  I think your implementation isn't quite correct.
> The semantics of a symlink are:
>
> If the link starts with / then it's an absolute path and replaces the
> filename and the operation is retried.
>
> Otherwise it's relative and appended to the current directory and the
> operation is retried.

Correct. I'm going to fix this immediately.
The relative part is ok, isn't it? SO I'll just insert an if-statement for
the absolute path part.

Anselm

[Etherboot-developers] Re: Loading kernel over NFS fails (solved!) - FIXED CODE

[<ke...@et...>]

>NFS-symlink support should now be in the 5.1 and in the 5.0 trees in
>CVS. Please have a look also at 5.1. Testing with ".." inside the
>path, multiple-level-symlinks e.g would be nice - obviously your nfs
>server behaves different than mine as I got error 21 in the beginning
>while you had 22 (or the other way round).

I looked at your code.  I think your implementation isn't quite correct.
The semantics of a symlink are:

If the link starts with / then it's an absolute path and replaces the
filename and the operation is retried.

Otherwise it's relative and appended to the current directory and the
operation is retried.

Re: [Etherboot-developers] Loading kernel over NFS fails (solved!)

[<ke...@et...>]

>UDP is nothing but a port number so IP/TCP is certainly harder
>than IP/UDP.  However the relevant case is how does:
>
>IP/UDP/TFTP or IP/UDP/NFS compare to IP/TCP/HTTP

But you need UDP for DHCP for the foreseeable future so the TFTP on top
of that is a small extra, whereas HTTP on top of TCP would be a lot of
code in addition to the UDP code. HTTP adds its own complexity, you have
to parse the headers, etc and this spills over into more functions, more
buffers in "userspace", etc.  And you wouldn't be able to do multicast
on TCP.

[Etherboot-developers] Re: Re[4]: [Etherboot-users] Loading kernel over NFS fails (solved!) - FIXED CODE

[<ebi...@ln...>]

ja...@Mc... writes:

> On Tue, 15 Jul 2003, Ken Yap wrote:
> 
> > >Hmm, kinda makes me think of specifying a URL.
> > >In fact, what if we could us HTTP to load a kernel ?
> > >
> > >Something like:
> > >
> > >   filename  = "http://192.168.0.254/lts/vmlinuz-2.4.21-ltsp-1";
> > >
> > >Just thinking out loud :)
> > 
> > You forget that HTTP uses TCP. Etherboot only supports UDP which is
> > significantly simpler in implementation. But something I have thought
> > about is a TFTP to HTTP proxy at the server side. One would have to pay
> > some attention to security though.
> 
> Ah yes, that little ole issue.
> 
> So, is TCP really that much bigger/harder than UDP ?

UDP is nothing but a port number so IP/TCP is certainly harder
than IP/UDP.  However the relevant case is how does:

IP/UDP/TFTP or IP/UDP/NFS compare to IP/TCP/HTTP

The big difference between IP/UDP/TFTP and IP/TCP for data
transmission is that a lot more data can be in flight simultaneously.
But I think a stupid TCP implementation would compare favorably with
TFTP.  

However I have the strange feeling a IP/TCP/HTTP stack would be
noticeably more complicated.

On the wish list of IP features to implement there are also.
- Fragmented packets.  (Result in better TFTP throughput)
- ICMP.  (Closed port errors would be very useful to get)

A very interesting question is what will happen when we finally
hit the transition to IPv6.  As DHCP is not necessary to get an
IP address.   We probably want to retain something like DHCP where we
multicast for a server and then we get a unicast reply full of
configuration information.   The current design scales and load
balances well.  So nothing may change.  But it may be the point
where everyones newer and shinier implementations can be used.

Eric

Re: [Etherboot-developers] VMware problems

[<ke...@et...>]

>There seem to be several problems for vmware, one of which seems to be
>inside the floppyloader - the dump of registers is always repeated as
>the int13 call directly over that output-all
>(arch/i386/prefix/floppyload.S line 230) fails. I had no
>documentation at hand, so did not find out what exactly that call
>should do and what it did not.

Hmm, the floppyloader is a hacked version of the Linux boot block so if
the Linux kernel loads from (virtual) floppy, it should work here too,
unless the changes are too drastic.

[Etherboot-developers] VMware problems

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

Hi list,

I spent some time trying to locate the bugs that prevent vmware
from running. I had some problems as the code is not too short
(although documented)...

There seem to be several problems for vmware, one of which seems to be
inside the floppyloader - the dump of registers is always repeated as
the int13 call directly over that output-all
(arch/i386/prefix/floppyload.S line 230) fails. I had no
documentation at hand, so did not find out what exactly that call
should do and what it did not.

Another problem - that bad exception error which occurs when loading
an eb51.nbi from eb50 - seems to stick inside relocate_to - the call
from relocate after that "Relocating text..." message makes the vmware
go ooops. I'd suspect the gdt modifications badly implemented (in
vmware, of course), but there is no workaround, is it?
Turning relocation off could be possible (is it? I didn't verify yet),
but IIRC there are some drivers that require it to be activated(?)

Perhaps someone with real knowledge about that assembler codepieces
(Eric? Ken?) could comment.

Thanks,
  Anselm

[Etherboot-developers] Porting Linux Drivers

[Timothy L. <tl...@ro...>]

Hi

This is as far as I went with my documentation.  I will continue when I
finish the tlan...

Tim

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.497 / Virus Database: 296 - Release Date: 7/4/2003