From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1751352AbdJRRr4 (ORCPT <rfc822;w@1wt.eu>);
        Wed, 18 Oct 2017 13:47:56 -0400
Received: from mail.kernel.org ([198.145.29.99]:52350 "EHLO mail.kernel.org"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1751069AbdJRRry (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 18 Oct 2017 13:47:54 -0400
DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B6A3521923
Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org
Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=luto@kernel.org
X-Google-Smtp-Source: ABhQp+QFIXz0F8Swll2uBP70Yfk+E3JqFkzU03VGCy77QzT2vyM3b4iAm60zJOaCmchlm9U35tiVmIZ8/84BVCChInY=
MIME-Version: 1.0
In-Reply-To: <CACVxJT_ZP=VAJQ_=D1JV0yt3bT_RZjtWTW61KcV5gCbhF8ixBw@mail.gmail.com>
References: <20170924200620.GA24368@avx2> <20171010220804.GA30735@outlook.office365.com>
 <20171011181234.GB2119@avx2> <20171012080608.GA23077@outlook.office365.com> <CACVxJT_ZP=VAJQ_=D1JV0yt3bT_RZjtWTW61KcV5gCbhF8ixBw@mail.gmail.com>
From: Andy Lutomirski <luto@kernel.org>
Date: Wed, 18 Oct 2017 10:47:32 -0700
X-Gmail-Original-Message-ID: <CALCETrW769=r4uXH2RqoQ0cQL2CakfupwAUM2_81Fr8Mo3JX=Q@mail.gmail.com>
Message-ID: <CALCETrW769=r4uXH2RqoQ0cQL2CakfupwAUM2_81Fr8Mo3JX=Q@mail.gmail.com>
Subject: Re: [1/2,v2] fdmap(2)
To: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Andrei Vagin <avagin@virtuozzo.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Linux API <linux-api@vger.kernel.org>,
        Randy Dunlap <rdunlap@infradead.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Djalal Harouni <tixxdz@gmail.com>,
        Alexey Gladkov <gladkov.alexey@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

> On Oct 18, 2017, at 4:35 AM, Alexey Dobriyan <adobriyan@gmail.com> wrote:
>
>> On 10/12/17, Andrei Vagin <avagin@virtuozzo.com> wrote:
>>
>> I'm agree with your points, but I think you choose a wrong set of data
>> to make an example of a new approach.
>>
>> You are talking a lot about statx, but for me it is unclear how fdmap
>> follows the idea of statx. Let's imagine that I want to extend fdmap to
>> return mnt_id for each file descriptor?
>
> fdmap() is standalone thing.
>
> Next step is to design fdinfo(2) (?) which uses descriptors from fdmap(2).
> Extending structures is done as usual: but version, add new fields to the end.
>

I very strongly disagree.  If you really want a new interface for
reading out information about other processes, design one that makes
sense as a whole.  Don't design it piecemeal. The last thing we need
is a crappy /proc alternative that covers a small fraction of use
cases.  And demonstrate that it actually has a material benefit over
fixing /proc.

Meanwhile, why not just fix /proc?