From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KU3Yy-0005vL-F3 for mharc-grub-devel@gnu.org; Fri, 15 Aug 2008 13:58:12 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KU3Yw-0005vA-5T for grub-devel@gnu.org; Fri, 15 Aug 2008 13:58:10 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KU3Yt-0005ud-Ui for grub-devel@gnu.org; Fri, 15 Aug 2008 13:58:09 -0400 Received: from [199.232.76.173] (port=58625 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KU3Yt-0005ua-QO for grub-devel@gnu.org; Fri, 15 Aug 2008 13:58:07 -0400 Received: from nf-out-0910.google.com ([64.233.182.185]:5749) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KU3Yt-00057C-6X for grub-devel@gnu.org; Fri, 15 Aug 2008 13:58:07 -0400 Received: by nf-out-0910.google.com with SMTP id c7so707715nfi.26 for ; Fri, 15 Aug 2008 10:58:06 -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=JSCpAwFC/ztdal5IyL0Z0u/CkeYyVyIinWLztEI8CCU=; b=d0b7QxnEdRgQvrDf7APfCvPIVKM50FO1YjDmoZWhcaHbOEVQnBZD1/w68B99GqInnl 1zcYw2fLx2GtnN2fm1IWS88vVXPYBsKeiEKU3tkgy9GUzy5WJN+wpRvNw6vQ0yErPtJX R4fDeWF8oj/Zj9BfqArMVjR8Ei3YLaoG++E3g= 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=BB9rdR05/PoX9XlCzOaKL57UcFXSgiyhr1Z9Zi/PZM8RwO6pph1AOu3WRvBUdTblb8 zdoxU8JVeerWf26PdYjMJXi9DYCPTeacgg8yCVRB1IlUxUDPFC350vYD8IWBPbu+9JIM Vexl66YY35/TZJoEy7zf8f9QxgKx2tJDgOJDM= Received: by 10.210.45.17 with SMTP id s17mr3483708ebs.192.1218823085988; Fri, 15 Aug 2008 10:58:05 -0700 (PDT) Received: from ?192.168.1.100? ( [213.37.137.93]) by mx.google.com with ESMTPS id z34sm271851ikz.9.2008.08.15.10.58.03 (version=SSLv3 cipher=RC4-MD5); Fri, 15 Aug 2008 10:58:04 -0700 (PDT) From: Javier =?ISO-8859-1?Q?Mart=EDn?= To: The development of GRUB 2 In-Reply-To: <48A5B96D.7040209@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> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-JK5iO5JA719oholMcnyK" Date: Fri, 15 Aug 2008 19:59:14 +0200 Message-Id: <1218823154.2510.23.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 17:58:10 -0000 --=-JK5iO5JA719oholMcnyK Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable El vie, 15-08-2008 a las 20:14 +0300, Vesa J=C3=A4=C3=A4skel=C3=A4inen escr= ibi=C3=B3: > Javier Mart=C3=ADn wrote: > > El vie, 15-08-2008 a las 19:31 +0300, Vesa J=C3=A4=C3=A4skel=C3=A4inen = escribi=C3=B3: > >> Javier Mart=C3=ADn wrote: > >>> WRT "kernel and modules going hand by hand", think about external > >>> modules: if the drivemap module is finally rejected for introduction = in > >>> GRUB, I will not scrap it, but keep it as a module external to the > >>> official GNU sources and possibly offer it in a web in the form of > >>> patches to the official GRUB2. In this case, changes made to the kern= el > >>> would not take into account that module, which would break if I weren= 't > >>> monitoring this list daily. > >> Then it is really your problem ;) > > Indeed, but bitrot is not just the real of external modules: it's > > happening right now even within the GRUB trunk as you admit in the > > "Build problems on powerpc" thread... >=20 > And? If Power PC maintainer is nowhere to update to newest additions > then it is rightly in in-compilable state and if it rots too long its > support will be removed. That's life. Yes, but you implicitly and particularly Robert explicitly argued that when kernel changes devs here take the time to update modules in consonance and vice versa. The PPC build problem shows that, for whatever reason, this is not always true. >=20 > >>> Additionally, the cost of this function in platforms which don't have > >>> any structs registered yet, as the function could be a stub like this= : > >>> > >>> void* grub_machine_get_platform_structure (int stidx) > >>> { > >>> grub_error (GRUB_ERR_BAD_ARGUMENT, "Struct %d not supported", stidx= ); > >>> return 0; > >>> } > >>> > >>> The kernel space taken would most likely be less than 50 bytes. For > >>> i386-pc, it could be like this (also lightweight) function: > >>> > >>> void* grub_machine_get_platform_structure (int stidx) > >>> { > >>> grub_errno =3D GRUB_ERR_NONE; > >>> > >>> switch (stidx) > >>> { > >>> case GRUB_MACHINE_I386_IVT: > >>> return /* Call to asm function that runs SIDT in real mode */ ; > >>> case GRUB_MACHINE_I386_BDA: > >>> return (void*)0x400; > >>> default: > >>> grub_error (GRUB_ERR_BAD_ARGUMENT, "Struct %d not supported", > >>> stidx); > >>> return 0; > >>> } > >>> } > >> And what lets assume couple of extra platforms... how about > >> x86-32bit-efi and ppc. What do they do? > >> > >> Implement their own enum entries for those indexes and only use their > >> own indices...? > > At first, they would just have the stub which does not recognize any > > index, but yes, i386-efi devs could decide that certain > > firmware-provided structure (like a video modes info table or such, I > > don't know the internals of EFI) might be interesting to a module > > they're creating, so they create an index for it and add it to the > > version of the function in their platform. > >=20 > > If I had not mentioned it before, the function would be declared in a > > cross-platform file, but _implemented_ in platform-specific files, and > > the indices would be declared in the platform-specific machine.h. Thus= , > > there would not be a "single" indices namespace: structure #1 might be > > the IVT in i386-pc, but some devices info table in powerpc-ieee1275. > >=20 > >> Where here we are sharing any code? (if we do not count the name of th= e > >> fuction.) Interface is kinda useless if there is no possibility that > >> no-one is sharing its functionality... > > The idea is a single function to retrieve the addresses of > > firmware-provided/used structures. This includes the IVT and BDA in > > i386-pc, but as I said before it could also be used by other platforms > > for their own structures. The alternative would be just creating such > > "get struct X" functions on each platform as they are needed, but I > > imagined that a single interface (with such a low cost in space) would > > be a more elegant solution. >=20 > 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. >=20 > 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 signature (prototype) for every platform. >=20 > And if we think about code safety, casting is bad. And if you keep > indices colliding on different platforms then you are just calling for > problems. It completely removes any advantage what this kinda wrapper > could have had. Why? any module that is "advanced" (in the sense of complicated) enough to require the use of platform-specific structures will be platform-specific itself, or at least the part of it that accesses the structures, and thus the risk of indices actually colliding is nearly zero. -Habbit >=20 >=20 > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel --=-JK5iO5JA719oholMcnyK 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) iQIVAwUASKXD8qSl+Fbdeo72AQIbAhAAw6terbTtiQ2slQJV6Xf49MlO5CsomudX aqUaKjPMK5wxZ9tC36RAh6XFrIWvGItEeOZHJYN+rjnbAxln472O3vs4CcMXl0Iv tRf4bJTTWPfQKqkOi6nJCZToyqDxGABGrMkgYUu4YQJFtdZLeta9qeiyRsD1xsc/ bT7fRYbESqhjantDRz+yTVs4B5Iy8twosgCeUNbghQxjvsfCe0qGJN4h0ASTEQaA /wckyre0dxlj4Kj2EaisOs+w/RRnqouz60i48vGEDRkuZ8DqCBnnbkYTcr6VJnry rQkWXF3X6BlKIsw2cNFoFDnDQSLLI5ymWOPbQNMqOBeaYIyPtnDJL2f0PlsY8kY9 Ec2WriXZ4o8DdQ2bo+B3BleobW9DEg6WzzKQ9dxdOBxMJFdzheZwoom09gdU5lIf hVl/FeIQhK/URTJA2FjwelD60rIHzMpl0QW/KbFf3Cd6HtyZqU33OjKbLdDODXLf K5uVAtITwwW5Y5ZWOI7SOHRxj42NvOuZhPfmC5r5ouTqU5N2CoTHk8dXXMpReQ1y kWSAEI1PVPIYktjXwz2lHeg452zm1Pi4nV3JVTW3FU9HtdYwnBPUE9M2axpTjTUz KcpHPoFHyF4vHC2x5eahGUYxDL1J5poojtfeMC0NVFDIYOKJ801oH06y6kp/csIs XaJ4Ps9yE2E= =rvdz -----END PGP SIGNATURE----- --=-JK5iO5JA719oholMcnyK--