[openbeos] Re: Ghost in the machine
- From: "Manuel Jesus Petit de Gabriel" <freston@xxxxxxxxxxx>
- To: <openbeos@xxxxxxxxxxxxx>
- Date: Sat, 6 Jul 2002 14:12:06 -0700
I don't know how much that code has deviated from the original newos kernel
(i suspect that
very little.) In that case:
i) there exist two sys_getcwd(): the syscall in libc.so and the core
implementation in the kernel
ii) libc.so::sys_getcwd -> kernel::syscall dispatcher ->
kernel::user_getcwd -> kernel:: sys_getcwd()
iii) sys_getcwd(), in either case, does not return a pointer but an
error code. As usual
error_code == 0 success
error_code < 0 failure
iv) header files are your friend :-) look in
include/libc/sys/syscall.h
manuel,
----- Original Message -----
From: "Daniel Reinhold" <danielr@xxxxxxxxxxxxx>
To: "Public OBOS mailing list" <openbeos@xxxxxxxxxxxxx>
Sent: Saturday, July 06, 2002 11:51 AM
Subject: [openbeos] Ghost in the machine
> Before I checked in my pwd fix, I did some tests to see that everything
> was both hunky and dory. While doing this, I uncovered a mystery. At
> least, it's a mystery to me. Perhaps one of you guys can enlighten me
> on this.
>
> The shell command cmd_pwd() calls sys_getcwd(). The sys_getcwd()
> function should return NULL on failure, a pointer to the filled buffer
> on success. But the cmd_pwd() function that called it was using NULL as
> success and a pointer to the buf as failure -- completely backward.
>
> How funny, I thought. I'll fix that. But the fix screwed it up. So I
> went back to the vfs.c file and looked at the sys_getcwd() function. It
> seemed to be returning a pointer to buf on success and NULL on failure,
> just like it should. But I tried rearranging the code a bit. No
> difference. No matter what I did, the shell function would not work
> unless I used NULL for success -- reverse of what it should be. But
> that's not how the sys_getcwd() in vfs.c worked. Wasn't it being
> called?
>
> I tried changing the output from within the function sys_getcwd(), but
> it made no difference. I even commented the whole function out so that
> it was not even implemented, but the shell still happily printed out
> the value of cwd.
>
> Yikes! I had the feeling of someone looking at printf ("2+2=%d", 2+2);
> and seeing 5 being printed. Was I insane, drunk, half-asleep? I felt
> like looking out the window and seeing if pigs were flying by!
>
> Finally, I noticed that user_getcwd() also called my patched function.
> A quick check --- yes, that's where the shell was actually connecting
> to the VFS. A moment's reflection convinced me that this made sense.
> The shell was a user app. So when it calls sys_getcwd(), something
> converts this into a call to user_getcwd() in the VFS layer. However, I
> haven't got a clue as to who is doing the translation. Maybe the host
> filesystem? No, none of them implement that function -- sys_getcwd() is
> not a syscall.
>
> Well, you got me. I guess that there is a ghost in the machine. Can
> anyone enlighten on how the shell's call to sys_getcwd() gets
> translated into a call to user_getcwd() in the VFS? And which
> sys_getcwd() is actually called? I'd be curious to see, because,
> wherever that function is, it's returns values are backward!
Other related posts:
