From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by monty-python.gnu.org with archive (Exim 4.34) id 1BTipk-0007q0-Mi for mharc-grub-devel@gnu.org; Fri, 28 May 2004 10:59:44 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.34) id 1BTipi-0007pY-ET for grub-devel@gnu.org; Fri, 28 May 2004 10:59:42 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.34) id 1BTipC-0007mz-3O for grub-devel@gnu.org; Fri, 28 May 2004 10:59:41 -0400 Received: from [145.74.66.11] (helo=mail-cn.han.nl) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BTiit-00079n-5A for grub-devel@gnu.org; Fri, 28 May 2004 10:52:39 -0400 Received: from localhost (charlie.han.nl [145.74.66.9]) by mail-cn.han.nl (Postfix) with ESMTP id CC7EE879C for ; Fri, 28 May 2004 16:46:24 +0200 (CEST) Received: from mail-cn.han.nl ([145.74.66.11]) by localhost (charlie.han.nl [145.74.66.9]) (amavisd-new, port 10024) with ESMTP id 30972-08 for ; Fri, 28 May 2004 16:46:22 +0200 (CEST) Received: from mail1.han.nl (mail1.han.nl [145.74.103.11]) by mail-cn.han.nl (Postfix) with ESMTP id B8EAE82BE for ; Fri, 28 May 2004 16:46:21 +0200 (CEST) Received: from marco.marco-g.com (a82-92-27-129.adsl.xs4all.nl [82.92.27.129]) by mail1.han.nl (Postfix) with ESMTP id B40B6C045 for ; Fri, 28 May 2004 15:46:20 +0200 (CEST) Mail-Copies-To: metgerards@student.han.nl To: The development of GRUB 2 References: <200405221621.51788.T.E.Baldwin99@members.leeds.ac.uk> <200405231903.10997.okuji@enbug.org> <200405272322.41029.T.E.Baldwin99@members.leeds.ac.uk> From: Marco Gerards Date: Fri, 28 May 2004 16:48:56 +0200 In-Reply-To: <200405272322.41029.T.E.Baldwin99@members.leeds.ac.uk> (Timothy Baldwin's message of "Thu, 27 May 2004 23:22:28 +0100") Message-ID: <87r7t438vb.fsf@marco.marco-g.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new@vscan-cn.han.nl Subject: Re: RISC OS/ARM port X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2004 14:59:43 -0000 Timothy Baldwin 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)/boot/grub/normal.mod > (native_untranslated).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: /pci@80000000/mac-io@10/ata0@20000/disk@0,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