[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RISC OS port
Re: RISC OS port
Sat, 27 Nov 2004 01:36:16 +0000
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 configure.ac 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!
Description: PGP signature