[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RISC OS port

From: Timothy Baldwin
Subject: Re: RISC OS port
Date: Sat, 27 Nov 2004 01:36:16 +0000
User-agent: KMail/1.7

On Friday 26 Nov 2004 10:18, Marco Gerards wrote:
> Timothy Baldwin <address@hidden> writes:
> > On Tuesday 23 Nov 2004 18:03, Marco Gerards wrote:

> > Attempting to use a filesystem handler within Grub would be unreliable
> > due the filesystem also being mounted read/write.
> Usually a filesystem is still usable readonly when it is mounted rw.
> This is the same as it is for grub-emu, for example.

The auto-defragment feature makes FileCore/ADFS, the main disc-based 
filesystem of RISC OS, one of the exceptions.

> And I assume 
> some filesystems are not mounted, like the ext2 partitions or so.
> >> Nice.  Can you please split up the patch somehow?
> >
> > I'll remove the module loader fixes I have already submitted.
> > I'll separate out the changes to the existing files, and the Linux
> > loader.
> Ok, that sounds nice.  You could even do the same for the filesystem
> and disk stuff, for example.  As far as I am concerned it does not
> have to work after the first commit, as long as it doesn't break
> anything.  I wonder how the other developers think about that.

Here is the split I propose:

0. Dynamic loader fixes.
1. Portability fixes and changes.
2. Console and core features, so that rescue mode works.
3. Disc support.
4. Filesystem API support.
5. Physical memory abstraction layer and RISC OS shutdown.
6. Hardware identification.
7. Linux loader.

> > The majority of can't be easily split up into independent patches. Shall
> > I split them up into a set of patches which have to be applied together?
> That would not make much sense, I think.

In the sense that the RISC OS port wouldn't compile if only some of them were 

> > May I use the standard names for (ROM resident) C library globals?
> Can you give an example of what you mean with that?

The RISC OS shared C library does not export its globals by name, instead the 
functions are accessed by a table of branch instructions in the client's (eg 
GRUB) bss section. Likewise the C library's static data (including errno, 
stdin, stdout, etc) also resides in the client's bss area and is accessed by 
the C library via a pointer in a register.

Normally the C library is used by linking the client with the library stubs 
which provide the binding between the names of globals and their addresses. 
GRUB does not use the stubs because:

1. They are in AOF instead of ELF.
2. None of the free stubs support using an old library with code compiled to 
the new ABI (APCS-32). The old ABI (APCS-26) does not work on new processors.
3. It would be an unreasonable build time dependncy.

Instead part of functionality of the stubs is included in 
kern/arm/RISC_OS/startup.S, as such we are free to choose which names we use 
for them. For clairity I suggest we use the standard names, as opposed to 
prefixing the names with grub_RISC_OS_ or simular.

GRUB uses the following functions from the C library at the moment:

> > May the official RISC OS system call names in
> > include/grub/arm/RISC_OS/swis.h stay? The file is only included in
> > assembler, and to change the names would be confusing.
> Is it a copyrighted file which was not written by you?

No, I wrote the file myself copying the names and numbers from the 

Member AFFS, WYLUG, SWP (UK), ANL, RESPECT, Leeds SA, Leeds Anti-war coalition
No to software patents!    Victory to the iraqi resistance!

Attachment: pgpv4QRx9J3JV.pgp
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]