From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1SO5W3-0005bC-Tx for mharc-grub-devel@gnu.org; Sat, 28 Apr 2012 07:08:39 -0400 Received: from eggs.gnu.org ([208.118.235.92]:60301) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SO5W0-0005ax-Ns for grub-devel@gnu.org; Sat, 28 Apr 2012 07:08:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SO5Vy-0001hm-Pf for grub-devel@gnu.org; Sat, 28 Apr 2012 07:08:36 -0400 Received: from mail-wg0-f49.google.com ([74.125.82.49]:46156) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SO5Vy-0001hc-G9 for grub-devel@gnu.org; Sat, 28 Apr 2012 07:08:34 -0400 Received: by wgbds1 with SMTP id ds1so1104185wgb.30 for ; Sat, 28 Apr 2012 04:08:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type; bh=zBj+L6mRjEevRObV+pE1vCEHJri75afdB6n390w3jw4=; b=WO+XV3qMHrPVYvDco8cyO0vvxadSkyQ1rrTetcprzzPq8evNQ2I22lqO+LfV1Cb12I vhJszIQp0eKUk/6iEEenhaN+4Vnz8dDNre2fXWksdU+N+ImCEIoPdpAfuRuXygQcZe14 MRp0ABau6n32tVqiIwlfs8wZdUB48kpIDZyuAZ4ES0Bdm46gquJmmx+tNYWLQWoMpd6b FsgRtuhgiKhOpWggPkVR39lyuUEN0mBk+wdL4jnmDH2HhX4qlPzBJWHgVWRn9SNeDR2m FeEBUgy6ZdC+vYoKlGG/0hmbMZ3NcaePHfumTYYsm7uCxTApEpZ+O0+s3Izbh90bsaEI skzg== Received: by 10.180.80.104 with SMTP id q8mr13885502wix.14.1335611312550; Sat, 28 Apr 2012 04:08:32 -0700 (PDT) Received: from debian.x201.phnet (70-16.203-62.cust.bluewin.ch. [62.203.16.70]) by mx.google.com with ESMTPS id k6sm11740512wiy.7.2012.04.28.04.08.30 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 28 Apr 2012 04:08:31 -0700 (PDT) Message-ID: <4F9BCFA5.4060108@gmail.com> Date: Sat, 28 Apr 2012 13:08:21 +0200 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.3) Gecko/20120329 Icedove/10.0.3 MIME-Version: 1.0 To: grub-devel@gnu.org Subject: Re: ReiserFS reading performance patch References: <4F9AE72D.5010800@gmail.com> <4F9B0212.9090407@gmail.com> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig76DDD2BD5A74295A162A1092" X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 74.125.82.49 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Apr 2012 11:08:38 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig76DDD2BD5A74295A162A1092 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 28.04.2012 12:06, Bean wrote: > 2012/4/28 Vladimir '=CF=86-coder/phcoder' Serbinenko : >> On 27.04.2012 20:36, Vladimir '=CF=86-coder/phcoder' Serbinenko wrote:= >>> On 27.04.2012 16:05, Albert Zeyer wrote: >>>> * Write a simplified compile.py script. >>> We don't have any compile.py. >>>> * Remove nested functions. They don't work on Mac because of stack >>>> execution protection. >>> It can be disabled. It's Apple fault for not allowing to disable it >>> selectively. Replacing nested functions is possible if done properly = but >>> the "let's make it all static" is wrong and will create problems with= >>> recursion, i.a. with nested partitions. >> And actually nested functions don't matter. What does are trampolines >> and they are only emitted it nested functions access local variables o= f >> parent and not inlined. > Hi, > > I think mac is not alone, netbsd uses non-executable stack and heap as > well. Anyway, lower system security just to run an application does > seem a little undesirable. NetBSD allows to enable and disable heap execution at runtime using __enable_executable_stack which is called by GCC automatically when emitting trampolines. > I once wrote a small framework to get rid of the nasty trampolines, for= example: > > #define DEFINE_CLOSURE struct __closure_struct { > #define DEFINE_CLOSURE_END } __closure_data; > #define CLOSURE_TYPE void *__closure void has a disadvantage of not checking the alignment. It's better to use opaque structs. > #define CLOSURE __closure > #define CLOSURE_DATA &__closure_data > #define USE_CLOSURE struct __closure_struct *__closure_p =3D __closure;= > #define UNUSED_CLOSURE (void) __closure; We systematically use __attribute__ ((unused)) This is a good way of doing things when there is no other option. However, in many cases it's better to use macros like FOR_*. They also result in smaller code. The major point where it can't be done is with ->dir but this interface should be changed anyway because it forces some code to scan through directory just to e.g. find out mtime of a single file. --=20 Regards Vladimir '=CF=86-coder/phcoder' Serbinenko --------------enig76DDD2BD5A74295A162A1092 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREKAAYFAk+bz60ACgkQNak7dOguQgm6qAD/Zt35lfQz4eqMkxI6FJSnMzgA e9x3A6Q6m0C9zal9zwcA/0HGI15IFiryRUuAn1GrkxP0YfhRxc6ew/JZbIvAj95v =5ABh -----END PGP SIGNATURE----- --------------enig76DDD2BD5A74295A162A1092--