branching the kernel, etc.

branching the kernel, etc.

[Dave Täht]

I'm posting this cross-list because I'd like to see development related
issues move to the bloat-devel list long term, and I see several
developer folk not on bloat-devel.

I'd like to get some honest development happening.

Branching the kernel, and maintaining it, seems to be a major
headache. I'd like someone with cred in the kernel communities to step
up, when it's needed. That person is not me. Anyone?

The problems are:

* Network device drivers are usually developed by small branches by
  vendor specific teams, then fed into one of three other branches
  (networking/wireless/staging), then into the mainline.

  Debloat work probably has to feed back through the same queues.
 
  It may well be the best places to get work done will be in the most
  relevant branch and mailing list.

* The firmware blobs are completely non-transparent to anyone but
  the vendor. Software mechanisms (rate limiting) can evolve. 

  Communicating effectively with the vendor may well require 
  cross language skills. 

* Queuing disciplines can easily live outside the kernel

* Openwrt lags behind the mainline often by a lot, carries a lot of out
  of tree packages, and yet there we can have the greatest effect.

* There are people enthusiastic about new forms of traffic exchange,
  notably ledbat. Others are interested in various forms of TCP. Others 
  are interested in IPv6. These cross wide swaths of the kernel, and
  would require a branch.

  There is roughly one person interested in each of these topics at
  present. My inclination is to wait for critical mass and get people to
  step up.

* I'd like to have a European presence, and was thinking about not using
  github to manage repos. Actually, I kind of like stressing p2p
  development using ipv6, but that's me.

* A build/test cluster would be nice. Just one fast 12 core box would be
  helpful. I liked the old handhelds.org model of shared development.

* Different solutions for different OSes

Related to all that is recruiting a BSD person, MS person, embedded
person, etc into the herd of cats.

-- 
Dave Taht
http://nex-6.taht.net

Re: branching the kernel, etc.

[Dan McDonald]

On Sun, Feb 06, 2011 at 11:09:36AM -0700, Dave Täht wrote:

<SNIP!>

> * Different solutions for different OSes
> 
> Related to all that is recruiting a BSD person, MS person, embedded
> person, etc into the herd of cats.

I'm lurking here on behalf of Illumos (the fork from formerly-Open Solaris).
In Illumos we can exert a *bit* more quality control, but most Illumos
developers have day jobs not *directly* related to the TCP/IP stack.

In other words, I have no time to contribute data.  I can, given solid
measurements, sway the powers-that-be in Illumos to possibly take in
appropriate changes.

Dan

Re: [Bloat] branching the kernel, etc.

[John W. Linville]

On Sun, Feb 06, 2011 at 11:09:36AM -0700, Dave Täht wrote:
> 
> I'm posting this cross-list because I'd like to see development related
> issues move to the bloat-devel list long term, and I see several
> developer folk not on bloat-devel.
> 
> I'd like to get some honest development happening.
> 
> Branching the kernel, and maintaining it, seems to be a major
> headache. I'd like someone with cred in the kernel communities to step
> up, when it's needed. That person is not me. Anyone?

I can do this.  FWIW, I am the Linux kernel maintainer for wireless
LANs already.  I'm already good at handling patches I don't fully
understand... :-)

Any objections?

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

Re: [Bloat] branching the kernel, etc.

[Eric Raymond]

John W. Linville <linville@tuxdriver.com>:
> > Branching the kernel, and maintaining it, seems to be a major
> > headache. I'd like someone with cred in the kernel communities to step
> > up, when it's needed. That person is not me. Anyone?
> 
> I can do this.  FWIW, I am the Linux kernel maintainer for wireless
> LANs already.  I'm already good at handling patches I don't fully
> understand... :-)
> 
> Any objections?

Objections? Not hardly...I think we love you! :-)
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>