From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KU4nN-0002fv-Fy for mharc-grub-devel@gnu.org; Fri, 15 Aug 2008 15:17:09 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KU4nM-0002fm-Mu for grub-devel@gnu.org; Fri, 15 Aug 2008 15:17:08 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KU4nL-0002fX-7V for grub-devel@gnu.org; Fri, 15 Aug 2008 15:17:07 -0400 Received: from [199.232.76.173] (port=40363 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KU4nL-0002fU-2q for grub-devel@gnu.org; Fri, 15 Aug 2008 15:17:07 -0400 Received: from nf-out-0910.google.com ([64.233.182.189]:26114) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KU4nK-0005Qz-KI for grub-devel@gnu.org; Fri, 15 Aug 2008 15:17:06 -0400 Received: by nf-out-0910.google.com with SMTP id c7so725168nfi.26 for ; Fri, 15 Aug 2008 12:17:05 -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=mQrzywbrhInz2PdIYbIcv45YNb54u1jvPjRuh+7Ftpw=; b=M7mUmp8V2tM9V/bPymdNWKFdq4V43JcruZZi6XwlX1c8wIvvDP/2hUpSQlcaWIRpNr UYCx3SG+ym+mg5mmRsNzEMapwpmmAUCqf51XAiXO4uT3lcbsjTn3Oes0KVr3725A6qmH tOLg+64yLHD9XCqSxDaLj3yvIIhdgxF/8mWT8= 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=GZtePHcC2Nh2do9Eo2tKky2aFgC/6qSSzik4h28M7xEPtW0bYCbLq6WjPtpOoigACT M8UVJImCTE3jwiTsy3ZoCZFYdM+COCETXuUkt+Lk9Brc/v5SEVuqEeEqpDmVLRkz/m8T 5t/OpCy1D5/WbhBiJT89BNJfL6lpzfekG8718= Received: by 10.210.117.1 with SMTP id p1mr3591170ebc.53.1218827825236; Fri, 15 Aug 2008 12:17:05 -0700 (PDT) Received: from ?192.168.1.100? ( [213.37.137.93]) by mx.google.com with ESMTPS id c22sm393852ika.1.2008.08.15.12.17.02 (version=SSLv3 cipher=RC4-MD5); Fri, 15 Aug 2008 12:17:04 -0700 (PDT) From: Javier =?ISO-8859-1?Q?Mart=EDn?= To: The development of GRUB 2 In-Reply-To: <48A5CC71.3020508@nic.fi> References: <1218684975.8757.139.camel@localhost> <48A4589D.3040902@nic.fi> <20080814180005.GB5614@thorin> <1218749362.19647.20.camel@localhost> <48A5AF50.2040906@nic.fi> <1218819798.2510.13.camel@localhost> <48A5B96D.7040209@nic.fi> <1218823154.2510.23.camel@localhost> <48A5CC71.3020508@nic.fi> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-lAubYo6BomlWnfIwQrKd" Date: Fri, 15 Aug 2008 21:18:14 +0200 Message-Id: <1218827894.2510.51.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: Fri, 15 Aug 2008 19:17:08 -0000 --=-lAubYo6BomlWnfIwQrKd Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable El vie, 15-08-2008 a las 21:35 +0300, Vesa J=C3=A4=C3=A4skel=C3=A4inen escr= ibi=C3=B3: > Javier Mart=C3=ADn wrote: > >> I still do not see the need to create cross platform function that > >> cannot be used for cross platform purposes. It is much more reasonable > >> to write such needs as in kernel for the platform or in platform > >> specific modules. > >> > >> I do not have a problem with function to retrieve pointer to some > >> platform specific function on platfrom specific code. That is normal > >> life of the platform. > > Well, think of this as a platform-specific function to retrieve the > > address of platform-specific (firmware-provided) structures. The only > > difference is that in my proposal such a function has the same signatur= e > > (prototype) for every platform. >=20 > Well... THEN WHY NOT MAKE A PLATFORM SPECIFIC FUCTION THAT IS CONVENIENT > TO USE ON PLATFORM WHERE IT IS MEANT TO BE USED FOR AND IT ACTUALLY HAVE > A MEANING ON WHERE IT IS ACCESSIBLE. I take that by "convenient to use" and your earlier "code safety" reference, you imply a function that returns a typed pointer to the structure, like "bda* var =3D grub_getbda();" in i386-pc, so that fields of such struct can be directly accessed by var->free_mem_kb. However, this requires that a function is created for each firmware structure that is deemed interesting by GRUB developers. In this proposal, only one (very lightweight) function is created and then IDs are defined for the structs. WRT "code safety", malloc and friends also return a void* that you have to cast, so nothing new under the sky. >=20 > If you want to learn something, study interfaces of disk->biosdisk->bios > and video->vbe->video bios... There are also several other good spots on > GRUB 2 code base that you could see... Will do, particularly the biosdisk part (video code nearly always makes my head spin). >=20 > You have still not provided a single GOOD example where this would be > used AND would provide some ADDED VALUE. Unless you provide a convincing > one (while I pretty much doubt) I do not see this feature to be in our > official tree. The added value (that expression reminds me of taxes) is: -Compared to SVN HEAD: a way to retrieve the _module-accessible_ address of firmware-provided structures. This is a protection against future changes in the GRUB kernel (like enabling paging, changing memory mapping schemes, etc.) that would otherwise force to inspect every single module for accesses to such structures by their "real" addresses. -Compared to SVN HEAD plus the many ad-hoc functions you seem to support: for most of the structures an asm helper is not required, thus less kernel space overhead than with many functions. Also, "focus of efforts" - maybe the oversight on "the" core function would add additional bitrot protection compared to the individuals functions. An use case would be in the proposed drivemap module, in the function installing an interrupt handler in the real-mode IVT: instead of the current code with magic addresses, /* Real mode IVT slot (seg:off far pointer) for interrupt 0x13. */ grub_uint32_t *ivtslot =3D (grub_uint32_t*)0x0000004c; The module could be like this: /* Real mode IVT slot (seg:off far pointer) for interrupt 0x13. */ grub_uint32_t *ivtslot =3D 19 + (grub_uint32_t*)grub_machine_get_fwstruct(GRUB_I386_PC_IVT); Then, if anything of the following ever happens: * The real mode IVT was live-relocated, either by GRUB or by the BIOS, by the use of LIDT * The real mode IVT was destroyed by GRUB, which keeps a copy at another address and sets it up, with the rest of a 8086-compatible environment only when it is required (memory pressure maybe?). * Linear addresses 0-1M do not correspond with physical addresses 0-1M because of whatever memory management the GRUB kernel is doing The above code would continue to work, while the even-more-above code would fail with unpredictable results. -Habbit >=20 >=20 >=20 > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel --=-lAubYo6BomlWnfIwQrKd 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) iQIVAwUASKXWdqSl+Fbdeo72AQK9bQ//dla68uup3bU5LkE7YgJ2vG8ZrJn1dQNm 5ivzoxeOIR/XYb5UDGhH0qLg5XG6Sn4kzTkHYSRZ9dxiprs5Vqp7Mv6GHcPIU3yA WneYuMJmV8niK7Xhv1oc0hyCKLPRMHeDl7EY/HN5a0TwaCpAc4Vd5B8wwTcKqQ5V T+/ntIxBjFnrrRFVsE98mFoUYVbQ+JcKNUlZCegRChqEGAk6xvJRSnZLGRqt24Wk sn/Wto5vWSOzXDteX9KqtYpgYPXYEnR+HYLtq2OCngihJEU0ABuxXDxvSNCrSzHf 4ClLhvm1/g39lHIK2+WGm4lJ0PoXM6GDZhHv+pR3K+qTG2vpHtQuPTbmGOwWia0z nFjLd+3O8Ttd9JQHXxwwPk0LcJT+Nh4Ww6DCEkMckrk3Pz8cR8kkF9X4KfBCoc9R mouupn1sw4l+0tR+PeNNG555gVgAxxvF8+1T75DfMK7xRFCM9AQrAfOVEh/9wvof uMoCRTlg3/yi+XyUFHQNa9zSs+Ji3vH/2ZcDF6NypJl9EYkamu2dCQHmJMeF9EAW 3IbfoIp+9J9sKYia0jJZmjb4ef1GRAjWm1dmTTHtwLlxN8eNKmweGn9aK5e9EXRp KpGiVjGs6YgXdAsdyTUNjB7pfhssIY04cMCIs4eLjvRhd38mEkkyoKYGGYez/dC/ Dbse/XP96yY= =q2La -----END PGP SIGNATURE----- --=-lAubYo6BomlWnfIwQrKd--