tree/branch: poky/master commit: a8dc76ee69cfe1ffe846c07a510e3a562a5b1a7f With the latest master, build appliance image could be built out successfully. But the VMWare Player requires PCNet32 driver for ethernet device if we choose "Other Linux 2.6.x kernel" as the template when creating guest. So we need to enable the option in Yocto kernel for qemux86 and qemux86-64. The information of NIC device shown in VMWare Player is like following: ####### Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] #######
Are you building the kernel for the build appliance ? or are you using the binary output of a nightly/scheduled build ? We don't want to throw the kitchen sink into any configuration. So if you are building this yourself, why not just have a layer that enables this option for your specific case ? That's exactly what the configuration fragments are for.
That or make a new BSP - which it is if it has a different hardware configuration.
This is generic for the build appliance, we want to make this easy to run on vmware. For some reason Vmware uses different NICs with different x86 configurations. They setup the PCNet for the 32bit Linux and Gigabit for the 64bit Linux. Have PCNet enabled by default would allow a broader set of Virtual tools to be used beyond just QEMU. This is important for the Build Appliance.
That's fine - but it doesn't address why the qemu machine config should be changed rather than creating a BSP for the build appliance. This would allow you to have exactly what you need, and nothing more.
I discussed this with Saul today. Turns out qemux86 does support pcnet32, so it is reasonable to include the driver in the BSP. We're testing this now to ensure enabling doesn't break the qemux86 BSP networking (it shouldn't, but testing anyway) and to validate it works for vmware for the self-hosted image. Once tested, I'll propose we make this change for the qemux86 machine in linux-yocto/meta.
This doesn't break the qemux86 machine, it still boots and gets an IP for the e1000 device. Saul, please let me know if the patch I sent works for the self-hosted image.
but if the standard emulation / boot doesn't use this .. it's extra and not in the spirit of an embedded BSP. No one has answered my question yet. Why not a config fragment in a layer ?
Note that we use the common-pc for the qemux86 machine - so it supports a lot of NICs, some of which are not even supported by qemux86. Now, I think we should probably reduce that, as the common-pc machine is, as you say, not in keeping with the spirit of an embedded kernel. But, it doesn't seem consistent to reject a change to add a driver for hardware that the qemu machine does support. It is perfectly reasonably for someone to pass "=net nic,model=pcnet" when booting with qemu. As to why not use a layer. The self hosted image is meant to be part of oe-core for demonstration purposes. As such, the goal is to minimize any setup necessary for the build - this would argue against using a layer. I had initially suggested a vmware32 machine that we could add to oe-core for this purpose, but that fragments the effort and increases QA for no real added value. By adding pcnet32 for qemux86, we can use the same image in vmware as well as qemu, increasing the usefullness of the image and decreasing the QA complexity. It seems like a lot of value for a single extra module.
don't let the 'common' in common-pc be misleading, it is targeted at a small set of machines (i.e. it's a finite list), so it does follow the general model. That being said, if someone sends a change for this, I won't reject it. I just don't want to see a whole set of really general and untestable options appearing for hardware that we don't have.
Fixed in master: 2e3845c555fb7da32e6482153f4d498475026f68