This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: The future of static dlopen

On Tue, Dec 19, 2017 at 11:24 PM, Florian Weimer <> wrote:
> On 12/20/2017 08:03 AM, Carlos O'Donell wrote:
>> It would be easiest to have a proxy process to handle these requests
>> for you... such a proxy process could be a proxy thread instead?
>> As you suggest earlier have the kernel start a new tid, and map into
>> your VMA a new dynamic executable that you can access and call into
>> for services?
> I would just add an option to /usr/bin/getent which causes it to enter
> co-process mode.  It's not going to be extremely efficient (especially if we
> don't use a persistent subprocess, but it would be quite reliable, unlike
> what we have to day).

This seems like another case where making nscd less of an afterthought
would be a win.  It already does this job, after all.  In principle,
static binaries could just omit the no-nscd fallback path.  (In
practice, falling back to "files [dns]" might be the right thing,
since static binaries tend to get used for recovery.)

I also wonder what other C libraries do for static NSS.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]