[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [MiNT] XaAES / GEM memory issues
> Me too, but you can't escape the fact that this is something that
> *traditionally* doesn't belong in the GEMDOS. So adding GUI-related
> functionality to this layer ("layer" in the sense that it runs inside the
> kernel) doesn't break the design any more than the device-interface does.
Gui related (or anything related) device driver: yes. This is perfectly
okay, as long as this "driver" does not draw windows or manages clipping
rectangles (because clipping is somthing that _is_ dependent on certain
gui, isn't it?).
> > I meant, that statical linking is completely unacceptable.
> >
> I'm not so sure about that. I personally prefer loadable modules as well,
> but it's not always something that can be used with the current design of
> FreeMiNT.
Hm, for example? What improvements you propose for the XDD layer?
> I don't know what Frank has in mind re. "kernel modules" though,
> perhaps this is something that can be used to add functionality not covered
> by the traditional filesystem/device modules.
I guess that he just means something that MiNT is currently missing,
e.g. block devices. "Modules" is a word that describes XDD and XFS files,
currently.
> > No, this is something else. Although (this is different topic) I
> >
> Not really, because this can be used to allow legacy code to run even with
> the old AES API.
Hm, can you elaborate?
> I believe it's possible to use the parameter block and still do it in a
> clean way.
Obviously. Parameter block is okay. Not okay is accesing it from other
process, because this is illegal. So, we keep parameter block and access
it from the same process, i.e. from a lib running in user context. I have
an impression that most of the discutants agree on that.
> Only the library should need this.
Indeed.
> But this ofcourse means that the AES library must run in the context of the
> calling process, I assume this is what we're been talking about all the
> time?
Yes, I have an impression that we are talking about it all the time.
--
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.