On Wed, 2 Aug 2000, Wolfgang Solfrank wrote:

> > If it's laid out that way, then that's a hack, and therein lies the real
> > problem.  :-)
> 
> It's not more of a hack than any other design decision.  Remember that not
> all of the world is Linux.

Umm... I never said it was.  I don't do Linux coding.  I really don't like
the Linux kernel that much.  :-)  I do Mach coding.  Mach basically looks
like BSD under the hood, just without most of the high level interfaces.


> > 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.
> 
> Huh?  AFAICT, a PTEG contains just 8 mappings, so you can map at most
> 32 KB with one PTEG.  Not too much :-).

Ah.  Sorry, misremembering the terminology here.  That'll each me to
comment on Mach's VM setup without actually digging out the code....  :-) 
It has a separate _space ID_ for the kernel, SID=0.  Not a PTEG.  You're
right.  That would make no sense the other way.


> > 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.  :-)
> 
> Why not?  1. it will be done only for LKMs, and 2. it's more or less
> done this way for the PowerOpen ABI on all function calls, so it probably
> isn't too bad.

I interpreted your statement to mean that all function calls would have
the extra overhead (i.e. every function call, including those that never
left the kernel).  Doing that for all LKM functions is certainly
reasonable.


David

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

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