Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 11 May 2013 09:23:31 +0100 (BST)
From:      Karl Dreger <k.dreger@yahoo.de>
To:        Alfred Perlstein <bright@mu.org>
Cc:        "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>
Subject:   Re: syscall to userland interface
Message-ID:  <1368260611.67320.YahooMailNeo@web171505.mail.ir2.yahoo.com>
In-Reply-To: <518D4C4F.90902@mu.org>
References:  <1368214284.29611.YahooMailNeo@web171503.mail.ir2.yahoo.com> <518D4C4F.90902@mu.org>

next in thread | previous in thread | raw e-mail | index | archive | help
=0A=0AI am feeling rather stupid at the moment, but I can't find the assemb=
ler =0A=0Afiles that you are referring to. Do you mean that every syscall u=
nder =0A=0Asys/kern/*.c has a corresponding .S file in src/lib/libc/? =0A=
=0A=0AThe actual transition from user to kernelland and back probably takes=
 =0A=0Aplace via the assembler routines in sys/i386/i386. Most notably exce=
ption.s =0A=0Afor my i386 cpu.=0A=0A=0AWhat my question boils down to is th=
is: when running fork and friends =0A=0Afrom userland they are invoked as:=
=0A=0Afork();, open();, read();, close(); ...=0A=0A=0Abut are defined as:=
=0A=0Asys_fork(), sys_open(), sys_read(), sys_close(), ...=0A=0Ain their ac=
tual c definition.=0A=0AIf the assembler files that you spoke about answer =
this discrepancy, =0A=0Athen the reason why the penny hasn't dropped yet is=
 because I haven't=0Afound them.=0A=0A=0AKarl=0A=0A=0A=0A__________________=
______________=0A Von: Alfred Perlstein <bright@mu.org>=0AAn: Karl Dreger <=
k.dreger@yahoo.de> =0ACC: "freebsd-hackers@freebsd.org" <freebsd-hackers@fr=
eebsd.org> =0AGesendet: 3:36 Samstag, 11.Mai 2013=0ABetreff: Re: syscall to=
 userland interface=0A =0A=0AOn 5/10/13 12:31 PM, Karl Dreger wrote:=0A> He=
llo,=0A> I have been taking a look at a few syscalls in /usr/src/sys/kern/ =
and=0A> always find that in their actuall c definition the function names a=
re=0A> preprended by a sys_. Take for example the fork system call which=0A=
> is found in /usr/src/sys/kern/kern_fork.c=0A>=0A> int=0A> sys_fork(struct=
 thread *td, struct fork_args *uap)=0A> ...=0A>=0A> Now when I write a prog=
ram from userland, that makes use of the=0A> fork system call, then if call=
 it as:=0A>=0A> fork();=0A>=0A> All the syscall are part of libc, which is =
usually defined in=0A> /usr/src/lib/libc/=0A>=0A> Since the system calls ar=
e already defined in the kernel sources, they=0A> no longer need to be defi=
ned in /usr/src/lib/libc/. This is the reason=0A> why one can only find the=
 manpages and no c files in=0A> /usr/src/lib/libc/sys?=0A> At least this is=
 how my thinking goes.=0A>=0A> Now, when the syscalls in the kernel sources=
 are all defined as sys_xxx=0A> but are invoked as xxx and the c headers al=
so show syscall prototypes=0A> without any prepended sys. How does the actu=
al user-, kernelland=0A> move happen? In other words, why do I invoke fork(=
) as fork() and=0A> not as sys_fork()?=0A>=0A> Or is there something that I=
 missed?=0A>=0A>=0A> Clarification on that point is highly welcome.=0A=0AWh=
en you build the system a whole bunch of assembler files are =0Aautomatical=
ly generated that define the functions you are looking for.=0A=0ALook for .=
S files under the object directory.=0A=0AThose assembler files have the mag=
ic to cause a system call to happen.=0A=0Aexample: src/lib/libc/getauid.S=
=A0 (note, this file is GENERATED, it's not =0Apart of src.)=0A=0A=0A=0A-Al=
fred=0A=0A_______________________________________________=0Afreebsd-hackers=
@freebsd.org mailing list=0Ahttp://lists.freebsd.org/mailman/listinfo/freeb=
sd-hackers=0ATo unsubscribe, send any mail to "freebsd-hackers-unsubscribe@=
freebsd.org"
From owner-freebsd-hackers@FreeBSD.ORG  Sat May 11 08:58:10 2013
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
Delivered-To: freebsd-hackers@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
 [IPv6:2001:1900:2254:206a::19:1])
 by hub.freebsd.org (Postfix) with ESMTP id D724E913
 for <freebsd-hackers@freebsd.org>; Sat, 11 May 2013 08:58:10 +0000 (UTC)
 (envelope-from mjguzik@gmail.com)
Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com
 [IPv6:2a00:1450:400c:c05::22c])
 by mx1.freebsd.org (Postfix) with ESMTP id 6ECA5F2C
 for <freebsd-hackers@freebsd.org>; Sat, 11 May 2013 08:58:10 +0000 (UTC)
Received: by mail-wi0-f172.google.com with SMTP id hm14so1339635wib.17
 for <freebsd-hackers@freebsd.org>; Sat, 11 May 2013 01:58:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=x-received:date:from:to:cc:subject:message-id:mail-followup-to
 :references:mime-version:content-type:content-disposition
 :in-reply-to:user-agent;
 bh=vUg/eZ7b8udYjNXd0oAED3fJ99HaTWxtF7HDfikIwzw=;
 b=amEG+I/Z/G7ZmMM4SmKwdToDjX30nZx5ppU+Yk0o0CX2jmKV2B3dZKDDI88zMWdA9o
 7GtSwBEMHTTRYbMaJ1VkN+P/xmlZPQ5dr+RwKmRp7gqL7stLOoKIZPFeYsYV0YXF26u0
 bbajwjsVCwelEQqwc+Cgb3pVfXPLfI7eKti+mq6KfYDtSt2a1Q+GU44dhBNVZM59x4du
 EH3qCbN/LKxcY76k5ioXhYFKOJVFJBXzFaxFt30zYmlVYxS3OkZxp1guJuXiads20exN
 0aQa+RjufWsvFU91eN4/A6o741nrc4peJ5K+xCeOaN85ar+sn/vvxixmJvJJviWcFrWD
 ZfrQ==
X-Received: by 10.194.5.196 with SMTP id u4mr29267305wju.54.1368262689574;
 Sat, 11 May 2013 01:58:09 -0700 (PDT)
Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net.
 [2001:470:1f08:1f7::2])
 by mx.google.com with ESMTPSA id nf9sm2378328wic.3.2013.05.11.01.58.07
 for <multiple recipients>
 (version=TLSv1 cipher=RC4-SHA bits=128/128);
 Sat, 11 May 2013 01:58:08 -0700 (PDT)
Date: Sat, 11 May 2013 10:58:05 +0200
From: Mateusz Guzik <mjguzik@gmail.com>
To: Karl Dreger <k.dreger@yahoo.de>
Subject: Re: syscall to userland interface
Message-ID: <20130511085805.GA23033@dft-labs.eu>
Mail-Followup-To: Mateusz Guzik <mjguzik@gmail.com>,
 Karl Dreger <k.dreger@yahoo.de>, Alfred Perlstein <bright@mu.org>,
 "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>
References: <1368214284.29611.YahooMailNeo@web171503.mail.ir2.yahoo.com>
 <518D4C4F.90902@mu.org>
 <1368260611.67320.YahooMailNeo@web171505.mail.ir2.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <1368260611.67320.YahooMailNeo@web171505.mail.ir2.yahoo.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>,
 Alfred Perlstein <bright@mu.org>
X-BeenThere: freebsd-hackers@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Technical Discussions relating to FreeBSD
 <freebsd-hackers.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-hackers>, 
 <mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers>;
List-Post: <mailto:freebsd-hackers@freebsd.org>
List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
 <mailto:freebsd-hackers-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 11 May 2013 08:58:10 -0000

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 <mjguzik gmail.com>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1368260611.67320.YahooMailNeo>