> On Oct 18, 2017, at 4:35 AM, Alexey Dobriyan <adobriyan@xxxxxxxxx> wrote: > >> On 10/12/17, Andrei Vagin <avagin@xxxxxxxxxxxxx> 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? -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
