Re: [MiNT] Proposal for SLB extension

["Konrad M. Kokoszkiewicz" <draco@obta.uw.edu.pl>]

Hi Joerg

> KMK>Exactly, and the smallest block to allocate (with mp) is 8k for my
> KMK>best knowledge. So doing separate kmalloc() for each application
> KMK>which calls Slbopen(), to hold one longword, would be pure waste of
> KMK>resources.
> On machines with no MP the memory usage is minimal.

Sorry, but the basic mode of MiNT operation is to run with memory
protection enabled, and the possibility to disable this is *optional*. Not
the other way around. So any memory related topics should take the memory
protection into account at the first place.

And despite that, my machine runs with memory protection enabled and i
don'\t want to waste its resources.

> And as machines with MP are in average equipped with more memory than those
> without, the drawback would not as hard for them as for the others. And this
> memory block can also be used for other local SLB execs (for other SLBs) and
> possibly for the SLB exec functions of other applications too...

It doesn't "can", it must be used for oter libs too. However, imho there
is no need to waste even one memory block.

> And don't forget that this is only one possible solution, there sure are
> others and I don't claim it to be the best

I don't (forget) :)
 
> KMK>Also, I disagree with the argument that this creates two different
> KMK>types of libs. Sure it does, but that's not any problem for an
> KMK>application that is gonna use one, since the application sees no
> KMK>difference between these 'types'.
> And my solution does this without creating a new SLB type

The "new" SLB type you're continuously talking about is completely
transparent for applications. I.e. "new" one can be used without problems
even when the kernel does not recognize the extension. And the other way
around. SO there is NO new SLB type, just an extension which utilizes a
legal field in the SLB header provided there for future usage. So, now it
is the future.
 
> KMK>In other words, I can't see why applications could have problems with
> KMK>that, as long as the flags in the SLB header are setup according to
> KMK>the real library's requirements.
> The possible problems are not at the application level, they are at the user
> level!

There are no problems at the user level. If an user want's to have
perfect setup, its his responsibility to find the best libs. Also, SLBs
aren't used by users, but by applications and an application can/must
explicitly specify the requested type/version/name of the library it
needs.

--
Konrad M.Kokoszkiewicz
mail: draco@atari.org
http://draco.atari.org

** Ea natura multitudinis est,
** aut servit humiliter, aut superbe dominatur (Liv. XXIV,25)
*************************************************************
** Taka to juz natura pospolstwa, ze albo sluzy ono unizenie,
** albo bezczelnie sie panoszy.