3 grammar
source | link

The mmap syscall needs a fd as parameter, but when you close that fd, the mmap is still alive in the process's memory address space.

SoTherefore keeping aan mmap doesn't need aan opened fd. So, so why dose Linux only support createcreating an mmap of a file using a fd of it, but not path of ita file-name-path? Wouldn't it be nice if we can have a mmapat syscall just like openat and execveat?

If mmap creates an extra reference to that file, why can't we have a mmapat which atomically creates such an reference at the first time without take an fd of the process then release it later.

Is there any historical or security reason for not having such syscall on Linux kernel?

The mmap syscall needs a fd as parameter, but when you close that fd, the mmap still alive in the process's memory address space.

So keeping a mmap doesn't need a opened fd. So why Linux only support create mmap of a file using a fd of it but not path of it? Wouldn't it be nice if we can have a mmapat syscall just like openat and execveat?

If mmap creates an extra reference to that file, why can't we have a mmapat which atomically creates such an reference at the first time without take an fd of the process then release it later.

Is there any historical or security reason for not having such syscall on Linux kernel?

The mmap syscall needs a fd as parameter, but when you close that fd, the mmap is still alive in the process's memory address space.

Therefore keeping an mmap doesn't need an opened fd, so why dose Linux only support creating an mmap of a file using a fd, but not a file-name-path? Wouldn't it be nice if we can have a mmapat syscall just like openat and execveat?

If mmap creates an extra reference to that file, why can't we have a mmapat which atomically creates such an reference at the first time without take an fd of the process then release it later.

Is there any historical or security reason for not having such syscall on Linux kernel?

2 added 292 characters in body
source | link

The mmap syscall needs a fd as parameter, but when you close that fd, the mmap still alive in the process's memory address space.

So keeping a mmap doesn't need a opened fd. So why Linux only support create mmap of a file using a fd of it but not path of it? Wouldn't it be nice if we can have a mmapat syscall just like openat and execveat?

If mmap creates an extra reference to that file, why can't we have a mmapat which atomically creates such an reference at the first time without take an fd of the process then release it later.

Is there any historical or security reason for not having such syscall on Linux kernel?

The mmap syscall needs a fd as parameter, but when you close that fd, the mmap still alive in the process's memory address space.

So keeping a mmap doesn't need a opened fd. So why Linux only support create mmap of a file using a fd of it but not path of it? Wouldn't it be nice if we can have a mmapat syscall just like openat and execveat?

The mmap syscall needs a fd as parameter, but when you close that fd, the mmap still alive in the process's memory address space.

So keeping a mmap doesn't need a opened fd. So why Linux only support create mmap of a file using a fd of it but not path of it? Wouldn't it be nice if we can have a mmapat syscall just like openat and execveat?

If mmap creates an extra reference to that file, why can't we have a mmapat which atomically creates such an reference at the first time without take an fd of the process then release it later.

Is there any historical or security reason for not having such syscall on Linux kernel?

1
source | link

Why doesn't Linux support mmap by path?

The mmap syscall needs a fd as parameter, but when you close that fd, the mmap still alive in the process's memory address space.

So keeping a mmap doesn't need a opened fd. So why Linux only support create mmap of a file using a fd of it but not path of it? Wouldn't it be nice if we can have a mmapat syscall just like openat and execveat?