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]

Re: [PATCH] resolv/resolv.h: allow alternative resolv.conf files


I have released userbindconf, a library and a utility command to
bind-mount files and directores in user-namespaces.
https://github.com/rd235/userbindmount

Nevertheless, the whole stuff sounds as a workaround to me.

On Fri, Aug 18, 2017 at 12:41:50PM -0400, Carlos O'Donell wrote:
> On 08/18/2017 11:07 AM, Renzo Davoli wrote:
> > It seems a bizantine procedure just to tell resolv to use a different
> > resolv.conf.
> I agree, but that's not the extent of this...
...
> > There is some extra work for the kernel (keep track of the new
> > namespaces, separate mounttables, more mount items) for a problem
> > that could be solved entirely at user level.
> Yes, you are right.
> You are paying the cost for a design abstraction.
> 
> Design abstractions make it easier for your users to know how your
> systems work without needing to learn something new e.g. a new
> environment variable.

An abstraction should be a simple concept able to represent a wide
range of situations. Astractions should be simpler than the 
"abstracted" concepts.

Using complicated methods to override a lack of generalization of
the lower layer is more a "distraction" than an "abstraction".

There are several environment variables already in glibc to
configure the name resolving process:
RES_OPTIONS, RESOLV_ADD_TRIM_DOMAINS RESOLV_MULTI 
RESOLV_OVERRIDE_TRIM_DOMAINS RESOLV_REORDER 
RESOLV_SERV_ORDER RESOLV_SPOOF_CHECK 

What to say about:
RESOLV_HOST_CONF
?

It redefines the path to be used instead of /etc/host.conf.
Isn't this very close to what I proposed as PATH_RESCONF?
(which could be renamed as RESOLV_RESCONF to be consistent
 with the others).

Is there really the need for a user-namespace for a so simple
(and common) generalization?
Timezones and locales should be implemented as "abstractions"
requiring namespaces if this is the idea, isn't it?
Try to think on how complex would be the management of
timezones and locales it this was the case...

Thank you

	renzo


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