[9fans] openat()

[9fans] openat()

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 591 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1108 bytes --]

Re: [9fans] openat()

[Gorka Guardiola]

[-- Attachment #1: Type: text/plain, Size: 1119 bytes --]

¿Isn't that fd2path, strcat and open?
Or am I misunderstanding something?

On Fri, Apr 5, 2024, 21:51 ron minnich <rminnich@gmail.com> 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 <https://9fans.topicbox.com/latest>* / 9fans / see discussions
> <https://9fans.topicbox.com/groups/9fans> + participants
> <https://9fans.topicbox.com/groups/9fans/members> + delivery options
> <https://9fans.topicbox.com/groups/9fans/subscription> Permalink
> <https://9fans.topicbox.com/groups/9fans/T675e737e776e5a9c-Mf6adaa9f7c07518efcb7a293>
>

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

[-- Attachment #2: Type: text/html, Size: 1545 bytes --]

Re: [9fans] openat()

[Gorka Guardiola]

[-- Attachment #1: Type: text/plain, Size: 1299 bytes --]

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 <paurea@gmail.com> wrote:

> ¿Isn't that fd2path, strcat and open?
> Or am I misunderstanding something?
>
> On Fri, Apr 5, 2024, 21:51 ron minnich <rminnich@gmail.com> 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 <https://9fans.topicbox.com/latest>* / 9fans / see discussions
>> <https://9fans.topicbox.com/groups/9fans> + participants
>> <https://9fans.topicbox.com/groups/9fans/members> + delivery options
>> <https://9fans.topicbox.com/groups/9fans/subscription> Permalink
>> <https://9fans.topicbox.com/groups/9fans/T675e737e776e5a9c-Mf6adaa9f7c07518efcb7a293>
>>

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

[-- Attachment #2: Type: text/html, Size: 2017 bytes --]

Re: [9fans] openat()

[Gorka Guardiola]

[-- Attachment #1: Type: text/plain, Size: 1606 bytes --]

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 <paurea@gmail.com> 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 <paurea@gmail.com> wrote:
>
>> ¿Isn't that fd2path, strcat and open?
>> Or am I misunderstanding something?
>>
>> On Fri, Apr 5, 2024, 21:51 ron minnich <rminnich@gmail.com> 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 <https://9fans.topicbox.com/latest>* / 9fans / see discussions
>>> <https://9fans.topicbox.com/groups/9fans> + participants
>>> <https://9fans.topicbox.com/groups/9fans/members> + delivery options
>>> <https://9fans.topicbox.com/groups/9fans/subscription> Permalink
>>> <https://9fans.topicbox.com/groups/9fans/T675e737e776e5a9c-Mf6adaa9f7c07518efcb7a293>
>>>

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

[-- Attachment #2: Type: text/html, Size: 2611 bytes --]

Re: [9fans] openat()

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 1823 bytes --]

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 <paurea@gmail.com> 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 <paurea@gmail.com> 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 <paurea@gmail.com> wrote:
>>
>>> ¿Isn't that fd2path, strcat and open?
>>> Or am I misunderstanding something?
>>>
>>> On Fri, Apr 5, 2024, 21:51 ron minnich <rminnich@gmail.com> 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 <https://9fans.topicbox.com/latest>* / 9fans / see discussions
> <https://9fans.topicbox.com/groups/9fans> + participants
> <https://9fans.topicbox.com/groups/9fans/members> + delivery options
> <https://9fans.topicbox.com/groups/9fans/subscription> Permalink
> <https://9fans.topicbox.com/groups/9fans/T675e737e776e5a9c-M43026122c2960e83ab07e80b>
>

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

[-- Attachment #2: Type: text/html, Size: 3158 bytes --]

Re: [9fans] openat()

[Bakul Shah via 9fans]

[-- Attachment #1: Type: text/plain, Size: 2072 bytes --]

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 <rminnich@gmail.com> 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 <paurea@gmail.com <mailto:paurea@gmail.com>> 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 <paurea@gmail.com <mailto:paurea@gmail.com>> 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 <paurea@gmail.com <mailto:paurea@gmail.com>> wrote:
>>>> ¿Isn't that fd2path, strcat and open?
>>>> Or am I misunderstanding something?
>>>> 
>>>> On Fri, Apr 5, 2024, 21:51 ron minnich <rminnich@gmail.com <mailto:rminnich@gmail.com>> 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 <https://9fans.topicbox.com/latest> / 9fans / see discussions <https://9fans.topicbox.com/groups/9fans> + participants <https://9fans.topicbox.com/groups/9fans/members> + delivery options <https://9fans.topicbox.com/groups/9fans/subscription>Permalink <https://9fans.topicbox.com/groups/9fans/T675e737e776e5a9c-M0445ed55bee993d4cfbd3450>

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

[-- Attachment #2: Type: text/html, Size: 3709 bytes --]

Re: [9fans] openat()

[Alyssa M via 9fans]

[-- Attachment #1: Type: text/plain, Size: 1198 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1851 bytes --]

Re: [9fans] openat()

[Gorka Guardiola]

[-- Attachment #1: Type: text/plain, Size: 2009 bytes --]

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 <https://9fans.topicbox.com/latest>* / 9fans / see discussions
> <https://9fans.topicbox.com/groups/9fans> + participants
> <https://9fans.topicbox.com/groups/9fans/members> + delivery options
> <https://9fans.topicbox.com/groups/9fans/subscription> Permalink
> <https://9fans.topicbox.com/groups/9fans/T675e737e776e5a9c-M77db5ff0993c7da831142e92>
>

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

[-- Attachment #2: Type: text/html, Size: 2787 bytes --]

Re: [9fans] openat()

[moody]

[-- Attachment #1: Type: text/plain, Size: 3111 bytes --]

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% </tmp/test { sleep 10; cat }
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
Permalink: https://9fans.topicbox.com/groups/9fans/T675e737e776e5a9c-M8abb414d4890eefbbbe7ef96
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 4135 bytes --]

Re: [9fans] openat()

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 4230 bytes --]

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 <moody@posixcafe.org> 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% </tmp/test { sleep 10; cat }
> 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 <https://9fans.topicbox.com/latest>* / 9fans / see discussions
> <https://9fans.topicbox.com/groups/9fans> + participants
> <https://9fans.topicbox.com/groups/9fans/members> + delivery options
> <https://9fans.topicbox.com/groups/9fans/subscription> Permalink
> <https://9fans.topicbox.com/groups/9fans/T675e737e776e5a9c-M8abb414d4890eefbbbe7ef96>
>

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

[-- Attachment #2: Type: text/html, Size: 5118 bytes --]

Re: [9fans] openat()

[David Leimbach via 9fans]

[-- Attachment #1: Type: text/html, Size: 5692 bytes --]

Re: [9fans] openat()

[Bakul Shah via 9fans]

[-- Attachment #1: Type: text/html, Size: 1787 bytes --]

Re: [9fans] openat()

[Alyssa M via 9fans]

[-- Attachment #1: Type: text/plain, Size: 1287 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2112 bytes --]

Re: [9fans] openat()

[moody]

[-- Attachment #1: Type: text/plain, Size: 1939 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2843 bytes --]

Re: [9fans] openat()

[Alyssa M via 9fans]

[-- Attachment #1: Type: text/plain, Size: 758 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1299 bytes --]

Re: [9fans] openat()

[Alyssa M via 9fans]

[-- Attachment #1: Type: text/plain, Size: 2408 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 3594 bytes --]

Re: [9fans] openat()

[wb.kloke]

[-- Attachment #1: Type: text/plain, Size: 1029 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1715 bytes --]