Re: [PATCH] Force UNIX domain sockets to be built in

On Dec 31, 2007 6:18 PM, Michael Buesch <mb@xxxxxxxxx> wrote:
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@xxxxxxxxxxxxxx> 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

I understand that point.
I just always assumed that kernel tests meant 'please test this patch'
and doing the compile yourself.

But I'm not convinced be the following:
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.

This looks more like a "regular" out-of-tree module for the purpose of
the suggested symbol garbage collector.
And for that case I already a 'don't use it then'-note.

The base problem is that there already are many options to break
external modules. (CONFIG_MODULES=n ;) )
Or in the case of this wireless module: CONFIG_CRYPTO_ARC4=n
(Without 'arc4' ieee80211_wep_init() will fail, that will fail
ieee80211_register_hw() and so no mac80211 driver could be loaded)

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.

The question I can't answer in this context is: Do distributions want
to support external modules?
Only if yes, your argument is valid. But then they could just disable
this feature and prevent this kind of bugreports.

Torsten
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: [PATCH] Force UNIX domain sockets to be built in
    ... same trigger could redo this garbage collect. ... Development is not a phase seperate from use or distribution. ... to load latest bleeding edge wireless stuff into a distribution kernel. ...
    (Linux-Kernel)
  • Re: [PATCH] Force UNIX domain sockets to be built in
    ... right now this would also need to trigger a rerun of depmod. ... Development is not a phase seperate from use or distribution. ... module testers for distributions will not be compiling their own modules ...
    (Linux-Kernel)