Messages in this thread | | | Subject | Re: [RFC] x86 ELF bootable kernels/Linux booting Linux/LinuxBIOS | From | (Eric W. Biederman) | Date | 05 Feb 2002 00:45:33 -0700 |
| |
"H. Peter Anvin" <hpa@zytor.com> 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 ramdisk.
> 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...
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/
| |