All of lore.kernel.org
 help / color / mirror / Atom feed
From: Khem Raj <raj.khem@gmail.com>
To: openembedded-core@lists.openembedded.org,
	 openembedded-devel@lists.openembedded.org
Subject: Re: Proposal: Creating meta-networking
Date: Fri, 15 Jun 2012 08:42:19 -0700	[thread overview]
Message-ID: <4FDB57DB.5090407@gmail.com> (raw)
In-Reply-To: <CANBf+V3=LvWkE28TR1qNR-NpLd60EGroEqmXQqypXAUUZ0pv-Q@mail.gmail.com>

-----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-----



WARNING: multiple messages have this Message-ID (diff)
From: Khem Raj <raj.khem@gmail.com>
To: openembedded-core@lists.openembedded.org,
	 openembedded-devel@lists.openembedded.org
Subject: Re: [OE-core] Proposal: Creating meta-networking
Date: Fri, 15 Jun 2012 08:42:19 -0700	[thread overview]
Message-ID: <4FDB57DB.5090407@gmail.com> (raw)
In-Reply-To: <CANBf+V3=LvWkE28TR1qNR-NpLd60EGroEqmXQqypXAUUZ0pv-Q@mail.gmail.com>

-----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-----



  reply	other threads:[~2012-06-15 15:52 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-15 15:15 Proposal: Creating meta-networking Joe MacDonald
2012-06-15 15:42 ` Khem Raj [this message]
2012-06-15 15:42   ` [OE-core] " Khem Raj
2012-06-15 18:08   ` Otavio Salvador
2012-06-15 18:55     ` Andrei Gherzan
2012-06-15 19:55       ` Philip Balister
2012-06-16 17:10         ` Joe MacDonald
2012-06-16 17:36         ` Marko Lindqvist
2012-06-16 17:45           ` Otavio Salvador
     [not found] ` <1442756.zsKFTug4Rk@helios>
     [not found]   ` <20120712195752.GN3293@windriver.com>
     [not found]     ` <38351001.3KzA0t96MO@helios>
2012-07-13 16:03       ` Koen Kooi
2012-07-13 16:15         ` Paul Eggleton
2012-07-16  7:16           ` Martin Jansa
2012-07-16 23:15       ` Paul Eggleton
2012-08-22 18:20 ` Christopher Larson
2012-08-22 18:59   ` Joe MacDonald
2012-08-22 19:22     ` Chris Larson
2012-08-22 19:37       ` Joe MacDonald
2012-08-22 19:41         ` Joe MacDonald
2012-08-23  6:22       ` Koen Kooi
2012-08-23 14:54         ` Joe MacDonald
  -- strict thread matches above, loose matches on Subject: below --
2012-07-23 12:57 Firago Alexey
2012-07-23 13:02 Firago Alexey
2012-07-24  0:09 ` Joe MacDonald

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FDB57DB.5090407@gmail.com \
    --to=raj.khem@gmail.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=openembedded-devel@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.