From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1NQguq-0006EN-5Q for mharc-grub-devel@gnu.org; Fri, 01 Jan 2010 07:47:40 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NQguo-0006DW-0x for grub-devel@gnu.org; Fri, 01 Jan 2010 07:47:38 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NQguj-0006C5-HQ for grub-devel@gnu.org; Fri, 01 Jan 2010 07:47:37 -0500 Received: from [199.232.76.173] (port=53288 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NQguj-0006C2-AG for grub-devel@gnu.org; Fri, 01 Jan 2010 07:47:33 -0500 Received: from xvm-190-8.ghst.net ([217.70.190.8]:56993 helo=aybabtu.com) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NQgui-00015V-Ro for grub-devel@gnu.org; Fri, 01 Jan 2010 07:47:33 -0500 Received: from [192.168.10.10] (helo=thorin) by aybabtu.com with esmtp (Exim 4.69) (envelope-from ) id 1NQgug-00064i-NB for grub-devel@gnu.org; Fri, 01 Jan 2010 13:47:30 +0100 Received: from rmh by thorin with local (Exim 4.69) (envelope-from ) id 1NQgug-0003un-6v for grub-devel@gnu.org; Fri, 01 Jan 2010 13:47:30 +0100 Date: Fri, 1 Jan 2010 13:47:30 +0100 From: Robert Millan To: The development of GNU GRUB Message-ID: <20100101124730.GR3692@thorin> References: <4B3C98EE.8020003@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4B3C98EE.8020003@gmail.com> Organization: free as in freedom X-Message-Flag: Worried about Outlook viruses? Switch to Thunderbird! www.mozilla.com/thunderbird X-Debbugs-No-Ack: true User-Agent: Mutt/1.5.18 (2008-05-17) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Subject: Re: [PATCH] Proof of concept interrupt wrapping X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jan 2010 12:47:38 -0000 On Thu, Dec 31, 2009 at 01:28:30PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote: > Hello. We were discussing with Robert how to move BIOS interrupt > routines out of kernel. There are following possibilities: > 1) Have a .lowmem section in every concerned module which will always be > placed in low memory. Currently in experimental. > Advantages: > a) moving functions to modules is straightforward > b) functions grow neither in size nor in complexity > Disadvantages: > c) needs lowmem allocators in core > 2) Make every function needing bios interrupts setup its own trampoline. > Due to complexity of trampolines it's not a real option > 3) Have an universal routine grub_interrupt (int intno, struct > grub_cpu_interrupt_regs *regs) which will be used by C routine to do the > interrupt calls. This would move the complexity from asm to C. > Advantages: > a) simplicity in core > b) complexity moved to a more readable language > c) we can also rename grub_interrupt to grub_interrupt_real and make > grub_interrupt dprintf registers before and after the call. This would > make debugging BIOS quirks easier. > Disadvantages: > a) Moving functions needs effort > b) C functions are probably bigger but it may be offset by possibility > of inlining functions > c) repeadetly changing from/to real mode is an overhead when executing > multiple interrupts in series. Fortunately this condition is rare in our > codebase and is only on non performance-critical parts like halting. > d) Some functions aren't covered by this. At least grub_pxe_call is in > this case. But we can use method 2 for them We could diminish #1.c with ifdef GRUB_MACHINE_PCBIOS, but it's still ugly. I like #3 a lot more. As for C being bigger than asm, it's argueable, taking into account that we have regparm, function alignment hacks, and gcc size optimizations :-) In any case #3 looks a lot cleaner. Some comments about the patch: > +struct grub_cpu_int_registers > +{ > + grub_uint16_t bx; > + grub_uint16_t es; > + grub_uint16_t cx; > + grub_uint16_t ax; > + grub_uint16_t dx; > + grub_uint16_t ds; > + grub_uint16_t di; > + grub_uint16_t flags; > + grub_uint16_t si; > +}; This structure is named in generic way, but its member names are CPU-specific. Is it useful to make this generic? In practice, it will be impossible for CPU-independant code to use it. Besides, it's biased towards BIOS as the only i386 way. If, say, some new i386 firmware provides an interrupt-based callback interface that we're compelled to support (and YES I really hope this won't happen...), it wouldn't use i8086 mode at all. I think it would be better to admit that this is a pure ad-hoc kludge. It's not beautiful, but it's *much* better than what we have now. -- Robert Millan "Be the change you want to see in the world" -- Gandhi