Thread View: comp.sys.acorn.tech
3 messages
3 total messages
Started by /G=Owen/S=Smith/O=SJ-Research/AD...
Wed, 18 Nov 1992 16:31
Re: Getting 3rd Party Filing Systems To Use Showfree
Author: /G=Owen/S=Smith/O=SJ-Research/AD...
Date: Wed, 18 Nov 1992 16:31
Date: Wed, 18 Nov 1992 16:31
54 lines
3023 bytes
3023 bytes
crj10@phx.cam.ac.uk (Clive Jones) wrote:
>The FreeSpace module knows, initially, how to deal with ADFS, RAMFS, NETFS,
>NFS and SCSIFS. Other filing systems have to register by calling:
(...details of SWIs and handlers deleted...)
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).
Next problem, FreeSpace calls you with the return address on the stack (the
one you can't use for anything) rather than in LR.
OS_FSControl 49 - reads free space on the disc or image file that holds a
specified object.
Entry: r0 = 49
r1 = pinter to name of object (null terminated)
Exit: r0 = free space
r1 = largest creatable object
r2 = disc size
If you pass adfs::4.$.PC.Drive_C.DRDOS.TMP in r1, the information returned
in r0-r2 will be for the PC hard disk image Drive_C and not ADFS drive 4.
All of the above information is in the grey cover photocopied PRMs that were
available at the the Acorn User show.
It's a shame you can't do *ShowFree on a per directory basis, because if you
could then you could get a free space display for your PC partition. Also
since RISC OS 3 can get the free space of any image/disk on any filing
system, it's a shame the FreeSpace module doesn't just use this. Then filing
systems wouldn't have to bother with all this registering lark. These sound
like things for Nick and Andrew's filer improvements package to me.
You can intercept the *Free call made by IDEFSFiler with:
*SetMacro Alias$Free If "<Wimp$State>"="desktop" then ShowFree -FS
<FileSwitch$TemporaryFilingSystem> %0 else %Free %0
This should be enough for you to bolt interactive free space display on top
of any RISC OS 2 filing system you may have, unless IDEFSFiler does a *%Free
rather than *Free in which case you'd have to sit on OS_CLI in some way :-(.
Owen.
Re: Getting 3rd Party Filing Systems To Use Showfree
Author: Ran Mokady
Date: Thu, 19 Nov 1992 16:55
Date: Thu, 19 Nov 1992 16:55
47 lines
2483 bytes
2483 bytes
>
>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 !
Sufficient stack space means that you should not go around allocating
buffers out of the stack, or using deeply recursive algorithms, but you
should have no problem if you are just pushing a few registers on the stack.
In fact, I'd be surprised if you ever get called when there are less that
256 bytes free on the stack, but don't quote me on it :-)
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!
>Owen.
Ran.
-----
RMokady@acorn.co.uk |
Ran Mokady | "We're children, Needing other children
Senior Software Engineer | And yet letting our grown up pride
Technical Support | Hide all the need inside
Acorn Computers | Acting more like children than children"
Cambridge, UK. |
Re: Getting 3rd Party Filing Systems To Use Showfree
Author: Brian Brunswick
Date: Fri, 20 Nov 1992 23:14
Date: Fri, 20 Nov 1992 23:14
43 lines
2768 bytes
2768 bytes
In article <20250@acorn.co.uk> RMokady@acorn.co.uk (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. -- Brian.Brunswick@cl.cam.ac.uk Disclaimer. Short sig rules!
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads