All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexey Dobriyan <adobriyan@gmail.com>
To: mtk.manpages@gmail.com
Cc: Andy Lutomirski <luto@amacapital.net>,
	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>,
	Aliaksandr Patseyenak <Aliaksandr_Patseyenak1@epam.com>,
	Tatsiana Brouka <Tatsiana_Brouka@epam.com>
Subject: Re: [PATCH 1/2 v2] fdmap(2)
Date: Thu, 28 Sep 2017 12:55:49 +0200	[thread overview]
Message-ID: <CACVxJT_B4m-O66haETWkFVx5AgGqDbM-K-53odJ0bRp0_2xhrQ@mail.gmail.com> (raw)
In-Reply-To: <CAKgNAkh4LsGEQOconE8vF9xD1ix1+MPqvrOa0ozvgjB+S2tQPw@mail.gmail.com>

On 9/28/17, Michael Kerrisk (man-pages) <mtk.manpages@gmail.com> wrote:
> On 27 September 2017 at 17:03, Andy Lutomirski <luto@amacapital.net> wrote:

>>> The idea is to start process. In ideal world, only bynary system calls
>>> would exist and shells could emulate /proc/* same way bash implement
>>> /dev/tcp
>>
>> Then start the process by doing it for real and making it obviously
>> useful.  We should not add a pair of vaguely useful, rather weak
>> syscalls just to start a process of modernizing /proc.

Before doing it for real it would be nice to have at least a nod
from people in charge that syscalls which return binary
information are OK. Otherwise some EIATF guy will just say
"NAK /proc is fine, it always was fine".

Or look from another angle: sched_setaffinity exists but there is
no /proc counterpart, shells must use taskset(1) and world didn't end.

> I concur.
>
> Alexey, you still have not wxplained who specifically needs this
> right now, and how, precisely, they plan to use the new system calls.
> It is all very arm-wavey so far.

It is not if you read even example program in the original patch.
Any program which queries information about file descriptors
will benefit both in CPU and memory usage.

void closefrom(int start)
{
	int fd[1024];
	int n;

	while ((n = fdmap(0, fd, sizeof(fd)/sizeof(fd[0]), start)) > 0) {
		unsigned int i;

		for (i = 0; i < n; i++)
			close(fd[i]);

		start = fd[n - 1] + 1;
	}
}

CRIU naturally to know everything about descriptors of target processes:
It does:

int predump_task_files(int pid)
{
        struct dirent *de;
        DIR *fd_dir;
        int ret = -1;

        pr_info("Pre-dump fds for %d)\n", pid);

        fd_dir = opendir_proc(pid, "fd");
        if (!fd_dir)
                return -1;

        while ((de = readdir(fd_dir))) {
                if (dir_dots(de))
                        continue;

                if (predump_one_fd(pid, atoi(de->d_name)))
                        goto out;
        }

        ret = 0;
out:
        closedir(fd_dir);
        return ret;
}

which is again inefficient.

  reply	other threads:[~2017-09-28 10:55 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-24 20:06 [PATCH 1/2 v2] fdmap(2) Alexey Dobriyan
2017-09-24 20:06 ` Alexey Dobriyan
2017-09-24 20:08 ` [PATCH v2 2/2] pidmap(2) Alexey Dobriyan
2017-09-24 20:08   ` Alexey Dobriyan
2017-09-24 21:27   ` Andy Lutomirski
2017-09-24 21:27     ` Andy Lutomirski
2017-09-26 18:46     ` Alexey Dobriyan
2017-09-26 18:46       ` Alexey Dobriyan
2017-09-27 15:04       ` Andy Lutomirski
2017-09-25  7:43   ` Michael Kerrisk (man-pages)
2017-09-25 10:47   ` Djalal Harouni
2017-09-25 10:47     ` Djalal Harouni
2017-09-26  5:44   ` kbuild test robot
2017-09-26  5:44     ` kbuild test robot
2017-09-24 21:31 ` [PATCH 1/2 v2] fdmap(2) Andy Lutomirski
2017-09-26 18:43   ` Alexey Dobriyan
2017-09-26 18:43     ` Alexey Dobriyan
2017-09-25  7:42 ` Michael Kerrisk (man-pages)
2017-09-25  7:42   ` Michael Kerrisk (man-pages)
2017-09-26 19:00   ` Alexey Dobriyan
2017-09-26 19:00     ` Alexey Dobriyan
2017-09-27 15:03     ` Andy Lutomirski
2017-09-27 15:03       ` Andy Lutomirski
2017-09-28  7:26       ` Michael Kerrisk (man-pages)
2017-09-28  7:26         ` Michael Kerrisk (man-pages)
2017-09-28 10:55         ` Alexey Dobriyan [this message]
2017-09-28 15:02           ` Andy Lutomirski
2017-09-28 15:02             ` Andy Lutomirski
2017-10-11 17:37             ` Alexey Dobriyan
2017-09-28 10:10       ` Alexey Dobriyan
2017-09-28 10:10         ` Alexey Dobriyan
2017-10-23  9:29   ` Pavel Machek
2017-10-23  9:29     ` Pavel Machek
2017-10-25 12:45     ` Alexey Dobriyan
2017-10-25 12:45       ` Alexey Dobriyan
2017-10-25 13:48       ` Pavel Machek
2017-09-26  4:25 ` kbuild test robot
2017-10-10 22:08 ` [1/2,v2] fdmap(2) Andrei Vagin
2017-10-10 22:08   ` Andrei Vagin
2017-10-11 18:12   ` Alexey Dobriyan
2017-10-12  8:06     ` Andrei Vagin
2017-10-12  8:06       ` Andrei Vagin
2017-10-18 11:35       ` Alexey Dobriyan
2017-10-18 11:35         ` Alexey Dobriyan
2017-10-18 17:47         ` Andy Lutomirski
2017-10-19 15:34           ` Alexey Dobriyan
2017-10-20  7:48             ` Greg KH
2017-10-25 13:11               ` Alexey Dobriyan
2017-10-25 13:11                 ` Alexey Dobriyan
2017-10-26  7:53             ` Andy Lutomirski
2017-10-26  7:53               ` Andy Lutomirski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CACVxJT_B4m-O66haETWkFVx5AgGqDbM-K-53odJ0bRp0_2xhrQ@mail.gmail.com \
    --to=adobriyan@gmail.com \
    --cc=Aliaksandr_Patseyenak1@epam.com \
    --cc=Tatsiana_Brouka@epam.com \
    --cc=akpm@linux-foundation.org \
    --cc=gladkov.alexey@gmail.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=mtk.manpages@gmail.com \
    --cc=rdunlap@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=tixxdz@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.