Re: RISC OS/ARM port

[Marco Gerards]

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.  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?  If it is not, can you please keep
the syntax like: ($DEVICE)/$PATH?

I assume that ADFS is the filesystem of RISC OS.  Can't you access the
raw disk and write a filesystem for GRUB to access the filesystem?  I
like that better because BIOSes are often limited or buggy and it
becomes easier to use older BIOSes without this fancy support, etc.

Perhaps I am just misunderstanding the issue, I have never used RISC
OS, I don't even know what it is.  But what I want to say is that we
should keep things consistent.

> The member "fs" is moved from "struct grub_net" to "struct grub_device", to 
> allow for filing systems which don't use grub's disk or network support.

Why is this required?  Normally you can just write a filesystem to
access the disk.  But this is just what I said above.

> 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?

> 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);

> 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);

> And finally a fix for a couple of (almost) null pointer derefrences, patch 
> attached.

That's great.  Unfortunately I don't have much time next weeks to do
everything I planned to do.  After that I can work almost full time on
Free Software projects during my summer vacation.

Hopefully someone else can have a look at your patch and check it in
if it is correct, it doesn't seem to be much work.

Thanks,
Marco