Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754751AbbK0N1t (ORCPT ); Fri, 27 Nov 2015 08:27:49 -0500 Received: from pandora.arm.linux.org.uk ([78.32.30.218]:34397 "EHLO pandora.arm.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754705AbbK0N1m (ORCPT ); Fri, 27 Nov 2015 08:27:42 -0500 Date: Fri, 27 Nov 2015 13:27:23 +0000 From: Russell King - ARM Linux To: Pali =?iso-8859-1?Q?Roh=E1r?= Cc: Frank Rowand , Tony Lindgren , Arnd Bergmann , Pavel Machek , "devicetree@vger.kernel.org" , Laura Abbott , Grant Likely , Rob Herring , Will Deacon , Ivaylo Dimitrov , Sebastian Reichel , Andreas =?iso-8859-1?Q?F=E4rber?= , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org Subject: Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry Message-ID: <20151127132722.GA30871@n2100.arm.linux.org.uk> References: <20150713131902.GH26485@atomide.com> <20151123144545.GD24147@pali> <20151125181644.GI2517@atomide.com> <17134653.86P3dFyQKK@wuerfel> <20151125210310.GT2517@atomide.com> <56568849.5080103@gmail.com> <20151126090739.GD14190@pali> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20151126090739.GD14190@pali> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2777 Lines: 73 On Thu, Nov 26, 2015 at 10:07:39AM +0100, Pali Roh?r wrote: > On Wednesday 25 November 2015 20:19:21 Frank Rowand wrote: > > > Or populate /proc/atags only for the ones that need it from machine > > > specific init_early? > > > > This is circling back to the first comment from Russell King where > > he suggested a legacy file for the N900 which calls save_atags(): > > > > Are the ATAGs at a fixed address on the N900? Can that be handled in > > some kind of legacy file for the N900 which calls save_atags() on it, so > > we don't end up introducing yet more stuff that we have to maintain into > > the distant future? If not, what about copying a known working atag > > structure into a legacy file for the N900? > > > > It seems to me that patches 1, 2, 4, and 5 could be replaced by this > > approach. > > Hi Frank, in this case I will ask my question again: It is possible to > read atags from that legacy file. And if yes how? I was not thinking > about this approach because somebody in past wrote that this is not > possible... It is possible to redirect any program to open any other file. You can do it via a LD preload, and intercepting the open(), and possibly the read() calls if you want to do something more fancy. The down-side is that you have to arrange for the preloaded object to be used by the linker, and the additional overhead it places on the intercepted functions. Eg, openatags.c: #define open libc_open #include #undef open #include int open(const char *pathname, int flags, mode_t mode) { static int (*old_open)(const char *pathname, int flags, mode_t mode); if (strcmp(pathname, "/proc/atags") == 0) pathname = "/tmp/my-atags"; if (!old_open) old_open = dlsym(RTLD_NEXT, "open"); return old_open(pathname, flags, mode); } Build the above (untested) with: gcc -O2 -o openatags.o -c openatags.c gcc -shared -o openatags.so openatags.o -ldl Now, when running one of these programs, you can test it with: LD_PRELOAD=openatags.so /name/of/program You could also list the full pathname to openatags.so in /etc/ld.so.preload, but test it first, because it will always be used by the linker in that case, and you wouldn't want normal commands to misbehave. Note that putting it in /etc/ld.so.preload will also have the effect that cat /proc/atags will also get redirected to /tmp/my-atags too. -- FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/