Hmm, that's text+data+bss of a recent 2.1 kernel ? Interesting ... I've
tried to build a "null" 2.1.125 kernel (no file systems, no networking,
no devices, no executable formats, etc.) for the ARM, and I still got a
fairly huge thing:
text data bss dec hex filename
312836 27636 93324 433796 69e84 vmlinux
Seems that your 68k code is much more dense than my ARM code.
> I find this very interesting, from an eclectic viewpoint.
;-) I've abandoned that idea by now ... it's just too messy. The way to
insert the gaps would have had to be something like this:
- obtain the sections and their sizes from all modules (plus alignment
constraints, etc.)
- calculate the right set of modules to use, while preserving the
original sequence of sections (e.g. we want head* at the beginning :-)
- create a linker script with the appropriate output sections
> (And all of this applies equally to user applications that try to load
> over gaps.
Ah no, they see perfect virtual memory anyway. The idea was simply to
avoid using virtual memory for the kernel too.
Then there's another problem, of course: the size of the kernel's memory
map is proportional to end_mem-start_mem, so if I pretend to have a few
MB worth of RAM between start_mem and end_mem, it'll quickly grow to a
few hundreds of kilobytes.
> Simplest, obviously. If you've got an MMU, take advantage of it.
Yep, that's what I'm trying to do now ... ;-)
>> - allocations from start_mem and end_mem are each limited to a total of
>> 512kB
>
> I'm not sure I follow. All allocations of memory with contiguous physical
> addresses would be limited to 512K, yes.
Yes, that's what I meant. The
foo = start_mem;
start_mem += sizeof(*foo);
things.
> How often are virt_to_phys and phys_to_virt invoked? Offhand, I can't see
> why these (or virt vs. bus) should be invoked very often. (I could easily
> be wrong.)
I'm not sure about the relative costs, but considering that they show up
at quite a few places in frequently-travelled code, they may be critical.
I guess I should add a counter once I get this to work :)
> See if you can ditch initrd: if you can boot off a ROM disk,
The use of ROM shouldn't be required, although you probably have to use
some CompactFlash (unless you want to run the Psion with NFS over PPP ;-)
The 6 MB ROM in the machine is forbidden territory before we're really
really, I mean *really* sure that Linux is stable on that box. Even then,
changing/replacing the internal ROMs may be technically unattractive.
But with nice linear VM for the kernel, initrd should be trivial to use.
Famous last words, I know :-)
Thanks,
- Werner
-- _________________________________________________________________________ / Werner Almesberger, DI-ICA,EPFL,CH werner.almesberger@lrc.di.epfl.ch / /_IN_R_131__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.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/