Re: [9fans] openat()

[wb . kloke]

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 with a user space implementation of the of the 
file lookup in namei() to get the benefits of a  proc specific namespace on my 
FreeBSDsystem, making Plan9 style bind and mount  available. This involved 
changing every  slash in a path name into  openat() calls for the splltted path 
components. pkeus.de/~wb/ns.c

Btw, there is another syscall in FreeBSD, which overlaps open() and openat() , 
namely fhopen(). This seems to isolate the namespace lookup operation and the 
actual file access.


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T675e737e776e5a9c-M6778010ee676c3e2eca3101e
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] openat()

[Alyssa M via 9fans]

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 how hard this would be...

devdup.c uses the bottom bit of the qid.path to distinguish #d/0 from #d/0ctl, 
so that would have to change to modulo 3 to allow the '5dir' virtual directory 
to be found when qid.path % 3 == 2, and twicefd would have to change to 
thricefd.
The idea is that a walk to #d/5dir would continue the walk at the cloned 
unopened directory fid that fd 5 is also holding in its chan (as I suggested in 
a previous post).

Currently, dupwalk just calls devwalk in dev.c, so we'd probably want to do the 
first step in dupwalk, doing fd2chan, much like dupopen does. Then call 
something else to walk from there. I'm not sure what though: walk() maybe?
I don't really know my way around the Plan 9 kernel, so this may not be the 
right way to do this. There are some scary creatures in dev.c, including a 
spikey backward pointing goto and some dark comments about contradictory rules 
and ugly bits... :o

You'd want to get the effect of having the directory open on fd 5 bound to 
#d/5dir without actually doing the bind (because you can't...).
Ideally if fd 5 is not a directory, then #d/5dir should not even appear.

The idea is that then:
int
openat (int fd, char *path, int mode)
{
char newpath[PATHSIZE];
sprintf (newpath, "#d/%ddir/%s", fd, path);
return open (newpath, mode);
}

could be a function in a library somewhere that would parcel it up in a more 
convenient form, and the rest of the *at suite could follow the same pattern. 
Maybe someone would want this for a version of APE emulating Linux?

So the idea is still partly-baked, and still very much in the realm of the 
hypothetical: 

Ron Minnich wrote:
"I don't want this to turn into a debate on the merits of openat"

I'm approaching this in the spirit of "if we had to implement this, how would 
we do it while inflicting the least harm"... :)
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T675e737e776e5a9c-M124c4e12c40240ab85dbdea0
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] openat()

[Alyssa M via 9fans]

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 appeared to make no measurable 
difference at all (though I don't know whether v9fs can take advantage of the 
*at capability).
Maybe there's some use case where it makes a more dramatic difference. My tests 
were not very scientific.
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T675e737e776e5a9c-M5f33ea51d2130dafe5918a21
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] openat()

[moody]

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 argument must be a fd to a directory , so the issue of walk 
not being able to use files is not relevant, but you still have the other 
walk(5) limitations on the source fid.

If you are instead just wanting something that has the interface of: 
openat(char *dir, char *file, mode) for the purpose of avoiding just the cd 
than open as you say. Than I don't see why you couldn't usually just combine 
the open path yourself before handing it to the kernel.

If we put aside the interface and just focus on it's ability to act as a method 
to cache a walk for reuse with multiple subsequent open's let's say than I 
still think the design of 9p gets in the way. The difference between walking 
first then being able to reuse the fid for further walks, and just always 
walking from the root is however many path elements being walked internally to 
the 9p server. So I imagine that the overhead of doing this partial walk first, 
pinging to the 9p server and back to userspace would only be cheaper if you 
were opening quite a large amount of files. Is that what you were getting at 
Ron?

In response to Bakul:

I don't think it's just an easy win at all. As mentioned already the act of 
getting whatever handle you choose from the 9p server and back to userspace as 
a method of reuse to prevent a couple of internal walks within the 9p server I 
think are not going to be favorable in performance.

Thanks,
moody


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T675e737e776e5a9c-M3c21a5ee93f83ca1650b537c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] openat()

[Bakul Shah via 9fans]

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 has nothing to do with plan9 but people explored some researchy ideas)On Apr 6, 2024, at 10:37 AM, ron minnich  wrote: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.

9fans
  / 9fans / see
discussions
  +
participants
  +
delivery options
Permalink

Re: [9fans] openat()

[Alyssa M via 9fans]

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? The open one could be used for read/write, etc, and the 
original could be used for subsequent walks.

Ron Minnich wrote:
"The question I had was, can I get the benefit of *at without doing 
what linux is doing, namely, for all system calls with a path, make an 
'...at' version.
I am guessing so, though I'm not sure it's as efficient."

Could you do something like
open ("/fd/5/as-dir/a/b/c", ...)
or
open ("#d/5/as-dir/a/b/c", ...)
where 5 is the file descriptor of an open directory, and "as-dir" is 
effectively bound to the directory it has open? 
The Linux docs make passing reference to "tricks involving /proc/../fd" which 
seems like a better idea than adding all those *at system calls...

... from the department of partly-baked ideas...
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T675e737e776e5a9c-M4f2926b33d54b9f6842c2078
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] openat()

[David Leimbach via 9fans]

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 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 likebind /dir /n/x and then just open /n/x/file... for a lot of files. This would work for any system call that takes a path.The question I had was, can I get the benefit of *at without doing what linux is doing, namely, for all system calls with a path, make an '...at' version.I am guessing so, though I'm not sure it's as efficient.On Fri, Apr 5, 2024 at 8:19 PM  wrote: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 cloning the fid) are specified. The fid must be valid in the current session and must not have been opened for I/O by an open or create message.

Since not every fid is eligible for being walked from, in order to implement opanat() in any way that would be better than just batching the fd2path and open would be to keep a "last directory" associated, like what we do with the string used to open it. Also worth mentioning that fd2path is not without its own problems, it's possible that the namespace has changed since the file has been opened so the same path may not work the second time. So tagging the last directory Chan would be "more correct", but I am not sure how useful this is.

Answering some other comments made:As I understand it from the rationale section on the
 linux man page, the call exists to avoid a race condition between 
checking that a directory exists and doing something to a path 
containing it. An additional motivator is providing the effect of 
additional current working directories notably for Linux threads (which 
presumably don't have their own. I think 'threads'  (processes that 
share memory) on Plan 9 do???).Each process has it's own current working directory:

% pwd
/home/moody
% @{cd /}
% pwd
% /home/moody
This is all based on the assumption that holding a file/directory open keeps it alive and in existence... which on Plan 9, I think it doesn't, does it? As I understand it, remove can remove a file or directory that is open, which is not like UNIX/Linux...
Depends on the file server implementation, I find that for more synthetic files they are indeed kept alive as long there is someone with a reference to the fid.
This is identifiable if all the cleanup happens on clunks(destroyfid in lib9p), which only happen when a fid's refcount hits zero.

For non-synthetic or more "disk" file servers the behavior can differ. Cwfs does not keep the data around, readers that attempt to read a deleted file, even if they already have a reference open to it will result in a phase error. However 9front's ramfs keeps the data around.

My test for this was as follows:win1% echo 'something' >/tmp/testwin2% win1% rm /tmp/test
# observe the error(if any) on win2So you really can't assume either case.Thanks,
moodyP.S.I apologize for the formatting, it seems my emails are not making it to the list when I attempt to send them from my mail server so I had to copy this response in to the web form.  I would like to figure out why if possible.

9fans
  / 9fans / see
discussions
  +
participants
  +
delivery options
Permalink

Re: [9fans] openat()

[ron minnich]

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... for a lot of files.

This would work for any system call that takes a path.

The question I had was, can I get the benefit of *at without doing what
linux is doing, namely, for all system calls with a path, make an '...at'
version.
I am guessing so, though I'm not sure it's as efficient.


On Fri, Apr 5, 2024 at 8:19 PM  wrote:

