Proposal: Creating meta-networking

Proposal: Creating meta-networking

[Joe MacDonald]

Hi all,

We've been talking about this on-and-off at Wind River for a while now,
but it now seems like a reasonable time to bring a proposal to the OE
community at large.  We're thinking about creating a new layer to house
recipes, etc.  for networking packages.  I'll try to address what seem to
be the most immediate questions (certainly the ones we've been thinking
most about any time I've discussed this with anyone):

Who would use this?

   The intent is that this would be a layer generally useful directly on
   top of the Yocto Project / OE-core, but it would also draw from and
   compliment meta-oe.  Right now I'm imagining two main groups interested
   in this layer.

      - Anyone building a small networking device (eg. a home router /
        bridge / switch).

      - Anyone wanting to add network services to their device (eg.
        anything that might benefit from a small ftp/tftp server)

What will it include?

   The focus should be on networking protocols, daemons, servers and utilities.
   The plan is for a staged approach.  Initially we're going to bring forward a
   number of recipes from OE Classic that aren't currently in OE-core or the
   meta-oe layer.  The short list right now is:

      - aoetools
      - openldap
      - quagga
      - radvd
      - tftp-hpa
      - traceroute
      - tunctl
      - vblade
      - vlan
      - xl2tpd

   The next two stages would run concurrently, with Wind River
   contributing a number of recipes we intend to support for the
   long-term.  That list is still being firmed up but will include:

      - freeradius
      - netcat
      - racoon2
      - rdist

   There's about another six or seven packages on the short list right
   now, generally in the same vein.

   The other stage is migrating packages that seem like obvious fits into
   this layer from meta-oe.  The current list under consideration would
   be:

      - atftp
      - bridge-utils
      - dnsmasq
      - dnsmasq-dbus
      - inetutils
      - ipsec-tools
      - iw
      - libnet
      - libnfnetlink
      - net-snmp
      - ntp
      - ntp-ssl
      - openvpn
      - ptpd
      - rp-pppoe
      - samba
      - strongswan
      - talloc
      - tcpdump
      - vsftpd

That's a lot of stuff, are you going to organize it somehow?

   The plan is that we will have subdirectories for logical groups of
   recipes in much the same way meta-oe is organized today.  Groupings I
   would propose right now would be:

      - recipes-daemons
         - containing stuff like atftp, dnsmasq, racoon2, radvd, etc.
      - recipes-protocols
         - containing stuff like quagga, openldap, xl2tpd, maybe iscsi if it
           appears, etc.
      - recipes-support
         - containing the rest, aoetools, bridge-utils, traceroute, etc.

   This is definitely the least-clear part of our plan so far and would
   need the most feedback and fine-tuning, I expect.

Why move anything from meta-oe?

   "Networking" covers such a broad area and touches so much that it
   really seems like 'meta-networking' should be a home for all of the
   embedded networking bits.  Leaving some parts in meta-oe and having the
   rest in meta-networking would ultimately seem a bit arbitrary.

Who is 'we'?

   Wind River is volunteering to maintain the layer and any recipes we
   contribute at the outset.  For recipes imported from OE Classic it'd be
   great if the maintainers there continued ownership, but if that's not
   possible, WR will also sign up for general maintenance.  For recipes
   imported from meta-oe we would hope that the current maintainers would
   continue support in meta-networking once it's created.  WR definitely
   won't be able to do this alone so we're hoping for help from everyone
   here.

When are you doing this?

   I've been working on a prototype on and off for the last little bit but
   considering the scope and potential impact, it seemed best to open up
   the discussion here first and if it seemed like a generally desirable
   thing, we'd get some version of this up and available within a few days
   of consensus.

So what does everyone think?  Awesome idea?  Terrible idea?  (Hopefully)
something in between?  All feedback is welcome.

-- 
Joe MacDonald, Sr. Member of Technical Staff, Linux Products Group, Wind River
direct 613.270.5750     mobile 613.291.7421     fax 613.592.2283

Re: [OE-core] Proposal: Creating meta-networking

[Khem Raj]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 6/15/2012 8:15 AM, Joe MacDonald wrote:
> Hi all,
> 
> We've been talking about this on-and-off at Wind River for a while
> now, but it now seems like a reasonable time to bring a proposal to
> the OE community at large.  We're thinking about creating a new
> layer to house recipes, etc.  for networking packages.  I'll try to
> address what seem to be the most immediate questions (certainly the
> ones we've been thinking most about any time I've discussed this
> with anyone):
> 
> Who would use this?
> 
> The intent is that this would be a layer generally useful directly
> on top of the Yocto Project / OE-core, but it would also draw from
> and compliment meta-oe.  Right now I'm imagining two main groups
> interested in this layer.
> 
> - Anyone building a small networking device (eg. a home router / 
> bridge / switch).
> 
> - Anyone wanting to add network services to their device (eg. 
> anything that might benefit from a small ftp/tftp server)
> 
> What will it include?
> 
> The focus should be on networking protocols, daemons, servers and
> utilities. The plan is for a staged approach.  Initially we're
> going to bring forward a number of recipes from OE Classic that
> aren't currently in OE-core or the meta-oe layer.  The short list
> right now is:
> 
> - aoetools - openldap - quagga - radvd - tftp-hpa - traceroute -
> tunctl - vblade - vlan - xl2tpd
> 
> The next two stages would run concurrently, with Wind River 
> contributing a number of recipes we intend to support for the 
> long-term.  That list is still being firmed up but will include:
> 
> - freeradius - netcat - racoon2 - rdist
> 
> There's about another six or seven packages on the short list
> right now, generally in the same vein.
> 
> The other stage is migrating packages that seem like obvious fits
> into this layer from meta-oe.  The current list under consideration
> would be:
> 
> - atftp - bridge-utils - dnsmasq - dnsmasq-dbus - inetutils -
> ipsec-tools - iw - libnet - libnfnetlink - net-snmp - ntp -
> ntp-ssl - openvpn - ptpd - rp-pppoe - samba - strongswan - talloc -
> tcpdump - vsftpd
> 
> That's a lot of stuff, are you going to organize it somehow?
> 
> The plan is that we will have subdirectories for logical groups of 
> recipes in much the same way meta-oe is organized today.  Groupings
> I would propose right now would be:
> 
> - recipes-daemons - containing stuff like atftp, dnsmasq, racoon2,
> radvd, etc. - recipes-protocols - containing stuff like quagga,
> openldap, xl2tpd, maybe iscsi if it appears, etc. -
> recipes-support - containing the rest, aoetools, bridge-utils,
> traceroute, etc.
> 
> This is definitely the least-clear part of our plan so far and
> would need the most feedback and fine-tuning, I expect.
> 
> Why move anything from meta-oe?
> 
> "Networking" covers such a broad area and touches so much that it 
> really seems like 'meta-networking' should be a home for all of
> the embedded networking bits.  Leaving some parts in meta-oe and
> having the rest in meta-networking would ultimately seem a bit
> arbitrary.
> 
> Who is 'we'?
> 
> Wind River is volunteering to maintain the layer and any recipes
> we contribute at the outset.  For recipes imported from OE Classic
> it'd be great if the maintainers there continued ownership, but if
> that's not possible, WR will also sign up for general maintenance.
> For recipes imported from meta-oe we would hope that the current
> maintainers would continue support in meta-networking once it's
> created.  WR definitely won't be able to do this alone so we're
> hoping for help from everyone here.
> 
> When are you doing this?
> 
> I've been working on a prototype on and off for the last little bit
> but considering the scope and potential impact, it seemed best to
> open up the discussion here first and if it seemed like a generally
> desirable thing, we'd get some version of this up and available
> within a few days of consensus.
> 
> So what does everyone think?  Awesome idea?  Terrible idea?
> (Hopefully) something in between?  All feedback is welcome.
> 

I think creating a networking layer is fine idea, alongside meta-oe,
as a separate layer in meta-openembedded repo. Reshuffling recipes
from meta-oe into different layers is fine. I would like to avoid copies.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/bV9sACgkQuwUzVZGdMxSaVgCeJN3phaSkPA18pJkb4mtjq2i5
BzQAnRK05weQOYDQxFc9ZqWz04MUrqB6
=8Cdm
-----END PGP SIGNATURE-----

Re: Proposal: Creating meta-networking

[Koen Kooi]

Op 13 jul. 2012, om 17:58 heeft Paul Eggleton het volgende geschreven:

> On Thursday 12 July 2012 15:57:52 Joe MacDonald wrote:
>> Just to make sure we're got it in context, though, the open points were:
>> 
>>   - tcpdump listed in meta-oe's recipes-core/tasks/task-cli-tools,
>>     under RDEPENDS_${PN}-debug.
> 
> Koen, any suggestions? This task has pretty random contents - some of it is 
> even hardware-specific. Do we really need to keep this together? 

That's an SHR recipe, you'd have to ask Martin Jansa.

The biggest blocker right now is where meta-networking is going to be hosted, the layers in the meta-openembedded repo can only depend on oe-core and bitbake, no other external layers.

regards,

Koen

Re: Proposal: Creating meta-networking

[Paul Eggleton]

On Friday 13 July 2012 18:03:08 Koen Kooi wrote:
> Op 13 jul. 2012, om 17:58 heeft Paul Eggleton het volgende geschreven:
> > On Thursday 12 July 2012 15:57:52 Joe MacDonald wrote:
> >> Just to make sure we're got it in context, though, the open points were:
> >>   - tcpdump listed in meta-oe's recipes-core/tasks/task-cli-tools,
> >>   
> >>     under RDEPENDS_${PN}-debug.
> > 
> > Koen, any suggestions? This task has pretty random contents - some of it
> > is even hardware-specific. Do we really need to keep this together?
> 
> That's an SHR recipe, you'd have to ask Martin Jansa.

Ultimately we should not have anything distro-specific in meta-oe at all, which 
means we all ought to have a say in its contents - otherwise it belongs in the 
distro layer.

Martin, do you have any objection to this task recipe being reworked in the 
face of the proposal to split tcpdump (and other networking-related recipes) 
out to meta-networking?

> The biggest blocker right now is where meta-networking is going to be
> hosted, the layers in the meta-openembedded repo can only depend on oe-core
> and bitbake, no other external layers.

I'll leave this for Joe to comment on.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: Proposal: Creating meta-networking

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 1676 bytes --]

