Re: Etherboot and gpxe

On Thu, 2009-08-06 at 11:52 -0700, Joyce Yu wrote:
> I spent sometime to look at the new gPXE API. I think it takes a few 
> days to port and debug a driver. But I am looking for a few other things 
> before I do the actually porting work. So I did a quick porting using 
> the legacy etherboot interfaces. What I found is the gPXE ROM image size 
> is too large. In the etherboot environment, I was able to control the 
> image size to be 32k by changing 'makerom.pl' to 'makerom.pl -s 0', and 
> make bin/xxxx.zrom. In the gPXE environment, the ROM image size of the 
> same driver is 64k which cause the option overflow in my system.  I can 
> see that my xxxx.o in gPXE (quick port using legacy interfaces) is five 
> times larger  than my xxxx.o in the etherboot.

That is very strange, and given the emphasis we put on small code I'm
surprised at the apparent difference in the same code compiled under
each environment. Generally, comparing the file size of object files is
misleading; could you post the output of running the `size' command on
each?

That said, in terms of final ROM size, gPXE contains many more features
than Etherboot, and they do take up some room. I know people have had
success cramming gPXE into 32kb in the past, but I'm not quite sure how
they managed it; hopefully someone else on this list can provide
suggestions. In quick testing I was able to get a rtl8139 ROM down to
38,400 bytes by simply disabling things in config/defaults.h - perhaps
you could try that?

> I also have a question regarding the usages of the iobuf in the TX in 
> gPXE. If the packet in the iobuf was copied to a pre-allocated buffer 
> and sent to the HW to be kicked to the wire, iobuf can be set to NULL to 
> be re-used by the stack after the kick, and there is no need to look at 
> the TX completion in the xxx_poll(), right?

The I/O buffer passed to your transmit() function is still owned by the
netdevice layer, and must eventually be freed by calling
netdev_tx_complete() on it. You should never free_iob() that I/O buffer
yourself. Theoretically, you could copy the contents into a preallocated
iobuf and call netdev_tx_complete() immediately in transmit(), but that
uses extra memory and time for the copy, robs the netdevice layer of
status information if the TX fails, and you'll still have to reap that
descriptor eventually. I recommend against this approach.

-- Josh

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

_______________________________________________
Etherboot-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/etherboot-discuss

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQBKey00I6LPMrSI3tYRAmoEAJ9pyS4mFSZrPf8UV1AkiSUm/iQnrgCgpe9m
Kac/3fRDrkhrHLf7B4Fovlk=
=Z7IN
-----END PGP SIGNATURE-----