> 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 
> cloning the fid) are specified. The fid must be valid in the current session 
> and must not have been opened for I/O by an open or create message.
>
> Since not every fid is eligible for being walked from, in order to implement 
> opanat() in any way that would be better than just batching the fd2path and 
> open would be to keep a "last directory" associated, like what we do with the 
> string used to open it. Also worth mentioning that fd2path is not without its 
> own problems, it's possible that the namespace has changed since the file has 
> been opened so the same path may not work the second time. So tagging the 
> last directory Chan would be "more correct", but I am not sure how useful 
> this is.
>
> Answering some other comments made:
>
> As I understand it from the rationale section on the linux man page, the
> call exists to avoid a race condition between checking that a directory
> exists and doing something to a path containing it. An additional motivator
> is providing the effect of additional current working directories notably
> for Linux threads (which presumably don't have their own. I think
> 'threads'  (processes that share memory) on Plan 9 do???).
>
>
> Each process has it's own current working directory:
>
> % pwd
> /home/moody
> % @{cd /}
> % pwd
> % /home/moody
>
> This is all based on the assumption that holding a file/directory open keeps 
> it alive and in existence... which on Plan 9, I think it doesn't, does it? As 
> I understand it, remove can remove a file or directory that is open, which is 
> not like UNIX/Linux...
>
>
> Depends on the file server implementation, I find that for more synthetic
> files they are indeed kept alive as long there is someone with a reference
> to the fid. This is identifiable if all the cleanup happens on
> clunks(destroyfid in lib9p), which only happen when a fid's refcount hits
> zero. For non-synthetic or more "disk" file servers the behavior can
> differ. Cwfs does not keep the data around, readers that attempt to read a
> deleted file, even if they already have a reference open to it will result
> in a phase error. However 9front's ramfs keeps the data around.
>
> My test for this was as follows:
> win1% echo 'something' >/tmp/test
> win2%  win1% rm /tmp/test # observe the error(if any) on win2
>
> So you really can't assume either case.
>
>
> Thanks,
> moody
>
> P.S.
> I apologize for the formatting, it seems my emails are not making it to
> the list when I attempt to send them from my mail server so I had to copy
> this response in to the web form.  I would like to figure out why if
> possible.
> *9fans * / 9fans / see discussions
>  + participants
>  + delivery options
>  Permalink
> 
>

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T675e737e776e5a9c-M3c953ec4ad1db560805d02b3
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] openat()

[moody]

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 
cloning the fid) are specified. The fid must be valid in the current session 
and must not have been opened for I/O by an open or create message.

Since not every fid is eligible for being walked from, in order to implement 
opanat() in any way that would be better than just batching the fd2path and 
open would be to keep a "last directory" associated, like what we do with the 
string used to open it. Also worth mentioning that fd2path is not without its 
own problems, it's possible that the namespace has changed since the file has 
been opened so the same path may not work the second time. So tagging the last 
directory Chan would be "more correct", but I am not sure how useful this is.

Answering some other comments made:
> As I understand it from the rationale section on the
 linux man page, the call exists to avoid a race condition between 
checking that a directory exists and doing something to a path 
containing it. An additional motivator is providing the effect of 
additional current working directories notably for Linux threads (which 
presumably don't have their own. I think 'threads'  (processes that 
share memory) on Plan 9 do???).

Each process has it's own current working directory:

% pwd
/home/moody
% @{cd /}
% pwd
% /home/moody
> This is all based on the assumption that holding a file/directory open keeps 
> it alive and in existence... which on Plan 9, I think it doesn't, does it? As 
> I understand it, remove can remove a file or directory that is open, which is 
> not like UNIX/Linux...
> 

Depends on the file server implementation, I find that for more synthetic files 
they are indeed kept alive as long there is someone with a reference to the fid.
This is identifiable if all the cleanup happens on clunks(destroyfid in lib9p), 
which only happen when a fid's refcount hits zero.

For non-synthetic or more "disk" file servers the behavior can differ. Cwfs 
does not keep the data around, readers that attempt to read a deleted file, 
even if they already have a reference open to it will result in a phase error. 
However 9front's ramfs keeps the data around.



My test for this was as follows:
win1% echo 'something' >/tmp/test
win2% https://9fans.topicbox.com/groups/9fans/T675e737e776e5a9c-M8abb414d4890eefbbbe7ef96
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] openat()

[Gorka Guardiola]

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
> service?
>

Yes, this is what I understood between my first answer and the second. You
don't want to rewalk the path and you already have the fid with the
directory part walked in the chan of dirfd. I think that if you walk the
remaining path from that chan (cloning it) you preserve the same guarantees
provided by openat.



> As I understand it from the rationale section on the linux man page, the
> call exists to avoid a race condition between checking that a directory
> exists and doing something to a path containing it. An additional motivator
> is providing the effect of additional current working directories notably
> for Linux threads (which presumably don't have their own. I think
> 'threads'  (processes that share memory) on Plan 9 do???).
>
> This is all based on the assumption that holding a file/directory open
> keeps it alive and in existence... which on Plan 9, I think it doesn't,
> does it? As I understand it, remove can remove a file or directory that is
> open, which is not like UNIX/Linux...
>
> Sorry, I'm just trying to understand the question.
>
>
> *9fans * / 9fans / see discussions
>  + participants
>  + delivery options
>  Permalink
> 
>

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T675e737e776e5a9c-M1c147cadc76c65a4fbb9aa76
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] openat()

[Alyssa M via 9fans]

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 page, the call 
exists to avoid a race condition between checking that a directory exists and 
doing something to a path containing it. An additional motivator is providing 
the effect of additional current working directories notably for Linux threads 
(which presumably don't have their own. I think 'threads'  (processes that 
share memory) on Plan 9 do???).

This is all based on the assumption that holding a file/directory open keeps it 
alive and in existence... which on Plan 9, I think it doesn't, does it? As I 
understand it, remove can remove a file or directory that is open, which is not 
like UNIX/Linux...

Sorry, I'm just trying to understand the question.


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T675e737e776e5a9c-M77db5ff0993c7da831142e92
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] openat()

[Bakul Shah via 9fans]

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: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 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 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, 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 few ideas but I'm more interested in your ideas.
> 
> Thanks
> 
> 9fans  / 9fans / see discussions 
>  + participants 
>  + delivery options 
> Permalink 
> 

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T675e737e776e5a9c-M0efc38028930341e0db8f794
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] openat()

[ron minnich]

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 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 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, 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 few ideas but I'm more interested in your ideas.

 Thanks

>>> *9fans * / 9fans / see discussions
>  + participants
>  + delivery options
>  Permalink
> 
>

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T675e737e776e5a9c-M0445ed55bee993d4cfbd3450
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] openat()

[Gorka Guardiola]

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 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, 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 few ideas but I'm more interested in your ideas.
>>>
>>> Thanks
>>> *9fans * / 9fans / see discussions
>>>  + participants
>>>  + delivery options
>>>  Permalink
>>> 
>>>

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T675e737e776e5a9c-M43026122c2960e83ab07e80b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] openat()

[Gorka Guardiola]

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, 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 few ideas but I'm more interested in your ideas.
>>
>> Thanks
>> *9fans * / 9fans / see discussions
>>  + participants
>>  + delivery options
>>  Permalink
>> 
>>

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T675e737e776e5a9c-M0fdda14083bc18f0e59c774f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] openat()

[Gorka Guardiola]

¿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 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 few ideas but I'm more interested in your ideas.
>
> Thanks
> *9fans * / 9fans / see discussions
>  + participants
>  + delivery options
>  Permalink
> 
>

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T675e737e776e5a9c-M9023f4cd7b382f26249c302b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] openat()

[ron minnich]

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 few ideas but I'm more interested in your ideas.

Thanks

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T675e737e776e5a9c-Mf6adaa9f7c07518efcb7a293
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription