From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KaYjp-0002ab-1C for mharc-grub-devel@gnu.org; Tue, 02 Sep 2008 12:28:17 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KaYjm-0002YW-G7 for grub-devel@gnu.org; Tue, 02 Sep 2008 12:28:14 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KaYjk-0002Wu-UQ for grub-devel@gnu.org; Tue, 02 Sep 2008 12:28:13 -0400 Received: from [199.232.76.173] (port=57587 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KaYjk-0002Wl-FL for grub-devel@gnu.org; Tue, 02 Sep 2008 12:28:12 -0400 Received: from ug-out-1314.google.com ([66.249.92.175]:34130) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KaYjj-0002gV-V8 for grub-devel@gnu.org; Tue, 02 Sep 2008 12:28:12 -0400 Received: by ug-out-1314.google.com with SMTP id m2so2278442uge.17 for ; Tue, 02 Sep 2008 09:28:10 -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=opJflB7NYTBR7jQSD9/cEdLnw2iahuoTOV4OzeHDlKY=; b=KbqIkKePIwUDrMuKquktEW2rz6uSXbRp739BcC8C6C1DxkbMgzu2GAK3MMjCiqcj2A fKdo8VGzCCHRNAx1KFN/vZOGBZZHGDHPbSw2j3ptD7M2Xk4gFuNk694BBMZbJC1wAgd/ txzXEtEZs62THjm9oNWd3Rb8BdhhFiNINDBPQ= 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=g+RNz1pEG3cRb3fnuOQV1uFfBmYDgv1G8Xk02MOyMec1fggH95PnsDDCYmLSytfSuX +hkOwh2+fVp+PmeZFwll6lzaeMqXZzZ8SzkSfwmqc+JmX3YlpNs0CtvpVCAH0RmBBTTI OKijUcX9gXHVo7n8sZXDgdMQVSj7Pg9vHKLRA= Received: by 10.67.123.8 with SMTP id a8mr4086629ugn.42.1220372889890; Tue, 02 Sep 2008 09:28:09 -0700 (PDT) Received: from ?192.168.1.100? ( [213.37.137.93]) by mx.google.com with ESMTPS id b39sm19303163ugf.41.2008.09.02.09.28.07 (version=SSLv3 cipher=RC4-MD5); Tue, 02 Sep 2008 09:28:08 -0700 (PDT) From: Javier =?ISO-8859-1?Q?Mart=EDn?= To: The development of GRUB 2 In-Reply-To: <48BD62BE.7090507@gmail.com> References: <48BD4C52.6040308@gmail.com> <1220367299.23879.15.camel@localhost> <48BD62BE.7090507@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-d0OoFwhbbvkd5iEpACng" Date: Tue, 02 Sep 2008 18:30:59 +0200 Message-Id: <1220373059.23879.25.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: Sendkey patch 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: Tue, 02 Sep 2008 16:28:15 -0000 --=-d0OoFwhbbvkd5iEpACng Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable El mar, 02-09-2008 a las 17:58 +0200, phcoder escribi=C3=B3: > > but it seems terser > > than mine even though it's a bit more difficult to understand because > > you use double pointers to avoid my handling of the head case. I don't > > understand the purpose of doubly-linking the list though... > >=20 > The goal is to avoid walking through list when deleting an entry from it. But you negate any performance gain when you _do_ traverse the list to add an entry to it instead of just make it the new head as I do. Besides, even for that, double indirection should be avoided in the structure previous pointer because it makes things oh-so-incredibly confusing. Besides, I think the "user" (i.e. module) visible type returned by _add and taken by _remove should be a "blank hidden type", i.e. you don't need to declare "struct grub_preboot_t" in loader.h because the public interface only uses _pointers_ to it, whose size is known. This is all the C compiler requires and you avoid polluting the namespace with internal implementation details. I recommend the following typedefs: typedef struct grub_preboot_t* grub_preboot_hnd; typedef grub_err_t *(grub_preboot_func)(int noreturn); So that the prototypes would look grub_preboot_hnd add(grub_preboot_func f); void remove(grub_preboot_hnd handle); > >> Whether we need also interface for adding "postboot" commands? (in cas= e > >> boot_function returns) > > I don't think it would offer a lot of functionality because most loader= s > > don't return on failure, they just get stuck or their payload > > triple-faults and reboots. >=20 > It's the case for i386-pc loaders but not the case of some other targets > (e.g. EFI). So the question remains. And same question for abortion procedures. This is a spinous matter because clean handling is difficult, not always possible and requires registering "undo" functions, i.e. more bloat in kernel. -Habbit --=-d0OoFwhbbvkd5iEpACng 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) iQIVAwUASL1qQqSl+Fbdeo72AQI6dQ/9HJiWP2yABj2VTtlHiAv3o1E3CBa3ME6Y KVtoIe4MO1/rJ0fgv+H3UXhmHnLH8dzwJ4yp3nChlyUsAlvip1CAudr9ovc1PBMy YhpkKn9OTD1xZliKf/mS/Lqc8GxwxQuekxX49Io8kxMnbTrMmaQzns62lWST8Bwy MU2SQ0OzhxYtjfhneeATzNWVKffH8UC511pDzXJqn+v0FzIgmbSfPze9NU9R72Jq Orv9H62gfbGfBC41WAGMlbYooxEcrSgznJhO4Po8LQ+eBvuLfa/m4Cxj9l4GvM1T taVcHoljgQIdhnDGw9nDuBHVEFB/jQ3UmBAqC302nwePFe/zqzt8XvtLPLcjVvaq pEvzHqyfZIZciGXBL1pWKXFYm5eYtHTrVA83IGZvORyb3uOO7PLCysZOHrvxqAT7 V9DtOWIo6aB3gNcBUdEqIUhPGEE6SN2gfzO/CIjlq8UHBevbagbPFSXRnVgvzrWi wyjU9ghmArsSDJWkQ6VgJvfossD1Ignva83eOTFIZ9XQT6g06HLjSNcz6LSnpvy3 cHHvpiLL/uEOiE/TjHyHz4F4w66C1s3IAoeZQvMfV8G8w+OYCbeBS8oKxd5k62zG GaWzmZ0k5n08L7E6Dlots0+a95/YWqOUt/yWCfRVz3LI5oQ2BCsx3PcMd1/fRXD3 So6mK388WsM= =hLbW -----END PGP SIGNATURE----- --=-d0OoFwhbbvkd5iEpACng--