Re: Kernel calls, are they documented somewhere?
Michael Bacarella [EMAIL PROTECTED] writes: gcc does not generate code that can make FreeBSD system calls directly. Most system calls as we know them by the manual have corresponding wrappers in libc. See /usr/src/lib/libc if you have the source installed. Wrong. The threaded C library (libc_r) has wrappers for many syscalls so it won't block all threads when one is waiting for a syscall to complete, but apart from that, very few syscalls are wrapped. Adam, it's really quite simple: if the carry flag is set, the syscall failed, and the value returned is the errno (in your example, open(2) returned 2, which is ENOENT, i.e. the file didn't exist). If it succeeded, the value returned is the result (a file descriptor in open(2)'s case). DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Kernel calls, are they documented somewhere?
On Thu, Nov 02, 2000 at 12:12:02AM -0500, Michael Bacarella wrote: This isn't such a daunting task with grep. Source code cross referencers can also help, but I don't use them nearly as often as I thought I would. Thanks for the grep suggestion. I think I found the source code for open() now (with grep): /usr/src/sys/kern/vfs_syscalls.c Indeed, when it fails, it returns an error. That happens to be 2 when the file does not exist (ENOENT = 2). Hmmm. That means that if I get a value above 2, it can be the file descriptor, or it can be an error. That's making me a bit nervous. I need to distinguish between errors and file descriptors. However, there seems to be a way, though not fullproof: Each open returns the file descriptor that is 1 higher than the last. Since stdin, stdout, and stderr are open already, the first fd = 3, the next 4, etc. I suppose I need to declare a variable and initialize it to 3. Whenever I call open, if the return value equals to that variable, the open probably succeeded, otherwise it failed. Then, of course, I need to increase the variable so I can use it with the next open. But this will probably not work if my program is called as a child of another which has some files opened already, will it? I am certainly open (no pun intended) to suggestions. Adam -- Roma non uno die aedificata est To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Kernel calls, are they documented somewhere?
G. Adam Stanislav wrote: On Thu, Nov 02, 2000 at 12:12:02AM -0500, Michael Bacarella wrote: gcc does not generate code that can make FreeBSD system calls directly. Most system calls as we know them by the manual have corresponding wrappers in libc. See /usr/src/lib/libc if you have the source installed. I do have the source code, and I have studied it, but it is uncommented. And, it seems, not all of it is included. For example, there is a /usr/src/lib/libc/sys/open.2 but no corresponding open.c. I have been unable to find the source code for open() in libc. There is an open.c in /usr/src/lib/libstand/ but it makes no system calls. Actually, it looks like a system call (it assigns its own file descriptors to files it opens), but it does not behave like our kernel (since it returns -1 on errors, while our kernel has been returning 2 in my tests when trying to open a non-existing file as O_RDONLY: sub eax, eax; EAX = 0 = O_RDONLY pusheax pusheax pushesi ; points at file name pusheax ; fake return address int 80h add esp, byte 16 (That's NASM syntax.) If the file exists, I get a file descriptor in EAX, otherwise EAX = 2. It would be nice if I could get some kind of formal confirmation that this is how it is supposed to be, and that all FreeBSD versions behave like that. Here's open(2) implemented as a C function: open: mov $0x5,%eax int $0x80 jc .L1 ret .L1:jmp __cerror __cerror: mov %eax,errno mov $-1,%eax ret The idea is to check the carry flag, since the kernel returns two different things in %eax, depending on whether an error has occurred. Our function maintains errno, since this is how things are done in the C library. If you need more info, e-mail me directly. -- Robert Nordier [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Kernel calls, are they documented somewhere?
On Thu, 2 Nov 2000, G. Adam Stanislav wrote: I do have the source code, and I have studied it, but it is uncommented. And, it seems, not all of it is included. For example, there is a /usr/src/lib/libc/sys/open.2 but no corresponding open.c. I have been unable to find the source code for open() in libc. There is an open.c The source for this type of syscalls is made "on the fly" in Makefile. Since normally you use /usr/obj for keeping built objects, the source files like e.g. open.S end up there. For open.S it contains the following: #include "SYS.h" RSYSCALL(open) which is a macro expanding to an asm wrapper around the syscall. (Mind you, I'm not an asm expert by any means, I just happen to know how the building process works.. :-) in /usr/src/lib/libstand/ but it makes no system calls. Actually, it looks like a system call (it assigns its own file descriptors to files it opens), but it does not behave like our kernel (since it returns -1 on errors, while our kernel has been returning 2 in my tests when trying to open a non-existing file as O_RDONLY: libstand is a very special animal - it's used only for providing BSD-like interface in BTX (bootloader) environment. Never use it when you run kernel. OTOH, it's very enlightening to look into it and see how you implement "syscalls" on a bare hardware... Andrzej Bialecki // [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com) // --- // -- FreeBSD: The Power to Serve. http://www.freebsd.org // --- Small Embedded FreeBSD: http://www.freebsd.org/~picobsd/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Kernel calls, are they documented somewhere?
On Thu, Nov 02, 2000 at 09:59:02AM +0100, Dag-Erling Smorgrav wrote: Adam, it's really quite simple: if the carry flag is set, the syscall failed, and the value returned is the errno (in your example, open(2) returned 2, which is ENOENT, i.e. the file didn't exist). If it succeeded, the value returned is the result (a file descriptor in open(2)'s case). Aha! Thank you (and everyone else who answered). That did the trick. I just knew FreeBSD would use a simple and elegant solution, and this one is both. Thanks again! Adam -- Don't send me spam, I'm a vegetarian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Kernel calls, are they documented somewhere?
Are the system calls made via interrupt 0x80 documented somewhere? Whatever section 2 of man says does not work when making direct kernel calls. It only describes how the C library calls work. For example, open() returns -1 if the file is not open. But int 80h made in assembly language with EAX = 5 (SYS_open) returns a positive value whether or not the file was opened. My tests show it returns 2 if the open fails, or a valid file descriptor otherwise. But can I rely on it being the case with other versions of FreeBSD (I have 3.1)? Similarly, SYS_sbrk always returns a very small value, while the C sbrk() works as described in man 2 sbrk. I have given up on SYS_sbrk altogether, and am reserving a huge buffer in .bss instead. But if I overrun that buffer, my software has to quit for "lack of memory". Please don't tell me to read the kernel source code: I am not about to spend weeks or months wading through it just so I can write free software. (Quite frankly I tried, but I often have no clue as to which file contains the code I am looking for.) What I'd like to know is if there is a document or a book that describes the return values of the various system calls. All I could find is the systemcalls.master (and .h and such) file which only gives me the arguments to pass to each call but not how to determine whether the call succeeded. Nor is eaminging the libc source code too helpful (it contains very few if any comments). This is very frustrating... Please, rest assured that I will publish any answers I find in Assembly Programming Journal, and on my web site, to make it easier on other assembly language programmers to code for FreeBSD. Most of them (us) have enough information to write assembly programs for Windows only. I'd like to change that and bring as many as possible to our camp. Cheers, Adam -- This signature intentionally left blank To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Kernel calls, are they documented somewhere?
On Thu, Nov 02, 2000 at 12:12:02AM -0500, Michael Bacarella wrote: gcc does not generate code that can make FreeBSD system calls directly. Most system calls as we know them by the manual have corresponding wrappers in libc. See /usr/src/lib/libc if you have the source installed. I do have the source code, and I have studied it, but it is uncommented. And, it seems, not all of it is included. For example, there is a /usr/src/lib/libc/sys/open.2 but no corresponding open.c. I have been unable to find the source code for open() in libc. There is an open.c in /usr/src/lib/libstand/ but it makes no system calls. Actually, it looks like a system call (it assigns its own file descriptors to files it opens), but it does not behave like our kernel (since it returns -1 on errors, while our kernel has been returning 2 in my tests when trying to open a non-existing file as O_RDONLY: sub eax, eax; EAX = 0 = O_RDONLY pusheax pusheax pushesi ; points at file name pusheax ; fake return address int 80h add esp, byte 16 (That's NASM syntax.) If the file exists, I get a file descriptor in EAX, otherwise EAX = 2. It would be nice if I could get some kind of formal confirmation that this is how it is supposed to be, and that all FreeBSD versions behave like that. Adam -- Apply standard disk lamer To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
