Re: [MiNT] Cookie Jar problem

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

Hello!

> > point to a reasonable address. In case of STIK we either make it point to a
> > global area established by gluestik, and make it unsafe by definition this
> > way, or integrate STIK emulation into kernel (I'd strongly dislike that).
>
> I don't know if you noticed but that's why gluestik is placed in global
> memory.

I did. The point is, as I understand, how to make the gluestik work with
the non-global cookie jar, right? You proposed the Ssystem() expansion,
but this would make the entire modification pointless (the point of making
jar private is avoid a situation when a buggy or maliciously written
program destroys the jar thus influencing all processes which would look
it up; with Ssystem() modifying all the copies this would still be
possible).

If gluestik would be an XDD, it would be able to place its cookie into
kernels cookie jar. This way the STiK cookie would become available for
all processes, and no kludges in Ssystem() are needed ("wolf/ox"
solution).

> > Obviously, if someone doesn't need such safety, can give up the private
> > cookie jar and use STiK programs ad libitum.
>
> It's just the problem that exactly these users are not abale to compile a
> kernel by itself.

It is up to you to decide, what compile switches to choose for the
distribution kernel. Besides, this is just an experiment. If it turns
over, that it creates more problems than advantages, restoring the
previous situation is harmless.

CVV

-- 
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.