From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-4.1 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 84F2A20248 for ; Mon, 18 Mar 2019 23:57:10 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:message-id:from:to:subject; q=dns; s= default; b=rB5IovWiatB127Ga2hNVWINtuZibNnmHyqrn5clZg9sj2XFUJwmvk KmwRIJz51hGsQOTrRMFuA+ntntB765Uc94i+hkL+0g1D6jQCMDJrfmzIPJqa4Vsr jWMQFsTpLUpG9ERNjxevFRTIm/4M7Wm/KBbFcp7BjjHgPtE9t2Zk9s= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:message-id:from:to:subject; s=default; bh=eUBmnbYwgxftevz76TiHErFByao=; b=how1ZhZlxfUZe6lPx/Nc3FUtpqyJ PZFkGSGOyvNOBKU4AMd0W0H0nkXjIOXTCJzUnKnMlnsQsQLmM+9bi2Cv/DSJOKiw aEB6fZlcl81Z5xxM/WSgr/dDjV453EMVY56LiYNgdXLm7wikTNM1H8HSRtifsACc tcZxHjZ02yMsZn8= Received: (qmail 59133 invoked by alias); 18 Mar 2019 23:57:07 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 59124 invoked by uid 89); 18 Mar 2019 23:57:07 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mx1.redhat.com Date: Mon, 18 Mar 2019 19:57:03 -0400 Message-Id: From: DJ Delorie To: libc-alpha@sourceware.org Subject: proposal: nsswitch refactoring Red Hat has had a long-standing request to make nsswitch.conf reloadable. It's come up again recently, so I'm looking to see what it would take. After discussing this with Carlos a bit, I've broken the task into three phases. I'd like some feedback on what the community (i.e. us) thinks about my general direction on this, so I don't waste a lot of time. First, the data relating to the various shared objects that implement the name services (libnss_foo.so) needs to be split out of the data specific to nsswitch.conf's layout. Why? Because we still never unload shared objects, so that data is effectively "write once" and should never change. Separating it from the changable data makes sense. Second, the nsswitch-specific data should be "compartmentalized" somehow, so that we can reference count it, set aside the "old" copy when we load a "new" copy, and clean it up after we know that there are no further users of that data. There are two schools of thought here - one memory chunk with all the data in it, or spread out data with careful management of it. One chunk is easier to free up (just call free()) but has some overhead in packing the data into it. Spread out data is easier to understand and manipulate, but you have to be more careful about cleanup. The third phase is to consider expanding the syntax and functionality of nsswitch.conf. My "vision" on this is to compile the nsswitch logic into a tiny p-code, and centralize running it. That way, an API (like getpwnam()) need only set up some data (query arguments, etc), and pass said data and a callback function to this central logic handler, which calls the callback when it decides which shared object needs to be queried next. This p-code could include new actions like two-way branching, more interesting error handlers, etc. Note: I had considered at one point allowing nsswitch to choose handlers based on the query string itself, but feedback seems to be that *that* kind of logic should be, itself, in a shared object handler. I don't know what other kinds of "smarts" should be in nsswitch.conf itself, but I'm trying to consider future unknown additions :-) Thoughts?