[PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list

[PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list

[David Woodhouse]

Andrew Morton has been saying recently that we need an 'embedded
maintainer', to take responsibility for 'embedded issues' in the core
kernel, as well as trying to improve our relationship with those using
the Linux kernel for 'embedded' devices -- who have a reputation of
not working with us very closely; to their detriment as well as our
own.

Various people, including myself, have been doing that kind of thing
on and off over the years anyway, but Andrew is probably right that
it's worth having someone listed in the MAINTAINERS file who actually
considers it their responsibility, and as a point of contact for
people seeking advice, review, etc.

I've volunteered to take a more active rôle in this, and Wind River
has agreed to assign Paul Gortmaker to it, too.  The following patch
adds both of us to the MAINTAINERS file.

We have also set up a mailing list, linux-embedded@vger.kernel.org,
where development related to embedded stuff can happen in a slightly
less noisy environment than the main linux-kernel list. We'd like to
encourage anyone working on Linux in embedded devices to join the list.

-- 
dwmw2

[PATCH 1/1] Embedded Maintainer(s), linux-embedded@vger list

[David Woodhouse]

Add Paul and myself, and the linux-embedded list, to MAINTAINERS.

Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

diff --git a/MAINTAINERS b/MAINTAINERS
index bca09ed..3650ed1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1550,6 +1550,14 @@ M:	raisch@de.ibm.com
 L:	general@lists.openfabrics.org
 S:	Supported
 
+EMBEDDED LINUX
+P:	Paul Gortmaker
+M:	paul.gortmaker@windriver.com
+P	David Woodhouse
+M:	dwmw2@infradead.org
+L:	linux-embedded@vger.kernel.org
+S:	Maintained
+
 EMULEX LPFC FC SCSI DRIVER
 P:	James Smart
 M:	james.smart@emulex.com

-- 
dwmw2

Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list

[Andi Kleen]

David Woodhouse <dwmw2@infradead.org> writes:

> Andrew Morton has been saying recently that we need an 'embedded
> maintainer', to take responsibility for 'embedded issues' in the core
> kernel, as well as trying to improve our relationship with those using
> the Linux kernel for 'embedded' devices -- who have a reputation of
> not working with us very closely; to their detriment as well as our
> own.

I hope your job description doesn't include adding more and more
CONFIGs though.

I am sure there are lots of low hanging fruit where memory can be
saved and it's a good thing someone cares about that, but please don't
focus on the code size only. Or if you work on that don't do it 
using CONFIG or when you really add a new one find some other 
that is pointless and remove it first. 

There are simply already far too many of them and they make the 
kernel harder and harder to change.

-Andi

Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list

[Josh Boyer]

On Wed, 2008-04-30 at 18:42 +0100, David Woodhouse wrote:
> Andrew Morton has been saying recently that we need an 'embedded
> maintainer', to take responsibility for 'embedded issues' in the core
> kernel, as well as trying to improve our relationship with those using
> the Linux kernel for 'embedded' devices -- who have a reputation of
> not working with us very closely; to their detriment as well as our
> own.
> 
> Various people, including myself, have been doing that kind of thing
> on and off over the years anyway, but Andrew is probably right that
> it's worth having someone listed in the MAINTAINERS file who actually
> considers it their responsibility, and as a point of contact for
> people seeking advice, review, etc.
> 
> I've volunteered to take a more active rôle in this, and Wind River
> has agreed to assign Paul Gortmaker to it, too.  The following patch
> adds both of us to the MAINTAINERS file.

Excellent news.

> We have also set up a mailing list, linux-embedded@vger.kernel.org,
> where development related to embedded stuff can happen in a slightly
> less noisy environment than the main linux-kernel list. We'd like to
> encourage anyone working on Linux in embedded devices to join the list.

Do you see this list as a general embedded patch/issues discussion list,
a help list, a list for vendors to interact with the community, or all
of the above?

I ask because having the entry in MAINTAINERS is great, but I expect
some to be a bit confused as to what that actually means.

josh

Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list

[David Woodhouse]

On Wed, 2008-04-30 at 13:26 -0500, Josh Boyer wrote:
> Do you see this list as a general embedded patch/issues discussion list,
> a help list, a list for vendors to interact with the community, or all
> of the above?

All of the above -- although I dislike the phrase 'interact with the
community'. I want vendors to be _part_ of the community, not outsiders
who merely interact with it.

-- 
dwmw2

Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list

[Josh Boyer]

On Wed, 2008-04-30 at 19:43 +0100, David Woodhouse wrote:
> On Wed, 2008-04-30 at 13:26 -0500, Josh Boyer wrote:
> > Do you see this list as a general embedded patch/issues discussion list,
> > a help list, a list for vendors to interact with the community, or all
> > of the above?
> 
> All of the above -- although I dislike the phrase 'interact with the
> community'. I want vendors to be _part_ of the community, not outsiders
> who merely interact with it.

Sure, agreed.  Have to start somewhere though.

josh

Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list

[David Woodhouse]

On Wed, 2008-04-30 at 20:22 +0200, Andi Kleen wrote:
> David Woodhouse <dwmw2@infradead.org> writes:
> 
> > Andrew Morton has been saying recently that we need an 'embedded
> > maintainer', to take responsibility for 'embedded issues' in the core
> > kernel, as well as trying to improve our relationship with those using
> > the Linux kernel for 'embedded' devices -- who have a reputation of
> > not working with us very closely; to their detriment as well as our
> > own.
> 
> I hope your job description doesn't include adding more and more
> CONFIGs though.
> 
> I am sure there are lots of low hanging fruit where memory can be
> saved and it's a good thing someone cares about that, but please don't
> focus on the code size only. Or if you work on that don't do it 
> using CONFIG or when you really add a new one find some other 
> that is pointless and remove it first. 
> 
> There are simply already far too many of them and they make the 
> kernel harder and harder to change.

I agree. And if we do want to pay attention to pure code size, there are
other approaches -- like --gc-sections and/or building with '--combine
-fwhole-program' which I was playing with for OLPC a while back. I must
dust that off now that the GCC fixes should mostly have made it into
current distributions.

-- 
dwmw2

Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list

[Adrian Bunk]

On Wed, Apr 30, 2008 at 06:42:02PM +0100, David Woodhouse wrote:
> Andrew Morton has been saying recently that we need an 'embedded
> maintainer', to take responsibility for 'embedded issues' in the core
> kernel, as well as trying to improve our relationship with those using
> the Linux kernel for 'embedded' devices -- who have a reputation of
> not working with us very closely; to their detriment as well as our
> own.
> 
> Various people, including myself, have been doing that kind of thing
> on and off over the years anyway, but Andrew is probably right that
> it's worth having someone listed in the MAINTAINERS file who actually
> considers it their responsibility, and as a point of contact for
> people seeking advice, review, etc.
>...

MAINTAINERS is mostly for finding the right contact for bug reports and 
patches.

For what should I Cc you and for what should I Cc you not?

> dwmw2

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list

[David Woodhouse]

On Thu, 2008-05-01 at 02:34 +0300, Adrian Bunk wrote:
> On Wed, Apr 30, 2008 at 06:42:02PM +0100, David Woodhouse wrote:
> > Andrew Morton has been saying recently that we need an 'embedded
> > maintainer', to take responsibility for 'embedded issues' in the core
> > kernel, as well as trying to improve our relationship with those using
> > the Linux kernel for 'embedded' devices -- who have a reputation of
> > not working with us very closely; to their detriment as well as our
> > own.
> > 
> > Various people, including myself, have been doing that kind of thing
> > on and off over the years anyway, but Andrew is probably right that
> > it's worth having someone listed in the MAINTAINERS file who actually
> > considers it their responsibility, and as a point of contact for
> > people seeking advice, review, etc.
> >...
> 
> MAINTAINERS is mostly for finding the right contact for bug reports and 
> patches.
> 
> For what should I Cc you and for what should I Cc you not?

The rôle of 'embedded maintainer' is a little different to other
maintainers -- it's not about owning a certain part of the code. We need
to keep an eye on changes throughout the kernel, for how they affect
embedded systems. That's not just 'bloatwatch', but other things too --
making sure that people don't keep assuming that "all the world's a PC",
for sure, but also feature requests -- talking to those working on XIP
for S390 block devices, and trying to ensure that the infrastructure
work they do is useful for XIP from flash in embedded systems, to pick
an example from the not-so-distant past.

So I can't really give you a simple answer to the question. It's
"anything which could have implications for embedded systems which
normal people might not have thought of". But I'll continue to trawl
linux-kernel with that mindset anyway, so I wouldn't worry _too_ much.

I see the linux-embedded list being mostly useful in bringing developers
"into the fold" from companies who have largely been resistant to being
part of the community. Asking them to join linux-kernel is probably not
a good idea; I see it as a kind of targeted kernelnewbies, in one sense.

-- 
dwmw2

Re: [PATCH 1/1] Embedded Maintainer(s), linux-embedded@vger list

[Bart Van Assche]

On Wed, Apr 30, 2008 at 7:44 PM, David Woodhouse <dwmw2@infradead.org> wrote:
> Add Paul and myself, and the linux-embedded list, to MAINTAINERS.
>
> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index bca09ed..3650ed1 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1550,6 +1550,14 @@ M:       raisch@de.ibm.com
>  L:     general@lists.openfabrics.org
>  S:     Supported
>
> +EMBEDDED LINUX
> +P:     Paul Gortmaker
> +M:     paul.gortmaker@windriver.com
> +P      David Woodhouse
> +M:     dwmw2@infradead.org
> +L:     linux-embedded@vger.kernel.org
> +S:     Maintained
> +
>  EMULEX LPFC FC SCSI DRIVER
>  P:     James Smart
>  M:     james.smart@emulex.com

It's great that more attention is being paid to the use of Linux in
embedded systems. And the MAINTAINERS file is probably the right file
to add the above information. But I'm afraid that the way the above
information is formatted will cause confusion. As an example, recently
there was a driver added to the Linux kernel for the PCF8575 chip.
This is an I2C chip that is only used in embedded systems. Regarding
driver review, should any such drivers be sent to the I2C mailing
list, the embedded mailing list or both ? The MAINTAINERS file should
be clear on this.

Bart.

Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list

[David Woodhouse]

On Thu, 2008-05-01 at 11:58 +0200, Andi Kleen wrote:
> But I think CONFIG is not the right way to solve this.  The right way
> is for someone to take a look at new core features in linux-next/mm
> and see how much code size growth they have and then complain if they
> are significant and work with the submitter to make it better or offset
> changes by reducing other areas. For example each significant code growth
> should be justified with clear advantages, but right now nobody looks
> at that and challenges people. In fact I commented on that occasionally
> in my reviews and sometimes good pure misunderstanding and unbelief on the i
> ssue.  That is something the embedded stake holders need to change I think.
> 
> CONFIG if anything should be only last resort when everything else failed 
> there. 

To a large extent, I agree. I certainly don't want to focus solely on
code size; there's a lot more to embedded Linux than that. But it _is_
an issue. 

There are some cases where we really _do_ want to have CONFIG options,
but I agree that we should keep them to a minimum. And when we _do_ have
CONFIG options, they don't have to litter the actual code with ifdefs.
We're quite capable of having "function calls" which in some
configurations just turn out to be empty macros, etc...

> Also then not all kernel code growth is the same.  Also there is code growth 
> and code growth anyways.  you don't specify what is resource constrained. Is 
> it flash or is it RAM?

He wasn't talking about one specific system. There'll be an element of
both.

> If it's RAM first I believe you can get much
> more result-for-invested-work-and-maintenance-impact by focussing on dynamic
> memory allocations than on code size. I did a presentation about that a couple 
> of years ago with some numbers 
> (http://halobates.de/memory.pdf and http://halobates.de/memorywaste.pdf) 
> And CONFIG is definitely not the right way to approach that, the right
> way is better data structures, better algorithms to size tables, just
> some general care etc.

Stuff like shrinking the rbtree structure by encoding the colour in the
low bits of the parent pointer, perhaps? :)

> If it's flash that is the problem that is more difficult. First if you
> don't do XIP you can just use a better compression algorithm and get
> a lot of slack for free. 

Potentially at a cost of higher boot time, which is another
commonly-cited issue for such devices.

> If it's XIP then you might need to do some real code size reductions
> (including __init). 

I've never been that convinced about XIP. Flash is more expensive than
RAM, and cheap flash is NAND and not XIP-able these days anyway. The
only really convincing motivation for XIP would be the _power_ budget,
and if your power budget is _that_ tight, then often you'd be better off
with something like eCos instead of Linux anyway.

> I think one solution would be making code size and memory size impact 
> analysis general part of the code review / linux-next/mm testing 
> process. But really focus on the code itself, not on its CONFIG. CONFIG
> is just the easy way out, but it's also the wrong one.

Don't worry -- we're not going to start seeing a flurry of patches
adding CONFIG options and turning Linux into #ifdef hell :)

-- 
dwmw2

Re: [PATCH 1/1] Embedded Maintainer(s), linux-embedded@vger list

[David Woodhouse]

On Thu, 2008-05-01 at 11:55 +0200, Bart Van Assche wrote:
> It's great that more attention is being paid to the use of Linux in
> embedded systems. And the MAINTAINERS file is probably the right file
> to add the above information. But I'm afraid that the way the above
> information is formatted will cause confusion. As an example, recently
> there was a driver added to the Linux kernel for the PCF8575 chip.
> This is an I2C chip that is only used in embedded systems. Regarding
> driver review, should any such drivers be sent to the I2C mailing
> list, the embedded mailing list or both ? The MAINTAINERS file should
> be clear on this.

The I²C list would be the best place to send such a patch. You could
also copy it to the linux-embedded list if it's likely to be of interest
to a reasonable proportion of "embedded" developers, but that wouldn't
be the primary route into Linus' tree for most things.

I can't really see any way to make that clear in the MAINTAINERS file
that wouldn't be clumsy and just as confusing -- I think it'll work out
just fine by itself. Do you have a concrete proposal?

-- 
dwmw2

Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list

[Andi Kleen]

> To a large extent, I agree. I certainly don't want to focus solely on
> code size; there's a lot more to embedded Linux than that. But it _is_

Not only code size, far more important is dynamic memory consumption.
[admittedly we right now lack a good instrumentation framework for this]

> There are some cases where we really _do_ want to have CONFIG options,
> but I agree that we should keep them to a minimum. And when we _do_ have
> CONFIG options, they don't have to litter the actual code with ifdefs.

The problem I see is more that really nobody can even compile not 
alone test all these combinations anymore. Hidding the problem in inlines
does not solve that. And no randconfig is not the solution either.

> > of years ago with some numbers 
> > (http://halobates.de/memory.pdf and http://halobates.de/memorywaste.pdf) 
> > And CONFIG is definitely not the right way to approach that, the right
> > way is better data structures, better algorithms to size tables, just
> > some general care etc.
> 
> Stuff like shrinking the rbtree structure by encoding the colour in the
> low bits of the parent pointer, perhaps? :)

Whatever pays off.

-Andi

Re: [PATCH 1/1] Embedded Maintainer(s), linux-embedded@vger list

[Bart Van Assche]

On Thu, May 1, 2008 at 12:05 PM, David Woodhouse <dwmw2@infradead.org> wrote:
> On Thu, 2008-05-01 at 11:55 +0200, Bart Van Assche wrote:
>> It's great that more attention is being paid to the use of Linux in
>> embedded systems. And the MAINTAINERS file is probably the right file
>> to add the above information. But I'm afraid that the way the above
>> information is formatted will cause confusion. As an example, recently
>> there was a driver added to the Linux kernel for the PCF8575 chip.
>> This is an I2C chip that is only used in embedded systems. Regarding
>> driver review, should any such drivers be sent to the I2C mailing
>> list, the embedded mailing list or both ? The MAINTAINERS file should
>> be clear on this.
>
> The I²C list would be the best place to send such a patch. You could
> also copy it to the linux-embedded list if it's likely to be of interest
> to a reasonable proportion of "embedded" developers, but that wouldn't
> be the primary route into Linus' tree for most things.
>
> I can't really see any way to make that clear in the MAINTAINERS file
> that wouldn't be clumsy and just as confusing -- I think it'll work out
> just fine by itself. Do you have a concrete proposal?

The information present in the current MAINTAINERS file is such that
given the name(s) of the source files affected by a patch, one can
look up the appropriate mailing list(s) and maintainer(s) to send the
patch to. Information about embedded maintainer(s) is different: it's
not about maintaining specific source files but about general
discussions with regard to kernel changes for embedded systems. Maybe
there should be two sections in the MAINTAINERS file, one for
maintainers of specific source trees and another section for
coordinators of specific usage scenario's of the Linux kernel ?

Bart.

Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list

[Kristoffer Ericson]

On Wed, 30 Apr 2008 18:42:02 +0100
David Woodhouse <dwmw2@infradead.org> wrote:

> Andrew Morton has been saying recently that we need an 'embedded
> maintainer', to take responsibility for 'embedded issues' in the core
> kernel, as well as trying to improve our relationship with those using
> the Linux kernel for 'embedded' devices -- who have a reputation of
> not working with us very closely; to their detriment as well as our
> own.

Sounds like a good idea. I doubt it will change much concerning development
but it would be good to have some "representation" for embedded stuff.

> 
> Various people, including myself, have been doing that kind of thing
> on and off over the years anyway, but Andrew is probably right that
> it's worth having someone listed in the MAINTAINERS file who actually
> considers it their responsibility, and as a point of contact for
> people seeking advice, review, etc.
> 

Agreed.

> I've volunteered to take a more active rôle in this, and Wind River
> has agreed to assign Paul Gortmaker to it, too.  The following patch
> adds both of us to the MAINTAINERS file.
> 
> We have also set up a mailing list, linux-embedded@vger.kernel.org,
> where development related to embedded stuff can happen in a slightly
> less noisy environment than the main linux-kernel list. We'd like to
> encourage anyone working on Linux in embedded devices to join the list.
> 
> -- 
> dwmw2
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


-- 
Kristoffer Ericson <Kristoffer.Ericson@Gmail.com>

Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list

[Pekka Enberg]

Hi Andi,

On Thu, May 1, 2008 at 1:41 PM, Andi Kleen <andi@firstfloor.org> wrote:
> > To a large extent, I agree. I certainly don't want to focus solely on
> > code size; there's a lot more to embedded Linux than that. But it _is_
>
>  Not only code size, far more important is dynamic memory consumption.
>  [admittedly we right now lack a good instrumentation framework for this]

There's a Google Summer of Code project going on now to implement such
instrumentation:

http://code.google.com/soc/2008/linux/appinfo.html?csaid=E749E676AD70FBB0

So any suggestions/input on this is obviously welcome.

Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list

[Eduard - Gabriel Munteanu]

Hi,

I'm the student working on this. I have already implemented tracing for
SLAB, SLUB and SLOB, and patched relayfs to work early on (just after
kmem_cache_init() runs). Currently, I'm working on the userspace tool,
so much of the coding is largely finished.

I wanted to submit the relay stuff, but couldn't contact its maintainer.

If anyone wants to take a look, I could set up a git repo somewhere
(which has to be done anyway, at some point).


	Cheers,
	Eduard

On Fri, 2 May 2008 18:00:43 +0300
"Pekka Enberg" <penberg@cs.helsinki.fi> wrote:

> Hi Andi,
> 
> On Thu, May 1, 2008 at 1:41 PM, Andi Kleen <andi@firstfloor.org>
> wrote:
> > > To a large extent, I agree. I certainly don't want to focus
> > > solely on code size; there's a lot more to embedded Linux than
> > > that. But it _is_
> >
> >  Not only code size, far more important is dynamic memory
> > consumption. [admittedly we right now lack a good instrumentation
> > framework for this]
> 
> There's a Google Summer of Code project going on now to implement such
> instrumentation:
> 
> http://code.google.com/soc/2008/linux/appinfo.html?csaid=E749E676AD70FBB0
> 
> So any suggestions/input on this is obviously welcome.

Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list

[Andrew Morton]

On Fri, 2 May 2008 23:01:41 +0300
Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro> wrote:

> I wanted to submit the relay stuff, but couldn't contact its maintainer.

Send a patch as per Documentation/SubmittingPatches to

	Andrew Morton <akpm@linux-foundation.org>
	linux-kernel@vger.kernel.org
	Tom Zanussi <zanussi@us.ibm.com>

and magic will happen.

<looks in ./MAINTAINERS>
<looks at Tom>

Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list

[Eduard - Gabriel Munteanu]

On Fri, 2 May 2008 13:14:47 -0700
Andrew Morton <akpm@linux-foundation.org> wrote:

> Send a patch as per Documentation/SubmittingPatches to
> 
> 	Andrew Morton <akpm@linux-foundation.org>
> 	linux-kernel@vger.kernel.org
> 	Tom Zanussi <zanussi@us.ibm.com>
> 
> and magic will happen.
> 
> <looks in ./MAINTAINERS>
> <looks at Tom>

I said I couldn't contact the maintainer, not that I don't know who's
the maintainer :-).

Unfortunately both e-mail addresses of Tom Zanussi don't work (for me).
Comcast won't accept my mails (though my mail provider's server looks
fine to others), and IBM says there's no 'zanussi' in their directory.

I will try again, but will you merge it / contact him otherwise if I
find it impossible? Anyway, you will be Cc-ed when I do.

BTW, Mathieu Desnoyers is also aware of my patch, and he looked
interested in it, if this matters.

Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list

[Andrew Morton]

On Fri, 2 May 2008 23:33:30 +0300
Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro> wrote:

> On Fri, 2 May 2008 13:14:47 -0700
> Andrew Morton <akpm@linux-foundation.org> wrote:
> 
> > Send a patch as per Documentation/SubmittingPatches to
> > 
> > 	Andrew Morton <akpm@linux-foundation.org>
> > 	linux-kernel@vger.kernel.org
> > 	Tom Zanussi <zanussi@us.ibm.com>
> > 
> > and magic will happen.
> > 
> > <looks in ./MAINTAINERS>
> > <looks at Tom>
> 
> I said I couldn't contact the maintainer, not that I don't know who's
> the maintainer :-).
> 
> Unfortunately both e-mail addresses of Tom Zanussi don't work (for me).
> Comcast won't accept my mails (though my mail provider's server looks
> fine to others), and IBM says there's no 'zanussi' in their directory.

Yeah, stuff happens.  It never hurts to cc me - I'm kind of the team
wicket-keeper.

> I will try again, but will you merge it / contact him otherwise if I
> find it impossible? Anyway, you will be Cc-ed when I do.

It will be handled appropriately ;)

> BTW, Mathieu Desnoyers is also aware of my patch, and he looked
> interested in it, if this matters.

Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list

[Randy Dunlap]

On Fri, 2 May 2008 13:53:48 -0700 Andrew Morton wrote:

> On Fri, 2 May 2008 23:33:30 +0300
> Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro> wrote:
> 
> > On Fri, 2 May 2008 13:14:47 -0700
> > Andrew Morton <akpm@linux-foundation.org> wrote:
> > 
> > > Send a patch as per Documentation/SubmittingPatches to
> > > 
> > > 	Andrew Morton <akpm@linux-foundation.org>
> > > 	linux-kernel@vger.kernel.org
> > > 	Tom Zanussi <zanussi@us.ibm.com>
> > > 
> > > and magic will happen.
> > > 
> > > <looks in ./MAINTAINERS>

How did you do that?

His most recent emails are from
Tom Zanussi <tzanussi@gmail.com> and
Tom Zanussi <zanussi@comcast.net>

> > > <looks at Tom>
> > 
> > I said I couldn't contact the maintainer, not that I don't know who's
> > the maintainer :-).
> > 
> > Unfortunately both e-mail addresses of Tom Zanussi don't work (for me).
> > Comcast won't accept my mails (though my mail provider's server looks
> > fine to others), and IBM says there's no 'zanussi' in their directory.
> 
> Yeah, stuff happens.  It never hurts to cc me - I'm kind of the team
> wicket-keeper.
> 
> > I will try again, but will you merge it / contact him otherwise if I
> > find it impossible? Anyway, you will be Cc-ed when I do.
> 
> It will be handled appropriately ;)
> 
> > BTW, Mathieu Desnoyers is also aware of my patch, and he looked
> > interested in it, if this matters.



---
~Randy

Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list

[Andrew Morton]

On Sat, 3 May 2008 15:24:27 -0700 Randy Dunlap <randy.dunlap@oracle.com> wrote:

> On Fri, 2 May 2008 13:53:48 -0700 Andrew Morton wrote:
> 
> > On Fri, 2 May 2008 23:33:30 +0300
> > Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro> wrote:
> > 
> > > On Fri, 2 May 2008 13:14:47 -0700
> > > Andrew Morton <akpm@linux-foundation.org> wrote:
> > > 
> > > > Send a patch as per Documentation/SubmittingPatches to
> > > > 
> > > > 	Andrew Morton <akpm@linux-foundation.org>
> > > > 	linux-kernel@vger.kernel.org
> > > > 	Tom Zanussi <zanussi@us.ibm.com>
> > > > 
> > > > and magic will happen.
> > > > 
> > > > <looks in ./MAINTAINERS>
> 
> How did you do that?

It just what I had in my email client's address book.

> His most recent emails are from
> Tom Zanussi <tzanussi@gmail.com> and
> Tom Zanussi <zanussi@comcast.net>

Quite a lot of kernel developers use quite a lot of email addresses and
it's rather a pita.  People perhaps underestimate the value of not being a
moving target.

Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list

[Denys Vlasenko]

