use at_keyboard.c on i386-ieee1275
PATCH 1/1 use at_keyboard.c on i386-ieee1275
Taking into account that ofconsole on i386:
- Has bugs with similar usability effect than at_keyboard.c (e.g. arrow keys not working).
- In practice doesn't provide support for any keyboard other than AT (since OFW shuts down USB before transfering control to us).
- Sharing code with other ports (CoreBoot, attow) is more efficient to get these bugs solved.
I propose to use at_keyboard.c as default for i386-ieee1275.
Signature · 5 lines
Robert Millan <GPLv2> I know my rights; I want my phone call! <DRM> What use is a phone call… if you are unable to speak? (as seen on /.)
conf/i386-ieee1275.rmk renamed from grub2/conf/i386-ieee1275.rmk +2 -1
@@ -17,7 +17,8 @@ kernel_elf_SOURCES = kern/i386/ieee1275/ kern/i386/dl.c kern/parser.c kern/partition.c \ kern/env.c \ kern/ieee1275/ieee1275.c \ - term/ieee1275/ofconsole.c disk/ieee1275/ofdisk.c \ + term/ieee1275/ofconsole.c term/i386/pc/at_keyboard.c \ + disk/ieee1275/ofdisk.c \ symlist.c kernel_elf_HEADERS = arg.h cache.h device.h disk.h dl.h elf.h elfload.h \ env.h err.h file.h fs.h kernel.h loader.h misc.h mm.h net.h parser.h \
include/grub/i386/ieee1275/console.h renamed from grub2/include/grub/i386/ieee1275/console.h +28 -1
@@ -1 +1,28 @@ -#include <grub/powerpc/ieee1275/console.h> +/* +* GRUB -- GRand Unified Bootloader +* Copyright (C) 2008 Free Software Foundation, Inc. +* +* GRUB is free software: you can redistribute it and/or modify +* it under the terms of the GNU General Public License as published by +* the Free Software Foundation, either version 3 of the License, or +* (at your option) any later version. +* +* GRUB is distributed in the hope that it will be useful, +* but WITHOUT ANY WARRANTY; without even the implied warranty of +* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +* GNU General Public License for more details. +* +* You should have received a copy of the GNU General Public License +* along with GRUB. If not, see <http://www.gnu.org/licenses/>. +*/ + +#ifndef GRUB_CONSOLE_MACHINE_HEADER +#define GRUB_CONSOLE_MACHINE_HEADER 1 + +#include <grub/symbol.h> + +void EXPORT_FUNC (grub_keyboard_controller_init ) (void ); +int EXPORT_FUNC (grub_console_checkkey ) (void ); +int EXPORT_FUNC (grub_console_getkey ) (void ); + +#endif /* ! GRUB_CONSOLE_MACHINE_HEADER */
kern/powerpc/ieee1275/init.c renamed from grub2/kern/powerpc/ieee1275/init.c +3 -0
@@ -181,6 +181,9 @@ grub_machine_init (void)int actual;grub_console_init (); +#ifdef __i386__ +grub_keyboard_controller_init (); +#endif grub_claim_heap ();grub_ofdisk_init ();
term/ieee1275/ofconsole.c renamed from grub2/term/ieee1275/ofconsole.c +5 -0
@@ -358,8 +358,13 @@ static struct grub_term grub_ofconsole_t .fini = grub_ofconsole_fini, .putchar = grub_ofconsole_putchar, .getcharwidth = grub_ofconsole_getcharwidth, +#ifdef __i386__ + .checkkey = grub_console_checkkey, + .getkey = grub_console_getkey, +#else .checkkey = grub_ofconsole_checkkey, .getkey = grub_ofconsole_getkey, +#endif .getxy = grub_ofconsole_getxy, .getwh = grub_ofconsole_getwh, .gotoxy = grub_ofconsole_gotoxy,
Quoted 10 lines · Robert Millan
Taking into account that ofconsole on i386:
- Has bugs with similar usability effect than
at_keyboard.c(e.g. arrow keys not working).
- In practice doesn't provide support for any keyboard other than AT (since OFW shuts down USB before transfering control to us).
- Sharing code with other ports (CoreBoot, attow) is more efficient to get these bugs solved.I propose to use
at_keyboard.cas default for i386-ieee1275.
Fine for me, it is your baby :-) Although you forgot the changelog entry.
Will you fix the ifdef's soon?
Doesn't this cause any problems? Now there are two keyboard drivers active.
--
Marco
Quoted 11 lines · Marco Gerards
Quoted 9 lines · Robert Millan
Taking into account that ofconsole on i386:
- Has bugs with similar usability effect than
at_keyboard.c(e.g. arrow keys not working).
- In practice doesn't provide support for any keyboard other than AT (since OFW shuts down USB before transfering control to us).
- Sharing code with other ports (CoreBoot, attow) is more efficient to get these bugs solved.
Quoted 3 lines
Quoted 1 line
I propose to use
at_keyboard.cas default for i386-ieee1275.Fine for me, it is your baby :-) Although you forgot the changelog entry.
* conf/i386-ieee1275.rmk (kernel_elf_SOURCES): Add `term/i386/pc/at_keyboard.c'.
* include/grub/i386/ieee1275/console.h: Add <grub/symbol.h>'. Remove <grub/powerpc/ieee1275/console.h>'. (grub_keyboard_controller_init): New function prototype. (grub_console_checkkey): Likewise.
(grub_console_getkey): Likewise.
* kern/powerpc/ieee1275/init.c (grub_machine_init): Initialize AT keyboard on i386.
* term/ieee1275/ofconsole.c (grub_ofconsole_term): On i386, use grub_ofconsole_checkkey() and grub_ofconsole_getkey() for input.
Quoted 1 line
Will you fix the ifdef's soon?
My plan is to propose a split of terminal handling in kernel so that input and output terminals become different objects. This would fix this hack and others (such as intermangled at_keyboard.c/vga_text.c with console.c in CB port, or gfxterm depending on grub_console_{get,check}key() ).
But I'd like to leave this for later. As mentioned on IRC, Debian is planning to start stabilizing next release in March. If GRUB 2 is mostly in shape at that time, we'll be able to use it as the default bootloader.
Which reminds me, is 1.96 coming soon? When lvm/raid, reiserfs and powerpc issues are fixed, it might be a good time. What do you think?
Quoted 2 lines
Doesn't this cause any problems? Now there are two keyboard drivers active.
Not at all. I didn't bother #ifdefing grub_ofconsole_{get,check}key out to avoid cluttering it (since space is not critical), but it works fine here.
The only drawback is that it doesn't automaticaly switch to serial tty when OFW is running there, but that's a problem for every other port anyway (I have a solution in mind as well; when we redesign terminal handling, we could layout a scheme in which multiple input or output terminals can be active at the same time).
Signature · 5 lines
Robert Millan <GPLv2> I know my rights; I want my phone call! <DRM> What use is a phone call… if you are unable to speak? (as seen on /.)
Quoted 25 lines · Robert Millan
Quoted 11 lines · Marco Gerards
Quoted 9 lines · Robert Millan
Taking into account that ofconsole on i386:
- Has bugs with similar usability effect than
at_keyboard.c(e.g. arrow keys not working).
- In practice doesn't provide support for any keyboard other than AT (since OFW shuts down USB before transfering control to us).
- Sharing code with other ports (CoreBoot, attow) is more efficient to get these bugs solved.Quoted 3 lines
Quoted 1 line
I propose to use
at_keyboard.cas default for i386-ieee1275.Fine for me, it is your baby :-) Although you forgot the changelog entry.
* conf/i386-ieee1275.rmk (
kernel_elf_SOURCES): Add `term/i386/pc/at_keyboard.c'.*
include/grub/i386/ieee1275/console.h: Add<grub/symbol.h>'. Remove<grub/powerpc/ieee1275/console.h>'. (grub_keyboard_controller_init): New function prototype. (grub_console_checkkey): Likewise.
(grub_console_getkey): Likewise.
Quoted 5 lines
*
kern/powerpc/ieee1275/init.c(grub_machine_init): Initialize AT keyboard on i386.*
term/ieee1275/ofconsole.c(grub_ofconsole_term): On i386, usegrub_ofconsole_checkkey()andgrub_ofconsole_getkey()for input.
Looks fine to me.
Quoted 6 lines
Quoted 1 line
Will you fix the ifdef's soon?
My plan is to propose a split of terminal handling in kernel so that input and output terminals become different objects. This would fix this hack and others (such as intermangled
at_keyboard.c/vga_text.cwithconsole.cin CB port, or gfxterm depending on grub_console_{get,check}key() ).
Great!
Quoted 3 lines
But I'd like to leave this for later. As mentioned on IRC, Debian is planning to start stabilizing next release in March. If GRUB 2 is mostly in shape at that time, we'll be able to use it as the default bootloader.
That's a good idea.
Quoted 2 lines
Which reminds me, is 1.96 coming soon? When lvm/raid, reiserfs and powerpc issues are fixed, it might be a good time. What do you think?
Fine for me, we didn't have a release for quite a while. To be honest, I just hate the upload procedure of ftp://alpha.gnu.org. The documents can be interpreted in two ways, or my English simply sucks. That's one reason for me not to release that quickly. ;-)
Quoted 5 lines
Quoted 2 lines
Doesn't this cause any problems? Now there are two keyboard drivers active.
Not at all. I didn't bother #ifdefing grub_ofconsole_{get,check}key out to avoid cluttering it (since space is not critical), but it works fine here.
Ok!
Quoted 5 lines
The only drawback is that it doesn't automaticaly switch to serial tty when OFW is running there, but that's a problem for every other port anyway (I have a solution in mind as well; when we redesign terminal handling, we could layout a scheme in which multiple input or output terminals can be active at the same time).
Yes, that would be nice! :-)
--
Marco
Quoted 9 lines · Marco Gerards
Quoted 9 lines
* conf/i386-ieee1275.rmk (
kernel_elf_SOURCES): Add `term/i386/pc/at_keyboard.c'.*
include/grub/i386/ieee1275/console.h: Add<grub/symbol.h>'. Remove<grub/powerpc/ieee1275/console.h>'. (grub_keyboard_controller_init): New function prototype. (grub_console_checkkey): Likewise.
(grub_console_getkey): Likewise.
Quoted 7 lines
Quoted 5 lines
*
kern/powerpc/ieee1275/init.c(grub_machine_init): Initialize AT keyboard on i386.*
term/ieee1275/ofconsole.c(grub_ofconsole_term): On i386, usegrub_ofconsole_checkkey()andgrub_ofconsole_getkey()for input.Looks fine to me.
Done. I also enabled serial.mod.
Signature · 5 lines
Robert Millan <GPLv2> I know my rights; I want my phone call! <DRM> What use is a phone call… if you are unable to speak? (as seen on /.)
Quoted 7 lines · Marco Gerards
Quoted 2 lines
Which reminds me, is 1.96 coming soon? When lvm/raid, reiserfs and powerpc issues are fixed, it might be a good time. What do you think?
Fine for me, we didn't have a release for quite a while. To be honest, I just hate the upload procedure of ftp://alpha.gnu.org. The documents can be interpreted in two ways, or my English simply sucks. That's one reason for me not to release that quickly. ;-)
Just leave the task to me. I have been the release manager for long, thus I know how to do it right.
All I need is ping from Robert. My preference is to publish a new version regularly, no matter whatever bugs remain (yeah, I am very aggressive in GRUB 2), but he stopped me releasing 1.96 previosly, IIRC.
Okuji
Quoted 11 lines · Yoshinori K. Okuji
Quoted 7 lines · Marco Gerards
Quoted 2 lines
Which reminds me, is 1.96 coming soon? When lvm/raid, reiserfs and powerpc issues are fixed, it might be a good time. What do you think?
Fine for me, we didn't have a release for quite a while. To be honest, I just hate the upload procedure of ftp://alpha.gnu.org. The documents can be interpreted in two ways, or my English simply sucks. That's one reason for me not to release that quickly. ;-)
Just leave the task to me. I have been the release manager for long, thus I know how to do it right.
:-)
As you noticed, I have no problem with this at all, just leave me to the C code :P
Quoted 3 lines
All I need is ping from Robert. My preference is to publish a new version regularly, no matter whatever bugs remain (yeah, I am very aggressive in GRUB 2), but he stopped me releasing 1.96 previosly, IIRC.
Ok :-)
--
Marco
Quoted 4 lines · Yoshinori K. Okuji
All I need is ping from Robert. My preference is to publish a new version regularly, no matter whatever bugs remain (yeah, I am very aggressive in GRUB 2), but he stopped me releasing 1.96 previosly, IIRC.
I didn't mean to stop you. I just pointed out that there are regressions, and that I don't think it's a good idea to release with (significant) regressions. But if you disagree, it's not a big concern to me. :-)
Anyway, the regressions are still there. Although we're closer to fixing them:
- I fixed one of the known problems with LVM/RAID, but others (2, I think) remain.
- Apple hardware still won't boot, but Pavel has put quite an effort in tracing this and IIRC he's very close to a fix.
Besides, I'm afraid I tell everyone to use CVS rather than 1.95, since 1.95 has much worse problems that affect a wider audience; the ones I fixed in my first commit (ignore 1st, 2nd breaks all udev users, 3rd breaks all users without floppy drive):
2006-09-14 Robert Millan <[email protected]>
* util/i386/pc/grub-install.in: Skip menu.lst when removing /boot/grub/*.lst.
* util/i386/pc/getroot.c: Don't recurse into dotdirs (e.g. ".static").
* util/i386/pc/grub-mkdevicemap.c: Make sure the floppy device exists before adding it to device.map.
So perhaps it's a good idea to release 1.96 with known regressions after all.
Signature · 5 lines
Robert Millan <GPLv2> I know my rights; I want my phone call! <DRM> What use is a phone call… if you are unable to speak? (as seen on /.)
Quoted 28 lines · Robert Millan
Quoted 4 lines · Yoshinori K. Okuji
All I need is ping from Robert. My preference is to publish a new version regularly, no matter whatever bugs remain (yeah, I am very aggressive in GRUB 2), but he stopped me releasing 1.96 previosly, IIRC.
I didn't mean to stop you. I just pointed out that there are regressions, and that I don't think it's a good idea to release with (significant) regressions. But if you disagree, it's not a big concern to me. :-)
Anyway, the regressions are still there. Although we're closer to fixing them:
- I fixed one of the known problems with LVM/RAID, but others (2, I think) remain.
- Apple hardware still won't boot, but Pavel has put quite an effort in tracing this and IIRC he's very close to a fix.
Besides, I'm afraid I tell everyone to use CVS rather than 1.95, since 1.95 has much worse problems that affect a wider audience; the ones I fixed in my first commit (ignore 1st, 2nd breaks all udev users, 3rd breaks all users without floppy drive):
2006-09-14 Robert Millan <[email protected]>
* util/i386/pc/grub-install.in: Skip menu.lst when removing
/boot/grub/*.lst.
Quoted 6 lines
*
util/i386/pc/getroot.c: Don't recurse into dotdirs (e.g. ".static").*
util/i386/pc/grub-mkdevicemap.c: Make sure the floppy device exists before adding it to device.map.So perhaps it's a good idea to release 1.96 with known regressions after all.
Personally, I am in favor of releasing often.
--
Marco
Quoted 2 lines · Robert Millan
So perhaps it's a good idea to release 1.96 with known regressions after all.
I think that would be a nicer approach at this stage. Anyway, nobody expects that GRUB 2 is rock-solid (am I wrong?), so it would be more convenient for the development to have a release frequently.
Okuji
Quoted 6 lines · Yoshinori K. Okuji
Quoted 2 lines · Robert Millan
So perhaps it's a good idea to release 1.96 with known regressions after all.
I think that would be a nicer approach at this stage. Anyway, nobody expects that GRUB 2 is rock-solid (am I wrong?),
Not yet. But in Debian, we plan to start stabilizing on March (we expect to make GRUB 2 the default in unstable by then).
Signature · 5 lines
Robert Millan <GPLv2> I know my rights; I want my phone call! <DRM> What use is a phone call… if you are unable to speak? (as seen on /.)
Quoted 7 lines · Yoshinori K. Okuji
Quoted 2 lines · Robert Millan
So perhaps it's a good idea to release 1.96 with known regressions after all.
I think that would be a nicer approach at this stage. Anyway, nobody expects that GRUB 2 is rock-solid (am I wrong?), so it would be more convenient for the development to have a release frequently.
Agreed. Often, people just use a release instead of CVS and report bugs. It would be better for us if newer versions were tested. Perhaps nightly snapshots would be nice, if there was an easy way to set this up...
--
Marco
Quoted 5 lines · Marco Gerards
Quoted 4 lines · Yoshinori K. Okuji
Quoted 2 lines · Robert Millan
So perhaps it's a good idea to release 1.96 with known regressions after all.
Quoted 8 lines
Quoted 3 lines
I think that would be a nicer approach at this stage. Anyway, nobody expects that GRUB 2 is rock-solid (am I wrong?), so it would be more convenient for the development to have a release frequently.
Agreed. Often, people just use a release instead of CVS and report bugs. It would be better for us if newer versions were tested. Perhaps nightly snapshots would be nice, if there was an easy way to set this up...
I have heard that savannah hackers can set up a nightly snapshot, so I can ask them, if you really want.
So, for the next release, I will make it in next weekend (on the 2nd or the 3rd), if nobody objects. Meanwhile, if you know user-visible changes which are not written in NEWS yet, please fill them up in that file.
Okuji
next release & NEWS file (Re: [PATCH] use at_keyboard.c on i386-ieee1275)
Quoted 4 lines · Yoshinori K. Okuji
So, for the next release, I will make it in next weekend (on the 2nd or the 3rd), if nobody objects. Meanwhile, if you know user-visible changes which are not written in NEWS yet, please fill them up in that file.
I came up with a few things. Before I add them, please can you review the list to make sure all the items are important enough to be mentioned?
Signature · 5 lines
Robert Millan <GPLv2> I know my rights; I want my phone call! <DRM> What use is a phone call… if you are unable to speak? (as seen on /.)
NEWS +22 -1
@@ -9,10 +9,31 @@ * grub-emu can access the host filesystem now. -* Add support for the NTFS and Reiserfs filesystems. +* Add support for the NTFS, cpio/tar and Reiserfs filesystems. * Add support for ATA/ATAPI. +* Add update-grub script to generate grub.cfg. + +* Add grub-mkrescue script to generate floppy or ElTorito images + (i386-pc only). + +* Add support for background images in gfxterm (background_image command). + +* Add support for detection of 64-bit support in CPU (cpuid command). + +* GPT is now enabled in i386-pc target. + +* Add grub-install for EFI. + +* Ported to the following new platforms: Efika, Open Hack'Ware + (qemu-system-ppc), coreboot a.k.a. LinuxBIOS, OLPC XO. + +* Add support for colored menu (menu_color_normal and menu_color_highlight + variables). + +* Fix support for loading Linux zImages (such as memtest86). + New in 1.95 - 2006-10-15: * Number partitions from 1 instead of 0. For instance, the first
Re: next release & NEWS file (Re: [PATCH] use at_keyboard.c on i386-ieee1275)
Quoted 8 lines · Robert Millan
Quoted 4 lines · Yoshinori K. Okuji
So, for the next release, I will make it in next weekend (on the 2nd or the 3rd), if nobody objects. Meanwhile, if you know user-visible changes which are not written in NEWS yet, please fill them up in that file.
I came up with a few things. Before I add them, please can you review the list to make sure all the items are important enough to be mentioned?
Either the fallback for missing /memory/available is applied, or it would be better not to mention qemu-system-ppc. That's not to put any pressure - I'm fine either way.
And by the way, Open Hack'Ware has a dumb terminal with no ANSI sequences. It's not as bad as hanging on startup or printing "our of memory" for every command, but it makes it hard to see what's being typed on the command line.
Signature · 2 lines
Regards, Pavel Roskin
Re: next release & NEWS file (Re: [PATCH] use at_keyboard.c on i386-ieee1275)
Quoted 10 lines · Pavel Roskin
Quoted 8 lines · Robert Millan
Quoted 4 lines · Yoshinori K. Okuji
So, for the next release, I will make it in next weekend (on the 2nd or the 3rd), if nobody objects. Meanwhile, if you know user-visible changes which are not written in NEWS yet, please fill them up in that file.
I came up with a few things. Before I add them, please can you review the list to make sure all the items are important enough to be mentioned?
Quoted 8 lines
Either the fallback for missing /memory/available is applied, or it would be better not to mention qemu-system-ppc. That's not to put any pressure - I'm fine either way.
And by the way, Open Hack'Ware has a dumb terminal with no ANSI sequences. It's not as bad as hanging on startup or printing "our of memory" for every command, but it makes it hard to see what's being typed on the command line.
Ok, committed (except for the Open Hackware port).
Signature · 5 lines
Robert Millan <GPLv2> I know my rights; I want my phone call! <DRM> What use is a phone call… if you are unable to speak? (as seen on /.)
Quoted 10 lines · Yoshinori K. Okuji
Quoted 9 lines · Marco Gerards
Quoted 7 lines · Yoshinori K. Okuji
Quoted 2 lines · Robert Millan
So perhaps it's a good idea to release 1.96 with known regressions after all.
I think that would be a nicer approach at this stage. Anyway, nobody expects that GRUB 2 is rock-solid (am I wrong?), so it would be more convenient for the development to have a release frequently.
Quoted 7 lines
Quoted 4 lines
Agreed. Often, people just use a release instead of CVS and report bugs. It would be better for us if newer versions were tested. Perhaps nightly snapshots would be nice, if there was an easy way to set this up...
I have heard that savannah hackers can set up a nightly snapshot, so I can ask them, if you really want.
Please do! :-)
Quoted 3 lines
So, for the next release, I will make it in next weekend (on the 2nd or the 3rd), if nobody objects. Meanwhile, if you know user-visible changes which are not written in NEWS yet, please fill them up in that file.
I will go over the ChangeLog to see if more has to be added.
--
Marco