From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15636 invoked by alias); 17 Apr 2015 16:29:50 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 14970 invoked by uid 89); 17 Apr 2015 16:29:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 17 Apr 2015 16:29:48 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t3HGTlPf028624 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Fri, 17 Apr 2015 12:29:47 -0400 Received: from blade.nx (ovpn-116-95.ams2.redhat.com [10.36.116.95]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t3HGTkWE004053; Fri, 17 Apr 2015 12:29:46 -0400 Received: by blade.nx (Postfix, from userid 1000) id 2107226410C; Fri, 17 Apr 2015 17:29:45 +0100 (BST) Date: Fri, 17 Apr 2015 16:29:00 -0000 From: Gary Benson To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: [PATCH 7/7] Implement vFile:setfs in gdbserver Message-ID: <20150417162944.GA16766@blade.nx> References: <1429186791-6867-1-git-send-email-gbenson@redhat.com> <1429186791-6867-8-git-send-email-gbenson@redhat.com> <553126FA.8030402@redhat.com> <20150417160524.GC14618@blade.nx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150417160524.GC14618@blade.nx> X-IsSubscribed: yes X-SW-Source: 2015-04/txt/msg00694.txt.bz2 Gary Benson wrote: > Pedro Alves wrote: > > So back on linux_ns_enter's naming --- > > > > I find the abstraction here a bit odd. It seems to be me that > > a function that does: > > > > #1 - select filesystem/namespace > > #2 - call foo > > #3 - restore filesystem/namespace > > > > should be a function in common code, and that the only > > target-specific part is selecting a filesystem/namespace. > > That is, simplifying, something like: > > > > /* Cause the filesystem to appear as it does to process PID and > > call FUNC with argument ARG, restoring the filesystem to its > > original state afterwards. Return nonzero if FUNC was called, > > zero otherwise (and set ERRNO). */ > > > > int > > call_with_fs_of (int pid, void (*func) (void *), void *arg) > > { > > int ret; > > > > target->select_fs (pid); > > ret = func (); > > target->select_fs (0); > > return ret; > > } > > > > Was there a reason this wasn't done that way? > > > > (maybe make target->select_fs() return the previous > > namespace, instead of passing 0 on the second > > call.) > > I'll have a go at doing it that way. It is kind of uglier doing it that way. It would need to look something more like this: struct cleanup **old_chain; if (target->select_fs (pid, &old_chain) != 0) return failure_return_value; ret = func (); do_cleanups (old_chain); return ret; linux_ns_enter has to open file descriptors for its own namespace and the one it wants to enter. Its own namespace file descriptor is what it needs to return, and it has to be held open: you can't flip namespace and then open your own descriptor to flip back. So the thing target->select_fs would have to return would be an open file descriptor (to then pass to target->restore_fs, which would take a file descriptor argument rather than an PID) but that would be putting a Linuxism into the target vector. Cheers, Gary -- http://gbenson.net/