From owner-freebsd-threads@FreeBSD.ORG Mon Oct 17 11:02:09 2005 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4DAA816A42B for ; Mon, 17 Oct 2005 11:02:09 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F95043D4C for ; Mon, 17 Oct 2005 11:02:09 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j9HB28do022549 for ; Mon, 17 Oct 2005 11:02:08 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j9HB27QO022543 for freebsd-threads@freebsd.org; Mon, 17 Oct 2005 11:02:07 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 17 Oct 2005 11:02:07 GMT Message-Id: <200510171102.j9HB27QO022543@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-threads@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2005 11:02:09 -0000 Current FreeBSD problem reports Critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2005/01/26] threads/76690threads fork hang in child for (-lc_r & -lthr) o [2005/05/11] threads/80887threads ULE with SMP broke libpthread/libthr on 5 2 problems total. Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2000/07/18] kern/20016 threads pthreads: Cannot set scheduling timer/Can o [2000/08/26] kern/20861 threads libc_r does not honor socket timeouts o [2001/01/20] threads/24472threads libc_r does not honor SO_SNDTIMEO/SO_RCVT o [2001/01/25] threads/24632threads libc_r delicate deviation from libc in ha o [2001/01/25] kern/24641 threads pthread_rwlock_rdlock can deadlock o [2001/11/26] bin/32295 threads pthread dont dequeue signals o [2002/02/01] threads/34536threads accept() blocks other threads o [2002/05/25] kern/38549 threads the procces compiled whith pthread stoppe o [2002/06/27] threads/39922threads [PATCH?] Threaded applications executed w o [2002/08/04] kern/41331 threads Pthread library open sets O_NONBLOCK flag o [2003/03/02] threads/48856threads Setting SIGCHLD to SIG_IGN still leaves z o [2003/03/10] threads/49087threads Signals lost in programs linked with libc s [2004/03/15] kern/64313 threads FreeBSD (OpenBSD) pthread implicit set/un o [2004/08/26] threads/70975threads unexpected and unreliable behaviour when o [2004/10/05] threads/72353threads Assertion fails in /usr/src/lib/libpthrea o [2004/10/07] threads/72429threads threads blocked in stdio (fgets, etc) are o [2004/10/21] threads/72953threads fork() unblocks blocked signals w/o PTHRE o [2004/12/19] threads/75273threads FBSD 5.3 libpthread (KSE) bug o [2004/12/21] threads/75374threads pthread_kill() ignores SA_SIGINFO flag o [2005/01/26] threads/76694threads fork cause hang in dup()/close() function o [2005/03/10] threads/78660threads Java hangs unkillably in STOP state after o [2005/04/08] threads/79683threads svctcp_create() fails if multiple threads o [2005/04/28] threads/80435threads panic on high loads o [2005/05/19] threads/81258threads Thread specific data is sometimes assigne o [2005/08/02] threads/84483threads problems with devel/nspr and -lc_r on 4.x s [2005/08/10] threads/84778threads libpthread busy loop/hang with Java when o [2005/08/20] threads/85160threads [patch] libobjc + libpthread/libthr crash o [2005/09/12] threads/86004threads libthr broken on amd64 28 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2000/05/26] kern/18824 threads gethostbyname is not thread safe o [2000/06/13] kern/19247 threads uthread_sigaction.c does not do anything o [2000/10/21] kern/22190 threads A threaded read(2) from a socketpair(2) f o [2001/09/09] threads/30464threads pthread mutex attributes -- pshared o [2002/05/02] threads/37676threads libc_r: msgsnd(), msgrcv(), pread(), pwri s [2002/07/16] threads/40671threads pthread_cancel doesn't remove thread from o [2004/07/13] threads/69020threads pthreads library leaks _gc_mutex o [2004/09/21] threads/71966threads Mlnet Core Dumped : Fatal error '_pq_inse o [2004/11/21] threads/74180threads KSE problem. Applications those riched ma o [2005/01/20] threads/76513threads libpthread is not working o [2005/04/13] threads/79887threads [patch] freopen() isn't thread-safe o [2005/05/13] threads/80992threads abort() sometimes not caught by gdb depen o [2005/05/26] threads/81534threads [PATCH] libc_r close() will fail on any f 13 problems total. From owner-freebsd-threads@FreeBSD.ORG Fri Oct 21 13:38:42 2005 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C2AC116A41F for ; Fri, 21 Oct 2005 13:38:42 +0000 (GMT) (envelope-from konstantinos.boukis@kcl.ac.uk) Received: from mail82.messagelabs.com (mail82.messagelabs.com [195.245.231.67]) by mx1.FreeBSD.org (Postfix) with SMTP id CBDE943D46 for ; Fri, 21 Oct 2005 13:38:41 +0000 (GMT) (envelope-from konstantinos.boukis@kcl.ac.uk) X-VirusChecked: Checked X-Env-Sender: konstantinos.boukis@kcl.ac.uk X-Msg-Ref: server-14.tower-82.messagelabs.com!1129901919!22581491!1 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [137.73.2.214] Received: (qmail 28332 invoked from network); 21 Oct 2005 13:38:39 -0000 Received: from outbound.kcl.ac.uk (137.73.2.214) by server-14.tower-82.messagelabs.com with SMTP; 21 Oct 2005 13:38:39 -0000 Received: from relay3.kcl.ac.uk ([137.73.2.218] helo=Hazel) by outbound.kcl.ac.uk outbound with esmtp (TLSv1:DHE-RSA-AES256-SHA:256) id 1ESx6L-0002cx-KK for freebsd-threads@freebsd.org; Fri, 21 Oct 2005 14:38:29 +0100 Received: from elder.kcl.ac.uk ([137.73.2.27] helo=localhost) by Hazel smtphack with esmtp id 1ESx65-0000YW-W0 for freebsd-threads@freebsd.org; Fri, 21 Oct 2005 14:38:15 +0100 Received: from host86-129-64-16.range86-129.btcentralplus.com (host86-129-64-16.range86-129.btcentralplus.com [86.129.64.16]) by impmail.kcl.ac.uk (IMP) with HTTP for ; Fri, 21 Oct 2005 14:38:13 +0100 Message-ID: <1129901893.4358ef45d0632@impmail.kcl.ac.uk> Date: Fri, 21 Oct 2005 14:38:13 +0100 From: Konstantinos Boukis To: freebsd-threads@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.8 X-KCLOriginating-IP: 86.129.64.16 X-KCLSpamScore: 0 X-KCLRealSpamScore: 0.0 X-KCLZStatus: 0 X-KCLSpamReport: X-KCL-MailScanner: Found to be clean X-MailScanner-From: konstantinos.boukis@kcl.ac.uk Subject: kernel upcall documentation X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2005 13:38:42 -0000 Hello, I am not quite sure whether this is the correct list, my problem is that I want to send an upcall from the kernel to userland to load a module (kernel threads cannot call linker_load_module since they do not have a valid fd_cdir). Is there any document describing how to make an upcall from the kernel to userland? Thanks Konstantinos From owner-freebsd-threads@FreeBSD.ORG Fri Oct 21 14:20:54 2005 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A17FB16A41F for ; Fri, 21 Oct 2005 14:20:54 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3124143D45 for ; Fri, 21 Oct 2005 14:20:54 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.5/8.13.5/NETPLEX) with ESMTP id j9LEKqme020719; Fri, 21 Oct 2005 10:20:52 -0400 (EDT) Date: Fri, 21 Oct 2005 10:20:52 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Konstantinos Boukis In-Reply-To: <1129901893.4358ef45d0632@impmail.kcl.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: freebsd-threads@freebsd.org Subject: Re: kernel upcall documentation X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2005 14:20:54 -0000 On Fri, 21 Oct 2005, Konstantinos Boukis wrote: > Hello, > I am not quite sure whether this is the correct list, my problem is that I want > to send an upcall from the kernel to userland to load a module (kernel threads > cannot call linker_load_module since they do not have a valid fd_cdir). Is > there any document describing how to make an upcall from the kernel to > userland? This is not how you want to do it. Do it the old fashioned way, with a read() or ioctl() from userland that blocks until the kernel is ready to have the module loaded. -- DE From owner-freebsd-threads@FreeBSD.ORG Fri Oct 21 14:38:36 2005 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4632E16A41F for ; Fri, 21 Oct 2005 14:38:36 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9ABAA43D46 for ; Fri, 21 Oct 2005 14:38:35 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.5/8.13.5/NETPLEX) with ESMTP id j9LEcYr1008090; Fri, 21 Oct 2005 10:38:34 -0400 (EDT) Date: Fri, 21 Oct 2005 10:38:34 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Konstantinos Boukis In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: freebsd-threads@freebsd.org Subject: Re: kernel upcall documentation X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2005 14:38:36 -0000 On Fri, 21 Oct 2005, Daniel Eischen wrote: > On Fri, 21 Oct 2005, Konstantinos Boukis wrote: > > > Hello, > > I am not quite sure whether this is the correct list, my problem is that I want > > to send an upcall from the kernel to userland to load a module (kernel threads > > cannot call linker_load_module since they do not have a valid fd_cdir). Is > > there any document describing how to make an upcall from the kernel to > > userland? > > This is not how you want to do it. Do it the old fashioned > way, with a read() or ioctl() from userland that blocks until > the kernel is ready to have the module loaded. Or find some other way to do it within the kernel... -- DE From owner-freebsd-threads@FreeBSD.ORG Fri Oct 21 16:28:14 2005 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F1E2A16A41F; Fri, 21 Oct 2005 16:28:13 +0000 (GMT) (envelope-from konstantinos.boukis@kcl.ac.uk) Received: from mail82.messagelabs.com (mail82.messagelabs.com [195.245.231.67]) by mx1.FreeBSD.org (Postfix) with SMTP id B623843D45; Fri, 21 Oct 2005 16:28:12 +0000 (GMT) (envelope-from konstantinos.boukis@kcl.ac.uk) X-VirusChecked: Checked X-Env-Sender: konstantinos.boukis@kcl.ac.uk X-Msg-Ref: server-2.tower-82.messagelabs.com!1129912090!38298453!1 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [137.73.2.214] Received: (qmail 4058 invoked from network); 21 Oct 2005 16:28:11 -0000 Received: from outbound.kcl.ac.uk (137.73.2.214) by server-2.tower-82.messagelabs.com with SMTP; 21 Oct 2005 16:28:11 -0000 Received: from relay3.kcl.ac.uk ([137.73.2.218] helo=Hazel) by outbound.kcl.ac.uk outbound with esmtp (TLSv1:DHE-RSA-AES256-SHA:256) id 1ESzk9-0004ht-Qc; Fri, 21 Oct 2005 17:27:45 +0100 Received: from elder.kcl.ac.uk ([137.73.2.27] helo=localhost) by Hazel smtphack with esmtp id 1ESzjw-0000Tl-A3; Fri, 21 Oct 2005 17:27:33 +0100 Received: from host86-129-77-190.range86-129.btcentralplus.com (host86-129-77-190.range86-129.btcentralplus.com [86.129.77.190]) by impmail.kcl.ac.uk (IMP) with HTTP for ; Fri, 21 Oct 2005 17:27:32 +0100 Message-ID: <1129912052.435916f42500c@impmail.kcl.ac.uk> Date: Fri, 21 Oct 2005 17:27:32 +0100 From: Konstantinos Boukis To: Daniel Eischen References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.8 X-KCLOriginating-IP: 86.129.77.190 X-KCLSpamScore: 0 X-KCLRealSpamScore: 0.0 X-KCLZStatus: 0 X-KCLSpamReport: X-KCL-MailScanner: Found to be clean X-MailScanner-From: konstantinos.boukis@kcl.ac.uk Cc: freebsd-threads@freebsd.org Subject: Re: kernel upcall documentation X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2005 16:28:14 -0000 Well, to be honest I managed to bypass the NULL fd_cdir problem by assigning a temporary valid filedesc to curthread->td_proc->p_fd just before the invocation to linker_load_module. However I am curious to see the upcall solution as well. When I read that: "When a thread blocks in the kernel, the (virtual) cpu is reallocated to another newly created context (thread) and it is allowed to proceed back to userland and runs a known routine with a known pointer as its argument." (from http://lists.freebsd.org/pipermail/freebsd-threads/2003-July/001018.html) I understood that when a kernel thread blocks it makes an upcall to userland and it calls the ku_func function. When ku_func accomplishes its operation then the kernel thread is resumed so as to comply with the upcall definition of clark's "The structuring of systems using upcalls" and Kohler's "the click modular router". So, have I got it right or I am missing something? Quoting Daniel Eischen : > On Fri, 21 Oct 2005, Daniel Eischen wrote: > > > On Fri, 21 Oct 2005, Konstantinos Boukis wrote: > > > > > Hello, > > > I am not quite sure whether this is the correct list, my problem is that > I want > > > to send an upcall from the kernel to userland to load a module (kernel > threads > > > cannot call linker_load_module since they do not have a valid fd_cdir). > Is > > > there any document describing how to make an upcall from the kernel to > > > userland? > > > > This is not how you want to do it. Do it the old fashioned > > way, with a read() or ioctl() from userland that blocks until > > the kernel is ready to have the module loaded. > > Or find some other way to do it within the kernel... > > -- > DE > > -- Konstantinos Boukis konstantinos.boukis@kcl.ac.uk From owner-freebsd-threads@FreeBSD.ORG Fri Oct 21 18:23:54 2005 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4550016A41F for ; Fri, 21 Oct 2005 18:23:54 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id DBDEC43D45 for ; Fri, 21 Oct 2005 18:23:53 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.5/8.13.5/NETPLEX) with ESMTP id j9LINqcX004835; Fri, 21 Oct 2005 14:23:52 -0400 (EDT) Date: Fri, 21 Oct 2005 14:23:52 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Konstantinos Boukis In-Reply-To: <1129912052.435916f42500c@impmail.kcl.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: freebsd-threads@freebsd.org Subject: Re: kernel upcall documentation X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2005 18:23:54 -0000 On Fri, 21 Oct 2005, Konstantinos Boukis wrote: > Well, to be honest I managed to bypass the NULL fd_cdir problem by assigning a > temporary valid filedesc to curthread->td_proc->p_fd just before the invocation > to linker_load_module. > However I am curious to see the upcall solution as well. When I read that: > "When a thread blocks in the kernel, the (virtual) cpu is reallocated to > another newly created context (thread) and it is allowed to proceed back > to userland and runs a known routine with a known pointer as its > argument." (from > http://lists.freebsd.org/pipermail/freebsd-threads/2003-July/001018.html) > I understood that when a kernel thread blocks it makes an upcall to userland and > it calls the ku_func function. When ku_func accomplishes its operation then the > kernel thread is resumed so as to comply with the upcall definition of clark's > "The structuring of systems using upcalls" and Kohler's "the click modular > router". So, have I got it right or I am missing something? These set of functions are meant for user threading, not kernel initiated threading. I don't know what Clark and Kohler describe, but these functions were specifically made for allowing thread libraries to be written. If you want userland to do something based on a kernel event, traditionally userland calls into the kernel and waits for the event, then does whatever it needs to when the event occurs. -- DE From owner-freebsd-threads@FreeBSD.ORG Fri Oct 21 19:18:12 2005 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D3DC516A41F; Fri, 21 Oct 2005 19:18:12 +0000 (GMT) (envelope-from konstantinos.boukis@kcl.ac.uk) Received: from mail82.messagelabs.com (mail82.messagelabs.com [195.245.231.67]) by mx1.FreeBSD.org (Postfix) with SMTP id BA58143D45; Fri, 21 Oct 2005 19:18:11 +0000 (GMT) (envelope-from konstantinos.boukis@kcl.ac.uk) X-VirusChecked: Checked X-Env-Sender: konstantinos.boukis@kcl.ac.uk X-Msg-Ref: server-10.tower-82.messagelabs.com!1129922289!24500313!1 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [137.73.2.214] Received: (qmail 5472 invoked from network); 21 Oct 2005 19:18:09 -0000 Received: from outbound.kcl.ac.uk (137.73.2.214) by server-10.tower-82.messagelabs.com with SMTP; 21 Oct 2005 19:18:09 -0000 Received: from relay3.kcl.ac.uk ([137.73.2.218] helo=Hazel) by outbound.kcl.ac.uk outbound with esmtp (TLSv1:DHE-RSA-AES256-SHA:256) id 1ET2Oe-0005Md-Sc; Fri, 21 Oct 2005 20:17:44 +0100 Received: from elder.kcl.ac.uk ([137.73.2.27] helo=localhost) by Hazel smtphack with esmtp id 1ET2OW-0002Fs-KD; Fri, 21 Oct 2005 20:17:38 +0100 Received: from host86-129-77-190.range86-129.btcentralplus.com (host86-129-77-190.range86-129.btcentralplus.com [86.129.77.190]) by impmail.kcl.ac.uk (IMP) with HTTP for ; Fri, 21 Oct 2005 20:17:36 +0100 Message-ID: <1129922256.43593ed0727ef@impmail.kcl.ac.uk> Date: Fri, 21 Oct 2005 20:17:36 +0100 From: Konstantinos Boukis To: Daniel Eischen References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.8 X-KCLOriginating-IP: 86.129.77.190 X-KCLSpamScore: 0 X-KCLRealSpamScore: 0.0 X-KCLZStatus: 0 X-KCLSpamReport: X-KCL-MailScanner: Found to be clean X-MailScanner-From: konstantinos.boukis@kcl.ac.uk Cc: freebsd-threads@freebsd.org Subject: Re: kernel upcall documentation X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2005 19:18:13 -0000 In Clark’s and Kohler’s definition for upcall, the function that initiates it waits for the upcalled function to finish its operation so as to resume. I could indeed employ a mechanism with signals between the kernel and the userland process but that would break the above definition since the kernel after wakeup() will continue its operation without waiting the userland process to finish (OK, I could then put the kernel thread to sleep and resume it from the userland, but this seems to me very sloppy programming). Anyway, just out of curiosity, is there a way for a kernel thread to invoke the userland function pointed by ku_func? (provided that a mailbox is already assigned to the kse from a userland kse_create invocation) Quoting Daniel Eischen : > On Fri, 21 Oct 2005, Konstantinos Boukis wrote: > > > Well, to be honest I managed to bypass the NULL fd_cdir problem by > assigning a > > temporary valid filedesc to curthread->td_proc->p_fd just before the > invocation > > to linker_load_module. > > However I am curious to see the upcall solution as well. When I read that: > > "When a thread blocks in the kernel, the (virtual) cpu is reallocated to > > another newly created context (thread) and it is allowed to proceed back > > to userland and runs a known routine with a known pointer as its > > argument." (from > > http://lists.freebsd.org/pipermail/freebsd-threads/2003-July/001018.html) > > I understood that when a kernel thread blocks it makes an upcall to > userland and > > it calls the ku_func function. When ku_func accomplishes its operation then > the > > kernel thread is resumed so as to comply with the upcall definition of > clark's > > "The structuring of systems using upcalls" and Kohler's "the click modular > > router". So, have I got it right or I am missing something? > > These set of functions are meant for user threading, not kernel > initiated threading. I don't know what Clark and Kohler describe, > but these functions were specifically made for allowing thread > libraries to be written. If you want userland to do something > based on a kernel event, traditionally userland calls into the > kernel and waits for the event, then does whatever it needs to > when the event occurs. > > -- > DE > > -- Konstantinos Boukis konstantinos.boukis@kcl.ac.uk From owner-freebsd-threads@FreeBSD.ORG Fri Oct 21 19:38:32 2005 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5E92916A41F for ; Fri, 21 Oct 2005 19:38:32 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE69C43D48 for ; Fri, 21 Oct 2005 19:38:31 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.5/8.13.5/NETPLEX) with ESMTP id j9LJcUbm023117; Fri, 21 Oct 2005 15:38:30 -0400 (EDT) Date: Fri, 21 Oct 2005 15:38:30 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Konstantinos Boukis In-Reply-To: <1129922256.43593ed0727ef@impmail.kcl.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: freebsd-threads@freebsd.org Subject: Re: kernel upcall documentation X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2005 19:38:32 -0000 On Fri, 21 Oct 2005, Konstantinos Boukis wrote: > In Clark=92s and Kohler=92s definition for upcall, the function that init= iates it > waits for the upcalled function to finish its operation so as to resume. = I > could indeed employ a mechanism with signals between the kernel and the > userland process but that would break the above definition since the kern= el > after wakeup() will continue its operation without waiting the userland p= rocess > to finish (OK, I could then put the kernel thread to sleep and resume it = from > the userland, but this seems to me very sloppy programming). I think it would be better to have userland (daemon) initiate things if you indeed need to have userland do stuff. What you want to do seems very much worse. How do you know there is a userland process waiting to do anything unless the userland first calls into the kernel? If that's the case, then just put the userland process (thread) to sleep via either read(), write(), ioctl(), kqueue(), or whatever until your event happens. Why is abusing the KSE functions any better? > Anyway, just out of curiosity, is there a way for a kernel thread to invo= ke the > userland function pointed by ku_func? (provided that a mailbox is already > assigned to the kse from a userland kse_create invocation) There is not necessarily a userland stack if it is a pure kernel thread. If you are trying to pass a stack from another userland process (thread), there is no guarantee that the process still exists and the stack is valid, mapped, and valid for the kernel thread to use. I'm not sure what it is you are trying to do, but I think you're looking at it the wrong way. --=20 DE From owner-freebsd-threads@FreeBSD.ORG Fri Oct 21 23:57:43 2005 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7EF0D16A41F; Fri, 21 Oct 2005 23:57:43 +0000 (GMT) (envelope-from konstantinos.boukis@kcl.ac.uk) Received: from mail83.messagelabs.com (mail83.messagelabs.com [195.245.231.83]) by mx1.FreeBSD.org (Postfix) with SMTP id 6A68743D45; Fri, 21 Oct 2005 23:57:42 +0000 (GMT) (envelope-from konstantinos.boukis@kcl.ac.uk) X-VirusChecked: Checked X-Env-Sender: konstantinos.boukis@kcl.ac.uk X-Msg-Ref: server-11.tower-83.messagelabs.com!1129939059!29704146!1 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [137.73.2.214] Received: (qmail 2125 invoked from network); 21 Oct 2005 23:57:39 -0000 Received: from outbound.kcl.ac.uk (137.73.2.214) by server-11.tower-83.messagelabs.com with SMTP; 21 Oct 2005 23:57:39 -0000 Received: from relay3.kcl.ac.uk ([137.73.2.218] helo=Hazel) by outbound.kcl.ac.uk outbound with esmtp (TLSv1:DHE-RSA-AES256-SHA:256) id 1ET6l8-0007UV-UC; Sat, 22 Oct 2005 00:57:14 +0100 Received: from elder.kcl.ac.uk ([137.73.2.27] helo=localhost) by Hazel smtphack with esmtp id 1ET6l1-0005RX-DU; Sat, 22 Oct 2005 00:57:08 +0100 Received: from host86-129-71-207.range86-129.btcentralplus.com (host86-129-71-207.range86-129.btcentralplus.com [86.129.71.207]) by impmail.kcl.ac.uk (IMP) with HTTP for ; Sat, 22 Oct 2005 00:57:07 +0100 Message-ID: <1129939027.43598053423cb@impmail.kcl.ac.uk> Date: Sat, 22 Oct 2005 00:57:07 +0100 From: Konstantinos Boukis To: Daniel Eischen References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.8 X-KCLOriginating-IP: 86.129.71.207 X-KCLSpamScore: 0 X-KCLRealSpamScore: 0.0 X-KCLZStatus: 0 X-KCLSpamReport: X-KCL-MailScanner: Found to be clean X-MailScanner-From: konstantinos.boukis@kcl.ac.uk Cc: freebsd-threads@freebsd.org Subject: Re: kernel upcall documentation X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2005 23:57:43 -0000 I tried not to bombard you with all the information of what I am doing but it seems inevitable ;-). I am working on a theoretical research project and the goal is to develop a mobile terminal (e.g. one that changes network continuously) that will be able to adapt to the offered mobility protocols (i.e. like Mobile IP) offered by the network. In my implementation the kernel identifies the offered protocol and installs the appropriate modules. >From my perspective I am more concerned for preserving the theoretical constrains (i.e. the model of computation) than the practical ones. Of course I understand your perspective as well; you are developing an operating system and your concern is to make it as stable as possible. But let’s assume that a userland stack does exist and is valid and mapped, can a kernel thread suspend, call the function pointed by ku_func in userland and then resume in kernel space? At the end of the day it is interesting and good fun to play around with those things, which I guess is our concern in common. Quoting Daniel Eischen : > On Fri, 21 Oct 2005, Konstantinos Boukis wrote: > > > In Clark’s and Kohler’s definition for upcall, the function that initiates > it > > waits for the upcalled function to finish its operation so as to resume. I > > could indeed employ a mechanism with signals between the kernel and the > > userland process but that would break the above definition since the > kernel > > after wakeup() will continue its operation without waiting the userland > process > > to finish (OK, I could then put the kernel thread to sleep and resume it > from > > the userland, but this seems to me very sloppy programming). > > I think it would be better to have userland (daemon) initiate things > if you indeed need to have userland do stuff. What you want to do > seems very much worse. How do you know there is a userland process > waiting to do anything unless the userland first calls into the > kernel? If that's the case, then just put the userland process > (thread) to sleep via either read(), write(), ioctl(), kqueue(), > or whatever until your event happens. Why is abusing the KSE > functions any better? > > > Anyway, just out of curiosity, is there a way for a kernel thread to invoke > the > > userland function pointed by ku_func? (provided that a mailbox is already > > assigned to the kse from a userland kse_create invocation) > > There is not necessarily a userland stack if it is a pure kernel > thread. If you are trying to pass a stack from another userland > process (thread), there is no guarantee that the process still > exists and the stack is valid, mapped, and valid for the kernel > thread to use. > > I'm not sure what it is you are trying to do, but I think you're > looking at it the wrong way. > > -- > DE > > -- Konstantinos Boukis konstantinos.boukis@kcl.ac.uk From owner-freebsd-threads@FreeBSD.ORG Sat Oct 22 04:53:41 2005 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EA1D816A41F for ; Sat, 22 Oct 2005 04:53:41 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8924743D45 for ; Sat, 22 Oct 2005 04:53:41 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.5/8.13.5/NETPLEX) with ESMTP id j9M4reFE015605; Sat, 22 Oct 2005 00:53:40 -0400 (EDT) Date: Sat, 22 Oct 2005 00:53:39 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Konstantinos Boukis In-Reply-To: <1129939027.43598053423cb@impmail.kcl.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: freebsd-threads@freebsd.org Subject: Re: kernel upcall documentation X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2005 04:53:42 -0000 On Sat, 22 Oct 2005, Konstantinos Boukis wrote: > I tried not to bombard you with all the information of what I am doing bu= t it > seems inevitable ;-). I am working on a theoretical research project and = the > goal is to develop a mobile terminal (e.g. one that changes network > continuously) that will be able to adapt to the offered mobility protocol= s > (i.e. like Mobile IP) offered by the network. In my implementation the ke= rnel > identifies the offered protocol and installs the appropriate modules. There are other examples to look at, like devd. Actually, I don't see why you can't just use devd. From devd(8): "Another example would be for devd to use a table to locate and load vi= a kldload(8) the proper driver for an unrecognized device that is added = to the system." > >From my perspective I am more concerned for preserving the theoretical > constrains (i.e. the model of computation) than the practical ones. Of co= urse I > understand your perspective as well; you are developing an operating syst= em and > your concern is to make it as stable as possible. But let=92s assume that= a > userland stack does exist and is valid and mapped, can a kernel thread su= spend, > call the function pointed by ku_func in userland and then resume in kerne= l > space? At the end of the day it is interesting and good fun to play aroun= d with > those things, which I guess is our concern in common. You might be able to get it to work, but it would probably take more work to get it to work the way you want it to. It would still be easier to make a simple device driver and use ioctl(). Again, look at devd. --=20 DE From owner-freebsd-threads@FreeBSD.ORG Sat Oct 22 07:15:48 2005 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0CCB216A41F for ; Sat, 22 Oct 2005 07:15:48 +0000 (GMT) (envelope-from jiashiun@gmail.com) Received: from qproxy.gmail.com (qproxy.gmail.com [72.14.204.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8A73243D45 for ; Sat, 22 Oct 2005 07:15:47 +0000 (GMT) (envelope-from jiashiun@gmail.com) Received: by qproxy.gmail.com with SMTP id a39so17960qbd for ; Sat, 22 Oct 2005 00:15:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=MnXBi/d7W3YfBP0eINhCED6eROTxtFo4D4flM1oMAkaC8avCmmktbAtN/lgsCfjHvEDe8+7mqtzdY7CSbV1u74o6+WO6vNZoA/INgojU3KyXS28muX38cBF5t011UMWClzDyTJPnWJ/i8mSEOicSKOWfsTpPe9PrDXuUd8XOGQI= Received: by 10.65.236.18 with SMTP id n18mr23033qbr; Sat, 22 Oct 2005 00:15:46 -0700 (PDT) Received: by 10.65.105.15 with HTTP; Sat, 22 Oct 2005 00:15:46 -0700 (PDT) Message-ID: <1d6d20bc0510220015h5e0c11f7s@mail.gmail.com> Date: Sat, 22 Oct 2005 15:15:46 +0800 From: Jia-Shiun Li To: Eischen , Konstantinos Boukis In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <1129939027.43598053423cb@impmail.kcl.ac.uk> Cc: freebsd-threads@freebsd.org Subject: Re: kernel upcall documentation X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2005 07:15:48 -0000 2005/10/22, Daniel Eischen : > On Sat, 22 Oct 2005, Konstantinos Boukis wrote: > > > I tried not to bombard you with all the information of what I am doing = but it > > seems inevitable ;-). I am working on a theoretical research project an= d the > > goal is to develop a mobile terminal (e.g. one that changes network > > continuously) that will be able to adapt to the offered mobility protoc= ols > > (i.e. like Mobile IP) offered by the network. In my implementation the = kernel > > identifies the offered protocol and installs the appropriate modules. > > There are other examples to look at, like devd. Actually, I don't > see why you can't just use devd. From devd(8): > > "Another example would be for devd to use a table to locate and load = via > kldload(8) the proper driver for an unrecognized device that is adde= d to > the system." the 'upcall' looks more like a Linux way to me, for example the Linux hotplug mechanism. In general Linux tends not to separate kernel and userland jobs that clear. It is an example to call userland programs directly from kernel. One other is the proc fs. Probably because the kernel (implementers) does not really have much control over user program so they want to do all jobs themselves. But just like Daniel said, there are other ways to do the same thing and make the duties of each parts clear. Kernel sees what happen, notify and leave the decision of responding action to userland. Defining interfaces (events in this example) is the key. Jia-Shiun.