On Wednesday 30 April 2008 21:11, David Woodhouse wrote:
> On Wed, 2008-04-30 at 20:22 +0200, Andi Kleen wrote:
> > David Woodhouse <dwmw2@infradead.org> writes:
> > 
> > > Andrew Morton has been saying recently that we need an 'embedded
> > > maintainer', to take responsibility for 'embedded issues' in the core
> > > kernel, as well as trying to improve our relationship with those using
> > > the Linux kernel for 'embedded' devices -- who have a reputation of
> > > not working with us very closely; to their detriment as well as our
> > > own.
> > 
> > I hope your job description doesn't include adding more and more
> > CONFIGs though.
> > 
> > I am sure there are lots of low hanging fruit where memory can be
> > saved and it's a good thing someone cares about that, but please don't
> > focus on the code size only. Or if you work on that don't do it 
> > using CONFIG or when you really add a new one find some other 
> > that is pointless and remove it first. 
> > 
> > There are simply already far too many of them and they make the 
> > kernel harder and harder to change.
> 
> I agree. And if we do want to pay attention to pure code size, there are
> other approaches -- like --gc-sections

I have some patches in this area too. Were submitted to Sam
but he was too busy it seems.
--
vda

Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list

[Denys Vlasenko]

On Thursday 01 May 2008 12:41, Andi Kleen wrote:
> > To a large extent, I agree. I certainly don't want to focus solely on
> > code size; there's a lot more to embedded Linux than that. But it _is_
> 
> Not only code size, far more important is dynamic memory consumption.
> [admittedly we right now lack a good instrumentation framework for this]
> 
> > There are some cases where we really _do_ want to have CONFIG options,
> > but I agree that we should keep them to a minimum. And when we _do_ have
> > CONFIG options, they don't have to litter the actual code with ifdefs.
> 
> The problem I see is more that really nobody can even compile not 
> alone test all these combinations anymore. Hidding the problem in inlines
> does not solve that. And no randconfig is not the solution either.

