From owner-freebsd-arch@FreeBSD.ORG Sun Oct 21 13:00:03 2007 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A519116A41A for ; Sun, 21 Oct 2007 13:00:03 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4014813C48D for ; Sun, 21 Oct 2007 12:58:53 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id E5E3048D39 for ; Sun, 21 Oct 2007 08:57:51 -0400 (EDT) Date: Sun, 21 Oct 2007 13:57:51 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: arch@FreeBSD.org In-Reply-To: <20071020184330.C70919@fledge.watson.org> Message-ID: <20071021135243.M70919@fledge.watson.org> References: <20071020184330.C70919@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: Re: Lock profiling results on TCP and an 8.x project X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Oct 2007 13:00:03 -0000 On Sat, 20 Oct 2007, Robert Watson wrote: > * When talking about percentage of available CPUs, I make the assumption > that > due to a sufficient quantity of CPUs, in most cases lock acquisition will > occur as a result of adaptive spinning rather than sleeping. In the > netperf > case, this is not true, since the number of potential workers exceeds the > number of CPUs, hence the turnstile contention. However, as sleeping on > locks itself is very expensive, it's reasonable to assume we would recover > a lot of CPU none-the-less. FYI, a feature request for lock profiling: it would be nice if we also tracked for each contention point time spent spinning vs. context switched waiting for the lock, and the number of context switches the lock acquisition point has caused. This would allow us to better understand the impact of adaptive lock behavior for workloads and configurations. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-arch@FreeBSD.ORG Sun Oct 21 20:09:08 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6BB7E16A418 for ; Sun, 21 Oct 2007 20:09:08 +0000 (UTC) (envelope-from freebsd-arch@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 3839E13C4BC for ; Sun, 21 Oct 2007 20:09:08 +0000 (UTC) (envelope-from freebsd-arch@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Ija2w-0002A0-P7 for freebsd-arch@freebsd.org; Sun, 21 Oct 2007 12:36:46 +0000 Received: from 89-172-36-59.adsl.net.t-com.hr ([89.172.36.59]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 21 Oct 2007 12:36:46 +0000 Received: from ivoras by 89-172-36-59.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 21 Oct 2007 12:36:46 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-arch@freebsd.org From: Ivan Voras Date: Sun, 21 Oct 2007 14:36:12 +0200 Lines: 29 Message-ID: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE0F4F085979DCBB40E6B0848" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 89-172-36-59.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) X-Enigmail-Version: 0.95.3 Sender: news Subject: kthreads, kprocs? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Oct 2007 20:09:08 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE0F4F085979DCBB40E6B0848 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I've seen the cvs notice about kthread renaming to kprocs, and I wonder why - what's the need for "proper" kthreads and how will it be different from current implementation of kprocs? Will it mimic userland to form a "hierarchy": processes have threads? Why, since all the kernel is a single context wrt memory protection? --------------enigE0F4F085979DCBB40E6B0848 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHG0e8ldnAQVacBcgRAtw6AKD0v+dAFC/njlkshzo4MZLWtDhcwACgzrpj kVcY2kiy3VUoaYgJvPJ1F3Q= =bVV5 -----END PGP SIGNATURE----- --------------enigE0F4F085979DCBB40E6B0848-- From owner-freebsd-arch@FreeBSD.ORG Sun Oct 21 20:33:08 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C65516A418 for ; Sun, 21 Oct 2007 20:33:08 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.176]) by mx1.freebsd.org (Postfix) with ESMTP id 6A0BD13C4A7 for ; Sun, 21 Oct 2007 20:33:08 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so1103787waf for ; Sun, 21 Oct 2007 13:32:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=fLSgI53BrOrox6aL6zu0GiZosu2dh71qjoSrfR1cgKc=; b=IL84UCYeMIFGwuBCpQADFwrOUIsxctYJDim30fwDEQQW1WlhltrZwNCy2fwTi+YBTFlRiKa1IKENirkg6AyBtPwCzZsc4vQCV13DVj8DdcMigYvIBPuyGsxEpafK1Z1JrsvTy0jn12Cn0ASlrqQBDW6nr8h/PFouPbcJ9pUMzT4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=sTDoQfuKAjR9hAbeYnRnWgd9MywiD9srK3DNZl+sQ/Szj8sZMYcXmaNQfcQ87KKN0eYU56UNb35HEsPI5fggtSAHGRL5bHDVsQNsPLNG+ZTqUNxwNC0EZy/v3QYmrJ/ADoiyYnH56aWn7LN+ouSqdIe8+zCWvlUutVR9AHsSHUk= Received: by 10.115.90.1 with SMTP id s1mr4569523wal.1192997198777; Sun, 21 Oct 2007 13:06:38 -0700 (PDT) Received: by 10.114.13.15 with HTTP; Sun, 21 Oct 2007 13:06:38 -0700 (PDT) Message-ID: Date: Sun, 21 Oct 2007 13:06:38 -0700 From: "Kip Macy" To: "Robert Watson" In-Reply-To: <20071021135243.M70919@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20071020184330.C70919@fledge.watson.org> <20071021135243.M70919@fledge.watson.org> Cc: arch@freebsd.org Subject: Re: Lock profiling results on TCP and an 8.x project X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Oct 2007 20:33:08 -0000 On 10/21/07, Robert Watson wrote: > On Sat, 20 Oct 2007, Robert Watson wrote: > > > * When talking about percentage of available CPUs, I make the assumption > > that > > due to a sufficient quantity of CPUs, in most cases lock acquisition will > > occur as a result of adaptive spinning rather than sleeping. In the > > netperf > > case, this is not true, since the number of potential workers exceeds the > > number of CPUs, hence the turnstile contention. However, as sleeping on > > locks itself is very expensive, it's reasonable to assume we would recover > > a lot of CPU none-the-less. > > FYI, a feature request for lock profiling: it would be nice if we also tracked > for each contention point time spent spinning vs. context switched waiting for > the lock, and the number of context switches the lock acquisition point has > caused. This would allow us to better understand the impact of adaptive lock > behavior for workloads and configurations. This would involve changing acquisition wait time into 3 fields: - time spent spinning - time spent context switched out - number of context switches The lock profiling object is fairly large as it is, so ideally this would happen after I've moved the lock_profile_object out of the lock_object. That is work that I've already mostly done as part of making profiling work for shared acquisitions and having it not break the ABI when enabled. Unfortunately, I haven't had time to make it commit-ready - so if someone wants to jump in and implement Robert's idea before that happens I won't object. -Kip From owner-freebsd-arch@FreeBSD.ORG Mon Oct 22 02:22:40 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D70916A421 for ; Mon, 22 Oct 2007 02:22:40 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.70]) by mx1.freebsd.org (Postfix) with ESMTP id 6213A13C4A6 for ; Mon, 22 Oct 2007 02:22:39 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (asmtp001-s [10.150.69.64]) by smtpoutm.mac.com (Xserve/smtpout007/MantshX 4.0) with ESMTP id l9L0md6V021884 for ; Sat, 20 Oct 2007 17:48:39 -0700 (PDT) Received: from [172.23.9.248] (nat-service4.juniper.net [66.129.225.151]) (authenticated bits=0) by mac.com (Xserve/asmtp001/MantshX 4.0) with ESMTP id l9L0mZpZ016919 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 20 Oct 2007 17:48:37 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <3AFF99A0-FE59-411F-94DC-D20071B211AB@mac.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: arch@freebsd.org From: Marcel Moolenaar Date: Sat, 20 Oct 2007 17:47:48 -0700 X-Mailer: Apple Mail (2.752.3) Cc: Subject: Removal of gpt(8) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2007 02:22:40 -0000 All, I'd like to remove gpt(8) from -CURRENT in the very near future (i.e. next coming weeks) and at the same time mark it obsolete in RELENG_7. If there are any objections, speak up. The background: gpt(8) was created just before the GEOM OAM API was added to GEOM. This resulted in usability issues when direct access to the underlying disk was disallowed by default. Ever since that time, gpt(8) could not be used to add or remove partitions when some other partition had a mounted file system in it. The solution was simple: Use the GEOM OAM API (ctlreq interface). Over the last 2 year the task of adding OAM support in GPT evolved into a generic partitioning class with corresponding tool according to the latest trends and standards. The generic partitioning tool currently support APM, GPT and, in a restricted form, MBR. While the generic partitioning tool needs further work to support all known partitioning schemes and support them fully, it's functionally complete for APM and GPT. The time is here to let go of the past, remove gpt(8) and commit to using gpart(8) and flesh it out further. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-arch@FreeBSD.ORG Mon Oct 22 03:42:44 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA79016A5B6 for ; Mon, 22 Oct 2007 03:42:44 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by mx1.freebsd.org (Postfix) with ESMTP id 7E09013C48D for ; Mon, 22 Oct 2007 03:42:44 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (proxy8.corp.yahoo.com [216.145.48.13]) by mrout3.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id l9M3Vtdn000843; Sun, 21 Oct 2007 20:31:57 -0700 (PDT) Date: Mon, 22 Oct 2007 11:18:56 +0900 Message-ID: From: gnn@freebsd.org To: Robert Watson In-Reply-To: <20071021135243.M70919@fledge.watson.org> References: <20071020184330.C70919@fledge.watson.org> <20071021135243.M70919@fledge.watson.org> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.7 Emacs/22.1 (i386-apple-darwin8.9.1) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: arch@freebsd.org Subject: Re: Lock profiling results on TCP and an 8.x project X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2007 03:42:44 -0000 BTW A side question. Do we have a consistent way to get such information in and out of the kernel? It would be nice to build tools to better help us visualize this sort of stuff. Of course, good work as always Robert. Best, George From owner-freebsd-arch@FreeBSD.ORG Mon Oct 22 04:23:47 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E946C16A419 for ; Mon, 22 Oct 2007 04:23:47 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.183]) by mx1.freebsd.org (Postfix) with ESMTP id C78AF13C465 for ; Mon, 22 Oct 2007 04:23:47 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so1212341waf for ; Sun, 21 Oct 2007 21:23:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=82NgSyljbpHnCfLVBBYDT9ke1AhFddzgkdafp8uBLaA=; b=JlsyCuBdUYAw4aoqp+CEjDDySkd51JTpzljNGLaKRL076KDKtmRjkl2wZsmeAqpKSZEAOyW4VK7qAWzkklk0WWjzA+g5eZP0jMEJC+eAQp1ISgBsHCyIK+7c2RvXiML8eXv4Fufl8zNCr4+jcUuQ4RoYEXS6qhxVQgzGM2vG+D0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=DTGNPF9lH7/UPFlp4uPMRUlH2VyKNoHffCrT7iLSzKY/aQ6C/QnOE0LMFN309SeksR85+h6ZcU5N0hxL1hjxyhP3ik01ia0MWMVhg0ZDmQW2W4I2FG/+j5VcfXAu0qC0cBaFAeTPOFA+uWSYRNu+5yUlhvUkZK6RoF6YC+QThok= Received: by 10.115.108.1 with SMTP id k1mr1286407wam.1193025400433; Sun, 21 Oct 2007 20:56:40 -0700 (PDT) Received: by 10.114.13.15 with HTTP; Sun, 21 Oct 2007 20:56:35 -0700 (PDT) Message-ID: Date: Sun, 21 Oct 2007 20:56:35 -0700 From: "Kip Macy" To: freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Should Xen be a sub-arch or a build option? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2007 04:23:48 -0000 Let me say in advance that this is not an invitation to discuss the technical merits of xen. This is purely a request to discuss how one would structure the tree were one to import it into CVS. Hypothetically speaking, if one were to import Xen support into CVS what would be the best way to go about it? There are a number of choices when doing it as a sub-arch: - A separate directory for i386 and amd64 - sys/xen-i386 - sys/xen-amd64 - A shared directory as most of the bits will be shared: - sys/xen - common bits - sys/xen/i386 - i386 specific bits - sys/xen/amd64 - amd64 specific bits It could, in principle, also be done as a build option. I'm not sure how well it would mesh with the existing build tools as there are a number of files that I would not want to compile in (e.g. code that talked directly to the BIOS) that is normally built by default. In that case I would structure it: - sys/i386/xen - xen specific bits for i386 - sys/amd64/xen - xen specific bits for amd64 There is also a question of where the drivers should be put. I propose that they would be put under sys/dev/xen, so you would have e.g. sys/dev/xen/xennet, sys/dev/xen/xenblk etc. -Kip From owner-freebsd-arch@FreeBSD.ORG Mon Oct 22 05:21:01 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C345B16A46E for ; Mon, 22 Oct 2007 05:21:01 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outW.internet-mail-service.net (outW.internet-mail-service.net [216.240.47.246]) by mx1.freebsd.org (Postfix) with ESMTP id ADCDB13C491 for ; Mon, 22 Oct 2007 05:21:01 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Sun, 21 Oct 2007 22:20:55 -0700 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 4FFBA126775; Sun, 21 Oct 2007 22:20:55 -0700 (PDT) Message-ID: <471C334D.9000605@elischer.org> Date: Sun, 21 Oct 2007 22:21:17 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Ivan Voras References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: kthreads, kprocs? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2007 05:21:01 -0000 Ivan Voras wrote: > Hi, > > I've seen the cvs notice about kthread renaming to kprocs, and I wonder > why - what's the need for "proper" kthreads and how will it be different > from current implementation of kprocs? Will it mimic userland to form a > "hierarchy": processes have threads? Why, since all the kernel is a > single context wrt memory protection? > well threads are lighter weight to create, and use less resources. you also increase context on the allprocs list lock (have you seen how many system processes ther eare these days?). they were processes when we didn't have threads and I'm kind of annoyed I didn't fix that when I made threads exist. SOME kernel processes NEED to be processes. The AIO helpers come to mind immediatly, but MOST don't.. here's part of a kdb 'ps' on my system right now.. 10 0 0 0 RL CPU 0 [swi4: clock sio] 1 0 1 0 SLs wait 0xc5ef5000 [init] 0 0 0 0 RLs (threaded) swapper 100013 CanRun [idle: cpu0] 100012 CanRun [idle: cpu1] 100011 CanRun [idle: cpu2] 100010 Run CPU 3 [idle: cpu3] 0 I [swapper] notice that the idle threads are just threads hanging off proc 0 as is the actual swapper thread. In the final version I think I might keep a separate 'Idle' process with NCPU threads but that's purely an aesthetic thing. unfortunatly, ps and top don't show the thread names yet but they will. From owner-freebsd-arch@FreeBSD.ORG Mon Oct 22 10:47:34 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C26A16A417 for ; Mon, 22 Oct 2007 10:47:34 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by mx1.freebsd.org (Postfix) with ESMTP id DB37F13C4B6 for ; Mon, 22 Oct 2007 10:47:32 +0000 (UTC) (envelope-from max@love2party.net) Received: from amd64.laiers.local (dslb-088-066-028-169.pools.arcor-ip.net [88.66.28.169]) by mrelayeu.kundenserver.de (node=mrelayeu4) with ESMTP (Nemesis) id 0ML21M-1IjuoJ0nKZ-0002Dy; Mon, 22 Oct 2007 12:47:03 +0200 From: Max Laier Organization: FreeBSD To: freebsd-arch@freebsd.org Date: Mon, 22 Oct 2007 12:46:52 +0200 User-Agent: KMail/1.9.7 References: In-Reply-To: X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2660110.uE77fQ4EcL"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200710221247.01695.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1/NbQ5Py4+UpVzFJAPYWB/QZEgX9UKP6srCxoD gtnJNwvmqJSE5CI+bTKqqDkHIYEQOAJiW+DPlUtgDfpLfgDhmm +hf/moL5JCdksSXJ4zgi0bkHBnCsSmLDUXDr8AFeVY= Cc: Kip Macy Subject: Re: Should Xen be a sub-arch or a build option? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2007 10:47:34 -0000 --nextPart2660110.uE77fQ4EcL Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 22 October 2007, Kip Macy wrote: > Let me say in advance that this is not an invitation to discuss the > technical merits of xen. This is purely a request to discuss how one > would structure the tree were one to import it into CVS. > > Hypothetically speaking, if one were to import Xen support into CVS > what would be the best way to go about it? > > There are a number of choices when doing it as a sub-arch: > - A separate directory for i386 and amd64 > - sys/xen-i386 > - sys/xen-amd64 This is certainly the most traditional way to do it. The fact that the=20 xen ports will share (a lot of) code with their respective parent doesn't=20 change that - pc98 is the precedent here. As it would also allow us to=20 treat xen as any other architecture without having to spread hacks all=20 over the build tools. I'd like to see us moving towards a separate arch/ directory in the long=20 run, but that belongs - with the new VCS discussion - somewhere else. > There is also a question of where the drivers should be put. I propose > that they would be put under sys/dev/xen, so you would have e.g. > sys/dev/xen/xennet, sys/dev/xen/xenblk etc. The existence of these drivers are also a reason - to me at least - to=20 keep xen as a platform of its own. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart2660110.uE77fQ4EcL Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBHHH+lXyyEoT62BG0RAr2NAJ4ybjENf9PU3X8Iypg93NkRkp0uFgCfVNol 0ZDrcggQ7mH2XGGXbT+J46A= =3s1t -----END PGP SIGNATURE----- --nextPart2660110.uE77fQ4EcL-- From owner-freebsd-arch@FreeBSD.ORG Mon Oct 22 11:21:13 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62D1216A419 for ; Mon, 22 Oct 2007 11:21:13 +0000 (UTC) (envelope-from freebsd-arch@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 1726513C4B0 for ; Mon, 22 Oct 2007 11:21:12 +0000 (UTC) (envelope-from freebsd-arch@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IjvKt-0003Cf-39 for freebsd-arch@freebsd.org; Mon, 22 Oct 2007 11:20:43 +0000 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 22 Oct 2007 11:20:43 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 22 Oct 2007 11:20:43 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-arch@freebsd.org From: Ivan Voras Date: Mon, 22 Oct 2007 13:22:11 +0200 Lines: 22 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.6 (X11/20070801) In-Reply-To: Sender: news Subject: Re: Should Xen be a sub-arch or a build option? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2007 11:21:13 -0000 Kip Macy wrote: > It could, in principle, also be done as a build option. I'm not sure > how well it would mesh with the existing build tools as there are a > number of files that I would not want to compile in (e.g. code that > talked directly to the BIOS) that is normally built by default. In > that case I would structure it: > > - sys/i386/xen - xen specific bits for i386 > - sys/amd64/xen - xen specific bits for amd64 I can only speak as an end-user: could it be done so that the Xen-enabled kernel is bootable on a normal non-virtualized machine? In this case it would be ideal if it's implemented as a build option, so people can share kernels across the machines. If not, then it certainly looks like a separate architecture. > There is also a question of where the drivers should be put. I propose > that they would be put under sys/dev/xen, so you would have e.g. > sys/dev/xen/xennet, sys/dev/xen/xenblk etc. In the above case (build option), this looks reasonable. From owner-freebsd-arch@FreeBSD.ORG Mon Oct 22 11:32:59 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC28016A421; Mon, 22 Oct 2007 11:32:59 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id 3BD3613C4AA; Mon, 22 Oct 2007 11:32:58 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A55D69.dip.t-dialin.net [84.165.93.105]) by redbull.bpaserver.net (Postfix) with ESMTP id 2C24A2E0EE; Mon, 22 Oct 2007 13:32:35 +0200 (CEST) Received: from webmail.leidinger.net (webmail.Leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 53B8C5B480D; Mon, 22 Oct 2007 13:31:28 +0200 (CEST) Received: (from www@localhost) by webmail.leidinger.net (8.14.1/8.13.8/Submit) id l9MBVSW6083151; Mon, 22 Oct 2007 13:31:28 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Mon, 22 Oct 2007 13:31:27 +0200 Message-ID: <20071022133127.m6cdvrs3c4o4480c@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Mon, 22 Oct 2007 13:31:27 +0200 From: Alexander Leidinger To: John-Mark Gurney References: <200710171245.36949.jhb@freebsd.org> <20071018133949.1430dlowvks8w4kg@webmail.leidinger.net> <20071019175602.GD39759@funkthat.com> In-Reply-To: <20071019175602.GD39759@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.4) / FreeBSD-7.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-12.904, required 8, BAYES_00 -15.00, J_CHICKENPOX_27 0.60, MIME_QP_LONG_LINE 1.40, RDNS_DYNAMIC 0.10) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: arch@freebsd.org, "Constantine A. Murenin" Subject: Re: sensors fun.. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2007 11:32:59 -0000 Quoting John-Mark Gurney (from Fri, 19 =20 Oct 2007 10:56:02 -0700): > Alexander Leidinger wrote this message on Thu, Oct 18, 2007 at 13:39 +0200= : >> One level is in the kernel. It's just an export interface to transfer >> status data from the kernel to userland. The goal of this framework is >> IMO to "collect" all this data in the kernel and provide a single >> point of contact for the userland to query this in-kernel data. That's >> what the soc project was about. Let's call this kernel sensors >> framework here. > > The project may have been about that, but what was committed included > more than that (systat and sensord)... systat shows what we have in hw.sensors. It allows users to use it =20 already now. systat takes just a peek at it and displays it. It is not =20 supposed to be a single-system monitoring solution, it just displays =20 some kernel values like top and ps and the rest of systat does. John =20 mentioned some kind of abstraction layer (a lib) to hide the =20 implementation detail of the transport interface between the kernel =20 and the userland. That's a good idea. I don't see where it is not =20 possible to convert systat to such an abstraction layer (a lib) when =20 it is available. In the mean time other people can add more sensors =20 and are able test if it works with an easy tool. For sensorsd: it's a tool to log some events to syslog, it's not a =20 fully developed single-system monitoring tool. You want to have log =20 traces somewhere when something goes wrong. And it doesn't make sense =20 to me to keep the decission making process -- when is is ok to log =20 something and when not based upon a config file -- in the kernel. This =20 is something what can be done in userland and doesn't need kernel =20 code. Like Poul mentioned, as much as possible shall be done in the =20 userland. And sensorsd can also be converted to use a library to =20 access the hw.sensors interface. Or maybe even removed, in case =20 FreeBSD get's a single-system sensors framework which takes care about =20 this. > It does look like you are finally understanding what we have been > talking about.. so I won't comment on the rest of it.. Sorry, but this is my point of view since a long time. That's nothing =20 I developed just recently. I will answer to your mail where I talked =20 about access to ISA stuff as time permits (maybe after I return from =20 hospital in a week or two), and I try to do it in a verbose way so =20 that the picture about Constantine's sensors framework is more clear =20 (I hope). And what you are talking about, doesn't seem to be what Poul is =20 talking about. For example what Poul proposes in the thread here on =20 arch (I've only read until the messages from Friday afternoon local =20 time, but will catch up later) needs much more "business logic" in the =20 kernel. If he wants to to an ioctl to tell the driver the polling =20 interval, then this exceeds the pure transport layer idea and moves a =20 lot of infrastructure which belongs IMO into a single-system sensors =20 framework (timers for sensors which are not event driven, trigger =20 values for sensors which measure analogue things, ...), but not in a =20 kernel sensors framework. I can see benefits for something what he =20 proposes in some cases (when events need to be reported very very =20 fast), but all those cases I can come up with where this is needed to =20 be in the kernel instead of in the userland, involves questions like =20 the maximum time until an event has to be reported to an application, =20 and if/how the FreeBSD kernel is able to fulfill such requirements. If =20 something like this is only needed in very few cases, I don't think =20 the kernel framework should be designed around that minority. The =20 cases I can come up with are where the monitoring is not monitoring of =20 the system (FreeBSD PC), but of something external. Something where =20 the purpose of the system is to take care about some (e.g., life-) =20 critical "application/service/device/...". I think those are special =20 situations which may need special handling of such things. Something =20 where a generic framework (and we all know that something what is =20 supposed to be to work in a lot of cases often trades in simplicity to =20 use and abstraction with speed and direct access) is in the way of the =20 very special needs of the goal at hand in such a situation. For those =20 reasons I asked several questions to Poul here in this thread (I don't =20 assume I know every possible use-case), unfortunately he told me he is =20 not interested in answering me those questions. What Poul proposes =20 contradicts the pure transport layer idea you are talking about (and I =20 think Constantines kernel sensors framework is an implementation of =20 such a transport layer). As you are interested in a lean and mean =20 kernel implementation, maybe you (or someone else) can answer me the =20 questions I directed to Poul (in case you support him regarding this =20 part too, and in case this was not answered in arch@ already since =20 Friday afternoon (I will catch up with the discussion on arch@ later)) =20 to let me understand why a lot of code which would reside in userland =20 (with e.g., Constantine's sensors framework or some other =20 implementation) would need to move into the kernel with the =20 architecture Poul proposes. Bye, Alexander. P.S.: When I don't answer immediately to answers or questions, it's =20 not because I don't want to answer. I will answer when I'm back from =20 hospital. --=20 Disraeli was pretty close: actually, there are Lies, Damn lies, Statistics, Benchmarks, and Delivery dates. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 From owner-freebsd-arch@FreeBSD.ORG Mon Oct 22 11:38:22 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5ABE16A418 for ; Mon, 22 Oct 2007 11:38:22 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by mx1.freebsd.org (Postfix) with ESMTP id A315D13C4DA for ; Mon, 22 Oct 2007 11:38:22 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (proxy8.corp.yahoo.com [216.145.48.13]) by mrout3.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id l9MBRW59096524; Mon, 22 Oct 2007 04:27:33 -0700 (PDT) Date: Mon, 22 Oct 2007 19:27:25 +0800 Message-ID: From: gnn@freebsd.org To: "Kip Macy" In-Reply-To: References: User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.7 Emacs/22.1 (i386-apple-darwin8.9.1) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: freebsd-arch@freebsd.org Subject: Re: Should Xen be a sub-arch or a build option? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2007 11:38:22 -0000 At Sun, 21 Oct 2007 20:56:35 -0700, Kip Macy wrote: > > Let me say in advance that this is not an invitation to discuss the > technical merits of xen. This is purely a request to discuss how one > would structure the tree were one to import it into CVS. > > Hypothetically speaking, if one were to import Xen support into CVS > what would be the best way to go about it? > > There are a number of choices when doing it as a sub-arch: > - A separate directory for i386 and amd64 > - sys/xen-i386 > - sys/xen-amd64 > - A shared directory as most of the bits will be shared: > - sys/xen - common bits > - sys/xen/i386 - i386 specific bits > - sys/xen/amd64 - amd64 specific bits > If most of the bits will be shared, then lets share them, that is, use the second proposal. I couldn't find a good example in the tree for a precedent, though the powerpc might come close, with its powermac and powerpc sub-directories. > It could, in principle, also be done as a build option. I'm not sure > how well it would mesh with the existing build tools as there are a > number of files that I would not want to compile in (e.g. code that > talked directly to the BIOS) that is normally built by default. In > that case I would structure it: > > - sys/i386/xen - xen specific bits for i386 > - sys/amd64/xen - xen specific bits for amd64 > > > There is also a question of where the drivers should be put. I propose > that they would be put under sys/dev/xen, so you would have e.g. > sys/dev/xen/xennet, sys/dev/xen/xenblk etc. Yes, this makes sense too. Thanks, George From owner-freebsd-arch@FreeBSD.ORG Mon Oct 22 12:08:14 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C938616A417 for ; Mon, 22 Oct 2007 12:08:14 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 857FB13C48E for ; Mon, 22 Oct 2007 12:08:14 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 01C2420A0; Mon, 22 Oct 2007 13:50:28 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id E2EDA209F; Mon, 22 Oct 2007 13:50:27 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id A0C048448C; Mon, 22 Oct 2007 13:50:26 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Kip Macy" References: Date: Mon, 22 Oct 2007 13:50:26 +0200 In-Reply-To: (Kip Macy's message of "Sun\, 21 Oct 2007 20\:56\:35 -0700") Message-ID: <86lk9ve5bx.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arch@freebsd.org Subject: Re: Should Xen be a sub-arch or a build option? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2007 12:08:14 -0000 "Kip Macy" writes: > Let me say in advance that this is not an invitation to discuss the > technical merits of xen. This is purely a request to discuss how one > would structure the tree were one to import it into CVS. > > Hypothetically speaking, if one were to import Xen support into CVS > what would be the best way to go about it? > > There are a number of choices when doing it as a sub-arch: > - A separate directory for i386 and amd64 > - sys/xen-i386 > - sys/xen-amd64 > - A shared directory as most of the bits will be shared: > - sys/xen - common bits > - sys/xen/i386 - i386 specific bits > - sys/xen/amd64 - amd64 specific bits > > It could, in principle, also be done as a build option. I'm not sure > how well it would mesh with the existing build tools as there are a > number of files that I would not want to compile in (e.g. code that > talked directly to the BIOS) that is normally built by default. In > that case I would structure it: > > - sys/i386/xen - xen specific bits for i386 > - sys/amd64/xen - xen specific bits for amd64 I'd say a kernel option would be the best choice; code that isn't relevant for Xen but is otherwise compiled by default can be bracketed with #ifndef XEN. > There is also a question of where the drivers should be put. I propose > that they would be put under sys/dev/xen, so you would have e.g. > sys/dev/xen/xennet, sys/dev/xen/xenblk etc. Sounds reasonable. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Mon Oct 22 16:32:26 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8996316A41B for ; Mon, 22 Oct 2007 16:32:26 +0000 (UTC) (envelope-from freebsd-arch@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 3E39313C481 for ; Mon, 22 Oct 2007 16:32:26 +0000 (UTC) (envelope-from freebsd-arch@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Ik0Br-0001e4-3l for freebsd-arch@freebsd.org; Mon, 22 Oct 2007 16:31:43 +0000 Received: from 89-172-59-139.adsl.net.t-com.hr ([89.172.59.139]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 22 Oct 2007 16:31:43 +0000 Received: from ivoras by 89-172-59-139.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 22 Oct 2007 16:31:43 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-arch@freebsd.org From: Ivan Voras Date: Mon, 22 Oct 2007 18:31:26 +0200 Lines: 26 Message-ID: References: <200710171245.36949.jhb@freebsd.org> <20071018133949.1430dlowvks8w4kg@webmail.leidinger.net> <200710181450.38224.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 89-172-59-139.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.0 (X11/20070527) In-Reply-To: <200710181450.38224.jhb@freebsd.org> Sender: news Subject: Re: sensors fun.. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2007 16:32:26 -0000 John Baldwin wrote: >I think the "public" interface that systat, > monitoring daemons, SNMP, etc. should be a userland interface that can have > multiple backends. It can pull data from a sensor implemented in userland or > a sensor implemented in the kernel. This looks very reasonable. Since it appears there's a need for two distinct types of sensors (polling / event based) and two ways of doing it (kernel / userland), and the 4 combinations can't share a lot of code or semantics, why not extend the scope of it all: - keep the OpenBSD sensors interface as the kernel-only poll-based part (Please don't underestimate the fact that it works and that it's already gained usage in other systems!) - create an event-based kernel interface - create a poll-based userland interface - create an event-based userland interface. - create an umberella userland library / interface that knows how to talk to each of them and exports a unified interface to whatever applications need it. The last 4 parts can then be ported by the other BSDs that use the first framework. (nothing's too difficult for a man that doesn't have to do it himself :) ) From owner-freebsd-arch@FreeBSD.ORG Mon Oct 22 17:25:56 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 223AA16A417 for ; Mon, 22 Oct 2007 17:25:56 +0000 (UTC) (envelope-from rink@rink.nu) Received: from mx1.rink.nu (thunderstone.rink.nu [80.112.228.34]) by mx1.freebsd.org (Postfix) with ESMTP id D0E6E13C48E for ; Mon, 22 Oct 2007 17:25:55 +0000 (UTC) (envelope-from rink@rink.nu) Received: from localhost (localhost [127.0.0.1]) by mx1.rink.nu (Postfix) with ESMTP id F0F196D445; Mon, 22 Oct 2007 19:09:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at rink.nu Received: from mx1.rink.nu ([127.0.0.1]) by localhost (thunderstone.rink.nu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aSKNeTOg779w; Mon, 22 Oct 2007 19:09:03 +0200 (CEST) Received: by mx1.rink.nu (Postfix, from userid 1000) id 3E71A6D43A; Mon, 22 Oct 2007 19:09:03 +0200 (CEST) Date: Mon, 22 Oct 2007 19:09:03 +0200 From: Rink Springer To: Kip Macy Message-ID: <20071022170903.GD2251@rink.nu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-arch@freebsd.org Subject: Re: Should Xen be a sub-arch or a build option? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2007 17:25:56 -0000 Hi Kip, On Sun, Oct 21, 2007 at 08:56:35PM -0700, Kip Macy wrote: > - A shared directory as most of the bits will be shared: > - sys/xen - common bits > - sys/xen/i386 - i386 specific bits > - sys/xen/amd64 - amd64 specific bits This is what I'd prefer - i386/amd64 as separate dir under sys/xen. > It could, in principle, also be done as a build option. I'm not sure > how well it would mesh with the existing build tools as there are a > number of files that I would not want to compile in (e.g. code that > talked directly to the BIOS) that is normally built by default. In > that case I would structure it: I wouldn't go for a build option; I'd prefer to make it seperate, as I fear making it a seperate build option would introduce needless clutter which can easily be avoided. > There is also a question of where the drivers should be put. I propose > that they would be put under sys/dev/xen, so you would have e.g. > sys/dev/xen/xennet, sys/dev/xen/xenblk etc. That sounds fine to me. -- Rink P.W. Springer - http://rink.nu "root is always right" -- the kernel From owner-freebsd-arch@FreeBSD.ORG Mon Oct 22 18:30:47 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D6BC16A417 for ; Mon, 22 Oct 2007 18:30:47 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.181]) by mx1.freebsd.org (Postfix) with ESMTP id CAAF313C4A6 for ; Mon, 22 Oct 2007 18:30:46 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so1473880waf for ; Mon, 22 Oct 2007 11:30:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=Ip4R39Hkjw2heKjTKnlsfuCqIJsJkEy6mg8pB6rT99s=; b=aBiXChlJDngq0XiJQxJq+shBosZ55TsZA3NUcn9LjlLBk+RawbK80+UBaQSLahB+iFN3Uvv10L7SpbgLz4dfTrWQOfs4kfnI1nILwh01ThVh7piH3A+1VOj2w5UaMcwhQmP5Bj+8ARzBbJDiWMIvDIiG949EIBx0EYJfHAazKRM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=kSGNH8T4Lykh2mvcvblGEMubaY6tx09d2Tb+cqihuEIBM17F7cQrbIvWUSCGisutAx8T3oynI9m8p9/dCRmeDaT8lxa/Q8+DM7+ywARH+M9QMJF7+T4+tjuTPqXAGnlGcaBgkssnyrbz8gcSW35TqPrTt9GMtwQX7yLMLgYIEic= Received: by 10.114.109.1 with SMTP id h1mr5817946wac.1193077842098; Mon, 22 Oct 2007 11:30:42 -0700 (PDT) Received: by 10.114.13.15 with HTTP; Mon, 22 Oct 2007 11:30:42 -0700 (PDT) Message-ID: Date: Mon, 22 Oct 2007 11:30:42 -0700 From: "Kip Macy" To: "=?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?=" In-Reply-To: <86lk9ve5bx.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <86lk9ve5bx.fsf@ds4.des.no> Cc: freebsd-arch@freebsd.org Subject: Re: Should Xen be a sub-arch or a build option? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2007 18:30:47 -0000 > I'd say a kernel option would be the best choice; code that isn't > relevant for Xen but is otherwise compiled by default can be bracketed > with #ifndef XEN. > The typical response is sub-arch - and that is what I did in my perforce branch, but I'd like to explore the build option approach as sub-arch requires a large amount of header duplication or creating headers that are empty except for including the native headers. What if, rather than putting ifndef XEN in 10 or 15 files, I instead added "native" to options.i386 and marked all those files as "native" in files.i386 and then put "native" in DEFAULTS. That would allow me to simply add "nooption native" in a XEN kernel config and disable their compilation without touching the files themselves. -Kip From owner-freebsd-arch@FreeBSD.ORG Mon Oct 22 21:38:11 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4171D16A417; Mon, 22 Oct 2007 21:38:11 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id CF16D13C4DD; Mon, 22 Oct 2007 21:38:10 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.1/8.14.1) with ESMTP id l9MLXAqO085560; Mon, 22 Oct 2007 15:33:10 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 22 Oct 2007 15:33:10 -0600 (MDT) Message-Id: <20071022.153310.74664457.imp@bsdimp.com> To: gnn@freebsd.org From: Warner Losh In-Reply-To: References: X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: kip.macy@gmail.com, freebsd-arch@freebsd.org Subject: Re: Should Xen be a sub-arch or a build option? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2007 21:38:11 -0000 > > Let me say in advance that this is not an invitation to discuss the > > technical merits of xen. This is purely a request to discuss how one > > would structure the tree were one to import it into CVS. > > > > Hypothetically speaking, if one were to import Xen support into CVS > > what would be the best way to go about it? > > > > There are a number of choices when doing it as a sub-arch: > > - A separate directory for i386 and amd64 > > - sys/xen-i386 > > - sys/xen-amd64 > > - A shared directory as most of the bits will be shared: > > - sys/xen - common bits > > - sys/xen/i386 - i386 specific bits > > - sys/xen/amd64 - amd64 specific bits > > > > If most of the bits will be shared, then lets share them, that is, use > the second proposal. I couldn't find a good example in the tree for a > precedent, though the powerpc might come close, with its powermac and > powerpc sub-directories. The embedded stuff has a lot of different 'ports' living in one directory currently. This is both good and bad. For arm, we can run on a number of different SoCs/boards and we use the config system to pull in the right bits. If you look in detail, the way this is done is to effectively have an arm base that provides most of the standard stuff, and then the kernel config for each board/class of processors pulling in standard stuff and optional stuff. It works OK. The bad part is that it totally glosses over softfloat vs FPU, endian, processor level, ABI, etc. Since that's not relevant for xen, I'll just mention it in passing. The basic thing that should determine if there's a separate architecture or just a build option is how much of the *machdep files change. If vm_machdep is totally different, then it needs to be a separate architecture (or subport ala arm/powerpc). If it is just a few ifdefs in a couple of places to do extra thing, assume certain things, etc, then it could be as little as a build option. pc98 goes the full architecture route. However, it does a reach-over to grab shared code. This works out well in practice, since there are kernel <-> userland interface differences ebtween pc98 and i386. The number of these is small (mostly relating to video modes and disk layout issues, iirc), but enough that this arrangement works well. If XEN has a lot of userland/kernel differences from i386/amd64, then it would make more sense to have as its own architecture. However, the config tools depend on the architecture we return for what make calls MACHINE and MACHINE_ARCH, mostly the latter. a xen/i386 or a xen/amd64 would just be changing MACHINE not MACHINE_ARCH, so likely wouldn't break too many things. Just like pc98/i386 doesn't break things. One wrinkle, however, is that presently MACHINE uniquely defines MACHINE_ARCH. If one wanted xen for both i386 and amd64 variants, there would need to be some infrastructure work. So that argues against it. Also, if one were doing a default build on a xen/i386 machine, our current build tools would build a xen/i386 system, not a i386/i386 system. Maybe that's desirable, maybe not. If not, then that argues against going the pc98 route. > > It could, in principle, also be done as a build option. I'm not sure > > how well it would mesh with the existing build tools as there are a > > number of files that I would not want to compile in (e.g. code that > > talked directly to the BIOS) that is normally built by default. In > > that case I would structure it: > > > > - sys/i386/xen - xen specific bits for i386 > > - sys/amd64/xen - xen specific bits for amd64 > > > > There is also a question of where the drivers should be put. I propose > > that they would be put under sys/dev/xen, so you would have e.g. > > sys/dev/xen/xennet, sys/dev/xen/xenblk etc. > > Yes, this makes sense too. Having it be a build option wouldn't preclude having extra bits being pulled in for that build option. If there were extra drivers that were needed, then it is cool. >From what I've seen of xen, one could make an argument for any of the three methods that we presently use in the tree. All of them would have their pros and cons. The stongest being for build option, followed closely by subarch. If it were me, I'd look at having it be a build option, much like PAE is a build option. PAE has a bigger impact on the i386 world than xen, and it is only an option. PAE breaks kernel ABIs, while xen doesn't (as far as I know). PAE changes the size of things like vm_addr_t and bus_addr_t. I think this would fit best with our current world view and sensabilities. Just my take. Maybe there are arguments for another option that would push it in another direction, but from what I've seen so far I'm unaware of them. Warner From owner-freebsd-arch@FreeBSD.ORG Tue Oct 23 00:36:48 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A14616A468 for ; Tue, 23 Oct 2007 00:36:48 +0000 (UTC) (envelope-from ml@t-b-o-h.net) Received: from vjofn.tucs-beachin-obx-house.com (vjofn-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::5e5]) by mx1.freebsd.org (Postfix) with ESMTP id C55B113C48E for ; Tue, 23 Oct 2007 00:36:47 +0000 (UTC) (envelope-from ml@t-b-o-h.net) Received: from himinbjorg.tucs-beachin-obx-house.com (cpe-68-175-8-11.hvc.res.rr.com [68.175.8.11]) (authenticated bits=0) by vjofn.tucs-beachin-obx-house.com (8.12.9/8.12.9) with ESMTP id l9N0abYN098657 for ; Mon, 22 Oct 2007 20:36:38 -0400 (EDT) Received: from himinbjorg.tucs-beachin-obx-house.com (localhost.tucs-beachin-obx-house.com [127.0.0.1]) by himinbjorg.tucs-beachin-obx-house.com (8.13.8/8.13.6) with ESMTP id l9N0aWMT003737 for ; Mon, 22 Oct 2007 20:36:32 -0400 (EDT) (envelope-from ml@t-b-o-h.net) Received: (from tbohml@localhost) by himinbjorg.tucs-beachin-obx-house.com (8.13.8/8.13.6/Submit) id l9N0aW4C003736 for freebsd-arch@freebsd.org; Mon, 22 Oct 2007 20:36:32 -0400 (EDT) (envelope-from tbohml) From: "Tuc at T-B-O-H.NET" Message-Id: <200710230036.l9N0aW4C003736@himinbjorg.tucs-beachin-obx-house.com> To: freebsd-arch@freebsd.org Date: Mon, 22 Oct 2007 20:36:32 -0400 (EDT) X-Mailer: ELM [version 2.5 PL8] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: kernel + /dev/console + syslog X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2007 00:36:48 -0000 Hi, This is something I've been persuing on the freebsd-questions and seemed to run into a brick wall of non-answers... So I'd like to pick it up here since it was something PHK spoke about about a year ago... The problem is the /dev/console+kernel WHATEVER that outputs to syslog as "kernel:". Sendmail is sending out alot of "SYSERR" that get logged as mail.err . I have the following syslog : *.err;kern.debug;auth.notice;mail.crit /dev/console *.emerg * *.debug /var/log/spool So what happens is a normal message gets logged to the console and goes to /var/log/spool, then the /dev/console+kernel hack end up re-processing it as a "kernel:" message. Its basically constantly triggering my syslog scanner which emails me a few thousand times a day... Anyone know how to write to the console WITHOUT this happening, or without syslog repeating it? Does anyone see any problems/issues/concerns with re-writing the first line to be : *.err;kern.debug;auth.notice;mail.crit /dev/ttyv0 Thanks, Tuc From owner-freebsd-arch@FreeBSD.ORG Tue Oct 23 06:58:52 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D812916A417 for ; Tue, 23 Oct 2007 06:58:52 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 9585313C465 for ; Tue, 23 Oct 2007 06:58:52 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 0DBDB2095; Tue, 23 Oct 2007 08:58:38 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 85AC1208D; Tue, 23 Oct 2007 08:58:37 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id 71D3284499; Tue, 23 Oct 2007 08:58:37 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Kip Macy" References: <86lk9ve5bx.fsf@ds4.des.no> Date: Tue, 23 Oct 2007 08:58:37 +0200 In-Reply-To: (Kip Macy's message of "Mon\, 22 Oct 2007 11\:30\:42 -0700") Message-ID: <86sl42mi5e.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arch@freebsd.org Subject: Re: Should Xen be a sub-arch or a build option? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2007 06:58:53 -0000 "Kip Macy" writes: > What if, rather than putting ifndef XEN in 10 or 15 files, I instead > added "native" to options.i386 and marked all those files as "native" > in files.i386 and then put "native" in DEFAULTS. That would allow me > to simply add "nooption native" in a XEN kernel config and disable > their compilation without touching the files themselves. or "legacy" perhaps, rather than "native". It would also be useful for anyone trying to run FreeBSD on a so-called "legacy-free" machine that doesn't have a PC-compatible BIOS (many thin clients for instance) DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Wed Oct 24 23:26:42 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C73BD16A418; Wed, 24 Oct 2007 23:26:42 +0000 (UTC) (envelope-from boris@brooknet.com.au) Received: from pecan.exetel.com.au (pecan.exetel.com.au [220.233.0.17]) by mx1.freebsd.org (Postfix) with ESMTP id 8974613C465; Wed, 24 Oct 2007 23:26:42 +0000 (UTC) (envelope-from boris@brooknet.com.au) Received: from 28.201.233.220.exetel.com.au ([220.233.201.28] helo=[192.168.100.148]) by pecan.exetel.com.au with esmtp (Exim 4.63) (envelope-from ) id 1Ikmut-0001e6-C8; Thu, 25 Oct 2007 06:33:27 +1000 In-Reply-To: <200710171245.36949.jhb@freebsd.org> References: <200710171245.36949.jhb@freebsd.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Sam Lawrance Date: Thu, 25 Oct 2007 06:33:49 +1000 To: John Baldwin X-Mailer: Apple Mail (2.752.3) Cc: arch@freebsd.org Subject: Re: sensors fun.. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2007 23:26:42 -0000 On 18/10/2007, at 2:45 AM, John Baldwin wrote: > [Trying to redirect this off cvs-all & friends.. ] > > So as I said previously, I thought about this some more offline > last night / > this morning and looked at the code some and here are my thoughts: > > Things I like about the current sensors code: > > - I like the actual sensor object used to represent a sensor. It > has a few > basic things like a string for a name, a type (I would have just done > a "units" for the value, but the type is basically that), and a > basic alarm > state. (I might have done 4 states, think green, yellow, orange, > red mapped > to good, warning, critical, bad. However, the 3 states in the > current code > is fine. 4 states might be overkill.) Perhaps an "unknown" state would be useful for those times when things aren't going quite right. From owner-freebsd-arch@FreeBSD.ORG Thu Oct 25 11:50:31 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1031D16A420; Thu, 25 Oct 2007 11:50:31 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id E6F2513C48A; Thu, 25 Oct 2007 11:50:30 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 51AB646F3E; Thu, 25 Oct 2007 07:50:30 -0400 (EDT) Date: Thu, 25 Oct 2007 12:50:30 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Warner Losh In-Reply-To: <20071022.153310.74664457.imp@bsdimp.com> Message-ID: <20071025124816.N16146@fledge.watson.org> References: <20071022.153310.74664457.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: gnn@freebsd.org, freebsd-arch@freebsd.org, kip.macy@gmail.com Subject: Re: Should Xen be a sub-arch or a build option? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2007 11:50:31 -0000 On Mon, 22 Oct 2007, Warner Losh wrote: > If it were me, I'd look at having it be a build option, much like PAE is a > build option. PAE has a bigger impact on the i386 world than xen, and it is > only an option. PAE breaks kernel ABIs, while xen doesn't (as far as I > know). PAE changes the size of things like vm_addr_t and bus_addr_t. I > think this would fit best with our current world view and sensabilities. I have to admit that I find the novelty and simplicity of "options XEN" pretty appealing -- I also had been thinking only in terms of a sub-arch and the associated paperwork. I guess the real question is what we lose by doing this -- will ps(1), vmstat(8), kgdb(8), etc, all work transparently across i386 and i386+xen? Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-arch@FreeBSD.ORG Fri Oct 26 07:03:27 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3547E16A41B for ; Fri, 26 Oct 2007 07:03:27 +0000 (UTC) (envelope-from dojo-interest-bounces@dojotoolkit.org) Received: from turtle.dojotoolkit.org (turtle.dojotoolkit.org [64.93.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id 1F0A313C48D for ; Fri, 26 Oct 2007 07:03:26 +0000 (UTC) (envelope-from dojo-interest-bounces@dojotoolkit.org) Received: from turtle.dojotoolkit.org (localhost.localdomain [127.0.0.1]) by turtle.dojotoolkit.org (Postfix) with ESMTP id 5D1AD23F856 for ; Fri, 26 Oct 2007 06:42:28 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit From: dojo-interest-bounces@dojotoolkit.org To: arch@freebsd.org Message-ID: Date: Fri, 26 Oct 2007 06:42:24 +0000 Precedence: bulk X-BeenThere: dojo-interest@dojotoolkit.org X-Mailman-Version: 2.1.9 X-List-Administrivia: yes Sender: dojo-interest-bounces@dojotoolkit.org Errors-To: dojo-interest-bounces@dojotoolkit.org Cc: Subject: Your message to Dojo-interest awaits moderator approval X-BeenThere: freebsd-arch@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2007 07:03:27 -0000 Your mail to 'Dojo-interest' with the subject (no subject) Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: http://dojotoolkit.org/mailman/confirm/dojo-interest/9185c47f4248440987e7b0e2ede6c04c06321718 From owner-freebsd-arch@FreeBSD.ORG Fri Oct 26 15:49:29 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5842616A418 for ; Fri, 26 Oct 2007 15:49:29 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (meestal-mk5.stack.nl [IPv6:2001:610:1108:5010::149]) by mx1.freebsd.org (Postfix) with ESMTP id 1A42F13C4A3 for ; Fri, 26 Oct 2007 15:49:29 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 47E733FE1F; Fri, 26 Oct 2007 17:49:28 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id 2FD07228C5; Fri, 26 Oct 2007 17:49:28 +0200 (CEST) Date: Fri, 26 Oct 2007 17:49:28 +0200 From: Jilles Tjoelker To: Jeff Roberson Message-ID: <20071026154927.GA13135@stack.nl> References: <20071008142928.Y912@10.0.0.1> <20071009100259.GW2180@deviant.kiev.zoral.com.ua> <200710092349.l99Nn01S073431@apollo.backplane.com> <20071009182046.J912@10.0.0.1> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071009182046.J912@10.0.0.1> X-Operating-System: FreeBSD 6.2-STABLE i386 User-Agent: Mutt/1.5.16 (2007-06-09) Cc: arch@freebsd.org Subject: Re: Abolishing sleeps in issignal() X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2007 15:49:29 -0000 On Tue, Oct 09, 2007 at 06:25:54PM -0700, Jeff Roberson wrote: > On Tue, 9 Oct 2007, Matthew Dillon wrote: > Sure, however, we already deal with interrupting these system calls now > either with short reads or syscall restart. The question is whether > changing the behavior to the same for SIGSTOP is a big enough change to > break things. I will see what posix has to say about it soon. >> The restart code only works if no cumulative events have occured... for >> example, if a UIO has not been filled at all (0 bytes read or written). >> ERESTART literally moves the program counter back to the start of the >> system call and causes userland to re-execute it. >> The best compromise that I found, which I implemented for Dragonfly a >> while back, was to ignore SIGSTOP in the kernel entirely and process >> the event in userret() instead. Except for certain process control >> cases like the debugger, SIGSTOP is handled asynchronously anyway. e.g. >> when you signal a SIGSTOP the kill() system call will return before >> the target process(es) have actually stopped. It's just that the >> window >> of opportunity is fairly small when SIGSTOP is handled in tsleep, and >> somewhat bigger when it is handled in userret. That's the only hangup. > Yes this is a very good idea. However, it's also a change in behavior. The > question is, which is more disruptive? Causing restart behavior or > allowing the syscalls to continue further than they original would've. I > will consult posix and see what Linux and Solaris do in more detail. I think quite a lot of programs assume that a short read on a regular file means EOF or error, and a short write on a regular file is an error. Making SIGSTOP interrupt partial read/write would break them. On the other hand, postponing SIGSTOP handling just degrades the user experience a little (and that can be improved again as mentioned elsewhere in the thread). -- Jilles Tjoelker From owner-freebsd-arch@FreeBSD.ORG Fri Oct 26 16:59:21 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0249016A46C for ; Fri, 26 Oct 2007 16:59:21 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id BC92113C4AC for ; Fri, 26 Oct 2007 16:59:20 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.1/8.14.1) with ESMTP id l9QGdNGc095257 for ; Fri, 26 Oct 2007 09:39:23 -0700 (PDT) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.1/8.14.1/Submit) id l9QGdNkr095256 for freebsd-arch@freebsd.org; Fri, 26 Oct 2007 09:39:23 -0700 (PDT) (envelope-from obrien) Date: Fri, 26 Oct 2007 09:39:23 -0700 From: "David O'Brien" To: freebsd-arch@freebsd.org Message-ID: <20071026163923.GA95109@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD 7.0-CURRENT User-Agent: Mutt/1.5.16 (2007-06-09) Subject: Filesystem INVARIANTS X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2007 16:59:21 -0000 Hi folks, Looking at the code in sys/ufs, I think most of the "DIAGNOSTIC"s should really be "INVARIANTS"s. In fact there are no "INVARIANTS" in the filesystem code at this time. Below is a diff of what I feel should change from "DIAGNOSTIC" to "INVARIANTS". I have not yet had a chance to benchmark the impact of this change when only INVARIANTS/INVARIANTS_SUPORT and not DIAGNOSTIC is set vs. nothing set. Thoughs? Opinions? Index: ufs/ffs/ffs_alloc.c =================================================================== RCS file: /home/ncvs/src/sys/ufs/ffs/ffs_alloc.c,v retrieving revision 1.147 diff -u -p -r1.147 ffs_alloc.c --- ufs/ffs/ffs_alloc.c 10 Sep 2007 14:12:29 -0000 1.147 +++ ufs/ffs/ffs_alloc.c 26 Oct 2007 16:34:18 -0000 @@ -94,7 +94,7 @@ typedef ufs2_daddr_t allocfcn_t(struct i static ufs2_daddr_t ffs_alloccg(struct inode *, int, ufs2_daddr_t, int); static ufs2_daddr_t ffs_alloccgblk(struct inode *, struct buf *, ufs2_daddr_t); -#ifdef DIAGNOSTIC +#ifdef INVARIANTS static int ffs_checkblk(struct inode *, ufs2_daddr_t, long); #endif static ufs2_daddr_t ffs_clusteralloc(struct inode *, int, ufs2_daddr_t, int); @@ -152,7 +152,7 @@ ffs_alloc(ip, lbn, bpref, size, cred, bn fs = ip->i_fs; ump = ip->i_ump; mtx_assert(UFS_MTX(ump), MA_OWNED); -#ifdef DIAGNOSTIC +#ifdef INVARIANTS if ((u_int)size > fs->fs_bsize || fragoff(fs, size) != 0) { printf("dev = %s, bsize = %ld, size = %d, fs = %s\n", devtoname(ip->i_dev), (long)fs->fs_bsize, size, @@ -161,7 +161,7 @@ ffs_alloc(ip, lbn, bpref, size, cred, bn } if (cred == NOCRED) panic("ffs_alloc: missing credential"); -#endif /* DIAGNOSTIC */ +#endif /* INVARIANTS */ reclaimed = 0; retry: #ifdef QUOTA @@ -252,7 +252,7 @@ ffs_realloccg(ip, lbprev, bprev, bpref, bp = NULL; ump = ip->i_ump; mtx_assert(UFS_MTX(ump), MA_OWNED); -#ifdef DIAGNOSTIC +#ifdef INVARIANTS if (vp->v_mount->mnt_kern_flag & MNTK_SUSPENDED) panic("ffs_realloccg: allocation on suspended filesystem"); if ((u_int)osize > fs->fs_bsize || fragoff(fs, osize) != 0 || @@ -265,7 +265,7 @@ ffs_realloccg(ip, lbprev, bprev, bpref, } if (cred == NOCRED) panic("ffs_realloccg: missing credential"); -#endif /* DIAGNOSTIC */ +#endif /* INVARIANTS */ reclaimed = 0; retry: if (priv_check_cred(cred, PRIV_VFS_BLOCKRESERVE, 0) && @@ -506,7 +506,7 @@ ffs_reallocblks_ufs1(ap) len = buflist->bs_nchildren; start_lbn = buflist->bs_children[0]->b_lblkno; end_lbn = start_lbn + len - 1; -#ifdef DIAGNOSTIC +#ifdef INVARIANTS for (i = 0; i < len; i++) if (!ffs_checkblk(ip, dbtofsb(fs, buflist->bs_children[i]->b_blkno), fs->fs_bsize)) @@ -552,7 +552,7 @@ ffs_reallocblks_ufs1(ap) if (end_lvl == 0 || (idp = &end_ap[end_lvl - 1])->in_off + 1 >= len) { ssize = len; } else { -#ifdef DIAGNOSTIC +#ifdef INVARIANTS if (start_ap[start_lvl-1].in_lbn == idp->in_lbn) panic("ffs_reallocblk: start == end"); #endif @@ -592,7 +592,7 @@ ffs_reallocblks_ufs1(ap) bap = ebap; soff = -i; } -#ifdef DIAGNOSTIC +#ifdef INVARIANTS if (!ffs_checkblk(ip, dbtofsb(fs, buflist->bs_children[i]->b_blkno), fs->fs_bsize)) panic("ffs_reallocblks: unallocated block 2"); @@ -658,7 +658,7 @@ ffs_reallocblks_ufs1(ap) dbtofsb(fs, buflist->bs_children[i]->b_blkno), fs->fs_bsize, ip->i_number); buflist->bs_children[i]->b_blkno = fsbtodb(fs, blkno); -#ifdef DIAGNOSTIC +#ifdef INVARIANTS if (!ffs_checkblk(ip, dbtofsb(fs, buflist->bs_children[i]->b_blkno), fs->fs_bsize)) panic("ffs_reallocblks: unallocated block 3"); @@ -713,7 +713,7 @@ ffs_reallocblks_ufs2(ap) len = buflist->bs_nchildren; start_lbn = buflist->bs_children[0]->b_lblkno; end_lbn = start_lbn + len - 1; -#ifdef DIAGNOSTIC +#ifdef INVARIANTS for (i = 0; i < len; i++) if (!ffs_checkblk(ip, dbtofsb(fs, buflist->bs_children[i]->b_blkno), fs->fs_bsize)) @@ -759,7 +759,7 @@ ffs_reallocblks_ufs2(ap) if (end_lvl == 0 || (idp = &end_ap[end_lvl - 1])->in_off + 1 >= len) { ssize = len; } else { -#ifdef DIAGNOSTIC +#ifdef INVARIANTS if (start_ap[start_lvl-1].in_lbn == idp->in_lbn) panic("ffs_reallocblk: start == end"); #endif @@ -799,7 +799,7 @@ ffs_reallocblks_ufs2(ap) bap = ebap; soff = -i; } -#ifdef DIAGNOSTIC +#ifdef INVARIANTS if (!ffs_checkblk(ip, dbtofsb(fs, buflist->bs_children[i]->b_blkno), fs->fs_bsize)) panic("ffs_reallocblks: unallocated block 2"); @@ -865,7 +865,7 @@ ffs_reallocblks_ufs2(ap) dbtofsb(fs, buflist->bs_children[i]->b_blkno), fs->fs_bsize, ip->i_number); buflist->bs_children[i]->b_blkno = fsbtodb(fs, blkno); -#ifdef DIAGNOSTIC +#ifdef INVARIANTS if (!ffs_checkblk(ip, dbtofsb(fs, buflist->bs_children[i]->b_blkno), fs->fs_bsize)) panic("ffs_reallocblks: unallocated block 3"); @@ -1261,7 +1261,7 @@ ffs_hashalloc(ip, cg, pref, size, alloca int i, icg = cg; mtx_assert(UFS_MTX(ip->i_ump), MA_OWNED); -#ifdef DIAGNOSTIC +#ifdef INVARIANTS if (ITOV(ip)->v_mount->mnt_kern_flag & MNTK_SUSPENDED) panic("ffs_hashalloc: allocation on suspended filesystem"); #endif @@ -1850,7 +1850,7 @@ ffs_blkfree(ump, fs, devvp, bno, size, i ffs_snapblkfree(fs, devvp, bno, size, inum)) return; } -#ifdef DIAGNOSTIC +#ifdef INVARIANTS if ((u_int)size > fs->fs_bsize || fragoff(fs, size) != 0 || fragnum(fs, bno) + numfrags(fs, size) > fs->fs_frag) { printf("dev=%s, bno = %jd, bsize = %ld, size = %ld, fs = %s\n", @@ -1945,7 +1945,7 @@ ffs_blkfree(ump, fs, devvp, bno, size, i bdwrite(bp); } -#ifdef DIAGNOSTIC +#ifdef INVARIANTS /* * Verify allocation of a block or fragment. Returns true if block or * fragment is allocated, false if it is free. @@ -1994,7 +1994,7 @@ ffs_checkblk(ip, bno, size) brelse(bp); return (!free); } -#endif /* DIAGNOSTIC */ +#endif /* INVARIANTS */ /* * Free an inode. Index: ufs/ffs/ffs_balloc.c =================================================================== RCS file: /home/ncvs/src/sys/ufs/ffs/ffs_balloc.c,v retrieving revision 1.50 diff -u -p -r1.50 ffs_balloc.c --- ufs/ffs/ffs_balloc.c 8 Feb 2005 17:23:39 -0000 1.50 +++ ufs/ffs/ffs_balloc.c 26 Oct 2007 16:34:18 -0000 @@ -220,7 +220,7 @@ ffs_balloc_ufs1(struct vnode *vp, off_t pref = 0; if ((error = ufs_getlbns(vp, lbn, indirs, &num)) != 0) return(error); -#ifdef DIAGNOSTIC +#ifdef INVARIANTS if (num < 1) panic ("ffs_balloc_ufs1: ufs_getlbns returned indirect block"); #endif @@ -692,7 +692,7 @@ ffs_balloc_ufs2(struct vnode *vp, off_t pref = 0; if ((error = ufs_getlbns(vp, lbn, indirs, &num)) != 0) return(error); -#ifdef DIAGNOSTIC +#ifdef INVARIANTS if (num < 1) panic ("ffs_balloc_ufs2: ufs_getlbns returned indirect block"); #endif Index: ufs/ffs/ffs_inode.c =================================================================== RCS file: /home/ncvs/src/sys/ufs/ffs/ffs_inode.c,v retrieving revision 1.108 diff -u -p -r1.108 ffs_inode.c --- ufs/ffs/ffs_inode.c 1 Jun 2007 01:12:45 -0000 1.108 +++ ufs/ffs/ffs_inode.c 26 Oct 2007 16:34:18 -0000 @@ -226,7 +226,7 @@ ffs_truncate(vp, length, flags, cred, td if (vp->v_type == VLNK && (ip->i_size < vp->v_mount->mnt_maxsymlinklen || datablocks == 0)) { -#ifdef DIAGNOSTIC +#ifdef INVARIANTS if (length != 0) panic("ffs_truncate: partial truncate of symlink"); #endif @@ -479,7 +479,7 @@ ffs_truncate(vp, length, flags, cred, td } } done: -#ifdef DIAGNOSTIC +#ifdef INVARIANTS for (level = SINGLE; level <= TRIPLE; level++) if (newblks[NDADDR + level] != DIP(ip, i_ib[level])) panic("ffs_truncate1"); @@ -493,7 +493,7 @@ done: vp->v_bufobj.bo_clean.bv_cnt > 0)) panic("ffs_truncate3"); VI_UNLOCK(vp); -#endif /* DIAGNOSTIC */ +#endif /* INVARIANTS */ /* * Put back the real size. */ Index: ufs/ffs/ffs_snapshot.c =================================================================== RCS file: /home/ncvs/src/sys/ufs/ffs/ffs_snapshot.c,v retrieving revision 1.136 diff -u -p -r1.136 ffs_snapshot.c --- ufs/ffs/ffs_snapshot.c 5 Jun 2007 00:00:56 -0000 1.136 +++ ufs/ffs/ffs_snapshot.c 26 Oct 2007 16:34:18 -0000 @@ -2300,7 +2300,7 @@ ffs_copyonwrite(devvp, bp) blkno=((ufs2_daddr_t *)(ibp->b_data))[indiroff]; bqrelse(ibp); } -#ifdef DIAGNOSTIC +#ifdef INVARIANTS if (blkno == BLK_SNAP && bp->b_lblkno >= 0) panic("ffs_copyonwrite: bad copy block"); #endif Index: ufs/ffs/ffs_softdep.c =================================================================== RCS file: /home/ncvs/src/sys/ufs/ffs/ffs_softdep.c,v retrieving revision 1.212 diff -u -p -r1.212 ffs_softdep.c --- ufs/ffs/ffs_softdep.c 20 Oct 2007 23:23:23 -0000 1.212 +++ ufs/ffs/ffs_softdep.c 26 Oct 2007 16:34:18 -0000 @@ -44,8 +44,8 @@ __FBSDID("$FreeBSD: src/sys/ufs/ffs/ffs_ /* * For now we want the safety net that the DIAGNOSTIC and DEBUG flags provide. */ -#ifndef DIAGNOSTIC -#define DIAGNOSTIC +#ifndef INVARIANTS +#define INVARIANTS #endif #ifndef DEBUG #define DEBUG @@ -2782,13 +2782,13 @@ handle_workitem_freeblocks(freeblks, fla vput(vp); } -#ifdef DIAGNOSTIC +#ifdef INVARIANTS if (freeblks->fb_chkcnt != blocksreleased && ((fs->fs_flags & FS_UNCLEAN) == 0 || (flags & LK_NOWAIT) != 0)) printf("handle_workitem_freeblocks: block count\n"); if (allerror) softdep_error("handle_workitem_freeblks", allerror); -#endif /* DIAGNOSTIC */ +#endif /* INVARIANTS */ ACQUIRE_LOCK(&lk); WORKITEM_FREE(freeblks, D_FREEBLKS); @@ -3915,7 +3915,7 @@ initiate_write_inodeblock_ufs1(inodedep, */ for (deplist = 0, adp = TAILQ_FIRST(&inodedep->id_inoupdt); adp; adp = TAILQ_NEXT(adp, ad_next)) { -#ifdef DIAGNOSTIC +#ifdef INVARIANTS if (deplist != 0 && prevlbn >= adp->ad_lbn) panic("softdep_write_inodeblock: lbn order"); prevlbn = adp->ad_lbn; @@ -3937,7 +3937,7 @@ initiate_write_inodeblock_ufs1(inodedep, if ((adp->ad_state & ATTACHED) == 0) panic("softdep_write_inodeblock: Unknown state 0x%x", adp->ad_state); -#endif /* DIAGNOSTIC */ +#endif /* INVARIANTS */ adp->ad_state &= ~ATTACHED; adp->ad_state |= UNDONE; } @@ -3957,18 +3957,18 @@ initiate_write_inodeblock_ufs1(inodedep, continue; dp->di_size = fs->fs_bsize * adp->ad_lbn + adp->ad_oldsize; for (i = adp->ad_lbn + 1; i < NDADDR; i++) { -#ifdef DIAGNOSTIC +#ifdef INVARIANTS if (dp->di_db[i] != 0 && (deplist & (1 << i)) == 0) panic("softdep_write_inodeblock: lost dep1"); -#endif /* DIAGNOSTIC */ +#endif /* INVARIANTS */ dp->di_db[i] = 0; } for (i = 0; i < NIADDR; i++) { -#ifdef DIAGNOSTIC +#ifdef INVARIANTS if (dp->di_ib[i] != 0 && (deplist & ((1 << NDADDR) << i)) == 0) panic("softdep_write_inodeblock: lost dep2"); -#endif /* DIAGNOSTIC */ +#endif /* INVARIANTS */ dp->di_ib[i] = 0; } return; @@ -4059,7 +4059,7 @@ initiate_write_inodeblock_ufs2(inodedep, */ for (deplist = 0, adp = TAILQ_FIRST(&inodedep->id_extupdt); adp; adp = TAILQ_NEXT(adp, ad_next)) { -#ifdef DIAGNOSTIC +#ifdef INVARIANTS if (deplist != 0 && prevlbn >= adp->ad_lbn) panic("softdep_write_inodeblock: lbn order"); prevlbn = adp->ad_lbn; @@ -4073,7 +4073,7 @@ initiate_write_inodeblock_ufs2(inodedep, if ((adp->ad_state & ATTACHED) == 0) panic("softdep_write_inodeblock: Unknown state 0x%x", adp->ad_state); -#endif /* DIAGNOSTIC */ +#endif /* INVARIANTS */ adp->ad_state &= ~ATTACHED; adp->ad_state |= UNDONE; } @@ -4091,10 +4091,10 @@ initiate_write_inodeblock_ufs2(inodedep, continue; dp->di_extsize = fs->fs_bsize * adp->ad_lbn + adp->ad_oldsize; for (i = adp->ad_lbn + 1; i < NXADDR; i++) { -#ifdef DIAGNOSTIC +#ifdef INVARIANTS if (dp->di_extb[i] != 0 && (deplist & (1 << i)) == 0) panic("softdep_write_inodeblock: lost dep1"); -#endif /* DIAGNOSTIC */ +#endif /* INVARIANTS */ dp->di_extb[i] = 0; } lastadp = NULL; @@ -4118,7 +4118,7 @@ initiate_write_inodeblock_ufs2(inodedep, */ for (deplist = 0, adp = TAILQ_FIRST(&inodedep->id_inoupdt); adp; adp = TAILQ_NEXT(adp, ad_next)) { -#ifdef DIAGNOSTIC +#ifdef INVARIANTS if (deplist != 0 && prevlbn >= adp->ad_lbn) panic("softdep_write_inodeblock: lbn order"); prevlbn = adp->ad_lbn; @@ -4140,7 +4140,7 @@ initiate_write_inodeblock_ufs2(inodedep, if ((adp->ad_state & ATTACHED) == 0) panic("softdep_write_inodeblock: Unknown state 0x%x", adp->ad_state); -#endif /* DIAGNOSTIC */ +#endif /* INVARIANTS */ adp->ad_state &= ~ATTACHED; adp->ad_state |= UNDONE; } @@ -4160,18 +4160,18 @@ initiate_write_inodeblock_ufs2(inodedep, continue; dp->di_size = fs->fs_bsize * adp->ad_lbn + adp->ad_oldsize; for (i = adp->ad_lbn + 1; i < NDADDR; i++) { -#ifdef DIAGNOSTIC +#ifdef INVARIANTS if (dp->di_db[i] != 0 && (deplist & (1 << i)) == 0) panic("softdep_write_inodeblock: lost dep2"); -#endif /* DIAGNOSTIC */ +#endif /* INVARIANTS */ dp->di_db[i] = 0; } for (i = 0; i < NIADDR; i++) { -#ifdef DIAGNOSTIC +#ifdef INVARIANTS if (dp->di_ib[i] != 0 && (deplist & ((1 << NDADDR) << i)) == 0) panic("softdep_write_inodeblock: lost dep3"); -#endif /* DIAGNOSTIC */ +#endif /* INVARIANTS */ dp->di_ib[i] = 0; } return; Index: ufs/ffs/ffs_vnops.c =================================================================== RCS file: /home/ncvs/src/sys/ufs/ffs/ffs_vnops.c,v retrieving revision 1.173 diff -u -p -r1.173 ffs_vnops.c --- ufs/ffs/ffs_vnops.c 13 Jul 2007 18:51:08 -0000 1.173 +++ ufs/ffs/ffs_vnops.c 26 Oct 2007 16:34:18 -0000 @@ -325,7 +325,7 @@ loop: passes -= 1; goto loop; } -#ifdef DIAGNOSTIC +#ifdef INVARIANTS if (!vn_isdisk(vp, NULL)) vprint("ffs_fsync: dirty", vp); #endif @@ -443,7 +443,7 @@ ffs_read(ap) seqcount = ap->a_ioflag >> IO_SEQSHIFT; ip = VTOI(vp); -#ifdef DIAGNOSTIC +#ifdef INVARIANTS if (uio->uio_rw != UIO_READ) panic("ffs_read: mode"); @@ -645,7 +645,7 @@ ffs_write(ap) seqcount = ap->a_ioflag >> IO_SEQSHIFT; ip = VTOI(vp); -#ifdef DIAGNOSTIC +#ifdef INVARIANTS if (uio->uio_rw != UIO_WRITE) panic("ffs_write: mode"); #endif @@ -869,7 +869,7 @@ ffs_extread(struct vnode *vp, struct uio fs = ip->i_fs; dp = ip->i_din2; -#ifdef DIAGNOSTIC +#ifdef INVARIANTS if (uio->uio_rw != UIO_READ || fs->fs_magic != FS_UFS2_MAGIC) panic("ffs_extread: mode"); @@ -1031,7 +1031,7 @@ ffs_extwrite(struct vnode *vp, struct ui KASSERT(!(ip->i_flag & IN_SPACECOUNTED), ("inode %u: inode is dead", ip->i_number)); -#ifdef DIAGNOSTIC +#ifdef INVARIANTS if (uio->uio_rw != UIO_WRITE || fs->fs_magic != FS_UFS2_MAGIC) panic("ffs_extwrite: mode"); #endif Index: ufs/ufs/ufs_bmap.c =================================================================== RCS file: /home/ncvs/src/sys/ufs/ufs/ufs_bmap.c,v retrieving revision 1.66 diff -u -p -r1.66 ufs_bmap.c --- ufs/ufs/ufs_bmap.c 1 Jun 2007 01:12:45 -0000 1.66 +++ ufs/ufs/ufs_bmap.c 26 Oct 2007 16:34:18 -0000 @@ -215,7 +215,7 @@ ufs_bmaparray(vp, bn, bnp, nbp, runp, ru ap->in_exists = 1; bp = getblk(vp, metalbn, mp->mnt_stat.f_iosize, 0, 0, 0); if ((bp->b_flags & B_CACHE) == 0) { -#ifdef DIAGNOSTIC +#ifdef INVARIANTS if (!daddr) panic("ufs_bmaparray: indirect block not in cache"); #endif Index: ufs/ufs/ufs_lookup.c =================================================================== RCS file: /home/ncvs/src/sys/ufs/ufs/ufs_lookup.c,v retrieving revision 1.83 diff -u -p -r1.83 ufs_lookup.c --- ufs/ufs/ufs_lookup.c 14 Mar 2007 08:50:27 -0000 1.83 +++ ufs/ufs/ufs_lookup.c 26 Oct 2007 16:34:18 -0000 @@ -660,7 +660,7 @@ ufs_makedirentry(ip, cnp, newdirp) struct direct *newdirp; { -#ifdef DIAGNOSTIC +#ifdef INVARIANTS if ((cnp->cn_flags & SAVENAME) == 0) panic("ufs_makedirentry: missing name"); #endif Index: ufs/ufs/ufs_vnops.c =================================================================== RCS file: /home/ncvs/src/sys/ufs/ufs/ufs_vnops.c,v retrieving revision 1.292 diff -u -p -r1.292 ufs_vnops.c --- ufs/ufs/ufs_vnops.c 24 Oct 2007 19:04:04 -0000 1.292 +++ ufs/ufs/ufs_vnops.c 26 Oct 2007 16:34:25 -0000 @@ -855,7 +855,7 @@ ufs_link(ap) struct direct newdir; int error; -#ifdef DIAGNOSTIC +#ifdef INVARIANTS if ((cnp->cn_flags & HASBUF) == 0) panic("ufs_link: no name"); #endif @@ -921,7 +921,7 @@ ufs_whiteout(ap) case CREATE: /* create a new directory whiteout */ -#ifdef DIAGNOSTIC +#ifdef INVARIANTS if ((cnp->cn_flags & SAVENAME) == 0) panic("ufs_whiteout: missing name"); if (dvp->v_mount->mnt_maxsymlinklen <= 0) @@ -937,7 +937,7 @@ ufs_whiteout(ap) case DELETE: /* remove an existing directory whiteout */ -#ifdef DIAGNOSTIC +#ifdef INVARIANTS if (dvp->v_mount->mnt_maxsymlinklen <= 0) panic("ufs_whiteout: old format filesystem"); #endif @@ -998,7 +998,7 @@ ufs_rename(ap) int doingdirectory = 0, oldparent = 0, newparent = 0; int error = 0, ioflag; -#ifdef DIAGNOSTIC +#ifdef INVARIANTS if ((tcnp->cn_flags & HASBUF) == 0 || (fcnp->cn_flags & HASBUF) == 0) panic("ufs_rename: no name"); @@ -1382,7 +1382,7 @@ ufs_mkdir(ap) int error, dmode; long blkoff; -#ifdef DIAGNOSTIC +#ifdef INVARIANTS if ((cnp->cn_flags & HASBUF) == 0) panic("ufs_mkdir: no name"); #endif @@ -2227,7 +2227,7 @@ ufs_makeinode(mode, dvp, vpp, cnp) int error; pdir = VTOI(dvp); -#ifdef DIAGNOSTIC +#ifdef INVARIANTS if ((cnp->cn_flags & HASBUF) == 0) panic("ufs_makeinode: no name"); #endif -- -- David (obrien@FreeBSD.org) Q: Because it reverses the logical flow of conversation. A: Why is top-posting (putting a reply at the top of the message) frowned upon? Let's not play "Jeopardy-style quoting" From owner-freebsd-arch@FreeBSD.ORG Sat Oct 27 04:42:08 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C92D116A419 for ; Sat, 27 Oct 2007 04:42:08 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id A410913C4AC for ; Sat, 27 Oct 2007 04:42:08 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id C384A3D47B for ; Sat, 27 Oct 2007 00:25:35 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Sat, 27 Oct 2007 00:25:35 -0400 X-Sasl-enc: LkdVSKbNKfzC+XLGh4Nla7Of1kgytgvMNk6pHHQPhqpw 1193459135 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 761532701 for ; Sat, 27 Oct 2007 00:25:35 -0400 (EDT) Message-ID: <4722BDBE.5030408@incunabulum.net> Date: Sat, 27 Oct 2007 05:25:34 +0100 From: Bruce M Simpson User-Agent: Thunderbird 2.0.0.6 (X11/20070928) MIME-Version: 1.0 To: freebsd-arch@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: C++ in the kernel X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Oct 2007 04:42:08 -0000 I was wondering if anyone had done any further thinking about this. It seems a team in Iceland succeeded in making Linux C++ enabled: http://netlab.ru.is/exception/LinuxCXX.shtml Particularly interesting are the measurements for exception handling. The Click Modular Router is an example of a test case for C++ in both the Linux and FreeBSD kernels. regards, BMS From owner-freebsd-arch@FreeBSD.ORG Sat Oct 27 07:02:52 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19A3D16A418 for ; Sat, 27 Oct 2007 07:02:52 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 0C7F513C494 for ; Sat, 27 Oct 2007 07:02:51 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 11B711A4D7C; Fri, 26 Oct 2007 23:37:28 -0700 (PDT) Date: Fri, 26 Oct 2007 23:37:28 -0700 From: Alfred Perlstein To: Bruce M Simpson Message-ID: <20071027063728.GK33488@elvis.mu.org> References: <4722BDBE.5030408@incunabulum.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4722BDBE.5030408@incunabulum.net> User-Agent: Mutt/1.4.2.3i Cc: freebsd-arch@freebsd.org Subject: Re: C++ in the kernel X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Oct 2007 07:02:52 -0000 * Bruce M Simpson [071026 21:42] wrote: > I was wondering if anyone had done any further thinking about this. > > It seems a team in Iceland succeeded in making Linux C++ enabled: > http://netlab.ru.is/exception/LinuxCXX.shtml > > Particularly interesting are the measurements for exception handling. > > The Click Modular Router is an example of a test case for C++ in both > the Linux and FreeBSD kernels. Heh, Click was extremely unstable for us on both FreeBSD and Linux. I do think it would be nice to suppost at miniumum a subset of C++ in kernel, but I think someone would have to come forward to do the heavy lifting. :) -Alfred From owner-freebsd-arch@FreeBSD.ORG Sat Oct 27 10:22:11 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32A5516A417; Sat, 27 Oct 2007 10:22:11 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id A093613C48E; Sat, 27 Oct 2007 10:22:10 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 689FB17105; Sat, 27 Oct 2007 10:22:08 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.1/8.14.1) with ESMTP id l9RAM7oX012774; Sat, 27 Oct 2007 10:22:07 GMT (envelope-from phk@critter.freebsd.dk) To: Alfred Perlstein From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 26 Oct 2007 23:37:28 MST." <20071027063728.GK33488@elvis.mu.org> Date: Sat, 27 Oct 2007 10:22:07 +0000 Message-ID: <12773.1193480527@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Bruce M Simpson , freebsd-arch@freebsd.org Subject: Re: C++ in the kernel X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Oct 2007 10:22:11 -0000 In message <20071027063728.GK33488@elvis.mu.org>, Alfred Perlstein writes: >I do think it would be nice to suppost at miniumum a subset of >C++ in kernel, but I think someone would have to come forward to do >the heavy lifting. :) I think it would be nice to augment C in the kernel, but C++ would not be the correct augmentation for this purpose. Instead of repeating myself, I'll just refer to my previous ramblings on the subject and the SoC correspondence on the 'K' language experiments. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Sat Oct 27 10:50:02 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3542216A417; Sat, 27 Oct 2007 10:50:02 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id C394A13C480; Sat, 27 Oct 2007 10:50:01 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 41BEE3E014; Sat, 27 Oct 2007 06:50:01 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Sat, 27 Oct 2007 06:50:01 -0400 X-Sasl-enc: BL73daX3H9b5AS/gZQMkuCv/41R2JciBbxhQ4uJt4SEL 1193482200 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id A21CC207B7; Sat, 27 Oct 2007 06:50:00 -0400 (EDT) Message-ID: <472317D7.8010406@incunabulum.net> Date: Sat, 27 Oct 2007 11:49:59 +0100 From: Bruce M Simpson User-Agent: Thunderbird 2.0.0.6 (X11/20070928) MIME-Version: 1.0 To: Poul-Henning Kamp References: <12773.1193480527@critter.freebsd.dk> In-Reply-To: <12773.1193480527@critter.freebsd.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alfred Perlstein , freebsd-arch@freebsd.org Subject: Re: C++ in the kernel X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Oct 2007 10:50:02 -0000 Hi Poul, Thanks for the feedback. Poul-Henning Kamp wrote: > I think it would be nice to augment C in the kernel, but C++ would > not be the correct augmentation for this purpose. > I should point out that I am not recommending the habitual use of C++ for FreeBSD kernel development, nor am I condoning that we accept C++ code into the tree without any *less* consideration than might be the case for contributions in other languages (usually C). I reiterate: as per my message to Alfred, C++ makes it very easy to write bad code, but despite this, it is a very powerful tool when wielded properly. My experiences in working with C++ have been very positive, although limited because I have been very choosy about the subset of the developers, and C++ code, that happen to exist in the world... > Instead of repeating myself, I'll just refer to my previous ramblings > on the subject and the SoC correspondence on the 'K' language > experiments. > I could not find any reference to this discussion in a mailing list search. I did read the article at: http://wiki.freebsd.org/K. It sounds like a new and interesting approach to a C-like language (* see footnote). However, that was not the original topic of my thread, which is to gauge interest for C++ runtime support in FreeBSD and if anyone is already doing this. C++ is happening *now*, in other environments, it is more relevant to what people are doing in the wider world than K, so I don't see how K is analagous to C++, it would be most helpful if your discussion on this issue were more easily available. The ultimate litmus test is how it gets used and if it's a qualitative, and quantitative, improvement. regards, BMS (*) It sounds like K reinvents Microsoft's Structured Exception Handling (SEH). GCC have had a Google SoC student working on porting SEH to GCC, I contacted their SoC mentor this week to try to find out what the status of that code is. From owner-freebsd-arch@FreeBSD.ORG Sat Oct 27 10:50:25 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F93716A421; Sat, 27 Oct 2007 10:50:25 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 1630D13C465; Sat, 27 Oct 2007 10:50:25 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id C068D3FB3F; Sat, 27 Oct 2007 06:50:24 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Sat, 27 Oct 2007 06:50:24 -0400 X-Sasl-enc: yA15BHnlIbrxuRGMBHsfk7E01ZLnzO/7+zxIa+DUbVpS 1193482224 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 5024F203DC; Sat, 27 Oct 2007 06:50:24 -0400 (EDT) Message-ID: <472317EF.8040300@incunabulum.net> Date: Sat, 27 Oct 2007 11:50:23 +0100 From: Bruce M Simpson User-Agent: Thunderbird 2.0.0.6 (X11/20070928) MIME-Version: 1.0 To: Alfred Perlstein References: <4722BDBE.5030408@incunabulum.net> <20071027063728.GK33488@elvis.mu.org> In-Reply-To: <20071027063728.GK33488@elvis.mu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: C++ in the kernel X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Oct 2007 10:50:25 -0000 Alfred, Thanks for the feedback. Alfred Perlstein wrote: > Heh, Click was extremely unstable for us on both FreeBSD and Linux. > I have been working with Eddie Kohler to stop the bit-rot of the kernel support for FreeBSD and submitted a mega-patch a few months ago. Can you provide further details to me off-list of what isn't working for you? > I do think it would be nice to suppost at miniumum a subset of > C++ in kernel, but I think someone would have to come forward to do > the heavy lifting. :) > I think what the Netlab results show is that it's possible to use a relatively rich set of C++ language features in an embedded context without bloat. Certainly Bjarne Stroustrup seems to be less in favour of the 'reduced subset' approach touted a few years ago. The point being, C++ makes it very easy to write bad code, however, that is no reason to rule out its use as it is a very powerful tool when wielded correctly, as my past and current experience working on XORP has borne out. regards BMS From owner-freebsd-arch@FreeBSD.ORG Sat Oct 27 11:19:40 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A1FE16A417; Sat, 27 Oct 2007 11:19:40 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 972ED13C48D; Sat, 27 Oct 2007 11:19:39 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 2264B17105; Sat, 27 Oct 2007 11:19:38 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.1/8.14.1) with ESMTP id l9RBJbRL013152; Sat, 27 Oct 2007 11:19:37 GMT (envelope-from phk@critter.freebsd.dk) To: Bruce M Simpson From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 27 Oct 2007 11:49:59 +0100." <472317D7.8010406@incunabulum.net> Date: Sat, 27 Oct 2007 11:19:37 +0000 Message-ID: <13151.1193483977@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Alfred Perlstein , freebsd-arch@freebsd.org Subject: Re: C++ in the kernel X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Oct 2007 11:19:40 -0000 In message <472317D7.8010406@incunabulum.net>, Bruce M Simpson writes: >I could not find any reference to this discussion in a mailing list >search. I did read the article at: http://wiki.freebsd.org/K. It sounds >like a new and interesting approach to a C-like language (* see footnote). > >However, that was not the original topic of my thread, which is to gauge >interest for C++ runtime support in FreeBSD and if anyone is already >doing this. One major problem I see about a C++ runtime, is that it puts even worse constraints on our compiler situation, raising the bar significantly for any non GPLv3 compiler we might consider. K, as envisioned, has the opposite effect, it gives us a layer of isolation from the backend C-compiler, a layer which we have 100% control with, and can bend to our requirements, rather than have to live with the sometimes arbitrary and often insensitive choices by the GCC crowd. Absent actual code for a K compiler, this is largely a philosophical discussion with little applicability, but the strategic impact of supporting C++ in the kernel should not be overlooked just because of that detail. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Sat Oct 27 17:26:35 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9858716A417 for ; Sat, 27 Oct 2007 17:26:35 +0000 (UTC) (envelope-from frank@exit.com) Received: from tinker.exit.com (tinker.exit.com [206.223.0.1]) by mx1.freebsd.org (Postfix) with ESMTP id C429413C481 for ; Sat, 27 Oct 2007 17:26:34 +0000 (UTC) (envelope-from frank@exit.com) Received: from jill.exit.com (jill.exit.com [206.223.0.4]) by tinker.exit.com (8.14.1/8.14.1) with ESMTP id l9RHAWMU078246; Sat, 27 Oct 2007 10:10:32 -0700 (PDT) (envelope-from frank@exit.com) Received: from jill.exit.com (localhost [127.0.0.1]) by jill.exit.com (8.14.1/8.14.1) with ESMTP id l9RHAWJ3056309; Sat, 27 Oct 2007 10:10:32 -0700 (PDT) (envelope-from frank@exit.com) Received: (from frank@localhost) by jill.exit.com (8.14.1/8.14.1/Submit) id l9RHAVBu056308; Sat, 27 Oct 2007 10:10:32 -0700 (PDT) (envelope-from frank@exit.com) X-Authentication-Warning: jill.exit.com: frank set sender to frank@exit.com using -f From: Frank Mayhar To: Bruce M Simpson In-Reply-To: <4722BDBE.5030408@incunabulum.net> References: <4722BDBE.5030408@incunabulum.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Exit Consulting Date: Sat, 27 Oct 2007 10:10:31 -0700 Message-Id: <1193505031.3656.8.camel@jill.exit.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 FreeBSD GNOME Team Port X-Virus-Scanned: ClamAV 0.91.2/4609/Sat Oct 27 08:22:58 2007 on tinker.exit.com X-Virus-Status: Clean Cc: freebsd-arch@freebsd.org Subject: Re: C++ in the kernel X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: frank@exit.com List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Oct 2007 17:26:35 -0000 On Sat, 2007-10-27 at 05:25 +0100, Bruce M Simpson wrote: > I was wondering if anyone had done any further thinking about this. Have you looked at the Mac OSX I/O Kit? It's entirely C++ (with some pretty stringent restrictions) and is really only used for device discovery. As far as I'm concerned, it's just about the only appropriate use for C++ in the kernel and I would drop my support even for that if I were introduced to something better. I haven't yet looked at K. -- Frank Mayhar frank@exit.com http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ http://www.zazzle.com/fmayhar* From owner-freebsd-arch@FreeBSD.ORG Sat Oct 27 19:35:56 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0204816A41B for ; Sat, 27 Oct 2007 19:35:56 +0000 (UTC) (envelope-from mashtizadeh@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.182]) by mx1.freebsd.org (Postfix) with ESMTP id AE28A13C48D for ; Sat, 27 Oct 2007 19:35:55 +0000 (UTC) (envelope-from mashtizadeh@gmail.com) Received: by py-out-1112.google.com with SMTP id u77so2131061pyb for ; Sat, 27 Oct 2007 12:35:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=7KTGKaWvOGkb0L0XKVsEHLasIIMng7fTk85fQ36xFaM=; b=SyR4my2dHONTpn8hdKMbhIwYEJjlHdzqxtoZzK39iOOZbIMzT0FrFAaHutyaqmgBdF6/5yC1lyi3tNIKMB7N4eF8RuSM2NR1Hq0icH/BmRs1whZXxcnVw86WB7eXv7iP/S8fb4DPDwAmmDDU1ZrXpheu9+TkkYomv9NiAtKhJfU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=Za1J5EmiJK4ix+5RiJncbZXwyGyKWj27jBMwzRj4wuMDp2u5PWqQUvMu3KmznFM98RwBLouWQNbkhZnJtZBJ322WE56/W4z31LFUX2WWNLH3sRFMY4TDgDPJVja/lH9SjaDV5XATsKfYKbYH6HpvpL4/W/xjot0MMiTMpI1lsgk= Received: by 10.142.78.10 with SMTP id a10mr1083880wfb.1193512058831; Sat, 27 Oct 2007 12:07:38 -0700 (PDT) Received: by 10.142.254.15 with HTTP; Sat, 27 Oct 2007 12:07:38 -0700 (PDT) Message-ID: <440b3e930710271207s2a615817v7a68538bd37092c7@mail.gmail.com> Date: Sat, 27 Oct 2007 12:07:38 -0700 From: "Ali Mashtizadeh" To: frank@exit.com In-Reply-To: <1193505031.3656.8.camel@jill.exit.com> MIME-Version: 1.0 References: <4722BDBE.5030408@incunabulum.net> <1193505031.3656.8.camel@jill.exit.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Bruce M Simpson , freebsd-arch@freebsd.org Subject: Re: C++ in the kernel X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Oct 2007 19:35:56 -0000 VGhlIE1hYyBPUyBYIEkvTyBLaXQgaGFzIGEgZmFpcmx5IGNsZWFuIGludGVyZmFjZS4gSSBhY3R1 YWxseSBhZGRlZCBhIGJpdCBvZgpDKysgc3VwcG9ydCB0byBteSBvd24gRnJlZUJTRCBLZXJuZWwg YSB3aGlsZSBiYWNrLiBJZiB5b3UgZHJvcCBleGNlcHRpb25zCmFuZCBSVFRJIGl0J3MgZmFpcmx5 IGVhc3kgdG8gaW1wbGVtZW50LiBJIGRpZG4ndCBwdXQgbXVjaCBlZmZvcnQgaW50byBtYWtpbmcK YW55IEMrKyBBUEkgZm9yIGRyaXZlcnMuIEkganVzdCB1c2VkIGl0IHNvIEkgY291bGQgaGF2ZSBv YmplY3Qgb3JpZW50ZWQgY29kZQppbiB0aGUgYmFja2VuZCBvZiBhIGRyaXZlcnMuIEkgdGhpbmsg aXQncyBub3QgcmVhbGx5IHdvcnRoIGl0IGluIG1vc3QgY2FzZXMuCgpUaGUgTDQgbWljcm9rZXJu ZWwgKGh0dHA6Ly9sNGthLm9yZy8pIGhhcyB2ZXJzaW9ucyBvZiBpdHMgS2VybmVsIHdyaXR0ZW4g aW4KQysrIGFuZCB0aGV5IG1ha2UgZXh0ZW5zaXZlIHVzZSBvZiB0ZW1wbGF0ZXMuIFRoYXQgaXMg cHJvYmFibHkgdGhlIG1vc3QKc3VjY2Vzc2Z1bCB1c2Ugb2YgQysrIGluIGEgS2VybmVsIEkndmUg c2Vlbi4KCkFsaQoKT24gMTAvMjcvMDcsIEZyYW5rIE1heWhhciA8ZnJhbmtAZXhpdC5jb20+IHdy b3RlOgo+Cj4gT24gU2F0LCAyMDA3LTEwLTI3IGF0IDA1OjI1ICswMTAwLCBCcnVjZSBNIFNpbXBz b24gd3JvdGU6Cj4gPiBJIHdhcyB3b25kZXJpbmcgaWYgYW55b25lIGhhZCBkb25lIGFueSBmdXJ0 aGVyIHRoaW5raW5nIGFib3V0IHRoaXMuCj4KPiBIYXZlIHlvdSBsb29rZWQgYXQgdGhlIE1hYyBP U1ggSS9PIEtpdD8gIEl0J3MgZW50aXJlbHkgQysrICh3aXRoIHNvbWUKPiBwcmV0dHkgc3RyaW5n ZW50IHJlc3RyaWN0aW9ucykgYW5kIGlzIHJlYWxseSBvbmx5IHVzZWQgZm9yIGRldmljZQo+IGRp c2NvdmVyeS4gIEFzIGZhciBhcyBJJ20gY29uY2VybmVkLCBpdCdzIGp1c3QgYWJvdXQgdGhlIG9u bHkKPiBhcHByb3ByaWF0ZSB1c2UgZm9yIEMrKyBpbiB0aGUga2VybmVsIGFuZCBJIHdvdWxkIGRy b3AgbXkgc3VwcG9ydCBldmVuCj4gZm9yIHRoYXQgaWYgSSB3ZXJlIGludHJvZHVjZWQgdG8gc29t ZXRoaW5nIGJldHRlci4gIEkgaGF2ZW4ndCB5ZXQgbG9va2VkCj4gYXQgSy4KPiAtLQo+IEZyYW5r IE1heWhhciBmcmFua0BleGl0LmNvbSAgICAgaHR0cDovL3d3dy5leGl0LmNvbS8KPiBFeGl0IENv bnN1bHRpbmcgICAgICAgICAgICAgICAgIGh0dHA6Ly93d3cuZ3BzY2xvY2suY29tLwo+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgaHR0cDovL3d3dy5leGl0LmNvbS9ibG9nL2ZyYW5r Lwo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaHR0cDovL3d3dy56YXp6bGUuY29t L2ZtYXloYXIqCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18KPiBmcmVlYnNkLWFyY2hAZnJlZWJzZC5vcmcgbWFpbGluZyBsaXN0Cj4gaHR0cDovL2xpc3Rz LmZyZWVic2Qub3JnL21haWxtYW4vbGlzdGluZm8vZnJlZWJzZC1hcmNoCj4gVG8gdW5zdWJzY3Jp YmUsIHNlbmQgYW55IG1haWwgdG8gImZyZWVic2QtYXJjaC11bnN1YnNjcmliZUBmcmVlYnNkLm9y ZyIKPgoKCgotLSAKQWxpIE1hc2h0aXphZGVoCti52YTbjCDZhdi02KrbjCDYstin2K/Zhwo=