lkml.org 
[lkml]   [2002]   [Nov]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [lkcd-devel] Re: What's left over.
From
Date
Linus Torvalds <torvalds@transmeta.com> writes:

> On 9 Nov 2002, Eric W. Biederman wrote:
> >
> > And despite my utter puzzlement on why you want the syscall cut in two.
>
> I'm amazed about your puzzlement, since everybody else seem to get my
> arguments, but as long as you play along I don't much care.
>
> I will explain once more why it needs to be cut into two, even if you're
> apparently willing to do it even without understanding:
>
> When you reboot, you often cannot load the image.
>
> This is _trivially_ true for panics or things like

That the load needs to be separate for handling panics is trivially
true. I simply have a very hard time believing that the load you want
for the normal case will be the load you want for a panic. I think
I want to be much more paranoid in preparing for the kernel to blow
up. And I want to move data around much more carefully. And that
care adds restrictions I want for the normal case.

So splitting it up to prepare for panic handling just looks like over
design.

> But it is _also_ true for any standard setup where you don't have
> a special "init" that knows about loading the kernel, and where to
> load it from.
>
> - Do you want to rewrite every "init" setup out there, adding
> some way to tell init where to load the kernel from?
>
> Or do you want to just split the thing in two, so that you can
> load the kernel _before_ you ask init to shut down, and just
> happily use bog-standard tools that everybody is already
> familiar with..

When you can change the init setup with just a couple of lines of
shell script seeing if file exists in magic location (say a special
ramfs or tmpfs), I guess it does not look hard to me.

> The two-part loader can clearly handle both cases. And if _you_ don't want
> a two-part loader, you can do exactly what you do now by just doing two
> system calls.

Right which is why I don't much care, so long as I don't have to test
reboot on panic any time soon...

I doubt we will see eye to eye on this one. So I will now finish up
the patch to split this all up.

> As to vmalloc - I don't actually much care how the first and second parts
> are implemented. I suggested a vmalloc()-like approach just because your
> patch looks unnecessarily complicated to me.

I'd love to make it simpler as well if I saw a clear opportunity that
wasn't just moving the complexity somewhere else. But when I really
look at it I think that I am just wordy.

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/

\
 
 \ /
  Last update: 2005-03-22 13:30    [W:0.247 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site