From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: "Pali Rohár" <pali.rohar@gmail.com>
Cc: "Frank Rowand" <frowand.list@gmail.com>,
"Tony Lindgren" <tony@atomide.com>,
"Arnd Bergmann" <arnd@arndb.de>, "Pavel Machek" <pavel@ucw.cz>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"Laura Abbott" <lauraa@codeaurora.org>,
"Grant Likely" <grant.likely@linaro.org>,
"Rob Herring" <robherring2@gmail.com>,
"Will Deacon" <will.deacon@arm.com>,
"Ivaylo Dimitrov" <ivo.g.dimitrov.75@gmail.com>,
"Sebastian Reichel" <sre@debian.org>,
"Andreas Färber" <afaerber@suse.de>,
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
Date: Fri, 27 Nov 2015 13:27:23 +0000 [thread overview]
Message-ID: <20151127132722.GA30871@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <20151126090739.GD14190@pali>
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 <fcntl.h>
#undef open
#include <string.h>
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.
next prev parent reply other threads:[~2015-11-27 13:27 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1436214373-12969-1-git-send-email-pali.rohar@gmail.com>
[not found] ` <20150713131902.GH26485@atomide.com>
[not found] ` <20151012201640.GQ23801@atomide.com>
[not found] ` <201510122225.12786@pali>
[not found] ` <20151012204509.GT23801@atomide.com>
[not found] ` <20151013143746.GJ23104@pali>
[not found] ` <20151105114041.GC27908@pali>
[not found] ` <20151105161756.GG3078@atomide.com>
2015-11-12 1:10 ` [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry Frank Rowand
2015-11-22 6:51 ` Pavel Machek
2015-11-23 14:45 ` Pali Rohár
2015-11-25 18:16 ` Tony Lindgren
2015-11-25 19:48 ` Arnd Bergmann
2015-11-25 21:03 ` Tony Lindgren
2015-11-25 21:29 ` Arnd Bergmann
2015-11-25 21:44 ` Pali Rohár
2015-11-25 21:51 ` Arnd Bergmann
2015-11-25 22:00 ` Pali Rohár
2015-11-26 4:19 ` Frank Rowand
2015-11-26 9:07 ` Pali Rohár
2015-11-26 20:39 ` Tony Lindgren
2015-11-26 21:12 ` Ivaylo Dimitrov
2015-11-27 8:38 ` Pali Rohár
2015-11-27 8:44 ` Michael Trimarchi
2015-11-27 8:52 ` Michael Trimarchi
2015-11-27 14:51 ` Tony Lindgren
2015-11-27 13:27 ` Russell King - ARM Linux [this message]
[not found] ` <20151127132722.GA30871-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2015-11-27 19:51 ` Russell King - ARM Linux
2015-11-27 21:06 ` Arnd Bergmann
2015-11-27 23:28 ` Nicolas Pitre
[not found] ` <alpine.LFD.2.20.1511271817230.22569-fMhRO7WWcppj+hNMo8g0rg@public.gmane.org>
2015-11-28 12:27 ` Arnd Bergmann
2015-11-28 12:54 ` Russell King - ARM Linux
2015-11-28 12:33 ` Russell King - ARM Linux
2015-11-28 17:34 ` Nicolas Pitre
[not found] ` <alpine.LFD.2.20.1511281232440.22569-fMhRO7WWcppj+hNMo8g0rg@public.gmane.org>
2015-11-28 21:02 ` Frank Rowand
2015-11-29 18:09 ` Russell King - ARM Linux
2015-11-29 18:19 ` Pali Rohár
2015-11-29 23:13 ` Russell King - ARM Linux
2015-11-30 0:09 ` Nicolas Pitre
[not found] ` <alpine.LFD.2.20.1511291902100.22569-fMhRO7WWcppj+hNMo8g0rg@public.gmane.org>
2015-11-30 0:15 ` Pali Rohár
2015-11-30 15:23 ` Tony Lindgren
[not found] ` <20151130152352.GY2517-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
2015-11-30 15:39 ` Pali Rohár
2015-11-30 16:09 ` Nicolas Pitre
2015-12-15 9:33 ` Pali Rohár
2015-12-15 11:04 ` Arnd Bergmann
2015-12-15 12:20 ` Russell King - ARM Linux
[not found] ` <20151215122038.GI30871-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2015-12-15 17:24 ` Nicolas Pitre
2015-12-23 14:54 ` Ivaylo Dimitrov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151127132722.GA30871@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=afaerber@suse.de \
--cc=arnd@arndb.de \
--cc=devicetree@vger.kernel.org \
--cc=frowand.list@gmail.com \
--cc=grant.likely@linaro.org \
--cc=ivo.g.dimitrov.75@gmail.com \
--cc=lauraa@codeaurora.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=pali.rohar@gmail.com \
--cc=pavel@ucw.cz \
--cc=robherring2@gmail.com \
--cc=sre@debian.org \
--cc=tony@atomide.com \
--cc=will.deacon@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).