(many months pass...)
I've recently been doing something a bit related:
While I've been refitting my old Linux 9P server, I decided to altered it to
use openat(2), and the other fd-relative *at calls. It used to keep an absolute
pathname string with each FID, so would start a file system walk f
Some replies seem to hold openat() for superfluous. In fact, IMHO the
traditional syscall open() should be deprecated.
In FreeBSD at least, the libc open() does in fact use the real thing
__sys_openat(). in /usr/src/lib/libc/sys/open.c
via the interposing table.
Some days ago, I experimented w
I left the oven on for my partly-baked idea.
I'm now thinking that with fd 5 as an example:
open ("#d/5dir/a/b/c", ...)
might be a practical way to do this (the syntax I suggested earlier would
require walking from a file, which wouldn't be sensible).
So I went snorkeling in the kernel to see
Well I got curious, and wrote a test program for my Linux RPi:
Doing the equivalent of what du(1) does (a recursive tree walk statting every
file) seemed to be about 15% faster with openat/fstatat than with open/lstat.
This was on a local drive (SD card).
Over 9p to my Plan 9 RPi from Linux it a
In response to Ron's mail. Still can not reply from my mail server.
I still don't quite understand what you are getting at.
I was focusing up on the linux interface (ie openat(int fd, char *path, int
flags, ...)) mapping of open fd to path. I see now as well that openat
specifies that the argum
Faster for any command that operates on dir trees such as diff, du, rm, tar.When I first looked at plan9, I was a bit surprised its open *didn’t* workthis way! May be because of this earlier thread on comp.unix.wizardshttps://groups.google.com/g/comp.unix.wizards/c/i8vapj9BAqs/m/FlNUK705I0UJ (which
Moody wrote:
"What you _would_ want for this would be the ability to walk from the existing
fd, however the limits of 9p walk make this a bit impossible to implement in a
great way in my opinion. "
Maybe the chan could keep two fids: the original walked fid, and an opened
clone of that fid? Th
Depending on the implementation of the file system, openat vs open can be more efficient if there’s a lot of metadata locking for file creation.Sent from my iPhoneOn Apr 6, 2024, at 1:36 PM, ron minnich wrote:openat gives you the effect of 'cd path; open file' without having to cd. I don't see a
openat gives you the effect of 'cd path; open file' without having to cd. I
don't see a lot of benefit to it unless you're opening a lot of files at
that path.
My first reaction, assuming you have a lot of files in that directory, was
something like
bind /dir /n/x and then just open /n/x/file... f
My two cents on this:
What you _would_ want for this would be the ability to walk from the existing
fd, however the limits of 9p walk make this a bit impossible to implement in a
great way in my opinion. From walk(5):
The fid must represent a directory unless zero path name elements(for just
c
On Fri, Apr 5, 2024, 23:49 Alyssa M via 9fans <9fans@9fans.net> wrote:
> Are you thinking narrowly about "What changes to the Plan 9 kernel would
> you make to emulate the Linux openat() system call" or more generally about
> "How would you design a facility for plan 9 that provides an equivalent
Are you thinking narrowly about "What changes to the Plan 9 kernel would you
make to emulate the Linux openat() system call" or more generally about "How
would you design a facility for plan 9 that provides an equivalent service?
As I understand it from the rationale section on the linux man pag
To me this sounds very similar to open() given a path relative to your current
working directory.
> On Apr 5, 2024, at 2:22 PM, ron minnich wrote:
>
> not so much what I want, I'm curious about ideas people have about
> implementing it that I would not think of.
>
> On Fri, Apr 5, 2024 at 1:3
not so much what I want, I'm curious about ideas people have about
implementing it that I would not think of.
On Fri, Apr 5, 2024 at 1:38 PM Gorka Guardiola wrote:
> Hmm sorry. Now I see what you want. Not to rewalk. You can use the chan of
> the dirfd and walk just the remainder cloning it and
Hmm sorry. Now I see what you want. Not to rewalk. You can use the chan of
the dirfd and walk just the remainder cloning it and creating a new one.
That way the openat provides the guarantees you want.
On Fri, Apr 5, 2024, 22:15 Gorka Guardiola wrote:
> I mean, if you want a new syscall jus copy
I mean, if you want a new syscall jus copy or call the implementation of
these.
On Fri, Apr 5, 2024, 22:12 Gorka Guardiola wrote:
> ¿Isn't that fd2path, strcat and open?
> Or am I misunderstanding something?
>
> On Fri, Apr 5, 2024, 21:51 ron minnich wrote:
>
>> One of the folks I worked with,
¿Isn't that fd2path, strcat and open?
Or am I misunderstanding something?
On Fri, Apr 5, 2024, 21:51 ron minnich wrote:
> One of the folks I worked with, when we pulled a big chunk of plan 9 into
> akaros, commented that he had implemented openat on akaros.
>
> I don't want this to turn into a d
One of the folks I worked with, when we pulled a big chunk of plan 9 into
akaros, commented that he had implemented openat on akaros.
I don't want this to turn into a debate on the merits of openat; I am more
curious: if you went to implement openat on Plan 9, how would you go about
it? I have a f
18 matches
Mail list logo
