This is the mail archive of the libc-alpha@sourceware.org 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] |
On 12/20/2017 05:36 PM, Zack Weinberg wrote:
On Tue, Dec 19, 2017 at 11:24 PM, Florian Weimer <fweimer@redhat.com> 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.
I don't think nscd takes care of everything. Enumeration is missing, I think, and so are some databases (aliasent, etherent).
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 thought about that as well, but I'm really not sure if using nscd brings a benefit. From a distribution perspective, if you have to install nscd to run certain satic libraries, that might also enable it for dynamically-linked binaries, and many users may not want that.
Thanks, Florian
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |