[9fans] fd2path(2)

[9fans] fd2path(2)

[William Ahern]

why not make the return value of fd2path() similar to SUSv3's snprintf()?
that is, return the length of the logical string. i've read a few archived
posts on this. one was to make the return value the remainder of the logical
length and the buffer length. another pointed out that inferno just returned
a malloc'd string on its own.

but, why force superfluous use of strlen()? the semantics of snprintf() seem
quite reasonable. in fact, i can't really figure out a down side... anybody?

- Bill

Re: [9fans] fd2path(2)

[rob pike, esq.]

> why not make the return value of fd2path() similar to SUSv3's snprintf()?
> that is, return the length of the logical string. i've read a few archived
> posts on this. one was to make the return value the remainder of the logical
> length and the buffer length. another pointed out that inferno just returned
> a malloc'd string on its own.

Perhaps it's a better interface, making it like read.  I don't
remember thinking about it, which probably means I just gave it the
default syscall return.  I do remember thinking about the NUL on the
end, which probably means I didn't think it was the same as read.

On the other hand, a quick grep shows most program just use the string
outright and strlen() is really cheap.  I suspect that between the two
of us we've spent more time talking about it than using strlen() on an
fd2path call will require in our lifetimes.

-rob

Re: [9fans] fd2path(2)

[William Ahern]

On Mon, May 05, 2003 at 09:18:55AM -0700, rob pike, esq. wrote:
> > why not make the return value of fd2path() similar to SUSv3's snprintf()?
> > that is, return the length of the logical string. i've read a few archived
> > posts on this. one was to make the return value the remainder of the logical
> > length and the buffer length. another pointed out that inferno just returned
> > a malloc'd string on its own.
>
> Perhaps it's a better interface, making it like read.  I don't
> remember thinking about it, which probably means I just gave it the
> default syscall return.  I do remember thinking about the NUL on the
> end, which probably means I didn't think it was the same as read.
>
> On the other hand, a quick grep shows most program just use the string
> outright and strlen() is really cheap.  I suspect that between the two
> of us we've spent more time talking about it than using strlen() on an
> fd2path call will require in our lifetimes.
>
> -rob

fair enough ;) i was just inquiring 'cause i'm re-creating cleanname() and
fd2path() on *bsd/linux for a little project of mine. i had the code written
(fname_normalize(char *, int, const char *), fname_get(int)), when i
discovered that plan9 already had an interface to do the same thing, and so
i figured i might as well copy the semantics (a tad more general, and
intuitive).

hmmmmm. does plan 9 have an interface for inquiring about file events? for
instance, on free/net/openbsd there is kqueue, which supports vnode events.
something similar on linux is DNOTIFY (dentry events). SGI has IMon (inode
monitor).

- Bill

Re: [9fans] fd2path(2)

[William Josephson]

On Mon, May 05, 2003 at 10:32:33AM -0700, William Ahern wrote:
> hmmmmm. does plan 9 have an interface for inquiring about file events? for
> instance, on free/net/openbsd there is kqueue, which supports vnode events.
> something similar on linux is DNOTIFY (dentry events). SGI has IMon (inode
> monitor).

No.  No select, either.  You can use libthread and ioprocs, though.
Or just use rfork() manually.

Re: [9fans] fd2path(2)

[rsc]

> hmmmmm. does plan 9 have an interface for inquiring about file events? for
> instance, on free/net/openbsd there is kqueue, which supports vnode events.
> something similar on linux is DNOTIFY (dentry events). SGI has IMon (inode
> monitor).

Plan 9 has no ``file events''.  Hence there is no interface for inquiring about them.

Re: [9fans] fd2path(2)

[William Ahern]

On Mon, May 05, 2003 at 02:12:37PM -0400, rsc@plan9.bell-labs.com wrote:
> > hmmmmm. does plan 9 have an interface for inquiring about file events? for
> > instance, on free/net/openbsd there is kqueue, which supports vnode events.
> > something similar on linux is DNOTIFY (dentry events). SGI has IMon (inode
> > monitor).
>
> Plan 9 has no ``file events''.  Hence there is no interface for inquiring about them.

apologies for the ignorant question. didn't think that one through....