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.
> 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 ;-)
> 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 ?
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.
> 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.
- Werner
-- _________________________________________________________________________ / Werner Almesberger, ICA, EPFL, CH Werner.Almesberger@epfl.ch / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/ - 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/
This archive was generated by hypermail 2b29 : Thu Nov 23 2000 - 21:00:16 EST