From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KU5eP-00088P-5f for mharc-grub-devel@gnu.org; Fri, 15 Aug 2008 16:11:57 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KU5eN-00084X-Ar for grub-devel@gnu.org; Fri, 15 Aug 2008 16:11:55 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KU5eM-00082t-Hh for grub-devel@gnu.org; Fri, 15 Aug 2008 16:11:54 -0400 Received: from [199.232.76.173] (port=41277 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KU5eM-00082g-EC for grub-devel@gnu.org; Fri, 15 Aug 2008 16:11:54 -0400 Received: from yw-out-1718.google.com ([74.125.46.155]:58621) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KU5eM-0008B8-A2 for grub-devel@gnu.org; Fri, 15 Aug 2008 16:11:54 -0400 Received: by yw-out-1718.google.com with SMTP id 9so88218ywk.66 for ; Fri, 15 Aug 2008 13:11:53 -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=jYjUpiJD+NDbxCNPirKH++SbVb6SwsbU2Hz7f5eOScg=; b=i6awu4kzmlDU758QtEyeqVjuSItRaTvRGtLYBZRx06f22IzYU4JKBwGf+xx1LbuNC+ F96kGMjPRWZvrzfpHXhnxBxSHTUCvopri506pdcEx723xwejgqPBjNmad6wltC1k8iTT 4/aXSh/dVaSEUJ7+zPoC/jeo9X4+JhYGGRYgs= 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=cAy8V0GbkS6fPmEbp/31/SY/kl2UCZs95iSbCxWVEi6pHvnYkg1eUASobq/EvenXKn jB7P0n3X9f4UzdbJuVbJZ0Ck/9HqHh0x/ENplVU4ZvKUMD81T5UG5p7qrQFY17BI96kF Cm0Knk7BYV6vF2JyTUm8qGPICqRxdWZuuWakY= Received: by 10.67.40.15 with SMTP id s15mr976877ugj.67.1218831111643; Fri, 15 Aug 2008 13:11:51 -0700 (PDT) Received: from ?192.168.1.100? ( [213.37.137.93]) by mx.google.com with ESMTPS id 18sm3289295ugk.82.2008.08.15.13.11.49 (version=SSLv3 cipher=RC4-MD5); Fri, 15 Aug 2008 13:11:50 -0700 (PDT) From: Javier =?ISO-8859-1?Q?Mart=EDn?= To: The development of GRUB 2 In-Reply-To: <48A5DD13.5050903@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> <1218827894.2510.51.camel@localhost> <48A5DD13.5050903@nic.fi> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-5QJl9vhrxqdpQf3f9u7M" Date: Fri, 15 Aug 2008 22:13:01 +0200 Message-Id: <1218831181.2510.56.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 20:11:55 -0000 --=-5QJl9vhrxqdpQf3f9u7M Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable El vie, 15-08-2008 a las 22:46 +0300, Vesa J=C3=A4=C3=A4skel=C3=A4inen escr= ibi=C3=B3: > Javier Mart=C3=ADn wrote: > > 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 field= s > > of such struct can be directly accessed by var->free_mem_kb. > >=20 > > 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 > In your case there is really no change. >=20 > You create new switch branch (which is most likely implemented by > function somewhere). >=20 > In order to access this void * you have to know its contents. Why not > use structure to define its contents where viable? True, I just wanted to avoid defining structures that would only be used once or twice, but you're right. >=20 > When using malloc() you know that memory returned is not formatted in > anyway. Therefore it is safe to cast. >=20 > You just want to make it more complex that it needs to be in my eyes. >=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 convinci= ng > >> one (while I pretty much doubt) I do not see this feature to be in our > >> official tree. > > 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, > >=20 > > /* Real mode IVT slot (seg:off far pointer) for interrupt 0x13. */ > > grub_uint32_t *ivtslot =3D (grub_uint32_t*)0x0000004c; > >=20 > > The module could be like this: > >=20 > > /* 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); >=20 > The better way that complies with all your error cases provided: >=20 > grub_ivt_entry_t *entry; > entry =3D grub_get_ivt_entry(0x13); > *entry =3D new_value; This was another of the solutions I was considering in this thread (the "many-functions approach"), I just found the single-function solution more elegant in the case of "large numbers" (>10) of structures becoming visible through this method, but your snippet looks fine and "safer". >=20 > of course grub_ivt_entry_t could be renamed to be something like > grub_realmode_addr_t. grub_realmode_farptr_t would suit better IMO. -Habbit >=20 > . >=20 >=20 > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel --=-5QJl9vhrxqdpQf3f9u7M 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) iQIVAwUASKXjTKSl+Fbdeo72AQLrJQ/+Lqvz0IbiX4+WV9w8yexJLOaKcQ/jL3uD JUfbCn+rURh/jm76wh3O9f7Gzc+rKz3woFTSAN77eaVPCsztmiJyhPqERitLMjdV RBYuoLmuafYeqXx0f2/GDUi4nGLSoicHGczVVwhtOD0ssr6dKWy69tjVPG5+nntY g0px6ifZVUUK1YHEEpf/5GQEWK4Uswoz2/T3CjqOYdX8Yf90RTnXOBJawDUc/zim WDHTiclNDmx1ioqRelPZccyHF7goFbh/LHuZwO48Wr0hTcsnDngYJqV5XQ4pB/v5 L/q3JsIi0OojFS7GHKyfruxPJOtwavNOQqXib61BP9RoC4FjfF418SD+MBisB7Ai IpTCexTal/2x+XN/A1dI6hff/d7Cssv4rf0OMoO16OLJgkypCcSglkXyBYFzkHfH puWDNM3S/vXcKWWA5BOKah8svgeEAJ16VFccB0Y8IDP3nCWbSDHOCKRObW5mz9cT dtpcCOr83EHv3eW9RczJ5XZ4CVqH+YC0mjDpA3iDzUn/zkIO8rslvDsXjb5XSVdd G1wbRne11oC8jzRcu2KqPpdmnfppQccsx4FhogHaU5CHsD5oz6z31SiLwKHVvq9h fAKpWOemtIXvwFLlBhcvFsm2lTNzFTrmZ4+x0WKMcQOpJxxJ7c4U6zGgojBPMlP8 o3cSs2M3CcE= =M892 -----END PGP SIGNATURE----- --=-5QJl9vhrxqdpQf3f9u7M--