On Wed, 2 Aug 2000, Wolfgang Solfrank wrote:

> Actually, doing 2) wouldn't be _that_ easy due to the way the kernel
> vm is layed out.  (For the record, the kernel is loaded into a 256 MB
> segment that is mapped 1:1 to physical memory.  Therefore reserving
> VA space near the kernel image would require reserving physical memory
> as well).

If it's laid out that way, then that's a hack, and therein lies the real
problem.  :-)  A much better answer is to deal with it that way only for
initial bootstrap (until VM is up), then set aside a whole PTEG for kernel
space (say, PTEG 0), but map exactly what is needed for the kernel.  Then
when you load a module, add another PTE into group 0.  The Mach VM
implementation under MkLinux does something along these lines, as far as I
can tell from trivial perusal.  And we all know how big its "modules" 
(servers) can be.  :-)


> The easiest would probably be do 1), using a path Greg Kritsch pointed
> out in his other mail, i.e. to make use of gcc's ability to compile all
> calls to a function via a function pointer.  Unfortunately, it seems as
> though currently there is no command line option to enable this for all
> functions, so you have to specify the "longcall" attribute for every
> function prototype :-(.

Yes, but you wouldn't _want_ all functions to be compiled that way -- just
the ones that cross module/kernel boundaries.  It really should be done on
a function by function basis if you elect to use this method, but fixing
the kernel mapping is probably easier, and much more flexible.  :-)


Later,
David

---------------------------------------------------------------------
A brief Haiku:

Microsoft is bad.
It seems secure at first glance.
Then you read your mail.