From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KabZN-0005he-F1 for mharc-grub-devel@gnu.org; Tue, 02 Sep 2008 15:29:41 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KabZL-0005gn-Vv for grub-devel@gnu.org; Tue, 02 Sep 2008 15:29:40 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KabZJ-0005eq-9P for grub-devel@gnu.org; Tue, 02 Sep 2008 15:29:39 -0400 Received: from [199.232.76.173] (port=39996 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KabZI-0005en-V1 for grub-devel@gnu.org; Tue, 02 Sep 2008 15:29:37 -0400 Received: from mta-out.inet.fi ([195.156.147.13]:55002 helo=kirsi2.inet.fi) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KabZI-0004gA-Qb for grub-devel@gnu.org; Tue, 02 Sep 2008 15:29:37 -0400 Received: from [127.0.0.1] (88.193.32.97) by kirsi2.inet.fi (8.5.014) id 488DC54E01A480F1 for grub-devel@gnu.org; Tue, 2 Sep 2008 22:29:33 +0300 Message-ID: <48BD941E.6050906@nic.fi> Date: Tue, 02 Sep 2008 22:29:34 +0300 From: =?UTF-8?B?VmVzYSBKw6TDpHNrZWzDpGluZW4=?= User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: The development of GRUB 2 References: <48BD4C52.6040308@gmail.com> <1220367299.23879.15.camel@localhost> <48BD62BE.7090507@gmail.com> <48BD67AD.8040209@nic.fi> <48BD8D7E.8040501@gmail.com> In-Reply-To: <48BD8D7E.8040501@gmail.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 3) Subject: Re: Sendkey patch X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 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: Tue, 02 Sep 2008 19:29:40 -0000 phcoder wrote: > Well the interface is as we described: the module gives a callback > function which will be called before launching boot function. This > interface is enough for both (and probaly many other) needs. The only > problem is that callback functions can conflict with each other and with > boot function. E.g. if callback sets an INT13h hook and then boot > function reads harddrive then it could get wrong data. In my opinion the > ese callback and boot functions shouldn't use device access at all. This > is especially true because theese functions are after grub_machine_fini. That is more like a textual description of the issues not an interface description. It has to be more concrete than that. And mechanism should support hook installation. And I do not see reason why that same thing cannot support also this send key stuff. >> This way it would be also easier to incorporate patches as there is >> already skeleton that can be used easily. >> > There could several templates for using such feature because it's quite > universal I am not really delighted about that... Just one or two connection points and that should be able to handle those cases. If not then we have something wrong somewhere...