9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* [9fans] 9p question
@ 2009-07-30 15:28 Venkatesh Srinivas
  2009-07-30 16:08 ` Russ Cox
  0 siblings, 1 reply; 5+ messages in thread
From: Venkatesh Srinivas @ 2009-07-30 15:28 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

Hi,

How come you can't TWalk along an open Fid?

Thanks,
-- vs



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [9fans] 9p question
  2009-07-30 15:28 [9fans] 9p question Venkatesh Srinivas
@ 2009-07-30 16:08 ` Russ Cox
  2009-07-30 16:30   ` Iruata Souza
  0 siblings, 1 reply; 5+ messages in thread
From: Russ Cox @ 2009-07-30 16:08 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

On Thu, Jul 30, 2009 at 8:28 AM, Venkatesh Srinivas<me@acm.jhu.edu> wrote:
> How come you can't TWalk along an open Fid?

In the original 9P protocol, that didn't make sense,
because walk always updated the fid it was starting from.
If you open a fid and then walk it elsewhere,
is it still open?  Is that an implicit close?
And the operation isn't needed by the Plan 9 kernel anyway,
so out it goes.

In the current 9P protocol, I think it would be fine to
allow a walk to start at an open fid as long as newfid
was being used to create a new fid.  This would
make it easy to implement fchdir on Unix.

Russ


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [9fans] 9p question
  2009-07-30 16:08 ` Russ Cox
@ 2009-07-30 16:30   ` Iruata Souza
  2009-07-30 20:44     ` Russ Cox
  0 siblings, 1 reply; 5+ messages in thread
From: Iruata Souza @ 2009-07-30 16:30 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

On Thu, Jul 30, 2009 at 1:08 PM, Russ Cox<rsc@swtch.com> wrote:
> On Thu, Jul 30, 2009 at 8:28 AM, Venkatesh Srinivas<me@acm.jhu.edu> wrote:
>> How come you can't TWalk along an open Fid?
>
> In the original 9P protocol, that didn't make sense,
> because walk always updated the fid it was starting from.
> If you open a fid and then walk it elsewhere,
> is it still open?  Is that an implicit close?
> And the operation isn't needed by the Plan 9 kernel anyway,
> so out it goes.
>
> In the current 9P protocol, I think it would be fine to
> allow a walk to start at an open fid as long as newfid
> was being used to create a new fid.  This would
> make it easy to implement fchdir on Unix.
>

it would surely make it easier for unix implementations. i have had
plenty of issues with that in o9fs.

but as yourself pointed out, what would that walk mean?

iru



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [9fans] 9p question
  2009-07-30 16:30   ` Iruata Souza
@ 2009-07-30 20:44     ` Russ Cox
  0 siblings, 0 replies; 5+ messages in thread
From: Russ Cox @ 2009-07-30 20:44 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

> it would surely make it easier for unix implementations. i have had
> plenty of issues with that in o9fs.
>
> but as yourself pointed out, what would that walk mean?

as i also pointed out, there's no problem if
the walk is creating a new fid.  it would be unopened.

russ


^ permalink raw reply	[flat|nested] 5+ messages in thread

* [9fans] 9p question
@ 2000-02-18 10:47 Roman
  0 siblings, 0 replies; 5+ messages in thread
From: Roman @ 2000-02-18 10:47 UTC (permalink / raw)


While  playing with u9fs and 9p I ask myself: Is there are any good reason that
each R-message contains fid ? I take a look at u9fs sources and have found 
that R-messages have exactly the same fid as T-messages. Is this a common
behavior and if yes, why do we need fids in R-messages at all ?

Thanks,
Roman.




^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2009-07-30 20:44 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-07-30 15:28 [9fans] 9p question Venkatesh Srinivas
2009-07-30 16:08 ` Russ Cox
2009-07-30 16:30   ` Iruata Souza
2009-07-30 20:44     ` Russ Cox
  -- strict thread matches above, loose matches on Subject: below --
2000-02-18 10:47 Roman

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).