To: perot@pallas.amp.uni-hannover.de
Subject: Re: Ownership problems again, oh no ...                                         


On Mon, 6 Jan 1997 18:00:56  Peter Rottengatter <perot wrote: 
>
>It seems to me that GEMDOS, under MagiC at least, accesses the serial 
>buffers directly, instead of going via BIOS and the vectors. As a 
>consequence, inserting vectors to dummy routines does not prevent other 
>apps, like CoNnect, from accessing the serial port. Thus some characters 
>go to CoNnect, others go to STiK, stupid.

Yes, but he probably did this to achieve higher speed for the gemdos Fread
and Fwrite operations, which otherwise waste lots of time on multiple BIOS
calls.  I can understand his choice, although it does eliminate the level
distinction between GEMDOS and BIOS.


>I've thought about this a lot, and the only solution I could come up is 
>using Fopen to allocate the port, in conjunction of the p_run trick to 
>move ownership to STiK. Would also solve the problem of switching between 
>LAN and SERIAL2. The BIOS vectors can still be used from the STiK work 
>thread. What do you think ? Do you have any alternative idea ?

No, that is the only satisfactory way I know for doing what we need.


>So if we really need to do this. I'd supply another call to the STX 
>interface :
>
>uint32  STiK_exec (uint32 (* func) ());
>
>This call would very much like Supexec() execute a piece of code within 
>STiK context, i.e. p_run set to the STiK basepage during execution. Do 
>you like it this way ? I guess `func' must be called in Super mode, to 
>prevent task switching. I'd raise the interupt mask too, maybe.

Having such a function in the interface easily can easily lead to abuse,
and internal functions should not use it anyway, since a macro is faster.
I agree that there should be a way for STXs and clients to do this also,
but I want them too to be able to use the fastest (asm macro) method, and
this requires that the basepage address itself must be accessible.

Like this:

void  *STiK_base_p;

That guarantees that only those who know what they're doing can use it,
thus making abuse a lot less likely, and allows both STXs and clients to
use maximum speed by eliminating function call overheads.  The pointer
can be read at init of STX or client, and moved to a local 'STiK_base_p'
variable, which can then be used like below:

	move.l  p_run_p(pc),a3		;this assumes a3 was free for use
	move.l	(a3),-(sp)		;save entry 'owner' basepage ptr
	move.l	STiK_base_p(pc),(a3)	;setup STiK basepage a new 'owner'
	gemdos	Fopen,dev_name_s,#2	;open the device through GEMDOS
	move.l	(sp)+,(a3)		;restore entry 'owner' to p_run
	move	d0,device_h		;store and test device handle
	bmi	some_error_code		;go elsewhere on error

In C the same thing could be done as:

	latest_p = *p_run_p;		/* save entry 'owner' basepage ptr */
	*p_run_p = STiK_base_p;		/* setup STiK basepage a new 'owner' */
	device_h = Fopen(dev_name_s,2);	/* open the device through GEMDOS */
	*p_run_p = latest_p;		/* restore entry 'owner' to p_run */
	if (device_h < 0)		/* store and test device handle */
		goto some_error_code;	/* go elsewhere on error */

Normally the method should only be used for five GEMDOS functions, which are
Fopen, Fclose, Malloc, Mxalloc, and Mfree.  It will be quite easy to make
include files for both C and assembler containing some macro definitions that
implement this method for those functions, and declares the pointers needed.

Note that I am not fanatically set against your suggested function, but see
it as a possible addition to the basepage variable.  The function alone is
not satisfactory, since it limits the speed by imposing extra overhead.
That does not matter so much for the dialer's needs, but could matter more
when some STX needs to create a file or memory block to be owned by STiK,
since this could happen during active communication.

The most flexible solution is of course to include both in the API.

-------------------------------------------------------------------------
Regards:  Ronald Andersson                     mailto:dlanor@oden.se
                                               http://www.oden.se/~dlanor
-------------------------------------------------------------------------