Because we allowed kernel to be developed without the requirement that
random config should be buildable for release kernels.

Had it been a requirement, keeping it in shape wouldn't be
too difficult.

Sure enough, _now_ fixing kernel to pass such a test on i386
would take several weeks of work at least. But it is doable.

I would even volunteer to do it if there are some
reasonable chances resulting patches would be viewed
as worthwhile for inclusion. I am somewhat tired
of killing weeks of my time only to find that my work
is deemed "not important enough for inclusion".
--
vda

Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list

[Adrian Bunk]

On Mon, Jun 23, 2008 at 07:28:09PM +0200, Denys Vlasenko wrote:
> On Thursday 01 May 2008 12:41, Andi Kleen wrote:
> > > To a large extent, I agree. I certainly don't want to focus solely on
> > > code size; there's a lot more to embedded Linux than that. But it _is_
> > 
> > Not only code size, far more important is dynamic memory consumption.
> > [admittedly we right now lack a good instrumentation framework for this]
> > 
> > > There are some cases where we really _do_ want to have CONFIG options,
> > > but I agree that we should keep them to a minimum. And when we _do_ have
> > > CONFIG options, they don't have to litter the actual code with ifdefs.
> > 
> > The problem I see is more that really nobody can even compile not 
> > alone test all these combinations anymore. Hidding the problem in inlines
> > does not solve that. And no randconfig is not the solution either.
> 
> Because we allowed kernel to be developed without the requirement that
> random config should be buildable for release kernels.
> 
> Had it been a requirement, keeping it in shape wouldn't be
> too difficult.
> 
> Sure enough, _now_ fixing kernel to pass such a test on i386
> would take several weeks of work at least. But it is doable.
>...

On i386 it might even already work today.

But guess how much time it costs to get at least all defconfigs 
compiling on the other 22 architectures.

Even getting allmodconfig/allyesconfig compiling isn't trivial for all 
architectures, and random configurations are _far_ from compiling.

And we are not talking about something to be done once, as soon as you 
leave x86 there are tons of regular breakages.

Plus the fact that you often get into situations where more options
mean complex and fragile stuff. Read the Kconfig files under 
drivers/media/ and check in git all commits to them since 2.6.25 alone, 
and you'll understand why "add an option for every bit" can result in
very high ongoing maintainance work required.

Not everything that is technically possible is also maintainable, and 
maintainability is a very important point in a project with several 
million lines changing each year.

> vda

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list

[Denys Vlasenko]

On Monday 23 June 2008 19:45, Adrian Bunk wrote:
> Plus the fact that you often get into situations where more options
> mean complex and fragile stuff. Read the Kconfig files under 
> drivers/media/ and check in git all commits to them since 2.6.25 alone, 
> and you'll understand why "add an option for every bit" can result in
> very high ongoing maintainance work required.
> 
> Not everything that is technically possible is also maintainable, and 
> maintainability is a very important point in a project with several 
> million lines changing each year.

Well, I am not (and was not) disputing this. I agree with it.
CONFIGs should not be multiplying like rabbits.
--
vda

Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list

[Sam Ravnborg]

