I'm currently testing NonVolatile Option (nvo) support for myri10ge
adapters. It's working, but I need to nail down some loose ends before
submitting the patches:
UI glitches
============
In the "config net0.nvo" GUI, there is no GUI way to clear a field once
it is set, and there is no way to set a field to a zero-length string.
So, I'd like to modify the GUI so ^C clears the field, ESC abandons
edits, and zero-length strings fields are supported.
Also, there are more nvo settings ing gPXE than will fit on screen. I'd
like to make the screen list jump-scroll when there are more options
than fit. (I believe jump-scrolling is friendlier to serial consoles
than scrolling a line at a time.)
Would such changes be acceptable? Would I be replicating others' efforts?
nvs/nvo API
===========
Myri10ge NICs use a 1MB EEPROM comprised of 64KB blocks. Blocks must be
erased as a whole to an all-bits-set state, but may be written a byte at
a time. (This is typical EEPROM behavior, I believe.) gPXE gets to use
the last 64KB block for NVO.
Superficially, this fits the nvs/nvo model, but some problems arise in
practice: When I register a 64KB nvo block, gPXE tries to allocate 64KB
at driver load, and fails. So, I'm currently giving NVO only a single
512 byte fragment, wasting the other 63.5KB of the block.
One problem lies in choosing the 'right' size for the NVO fragment. If
I make it too small, settings won't fit. If I make it too large,
malloc() will fail on more systems. The 2 other gPXE drivers that
support NVO provide 256 bytes or less of NVO fragments.
So, can anyone tell me the maximum legitimate NVO record length that
gPXE can currently generate?
Another problem lies in the semantics of nvs writes: the documenting
comments do not define what happens to unwritten bytes within the block.
Can we add "NVS writes leave any unwritten bytes within the written
block in an undefined state." to clarify the semantics in an
EEPROM-compatible way, without requiring any change the the extant drivers?
Production considerations
=========================
We'd like to ship a single gPXE ROM that is usable by as many of our
customers as possible. The default autoboot behaviour satisfies most,
but some are asking pure nvo configuration without DHCP. I can roll a
custom ROM with a gPXE boot script for them, but this seems a waste when
all they want to do is 'sanboot ${net0.nvo/root-path}' with the network
interface configured via nvo. The sanboot support is already in the
default ROM, and it's a shame if they have to build and field-upgrade
the ROM in each NIC just for a one-line boot script.
So, is there a way to do this without building a custom ROM?
If not, I'm thinking of adding a 'boot-script' nvo setting that is used
if set. Is there a better way?
Thanks,
--Glenn
_______________________________________________
gPXE mailing list
gPXE@etherboot.org
http://etherboot.org/mailman/listinfo/gpxe
