Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1741434

Re: [PATCH 1/2 v2] fdmap(2)

From Alexey Dobriyan <adobriyan@gmail.com>
Newsgroups linux.kernel
Subject Re: [PATCH 1/2 v2] fdmap(2)
Date 2017-09-28 13:00 +0200
Message-ID <uuEHW-7Wb-37@gated-at.bofh.it> (permalink)
References <utlnX-4Gy-5@gated-at.bofh.it> <utwjn-3iD-11@gated-at.bofh.it> <uu3p0-jm-9@gated-at.bofh.it> <uum8j-4P4-63@gated-at.bofh.it> <uuBqG-5Tq-15@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


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.

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: [PATCH 1/2 v2] fdmap(2) Alexey Dobriyan <adobriyan@gmail.com> - 2017-09-26 21:10 +0200
  Re: [PATCH 1/2 v2] fdmap(2) Andy Lutomirski <luto@amacapital.net> - 2017-09-27 17:10 +0200
    Re: [PATCH 1/2 v2] fdmap(2) "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> - 2017-09-28 09:30 +0200
      Re: [PATCH 1/2 v2] fdmap(2) Alexey Dobriyan <adobriyan@gmail.com> - 2017-09-28 13:00 +0200
        Re: [PATCH 1/2 v2] fdmap(2) Andy Lutomirski <luto@kernel.org> - 2017-09-28 17:10 +0200
    Re: [PATCH 1/2 v2] fdmap(2) Alexey Dobriyan <adobriyan@gmail.com> - 2017-09-28 12:20 +0200

csiph-web