NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/sys/acorn/tech/705

Text File | 1992-11-20 | 2.6 KB | 57 lines

Newsgroups: comp.sys.acorn.tech
Path: sparky!uunet!pipex!warwick!pavo.csi.cam.ac.uk!bdb
From: [e-mail] (Brian Brunswick)
Subject: Re: Getting 3rd Party Filing Systems To Use Showfree
Message-ID: <[e-mail]>
Sender: [e-mail] (USENET news)
Nntp-Posting-Host: ely.cl.cam.ac.uk
Reply-To: [e-mail] (Brian Brunswick)
Organization: U of Cambridge Comp Lab, UK
References: <ARM200-921118163118-7952E65F*@MHS> <[e-mail]>
Date: Fri, 20 Nov 1992 23:14:23 GMT
Lines: 43

In article <[e-mail]> [e-mail] (Ran Mokady) writes:
( Quoting Owen smith at start0
>>
>>Actually using this is a bit tricky. Brian Brunswick has working code which
>>uses this in Memphis (possibly not the released version). The biggest
>>problem is that when the FreeSpace module calls your handler routine, you
>>are in User mode and R13 points to the FreeSpace module's private stack in
>>it's workspace. This is of zero gauranteed depth ie. you can't use it, so
>>you have no stack (unless you want to over-write random bits of RMA). So you
>>need to supply your own stack, or not use any stack, or call SWI OS_EnterOS
>>to get the SVC stack. You can ease the problem by doing as little work
>>yourself as possible eg. call SWI OS_FSControl 49 (get free space) to do all
>>the work for you for free space reason code 2 (the other option for IDEFS
>>is to call IDEFS_DescribeDisc).
>>
>
> This is not quite as bad as you try and present it ...
>
> By the same token, you are never guaranteed that there is any free space on
>the SVC stack, and so should check every time before you push a register.
>
> The routines are called in USR mode, WITH SUFFICIENT STACK SPACE !
>
...
> In fact, from having a second look at the code, for some of the reason
>codes you may be called in SVC mode, so don't go round allocating a stack
>and making R13 point to it, or you may end up corrupting the SVC stack
>pointer!


It wouldn't have been so bad if I hadn't been writing in C with cmhg
style headers on the entrance, that fix up the stack chunks for you.
I was mystified as to why my routines kept reporting out of memory
errors for allocating from the rma... until I found out the the stack
pointer that I was being passed was in the RMA, so that the stub
routine ahppily put the C relocation offsets over the beginning of the
RMA area, corrupting its heap, so allocation failed. Of course, when I
returned an error the exit routine UNcorrupted them again...
Eventually I wrote some m/c stubs that used FSControl freespace,
and settled for implementing the fscontrol properly in call my fses.

--
[e-mail]  Disclaimer.  Short sig rules!