Re: [RFC] Multi-terminal support (Re: [PATCH] terminal split)
Robert Millan wrote: On Tue, Nov 25, 2008 at 10:23:52PM +0100, Yoshinori K. Okuji wrote: I've been thinking... what if we make this generic? I.e. with an event loop, then terminals can register their poll functions to it, and write their stuff to a shared resource the rest of GRUB can read from. For inputs, this is trivial for me. But, for outputs, not simple. For example, although we don't support yet in GRUB 2, if we have a dumb terminal, the menu interface must be very different from others. Aside from the problem with output ones, what to you think of the event loop idea? It can be useful exploit the parellelism in hardware initialisations. Currently GRUB can do silly things like: - wait for keyboard controller in grub_keyboard_controller_read() and in grub_keyboard_controller_write() - move on - wait for ATA disk in grub_atapi_read() - move on - wait for _user_ to stare at the menu and pick an option - move on which could be avoided this way (instead of waiting, each function would register a hook that will be repeatedly run untill it returns non-zero). Well... I think better road would be co-operative multitasking. While waiting for hardware to respond you could give time to other tasks to handle their stuff. This would also make easier to write such tasks as you do not have to think about complex event system. System you propose can get quite complex to understand and maintain. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] Multi-terminal support (Re: [PATCH] terminal split)
On Tue, Nov 25, 2008 at 10:23:52PM +0100, Yoshinori K. Okuji wrote: I've been thinking... what if we make this generic? I.e. with an event loop, then terminals can register their poll functions to it, and write their stuff to a shared resource the rest of GRUB can read from. For inputs, this is trivial for me. But, for outputs, not simple. For example, although we don't support yet in GRUB 2, if we have a dumb terminal, the menu interface must be very different from others. Aside from the problem with output ones, what to you think of the event loop idea? It can be useful exploit the parellelism in hardware initialisations. Currently GRUB can do silly things like: - wait for keyboard controller in grub_keyboard_controller_read() and in grub_keyboard_controller_write() - move on - wait for ATA disk in grub_atapi_read() - move on - wait for _user_ to stare at the menu and pick an option - move on which could be avoided this way (instead of waiting, each function would register a hook that will be repeatedly run untill it returns non-zero). -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: SPAM-LOW: Re: [RFC] Multi-terminal support (Re: [PATCH] terminal split)
* Yoshinori K. Okuji wrote, On 25/11/08 21:23: On Saturday 22 November 2008 20:54:57 Robert Millan wrote: On Sat, Nov 22, 2008 at 06:42:54PM +0100, Yoshinori K. Okuji wrote: However, whenever you want to do more than that, you must control each terminal differently. In particular, the menu code. The menu interface may not be uniform with all terminals. A terminal might have the size 80x25. Another might have 120x40. This is more complex with graphical terminals. This problem does only happen with output terminals, right? My primary concern are input terminals, because if we want to support USB keyboards we need to probe from both USB and AT ones at the same time. Yes. I like the idea that GRUB displays the user interface simultaneously. But this requires a lot of refactoring. Probably, the menu code will have to iterate all terminals explicitly, and make actions differently for each terminal, based on the capabilities. With the menu editor, how should the cursor be managed? We need to think a lot. I've been thinking... what if we make this generic? I.e. with an event loop, then terminals can register their poll functions to it, and write their stuff to a shared resource the rest of GRUB can read from. For inputs, this is trivial for me. But, for outputs, not simple. For example, although we don't support yet in GRUB 2, if we have a dumb terminal, the menu interface must be very different from others. I just noticed this converation. I use 2x16 character 4 button serial terminals, and on some of them you have to poll for keypresses! (And ideally convert a bitmap into keycodes, and debounce). Sam ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] Multi-terminal support (Re: [PATCH] terminal split)
On Saturday 22 November 2008 20:54:57 Robert Millan wrote: On Sat, Nov 22, 2008 at 06:42:54PM +0100, Yoshinori K. Okuji wrote: However, whenever you want to do more than that, you must control each terminal differently. In particular, the menu code. The menu interface may not be uniform with all terminals. A terminal might have the size 80x25. Another might have 120x40. This is more complex with graphical terminals. This problem does only happen with output terminals, right? My primary concern are input terminals, because if we want to support USB keyboards we need to probe from both USB and AT ones at the same time. Yes. I like the idea that GRUB displays the user interface simultaneously. But this requires a lot of refactoring. Probably, the menu code will have to iterate all terminals explicitly, and make actions differently for each terminal, based on the capabilities. With the menu editor, how should the cursor be managed? We need to think a lot. I've been thinking... what if we make this generic? I.e. with an event loop, then terminals can register their poll functions to it, and write their stuff to a shared resource the rest of GRUB can read from. For inputs, this is trivial for me. But, for outputs, not simple. For example, although we don't support yet in GRUB 2, if we have a dumb terminal, the menu interface must be very different from others. Regards, Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] Multi-terminal support (Re: [PATCH] terminal split)
On Sat, Nov 22, 2008 at 06:42:54PM +0100, Yoshinori K. Okuji wrote: However, whenever you want to do more than that, you must control each terminal differently. In particular, the menu code. The menu interface may not be uniform with all terminals. A terminal might have the size 80x25. Another might have 120x40. This is more complex with graphical terminals. This problem does only happen with output terminals, right? My primary concern are input terminals, because if we want to support USB keyboards we need to probe from both USB and AT ones at the same time. I like the idea that GRUB displays the user interface simultaneously. But this requires a lot of refactoring. Probably, the menu code will have to iterate all terminals explicitly, and make actions differently for each terminal, based on the capabilities. With the menu editor, how should the cursor be managed? We need to think a lot. I've been thinking... what if we make this generic? I.e. with an event loop, then terminals can register their poll functions to it, and write their stuff to a shared resource the rest of GRUB can read from. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