On Mon, Jun 23, 2008 at 07:22:10PM +0200, Denys Vlasenko wrote:
> On Wednesday 30 April 2008 21:11, David Woodhouse wrote:
> > On Wed, 2008-04-30 at 20:22 +0200, Andi Kleen wrote:
> > > David Woodhouse <dwmw2@infradead.org> writes:
> > > 
> > > > Andrew Morton has been saying recently that we need an 'embedded
> > > > maintainer', to take responsibility for 'embedded issues' in the core
> > > > kernel, as well as trying to improve our relationship with those using
> > > > the Linux kernel for 'embedded' devices -- who have a reputation of
> > > > not working with us very closely; to their detriment as well as our
> > > > own.
> > > 
> > > I hope your job description doesn't include adding more and more
> > > CONFIGs though.
> > > 
> > > I am sure there are lots of low hanging fruit where memory can be
> > > saved and it's a good thing someone cares about that, but please don't
> > > focus on the code size only. Or if you work on that don't do it 
> > > using CONFIG or when you really add a new one find some other 
> > > that is pointless and remove it first. 
> > > 
> > > There are simply already far too many of them and they make the 
> > > kernel harder and harder to change.
> > 
> > I agree. And if we do want to pay attention to pure code size, there are
> > other approaches -- like --gc-sections
> 
> I have some patches in this area too. Were submitted to Sam
> but he was too busy it seems.
They were not trivial to apply and so went down on the TODO list.
We could try to push the generic and x86 specific .lds stuff via
the arch maintainers?

	Sam

Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list

[Tim Bird]

Adrian Bunk wrote:
> On Mon, Jun 23, 2008 at 07:28:09PM +0200, Denys Vlasenko wrote:
>> Had it been a requirement, keeping it in shape wouldn't be
>> too difficult.
>>
>> Sure enough, _now_ fixing kernel to pass such a test on i386
>> would take several weeks of work at least. But it is doable.
>> ...
> 
> On i386 it might even already work today.
> 
> But guess how much time it costs to get at least all defconfigs 
> compiling on the other 22 architectures.
> 
> Even getting allmodconfig/allyesconfig compiling isn't trivial for all 
> architectures, and random configurations are _far_ from compiling.
> 
> And we are not talking about something to be done once, as soon as you 
> leave x86 there are tons of regular breakages.
> 
> Plus the fact that you often get into situations where more options
> mean complex and fragile stuff. Read the Kconfig files under 
> drivers/media/ and check in git all commits to them since 2.6.25 alone, 
> and you'll understand why "add an option for every bit" can result in
> very high ongoing maintainance work required.
> 
> Not everything that is technically possible is also maintainable, and 
> maintainability is a very important point in a project with several 
> million lines changing each year.

OK sure.  Nobody's going to disagree with that.  I would, however,
disagree with a characterization of Linux-tiny as "adding an option
for every bit".  Linux-tiny has been around about 5 years now, and
if you added the whole thing right now you'd add about 30 config
options.

If you're worried about this multiplying out of control, let me
just say that having to curtail the rate of patch submission by
embedded developers has not been our biggest problem.  :-)
 -- Tim

=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================

Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list

[Denys Vlasenko]

On Monday 23 June 2008 20:57, Sam Ravnborg wrote:
> > > I agree. And if we do want to pay attention to pure code size, there are
> > > other approaches -- like --gc-sections
> > 
> > I have some patches in this area too. Were submitted to Sam
> > but he was too busy it seems.
>
> They were not trivial to apply and so went down on the TODO list.

I realize that they were not trivial to review, but that
was unavoidable. They were even more not trivial to create.

> We could try to push the generic and x86 specific .lds stuff via
> the arch maintainers?

IIRC I splitted the entire GC collection patch in a way
that first patches were doing exactly this easier first part
and I hoped that at least these first patches
will be taken. They were big, but somewhat trivial,
from "it's obviously safe" department.

Had they been applied, now making --gc-sections to work
would be easier.
--
vda

Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list

[Sam Ravnborg]

On Mon, Jun 23, 2008 at 09:12:30PM +0200, Denys Vlasenko wrote:
> On Monday 23 June 2008 20:57, Sam Ravnborg wrote:
> > > > I agree. And if we do want to pay attention to pure code size, there are
> > > > other approaches -- like --gc-sections
> > > 
> > > I have some patches in this area too. Were submitted to Sam
> > > but he was too busy it seems.
> >
> > They were not trivial to apply and so went down on the TODO list.
> 
> I realize that they were not trivial to review, but that
> was unavoidable. They were even more not trivial to create.
> 
> > We could try to push the generic and x86 specific .lds stuff via
> > the arch maintainers?
> 
> IIRC I splitted the entire GC collection patch in a way
> that first patches were doing exactly this easier first part
> and I hoped that at least these first patches
> will be taken. They were big, but somewhat trivial,
> from "it's obviously safe" department.

I do not recall anything wrong with the patch-set.

> 
> Had they been applied, now making --gc-sections to work
> would be easier.
Agreed. I should have asked you to push this via arch maintainers back then.

	Sam

Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list

[James Chapman]

