From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KU2gs-00037J-8U for mharc-grub-devel@gnu.org; Fri, 15 Aug 2008 13:02:18 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KU2gq-00035g-8r for grub-devel@gnu.org; Fri, 15 Aug 2008 13:02:16 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KU2gn-000337-0G for grub-devel@gnu.org; Fri, 15 Aug 2008 13:02:15 -0400 Received: from [199.232.76.173] (port=49949 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KU2gm-00032v-R9 for grub-devel@gnu.org; Fri, 15 Aug 2008 13:02:12 -0400 Received: from yx-out-1718.google.com ([74.125.44.155]:26926) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KU2gm-0001Zz-7I for grub-devel@gnu.org; Fri, 15 Aug 2008 13:02:12 -0400 Received: by yx-out-1718.google.com with SMTP id 34so644068yxf.66 for ; Fri, 15 Aug 2008 10:02:11 -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=5P07Lmmgv1QE20shuQOIeMtqNd0F/n0tSHiBbJOKHig=; b=baCOLrvN+1WAVhvB6IlQaTfILTLtNRyCkVetGtP94DSUkGgCL/A3PgisDomiI+pdfu VFxE2cLB46ekaZGv20pPmVPIVntoFikcJjoBkMynQMrwfd494CMGNuaTtp2gS1lDAJDQ lwyNWwnvy8ATuyyR2pK/LMZFZSuhiXHSuAtaw= 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=LqV2DQaS/yfU5xEVXQcjdolpdHXkHSz9y0NAp2UPGYUlCkNdZ/GGuUok7fgqx1q9oU whoIuSP12HmjSXpwFGVfEV51GLgjQJ+KTgDcshweEGvlvufKlt1bt+pi5MwhvDA45nsg dHkTDPzfcshAx8wEKhQFvEBrwoD2zFdZCxLkU= Received: by 10.66.244.11 with SMTP id r11mr793882ugh.47.1218819730050; Fri, 15 Aug 2008 10:02:10 -0700 (PDT) Received: from ?192.168.1.100? ( [213.37.137.93]) by mx.google.com with ESMTPS id c1sm259191ugf.11.2008.08.15.10.02.08 (version=SSLv3 cipher=RC4-MD5); Fri, 15 Aug 2008 10:02:09 -0700 (PDT) From: Javier =?ISO-8859-1?Q?Mart=EDn?= To: The development of GRUB 2 In-Reply-To: <48A5AF50.2040906@nic.fi> References: <1218684975.8757.139.camel@localhost> <48A4589D.3040902@nic.fi> <20080814180005.GB5614@thorin> <1218749362.19647.20.camel@localhost> <48A5AF50.2040906@nic.fi> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-hynlhYcUab6dy0hbmlmG" Date: Fri, 15 Aug 2008 19:03:18 +0200 Message-Id: <1218819798.2510.13.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:02:16 -0000 --=-hynlhYcUab6dy0hbmlmG Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable El vie, 15-08-2008 a las 19:31 +0300, Vesa J=C3=A4=C3=A4skel=C3=A4inen escr= ibi=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 kernel > > would not take into account that module, which would break if I weren't > > monitoring this list daily. >=20 > 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 > > 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: > >=20 > > void* grub_machine_get_platform_structure (int stidx) > > { > > grub_error (GRUB_ERR_BAD_ARGUMENT, "Struct %d not supported", stidx); > > return 0; > > } > >=20 > > The kernel space taken would most likely be less than 50 bytes. For > > i386-pc, it could be like this (also lightweight) function: > >=20 > > void* grub_machine_get_platform_structure (int stidx) > > { > > grub_errno =3D GRUB_ERR_NONE; > >=20 > > 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; > > } > > } >=20 > And what lets assume couple of extra platforms... how about > x86-32bit-efi and ppc. What do they do? >=20 > 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. 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 the > 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. -Habbit >=20 >=20 >=20 > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel --=-hynlhYcUab6dy0hbmlmG 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) iQIVAwUASKW21qSl+Fbdeo72AQLtQxAAnLeg7McI8ub0YCgT6BxE4A+U3JVZTST5 1HXNqy3m+BkysGW261TSdYdErjaXjniB3D9jGfyV2PkfNsBZAb0Tr/N44sAVH0HX ZvS4K4hcS/jlzp2rwLnkA1s1tNpcHaTZ4CWxWPAXrNMdxhoW2FWW9v89msHZ7hiH AdC8xEPXm0INTVZD8sm8VID6YVVd/ZpRo7X8fHVdfr3zWz+iAIZv4hj6tOty4D4w SLuqqVzQGJB5Rx594+OfENfi5pSLCZ8wogoj0X4B9gWx6DiYPltZPihWI72b/ZL6 jqudk/T7wYU6+dn/qj5i6k1qrT+gCHhopW5u9FqpFgVkDqKyBhQN13QZa4NQOpKm q46v67JNc5MPdUvySh70eEdBlHubMxRCU1op+QrXXiYvxhkKx5CUvNx5xV7lYy0s R9mOSp1zSQumn2cZ8OrMnkgXd0GbSCa6TpNriSqhBs/xTRmm2M7z7Gpci09KcDwX 1oC9YxSomOxbVzduKiRWDAKRGVd77i7QOFf//rcC75kKVIxLxgUXk8D4P/IbxN0e caB/QXuO5SIUl0CVLrUgI0orkMiCnH8RT/HRn2Ik0f3rLGvnNgkEol455H8iqSa+ hsk1vj+dbQihJzi7wR4PCJPjbN4gP2wKZwT1Rguwr7KnmEqx86IU4VCBfXt6cDTK zrWygEAHlcI= =aAu6 -----END PGP SIGNATURE----- --=-hynlhYcUab6dy0hbmlmG--