From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KTkcK-0005yb-4k for mharc-grub-devel@gnu.org; Thu, 14 Aug 2008 17:44:24 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KTkcG-0005wz-SJ for grub-devel@gnu.org; Thu, 14 Aug 2008 17:44:21 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KTkcC-0005tz-M7 for grub-devel@gnu.org; Thu, 14 Aug 2008 17:44:18 -0400 Received: from [199.232.76.173] (port=38832 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KTkcC-0005to-Gk for grub-devel@gnu.org; Thu, 14 Aug 2008 17:44:16 -0400 Received: from ug-out-1314.google.com ([66.249.92.169]:40134) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KTkcC-0005ax-1c for grub-devel@gnu.org; Thu, 14 Aug 2008 17:44:16 -0400 Received: by ug-out-1314.google.com with SMTP id s2so28958uge.6 for ; Thu, 14 Aug 2008 14:44:14 -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:in-reply-to :references:content-type:date:message-id:mime-version:x-mailer; bh=l8xgVDsoa1SLtTrmfyblrzDnfsU+w9ivV5HdbC4nsHI=; b=n0JiJAfOraifrpGIMBBgrfxe28tHkb0q8BmYHyrLphbKWIxSJTNUoZROvR51MIfG2G iZevBR2+UlrdKO+/diiO0Qd+aNUWMVgcAIDdCjZ9jjIOK/B1zk+uGvzzhgVJO9C4G9Dl bCwdE0YxmUdOBKWNFw4b1Gj/ttHQOtsOsSzyo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:in-reply-to:references:content-type:date:message-id :mime-version:x-mailer; b=opE7gSH5VmBOjnDBWFps5pIaeKHDYVJNe7stzVox5JbAS1eZ/n5FaoYmObCUXWlJpx WduUHfyoZfMQgHpCvASEM8vFOwWFXvWa8qEF6DZRylXjd19k0cdfH1xhK9X0Sk6kAmd1 9bDVVBW+gs7ZPBxvUCkG6BS8VVmMkAxijwq6k= Received: by 10.210.44.1 with SMTP id r1mr2004908ebr.11.1218750254869; Thu, 14 Aug 2008 14:44:14 -0700 (PDT) Received: from ?192.168.1.100? ( [213.37.137.93]) by mx.google.com with ESMTPS id y37sm3141199iky.8.2008.08.14.14.44.05 (version=SSLv3 cipher=RC4-MD5); Thu, 14 Aug 2008 14:44:13 -0700 (PDT) From: Javier =?ISO-8859-1?Q?Mart=EDn?= To: The development of GRUB 2 In-Reply-To: <48A46E57.7080401@nic.fi> References: <1218684975.8757.139.camel@localhost> <48A4589D.3040902@nic.fi> <48A46E57.7080401@nic.fi> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-4hqn43IXEZezWshE6RJT" Date: Thu, 14 Aug 2008 23:45:06 +0200 Message-Id: <1218750306.19647.33.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: Re: [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 21:44:22 -0000 --=-4hqn43IXEZezWshE6RJT Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable El jue, 14-08-2008 a las 20:41 +0300, Vesa J=C3=A4=C3=A4skel=C3=A4inen escr= ibi=C3=B3: > Javier Mart=C3=ADn wrote: > > 2008/8/14 Vesa J=C3=A4=C3=A4skel=C3=A4inen : > >> Javier Mart=C3=ADn wrote: > >>> 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 whi= ch > >>> 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. > >> But it is designed to use linear address space for memory so no need t= o > >> worry about it. I do not see any reason why there would be paging or > >> non-linear memory mapping in GRUB 2 (i386-pcbios). > > Yes, but this is a "kernel" design decision that is specified nowhere > > to the modules writers. Thus, this could change tomorrow and the > > scheme would break down. >=20 > Still I do not that being changed on GRUB 2 (i386-pcbios). And basically > generic module writers do not need to care, and if it is platform > specific module then you can adapt to that platform if needed. Think it > like device driver. Device drivers are just the kind of example that I'm basing upon: the part related to their hardware they manipulate as directly and recklessly as the OS kernel allows them, but WRT other parts of the system they rely on a very defined kernel-driver interface (NDIS, anyone?) that simply is very nebulous in GRUB. You say that paging will never be enabled in GRUB2, and it is very likely that your assertion holds, but what if we suddenly find some kind of benefit to enable it and some other rock to be walked around requires that the first MB of memory not be identity mapped? Kaboom for modules assuming it is: they were assuming things about the implementation of the kernel that do _not_ have to hold as they are nowhere specified >=20 > >> Or did I miss something? > >> > >> So basically I do not see need for such services. As this does not eve= n > >> need to be platform independent. > >> > >> If you need to alter IVT you can modify it on the fly. Though you have > >> to remember where to use only LOW mem addresses in there. > > Not just low mem addresses, I need to compute the real mode far > > pointer (seg:off). Besides, while the BDA always starts at 0040:0000, > > the IVT could have been relocated by either the BIOS or GRUB itself, > > so I need to use SIDT, which is not a privileged instruction itself > > but requires a privileged drop to r-mode to get the IVT address > > instead of the pmode IDT. >=20 > Last time I checked seg:off conversion was (seg << 4) | off giving > access to 1 MiB of memory. I meant that _if_ some kind of mapping was enabled, such conversion would be non-trivial and possibly only known to the kernel. >=20 > BIOS will not relocate this as it is assumed in later stages to be on > that address. And I do not see GRUB doing that as it would need to keep > that table in same place as where BIOS has stored it. All x86-32/64 BIOSes could perfectly relocate the IVT because they feel like it, as the LIDT/SIDT operations were introduced with the 80286. Most current OSes (Linux, Windows from the NT family, etc.) don't care about the IVT just because they have no need of using it ever again, start with a cli and jump into pmode as soon as they can.=20 >=20 > If you still prefer to query it on x86, then there is nothing there to > limit you on doing that. You can always write code to low mem area to > have a real mode call to query any addresses you wish. But I still do > not see any reason why you would write heavy wrapper for that kind of > information especially when those are really platform specific and are > usually not shared between systems. Every platform should use familiar > and convenient method do query that kind of information. As I showed in my reply to Robert's message, the wrapper need not be "heavy": most likely the opposite, as a "stub" implementation for platforms not providing any structures is under 50 bytes, and the "wrapper" for other platforms consists mainly of a switch-case. -Habbit >=20 >=20 >=20 > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel --=-4hqn43IXEZezWshE6RJT 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) iQIVAwUASKSnYaSl+Fbdeo72AQK1YA//cG2P1vKTrRZTxPyN4f4R/3XBWc56knn8 uMyvfOTLB9h08haKx8hiyn38y8W9D2i8JffJPmtIWxKoQvR8QFs/diN+byddctma 3PMrfzqZhh4kxTZI0Jb39ha3G4ctAj83zgOKsKoI/aMPKrTCTicZz84XV6TfVZjW fqcm3JcA4WT/Eao1R/K94EtBZAogdPABrxqyU7tgCQxBhDPv04sZEQPFdMIV1quq KvQzBJswwIiQPjp6SFVJvxvnsl62f7ChHlfuKlyN65es7QRTLtx2/cNQHy/a5ofo E3s6pGJtsxxveVNwPBJRfP+i9KMoGtVgzX5PsO93UvN/wkXjYIkDgyGw6rIStv5I MmKkPbX1Go++hpODOob6MEHy+LZ5XVrFD7Hyht0KEM95CtJ5m0k8Xs3uq/sVBdIc f87S2dhH+c4qK3LM8KkAXYs3tm0tt8hLFpSH0z/oSoGVbozFZVaaeEfS4Lmz/8T4 VEP4SDGLr8EHOLlqNuULAdZvcM2n6Adei3wKhYXfLQom+SNnZrtf9TaVM+RbwQj2 X6ICuvy0RGakrsZNH1ez57ilGMEIHX/pMB5Ag98yyIDWqK4IrV3TYe3uvqdk1RqT 5C5jzTkGG34JS5UXQ2ZdhOT8lqhv+bxOK1uvx2Hzvhq0Q9Rvj0BKUYcxdI5HAJ9H YE9wL9alOUk= =qyki -----END PGP SIGNATURE----- --=-4hqn43IXEZezWshE6RJT--