Re: 2.6.17-rc1-mm1: KEXEC became SMP-only

[ebiederm@xmission.com (Eric W. Biederman)]

Zachary Amsden <zach@vmware.com> writes:

> No, this cleanup only eliminates the need to duplicate redundant code.   How
> does a machine vector make it any harder to break?  You still have a function
> with multiple definitions.  Duplicating code makes things really easy to break -
> twice.

Sharing functions is good, but if you don't share things carefully your code
becomes very brittle because it depends in non obvious ways on other
code.

A machine vector isn't exactly what is needed (although that allows building
all of the subarches at the same time).  What is needed are clear places
where the sub architectures get called.

The lack of visibility is what makes subarch code so easy to break right now.

I have had times where I have made a global change and fixed up the entire
kernel and all that broke was the i386 subarchitectures because there
was a dependency but it was totally invisible.  Despite testing on and
being most familiar with i386.

For example every other arch only has one implementation
of machine_restart, machine_halt, machine_power_off, and if they
have subarchitectures they have calls to subarch_restart, subarch_halt,
and subarch_power_off.  At which point it is trivial to see that
the code lives in a subarchitecture.

Even if that code turns right around and calls a common function on
all but one of the subarchitectures, at least the logic is visible when
you read the code.

If all you are doing is this one little clean up we can probably stop here.
But this looks like a start on getting a vmi or xen subarch working.

If this is really a prelude to introducing more subarchitectures we
need to fix the infrastructure, so it is obvious what is going on.
I would really like to see a machine vector, so we could compile in
multiple subarchitectures at the same time.  That makes building
a generic kernel easier, and the requirement that the we need
to build a generic kernel makes the structure of the subarchiteture
hooks hierarchical and you wind up with code whose dependencies
are visible.  Instead of the current linker and preprocessor magic.
Functions named hook are impossible to comprehend what they
are supposed to do while reading through the code.

Eric

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