Re: Q: Linux rebooting directly into linux.

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

Werner Almesberger <Werner.Almesberger@epfl.ch> writes:

> Eric W. Biederman wrote:
> > Well there is that.  Somehow implementing scatter/gather from 
> > a user space process seemed like a potential mess, and extra work.
> 
> Did you look at kiobufs ? I think they may just have the right
> functionality. I always wanted bootimg to be able to memory-map things
> to reduce memory pressure, and it seems now all the ingredients are in
> place. Your file-based approach could probably use brw_kiovec.

When I looked kiobufs seemed to do a good gather but not a good scatter.
The code wasn't trivially reusable, and the structures had a lot
of overhead.

> 
> > I need to find time soon and write up all of the file format details
> > in an RFC like the GRUB multiboot spec.  Possibly even submit it
> > to the IETF as an RFC for compatible booting and multiple platforms.
> 
> Hmm, if you succeed in selling the format as an integral part of your
> network boot protocol, this may even work ;-)

Well I'd sell it to promote interoperability.  What I'm doing protocol
wise has been RFC sanctions for years.  It's just that every vendor
invents their own format.  So interoperability is a problem.

> 
> > This is the big reason I'm not in favor
> > of the bootimg approach, that doesn't define anything.
> 
> Oh, it does - but the policy is implemented in user space. And, of
> course, it's rather simple. But I'm a little confused with your
> UBE. It only seems to copy the e820 information, so you still seem
> to rely on e.g. the SMP tables the BIOS stores in memory. Also, I
> don't quite see where you're using the saved information. What am
> I missing ?

Defining all of the parameters for the UBE is a separate issue.
It comes next in a couple of weeks.

The rebooting is done the rest is not yet.

As far as where I use the information is used, look in do_kexec.
Right after kimage_get_chunk which figures out where it is safe
to put the information.  

> However, parameter passing like UBE may solve the following two
> potential problems:
> 
>  - kernel 1 copies tables marked by "magic" numbers in memory,
>    then boots kernel 2, which trips over the copy
>  - kernel 1 doesn't know about a table and damages it, then boots
>    kernel 2, which recognizes the table, and trips over it
> 
> But I think we don't need to copy or even convert the entire tables for
> this. After all, any OS that boots on i386 already knows how to parse
> the BIOS-provided tables, so I think it's better to directly re-use
> this code than to invent a new format. A few flags or maybe a short
> list should be sufficient for the problems I've described above.

I agree writing the code to understand the table may be a significant
issue.  On the other hand I still think it is worth a look, being
able to unify option parsing for multiple platforms is not a small
gain, nor is getting out from short sighted vendor half standards.

Besides which most tables seem to contain a lot of information that
is probeable.  Which just makes them a waste of BIOS space, and
sources of bugs.

> > My primary non-linux target are the BSD's, and various experimental
> > OS's.  And in those cases why go to the pain of dropping out of
> > protected mode if you are going to just load back into it again.
> 
> Yep, I fully agree.
> 
> > Compiling the code in it's own file and putting it in it's own section
> > of the kernel for size would probably do it though.
> 
> This is exactly what bootimg does :)
> 
> > Being sure the code is PIC is a little tricky though.
> 
> Yes, for now I cheat and depend on gcc to generate code that just
> happens to be PIC.

Hmm. I wonder how hard it would be to add -fPIC to the compilation
line for that file.  But I'm not certain that would do what I want
in this instance...

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