[syslinux] Etherboot & pxelinux (was: thank you)

H. Peter Anvin hpa at zytor.com
Thu Feb 7 14:27:31 PST 2002

Josef Siemes wrote:

> That's a different point - if the high level bits in pxelinux were in
> C I'd have done something there. Since I only can read a bit assembler
> but not write it I can see how it works, maybe why, but can't extend
> it to my needs. I'd for example like to have blksize in pxelinux, 
> but since it's too complicated for me to implement and hpa doesn't
> have the time to do it I'll go on without it. Maybe sometime parts
> of syslinux/pxelinux/isolinux will be available in C so I can do 
> something about it.

At some point I might do a C-based bootloader -- probably an actually
working implementation of Genesis -- but the *LINUX series are designed to
be as small as possible, which means that going to C, using a 16-bit C
compiler, isn't really practical -- free 16-bit compilers are uniformly

blksize is complicated because the TFTP spec for blksize is broken --
"blksize 1024" doesn't mean "give me a 1024-byte block if you can", rather
   it means "give me any block size 1024 bytes or less."  Dealing with
block sizes that are not multiples of 1024 means doing some very
sophisticated buffering, which impacts memory management.  Unlike an
on-disk filesystem we can't afford to flush a pending connection should we
need the space; the connection needs to be maintained.

I actually have a "blksize2" option in tftp-hpa that resolves this
problem, however, if PXELINUX ever used it it would only work against

Since you have to turn off blksize anyway if you want to support early PXE
stacks, how much does this matter?

I suspect the right way to do this is to negotiate "blksize 1024", set
SECTOR_SIZE in PXELINUX to 1024, and if the server comes back with blksize
other than 512 or 1024, EOPTNEG the connection and try again without
blksize -- if block size is 512 then we would always treat blocks in
pairs, which isn't a problem, obviously.

Now, questions:

a) Is this worthwhile enough that I should spend time on it?  How much do
you think it will buy you?

b) Should we aim for an even larger blksize by default?  What about PXE
stacks that don't handle defragmentation correctly?

Either way, this will have to wait until I get 1.70/2.00 out (haven't
decided yet if I should bump it up to 2.00) -- this is the code
restructuring to support multifile initramfs.


More information about the Syslinux mailing list