[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200712311818.12825.mb@bu3sch.de>
Date: Mon, 31 Dec 2007 18:18:12 +0100
From: Michael Buesch <mb@...sch.de>
To: Alan Cox <alan@...rguk.ukuu.org.uk>
Cc: "Torsten Kaiser" <just.for.lkml@...glemail.com>,
"Adrian Bunk" <bunk@...nel.org>, "Bodo Eggert" <7eggert@....de>,
"Jan Engelhardt" <jengelh@...putergmbh.de>, devzero@....de,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH] Force UNIX domain sockets to be built in
On Monday 31 December 2007 17:38:03 Alan Cox wrote:
> On Mon, 31 Dec 2007 17:17:19 +0100
> "Torsten Kaiser" <just.for.lkml@...glemail.com> wrote:
>
> > a) this could be disabled during development if you want this
> > b) this would even only affect development if you add new code that
> > now needs a EXPORT_SYMBOL that was removed on an earlier build. And
> > right now this would also need to trigger a rerun of depmod. And the
> > same trigger could redo this garbage collect.
> >
> > Or am I missing something obvious?
>
> Development is not a phase seperate from use or distribution. A lot of
> module testers for distributions will not be compiling their own modules
> but loading in ones to test provided by their vendor - which may of
> course then need different ksyms
As an example, the whole purpose wireless-compat package is
to load latest bleeding edge wireless stuff into a distribution kernel.
So people are not required to recompile their kernels for using
drivers that support their hardware.
And guess what, it is used a _lot_. And lots of bugs are found with it.
It increases our testing community a lot.
So, all this wouldn't work, if kernel symbols could randomly get
nuked by some "garbage collector".
In practice, no distribution would use symbol garbage collection, as the
only benefit from it would be an increased level of bugreports.
--
Greetings Michael.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists