Bug fix for getcwd()

6 views
Skip to first unread message

Kevin Klues

unread,
Jul 28, 2015, 12:09:28 AM7/28/15
to akaros
The following changes since commit 25d30420d7e79f0505ca1fd33e6e49aea619dd79:

Fixes LD_LIBRARY_PATH typo (2015-07-27 11:47:38 -0400)

are available in the git repository at:

g...@github.com:brho/akaros.git klueska-minor-bug-fixes

for you to fetch changes up to 6de6b310f5aadc9636fd57a40b78d8da439c4095:

Retval now set properly on successful sys_getcwd (2015-07-27 21:04:19 -0700)

----------------------------------------------------------------
Kevin Klues (1):
Retval now set properly on successful sys_getcwd

kern/src/syscall.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)

barret rhoden

unread,
Jul 28, 2015, 8:44:16 AM7/28/15
to aka...@googlegroups.com
On 2015-07-27 at 21:09 Kevin Klues wrote:
> Retval now set properly on successful sys_getcwd

Does Go require this behavior? I wanted to keep getcwd and fd2path
returning in a similar style. In this case, it was -1 on error, 0 on
success. In Plan 9, fd2path returns 0. In glibc, we have no real
restrictions, since we write the userland getcwd() (which returns
char*).

Anyway, we can do either, but I was erring on the side of the simplest
for the kernel. I know Linux's raw interface returns the length of the
buffer (+1 for the \0), so we can do that if it'll make life easier.

Barret


Kevin Klues

unread,
Jul 28, 2015, 10:10:46 AM7/28/15
to aka...@googlegroups.com
It doesn't require it, necessarily (I can probably just do the strlen inside go itself). I just didn't realize / forgot that the semantics had changed, so thought it was a bug. Either way, we should probably cave the strlen calculation instead of calling it 3 separate times.
--
~Kevin

Kevin Klues

unread,
Jul 28, 2015, 12:37:58 PM7/28/15
to aka...@googlegroups.com
I was able to fix this relatively simply on the go side of things, so
no kernel change is necessary. The relevant commit is here, if you're
interested:

https://github.com/klueska/go-akaros/commit/c9809df6251bf3dab65d3c86d3e2199d231ce4d3

--
~Kevin

Barret Rhoden

unread,
Jul 28, 2015, 12:58:17 PM7/28/15
to aka...@googlegroups.com
On 2015-07-28 at 09:37 Kevin Klues <klu...@gmail.com> wrote:
> I was able to fix this relatively simply on the go side of things, so
> no kernel change is necessary. The relevant commit is here, if you're
> interested:
>
> https://github.com/klueska/go-akaros/commit/c9809df6251bf3dab65d3c86d3e2199d231ce4d3

cool.

out of curiosity, does Getcwd() ever return n < 0 when there is *not*
an error?

> On Tue, Jul 28, 2015 at 7:10 AM, Kevin Klues <klu...@gmail.com>
> wrote:
> > Either way, we should probably cave the strlen calculation instead
> > of calling it 3 separate times.

yeah, that's a bit excessive. though at runtime, we only call it
twice! =)

barret


Kevin Klues

unread,
Jul 28, 2015, 1:08:15 PM7/28/15
to akaros
> out of curiosity, does Getcwd() ever return n < 0 when there is *not*
> an error?

Yeah, I thought this might be able to be removed now.
It used to have problems (due to VFS vs. 9ns issues, where we would
get an errstr, but no errno), but I haven't verified that this is the
case still.

>
>> On Tue, Jul 28, 2015 at 7:10 AM, Kevin Klues <klu...@gmail.com>
>> wrote:
>> > Either way, we should probably cave the strlen calculation instead
>> > of calling it 3 separate times.
>
> yeah, that's a bit excessive. though at runtime, we only call it
> twice! =)
>
> barret
>

--
~Kevin

Reply all
Reply to author
Forward
0 new messages