Adrian Bunk wrote:
> On Mon, Jun 23, 2008 at 07:28:09PM +0200, Denys Vlasenko wrote:
>> On Thursday 01 May 2008 12:41, Andi Kleen wrote:
>>>> To a large extent, I agree. I certainly don't want to focus solely on
>>>> code size; there's a lot more to embedded Linux than that. But it _is_
>>> Not only code size, far more important is dynamic memory consumption.
>>> [admittedly we right now lack a good instrumentation framework for this]
>>>
>>>> There are some cases where we really _do_ want to have CONFIG options,
>>>> but I agree that we should keep them to a minimum. And when we _do_ have
>>>> CONFIG options, they don't have to litter the actual code with ifdefs.
>>> The problem I see is more that really nobody can even compile not 
>>> alone test all these combinations anymore. Hidding the problem in inlines
>>> does not solve that. And no randconfig is not the solution either.
>> Because we allowed kernel to be developed without the requirement that
>> random config should be buildable for release kernels.
>>
>> Had it been a requirement, keeping it in shape wouldn't be
>> too difficult.
>>
>> Sure enough, _now_ fixing kernel to pass such a test on i386
>> would take several weeks of work at least. But it is doable.
>> ...
> 
> On i386 it might even already work today.
> 
> But guess how much time it costs to get at least all defconfigs 
> compiling on the other 22 architectures.
> 
> Even getting allmodconfig/allyesconfig compiling isn't trivial for all 
> architectures, and random configurations are _far_ from compiling.
 >
 > And we are not talking about something to be done once, as soon as you
 > leave x86 there are tons of regular breakages.

Could automated builds and build error reporting be used to help resolve 
these problems?

The good people at Simtec have an automated build report available as an 
e-mail digest. I use it to watch for architecture build breakages in 
subsystems or drivers that I use or touch. It covers defconfigs of ARM 
and MIPS architectures and reports compile errors/warnings, module size, 
kernel size etc. If this approach were extended/distributed to cover 
more architectures and random config builds, developers could with 
little effort spot problems and fix them. Hell, it might also encourage 
new developers to get involved and contribute.

Here's a link to a recent report for ARM, fyi:-

http://lists.simtec.co.uk/pipermail/kautobuild/2008-June/001299.html

> Plus the fact that you often get into situations where more options
> mean complex and fragile stuff. Read the Kconfig files under 
> drivers/media/ and check in git all commits to them since 2.6.25 alone, 
> and you'll understand why "add an option for every bit" can result in
> very high ongoing maintainance work required.
> 
> Not everything that is technically possible is also maintainable, and 
> maintainability is a very important point in a project with several 
> million lines changing each year.
> 
>> vda
> 
> cu
> Adrian

-- 
James Chapman
Katalix Systems Ltd
http://www.katalix.com
Catalysts for your Embedded Linux software development

Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list

[Adrian Bunk]

On Wed, Jun 25, 2008 at 10:50:43AM +0100, James Chapman wrote:
> Adrian Bunk wrote:
>> On Mon, Jun 23, 2008 at 07:28:09PM +0200, Denys Vlasenko wrote:
>>> On Thursday 01 May 2008 12:41, Andi Kleen wrote:
>>>>> To a large extent, I agree. I certainly don't want to focus solely on
>>>>> code size; there's a lot more to embedded Linux than that. But it _is_
>>>> Not only code size, far more important is dynamic memory consumption.
>>>> [admittedly we right now lack a good instrumentation framework for this]
>>>>
>>>>> There are some cases where we really _do_ want to have CONFIG options,
>>>>> but I agree that we should keep them to a minimum. And when we _do_ have
>>>>> CONFIG options, they don't have to litter the actual code with ifdefs.
>>>> The problem I see is more that really nobody can even compile not  
>>>> alone test all these combinations anymore. Hidding the problem in 
>>>> inlines
>>>> does not solve that. And no randconfig is not the solution either.
>>> Because we allowed kernel to be developed without the requirement that
>>> random config should be buildable for release kernels.
>>>
>>> Had it been a requirement, keeping it in shape wouldn't be
>>> too difficult.
>>>
>>> Sure enough, _now_ fixing kernel to pass such a test on i386
>>> would take several weeks of work at least. But it is doable.
>>> ...
>>
>> On i386 it might even already work today.
>>
>> But guess how much time it costs to get at least all defconfigs  
>> compiling on the other 22 architectures.
>>
>> Even getting allmodconfig/allyesconfig compiling isn't trivial for all  
>> architectures, and random configurations are _far_ from compiling.
> >
> > And we are not talking about something to be done once, as soon as you
> > leave x86 there are tons of regular breakages.
>
> Could automated builds and build error reporting be used to help resolve  
> these problems?
> 
> The good people at Simtec have an automated build report available as an  
> e-mail digest. I use it to watch for architecture build breakages in  
> subsystems or drivers that I use or touch. It covers defconfigs of ARM  
> and MIPS architectures and reports compile errors/warnings, module size,  
> kernel size etc. If this approach were extended/distributed to cover  
> more architectures

Jan Dittmer has a great page showing the build status and kernel size of 
the defconfigs of all architectures that is running since 2004 or 2005:
  http://l4x.org/k/

> and random config builds, developers could with  
> little effort spot problems and fix them. Hell, it might also encourage  
> new developers to get involved and contribute.

Perhaps in an ideal world...

In reality, I'd claim I'm one out of only two people who regularly fix 
architecture-specific build problems for all architectures.

> James Chapman

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed