[ipxe-devel] [PATCH 0/2] Fill in iBFT VLAN field

[Stefan Hajnoczi]

On Fri, Mar 01, 2013 at 04:44:46PM +0000, Michael Brown wrote:
> On 01/03/13 15:32, Stefan Hajnoczi wrote:
> >iSCSI booting does not work VLANs because the iBFT VLAN field is not
> >being filled in.  Without the 802.1Q VLAN Identifier from the iBFT, the
> >operating system cannot connect to the iSCSI target.
> 
> Applied, with some modifications, thanks!
> 
>   http://git.ipxe.org/ipxe.git/commitdiff/7426177
>   http://git.ipxe.org/ipxe.git/commitdiff/7d64abb

Cool, nice improvement, thanks!

> Inspired by your patches, I also allowed VLAN support to be dropped
> from builds that happen to contain VLAN-using drivers (e.g. Hermon):
> 
>   http://git.ipxe.org/ipxe.git/commitdiff/77f64b1
> 
> In the process of testing these, I've noticed a problem with the
> build process.  Where the weak symbol is defined by an object other
> than the object that refers to the symbol, then it's undefined
> whether the linker will pull in the weak-symbol version or the
> strong-symbol version.  To ensure that the weak-symbol version is
> used as desired, it would be necessary to force the
> weak-symbol-defining object to be earlier in the link order than any
> objects referring to that symbol.
> 
> This is particularly problematic for symbols referred to by drivers.
> For example, hermon.o refers to vlan_find().  Since the driver's
> object is the first object dragged in by the build process, there is
> no opportunity for the weak version (in netdevice.o) to be defined
> before hermon.o refers to it.

I'm not aware of a solution that continues to let the linker decide
which objects to pull in.  That part of the build process could be
replaced by a custom tool which outputs an ordered list of object files.
This list would be used on the linker command-line instead of a static
library.

It feels wrong to write a custom tool though :(.

Stefan