[PATCH] add-build-git-head-info.patch

Mike (mwester) mwester at dls.net
Sun Jul 27 18:38:11 CEST 2008


Andy Green wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Somebody in the thread at some point said:
> | Andy Green wrote:
> |> -----BEGIN PGP SIGNED MESSAGE-----
> |> Hash: SHA1
> |>
> |> Somebody in the thread at some point said:
> |>
> |> | Are we ready to deal with the "I flashed my kernel but I forgot to
> |> | update my rootfs -- now my neo won't boot!" problems? :-D
> |>
> |> Why won't it boot?  Everything it needs to boot is inside the monolithic
> |> kernel.
> |>
> |> What you seem to be saying is that we should prepare ourselves for the
> |> "my kernel crashed because I inserted some old .ko from a previous
> |> deleted kernel" problems?
> |>
> |> - -Andy
> |
> | It isn't worth arguing; forget I brought this up in the first place.
> 
> Is this arguing or "talking it through"?

Ok, you're right -- not arguing.  Yet.  Based on my previous discussions
on this topic, I'm "jumping the gun" and anticipating where this is
headed, and I think that'll end up to be an unnecessary distraction is all.

> I never update the modules on the rootfs-es I work on, I just teleport
> the monolithic kernel in and work with a config that has all the bits I
> need in the monolithic kernel.  Consequently, sometimes I do see bad old
> modules coming in and OOPSing me until I go and delete the original
> /lib/modules off the SD Card.  So it is a real issue being relaxed about
> /lib/module versioning.
> 
> - -Andy

But that's a different problem -- that's configuration management.  My
original proposal was solely focused on identification.

The extra and local versioning stuff in the kernel is primarily for
configuration management.  The "user at host" and date information is
primarily for identification.  We have an identification problem with
the bug reports right here and now, and I was merely proposing that we
hijack the user at host to solve the identification problem without
affecting -- for good or for bad -- the current state of the
configuration management stuff.

It's just painful when extra and local version info gets involved, users
get angry because they need to install modules all the time and things
get screwed up when they forget; developers get angry because they need
to install them but know darned well that the bump in version number was
insignificant and thus dealing with modules is wasted effort for them,
then somebody gets rid of a whole lot of modules to solve the problem
with a monolithic kernel, which usually annoys someone else who insists
that for some important reason a module-ized kernel is critical to them,
and then somewhere somebody gets all irate because they have an
out-of-tree kernel module they've built and they can't keep up because
the kernel versioning changes with every nightly build...

FWIW, I build and test with a monolithic kernel, so it matters not to me
personally.  But the distros have many modules, and at least some of
them are modules for important reasons.  So adding extra or local
version to the standard distro would have far-reaching effects on the feeds.

Mike (mwester)




More information about the openmoko-kernel mailing list