From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KTTca-0005fi-E7 for mharc-grub-devel@gnu.org; Wed, 13 Aug 2008 23:35:32 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KTTcY-0005f5-FU for grub-devel@gnu.org; Wed, 13 Aug 2008 23:35:30 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KTTcW-0005eR-R4 for grub-devel@gnu.org; Wed, 13 Aug 2008 23:35:30 -0400 Received: from [199.232.76.173] (port=44540 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KTTcW-0005eM-Lm for grub-devel@gnu.org; Wed, 13 Aug 2008 23:35:28 -0400 Received: from nf-out-0910.google.com ([64.233.182.190]:26882) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KTTcW-0007jq-8Z for grub-devel@gnu.org; Wed, 13 Aug 2008 23:35:28 -0400 Received: by nf-out-0910.google.com with SMTP id c7so204728nfi.26 for ; Wed, 13 Aug 2008 20:35:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:content-type :date:message-id:mime-version:x-mailer; bh=RP8khJA/0EiWw0pdG0dgkMvD9X4kLUnYzBkSJspE64M=; b=ZEtH8gL0p1BdOE5O56es4ATvG+zelGJedpEle8UKffKTuc4eaSQErYdVHFfLxr7XHU gEuDzghHSBx4WOWwSdoS8kxY8iaTnqnO2fNu3JDgTEpTH1BVwIaJtyVCpdnhzKc91o/L XmOa7cNbHC3qJUU/ljAM6SqKPQTYQAedV7vlA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:content-type:date:message-id:mime-version:x-mailer; b=ESIswHNuZzIKQgum23mV7tPcS/jnx2Eydmkq2Uy7VIZprZpeyiukuTMqx8yDFGWqy3 Wpj9oofIEksFZEa6XbxHzeiDwlllBDmRSP+rezsBzMT43QAlxd2PJe/FEtSYZDy2ssvT I2QIrQfLDAJi9esDRl9QGjWv+1UrZjkNQDAYs= Received: by 10.210.65.2 with SMTP id n2mr744102eba.145.1218684926342; Wed, 13 Aug 2008 20:35:26 -0700 (PDT) Received: from ?192.168.1.100? ( [213.37.137.93]) by mx.google.com with ESMTPS id z37sm1471945ikz.6.2008.08.13.20.35.24 (version=SSLv3 cipher=RC4-MD5); Wed, 13 Aug 2008 20:35:25 -0700 (PDT) From: Javier =?ISO-8859-1?Q?Mart=EDn?= To: The development of GRUB 2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-pkDbsSCtTwTVHyzHAtS9" Date: Thu, 14 Aug 2008 05:36:15 +0200 Message-Id: <1218684975.8757.139.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 2) Subject: [RFC] Platform information services 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: Thu, 14 Aug 2008 03:35:30 -0000 --=-pkDbsSCtTwTVHyzHAtS9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi there everybody, I'm opening the RFC because I want to add some kind of infrastructure to retrieve the address of system/platform structures. I will explain myself: my use case is in i386-pc and for the drivemap module, in which a function installs a TSR int13h handler. This requires the function to have access to two real mode structures, namely the BIOS Data Area, which is based at 0040:0000h; and the Interrupt Vector Table, which conventionally starts at 0 but that could have been placed elsewhere by the use of the LIDT instruction. Currently, the code just "hopes for the best" and accesses 0x0 and 0x400 directly as protected mode addresses from within the GRUB environment, which has the additional assumption that GRUB has not enabled any kind of paging or memory mapping. Obviously, the Right Way for this would be for the code to check where its targets are, but even when the location of the IVT can be queried by the non-privileged instruction SIDT, that would require a privileged trip to real mode and back from it in order to query the location of the real mode IVT instead of the pmode IDT that is in effect in the GRUB environment (but this still does not deal with a possible paging). Thus, the best course of action I see would be to add a "platform information" infrastructure in kernel (that last word has probably put me on the death list of several people here =C2=AC=C2=AC). My idea would ad= d a cross-platform header platform.h declaring the following prototype: void* grub_machine_get_platform_structure (int stidx); Then, the machine.h file for each platform would declare which structures are available, like the IVT and the BDA for i386-pc. The code would be used like this: #include #include /* (...) Now from within a function */ grub_uint8_t* bda =3D (grub_uint8_t*)grub_machine_get_platform_structure (GRUB_MACHINE_I386_BDA); if (!bda) /* Error info in errno & errmsg - bail out */ else grub_printf ("Avail mem: %d KiB", *((grub_uint16_t*)(bda + 0x13))); The pointers provided by this new function would be guaranteed to: - Be able to access the whole requested structure (if any segmentation is in effect, the whole struct is addressable from that base address) - Have been mapping-marshaled, i.e. if any kind of paging has been enabled, the address returned can be directly used as a C pointer. - Be read-write? Maybe this could be requested through an additional "flags" parameter to the function... Initially this addition would only benefit i386-pc and in particular my drivemap patch, but maybe it can also be used by modules to query EFI info structures and such... What are your thoughts on the matter? (fanatics with death threats for trying to add something to kernel, please abstain) -Habbit --=-pkDbsSCtTwTVHyzHAtS9 Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iQIVAwUASKOoL6Sl+Fbdeo72AQK6iw//XVqBg844VGIbQWS7prk/jLAifZRtWCzw hzk97XnmxO6SqRmrZalhB3G+DDiN8ptGD/XF3h5Bf2SrV4MuLQrt8uIvv+z2WSXS D7clN4fPSWwmT9t4ju6i4yirW8uMpE31tzzlyHVS4KYtB2E2eXUUTCzGmrQQKxAO 3+2QauXPYihnGY0tnmXZx7hV372wg0PjU3yMYZ0xPiIaLut+JVb1/0peHWxc6mhR M+A2VEcLazg6CSvA06mAP8uZLjXvyIBjGMD951Y7hkO/+nLpm0OHsKokOB+s0Lum 0EXl5B0VJuj5mItbe3X3/RpgU0vUq/MbYZM/Fk3BgrL4ldKcC7HefsVfDtyDYKyE Gc+L84QcF2VNCO+9T0uKtqDarSJsvfrKOwhcH0ghcmbUINyV6QPulJSXkqwuKNQA DknaHgjkqE8RepSCGNUHqsZVVrlBm7yB5zUQA21oaxGvsyaXtrzl+nmwVtzo/fR/ Dzci32fGRoQDDIigjDUj1dGnEJBeOaB5uHujcMqjJc2vXNELStnOpu7kBBf1raty SxYihaiDiHfXcrsxCrynUri+PCk7zp95X6MP++ailxWL+1DWQI85ZxGm59EJDSF8 7uI0YfZmBY0wKAoge7tf2GNFPZ+Mer+Q3CN2kjLL2UQ8uDDZTH0SqCCDY4hRcAOd 0dJYGvs2+oU= =n9WW -----END PGP SIGNATURE----- --=-pkDbsSCtTwTVHyzHAtS9--