On Fri, Jul 13, 2012 at 05:15:33PM +0100, Paul Eggleton wrote:
> On Friday 13 July 2012 18:03:08 Koen Kooi wrote:
> > Op 13 jul. 2012, om 17:58 heeft Paul Eggleton het volgende geschreven:
> > > On Thursday 12 July 2012 15:57:52 Joe MacDonald wrote:
> > >> Just to make sure we're got it in context, though, the open points were:
> > >>   - tcpdump listed in meta-oe's recipes-core/tasks/task-cli-tools,
> > >>   
> > >>     under RDEPENDS_${PN}-debug.
> > > 
> > > Koen, any suggestions? This task has pretty random contents - some of it
> > > is even hardware-specific. Do we really need to keep this together?
> > 
> > That's an SHR recipe, you'd have to ask Martin Jansa.
> 
> Ultimately we should not have anything distro-specific in meta-oe at all, which 
> means we all ought to have a say in its contents - otherwise it belongs in the 
> distro layer.

It was added from oe-core, because we (SHR) were still using it in our
images/tasks. If we're the only one user I don't mind moving it to our
distro layer or reworking it to something usefull for other people too.

> Martin, do you have any objection to this task recipe being reworked in the 
> face of the proposal to split tcpdump (and other networking-related recipes) 
> out to meta-networking?

Not at all.. I'll just add meta-networking to our layers setup..

> > The biggest blocker right now is where meta-networking is going to be
> > hosted, the layers in the meta-openembedded repo can only depend on oe-core
> > and bitbake, no other external layers.
> 
> I'll leave this for Joe to comment on.

Cheers,

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: Proposal: Creating meta-networking

[Paul Eggleton]

On Friday 13 July 2012 16:58:00 Paul Eggleton wrote:
> On Thursday 12 July 2012 15:57:52 Joe MacDonald wrote:
> >    - systemd
> 
> Despite what I said yesterday Andreas has come through with v2 of the patch
> series this morning, so assuming that's in good shape, it looks like we
> should be on track to do the meta-systemd split and then meta-networking
> after that, which will save a whole lot of hassle. It probably will be
> necessary to patch meta-systemd at the same time to move the
> meta-networking parts into a subdirectory so they can be masked out if
> desired, but that's a trivial exercise.

Following up, the meta-systemd split-out has now been merged, so this should 
no longer be a blocker.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre