Porting RISC OS to Linux

I thought about posting this in the “Porting RISC OS”, but decided against that due to that Linux is not “new hardware”, and calling module entry points in user mode is a big change.

Since Linux programs run in USR mode with no access to the MMU, substantial changes are required.

Linux provides a thread local storage pointer which may be read by calling __kuser_get_tls

There will be 2 simulated banked copies of R13 and R14, one for user and system modes and one for all other modes. These will be stored in a structure pointed by thread local storage pointer :

• SWI Handler address
• Virtual CPSR – lower 8 bits – RISC OS doesn’t use other privileged bits.
• IRQ pending flag
• R13_usr
• R14_usr
• R13_svc
• R14_svc

Write some assembler macros to implement MSR and MRS operating on the virtual CPSR. These macros will, except in the kernel (and perhaps “ROM” builds) will use a branch table set up during module initialisation by a new kernel SWI, I have .

Eliminate the rarely used msr, mrs, mymsr and mymrs macros to allow msr and mrs to generate literal instructions.

Modify Linux to allow all SWI calls to be directed to a kernel module by setting a flag in the thread_info struct. There is already support for directing unknown SWI calls, but since the introduction of EABI, SWI 0 is a Linux system call; on RISC OS SWI 0 is OS_WriteC.

Write a Linux kernel module to direct SWI calls to the RISC OS SWI handler with the callers CPSR and PC already on the stack and the callers PC in R14.

Alternatively I think this can be implemented entirely in user mode on unmodified Linux, at a cost of a thread switch and 2 system calls per RISC OS SWI using ptrace

Modify QEMU to provide the same interface.

The HAL will call the IRQ handler in a similar fashion, but will leave some spare words below the initial value of the stack pointer. Returning from interrupts will be handled using a SWI.

There are two possible implement memory management, either ate the page level with physical memory will be represented as a file, with mappings adjusted with mmap or remap_file_pages, or at the dynamic area level. In either case the allocation of logical address space should be delegated to Linux in order collisions with QEMU etc. I am more inclined to go with the dynamic area level.

In summary, new SWI calls, with proposed names:

• OS_InstallPVOps
• OS_Counter – replaces __counter in the SharedCLibary to avoid mode switching complexity.
• LinuxSupport_Syscall – Linux EABI system call, relocated from SWI 0.
• LinuxSupport_Intercept – enables and disables RISC OS SWIs.
• LinuxSupport_LoadRegisters – Sets R13, sets CPSR, loads high numbered registers from memory, raise signal if IRQ pending.
• LinuxSupport_SetFdCallBack – Call a provided routine when a file descriptor has data ready or can be written to, as either interrupts or callbacks.

I suppose the big question is how much third party software breaks, due to running in user mode. Based upon searching the source for manipulation of the PSR, the IOMD ROM contains a few surprises:

• BASIC
• InternationalKeyboard
• SharedCLibary
• DeviceFS
• UnsqueezeAIF
• Filecore
• NetFiler
• NetFS
• NetPrint

A few modules enable interrupts on entry, why?

Plans changed slightly, with a full set of processor modes being emulated but R8 to R12 not banked.

I have the kernel and few modules running, and once I implement OS_SyncCodeAreas etc, I expect it run on any modern ARM Linux system.

SWIs relating to a MMU or page level memory management are not implemented.
ZeroPage is relocated to &307F0000
OS_AMBControl is not yet implemented.
Dynamic area are implemented, except sparse dynamic areas.
No persistent filing system is implemented yet.
A couple of SWI numbers need allocating.

I have had a few SharedCLibrary programs running, including the ROOL/Acorn linker.

Any suggestions for a suitable license? New components are a HAL, a Library for making Linux system calls, and an (optional) Linux kernel module for directing SWI calls to RISC OS.

A sample run:

tim@versatile:~/RISC_OS$ IOMDHALDev/Images/Test,fe5 --nvram CMOS
Personality not availiable so using ptrace - This maybe slow.
Hello World
...............
...............
15 of 15 interrupts counted.
Starting kernel...
Init_MapInRAM2
Init_MapInRAM2
Init_MapInRAM2
HAL initialised
IICInit
HAL_KbdScanSetup
Allocating stacks
Init_MapInRAM2
Init_MapInRAM2
Init_MapInRAM2
Init_MapInRAM2
Init_MapInRAM2
Init_MapInRAM2
Init_MapInRAM2
Init_MapInRAM2
Init_MapInRAM2
Init_MapInRAM2
Init_MapInRAM2
Init_MapInRAM2
InitCMOSCache entry
InitCMOSCache done
Before IMB_Full
IMB_Full done
Keyboard scan complete
POR detected
InitDynamicAreas
Application Space
InitVectors
InitIRQ1
IMB_Full
VduInit
ExecuteInit
KeyInit
MouseInit
OscliInit
Enabling IRQs
IRQs on
Debug terminal on
HAL_InitDevices
InitVariables
AMBControl_Init
ModuleInit
init mod UtilityModule
init mod FileSwitch
init mod ResourceFS
init mod TerritoryManager
init mod Messages
init mod MessageTrans
init mod UK
init mod BASIC
init mod BASICTrans
init mod FileCore
init mod RamFS
init mod Obey
init mod PipeFS
mod init done
Service_PostInit
callbacks

RISC OS 256MB

Acorn ResourceFS

No keyboard present - autobooting
ARM BBC BASIC V version 1.54 (C) Acorn 1989

Starting with 651516 bytes free

>PRINT TIME
       983
>*Cat Resources
Dir. Resources:$.Resources Option 02 (Run) 
CSD  Resources:"Unset"
Lib. Resources:"Unset"
URD  Resources:"Unset"
BASIC        DWR/    FileCore     DWR/    FileSwitch   DWR/   
Global       DWR/    Kernel       DWR/    MsgTrans     DWR/   
Obey         DWR/    PipeFS       DWR/    RAMFS        DWR/   
ResourceFS   DWR/    TerrMgr      DWR/    UK           DWR/   
>*Modules
No. Position Workspace Name
  1 3041BC38 00000000  UtilityModule
  2 3043D238 20000014  FileSwitch
  3 3044ABCC 200014D4  ResourceFS
  4 3044B8B4 20001514  TerritoryManager
  5 3044DDC4 00000000  Messages
  6 30461320 20001614  MessageTrans
  7 30462710 20003134  UK
  8 30464310 00000000  BASIC
  9 30473E58 200036D4  BASICTrans
 10 30474C00 20003DD4  FileCore%RAM
    30474C00 00000000  FileCore%Base
 11 304889BC 20003D34  RamFS
 12 304892CC 00000000  Obey
 13 30489C6C 200150D4  PipeFS
>*ROMModules
No. Position    Module Name             Version Status
  1 System ROM  UtilityModule           5.21    Active
  2 System ROM  FileSwitch              2.82    Active
  3 System ROM  ResourceFS              0.25    Active
  4 System ROM  TerritoryManager        0.55    Active
  5 System ROM  Messages                1.10    Active
  6 System ROM  MessageTrans            0.49    Active
  7 System ROM  UK                      0.58    Active
  8 System ROM  BASIC                   1.54    Running
  9 System ROM  BASICTrans              2.15    Active
 10 System ROM  FileCore                3.63    Active
 11 System ROM  RamFS                   2.29    Active
 12 System ROM  Obey                    0.39    Active
 13 System ROM  PipeFS                  0.22    Active
>

PS. Why is the above double-spaced? (Edit: fixed)

very interesting results!!
the double spaced lines are probably due to cr lf in the output.
Any place where i can take a look at the code? I have plenty ARM boards but most of all got a ARM chromebook that I would love to use to try this out. (the chromebook runs Ubuntu)

Any suggestions for a suitable license?

Not GPL, please.

Take a read of the EUPL, see if you like that?
https://joinup.ec.europa.eu/software/page/eupl/licence-eupl

Interesting outcome! You must be very pleased with this :-) As for the double-spaced appearance here, try editing to include blank lines outside the <pre> tags.

Nice idea.

Is this a problem at all?

http://ro-lookandfeel.blogspot.de/2011_07_01_archive.html

The problem is that at least one instruction to return to user mode (MSR CPSR_c, r1) is still a legal instruction in user mode (i.e. its execution isn’t flagged as an exception), so ROLF can’t detect that it should switch the “banked” registers it emulates.

Presumably you can just modify the source to use different instructions.

Rick: Why not GPL?

Second attempt, as the piece of crap Safari in iOS 7.0.3 seems to like throwing away web pages almost as much as Android. Switch to a new tab for 10 seconds? Okay, then that message you spent fifteen minutes writing is history, na na na-na… So this is written in QuickOffice and a cut’n’paste later…

Rick: Why not GPL?

In a nutshell, the GPL is a creeping cancer. While it’s creators and the veritable armada of fervent supporters talk about freedoms and such, the GPL is:

• compatible only with itself
• a legalese nightmare, a lot of which hasn’t actually been tested in court (thus reality could easily differ from expectations – note that the GPL has been around coming on two decades, and people are still confused by the issue of what constitutes linking – don’t expect the GPL itself to clarify things much)
• compatible only with itself
• increasingly restrictive, GPL v3 is bordering on taking the p…s for a so-called free licence
• compatible only with itself

To put this into context, take a look at the Compatibility Clause in section 5 of the EUPL. Note how it permits you to take EUPL code and relicence it to fit in with a more restrictive licence. You don’t need to ask, the EUPL specifically permits you to take EUPL code and use it within a GPL project. The same is not true in reverse.
Furthermore, note how the list of compatible licences (appendix at the end) includes GPL v2 but not v3. It probably says a lot that the EU doesn’t consider the latest GPL to be in the spirit of things.

It isn’t just me on an anti GPL rant. The Linux kernel is a GPL v2 project, and may not ever become v3 – here is why: http://lwn.net/Articles/200422/ I find it a rather damning indictment that the people who you thought would have fully supported the GPL have turned away from this incarnation. But they are right. The free licence is increasingly less free, to the detriment of all of us. And, as mentioned way too much above, it is solidly compatible only with itself. Actually, while it guarantees source code is available, it attempts to coerce other source code, and, well, that’s a damn weird concept of freedom you have, Mr. Stallman!

Some other stuff to look at:

• http://java.dzone.com/articles/why-gpl-or-how-gpl-eats-kitten
• http://m.linuxjournal.com/article/5935
• http://www.homolog.us/blogs/blog/2013/07/31/another-reason-gpl-is-a-bad-license/

The last one is particularly interesting. I have, already, seen a GPL program I liked and thought it might be nice to work with, port, etc. Then I realise maybe some of the functions and methods could be recycled in my other programs.
This is when the chilling effect begins. I respond to it by deleting all of the GPL code, and either writing my own implementation from the ground up, or saying “I’ll do it another day” and that day never comes.
Not because I don’t want a GPL project, not because my projects are not compatible with the GPL, but because the GPL is not compatible with me or my projects. With what happened with Castle in the back of my mind (and note the absence of GPL within the RISC OS kernel), I really can’t be bothered with the hassles.
The aim of the FSF is laudable. By contrast, the GPL is laughable.

If you think, somewhere down the line, your software might have some commercial value (running RISC OS software on something that isn’t RISC OS could lead to some interesting developments in the future), you might want to read the last article above very carefully.

And when/if you release your program to the world, I will use it if it can work for me, but if the source code is GPL, I won’t go anywhere near that. Sorry, that’s just how it is.

Ultimately the decision is yours to make. I’m just trying to suggest to you that there are better options than the GPL.

MSR CPSR_c, r1

Wouldn’t that be supportable by keeping track of whether or not the program thinks that it is in SVC mode? That way, if you come across an instruction such as this, you’ll know how to handle it…

Wouldn’t that be supportable by keeping track of whether or not the program thinks that it is in SVC mode? That way, if you come across an instruction such as this, you’ll know how to handle it…

I don’t think so. Jan Rinze and I were trying to get a RISC OS personality working on Linux a couple of years ago, and the problem was that MSR CPSR_c, r1 executes in USR mode without the processor skipping a beat, so the program can’t tell if it’s still meant to be in SVC or USR mode. Of course, eliminating all occurances of that form of instruction from the RISC OS code (and any 3rd party modules) would solve the problem.

My solution was to re-implement an emulator to emulate ARM on ARM, it still needs a bit of work on unaligned memory accesses, though. It’s GPL, so it can be used in any GPL projects :)

Seriously, it’s mine and Jan’s, so another licence would be possible (only two people to ask).

From your other post:

If you think, somewhere down the line, your software might have some commercial value (running RISC OS software on something that isn’t RISC OS could lead to some interesting developments in the future), you might want to read the last article above very carefully.

I’m reading your links, by the way, but it may take some time. That said, paragraph one of the last article saying “GPL is dead in the real software-land.” isn’t off to a good start, especially as the first article gives no impression that Linux is going to move away from GPL.

btw. I’ve already run some RISC OS software on something that isn’t RISC OS. AWRender, if not ArtWorks, runs on ROLF, for example.

OK, that last link: http://www.homolog.us/blogs/blog/2013/07/31/another-reason-gpl-is-a-bad-license/

It says:
1 government-funded academic programmers is [sic] fully embracing GPL license
2 GPL is dead in the real software-land
3 Sean Eddy copyrighted HMMER
4 GPL license has been disastrous for small software companies
5 the idea of sharing code is often spurned in academia
6 Are firms responsible for GPL violations on code they receive from third parties? A German court thinks so. http://yro.slashdot.org/story/13/07/30/1527231/german-court-finds-fantec-responsible-for-gpl-violation-on-third-party-code

1 & 5 contradict each other
2 implies Linux is not in real-software land
3 Is wrong. HMMER is now a trademark for the “official” open source HMMER codebase, which is GPLv3
4 Has no evidence to support it at all; I would say it allowed small (and large) software companies to develop bespoke systems using GPL code for their customers to use, with no requirement that the customers make the work freely available, as long as they don’t distribute it further
6 Is an example of the GPL working exactly as it should:

Basically the scheme is the following: A gives code to B under a given license. B then gives the code to C in a way that violates A’s license. C relies on B having followed A’s license and figures out that redistribution in a certain way would not violate A’s license. However since B’s analysis rests on the false assumption that B complied, it turns out that C’s redistribution of the code also violates A’s license. But with a closer inspection, C could have found out that B didn’t comply. The court ruling now says that C is responsible for violating the license.

Here A is whoever owns the copyright for the code in question, B is Fantec’s firmware supplier, C is Fantec, the license is the GPL, and the violation is not distributing the complete corresponding source code

A later comment in the same thread http://yro.slashdot.org/story/13/07/30/1527231/german-court-finds-fantec-responsible-for-gpl-violation-on-third-party-code points out:

If you read TFA you’ll see that this is not their first time violating the GPL on the plaintiff’s code. The first time, they were allowed to correct the error and sign an agreement that they wouldn’t let it happen again. There was a monetary penalty attached to further violations. They did, in fact, violate the licence on the same software AGAIN. They were offered the opportunity to correct the error, pay the agreed upon penalty and call it good, but they refused. Then and only then did they get sued.

Of course, eliminating all occurances of that form of instruction from the RISC OS code (and any 3rd party modules) would solve the problem.

Could you not make a trap instruction to replace this one, that you can pick up and handle when it faults? (sort of like how FPE worked)

It’s GPL, so it can be used in any GPL projects :)

But not in anything else…

That said, paragraph one of the last article saying “GPL is dead in the real software-land.” isn’t off to a good start, especially as the first article gives no impression that Linux is going to move away from GPL.

I think what that means is in respect to commercial offerings. Linux is a peculiarity in that it is not commercial, Linux isn’t “sold”, it isn’t commercial.
On the other hand, if you have a little bit of hardware that is a media player and your audio decoder is based upon a GPL project, and it is an intrinsic part of your firmware…are you obliged to release your firmware sources as GPL? Does this hold true if the GPL component is two files in two hundred? What does this do to the product commercially?
I wonder about firmware updates for ADSL boxes. When it boots a version of Linux, you know there is GPL in there. If the entire firmware is one lump that gets flashed in, shouldn’t that imply that GPL applies to it all? Including the network specific commercially sensitive parts that they don’t want Joe Public messing with? Hmmm…

1 & 5 contradict each other

Not necessarily. It depends who is releasing the code. One I heard of a while ago (perhaps on The Register) is that students were releasing their code as GPL and sharing between them (“them” being in different establishments), because the powers that be would rather squirrel away good software for their own benefit and not have it shared. So dumping stuff on the likes of sourceforge was probably a rebellion against this practice.

2 implies Linux is not in real-software land

Could have been worded a lot better. I take this to mean “commercial software” (as in, software inside stuff, not just that which you buy in PCWorld). We know this in a factor, the anti-Tivosation part of GPL v3 is for… TiVo… A “box that does stuff”.

to develop bespoke systems using GPL code for their customers to use

Again, it depends upon what you are looking at. How bespoke is the system? A full application layer, like a database for managing a library? If this uses GPL parts, and is therefore GPL itself, what is to stop the customer from requesting the sources and then developing it themselves? Or even forking it and making their own versions for others? This might be in the spirit of the free software ethos, but it isn’t going to do your business any favours…

Have a look at this for more on the potential problems:
http://www.freebsd.org/doc/en/articles/bsdl-gpl/gpl-advantages.htm

Oh, and:
http://books.google.co.uk/books?id=I-hVqkX6A9cC&pg=PA21&lpg=PA21

as long as they don’t distribute it further

…however, they are entitled to if they wish.

“They were offered the opportunity to correct the error, pay the agreed upon penalty and call it good, but they refused. Then and only then did they get sued.”

Oooookay… They were twats. Noted.

It might be worth saying, again, about the distinct lack of GPL code within RISC OS itself. The cvs archive contains three LGPL sources (JSmith) but I don’t recognise the names so I don’t think they actually get baked into the images.
Why is this?
Is it, perhaps, that the inclusion of GPL code within RISC OS might require RISC OS itself to become GPL? The whole issue of linking becomes quite a mess when talking about RISC OS which was designed from the outset to be highly modular. Trying to argue that a GPL module in the ROM image doesn’t count as a part of RISC OS is about as likely to work as trying to argue that WindowManager (a different module in the ROM image) is not a part of RISC OS.
Now think about us, and Castle, and RISC OS itself. I reckon what we stand to gain from including GPL is outweighed by what we stand to lose from doing such a thing.

Have a look at this for more on the potential problems:
http://www.freebsd.org/doc/en/articles/bsdl-gpl/gpl-advantages.htm

404 not found

try
http://www.freebsd.org/doc/en/articles/bsdl-gpl/gpl-advantages.html

http://books.google.co.uk/books?id=I-hVqkX6A9cC&pg=PA21&lpg=PA21

Building Embedded Linux Systems

“You have reached your viewing limit for this book”

My Humax FoxSat runs this: Linux Foxsat-HDR1 2.6.12-4.2-brcmstb #1 Fri Jul 27 10:24:17 KST 2012 7403a0 GNU/Linux, it’s the reason I can access it via a web interface thanks to some excellent, free, modifications.

But that’s beside the point.

Could you not make a trap instruction to replace this one, that you can pick up and handle when it faults? (sort of like how FPE worked)

I expect so, but you’d still have to scan through all the code to find them, and you’d have problems if a constant somewhere happens to match the bit pattern, which is why the ARM-on-ARM emulator is the best approach to detect these things at runtime. Removing them from the source code would be preferable.

Now think about us, and Castle, and RISC OS itself. I reckon what we stand to gain from including GPL is outweighed by what we stand to lose from doing such a thing.

I agree, the code written specifically to port RISC OS to Linux should probably not be GPL, although there’s no reason you can’t use LGPL code in the OS because the authors specifically licence it to be used in non-GPL programs.

Part of the idea of GPL is to free the customer from the vendor. I can see why vendors may not like that idea, but there it is. It frees your hypothetical library to maintain the system they paid for to be built, although most larger organisations are more likely to pay for ongoing maintenance contracts than hire some engineers to modify it, unless the rates get extortionate.

If you don’t like the licence, don’t use the software, it’s the price the people who wrote the software decided to put on it.

There’s some GPL version 2 with exception header files from Linux used by the RISC OS kernel and HAL. The exception is:

NOTE! This copyright does not cover user programs that use kernel
services by normal system calls – this is merely considered normal use
of the kernel, and does not fall under the heading of “derived work”.

As such it is like many normal Linux programs.

I’ve made some changes to Linux (optional) and QEMU, these of course come under the licence of the respective projects.

I will go with a BSD style license, for the new components. There isn’t much to add to them that can’t go in a RISC OS module, and they aren’t much use outside RISC OS.

Of course, eliminating all occurances of that form of instruction from the RISC OS code (and any 3rd party modules) would solve the problem.

I’ve eliminated them from the RISC OS kernel by replacing them with Objasm macros.

