[OE-core] [oe-commits] Joshua Lock : netbase: remove redundant assignments

Koen Kooi koen at dominion.thruhere.net
Mon Feb 27 13:26:44 UTC 2012


Op 27 feb. 2012, om 13:13 heeft Richard Purdie het volgende geschreven:

> On Mon, 2012-02-27 at 12:31 +0100, Koen Kooi wrote:
>> Op 27 feb. 2012, om 11:33 heeft Martin Jansa het volgende geschreven:
>> 
>>> On Wed, Feb 22, 2012 at 10:13:09PM +0000, git at git.openembedded.org wrote:
>>>> Module: openembedded-core.git
>>>> Branch: master
>>>> Commit: c3d5800d2850a186f91b5a0db642aa5d1c20156b
>>>> URL:    http://git.openembedded.org/?p=openembedded-core.git&a=commit;h=c3d5800d2850a186f91b5a0db642aa5d1c20156b
>>>> 
>>>> Author: Joshua Lock <josh at linux.intel.com>
>>>> Date:   Tue Feb 21 17:46:44 2012 -0800
>>>> 
>>>> netbase: remove redundant assignments
>>>> 
>>>> There's no need to explicitly set PACKAGE_ARCH = MACHINE_ARCH, base.bbclass
>>>> takes care of setting this value for us based on the interfaces for those
>>>> machines being an OVERRIDE.
>>> 
>>> do_install () {
>>> ...
>>>       # Disable network manager on machines that commonly do NFS booting
>>>       case "${MACHINE}" in
>>>               "qemuarm" | "qemux86" | "qemux86-64" | "qemumips" | "qemuppc" )
>>> 
>>> This causes do_install hash to depend on MACHINE variable for all MACHINEs, 
>>> so making whole recipe MACHINE_ARCH would be more effective then rebuilding 
>>> TARGET_ARCH package after every MACHINE switch.
>> 
>> That whole bit needs to go into the specific nfs image recipe, not
>> into the recipe. Unless we decide nfs is the one and only way to boot
>> qemu machines.
> 
> Clearly the qemu machines boot on non-nfs setups just fine and the
> comment is just a bit stale here.
> 
> For qemu we expect the IP address to be stable and consistent so we know
> where to find it and we don't expect it to disappear. The problem was
> that if network manager starts poking around the main ethernet
> interface, anything can go wrong (e.g. random QA test failures if
> networkmanager decided to change the interface at the wrong moment). We
> therefore really do know better than network manager when it comes to
> ethernet connectivity into our qemu images.
> 
> There are a few options here:
> 
> a) Whitelist the MACHINE variable in hashes apart from the qemu machines
> 
> b) Change the code to a do_install_append_qemu* which would mean the
> hashes become stable.

Both are hacks for the nfs use case.

> c) Shove the information into a qemu specific package. 
> 
> The trouble with c) before everyone decides its the best is how/when do
> you include that package. It really needs to be present whenever network
> manager is present. I don't want to end up with someone installing it
> from feeds and getting different behaviour as it would be a nightmare to
> debug.

If you put it in a seperate package it's becomes something people can opt-in to. If someone opts-in and it breaks because of that, that person gets to keep both pieces.

> d) We could also decide we don't care about network manager any more and
> just delete this I guess since we default to connman now.

You can load the networkmanager plugin (http://wiki.debian.org/NetworkManager#Wired_Networks_are_Unmanaged) that makes it ignore entries in /etc/network/interfaces to accomplish the same. Right now both connman and networkmanager ignore /etc/network/interfaces which leads to mass confusion. I discussed this with Josh at ELC but forgot to send an email about this. I think we should split netbase into:

1) a package with /etc/rpc, /etc/hosts, /etc/protocols and /etc/services
2) a package with /etc/network/interfaces
3) a package with the initscript (probably move that into the ifupdown package)

That way we can support the following without having unused config files in the filesystem:

* simple ifupdown style networking using /etc/network/interfaces
* networkmanager honouring devices managed by /etc/network/interfaces
* networkmanager handling everything
* connman handling everything
* no networking in userspace, boot with ip=dhcp

regards,

Koen





More information about the Openembedded-core mailing list