Re: Supexec/Super patch?

["Konrad M.Kokoszkiewicz" <draco@mi.com.pl>]

> > OK, what about another way: implement a system call allowing to access
> > (to read) vital GEMDOS variables, like p_cookie or hz_200, from any user
> > process and prepare a whole MiNT distribution (like KGMD is) supporting
> > it?
> 
> That's more or less what I was talking about all the time. But I think
> we should have an own system call for each variable. Otherwise we get
> problems with the return types (one is long, one is short, one is
> pointer, one is time_t, etc.). This is also less vulnerable to changes
> in the future. Probably we can group some variables that belong
> together somehow.

Hm, it may be rather hard to do, we would run out of free function codes
very quickly 8) But since all these variables are either words or
longwords, and the system used to return everything in d0, the question
of several different types is just an usual C-language crap. From the
"low-level" point of view, there are only two types, word and longword
(perhaps some are bytes, I am not sure), as I wrote above.

So, it may be one function "read-a-GEMDOS-variable" with two parameters:

1) word: 16-bit address
2) word: code for word (0) or longword (1) to be fetched and returned.

The value would be returned in d0. Of course, it may be considered a way
to handle an error from this function, for example when the user is
not allowed even to read a variable, but I don't think it is much
critical. You may read everything and it is not useful for you as
long as you aren't able to write. Of course, the function may just
return zeroes for variables the user is not allowed to inspect or should
not have any interest in them (interrupt autovectors, traps etc).

So it may be something like this:

	move.w	#$01,-(sp)		;read longword
	move.w	#_hz_200,-(sp)		;from _hz_200.
	move.w	#Sreadsysvar,-(sp)	;(or whatever name you like)
	trap	#1
	addq.l	#$06,sp

The only thing to do (after such a function would have been implemented)
is to adjust MiNT Libs...

Gtx

Konrad M.Kokoszkiewicz

mail:draco@nidus.mi.com.pl
     draco@irc.pl
     draco@piwo.bl.pg.gda.pl
     conradus@avanti.orient.uw.edu.pl
     conradus@plearn.edu.pl
     draco@nuova.id.uw.edu.pl
http://www.orient.uw.edu.pl/~conradus/
 IRC:[Draco]

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