From: Ian Kent <raven@themaw.net>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: autofs@linux.kernel.org
Subject: Re: Executable maps
Date: Tue, 06 Jul 2010 09:19:17 +0800 [thread overview]
Message-ID: <1278379157.3070.12.camel@localhost> (raw)
In-Reply-To: <4C2E6209.5030506@zytor.com>
On Fri, 2010-07-02 at 15:02 -0700, H. Peter Anvin wrote:
> On 06/13/2010 09:44 PM, Ian Kent wrote:
> >
> > Don't think that could work.
> > There's no way for a program map to enumerate the entire map at initial
> > startup and I don't want to add something that allows that because
> > program maps are dynamic and that introduces all sorts of difficulties
> > for the handling of direct mounts. And there is no way to use a program
> > map for a direct mount that has not been mounted (at startup).
> >
>
> Sorry for a *way late* reply.
>
> There isn't a reason why a protocol for a program map to enumerate
> itself couldn't be constructed, probably invoking the program map
> without an argument, and receiving an enumeration on stdout; either
> null- or LF-separated.
>
> Obviously not all program maps will be capable of being enumerated, but
> that's true for any map set.
I think I more or less nacked that idea a while back but it is the
obvious and sensible way to do it.
Of course there is the bonus that any program map that doesn't check the
passed in key, assuming it's non-null, will likely SEGV, which would
make it all worth while.
Hehe, but seriously automount should be able to cope with crashing
program maps. I'm fairly sure I've tested that on occasion.
So, sounds good, I'll give it a go and we'll see what happens.
Ian
prev parent reply other threads:[~2010-07-06 1:19 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-07 23:33 Executable maps Techie
2010-06-14 4:44 ` Ian Kent
2010-07-02 22:02 ` H. Peter Anvin
2010-07-06 1:19 ` Ian Kent [this message]
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=1278379157.3070.12.camel@localhost \
--to=raven@themaw.net \
--cc=autofs@linux.kernel.org \
--cc=hpa@zytor.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.