On Fri, 2008-02-29 at 09:59 -0700, Zan Lynx wrote:
And when that happens, the same taint flag will be set. Your argument is
a non-argument :)
But anyway...
FWIW, I wasn't actually trying to start this debate with the patch I
sent before - I was simply correcting what seemed to be "obviously"
broken logic in module.c for handling ndiswrapper[0]. I was auditing the
taint flags for a backport to another kernel, and noticed this. Having
said that, there would seem to be two directions this can now go in:
*). Back out this patch, go back to previous situation. But then there's
still special case logic for ndiswrapper, and it's not really doing what
people would likely consider the "right" thing with its tainting then. I
again suggest that ndiswrapper would need to be sure to set the taint
flags itself, which would be an alternative to "policing" it.
*). Keep this patch. And potentially add some more for other similar
shim layers - I can think of a certain graphics driver that might
qualify for similar treatment, if one wants to go there. But I might
need to find a tailor specializing in *really* fire retardant pants
before I think of being the one who submits that patch.
I've no idea what "the right thing" is here, but many seem to think it
involves backing out this patch (the most compelling argument given so
far is that it might force ndiswrapper simply to change its name, and
that there's no clear idea if the kernel should be enforcing ideology).
Since we've brought it up, one good thing I would like to see come of
this perhaps is a clearer understanding of what the kernel should and
should not be doing in terms of "license compliance enforcement". We
have had lots of talk, but perhaps a "policy" document is worthwhile.
Jon.
[0] If this is reverted, please do stick in a reference to:
http://lwn.net/Articles/205644/ to avoid repeats.
--
