Werner Almesberger <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
