Re: syscall to userland interface
On 5/11/13, Alfred Perlstein wrote: > On 5/11/13 1:23 AM, Karl Dreger wrote: >> >> I am feeling rather stupid at the moment, but I can't find the assembler >> >> files that you are referring to. Do you mean that every syscall under >> >> sys/kern/*.c has a corresponding .S file in src/lib/libc/? > > Nope, the .S files are under the object directory: > >> When you build the system a whole bunch of assembler files are >> automatically generated that define the functions you are looking for. >> >> Look for .S files under the object directory. >> >> Those assembler files have the magic to cause a system call to happen. >> >> example: src/lib/libc/getauid.S (note, this file is GENERATED, it's not >> part of src.) > > > >> >> >> The actual transition from user to kernelland and back probably takes >> >> place via the assembler routines in sys/i386/i386. Most notably >> exception.s >> >> for my i386 cpu. >> >> >> What my question boils down to is this: when running fork and friends >> >> from userland they are invoked as: >> >> fork();, open();, read();, close(); ... >> >> >> but are defined as: >> >> sys_fork(), sys_open(), sys_read(), sys_close(), ... >> >> in their actual c definition. >> >> If the assembler files that you spoke about answer this discrepancy, >> >> then the reason why the penny hasn't dropped yet is because I haven't >> found them. >> >> > Again, they are generated as part of build. You will NOT find them > during a checkout. cd /usr/obj/*/lib/libc/ ls *.S > > -Alfred > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: syscall to userland interface
On 5/11/13 1:23 AM, Karl Dreger wrote: I am feeling rather stupid at the moment, but I can't find the assembler files that you are referring to. Do you mean that every syscall under sys/kern/*.c has a corresponding .S file in src/lib/libc/? Nope, the .S files are under the object directory: When you build the system a whole bunch of assembler files are automatically generated that define the functions you are looking for. Look for .S files under the object directory. Those assembler files have the magic to cause a system call to happen. example: src/lib/libc/getauid.S (note, this file is GENERATED, it's not part of src.) The actual transition from user to kernelland and back probably takes place via the assembler routines in sys/i386/i386. Most notably exception.s for my i386 cpu. What my question boils down to is this: when running fork and friends from userland they are invoked as: fork();, open();, read();, close(); ... but are defined as: sys_fork(), sys_open(), sys_read(), sys_close(), ... in their actual c definition. If the assembler files that you spoke about answer this discrepancy, then the reason why the penny hasn't dropped yet is because I haven't found them. Again, they are generated as part of build. You will NOT find them during a checkout. -Alfred ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: syscall to userland interface
Yes, that makes it clear. Now, that you are actually speaking about the syscall table, I have to say that I was aware of there being one, but I never before saw it that way. Thanks Von: Mateusz Guzik An: Karl Dreger CC: "freebsd-hackers@freebsd.org" ; Alfred Perlstein Gesendet: 16:58 Samstag, 11.Mai 2013 Betreff: Re: syscall to userland interface On Sat, May 11, 2013 at 09:23:31AM +0100, Karl Dreger wrote: > What my question boils down to is this: when running fork and friends > > from userland they are invoked as: > > fork();, open();, read();, close(); ... > > > but are defined as: > > sys_fork(), sys_open(), sys_read(), sys_close(), ... > > in their actual c definition. sys_* are symbols visible only in the kernel, and as such their names or existence is not visible from userspace. The kernel has syscall table - each syscall has an entry in the table at specified offset (syscall number) with a pointer to function implementing given syscall. Userspace knows syscall numbers. So the common thing for both userspace and kernel is syscall number, it has nothing to do with names. Here is an example how syscall worked on i386: - you put syscall numer in eax register - you call the kernel by issuing int 80h - handler in the kernel takes number from eax, looks up appropriate function from syscall table and calls that function Here is an example: http://www.freebsd.org/doc/en/books/developers-handbook/x86-system-calls.html e.g. fork has number 2. So, what userspace fork function does is simply telling the kernel to execute syscall number 2. It is not important how function implementing this syscall is named, it could be "foobarbecausewhynot". I hope this clears things up. -- Mateusz Guzik ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: syscall to userland interface
On Sat, May 11, 2013 at 09:23:31AM +0100, Karl Dreger wrote: > What my question boils down to is this: when running fork and friends > > from userland they are invoked as: > > fork();, open();, read();, close(); ... > > > but are defined as: > > sys_fork(), sys_open(), sys_read(), sys_close(), ... > > in their actual c definition. sys_* are symbols visible only in the kernel, and as such their names or existence is not visible from userspace. The kernel has syscall table - each syscall has an entry in the table at specified offset (syscall number) with a pointer to function implementing given syscall. Userspace knows syscall numbers. So the common thing for both userspace and kernel is syscall number, it has nothing to do with names. Here is an example how syscall worked on i386: - you put syscall numer in eax register - you call the kernel by issuing int 80h - handler in the kernel takes number from eax, looks up appropriate function from syscall table and calls that function Here is an example: http://www.freebsd.org/doc/en/books/developers-handbook/x86-system-calls.html e.g. fork has number 2. So, what userspace fork function does is simply telling the kernel to execute syscall number 2. It is not important how function implementing this syscall is named, it could be "foobarbecausewhynot". I hope this clears things up. -- Mateusz Guzik ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: syscall to userland interface
I am feeling rather stupid at the moment, but I can't find the assembler files that you are referring to. Do you mean that every syscall under sys/kern/*.c has a corresponding .S file in src/lib/libc/? The actual transition from user to kernelland and back probably takes place via the assembler routines in sys/i386/i386. Most notably exception.s for my i386 cpu. What my question boils down to is this: when running fork and friends from userland they are invoked as: fork();, open();, read();, close(); ... but are defined as: sys_fork(), sys_open(), sys_read(), sys_close(), ... in their actual c definition. If the assembler files that you spoke about answer this discrepancy, then the reason why the penny hasn't dropped yet is because I haven't found them. Karl Von: Alfred Perlstein An: Karl Dreger CC: "freebsd-hackers@freebsd.org" Gesendet: 3:36 Samstag, 11.Mai 2013 Betreff: Re: syscall to userland interface On 5/10/13 12:31 PM, Karl Dreger wrote: > Hello, > I have been taking a look at a few syscalls in /usr/src/sys/kern/ and > always find that in their actuall c definition the function names are > preprended by a sys_. Take for example the fork system call which > is found in /usr/src/sys/kern/kern_fork.c > > int > sys_fork(struct thread *td, struct fork_args *uap) > ... > > Now when I write a program from userland, that makes use of the > fork system call, then if call it as: > > fork(); > > All the syscall are part of libc, which is usually defined in > /usr/src/lib/libc/ > > Since the system calls are already defined in the kernel sources, they > no longer need to be defined in /usr/src/lib/libc/. This is the reason > why one can only find the manpages and no c files in > /usr/src/lib/libc/sys? > At least this is how my thinking goes. > > Now, when the syscalls in the kernel sources are all defined as sys_xxx > but are invoked as xxx and the c headers also show syscall prototypes > without any prepended sys. How does the actual user-, kernelland > move happen? In other words, why do I invoke fork() as fork() and > not as sys_fork()? > > Or is there something that I missed? > > > Clarification on that point is highly welcome. When you build the system a whole bunch of assembler files are automatically generated that define the functions you are looking for. Look for .S files under the object directory. Those assembler files have the magic to cause a system call to happen. example: src/lib/libc/getauid.S (note, this file is GENERATED, it's not part of src.) -Alfred ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: syscall to userland interface
On 5/10/13 12:31 PM, Karl Dreger wrote: Hello, I have been taking a look at a few syscalls in /usr/src/sys/kern/ and always find that in their actuall c definition the function names are preprended by a sys_. Take for example the fork system call which is found in /usr/src/sys/kern/kern_fork.c int sys_fork(struct thread *td, struct fork_args *uap) ... Now when I write a program from userland, that makes use of the fork system call, then if call it as: fork(); All the syscall are part of libc, which is usually defined in /usr/src/lib/libc/ Since the system calls are already defined in the kernel sources, they no longer need to be defined in /usr/src/lib/libc/. This is the reason why one can only find the manpages and no c files in /usr/src/lib/libc/sys? At least this is how my thinking goes. Now, when the syscalls in the kernel sources are all defined as sys_xxx but are invoked as xxx and the c headers also show syscall prototypes without any prepended sys. How does the actual user-, kernelland move happen? In other words, why do I invoke fork() as fork() and not as sys_fork()? Or is there something that I missed? Clarification on that point is highly welcome. When you build the system a whole bunch of assembler files are automatically generated that define the functions you are looking for. Look for .S files under the object directory. Those assembler files have the magic to cause a system call to happen. example: src/lib/libc/getauid.S (note, this file is GENERATED, it's not part of src.) -Alfred ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
syscall to userland interface
Hello, I have been taking a look at a few syscalls in /usr/src/sys/kern/ and always find that in their actuall c definition the function names are preprended by a sys_. Take for example the fork system call which is found in /usr/src/sys/kern/kern_fork.c int sys_fork(struct thread *td, struct fork_args *uap) ... Now when I write a program from userland, that makes use of the fork system call, then if call it as: fork(); All the syscall are part of libc, which is usually defined in /usr/src/lib/libc/ Since the system calls are already defined in the kernel sources, they no longer need to be defined in /usr/src/lib/libc/. This is the reason why one can only find the manpages and no c files in /usr/src/lib/libc/sys? At least this is how my thinking goes. Now, when the syscalls in the kernel sources are all defined as sys_xxx but are invoked as xxx and the c headers also show syscall prototypes without any prepended sys. How does the actual user-, kernelland move happen? In other words, why do I invoke fork() as fork() and not as sys_fork()? Or is there something that I missed? Clarification on that point is highly welcome. Thanks ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
