Kernel versioning [was Re: Kernel package and modules]

Mike (mwester) mwester at dls.net
Tue Aug 5 22:07:25 CEST 2008


Joachim Steiger wrote:
>> *sigh*  Well, I tried.  Perhaps I'm not the convincing orator
>> (emailator?) that is required to present the customer-support POV.
>> Further, it's unclear to whom the argument needs to be presented.
>>
>> I'll figure out some means -- despite your unilateral decision -- to
>> ensure that the average joe-geek who bought the phone can flash an
>> experimental kernel and test it with ease, low-risk, and as small an
>> effort as possible.  It'll just have to be another community effort.
> 
> not really.
> 
> my view of this:
> 
> default should be: users don't shoot themselves into the foot. -> andys
> last proposal.
> 
> from man modprobe:
> 
> --cut--
>  -f --force
>      Try to strip any  versioning  information  from  the module,
>      which  might otherwise stop it from loading: this is the same
>      as using both --force-vermagic and --force-modversion.  Natu‐
>      rally,  these  checks are there for your protection, so using
>      this option is dangerous.
> 
>      This applies to any modules inserted:  both  the  module  (or
>      alias) on the command line, and any modules it depends on.
> --/cut--
> 
> i guess even a simple --force-modversion would be enough, since the
> modmagic should fit in any case when trying this.
> 
> sounds like it should be in some howto when modversion restriction is
> getting implemented. ;)

Sorry, no.  My point has been completely missed.

Look, it's not about what the user _CAN_ do, it's about what they _WILL_
do!

Sure, somebody can write up a wiki article describing how to hack up the
rootfs startup files to do the above modprobe stuff.  Or somebody can
insist that the user package up all the modules, and copy them to the
rootfs, and all that stuff.  The user _CAN_ do either of those.

But that's missing the point -- the typical user WON'T do that, because
it's too much work, and too much effort, and too much risk for them.
It's not like we're doing the users a favor either -- they get to be
guinea pigs and we ask them to actively participate in the debugging and
information-gathering process by trying various patches to see if it got
better (consider the SD card GPS patches recently for a case in point).

For goodness sakes, this is a development issue, we can't shove crap off
to users to deal with; we should all be delighted when a user troubles
themselves to build a patched kernel and flashes it to see if our
attempts to make the problem better actually do anything useful.  The
least we can do is make that effort by that user as painless and simple
an experience as we can -- instead, what I'm hearing is that we can't be
BOTHERED to manually edit ONE kernel file to bump up EXTRAVERSION only
when necessary, or that the user can go read a wiki to figure out what
to edit to forcibly load modules.  Not nice.  And not going to be effective.

If we implement the automatic GIT hash thing, I think we'll find that,
at any point in time, "last night's stable" will be the only kernel in
the field.


I refuse to roll over on this issue.  Gratuitous stuffing of GIT hashes
into EXTRAVERSION is ugly, lazy in the bad non-Larry-Wall way, and
shoves a problem downstream onto the wrong group of people.


Mike (mwester)




More information about the devel mailing list