Re: [MiNT] kernel 1.15.10b fragmentation

[Johan Klockars <rand@cd.chalmers.se>]

> > F_OS_SPECIAL does not seem to be terribly well documented (at least I didn't
> > find it when grep:ing through the docs, but there was some comments in the
> > sources), but from what I could see it grants others supervisor access to
> > the memory space of the process that has it set. At least for an AES, that
> > seems like a huge unnecessary risk (but it is of course necessary if the
> > AES is also called in user context).
> 
> As far as I can say this F_OS_SPECIAL thing is a real bad hack in the
> kernel that complicate lot of things.

Well, it really is a pity that the AES was defined the way it was.
I think the server idea could have worked very well (without F_OS_SPECIAL)
if applications had not been able to bypass the AES for resource access
(and if it had been possible to send the necessary parameters quickly
enough).

> > IMO, the current way _is_ the correct one, under the limitations that
> > the AES specification (and the MiNT implementation) sets.
> 
> What limitations sets the MiNT kernel?

It has been a long time since I looked into this now (I did some relatively
significant work on XaAES two years or so ago), but mainly I was frustrated
by the slow and/or limited interprocess communication and synchronization
mechanisms.
Neither pipes, messages (don't recall what those were actually called),
nor even semaphores were near quick (or flexible, in cases) enough to
satisfy me. The unavoidable trap chains certainly didn't improve this,
which was the main reason why I jumped into that discussion some time ago.

-- 
  Chalmers University   | Why are these |  e-mail:   rand@cd.chalmers.se
     of Technology      |  .signatures  |            johank@omicron.se
                        | so hard to do |  WWW:      rand.thn.htu.se
   Gothenburg, Sweden   |     well?     |            (fVDI, MGIFv5, QLem)