Re: Introducing the patchadd binary patch toolchain

[Elad Efrat <elad%NetBSD.org@localhost>]

On Wed, Apr 29, 2009 at 11:03 PM, matthew sporleder
<msporleder%gmail.com@localhost> wrote:

> I was asking if binary patching allowed you to replace just parts of a
> binary kernel because replacing a whole kernel file is just the wrong
> thing to do without a way to validate that a user definitely wants
> your new GENERIC.  For example, would binary patching let you look at
> /netbsd and ask "is LFS in here ? patch xyz : goto nextpatch"

I think you can ask that with /usr/bin/nm, and perhaps even get the
full kernel config using config -x.

> I actually think the move to /stand/ modules + lighter kernels makes
> this more possible than ever before (even if you add drivers to your
> kernel, replacing a subsystem in /stand/ is probably still safe), I
> don't have a good solution in mind.

Let me put it like this: I would be very surprised if we claimed we
support patching custom kernels.

Take netinet and netinet6. Both can contain code that changes
depending on the other (leaving aside other subsystems). So even if
you do manage to have a system that's all divided into modules, you'll
be left with the cases where one subsystem is affected by options that
control another.

I think if we want to encourage users to tune their kernels to their
needs *and* provide support in a sensible way, we need to provide a
full replacement that can be used, either permanently or temporarily
until the new kernel is built with the user's config file. Whether you
also provide patches for the GENERICs or not should be discussed as an
addition to this main functionality.

FWIW, haze allows you to choose the mode (binary updates or binary
patching) in the configuration file/command line and the usage remains
the same.

-e.