On Wednesday 30 April 2008 21:11, David Woodhouse wrote:
> On Wed, 2008-04-30 at 20:22 +0200, Andi Kleen wrote:
> > David Woodhouse <[email protected]> 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
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 <[email protected]> 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
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
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