[lkml]   [2002]   [Feb]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] x86 ELF bootable kernels/Linux booting Linux/LinuxBIOS
"H. Peter Anvin" <> writes:

> Werner Almesberger wrote:
> >
> > Well, it keeps things simple for the kernel, and bootimg(8) needs
> > to know the target architecture anyway. But there isn't really a
> > design reason why it would have to use pages, agreed.
> >
> I looked at this point at some time, and I found that it made it a lot
> easier to write code to permute memory arbitrarily, as may be required.
> The reason is that you really want to keep an array that's O(N) in the
> size of memory to keep track of where things are, and in order to do that,
> realistically, you need to have some reasonably large granularity -- 4K
> pages are just about right.

On the kernel side I still plan to use pages, though my ideal case
would be to allocate one great big slab of non-conflicting memory, and
just copy everything to where it needs to go.

On the user space side what I am proposing actually increases the
granularity quite a bit. For a linux kernel with a ramdisk you should
only need to pass the kernel 3 segments. (Assuming everything is
contiguous in user space memory). The setup code, the kernel, and the

> Of course, maybe I was just using a dumb algorithm... :)

Perhaps. So far I don't need an array that is O(N) in the size of
memory just O(N) in the size of the image I am copying. The
permutations that are necessary to avoid conflicts in the pathological
cases are a pain. But I've already done that...

Anyway now it's back to the trenches...

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

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