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

--

[ message continues ]

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

--

[ message continues ]

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

[ message continues ]

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

--

[ message continues ]

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

[ message continues ]

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

[ message continues ]

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

--

[ message continues ]

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

[ message continues ]

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

[ message continues ]

I realize that they were not trivial to review, but that

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

--

[ message continues ]

Agreed. I should have asked you to push this via arch maintainers back then.

	Sam
--

[ message continues ]

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

--

[ message continues ]

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

--

[ message continues ]

Sure, agreed.  Have to start somewhere though.

josh

--

[ message continues ]

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


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

--

[ message continues ]

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

--

[ message continues ]

On Wed, 30 Apr 2008 18:42:02 +0100

Sounds like a good idea. I doubt it will change much concerning development



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

[ message continues ]