Re: RISC OS/ARM port

[Timothy Baldwin]

On Friday 28 May 2004 15:48, Marco Gerards wrote:
> Timothy Baldwin <address@hidden> writes:
> > I intend to add to the RISC OS port I am working on support for the
> > native RISC OS filing system API, with paths such as:
> >
> > (native)ADFS::0/$/boot/grub/normal.mod
> > (native_untranslated)ADFS::0.$.boot.grub.normal/mod
> > (native)<foobar$Dir>/boot/grub/normal.mod
> > (native_untranslated)<foobar$Dir>.boot.grub.normal/mod
>
> Personally I do not like this too much.  That means GRUB works
> different on every architecture.

(native_untranslated) is scrapped.

(native) will pass the path to the RISC OS API after applying the usual UNIX 
to RISC OS path conversion. Other ports to operating systems (eg, old MacOS, 
Windows CE, EPOC32) could use the same syntax.

> For the PPC port I worked hard on 
> keeping sane device name.
>
> On the apple there are aliases that can be used to lookup the
> open firmware device.  Some of these aliases are: hd, cd, zip, ata0
> (IIRC).  I like that much more than the device paths for open firmware
> that are used by yaboot:
> /address@hidden/address@hidden/address@hidden/address@hidden,0
>
> You can not expect a user to type that all the time, it sucks! :)
>
> Of course it should be possible to use the full device path on the
> PPC.
>
> How about RISC OS?  Can't you just do the same?  Is it, for example,
> possible to enumerate the devices?

It is possible to enumerate the devices, but not in a reliably stable fashion, 
further the devices can be any of discs, partitions, files, and the ram disc.

I can and will create aliases (fd0) to (fd3) for floppy drives.

> If it is not, can you please keep 
> the syntax like: ($DEVICE)/$PATH?

Already does for grub filing systems on disks, will add support for native 
filing systems on disks using this syntax.


>
> I assume that ADFS is the filesystem of RISC OS. 

It is the main disc-based filing system, and is alternativley called Filecore, 
but in the context I used it is the name of a device driver. The RISC OS 
documentation and community call block device drivers "filing systems".

> Can't you access the raw disk

I can and do access the raw disk for other filing systems.

> and write a filesystem for GRUB to access the filesystem? 

I can't, because:
1. It is poorly documented, and new versions are often under NDA.
2. The filing system will be mounted read/write, and therefore may be
   automatically defragmented.
3. Grub needs to write to it to install a later version of itself.
4. Write support has not been successfully reimplemented, and it was about a
   decade before native write support was stable with the (tiny) disc cache
   enabled.
5. There are many more filing systems that may be encountered under RISC OS.

> I like that better because BIOSes are often limited or buggy and it
> becomes easier to use older BIOSes without this fancy support, etc.

The filing system API is older (before 1982), and well documented, and has 
been used by 1000's or more released programs, the newer (1st version of RISC 
OS at about 1987, with later revsions) block device API has been used by 
about 10 released programs. Any comparisons with PC BIOSes are irrelevant.

> Perhaps I am just misunderstanding the issue, I have never used RISC
> OS, I don't even know what it is.

It it a ROM-based operating system, with co-operative multitasking and a GUI. 
It runs on ARM processors, and is used on some desktop computers. It used to 
popular in UK schools and homes. It is a extended re-write of operating 
system of the BBC Microcomputer.

> But what I want to say is that we 
> should keep things consistent.

My proposed "(native)" syntax is needed to support paths specified by RISC OS 
system (environment) variables, which is needed when the complete path is not 
known in advance. This would be the case if we put Grub, config file, kernel 
and initrd in a directory and treat it like most RISC OS programs.

It is impossible to map all RISC OS paths to ($DEVICE)/$PATH, because we don't 
know part of the path refers to the device, and we would lose any filing 
system specified.

And finally "(fd0)/foo/bar" would be a confusing path to a file on an NFS 
server, whilst "(native)/ADFS::0/$/foo/bar" would suggest some RISC OS 
behaviour was being used.

[snip]

> > My RISC OS port now has support for discs, modules and both rescue mode
> > and normal mode command prompts work, except some console problems.
>
> This is really nice!
>
> What are the console problems?  Doesn't the console support something
> similar like ANSI or VT100 or such?

No, it's a superset of that used by the (8-bit) BBC Micro. I have not 
implemented support for the arrow keys, the Escape key (which renders the 
console useless unless disabled or acknowledged), or box drawing characters 
(which means re-defining some characters). Also size assumptions as below.

I assume it's the size assumptions stopping the pager from working.

>
> > To deal with variable console sizes I propose creating a new member in
> > "struct grub_term", and removing asumptions:
>
> Absolutely, that assumption should be changed.  And it should be
> possible to resize the terminal.
>
> > grub_uint16_t (*getsize) (void);
>
> Shouldn't that be:
> void (*getxy) (grub_uint16_t *width, grub_uint16_t *height);

That was my original idea.

> > The width of the terminal croodinates should be increased as they are in
> > danger of overflowing, I suggest to 16 bits.
>
> I agree.  The same is true for `getxy', I think this interface would
> be better:
>
> void (*getxy) (grub_uint16_t *x, grub_uint16_t *y);

With that interface, unsigned int would be probably smaller, faster, and 
easier to implement.

Currently libgcc is linked to the kernel, and the routines exported, at the 
moment libgcc is used for 32-bit division and 64-bit shifts. Is that a 
sensible approach? 


-- 
Member AFFS, WYLUG, SWP (UK), ANL, RESPECT, Leeds SA, Leeds Anti-war coalition
No to software patents!    No to DRM/EUCD - hands off our computers!

pgpyKN6ncCRLR.pgp
Description: signature