@Timothy:
I have an XScale laptop here that runs Linux. I was considering to try to duplicate your efforts and to have the framebuffer device to show the RISC OS screen.
For that there are a few options, either map the fbdev to the RISC OS screen area or have a thread copy the data to the fbdev. (last one would be slow but could do some nice colour translations and resizing.)
Do you have a project page somewhere with the required changes/patches? I can build ROMs on the Panda, have all sources for the kernel of the laptop etc.

I am gradually uploading patches to: http://tim.majoroak.me.uk/ROL1/ as I test them in IOMD builds and get feedback.

Currently present:

• A fix for the invalid comments in the ExportVals Makefile
• A fix for TickIrqReenter option, which if disabled unbalances the stack.
• A fix for BuffPtrInitLoop, which doesn’t terminate properly.
• Move the kernel includes into a separate file, in order that they can be included in another file to generate a C header file used internally in the kernel (implementing dynamic areas).
• Fix DebugTX to preserve LR and CPSR, it’s hard find bugs when debugging code alters the behaviour of the code.
• Fix some comments relating to Dynamic Areas

More shortly…

Now uploaded:

• The changes to move dependencies out of Makefiles, as I described on the Code Review forum.
• A new header file, containing the Objasm macros vMSR and vMRS which will (in a later patch) emulate MSR and MRS. Any comments on the name of these macros? I’ve just realised they clash with VFP instructions except for the case.
• Use the macros in AsmUtils.
• And in the Kernel.
• Remove soft resets, I assume this is not useful and only serves to make the code confusing.
• Use OS_ChangeDynamicArea to set initial size of the application space, and limit to a more reasonable 640K.
• Change mymrs and mymsr to use the mnemonics.
• Then change Generic32 and Generic26 to use vMRS and vMSR

Now uploaded:

• HAL, System call library, scripts for maintaining Linux headers, build scripts etc.
• Headers from Linux 3.10.16
• HdrSrc changes

The next 2 patches may be controversial among die-hard assembler fans:

• Bring s.End back into use
• Then add a C file into the kernel (real contents later).

More:

Pad the SWI handler upto it’s allocated size, this is a temporary hack until the size is stable.

Change the ROMLimit check in callback handling so that the end of the ROM need not be a valid ARM immediate constant:

diff --git a/castle/RiscOS/Sources/Kernel/s/Kernel b/castle/RiscOS/Sources/Kernel/s/Kernel
index 20caeb0..9b0b5cb 100644
--- a/castle/RiscOS/Sources/Kernel/s/Kernel
+++ b/castle/RiscOS/Sources/Kernel/s/Kernel
@@ -645,8 +645,8 @@ callback_checking
         CMP     r0, #ROM
         BHS     Do_CallBack
  |
-        CMP     r0, #ROM
-        RSBHIS  r12, r0, #ROMLimit
+        SUBS    r12, r0, #ROM
+        RSBHIS  r12, r12, #ROMLimit - ROM
         BHI     Do_CallBack
  ]
       [ :LNOT: FixCallBacks

Is the above correct?

• Use the MOVS_PC_LR macro in the Kernel
• Move the dynamic area flags from s.ChangeDyn to hdr.KernelWS
• Map ZeroPage before allocating HAL workspace,
• The rest of the changes to the kernel
• Fileswitch changes

That’s sufficient to boot to a command line, commentary on the rest of the patches will have to wait, but most of them are uploaded.

I have uploaded complete source and the executable.

I’ll have a look at it tomorrow. The sheer amount of work you have done is amazing!

hope to post some results back soon about my attempt to get this working here.

What’s your eventual goal with this? Is it just something fun to play around with, or is it part of some grand scheme to revolutionise the OS?

Linux system calls are prefixed with “sys_” to avoid name clashes with the C Library, Unixlib etc. The prefix “sys_” was inspired by use in Linux, I rejected “linux_” as too specific, someone might want to port this to BSD sometime. Unfortunately this does not help with the names of constants or structures.

2 SWI names and numbers need allocating:

• 0xC0000 – This is all Linux system calls, multiplexed by R7 and relocated from SWI 0, which clashes with OS_WriteC. It would appear that the top-level registry of SWI numbers has been abandoned, leaving only per OS allocations.
• 0xC0001 – This is used to enable SWI intercepting provided by my modifications to QEMU and a Linux kernel module, which take the place of slow method in the HAL.
  Would the names LinuxUtils_Syscall and LinuxUtils_InterceptSWI and a module SWI alloction, shared with a future LinuxUtils module be okay?