On Wed, 2014-11-05 at 16:29 +0000, Burton, Ross wrote: > On 4 November 2014 08:09, Patrick Ohly <[email protected]> wrote: > Recently I built a custom image which depended on a DHCP > server to > configure Ethernet. runqemu with tap for networking doesn't > provide one > at the moment, so ssh logins did not work. > > Instead of customizing images for runqemu, I think it would be > better to > adapt runqemu and uses images as on the target device. > Attached two > patches which work for me. Is that of interest for inclusion > upstream? > > > > I've long been of the opinion that runqemu needs the ability to setup > a DHCP/DNS server for the guest, as whilst you can special-case qemu > machines and hard-code the relevant network configuration it doesn't > help with testing. That said, I'm not convinced that dhcpd+bind is > the right way forward, something like dnsmasq (currently in > meta-networking) might be quicker to build and more flexible in this > environment.
I was looking for a solution that works inside the Poky repository, without external dependencies, and thus only depends on oe-core. Are you suggesting that dnsmasq should be moved into oe-core? What extra flexibility would you like see provided on the host side? All I needed was the DHCP server, so bind+dhcpd fit the bill for me. Compilation speed didn't seem like a big deal. Handing DNS settings to the DHCP client is missing in the patch, but could be added also when using bind+dhcpd. It's a bit harder to do in the general case than with dnsmasq, because runqemu-internal somehow needs to determine where it can find a DNS server in order to configure dhcpd, whereas dnsmasq itself could act as DNS proxy. When using dhcpd, would hard-coding a well-known one like Google's 8.8.8.8 as default with an explicit override via env variable be acceptable? Either way, what would be the right way to integrate this from a user perspective? Should running the DHCP server (whichever one it is) be done by default? Always or should there be an option to turn it on or off? How? > I suppose more work is needed, in particular around how to > enable or > disable this feature. Patching the .bb files also leads to a > (to me) > strange QA error. See the comments in the patches for details. > > This is likely due to bind using PACKAGES_prepend instead of PACKAGES > =+ (=+ is prepend), which messes up the native.bbclass magic. That's right, replacing _prepend with =+ fixed the problem. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
