From owner-freebsd-arch@FreeBSD.ORG Sat Oct 25 13:20:44 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7BCF120F for ; Sat, 25 Oct 2014 13:20:44 +0000 (UTC) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 14136760 for ; Sat, 25 Oct 2014 13:20:43 +0000 (UTC) Received: by mail-wg0-f51.google.com with SMTP id b13so2776434wgh.22 for ; Sat, 25 Oct 2014 06:20:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=RRrYWh3AWV3ZNE09mM1Il03iZtqdhpGjMAIDhcuN1vE=; b=nVPkfZGI4yHKGp9KkB+uY5jKTw6WLQJNnL507XqJT69AD/tXDdeaKFm6UGt1dQYn6o jDzvlsKouN8fhnPKZkNWp/tqUv2xdW+bMHE3yk+I60X9Ki9jwa1QhczoiPE91P+E216c D+qvCKHw2LGv10Ri4vSzvXWutOzwFP39awPglZWMGsJq9UmUw/cPPSuK0O2340WNhZ/l qOjA3RHU+cq8JNcn/JmTUjCmm12tnU5TwMF2OlPcStlqWTpOQZOop+9ol/MtXub8BZCQ CACtakSGVVUMFcZwIe1WbAOoDYdu0zxpSlZWQkvOFrQ7B16F4ssfyPyNaUQ6c4h++1ge Mf5A== X-Received: by 10.180.212.42 with SMTP id nh10mr10296876wic.52.1414243242298; Sat, 25 Oct 2014 06:20:42 -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 f7sm5121911wiz.13.2014.10.25.06.20.41 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sat, 25 Oct 2014 06:20:41 -0700 (PDT) Date: Sat, 25 Oct 2014 15:20:39 +0200 From: Mateusz Guzik To: Konstantin Belousov Subject: Re: syscalls from loadable modules compiled in statically into the kernel Message-ID: <20141025132039.GA20599@dft-labs.eu> References: <20141025022808.GA14551@dft-labs.eu> <20141025092234.GI1877@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20141025092234.GI1877@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Oct 2014 13:20:44 -0000 On Sat, Oct 25, 2014 at 12:22:34PM +0300, Konstantin Belousov wrote: > On Sat, Oct 25, 2014 at 04:28:09AM +0200, Mateusz Guzik wrote: > > The kernel has the following mechanism: > > > > int > > syscall_thread_enter(struct thread *td, struct sysent *se) > > { > > u_int32_t cnt, oldcnt; > > > > do { > > oldcnt = se->sy_thrcnt; > > if ((oldcnt & SY_THR_STATIC) != 0) > > return (0); > > if ((oldcnt & (SY_THR_DRAINING | SY_THR_ABSENT)) != 0) > > return (ENOSYS); > > cnt = oldcnt + SY_THR_INCR; > > } while (atomic_cmpset_acq_32(&se->sy_thrcnt, oldcnt, cnt) == 0); > > return (0); > > } > > > > Except it turns out that it is used even if given module (here: sysvshm) is > > compiled in statically. > > > > So my proposal is to give modules an easy way to tell whether they got > > compiled in and extend syscall_register interface so that it would allow > > registering static syscalls. > > > > The latter could also be used by modules which are loadable, but don't > > support unloads. > > > > I don't have any good idea how to provide aforementioned detection > > method though. > The method would be a combination of some change to syscall_register() > and #ifdef KLD_MODULE. Look at the sys/conf.h MAKEDEV_ETERNAL_KLD > definition, which provides similar in spirit optimization for > non-destructable cdevs. > Ok, so I'll add sysctl_register_flags and SY_THR_STATIC_KLD + making sure SY_THR_STATIC cannot be unregistered. > > > > Also, please see https://reviews.freebsd.org/D1007 which moves > > SY_THR_STATIC check to an inline function, saving us 2 function calls on > > each syscall. > > Did you benchmarked this ? I dislike the code bloat. with syscall_timing from tools/tools ministat says +4% for getuid and +1 for pipe+close. -- Mateusz Guzik