From owner-freebsd-arch@FreeBSD.ORG Mon Nov 5 17:58: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 45E2F16A419 for ; Mon, 5 Nov 2007 17:58:47 +0000 (UTC) (envelope-from Ben.Crowhurst@travel2.com) Received: from mx2.bt.net (mx2.bt.net [217.35.209.165]) by mx1.freebsd.org (Postfix) with ESMTP id 003F513C4A7 for ; Mon, 5 Nov 2007 17:58:46 +0000 (UTC) (envelope-from Ben.Crowhurst@travel2.com) Received: from [217.33.104.102] (helo=mailgate.travel2.com) by insmtp23 with esmtp (Exim 4.50) id 1Ip3Zc-0003cE-Vq for freebsd-arch@freebsd.org; Mon, 05 Nov 2007 15:09:09 +0000 Received: from [10.166.136.173] by travel2.com (MDaemon PRO v9.5.6) with ESMTP id md50008940792.msg for ; Mon, 05 Nov 2007 15:07:58 +0000 Message-ID: <472F31DF.4050507@travel2.com> Date: Mon, 05 Nov 2007 15:08:15 +0000 From: Ben Crowhurst User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: freebsd-arch@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-Sender: Ben.Crowhurst@travel2.com X-Spam-Processed: mailgate.travel2.com, Mon, 05 Nov 2007 15:07:58 +0000 (not processed: spam filter heuristic analysis disabled) X-MDRemoteIP: 10.166.136.173 X-Return-Path: Ben.Crowhurst@travel2.com X-Envelope-From: Ben.Crowhurst@travel2.com X-MDaemon-Deliver-To: freebsd-arch@freebsd.org X-MDAV-Processed: mailgate.travel2.com, Mon, 05 Nov 2007 15:07:59 +0000 Subject: Objective-C kernel Development X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ben.Crowhurst@travel2.com List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2007 17:58:47 -0000 Has Objective-C ever been concidered for kernel development? regards, BPC From owner-freebsd-arch@FreeBSD.ORG Mon Nov 5 18:22:17 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 353D916A41A for ; Mon, 5 Nov 2007 18:22:17 +0000 (UTC) (envelope-from mashtizadeh@gmail.com) Received: from rn-out-0102.google.com (rn-out-0910.google.com [64.233.170.191]) by mx1.freebsd.org (Postfix) with ESMTP id 8BB8113C4B3 for ; Mon, 5 Nov 2007 18:22:16 +0000 (UTC) (envelope-from mashtizadeh@gmail.com) Received: by rn-out-0102.google.com with SMTP id s42so530587rnb for ; Mon, 05 Nov 2007 10:21:56 -0800 (PST) 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=0JNG88v/W+5p9q4Qq8Keg7g5/cYaX5uWDG+yHjnW8oo=; b=s7YzDPavN38xzWJmMMX895Sjq8gragVByiHefv2IHcVVNfz2rHZFhsaPAy+481l05dCjlXDpBdbB1A861QZdLyyDI4LIxPZ2TT4VZobTX3LoHIJr6baLBYodkEMyb/79cPogKM+zU3mpN8JYvTzn/GoAGOb+7ecn+FvSQniBVCE= 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=WmySJoU/qzJteD1krL3NLKApIA89pxoVH0Y+2Kxf0HqhpKRE+d5yNMylYN2G4IRbOHzRk2mjlXpj2+HnBF13ktA9hOsqNyV3UUG8xfT7r9C1CksqEAvJkikgJNlM8lcULU5WWBJTKPvJDxsns0uo5XCOZOoEZQhV4PlMeDoLd9E= Received: by 10.142.103.6 with SMTP id a6mr1159211wfc.1194286916020; Mon, 05 Nov 2007 10:21:56 -0800 (PST) Received: by 10.142.254.15 with HTTP; Mon, 5 Nov 2007 10:21:55 -0800 (PST) Message-ID: <440b3e930711051021p778e34cfy714793dc5b7d328@mail.gmail.com> Date: Mon, 5 Nov 2007 10:21:55 -0800 From: "Ali Mashtizadeh" To: Ben.Crowhurst@travel2.com In-Reply-To: <472F31DF.4050507@travel2.com> MIME-Version: 1.0 References: <472F31DF.4050507@travel2.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: freebsd-arch@freebsd.org Subject: Re: Objective-C kernel Development 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, 05 Nov 2007 18:22:17 -0000 TW9yZSBpbnRlcmVzdGluZyBjaG9pY2VzIGFyZSBqYXZhIG9yIEMjIGp1c3QgYmVjYXVzZSB0aGV5 IGFyZSB0eXBlc2FmZSAoZS5nLjoKSlgsIHNpbmd1bGFyaXR5KS4gSSdtIG5vdCBzdXJlIHdoeSBh bnlvbmUgd291bGQgd2FudCB0byBzdWZmZXIgd2l0aCBvYmotYz8KCkFsaQoKT24gMTEvNS8wNywg QmVuIENyb3dodXJzdCA8QmVuLkNyb3dodXJzdEB0cmF2ZWwyLmNvbT4gd3JvdGU6Cj4KPiBIYXMg T2JqZWN0aXZlLUMgZXZlciBiZWVuIGNvbmNpZGVyZWQgZm9yIGtlcm5lbCBkZXZlbG9wbWVudD8K Pgo+IHJlZ2FyZHMsCj4gQlBDCj4KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXwo+IGZyZWVic2QtYXJjaEBmcmVlYnNkLm9yZyBtYWlsaW5nIGxpc3QKPiBo dHRwOi8vbGlzdHMuZnJlZWJzZC5vcmcvbWFpbG1hbi9saXN0aW5mby9mcmVlYnNkLWFyY2gKPiBU byB1bnN1YnNjcmliZSwgc2VuZCBhbnkgbWFpbCB0byAiZnJlZWJzZC1hcmNoLXVuc3Vic2NyaWJl QGZyZWVic2Qub3JnIgo+CgoKCi0tIApBbGkgTWFzaHRpemFkZWgK2LnZhNuMINmF2LTYqtuMINiy 2KfYr9mHCg== From owner-freebsd-arch@FreeBSD.ORG Mon Nov 5 22:11:42 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 786D116A418 for ; Mon, 5 Nov 2007 22:11:42 +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 2657F13C480 for ; Mon, 5 Nov 2007 22:11:42 +0000 (UTC) (envelope-from freebsd-arch@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IpAAI-00038u-D3 for freebsd-arch@freebsd.org; Mon, 05 Nov 2007 22:11:26 +0000 Received: from 89-172-61-149.adsl.net.t-com.hr ([89.172.61.149]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 05 Nov 2007 22:11:26 +0000 Received: from ivoras by 89-172-61-149.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 05 Nov 2007 22:11:26 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-arch@freebsd.org From: Ivan Voras Date: Mon, 05 Nov 2007 23:11:05 +0100 Lines: 33 Message-ID: References: <472F31DF.4050507@travel2.com> <440b3e930711051021p778e34cfy714793dc5b7d328@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2F8053FB4E60340B3C76944A" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 89-172-61-149.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) In-Reply-To: <440b3e930711051021p778e34cfy714793dc5b7d328@mail.gmail.com> X-Enigmail-Version: 0.95.5 Sender: news Subject: Re: Objective-C kernel Development 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, 05 Nov 2007 22:11:42 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2F8053FB4E60340B3C76944A Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ali Mashtizadeh wrote: > More interesting choices are java or C# just because they are typesafe = (e.g.: > JX, singularity). I'm not sure why anyone would want to suffer with obj= -c? When we're at it, why not Python? :) (I'd like to color it green...) --------------enig2F8053FB4E60340B3C76944A 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 iD8DBQFHL5T/ldnAQVacBcgRAoYkAKC3ii32jjdYgQ0Sdfh1qzvZmOModwCg8BpM uCLVy70jDfRImwnrz99DmEM= =Dj9B -----END PGP SIGNATURE----- --------------enig2F8053FB4E60340B3C76944A-- From owner-freebsd-arch@FreeBSD.ORG Mon Nov 5 22:15: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 2806616A41A for ; Mon, 5 Nov 2007 22:15:11 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (mail.bitblocks.com [64.142.15.60]) by mx1.freebsd.org (Postfix) with ESMTP id D0A6213C49D for ; Mon, 5 Nov 2007 22:15:10 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (localhost.bitblocks.com [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id 862E45B3E; Mon, 5 Nov 2007 14:15:00 -0800 (PST) To: Ivan Voras In-reply-to: Your message of "Mon, 05 Nov 2007 23:11:05 +0100." Date: Mon, 05 Nov 2007 14:15:00 -0800 From: Bakul Shah Message-Id: <20071105221500.862E45B3E@mail.bitblocks.com> Cc: freebsd-arch@freebsd.org Subject: Re: Objective-C kernel Development 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, 05 Nov 2007 22:15:11 -0000 > Ali Mashtizadeh wrote: > > More interesting choices are java or C# just because they are typesafe (e.g.: > > JX, singularity). I'm not sure why anyone would want to suffer with obj -c? > > When we're at it, why not Python? :) > > > (I'd like to color it green...) That is not changing the bikeshed color; that is changing the bikeshed with a parking lot. From owner-freebsd-arch@FreeBSD.ORG Mon Nov 5 22:16:23 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 DEA8216A469 for ; Mon, 5 Nov 2007 22:16:23 +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 BDB1713C4AA for ; Mon, 5 Nov 2007 22:16:23 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 48D4E1A4D89; Mon, 5 Nov 2007 14:16:10 -0800 (PST) Date: Mon, 5 Nov 2007 14:16:10 -0800 From: Alfred Perlstein To: Ivan Voras Message-ID: <20071105221610.GF8950@elvis.mu.org> References: <472F31DF.4050507@travel2.com> <440b3e930711051021p778e34cfy714793dc5b7d328@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-arch@freebsd.org Subject: Re: Objective-C kernel Development 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, 05 Nov 2007 22:16:24 -0000 * Ivan Voras [071105 14:11] wrote: > Ali Mashtizadeh wrote: > > More interesting choices are java or C# just because they are typesafe (e.g.: > > JX, singularity). I'm not sure why anyone would want to suffer with obj-c? > > When we're at it, why not Python? :) > > > > (I'd like to color it green...) > I think the gist of it is that the FreeBSD project will certainly consider bringing in runtime environments for just about anything, however entertaining the idea of it becoming an "official" extention and replacing or bringing in core-code that requires said runtime or language will most likely not be allowed until the tool is allowed to settle for some number of years. -- - Alfred Perlstein From owner-freebsd-arch@FreeBSD.ORG Mon Nov 5 22:20:27 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 CB69316A417 for ; Mon, 5 Nov 2007 22:20:27 +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 7B49313C480 for ; Mon, 5 Nov 2007 22:20:27 +0000 (UTC) (envelope-from freebsd-arch@m.gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1IpAIc-0004VS-GT for freebsd-arch@freebsd.org; Mon, 05 Nov 2007 22:20:02 +0000 Received: from 89-172-61-149.adsl.net.t-com.hr ([89.172.61.149]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 05 Nov 2007 22:20:02 +0000 Received: from ivoras by 89-172-61-149.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 05 Nov 2007 22:20:02 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-arch@freebsd.org From: Ivan Voras Date: Mon, 05 Nov 2007 23:16:51 +0100 Lines: 29 Message-ID: References: <472F31DF.4050507@travel2.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig80B4BE202A6CB711060E6F4B" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 89-172-61-149.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) In-Reply-To: <472F31DF.4050507@travel2.com> X-Enigmail-Version: 0.95.5 Sender: news Subject: Re: Objective-C kernel Development 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, 05 Nov 2007 22:20:27 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig80B4BE202A6CB711060E6F4B Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ben Crowhurst wrote: > Has Objective-C ever been concidered for kernel development? I haven't done anything in it, but it seems it has some good points: native compilation and similarity to C. On the other hand it's not nearly as popular and well-known as C++, doesn't have templates and not even Apple uses it in kernel (IOKit is in C++). --------------enig80B4BE202A6CB711060E6F4B 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 iD8DBQFHL5ZTldnAQVacBcgRAvr+AKDVjuIYxnBeiNGNuS51uYHYr8jGqQCbBgEa hof6tosT4wyqyR8iRXbWpck= =UO4G -----END PGP SIGNATURE----- --------------enig80B4BE202A6CB711060E6F4B-- From owner-freebsd-arch@FreeBSD.ORG Tue Nov 6 03:19:12 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 CE99516A41A; Tue, 6 Nov 2007 03:19:12 +0000 (UTC) (envelope-from bobmc@fcibroadband.com) Received: from smtp-out.fcibroadband.com (smtp-out.fcibroadband.com [64.119.104.17]) by mx1.freebsd.org (Postfix) with ESMTP id 9ADB013C4A6; Tue, 6 Nov 2007 03:19:12 +0000 (UTC) (envelope-from bobmc@fcibroadband.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp-in1.fcibroadband.com (Postfix) with ESMTP id 5356F1B1838; Mon, 5 Nov 2007 21:59:08 -0500 (EST) Received: from smtp-out1 ([127.0.0.1]) by localhost (smtp-out1 [127.0.0.1]) (amavisd-new, port 10025) with SMTP id 04787-08; Mon, 5 Nov 2007 21:59:05 -0500 (EST) Received: from [192.168.1.100] (host661461424a.dsl.res.tor.fcibroadband.com [66.146.142.74]) by smtp-out.fcibroadband.com (Postfix) with ESMTP id 836371B17F8; Mon, 5 Nov 2007 21:59:05 -0500 (EST) Message-ID: <472FE67F.90207@fcibroadband.com> Date: Mon, 05 Nov 2007 22:58:55 -0500 From: Bob McIsaac User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: Ivan Voras References: <472F31DF.4050507@travel2.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: Objective-C kernel Development X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bobmc@bobmc.net List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2007 03:19:12 -0000 Ivan Voras wrote: > Ben Crowhurst wrote: > >> Has Objective-C ever been concidered for kernel development? >> > > I haven't done anything in it, but it seems it has some good points: > native compilation and similarity to C. On the other hand it's not > nearly as popular and well-known as C++, doesn't have templates and not > even Apple uses it in kernel (IOKit is in C++). > > Higher level languages help application programmers but may not help kernel developers because different concerns and constraints apply. Performance is much more important for kernel. The memory-management and bounds checking built into some languages might hinder the kernel guys who want precise control over every aspect of kernel execution. Someone said that with C you can shoot yourself in the foot, but C++ blows your leg off. Perhaps the skill and motivation of the kernel developer is more important than the language used. -BobMc- From owner-freebsd-arch@FreeBSD.ORG Tue Nov 6 05:07: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 2E91716A419 for ; Tue, 6 Nov 2007 05:07:22 +0000 (UTC) (envelope-from info-grants@SoftHome.net) Received: from trinity.rocler.com (trinity.rocler.com [216.137.96.58]) by mx1.freebsd.org (Postfix) with ESMTP id DCAD013C4A6 for ; Tue, 6 Nov 2007 05:07:21 +0000 (UTC) (envelope-from info-grants@SoftHome.net) Received: from hfhjfhjfjf-7456hh4g (dsl-dyn-107-107.rocler.com [216.137.107.107]) by trinity.rocler.com (8.14.1/8.14.1) with ESMTP id lA63xEXZ025992 for ; Mon, 5 Nov 2007 22:59:14 -0500 From: "Canadian subsidy directory 2007" To: freebsd-arch@freebsd.org Date: Mon, 5 Nov 2007 22:59:49 -0500 MIME-Version: 1.0 Message-ID: <1194275408458b9b56d7cb25eb194fa9ab716b0749@SoftHome.net> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.63 on 216.137.96.58 Subject: =?iso-8859-1?q?Press_release_/_Communiqu=E9?= 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, 06 Nov 2007 05:07:22 -0000 (Message en francais ci-dessous) PRESS RELEASE C A N A D I A N S U B S I D Y D I R E C T O R Y Legal Deposit-National Library The Canadian Subsidy Directory 2007 is now available, newly revised it is the most complete and affordable reference for anyone looking for financing. It is the perfect tool for new and existing businesses, individuals, foundations and associations. This Publication contains more than 3200 direct and indirect financial subsidies, grants and loans offered by government departments and agencies, foundations, associations and organizations. In this new 2007 edition all programs are well described. The C a n a d i a n S u b s i d y D i r e c t o r y is the most comprehensive tool to start up a business, improve existent activities, set up a business plan, or obtain assistance from experts in fields such as: Industry, transport, agriculture, communications, municipal infrastructure, education, import-export, labour, construction and renovation, the service sector, hi-tech industries, research and development, joint ventures, arts, cinema, theatre, music and recording industry, the self employed, contests, and new talents. Assistance from and for foundations and associations, guidance to prepare a business plan, market surveys, computers, and much more! The Canadian Subsidy Directory is sold $ 69.95 (CD-ROM), $ 149.95 (Printed 430 pages) to obtain a copy please call toll free **1-866-322-3376** *********************************************** **FRANCAIS** COMMUNIQUÉ DE PRESSE Les Publications Canadiennes offrent au public une édition révisée de l' A N N U A I R E D E S S U B V E N T I O N S A U Q U É B E C contenant plus de 1900 programmes d'aides et de subventions provenant des divers paliers gouvernementaux et organismes. L' A N N U A I R E D E S S U B V E N T I O N S A U Q U É B E C est l'outil idéal soit pour démarrer son entreprise, améliorer une entreprise existante, mettre sur pied son plan d'affaires ou obtenir l'aide de conseillers experts dans le domaine des affaires: Démarrage d'entreprises, études, recherches, arts, agriculture, import export, main d'oeuvre, cinéma, prêts, promotion, bourses, théatre, transports, communications, mise sur pied et développement d'entreprises, construction et rénovation, aérospatial, concours, nouveaux talents, aide aux associations, organismes et fondations, informatique, musique, industrie du disque, plans d'affaires, études de marchés, infrastructures, aide aux travailleurs autonomes et plus encore ! Cd-rom(format .pdf).............$ 69.95 Imprimé(Cd-inclus) .............$ 149.95 Informations.....................ligne sans frais **1-866-322-3376 unsuscribe requests: use delete2007@mailcan.com From owner-freebsd-arch@FreeBSD.ORG Tue Nov 6 16:05: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 81EFA16A418 for ; Tue, 6 Nov 2007 16:05:31 +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 6296F13C4B3 for ; Tue, 6 Nov 2007 16:05:31 +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 lA6G5Mle019959 for ; Tue, 6 Nov 2007 08:05:22 -0800 (PST) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.1/8.14.1/Submit) id lA6G5M2E019958 for freebsd-arch@freebsd.org; Tue, 6 Nov 2007 08:05:22 -0800 (PST) (envelope-from obrien) Date: Tue, 6 Nov 2007 08:05:21 -0800 From: "David O'Brien" To: freebsd-arch@freebsd.org Message-ID: <20071106160521.GG18357@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: Rename sys/*/conf/DEFAULT to _DEFAULT 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: Tue, 06 Nov 2007 16:05:31 -0000 Hi folks, In the days of modern Unix, many (most?) of us have come to expect and depend on command-line completion that today's modern shells provide in order to reduce typing (and inaccurate typing). Given that premise, the "DEFAULTS" file in sys/*/conf constantly trips me up as my kernel files are named "DEO". I know others with kernel configs named with a 'D' that grumbled when command-line completion was now thwart due to "DEFAULTS". A very simple solution to this is to rename "DEFAULTS" to "_DEFAULTS". One of the purposes for DEFAULTS was to semi-hide devices and options that really aren't optional (unless you really know what you're doing) or have POLA concerns so they would not be causally removed. So this name change also puts this file to a different "name space" - and in fact may better convey "there are no user serviceable parts in here". Thoughts? -- -- 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 Tue Nov 6 16:18: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 0BBE316A420; Tue, 6 Nov 2007 16:18:14 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (cl-162.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:a1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 811E213C49D; Tue, 6 Nov 2007 16:18:13 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.1/8.13.8) with ESMTP id lA6GICtb089069; Tue, 6 Nov 2007 10:18:12 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.1/8.13.8/Submit) id lA6GIC3P089068; Tue, 6 Nov 2007 10:18:12 -0600 (CST) (envelope-from brooks) Date: Tue, 6 Nov 2007 10:18:12 -0600 From: Brooks Davis To: obrien@freebsd.org, freebsd-arch@freebsd.org Message-ID: <20071106161812.GD88328@lor.one-eyed-alien.net> References: <20071106160521.GG18357@dragon.NUXI.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MAH+hnPXVZWQ5cD/" Content-Disposition: inline In-Reply-To: <20071106160521.GG18357@dragon.NUXI.org> User-Agent: Mutt/1.5.16 (2007-06-09) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Tue, 06 Nov 2007 10:18:12 -0600 (CST) Cc: Subject: Re: Rename sys/*/conf/DEFAULT to _DEFAULT 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, 06 Nov 2007 16:18:14 -0000 --MAH+hnPXVZWQ5cD/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 06, 2007 at 08:05:21AM -0800, David O'Brien wrote: > Hi folks, > In the days of modern Unix, many (most?) of us have come to expect and > depend on command-line completion that today's modern shells provide in > order to reduce typing (and inaccurate typing). >=20 > Given that premise, the "DEFAULTS" file in sys/*/conf constantly trips me > up as my kernel files are named "DEO". I know others with kernel configs > named with a 'D' that grumbled when command-line completion was now > thwart due to "DEFAULTS". >=20 > A very simple solution to this is to rename "DEFAULTS" to "_DEFAULTS". >=20 > One of the purposes for DEFAULTS was to semi-hide devices and options > that really aren't optional (unless you really know what you're doing) or > have POLA concerns so they would not be causally removed. So this name > change also puts this file to a different "name space" - and in fact may > better convey "there are no user serviceable parts in here". >=20 > Thoughts? On one level this seems reasonable, on another, I don't see the point since on ever platform kernels beginning with G or N have this issue and on i386 you add at least S and P to that list. It's slightly annoying, but IMO not terribly important and this doesn't actually solve more than 1/3 of the problem at best so I'm not convinced. -- Brooks --MAH+hnPXVZWQ5cD/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFHMJPEXY6L6fI4GtQRAvA3AJ93d6yCIEbkX+MNq7brSFxGegtLpgCeOYXl G3HQx3/1eA3rcftyzdwe15Y= =5Qy2 -----END PGP SIGNATURE----- --MAH+hnPXVZWQ5cD/-- From owner-freebsd-arch@FreeBSD.ORG Tue Nov 6 16:39:17 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 6DEB116A494 for ; Tue, 6 Nov 2007 16:39:17 +0000 (UTC) (envelope-from jasone@freebsd.org) Received: from canonware.com (canonware.com [64.183.146.166]) by mx1.freebsd.org (Postfix) with ESMTP id 510A513C480 for ; Tue, 6 Nov 2007 16:39:12 +0000 (UTC) (envelope-from jasone@freebsd.org) Received: from [192.168.168.201] (canonware.com [64.183.146.166]) by canonware.com (Postfix) with ESMTP id DBD081298B0; Tue, 6 Nov 2007 08:24:31 -0800 (PST) Message-ID: <47309480.4050103@freebsd.org> Date: Tue, 06 Nov 2007 08:21:20 -0800 From: Jason Evans User-Agent: Thunderbird 1.5.0.12 (X11/20071018) MIME-Version: 1.0 To: obrien@freebsd.org, freebsd-arch@freebsd.org References: <20071106160521.GG18357@dragon.NUXI.org> In-Reply-To: <20071106160521.GG18357@dragon.NUXI.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Rename sys/*/conf/DEFAULT to _DEFAULT 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, 06 Nov 2007 16:39:17 -0000 David O'Brien wrote: > In the days of modern Unix, many (most?) of us have come to expect and > depend on command-line completion that today's modern shells provide in > order to reduce typing (and inaccurate typing). > > Given that premise, the "DEFAULTS" file in sys/*/conf constantly trips me > up as my kernel files are named "DEO". I know others with kernel configs > named with a 'D' that grumbled when command-line completion was now > thwart due to "DEFAULTS". > > A very simple solution to this is to rename "DEFAULTS" to "_DEFAULTS". > > One of the purposes for DEFAULTS was to semi-hide devices and options > that really aren't optional (unless you really know what you're doing) or > have POLA concerns so they would not be causally removed. So this name > change also puts this file to a different "name space" - and in fact may > better convey "there are no user serviceable parts in here". I understand your motivation, since I also heavily use completion. However, I definitely object to renaming DEFAULTS based on its potential to share a prefix with a user-created directory entry. The real solution to the completion problem is simply to become used to typing a sufficiently long prefix before prompting the shell for completion, or if this is *really* bugging you, renaming your kernel config(s). I think it would be a mistake to start making naming decisions based on potential non-uniqueness of prefixes. Now, if you were to argue that DEFAULTS steals from the set of possible kernel names, and is a land mine that users must somehow know to avoid, I'd be less inclined to protest. :-) Jason From owner-freebsd-arch@FreeBSD.ORG Tue Nov 6 16:48: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 4636E16A46E; Tue, 6 Nov 2007 16:48:02 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.freebsd.org (Postfix) with ESMTP id 2D71613C4A3; Tue, 6 Nov 2007 16:48:02 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.13.6) with ESMTP id lA6GB0UN002011; Tue, 6 Nov 2007 08:11:00 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id lA6GB0vi002010; Tue, 6 Nov 2007 08:11:00 -0800 (PST) (envelope-from rizzo) Date: Tue, 6 Nov 2007 08:11:00 -0800 From: Luigi Rizzo To: obrien@freebsd.org, freebsd-arch@freebsd.org Message-ID: <20071106081100.A1940@xorpc.icir.org> References: <20071106160521.GG18357@dragon.NUXI.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20071106160521.GG18357@dragon.NUXI.org>; from obrien@freebsd.org on Tue, Nov 06, 2007 at 08:05:21AM -0800 Cc: Subject: Re: Rename sys/*/conf/DEFAULT to _DEFAULT 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, 06 Nov 2007 16:48:02 -0000 On Tue, Nov 06, 2007 at 08:05:21AM -0800, David O'Brien wrote: > Hi folks, > In the days of modern Unix, many (most?) of us have come to expect and > depend on command-line completion that today's modern shells provide in > order to reduce typing (and inaccurate typing). > > Given that premise, the "DEFAULTS" file in sys/*/conf constantly trips me > up as my kernel files are named "DEO". I know others with kernel configs > named with a 'D' that grumbled when command-line completion was now > thwart due to "DEFAULTS". > > A very simple solution to this is to rename "DEFAULTS" to "_DEFAULTS". objection! _luigi :) From owner-freebsd-arch@FreeBSD.ORG Tue Nov 6 17:00:24 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 5509D16A417 for ; Tue, 6 Nov 2007 17:00:24 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.229]) by mx1.freebsd.org (Postfix) with ESMTP id 08D2713C4A7 for ; Tue, 6 Nov 2007 17:00:23 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so1854675wxd for ; Tue, 06 Nov 2007 09:00:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer:mime-version:content-type; bh=6h3CVCLIKX3ja2M2FSNzCuCtifwSm0ayrZoak3HT54E=; b=BXC94TTiyyNpZLrgcerqQG9vIidcXFvl1s+m+JdCSiB2ymG6h9vZymUQo8BepN7/LoL92b9AQ79ePuhn9CZo1SUgpJowoaRFEztvNEvCsbDTkABLrkN3KtnEFdkRq0h4uxqnN0Xe/Jt0vQ8OktQoIuONMRRixcetTsdHNut6SJ8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer:mime-version:content-type; b=Rn4azRh32tZ+pT0PtBE6HpClsv2nUtE7vHUM8wFx9XLNqJRBg+whupo4asGKy9fYTcXeok5c+cr2rMhL8Y37qF39CLFUmXoSXcEyvSThAup6lqv+RjCRXAYnYPWbEKdkcEToYE4q+GL7sWpbEArQZSt+gl+aSxMu8KoSJKhLXVI= Received: by 10.70.56.13 with SMTP id e13mr10397284wxa.1194366790764; Tue, 06 Nov 2007 08:33:10 -0800 (PST) Received: from kan.dnsalias.net ( [24.218.183.247]) by mx.google.com with ESMTPS id i34sm20193336wxd.2007.11.06.08.33.09 (version=SSLv3 cipher=OTHER); Tue, 06 Nov 2007 08:33:09 -0800 (PST) Date: Tue, 6 Nov 2007 11:33:03 -0500 From: Alexander Kabaev To: obrien@freebsd.org Message-ID: <20071106113303.00ff6912@kan.dnsalias.net> In-Reply-To: <20071106160521.GG18357@dragon.NUXI.org> References: <20071106160521.GG18357@dragon.NUXI.org> X-Mailer: Claws Mail 3.0.2 (GTK+ 2.12.1; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/YOuNJ/C+N3n4+24bjZqLGqE"; protocol="application/pgp-signature"; micalg=PGP-SHA1 Cc: freebsd-arch@freebsd.org Subject: Re: Rename sys/*/conf/DEFAULT to _DEFAULT 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, 06 Nov 2007 17:00:24 -0000 --Sig_/YOuNJ/C+N3n4+24bjZqLGqE Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 6 Nov 2007 08:05:21 -0800 "David O'Brien" wrote: > Hi folks, > In the days of modern Unix, many (most?) of us have come to expect and > depend on command-line completion that today's modern shells provide > in order to reduce typing (and inaccurate typing). >=20 > Given that premise, the "DEFAULTS" file in sys/*/conf constantly > trips me up as my kernel files are named "DEO". I know others with > kernel configs named with a 'D' that grumbled when command-line > completion was now thwart due to "DEFAULTS". >=20 > A very simple solution to this is to rename "DEFAULTS" to "_DEFAULTS". >=20 > One of the purposes for DEFAULTS was to semi-hide devices and options > that really aren't optional (unless you really know what you're > doing) or have POLA concerns so they would not be causally removed. > So this name change also puts this file to a different "name space" - > and in fact may better convey "there are no user serviceable parts in > here". >=20 > Thoughts? Hi, my thoughts are: gratuitous and unnecessary. Renaming _your_ config file to something else is a better alternative, IMHO. And it has no impact on others as a side benefit.=20 --=20 Alexander Kabaev --Sig_/YOuNJ/C+N3n4+24bjZqLGqE Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHMJc/Q6z1jMm+XZYRAmVJAJ9S4aI/5FVyT5M6ejWE1jwuxxW5zgCg6SZs ONNem0c7ioIMwkT31kwokXk= =wbnw -----END PGP SIGNATURE----- --Sig_/YOuNJ/C+N3n4+24bjZqLGqE-- From owner-freebsd-arch@FreeBSD.ORG Tue Nov 6 17:28: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 41DB316A417 for ; Tue, 6 Nov 2007 17:28:01 +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 2CBD213C48D for ; Tue, 6 Nov 2007 17:28:00 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 8D2551A4D80; Tue, 6 Nov 2007 09:28:00 -0800 (PST) Date: Tue, 6 Nov 2007 09:28:00 -0800 From: Alfred Perlstein To: obrien@freebsd.org, freebsd-arch@freebsd.org Message-ID: <20071106172800.GR8950@elvis.mu.org> References: <20071106160521.GG18357@dragon.NUXI.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071106160521.GG18357@dragon.NUXI.org> User-Agent: Mutt/1.4.2.3i Cc: Subject: Re: Rename sys/*/conf/DEFAULT to _DEFAULT 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, 06 Nov 2007 17:28:01 -0000 * David O'Brien [071106 08:05] wrote: > Hi folks, > In the days of modern Unix, many (most?) of us have come to expect and > depend on command-line completion that today's modern shells provide in > order to reduce typing (and inaccurate typing). > > Given that premise, the "DEFAULTS" file in sys/*/conf constantly trips me > up as my kernel files are named "DEO". I know others with kernel configs > named with a 'D' that grumbled when command-line completion was now > thwart due to "DEFAULTS". > > A very simple solution to this is to rename "DEFAULTS" to "_DEFAULTS". > > One of the purposes for DEFAULTS was to semi-hide devices and options > that really aren't optional (unless you really know what you're doing) or > have POLA concerns so they would not be causally removed. So this name > change also puts this file to a different "name space" - and in fact may > better convey "there are no user serviceable parts in here". > > Thoughts? > I would like to see this happen, in fact I would like to see all files under those directories prefixed by underscores, the reason is that I call my kernel file GRATUITOUS (for obvious reasons) and the clash with GENERIC has me about to lose my mind. -- - Alfred Perlstein From owner-freebsd-arch@FreeBSD.ORG Tue Nov 6 17:28:30 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 4FC5716A46B for ; Tue, 6 Nov 2007 17:28:30 +0000 (UTC) (envelope-from ivan.pulleyn@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by mx1.freebsd.org (Postfix) with ESMTP id CD49613C4B6 for ; Tue, 6 Nov 2007 17:28:28 +0000 (UTC) (envelope-from ivan.pulleyn@gmail.com) Received: by ug-out-1314.google.com with SMTP id y2so1396841uge for ; Tue, 06 Nov 2007 09:28:27 -0800 (PST) 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:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=VglTed2pxgHXJGsleFkzqbYxXWGPaVXLWag3/S+3Kgo=; b=l8xWfDLXbaHFQTEtI8qGdRwLO1Im9hLPZAikuBNQLLu8whtaKQ1a19X4/ptvAtDi31yCHtshCwWZm6oqcM4oqIF36RL3Uko8v29GIxHqN5t/0ytII/fNYH7maweE+I+5e7YTEDEV+GLOLujXfo3QadLLQm7SRjumHGjRATYQgrw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=b9d6R174Rn/87R0fx+SxTGV2gCnVhj5QbgJ6F9B+hO5+axR+28/oyV3VqxmD3Iq0cXtuS3KKz6qBZ81Bk5lrickJ8m4APbPDJeLbnPvwmXFgrRtaT5su0x1+krlaqci9zKX0KE+2JEccNQhHT7awyEn2smARl5tFyHTZnZtVB+0= Received: by 10.78.173.20 with SMTP id v20mr5098774hue.1194368414309; Tue, 06 Nov 2007 09:00:14 -0800 (PST) Received: by 10.78.45.8 with HTTP; Tue, 6 Nov 2007 09:00:14 -0800 (PST) Message-ID: <755b32b20711060900w6f213c0fy5f48de4238788293@mail.gmail.com> Date: Tue, 6 Nov 2007 09:00:14 -0800 From: "Ivan Pulleyn" To: obrien@freebsd.org, freebsd-arch@freebsd.org In-Reply-To: <20071106160521.GG18357@dragon.NUXI.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20071106160521.GG18357@dragon.NUXI.org> Cc: Subject: Re: Rename sys/*/conf/DEFAULT to _DEFAULT 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, 06 Nov 2007 17:28:30 -0000 On Nov 6, 2007 8:05 AM, David O'Brien wrote: > > A very simple solution to this is to rename "DEFAULTS" to "_DEFAULTS". > I would think adding "/DEFAULTS" to your file name completion exclude list would be a better solution. Ivan.., From owner-freebsd-arch@FreeBSD.ORG Wed Nov 7 13:49: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 4DBE916A475 for ; Wed, 7 Nov 2007 13:49:22 +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 1A90313C4F9 for ; Wed, 7 Nov 2007 13:49:21 +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 lA7DnCW6047724 for ; Wed, 7 Nov 2007 05:49:12 -0800 (PST) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.1/8.14.1/Submit) id lA7DnCHc047723 for freebsd-arch@freebsd.org; Wed, 7 Nov 2007 05:49:12 -0800 (PST) (envelope-from obrien) Date: Wed, 7 Nov 2007 05:49:12 -0800 From: "David O'Brien" To: freebsd-arch@freebsd.org Message-ID: <20071107134912.GA47286@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, freebsd-arch@freebsd.org References: <20071106160521.GG18357@dragon.NUXI.org> <20071106161812.GD88328@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071106161812.GD88328@lor.one-eyed-alien.net> X-Operating-System: FreeBSD 7.0-CURRENT User-Agent: Mutt/1.5.16 (2007-06-09) Subject: Re: Rename sys/*/conf/DEFAULT to _DEFAULT 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: Wed, 07 Nov 2007 13:49:22 -0000 On Tue, Nov 06, 2007 at 10:18:12AM -0600, Brooks Davis wrote: > On one level this seems reasonable, on another, I don't see the point > since on ever platform kernels beginning with G or N have this issue and > on i386 you add at least S and P to that list. If not, why not make it easier for folks with a kernel file named "DE*"? If I could help with G, N, S, & P I would. > It's slightly annoying, > but IMO not terribly important and this doesn't actually solve more > than 1/3 of the problem at best so I'm not convinced. Why do you really care?? Does a file named _DEFAULTS bother anyone? Considering that I'm not asking you, to do the work of the rename - and the change is only two lines; is there really a need to object? I'm I likely to break someones scripts? Do folks type "DEFAULT" in sys/*/conf often? On Tue, Nov 06, 2007 at 11:33:03AM -0500, Alexander Kabaev wrote: > my thoughts are: gratuitous and unnecessary. Renaming _your_ config > file to something else is a better alternative, IMHO. Thanks, but no - I don't care to go thru the legal proceeding's to change my name. On Tue, Nov 06, 2007 at 09:00:14AM -0800, Ivan Pulleyn wrote: > I would think adding "/DEFAULTS" to your file name completion exclude > list would be a better solution. I don't know how to - this change takes less time than it would for me to figure out how to. And, what I'm trying to do helps others so they don't have to learn either. On Tue, Nov 06, 2007 at 08:21:20AM -0800, Jason Evans wrote: > Now, if you were to argue that DEFAULTS steals from the set of possible > kernel names, and is a land mine that users must somehow know to avoid, > I'd be less inclined to protest. :-) I will add that to the list of benefits (there's not just one), and I could see a realistic one given some commercial environments I've seen. -- -- David (obrien@FreeBSD.org) From owner-freebsd-arch@FreeBSD.ORG Wed Nov 7 14:48: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 0317316A418; Wed, 7 Nov 2007 14:48:14 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id 98C4E13C4AA; Wed, 7 Nov 2007 14:48:13 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id A3DFD45F42; Wed, 7 Nov 2007 15:26:54 +0100 (CET) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id D699445E8F; Wed, 7 Nov 2007 15:26:49 +0100 (CET) Date: Wed, 7 Nov 2007 15:26:42 +0100 From: Pawel Jakub Dawidek To: obrien@freebsd.org, freebsd-arch@freebsd.org Message-ID: <20071107142642.GA15618@garage.freebsd.pl> References: <20071106160521.GG18357@dragon.NUXI.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HsYKTmaHn9HHfM39" Content-Disposition: inline In-Reply-To: <20071106160521.GG18357@dragon.NUXI.org> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: Subject: Re: Rename sys/*/conf/DEFAULT to _DEFAULT 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, 07 Nov 2007 14:48:14 -0000 --HsYKTmaHn9HHfM39 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 06, 2007 at 08:05:21AM -0800, David O'Brien wrote: > Hi folks, > In the days of modern Unix, many (most?) of us have come to expect and > depend on command-line completion that today's modern shells provide in > order to reduce typing (and inaccurate typing). >=20 > Given that premise, the "DEFAULTS" file in sys/*/conf constantly trips me > up as my kernel files are named "DEO". I know others with kernel configs > named with a 'D' that grumbled when command-line completion was now > thwart due to "DEFAULTS". >=20 > A very simple solution to this is to rename "DEFAULTS" to "_DEFAULTS". >=20 > One of the purposes for DEFAULTS was to semi-hide devices and options > that really aren't optional (unless you really know what you're doing) or > have POLA concerns so they would not be causally removed. So this name > change also puts this file to a different "name space" - and in fact may > better convey "there are no user serviceable parts in here". >=20 > Thoughts? While you are there, could you also rename /sys/conf/ to /sys/_conf/? I hate it when I try to enter /sys/contrib/ and I go to /sys/conf/, really. I need to type four letters to get it right and this is a real PITA! :) --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --HsYKTmaHn9HHfM39 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHMcsiForvXbEpPzQRAoFZAKDE1ziWTj7FiGc33hqQh/TL5qDehACgv86l 1iM++hSvu6w6RQTMeFzE38w= =VZrD -----END PGP SIGNATURE----- --HsYKTmaHn9HHfM39-- From owner-freebsd-arch@FreeBSD.ORG Wed Nov 7 17:13:45 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 E967C16A498 for ; Wed, 7 Nov 2007 17:13:45 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id 5FDDC13C4C4 for ; Wed, 7 Nov 2007 17:13:45 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=deviant.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Ipnmv-000BsR-ET for freebsd-arch@freebsd.org; Wed, 07 Nov 2007 18:30:00 +0200 Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id lA7GTqIl018874 for ; Wed, 7 Nov 2007 18:29:53 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1/Submit) id lA7GTqCU018873 for freebsd-arch@freebsd.org; Wed, 7 Nov 2007 18:29:52 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 7 Nov 2007 18:29:52 +0200 From: Kostik Belousov To: freebsd-arch@freebsd.org Message-ID: <20071107162951.GA37471@deviant.kiev.zoral.com.ua> References: <20071031150620.GT37471@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GUfsrdPq8omuo5Le" Content-Disposition: inline In-Reply-To: <20071031150620.GT37471@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.3i X-Scanner-Signature: 362d5034abbfed611c52a2913ea5ff69 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 1747 [Nov 07 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Subject: Re: fdclone KPI 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, 07 Nov 2007 17:13:46 -0000 --GUfsrdPq8omuo5Le Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 31, 2007 at 05:06:20PM +0200, Kostik Belousov wrote: > Dear arch@ readers, > with the important help from Peter Holm I have implemented the KPI that > provides the ability for the driver to implement cloning on the open(2). > This is another (IMHO, more UNIXy) way to provide per-fd private data > for the driver. It seems that at least /dev/apm, /dev/drm and /dev/sg > could immediately benefit from the fdclone() KPI. >=20 > The patch is at > http://people.freebsd.org/~kib/misc/fdclone.9.patch As Oleksandr Tymoshenko pointed out, the patch was not really available at this address. Fixed, sorry. > Sample dumb driver that uses the KPI is at > http://people.freebsd.org/~kib/fclone >=20 > The driver that uses the fdclone() shall provide cdevsw for master device, > and cdevsw for clones. Master shall have d_fdopen() method that could call > int fdclone(struct cdevsw *_csw, struct file *_fp, int _fmode, > struct cdev **_clone, void *si_drv1, struct thread *td); > to replace the reference in the _fp with newly created cdev. >=20 > After successfull fdclone() call, all further calls on the _fp > are dispatched to the clone _csw instead of master one. si_drv1 of the > new cdev is set to respective argument, allowing the clone to find the > master. >=20 > The cloned cdev is not accessible for lookup through the devfs, and is > destroyed automatically on the final close of the last filedescriptor that > references the vnode. >=20 > Please, review. Your feedback is welcome ! --GUfsrdPq8omuo5Le Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHMef/C3+MBN1Mb4gRAn8KAJ4x3J+nj7bdvdRbwZOOjHaGnWXaQgCcDogL 5F8lAqBVDBo4JplfHq3t7PY= =SOI0 -----END PGP SIGNATURE----- --GUfsrdPq8omuo5Le-- From owner-freebsd-arch@FreeBSD.ORG Wed Nov 7 19:46:44 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 1141C16A417 for ; Wed, 7 Nov 2007 19:46:44 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.67]) by mx1.freebsd.org (Postfix) with ESMTP id ED81B13C4A8 for ; Wed, 7 Nov 2007 19:46:43 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (asmtp007-s [10.150.69.70]) by smtpoutm.mac.com (Xserve/smtpout004/MantshX 4.0) with ESMTP id lA7JgtnZ025221; Wed, 7 Nov 2007 11:42:55 -0800 (PST) Received: from mini-g4.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mac.com (Xserve/asmtp007/MantshX 4.0) with ESMTP id lA7JgrdL011195 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 7 Nov 2007 11:42:53 -0800 (PST) Message-Id: <6E9A161D-67A8-4824-B85C-BA82AD240C7E@mac.com> From: Marcel Moolenaar To: obrien@freebsd.org In-Reply-To: <20071107134912.GA47286@dragon.NUXI.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v912) Date: Wed, 7 Nov 2007 11:42:52 -0800 References: <20071106160521.GG18357@dragon.NUXI.org> <20071106161812.GD88328@lor.one-eyed-alien.net> <20071107134912.GA47286@dragon.NUXI.org> X-Mailer: Apple Mail (2.912) Cc: freebsd-arch@freebsd.org Subject: Re: Rename sys/*/conf/DEFAULT to _DEFAULT 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, 07 Nov 2007 19:46:44 -0000 On Nov 7, 2007, at 5:49 AM, David O'Brien wrote: > On Tue, Nov 06, 2007 at 10:18:12AM -0600, Brooks Davis wrote: >> On one level this seems reasonable, on another, I don't see the point >> since on ever platform kernels beginning with G or N have this >> issue and >> on i386 you add at least S and P to that list. > > If not, why not make it easier for folks with a kernel file named > "DE*"? What about this: We move src/sys/${ARCH}/conf/DEFAULTS to src/sys/conf/DEFAULTS.${arch} and we can even add a generic src/sys/conf/DEFAULTS if there's a reason for it. That seems to be a much better solution than renaming a file so that it stops being in the way for some, only to have it become in the way for others. That's just pointless... -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-arch@FreeBSD.ORG Wed Nov 7 20:53:57 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 5E70416A420 for ; Wed, 7 Nov 2007 20:53:57 +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 3CAFC13C4A8 for ; Wed, 7 Nov 2007 20:53:57 +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 lA7Kri2c058474; Wed, 7 Nov 2007 12:53:44 -0800 (PST) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.1/8.14.1/Submit) id lA7Kri1E058473; Wed, 7 Nov 2007 12:53:44 -0800 (PST) (envelope-from obrien) Date: Wed, 7 Nov 2007 12:53:44 -0800 From: "David O'Brien" To: Marcel Moolenaar Message-ID: <20071107205344.GA58422@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Marcel Moolenaar , freebsd-arch@freebsd.org References: <20071106160521.GG18357@dragon.NUXI.org> <20071106161812.GD88328@lor.one-eyed-alien.net> <20071107134912.GA47286@dragon.NUXI.org> <6E9A161D-67A8-4824-B85C-BA82AD240C7E@mac.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6E9A161D-67A8-4824-B85C-BA82AD240C7E@mac.com> X-Operating-System: FreeBSD 7.0-CURRENT User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-arch@freebsd.org Subject: Re: Rename sys/*/conf/DEFAULT to _DEFAULT 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: Wed, 07 Nov 2007 20:53:57 -0000 On Wed, Nov 07, 2007 at 11:42:52AM -0800, Marcel Moolenaar wrote: > What about this: > We move src/sys/${ARCH}/conf/DEFAULTS to src/sys/conf/DEFAULTS.${arch} > and we can even add a generic src/sys/conf/DEFAULTS if there's a reason > for it. I thought about something similar, but didn't suggest this as I thought it would be too big a change for others to swallow. But it does not bother me. > That seems to be a much better solution than renaming a file so that it > stops being in the way for some, only to have it become in the way for > others. That's just pointless... I've never seen anyone post indications of having a kernel config file named _*. So I don't find it pointless. -- -- David (obrien@FreeBSD.org) From owner-freebsd-arch@FreeBSD.ORG Wed Nov 7 21:37:42 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 D280716A420 for ; Wed, 7 Nov 2007 21:37:42 +0000 (UTC) (envelope-from ivan.pulleyn@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by mx1.freebsd.org (Postfix) with ESMTP id 5A12D13C4AC for ; Wed, 7 Nov 2007 21:37:41 +0000 (UTC) (envelope-from ivan.pulleyn@gmail.com) Received: by ug-out-1314.google.com with SMTP id y2so284597uge for ; Wed, 07 Nov 2007 13:37:30 -0800 (PST) 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:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=cu/cljTHqpLChUekRwEt8s0R0WdACDAHs39AVT0bObs=; b=Ny/Eqtqe9ZOU4UJ37HRqUYMH5y7ISDe/AYHLmSthDOEc1GDDxmqftUt/9+fZskzGfKktclTQGCa10q9Sve7O1+D95QS+K0gxrvFMhsKE9UFUpV7isI5mw958eEsUTfu/TTnkGtsh1mUZynYMJtaFh1KqHJgDPF1cpr4oq+FcxyE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=S7HXoNFqmVyr133f3Umvku4uclJxlMFiq0BObSGIU2fx7kqJXLc6/foFBlbnx7ceBUH9k8Ov0RxII5sBk57rcYs6cqxtydKcTE2Aq9p//DmxZMpjr2p1PsWuRJSBapVxPLvyYfiz6omR/HqjUxp9DibQpQPfN9LLhMj3bXUC4Co= Received: by 10.78.159.7 with SMTP id h7mr6570078hue.1194471449921; Wed, 07 Nov 2007 13:37:29 -0800 (PST) Received: by 10.78.45.8 with HTTP; Wed, 7 Nov 2007 13:37:29 -0800 (PST) Message-ID: <755b32b20711071337g36d4e76fuf2d893b68ea1e448@mail.gmail.com> Date: Wed, 7 Nov 2007 13:37:29 -0800 From: "Ivan Pulleyn" To: "Julian Elischer" , freebsd-arch@freebsd.org In-Reply-To: <4730B0AA.2030505@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20071106160521.GG18357@dragon.NUXI.org> <755b32b20711060900w6f213c0fy5f48de4238788293@mail.gmail.com> <4730B0AA.2030505@elischer.org> Cc: Subject: Re: Rename sys/*/conf/DEFAULT to _DEFAULT 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, 07 Nov 2007 21:37:42 -0000 On Nov 6, 2007 10:21 AM, Julian Elischer wrote: > > interesting... I didn't know about this.. how does one do that in csh? > I'm not sure about csh, but in bash you can do this (I think) by setting $FIGNORE. Ivan... From owner-freebsd-arch@FreeBSD.ORG Thu Nov 8 17:07:27 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 F293A16A468 for ; Thu, 8 Nov 2007 17:07:27 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id 8E69A13C4C3 for ; Thu, 8 Nov 2007 17:07:27 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.8p) with ESMTP id 218332148-1834499 for multiple; Thu, 08 Nov 2007 10:41:30 -0500 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id lA8Feujl096145; Thu, 8 Nov 2007 10:40:56 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-arch@freebsd.org Date: Thu, 8 Nov 2007 10:03:08 -0500 User-Agent: KMail/1.9.6 References: <20071106160521.GG18357@dragon.NUXI.org> <20071107134912.GA47286@dragon.NUXI.org> <6E9A161D-67A8-4824-B85C-BA82AD240C7E@mac.com> In-Reply-To: <6E9A161D-67A8-4824-B85C-BA82AD240C7E@mac.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200711081003.08869.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Thu, 08 Nov 2007 10:40:56 -0500 (EST) X-Virus-Scanned: ClamAV 0.91.2/4708/Thu Nov 8 01:07:54 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Marcel Moolenaar Subject: Re: Rename sys/*/conf/DEFAULT to _DEFAULT 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, 08 Nov 2007 17:07:28 -0000 On Wednesday 07 November 2007 02:42:52 pm Marcel Moolenaar wrote: > > On Nov 7, 2007, at 5:49 AM, David O'Brien wrote: > > > On Tue, Nov 06, 2007 at 10:18:12AM -0600, Brooks Davis wrote: > >> On one level this seems reasonable, on another, I don't see the point > >> since on ever platform kernels beginning with G or N have this > >> issue and > >> on i386 you add at least S and P to that list. > > > > If not, why not make it easier for folks with a kernel file named > > "DE*"? > > What about this: > > We move src/sys/${ARCH}/conf/DEFAULTS to src/sys/conf/DEFAULTS.${arch} > and we can even add a generic src/sys/conf/DEFAULTS if there's a reason > for it. > > That seems to be a much better solution than renaming a file so that it > stops being in the way for some, only to have it become in the way for > others. That's just pointless... Agreed. The tab completion argument is a bit weak, but this is probably a good idea. All the other files config(8) reads reside in sys/conf, so that is probably a better place. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Thu Nov 8 20:01:39 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 C923616A421 for ; Thu, 8 Nov 2007 20:01:39 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by mx1.freebsd.org (Postfix) with ESMTP id 4665513C4BA for ; Thu, 8 Nov 2007 20:01:39 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so228148nfb for ; Thu, 08 Nov 2007 12:01:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; bh=jzmrghTcmXZMrFhALwp8y617WIMMfP3jEVgtfelp2iA=; b=hRkrBlV3/l2BckX6oUPFDfovMeywgDlABWTP1exnizFlW0HzpNsDLOmp9hDAIlXNdpvs1HrFVflOb9SnMCuHXfM+KwnvE/JfvU1qcivk/RnNb+r5qm/pgaDT9IeKcu+/+Obdn3omN5x0I4PSx2XpvoCIUAnVxoUz4783GZ+XH7U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=HySyfrs9z6V0APvRq6bmJfTnzI3O0Nsl+KBtLA2VbQHciYkx/i9i+FfEUlbIV7FLYjvVlA48onRMOuYWRgnCR60NBdivm4sKAf5VU1UxUaYP+Jhn85y+5Z0AR1cl3fd/+9DmLgKohW/bBMJtjIx6zr6oXgEtN9JISvhT8fe85t0= Received: by 10.86.77.5 with SMTP id z5mr771367fga.1194550507967; Thu, 08 Nov 2007 11:35:07 -0800 (PST) Received: by 10.86.90.4 with HTTP; Thu, 8 Nov 2007 11:35:07 -0800 (PST) Message-ID: <3bbf2fe10711081135y3473817ejbc72574e3e8c763d@mail.gmail.com> Date: Thu, 8 Nov 2007 20:35:07 +0100 From: "Attilio Rao" Sender: asmrookie@gmail.com To: freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 8476ae5a7da20049 Cc: Robert Watson , Pawel Jakub Dawidek Subject: [RFC] callout overhaul: part I 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, 08 Nov 2007 20:01:39 -0000 Hello, Some benchmarks posted by rwatson some time ago ( http://lists.freebsd.org/pipermail/freebsd-arch/2007-October/006945.html ) evicted callout_lock spinlock as an highly contented lock, in particular for network paths. Honestly, this is not a surprise at all :). This moved me in the direction of working on callouts, mainly for improving the scalability respect a large number of CPUs but, since callout are rather sensitive for the whole system, a general overhaul to the whole mecanism would be a good idea. In particular, I found phk's ideas about it ( http://lists.freebsd.org/pipermail/freebsd-arch/2006-November/005730.html ) very valuable and I have on-going discussions with him and rwatson about these. phk's proposal is however not complete at 100% and I'm trying to integrate with other missing supports. This patch, for example: http://people.freebsd.org/~attilio/callout_rwlock.diff would add the support for callout working with rwlock. Currently, mutex are the only possible kind of lock to be used in conjuction with callouts and this is a little bit limitative. The support is implemented using the jhb's abstraction layer for locks. Even if it is rather generic to be used with any kind of abstracted lock, only rwlock and mutex are allowed to work because of softclock() running in a kthread. A new function is added to the KPI called callout_init_rw() which basically does the same of callout_init_mtx() but with a rwlock. Addictionally, it can get the new flag CALLOUT_SHAREDLOCK which let acquiring the rwlock in shared mode while running the callout. Using CALLOUT_SHAREDLOCK with callout_init_mtx() has no effect. We could panic for it if someone it worths, but it would end up polluting callout.h or alternatively complicating new _callout_init_lock(). Please, also note that the mtx_owned() stuff from the callout_stop() function is removed as theoretically the lock, when specified, should always be acquired when running callout_stop(). However, as there is no simple way to do assertions with the lock abstraction class, and there is no way to retrieve a child object from the lock_object class, don't do any assertion for the moment, just comment the situation. I'm eager to hear for your feedbacks. Thanks, Attilio PS: It seems that other developers alredy did something similar (like pjd. It seems we discussed about it some time ago but I completely forgot about that... :)), please report if you have had better ideas on it. -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-arch@FreeBSD.ORG Fri Nov 9 11:47:41 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 A2B2D16A418; Fri, 9 Nov 2007 11:47:41 +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 DA54413C4B7; Fri, 9 Nov 2007 11:47:40 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A5407C.dip.t-dialin.net [84.165.64.124]) by redbull.bpaserver.net (Postfix) with ESMTP id 781BA2E35D; Fri, 9 Nov 2007 12:44:24 +0100 (CET) Received: from deskjail (deskjail.Leidinger.net [192.168.1.109]) by outgoing.leidinger.net (Postfix) with ESMTP id EC2B03148AE3; Fri, 9 Nov 2007 12:44:21 +0100 (CET) Date: Fri, 9 Nov 2007 12:44:21 +0100 From: Alexander Leidinger To: jhb@freebsd.org, phk@freebsd.org, imp@freebsd.org, rwatson@freebsd.org Message-ID: <20071109124421.3c1901b1@deskjail> X-Mailer: Claws Mail 3.0.1 (GTK+ 2.10.14; i686-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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=1.269, required 8, BAYES_40 -0.18, J_CHICKENPOX_43 0.60, J_CHICKENPOX_66 0.60, RDNS_DYNAMIC 0.10, TW_PH 0.08, TW_VC 0.08) X-BPAnet-MailScanner-SpamScore: s X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: arch@freebsd.org, cnst@freebsd.org Subject: sensors framework continued (architecture) 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, 09 Nov 2007 11:47:41 -0000 Hi, I'm back from the surgery and am in a state where I don't have to take any = medication since some days. So I think I'm fit enough to move forward here.= As there was no further discussion since nearly two weeks on this, I summa= rize what we have so far. First some definitions so that we have a common u= nderstanding of the parts involved. Then what seems to be the current state= of affairs from an architectural point of view. The definitions: Kernel sensors framework: It's just an export interface to transfer status = data from the kernel to userland. The goal of this framework is to "collect= " all this data in the kernel and provide a single point of contact for the= userland to query this in-kernel data. In-kernel data means raw data from = devices here, e.g., temperature data of one particular sensor, but not a co= mputed value like "kern.ipc.maxsockets-kern.ipc.numopensockets". What data = is exported how (via the sensors interface, via sysctl kern.xxx or anything= else) is up to a decission for the data based upon rules we come up with (= explicitely or implicitely). An explicite rule could be to not export time = related data via the sensors framework but via our existing standards compl= iant API. An implicit rule could be to export temperature data from the ker= nel via the sensors framework. Single-system sensors framework: This part would be responsible to be a sin= gle point of contact to query the status data of the entire system. This us= erland part would be responsible to automatically collect data which is exp= orted from the kernel (raw data) via the sensors framework, and to collect = data from userland stuff (either application specific data like number of c= hilds of a webserver, or a computed value from raw data like "kern.ipc.maxs= ockets-kern.ipc.numopensockets"). It would provide an interface to be able = to query the in-machine data. It could also be used to augment data from th= e kernel sensors framework with additional meta data which can not be autom= atically determined (e.g. location, name-override, ...). Group-level sensors framework: This part would be responsible to collect se= nsor data in the entire (sub-)network from the single-system sensors framew= ork and provide an interface to query the data from the entire (sub-)networ= k (an example would be nagios, some commercial offering, or something compl= etely different). The current state of affairs: We want a kernel sensors framework and a single-system sensors framework in= FreeBSD. For the kernel sensors framework phk proposes (Message-ID: <81952.119278686= 4@critter.freebsd.dk>, <82533.1192797289@critter.freebsd.dk>) a fd which su= pports select/poll/kevent as the interface between the kernel and the userl= and (Julian and Max also proposed an fd based interface without going into = as much details regarding events like Poul did). An ioctl() could be used t= o specify the polling intervall of sensors which are not event-driven. This= implies that we have to move the polling intervall code for non-event driv= en sensors from the userland to the kernel. This is contrary to his requst = that as much as possible is done in userland. Having this in kernel is bene= ficial for time critical sensor data where a fast reaction to critical situ= ations is needed, but in such a situation we need to talk about garanteed r= eaction times and if FreeBSD is able to meet those requirements or if a rea= l-time OS is better suited for this application scenario. As we have no har= d data provided in this discussion regarding this topic I would say having = the polling intervall logic in the kernel is premature optimization so far. Warner proposes to use an existing interface (devd) for event driven sensor= s (<20071019.100516.74722974.imp@bsdimp.com>). Poul agrees that events (lik= e "high temp" and similar, but not the actual raw data like "32=C2=B0C") co= uld be send to devd instead. I like to extend this so that it is send over = the devd socket, but that devd should not react to every sensor related eve= nt, but the signle-system sensor framework is supposed to handle such event= s. Devd could react to those events too, if desired by the admin, but it do= esn't make sense to let devd handle all events by default. It may make sens= e to let devd handle events which require immediate action (shutting down (= sub)systems, sending emails (if desired), ...), but if the group-level sens= ors framework handles parts of this (like sending notifications), devd inte= raction for those is not desired (the handling of events in devd needs to b= e decided on a case by case basis). This would require to extend the devctl= interface to allow more than one reader. Robert thinks that sysctl MIBs offer "a more semantically rich and, to be h= onest, better defined way of interacting with live subsystems than device f= iles do in a generic sense". Nobody objected to this opinion or provided re= asons why a fd based approach is better than a sysctl MIB based approach. R= icardo Nabinger Sanchez points out http://www.ietf.org/rfc/rfc3433.txt (RFC= for sensor MIBs).=20 The single-system sensors framework should be implemented in a library whic= h userland programs like systat, SNMP or other monitoring daemons use (jhb,= Message-Id: <200710181450.38224.jhb@freebsd.org>). The kernel-userland int= erface of the kernel sensors framework would be an internal interface of Fr= eeBSD and every program which wants access to a sensor would have to use th= e library as the official interface. So to sum it up it looks like the architecture looks as follows: - using sysctls for centralized exporting of sensor data from kernel to userland (polling interface for userland polling code) - using devctl_notify() for change-events (the userland can then read the changed value via the sysctl interface) - writting a library (the single-system sensors framework backend) which abstracts away the kernel-userland interface of the kernel sensors framework and provides an official interface for userland programs to all sensors in the system Did I got the architecture/summary right or did I miss a mail on arch@ whic= h made the fd based approach more beneficial than the sysctl+devctl based a= pproach? Bye, Alexander. --=20 Fashion is a form of ugliness so intolerable that we have to alter it every six months. -- Oscar Wilde 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 Fri Nov 9 17:20:23 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 E5C2116A468 for ; Fri, 9 Nov 2007 17:20:23 +0000 (UTC) (envelope-from qpadla@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.185]) by mx1.freebsd.org (Postfix) with ESMTP id 4260C13C4B7 for ; Fri, 9 Nov 2007 17:20:23 +0000 (UTC) (envelope-from qpadla@gmail.com) Received: by fk-out-0910.google.com with SMTP id b27so650424fka for ; Fri, 09 Nov 2007 09:20:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:reply-to:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:message-id; bh=iCYW/Jl3ohZT/V6rVfEs6ZsrHVY2A+ZKgntW9MkS44k=; b=lNexS+vkrDwGV9r0+MUTd5v657ioVaYhxbdbcIeJWxyb5Qp38Dcg3ZzqjwQ9vlKeUZRTsLzoiOpHC42nM8cJIdgathuS+jvkQtOxaxTMhUy6ssC+TSCqkA7Qch5R1Z3FV70lsUgKtLf5beiKFLmAJmaf/ifEwrPMuMgxMV0Ljq0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:reply-to:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:message-id; b=oxb2NhL5EDCZav+pLb6ImDXRobXFcv71b1JZTvE23dELo+i1TKAVZBAgVKAkEyiOiftlHDgB4xrHmaEGHbHfruYNzlBZ4LD9V5LBSAHv92JRYSNoyJ6LbZEHfZFWfjthMkO6LMsqF2ADzLN8RHhMzbEbOUgPLSbmrVai4Ygfdyw= Received: by 10.82.175.17 with SMTP id x17mr4294843bue.1194627215868; Fri, 09 Nov 2007 08:53:35 -0800 (PST) Received: from orion ( [89.162.141.1]) by mx.google.com with ESMTPS id y2sm4711816mug.2007.11.09.08.53.32 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 09 Nov 2007 08:53:34 -0800 (PST) From: Nikolay Pavlov To: freebsd-arch@freebsd.org Date: Fri, 9 Nov 2007 18:51:10 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <20071109124421.3c1901b1@deskjail> In-Reply-To: <20071109124421.3c1901b1@deskjail> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3093353.TiXXcl7AEI"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200711091851.19445.qpadla@gmail.com> Cc: cnst@freebsd.org, arch@freebsd.org, rwatson@freebsd.org, Alexander Leidinger , imp@freebsd.org Subject: Re: sensors framework continued (architecture) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: qpadla@gmail.com List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2007 17:20:24 -0000 --nextPart3093353.TiXXcl7AEI Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Friday 09 November 2007 13:44:21 Alexander Leidinger wrote: > Robert thinks that sysctl MIBs offer "a more semantically rich and, to > be honest, better defined way of interacting with live subsystems than > device files do in a generic sense". Nobody objected to this opinion or > provided reasons why a fd based approach is better than a sysctl MIB > based approach. Ricardo Nabinger Sanchez points out > http://www.ietf.org/rfc/rfc3433.txt (RFC for sensor MIBs). I think a MIB approach is much more usefull between "Single-system sensors= =20 framework" and "Group-level sensors framework" and a good example here is=20 a SNMP(the general usage example of the MIB defined in rfc3433). I am not=20 a kernel developer and don't know whether it's a good for pass the data or= =20 not, but as experienced administrator should mansion that sysctl mib's is=20 expected (IMHO) to be used as a configuration interface to define a kernel= =20 and system behavior. It's much more easy to use userland utilities such as= =20 vmstat, systat, netstat, sockstat than listing some stats and data via=20 sysctl. Also i suspect that such complex and rich thing as sensors=20 framework often would be a subject to various changes and extensions, so i= =20 vote to hide kernel part as much as possible.=20 =2D-=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 =2D Best regards, Nikolay Pavlov. <<<----------------------------------- = =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 --nextPart3093353.TiXXcl7AEI Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBHNJAH/2R6KvEYGaIRAgkhAJ44iVEo9wz2IpZiZ3wlacG/iqifBwCfaEkn /6NDikrU+K+mbEd7WeAwVX8= =vPmq -----END PGP SIGNATURE----- --nextPart3093353.TiXXcl7AEI-- From owner-freebsd-arch@FreeBSD.ORG Fri Nov 9 17:22:37 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 E776F16A418 for ; Fri, 9 Nov 2007 17:22:37 +0000 (UTC) (envelope-from qpadla@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.191]) by mx1.freebsd.org (Postfix) with ESMTP id 6721A13C4A8 for ; Fri, 9 Nov 2007 17:22:36 +0000 (UTC) (envelope-from qpadla@gmail.com) Received: by fk-out-0910.google.com with SMTP id b27so651050fka for ; Fri, 09 Nov 2007 09:22:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:reply-to:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:message-id; bh=iCYW/Jl3ohZT/V6rVfEs6ZsrHVY2A+ZKgntW9MkS44k=; b=lNexS+vkrDwGV9r0+MUTd5v657ioVaYhxbdbcIeJWxyb5Qp38Dcg3ZzqjwQ9vlKeUZRTsLzoiOpHC42nM8cJIdgathuS+jvkQtOxaxTMhUy6ssC+TSCqkA7Qch5R1Z3FV70lsUgKtLf5beiKFLmAJmaf/ifEwrPMuMgxMV0Ljq0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:reply-to:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:message-id; b=oxb2NhL5EDCZav+pLb6ImDXRobXFcv71b1JZTvE23dELo+i1TKAVZBAgVKAkEyiOiftlHDgB4xrHmaEGHbHfruYNzlBZ4LD9V5LBSAHv92JRYSNoyJ6LbZEHfZFWfjthMkO6LMsqF2ADzLN8RHhMzbEbOUgPLSbmrVai4Ygfdyw= Received: by 10.82.175.17 with SMTP id x17mr4294843bue.1194627215868; Fri, 09 Nov 2007 08:53:35 -0800 (PST) Received: from orion ( [89.162.141.1]) by mx.google.com with ESMTPS id y2sm4711816mug.2007.11.09.08.53.32 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 09 Nov 2007 08:53:34 -0800 (PST) From: Nikolay Pavlov To: freebsd-arch@freebsd.org Date: Fri, 9 Nov 2007 18:51:10 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <20071109124421.3c1901b1@deskjail> In-Reply-To: <20071109124421.3c1901b1@deskjail> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3093353.TiXXcl7AEI"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200711091851.19445.qpadla@gmail.com> Cc: cnst@freebsd.org, arch@freebsd.org, rwatson@freebsd.org, Alexander Leidinger , imp@freebsd.org Subject: Re: sensors framework continued (architecture) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: qpadla@gmail.com List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2007 17:22:38 -0000 --nextPart3093353.TiXXcl7AEI Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Friday 09 November 2007 13:44:21 Alexander Leidinger wrote: > Robert thinks that sysctl MIBs offer "a more semantically rich and, to > be honest, better defined way of interacting with live subsystems than > device files do in a generic sense". Nobody objected to this opinion or > provided reasons why a fd based approach is better than a sysctl MIB > based approach. Ricardo Nabinger Sanchez points out > http://www.ietf.org/rfc/rfc3433.txt (RFC for sensor MIBs). I think a MIB approach is much more usefull between "Single-system sensors= =20 framework" and "Group-level sensors framework" and a good example here is=20 a SNMP(the general usage example of the MIB defined in rfc3433). I am not=20 a kernel developer and don't know whether it's a good for pass the data or= =20 not, but as experienced administrator should mansion that sysctl mib's is=20 expected (IMHO) to be used as a configuration interface to define a kernel= =20 and system behavior. It's much more easy to use userland utilities such as= =20 vmstat, systat, netstat, sockstat than listing some stats and data via=20 sysctl. Also i suspect that such complex and rich thing as sensors=20 framework often would be a subject to various changes and extensions, so i= =20 vote to hide kernel part as much as possible.=20 =2D-=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 =2D Best regards, Nikolay Pavlov. <<<----------------------------------- = =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 --nextPart3093353.TiXXcl7AEI Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBHNJAH/2R6KvEYGaIRAgkhAJ44iVEo9wz2IpZiZ3wlacG/iqifBwCfaEkn /6NDikrU+K+mbEd7WeAwVX8= =vPmq -----END PGP SIGNATURE----- --nextPart3093353.TiXXcl7AEI-- From owner-freebsd-arch@FreeBSD.ORG Fri Nov 9 17:58:26 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 062A116A419; Fri, 9 Nov 2007 17:58:26 +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 0D06B13C4C4; Fri, 9 Nov 2007 17:58:24 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A55635.dip.t-dialin.net [84.165.86.53]) by redbull.bpaserver.net (Postfix) with ESMTP id 2D97A2E249; Fri, 9 Nov 2007 18:57:45 +0100 (CET) Received: from deskjail (deskjail.Leidinger.net [192.168.1.109]) by outgoing.leidinger.net (Postfix) with ESMTP id 689163148AC6; Fri, 9 Nov 2007 18:57:42 +0100 (CET) Date: Fri, 9 Nov 2007 18:57:41 +0100 From: Alexander Leidinger To: qpadla@gmail.com Message-ID: <20071109185741.13930f0b@deskjail> In-Reply-To: <200711091851.19445.qpadla@gmail.com> References: <20071109124421.3c1901b1@deskjail> <200711091851.19445.qpadla@gmail.com> X-Mailer: Claws Mail 3.0.1 (GTK+ 2.10.14; i686-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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=-14.069, required 8, BAYES_00 -15.00, J_CHICKENPOX_43 0.60, RDNS_DYNAMIC 0.10, TW_BK 0.08, TW_OC 0.08, TW_VC 0.08) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: cnst@freebsd.org, arch@freebsd.org, rwatson@freebsd.org, freebsd-arch@freebsd.org, imp@freebsd.org Subject: Re: sensors framework continued (architecture) 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, 09 Nov 2007 17:58:26 -0000 Quoting Nikolay Pavlov (Fri, 9 Nov 2007 18:51:10 +0200): > On Friday 09 November 2007 13:44:21 Alexander Leidinger wrote: > > Robert thinks that sysctl MIBs offer "a more semantically rich and, to > > be honest, better defined way of interacting with live subsystems than > > device files do in a generic sense". Nobody objected to this opinion or > > provided reasons why a fd based approach is better than a sysctl MIB > > based approach. Ricardo Nabinger Sanchez points out > > http://www.ietf.org/rfc/rfc3433.txt (RFC for sensor MIBs). > > I think a MIB approach is much more usefull between "Single-system sensors > framework" and "Group-level sensors framework" and a good example here is > a SNMP(the general usage example of the MIB defined in rfc3433). I am not > a kernel developer and don't know whether it's a good for pass the data or > not, but as experienced administrator should mansion that sysctl mib's is > expected (IMHO) to be used as a configuration interface to define a kernel > and system behavior. It's much more easy to use userland utilities such as We have a lot of read only sysctls, so it's de-facto not only a configuration interface, but also a status description interface already. And if you use top or ps, you already use the sysctl framework to get the information about the processes. Both utilities use libkvm, which is the official userland interface to access this information. The libkvm uses the internal interface via sysctls to get this information. So we already have precedence of the use of sysctl for such status data. > vmstat, systat, netstat, sockstat than listing some stats and data via > sysctl. Also i suspect that such complex and rich thing as sensors You are not supposed to list stats and data via sysctl (the kernel level sensors framework) as an administrator. You are supposed to use the userland tools (the single-system sensors framework tools) to query this data. Listing the sensors in systat would be one way of accessing this information, and people already have though about this (this thread is triggered by Google Summer of Code 2007 work where the sensors are already displayed in systat). If you "by accident" know how to get the sensor information the "inofficial" way, nobody prevents you to do it (like nobody prevents you to get the same information as top/ps gets via sysctl), but then you are supposed to not moan if we change the way we export this data. > framework often would be a subject to various changes and extensions, so i > vote to hide kernel part as much as possible. This was addressed further down in the text (the part which you didn't quote here). The official user interface to the sensors from userland would be the userland library. As we are an open source OS, we can not hide something, we can only declare something as an official interface, or an internal interface. sysctl would allow to export the data in an hierarchical and unified way. sysctl is a well tested and working interface in FreeBSD to export data from the kernel to the userland. If or if not there are much changes and extensions in an incompatible way, can not be determined in such a high level architectural discussion. To be able to talk about this, we have to got more towards the implementation direction. But anyway, the userland access library we envision so far is supposed to handle this gracefully. The implicit question we answered here is, if we invent a new interface or augment an existing and well tested interface with some meta information in a subtree. So far it looks we want to use existing interfaces (a sysctl subtree for the data and devctl for notifications). What such an hierarchical and MIB like interface allows is, that you can get the notification "event sensor X switched to a critical value" and directly poll the value in an easy way. If, for example, you want to produce something similar via a pseudo-filesystem, you have to actually write a filesystem. This is a more complex task to get right than to use the functions in the kernel to handle sysctls. It also involves more processing in the kernel (mounting, VFS interaction, ...). With procfs we learned that a filesystem for something like this is hard to get right. After switching from procfs to sysctl's to gather data for top/ps/..., we noticed that it is more easy to get right via sysctl's, and that sysctl's are a good interface to export such data from the kernel. Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-arch@FreeBSD.ORG Fri Nov 9 18:13: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 AC1CB16A417 for ; Fri, 9 Nov 2007 18:13:48 +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 1E18213C481 for ; Fri, 9 Nov 2007 18:13:48 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A55635.dip.t-dialin.net [84.165.86.53]) by redbull.bpaserver.net (Postfix) with ESMTP id 2D97A2E249; Fri, 9 Nov 2007 18:57:45 +0100 (CET) Received: from deskjail (deskjail.Leidinger.net [192.168.1.109]) by outgoing.leidinger.net (Postfix) with ESMTP id 689163148AC6; Fri, 9 Nov 2007 18:57:42 +0100 (CET) Date: Fri, 9 Nov 2007 18:57:41 +0100 From: Alexander Leidinger To: qpadla@gmail.com Message-ID: <20071109185741.13930f0b@deskjail> In-Reply-To: <200711091851.19445.qpadla@gmail.com> References: <20071109124421.3c1901b1@deskjail> <200711091851.19445.qpadla@gmail.com> X-Mailer: Claws Mail 3.0.1 (GTK+ 2.10.14; i686-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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=-14.069, required 8, BAYES_00 -15.00, J_CHICKENPOX_43 0.60, RDNS_DYNAMIC 0.10, TW_BK 0.08, TW_OC 0.08, TW_VC 0.08) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: cnst@freebsd.org, arch@freebsd.org, rwatson@freebsd.org, freebsd-arch@freebsd.org, imp@freebsd.org Subject: Re: sensors framework continued (architecture) 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, 09 Nov 2007 18:13:48 -0000 Quoting Nikolay Pavlov (Fri, 9 Nov 2007 18:51:10 +0200): > On Friday 09 November 2007 13:44:21 Alexander Leidinger wrote: > > Robert thinks that sysctl MIBs offer "a more semantically rich and, to > > be honest, better defined way of interacting with live subsystems than > > device files do in a generic sense". Nobody objected to this opinion or > > provided reasons why a fd based approach is better than a sysctl MIB > > based approach. Ricardo Nabinger Sanchez points out > > http://www.ietf.org/rfc/rfc3433.txt (RFC for sensor MIBs). > > I think a MIB approach is much more usefull between "Single-system sensors > framework" and "Group-level sensors framework" and a good example here is > a SNMP(the general usage example of the MIB defined in rfc3433). I am not > a kernel developer and don't know whether it's a good for pass the data or > not, but as experienced administrator should mansion that sysctl mib's is > expected (IMHO) to be used as a configuration interface to define a kernel > and system behavior. It's much more easy to use userland utilities such as We have a lot of read only sysctls, so it's de-facto not only a configuration interface, but also a status description interface already. And if you use top or ps, you already use the sysctl framework to get the information about the processes. Both utilities use libkvm, which is the official userland interface to access this information. The libkvm uses the internal interface via sysctls to get this information. So we already have precedence of the use of sysctl for such status data. > vmstat, systat, netstat, sockstat than listing some stats and data via > sysctl. Also i suspect that such complex and rich thing as sensors You are not supposed to list stats and data via sysctl (the kernel level sensors framework) as an administrator. You are supposed to use the userland tools (the single-system sensors framework tools) to query this data. Listing the sensors in systat would be one way of accessing this information, and people already have though about this (this thread is triggered by Google Summer of Code 2007 work where the sensors are already displayed in systat). If you "by accident" know how to get the sensor information the "inofficial" way, nobody prevents you to do it (like nobody prevents you to get the same information as top/ps gets via sysctl), but then you are supposed to not moan if we change the way we export this data. > framework often would be a subject to various changes and extensions, so i > vote to hide kernel part as much as possible. This was addressed further down in the text (the part which you didn't quote here). The official user interface to the sensors from userland would be the userland library. As we are an open source OS, we can not hide something, we can only declare something as an official interface, or an internal interface. sysctl would allow to export the data in an hierarchical and unified way. sysctl is a well tested and working interface in FreeBSD to export data from the kernel to the userland. If or if not there are much changes and extensions in an incompatible way, can not be determined in such a high level architectural discussion. To be able to talk about this, we have to got more towards the implementation direction. But anyway, the userland access library we envision so far is supposed to handle this gracefully. The implicit question we answered here is, if we invent a new interface or augment an existing and well tested interface with some meta information in a subtree. So far it looks we want to use existing interfaces (a sysctl subtree for the data and devctl for notifications). What such an hierarchical and MIB like interface allows is, that you can get the notification "event sensor X switched to a critical value" and directly poll the value in an easy way. If, for example, you want to produce something similar via a pseudo-filesystem, you have to actually write a filesystem. This is a more complex task to get right than to use the functions in the kernel to handle sysctls. It also involves more processing in the kernel (mounting, VFS interaction, ...). With procfs we learned that a filesystem for something like this is hard to get right. After switching from procfs to sysctl's to gather data for top/ps/..., we noticed that it is more easy to get right via sysctl's, and that sysctl's are a good interface to export such data from the kernel. Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-arch@FreeBSD.ORG Fri Nov 9 19:03: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 049EB16A419 for ; Fri, 9 Nov 2007 19:03:56 +0000 (UTC) (envelope-from qpadla@gmail.com) Received: from ik-out-1112.google.com (ik-out-1112.google.com [66.249.90.183]) by mx1.freebsd.org (Postfix) with ESMTP id 4904513C4B3 for ; Fri, 9 Nov 2007 19:03:52 +0000 (UTC) (envelope-from qpadla@gmail.com) Received: by ik-out-1112.google.com with SMTP id c21so408399ika for ; Fri, 09 Nov 2007 11:03:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:reply-to:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:message-id; bh=fznop7CxdB5OJ6Sk33YYYVC2rUMZsWNsGYV49Q0nNwE=; b=Lx2QUotYjnYd9ESxLooLMzf8kVkPEZT4YYjJnJPs17nR/tPdNKCeH6WSGihRafvtlxi4DS5MF5NJp/ZaokRgKjiej+ItvDYI9U52kr2eqtH1Q7bAmiNLfXFq+ys8WHMQU8VbCA5r4QYJaOkeVngfVqSD7OHTCA5+6c5hejSNQBc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:reply-to:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:message-id; b=HrxEEkdsEez2DNghF5ngWJLs1QcJZX2Na8wtkq+1AsUrmtaOOYWr0nRp2hxzmfrglEs+3LCi/FfBqFMCuF1XXw6jVjqNOAT3TO6b7xpvWLPKdEExE88ZR+WtdTY3eYUdMskoGbk1RPjCx9Q7cglf1wPvCOFM8/DgTXutYcMF2PM= Received: by 10.78.151.3 with SMTP id y3mr2829822hud.1194635023335; Fri, 09 Nov 2007 11:03:43 -0800 (PST) Received: from orion ( [89.162.141.1]) by mx.google.com with ESMTPS id b36sm3141520ika.2007.11.09.11.03.40 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 09 Nov 2007 11:03:42 -0800 (PST) From: Nikolay Pavlov To: Alexander Leidinger Date: Fri, 9 Nov 2007 21:03:43 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <20071109124421.3c1901b1@deskjail> <200711091851.19445.qpadla@gmail.com> <20071109185741.13930f0b@deskjail> In-Reply-To: <20071109185741.13930f0b@deskjail> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1672619.TaOcxpx39Z"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200711092103.48652.qpadla@gmail.com> Cc: cnst@freebsd.org, arch@freebsd.org, rwatson@freebsd.org, freebsd-arch@freebsd.org, imp@freebsd.org Subject: Re: sensors framework continued (architecture) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: qpadla@gmail.com List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2007 19:03:56 -0000 --nextPart1672619.TaOcxpx39Z Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Friday 09 November 2007 19:57:41 Alexander Leidinger wrote: > This was addressed further down in the text (the part which you didn't > quote here). The official user interface to the sensors from userland > would be the userland library. As we are an open source OS, we can not > hide something, we can only declare something as an official interface, > or an internal interface. sysctl would allow to export the data in an > hierarchical and unified way. sysctl is a well tested and working > interface in FreeBSD to export data from the kernel to the userland. > > If or if not there are much changes and extensions in an incompatible > way, can not be determined in such a high level architectural > discussion. To be able to talk about this, we have to got more towards > the implementation direction. But anyway, the userland access library > we envision so far is supposed to handle this gracefully. > > The implicit question we answered here is, if we invent a new interface > or augment an existing and well tested interface with some meta > information in a subtree. So far it looks we want to use existing > interfaces (a sysctl subtree for the data and devctl for notifications). > > What such an hierarchical and MIB like interface allows is, that you > can get the notification "event sensor X switched to a critical value" > and directly poll the value in an easy way. If, for example, you want > to produce something similar via a pseudo-filesystem, you have to > actually write a filesystem. This is a more complex task to get right > than to use the functions in the kernel to handle sysctls. It also > involves more processing in the kernel (mounting, VFS > interaction, ...). With procfs we learned that a filesystem for > something like this is hard to get right. After switching from procfs > to sysctl's to gather data for top/ps/..., we noticed that it is more > easy to get right via sysctl's, and that sysctl's are a good interface > to export such data from the kernel. Then it's ok for me :)=20 But i think you should drop some unrealistic requirements: Please do not define some event-latency thresholds here. So if it's to=20 complicated to handle in kernel event triggers, just let the daemons do=20 the job. FreeBSD is not RT OS in any way.=20 An RFC already mentioned above show a good example of how the data could be= =20 exported to another world via SNMP (you can even generate traps via BSNMPD= =20 daemon), let's do not invent yet another "Group-level sensors framework".=20 I am bit sceptic of it. So as an admin i would be happy with a daemon that= =20 could write some logs and trigger events, utility that could show current=20 stats and SNMP MIB that could be listed via network. This just my=20 requirements for sensors framework as a black box :)=20 Thanks. =2D-=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 =2D Best regards, Nikolay Pavlov. <<<----------------------------------- = =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 --nextPart1672619.TaOcxpx39Z Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBHNK8U/2R6KvEYGaIRAlLkAJ4+Cd+bKsSqAVsKpACJHJKXct6PYACfYWTW mp3PfXt6vMlkkymOjVVTobY= =Cq/Z -----END PGP SIGNATURE----- --nextPart1672619.TaOcxpx39Z-- From owner-freebsd-arch@FreeBSD.ORG Fri Nov 9 19:03:56 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 20E8D16A421 for ; Fri, 9 Nov 2007 19:03:56 +0000 (UTC) (envelope-from qpadla@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by mx1.freebsd.org (Postfix) with ESMTP id 4984913C4B7 for ; Fri, 9 Nov 2007 19:03:52 +0000 (UTC) (envelope-from qpadla@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so500333nfb for ; Fri, 09 Nov 2007 11:03:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:reply-to:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:message-id; bh=fznop7CxdB5OJ6Sk33YYYVC2rUMZsWNsGYV49Q0nNwE=; b=Lx2QUotYjnYd9ESxLooLMzf8kVkPEZT4YYjJnJPs17nR/tPdNKCeH6WSGihRafvtlxi4DS5MF5NJp/ZaokRgKjiej+ItvDYI9U52kr2eqtH1Q7bAmiNLfXFq+ys8WHMQU8VbCA5r4QYJaOkeVngfVqSD7OHTCA5+6c5hejSNQBc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:reply-to:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:message-id; b=HrxEEkdsEez2DNghF5ngWJLs1QcJZX2Na8wtkq+1AsUrmtaOOYWr0nRp2hxzmfrglEs+3LCi/FfBqFMCuF1XXw6jVjqNOAT3TO6b7xpvWLPKdEExE88ZR+WtdTY3eYUdMskoGbk1RPjCx9Q7cglf1wPvCOFM8/DgTXutYcMF2PM= Received: by 10.78.151.3 with SMTP id y3mr2829822hud.1194635023335; Fri, 09 Nov 2007 11:03:43 -0800 (PST) Received: from orion ( [89.162.141.1]) by mx.google.com with ESMTPS id b36sm3141520ika.2007.11.09.11.03.40 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 09 Nov 2007 11:03:42 -0800 (PST) From: Nikolay Pavlov To: Alexander Leidinger Date: Fri, 9 Nov 2007 21:03:43 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <20071109124421.3c1901b1@deskjail> <200711091851.19445.qpadla@gmail.com> <20071109185741.13930f0b@deskjail> In-Reply-To: <20071109185741.13930f0b@deskjail> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1672619.TaOcxpx39Z"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200711092103.48652.qpadla@gmail.com> Cc: cnst@freebsd.org, arch@freebsd.org, rwatson@freebsd.org, freebsd-arch@freebsd.org, imp@freebsd.org Subject: Re: sensors framework continued (architecture) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: qpadla@gmail.com List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2007 19:03:56 -0000 --nextPart1672619.TaOcxpx39Z Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Friday 09 November 2007 19:57:41 Alexander Leidinger wrote: > This was addressed further down in the text (the part which you didn't > quote here). The official user interface to the sensors from userland > would be the userland library. As we are an open source OS, we can not > hide something, we can only declare something as an official interface, > or an internal interface. sysctl would allow to export the data in an > hierarchical and unified way. sysctl is a well tested and working > interface in FreeBSD to export data from the kernel to the userland. > > If or if not there are much changes and extensions in an incompatible > way, can not be determined in such a high level architectural > discussion. To be able to talk about this, we have to got more towards > the implementation direction. But anyway, the userland access library > we envision so far is supposed to handle this gracefully. > > The implicit question we answered here is, if we invent a new interface > or augment an existing and well tested interface with some meta > information in a subtree. So far it looks we want to use existing > interfaces (a sysctl subtree for the data and devctl for notifications). > > What such an hierarchical and MIB like interface allows is, that you > can get the notification "event sensor X switched to a critical value" > and directly poll the value in an easy way. If, for example, you want > to produce something similar via a pseudo-filesystem, you have to > actually write a filesystem. This is a more complex task to get right > than to use the functions in the kernel to handle sysctls. It also > involves more processing in the kernel (mounting, VFS > interaction, ...). With procfs we learned that a filesystem for > something like this is hard to get right. After switching from procfs > to sysctl's to gather data for top/ps/..., we noticed that it is more > easy to get right via sysctl's, and that sysctl's are a good interface > to export such data from the kernel. Then it's ok for me :)=20 But i think you should drop some unrealistic requirements: Please do not define some event-latency thresholds here. So if it's to=20 complicated to handle in kernel event triggers, just let the daemons do=20 the job. FreeBSD is not RT OS in any way.=20 An RFC already mentioned above show a good example of how the data could be= =20 exported to another world via SNMP (you can even generate traps via BSNMPD= =20 daemon), let's do not invent yet another "Group-level sensors framework".=20 I am bit sceptic of it. So as an admin i would be happy with a daemon that= =20 could write some logs and trigger events, utility that could show current=20 stats and SNMP MIB that could be listed via network. This just my=20 requirements for sensors framework as a black box :)=20 Thanks. =2D-=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 =2D Best regards, Nikolay Pavlov. <<<----------------------------------- = =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 --nextPart1672619.TaOcxpx39Z Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBHNK8U/2R6KvEYGaIRAlLkAJ4+Cd+bKsSqAVsKpACJHJKXct6PYACfYWTW mp3PfXt6vMlkkymOjVVTobY= =Cq/Z -----END PGP SIGNATURE----- --nextPart1672619.TaOcxpx39Z-- From owner-freebsd-arch@FreeBSD.ORG Fri Nov 9 20:57:36 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 21ACF16A418; Fri, 9 Nov 2007 20:57:36 +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 4709D13C4A8; Fri, 9 Nov 2007 20:57:35 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A55635.dip.t-dialin.net [84.165.86.53]) by redbull.bpaserver.net (Postfix) with ESMTP id 590EC2E0D9; Fri, 9 Nov 2007 21:57:22 +0100 (CET) Received: from deskjail (deskjail.Leidinger.net [192.168.1.109]) by outgoing.leidinger.net (Postfix) with ESMTP id B7E463148AC6; Fri, 9 Nov 2007 21:57:19 +0100 (CET) Date: Fri, 9 Nov 2007 21:57:18 +0100 From: Alexander Leidinger To: qpadla@gmail.com Message-ID: <20071109215718.370a90d6@deskjail> In-Reply-To: <200711092103.48652.qpadla@gmail.com> References: <20071109124421.3c1901b1@deskjail> <200711091851.19445.qpadla@gmail.com> <20071109185741.13930f0b@deskjail> <200711092103.48652.qpadla@gmail.com> X-Mailer: Claws Mail 3.0.1 (GTK+ 2.10.14; i686-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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=-15.246, required 8, autolearn=not spam, BAYES_00 -15.00, RDNS_DYNAMIC 0.10, SMILEY -0.50, TW_OC 0.08, TW_VC 0.08) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: cnst@freebsd.org, arch@freebsd.org, rwatson@freebsd.org, freebsd-arch@freebsd.org, imp@freebsd.org Subject: Re: sensors framework continued (architecture) 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, 09 Nov 2007 20:57:36 -0000 Quoting Nikolay Pavlov (Fri, 9 Nov 2007 21:03:43 +0200): > On Friday 09 November 2007 19:57:41 Alexander Leidinger wrote: > > This was addressed further down in the text (the part which you didn't > > quote here). The official user interface to the sensors from userland > > would be the userland library. As we are an open source OS, we can not > > hide something, we can only declare something as an official interface, > > or an internal interface. sysctl would allow to export the data in an > > hierarchical and unified way. sysctl is a well tested and working > > interface in FreeBSD to export data from the kernel to the userland. > > > > If or if not there are much changes and extensions in an incompatible > > way, can not be determined in such a high level architectural > > discussion. To be able to talk about this, we have to got more towards > > the implementation direction. But anyway, the userland access library > > we envision so far is supposed to handle this gracefully. > > > > The implicit question we answered here is, if we invent a new interface > > or augment an existing and well tested interface with some meta > > information in a subtree. So far it looks we want to use existing > > interfaces (a sysctl subtree for the data and devctl for notifications). > > > > What such an hierarchical and MIB like interface allows is, that you > > can get the notification "event sensor X switched to a critical value" > > and directly poll the value in an easy way. If, for example, you want > > to produce something similar via a pseudo-filesystem, you have to > > actually write a filesystem. This is a more complex task to get right > > than to use the functions in the kernel to handle sysctls. It also > > involves more processing in the kernel (mounting, VFS > > interaction, ...). With procfs we learned that a filesystem for > > something like this is hard to get right. After switching from procfs > > to sysctl's to gather data for top/ps/..., we noticed that it is more > > easy to get right via sysctl's, and that sysctl's are a good interface > > to export such data from the kernel. > > Then it's ok for me :) > But i think you should drop some unrealistic requirements: > Please do not define some event-latency thresholds here. So if it's to > complicated to handle in kernel event triggers, just let the daemons do > the job. FreeBSD is not RT OS in any way. You just expressed my opinion in another way. Poul's suggestion triggered those thoughts, and as I already wrote, as long as we don't have hard date which shows that we need something like this, we should not put the polling code into the kernel. IMO we should let the userland do the work. In my current view of the situation we just use devctl to notify the userland about a change of a event based sensor. For non-event based sensors the userland is responsible to poll in suitable time intervals. > An RFC already mentioned above show a good example of how the data could be > exported to another world via SNMP (you can even generate traps via BSNMPD > daemon), let's do not invent yet another "Group-level sensors framework". > I am bit sceptic of it. So as an admin i would be happy with a daemon that > could write some logs and trigger events, utility that could show current > stats and SNMP MIB that could be listed via network. This just my > requirements for sensors framework as a black box :) The userland library we have in mind would allow to define a config for the sensors in a central place for all tools which make use of it. One tool which could make use of it would be bsnmpd. It could contain a generic plugin which queries the userland sensors library and populate a suitable MIB with all the sensors the library provides. The userland library could also be used by systat to show the current stats. For the events triggering (only for event based sensors) devd could be used in the current model I wrote about. And regarding the logging of some sensor data, there's also no problem (also using the library). In fact for all the usage scenarios you talked about (except for bsnmpd) exists code produced in a Google Sumemr of Code project which does just this for kernel sensors. What we do here in this thread is to evaluate the architecture of some kind of sensors framework we want to have and if the existing code meets our architectural requirements (or parts of it). If it meets our requirements, the next logical step would be to investigate the code if it fulfills our quality requirements, or if there need to be some changes to it. Bye, Alexander. -- VICARIOUSLY experience some reason to LIVE!! http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-arch@FreeBSD.ORG Fri Nov 9 20:57:36 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 21ACF16A418; Fri, 9 Nov 2007 20:57:36 +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 4709D13C4A8; Fri, 9 Nov 2007 20:57:35 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A55635.dip.t-dialin.net [84.165.86.53]) by redbull.bpaserver.net (Postfix) with ESMTP id 590EC2E0D9; Fri, 9 Nov 2007 21:57:22 +0100 (CET) Received: from deskjail (deskjail.Leidinger.net [192.168.1.109]) by outgoing.leidinger.net (Postfix) with ESMTP id B7E463148AC6; Fri, 9 Nov 2007 21:57:19 +0100 (CET) Date: Fri, 9 Nov 2007 21:57:18 +0100 From: Alexander Leidinger To: qpadla@gmail.com Message-ID: <20071109215718.370a90d6@deskjail> In-Reply-To: <200711092103.48652.qpadla@gmail.com> References: <20071109124421.3c1901b1@deskjail> <200711091851.19445.qpadla@gmail.com> <20071109185741.13930f0b@deskjail> <200711092103.48652.qpadla@gmail.com> X-Mailer: Claws Mail 3.0.1 (GTK+ 2.10.14; i686-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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=-15.246, required 8, autolearn=not spam, BAYES_00 -15.00, RDNS_DYNAMIC 0.10, SMILEY -0.50, TW_OC 0.08, TW_VC 0.08) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: cnst@freebsd.org, arch@freebsd.org, rwatson@freebsd.org, freebsd-arch@freebsd.org, imp@freebsd.org Subject: Re: sensors framework continued (architecture) 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, 09 Nov 2007 20:57:36 -0000 Quoting Nikolay Pavlov (Fri, 9 Nov 2007 21:03:43 +0200): > On Friday 09 November 2007 19:57:41 Alexander Leidinger wrote: > > This was addressed further down in the text (the part which you didn't > > quote here). The official user interface to the sensors from userland > > would be the userland library. As we are an open source OS, we can not > > hide something, we can only declare something as an official interface, > > or an internal interface. sysctl would allow to export the data in an > > hierarchical and unified way. sysctl is a well tested and working > > interface in FreeBSD to export data from the kernel to the userland. > > > > If or if not there are much changes and extensions in an incompatible > > way, can not be determined in such a high level architectural > > discussion. To be able to talk about this, we have to got more towards > > the implementation direction. But anyway, the userland access library > > we envision so far is supposed to handle this gracefully. > > > > The implicit question we answered here is, if we invent a new interface > > or augment an existing and well tested interface with some meta > > information in a subtree. So far it looks we want to use existing > > interfaces (a sysctl subtree for the data and devctl for notifications). > > > > What such an hierarchical and MIB like interface allows is, that you > > can get the notification "event sensor X switched to a critical value" > > and directly poll the value in an easy way. If, for example, you want > > to produce something similar via a pseudo-filesystem, you have to > > actually write a filesystem. This is a more complex task to get right > > than to use the functions in the kernel to handle sysctls. It also > > involves more processing in the kernel (mounting, VFS > > interaction, ...). With procfs we learned that a filesystem for > > something like this is hard to get right. After switching from procfs > > to sysctl's to gather data for top/ps/..., we noticed that it is more > > easy to get right via sysctl's, and that sysctl's are a good interface > > to export such data from the kernel. > > Then it's ok for me :) > But i think you should drop some unrealistic requirements: > Please do not define some event-latency thresholds here. So if it's to > complicated to handle in kernel event triggers, just let the daemons do > the job. FreeBSD is not RT OS in any way. You just expressed my opinion in another way. Poul's suggestion triggered those thoughts, and as I already wrote, as long as we don't have hard date which shows that we need something like this, we should not put the polling code into the kernel. IMO we should let the userland do the work. In my current view of the situation we just use devctl to notify the userland about a change of a event based sensor. For non-event based sensors the userland is responsible to poll in suitable time intervals. > An RFC already mentioned above show a good example of how the data could be > exported to another world via SNMP (you can even generate traps via BSNMPD > daemon), let's do not invent yet another "Group-level sensors framework". > I am bit sceptic of it. So as an admin i would be happy with a daemon that > could write some logs and trigger events, utility that could show current > stats and SNMP MIB that could be listed via network. This just my > requirements for sensors framework as a black box :) The userland library we have in mind would allow to define a config for the sensors in a central place for all tools which make use of it. One tool which could make use of it would be bsnmpd. It could contain a generic plugin which queries the userland sensors library and populate a suitable MIB with all the sensors the library provides. The userland library could also be used by systat to show the current stats. For the events triggering (only for event based sensors) devd could be used in the current model I wrote about. And regarding the logging of some sensor data, there's also no problem (also using the library). In fact for all the usage scenarios you talked about (except for bsnmpd) exists code produced in a Google Sumemr of Code project which does just this for kernel sensors. What we do here in this thread is to evaluate the architecture of some kind of sensors framework we want to have and if the existing code meets our architectural requirements (or parts of it). If it meets our requirements, the next logical step would be to investigate the code if it fulfills our quality requirements, or if there need to be some changes to it. Bye, Alexander. -- VICARIOUSLY experience some reason to LIVE!! http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-arch@FreeBSD.ORG Sat Nov 10 09:34: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 2A07816A41A for ; Sat, 10 Nov 2007 09:34:48 +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 C07A813C491 for ; Sat, 10 Nov 2007 09:34:47 +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 EB58B17105; Sat, 10 Nov 2007 09:34:37 +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 lAA9Yb2v063474; Sat, 10 Nov 2007 09:34:37 GMT (envelope-from phk@critter.freebsd.dk) To: "Attilio Rao" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 08 Nov 2007 20:35:07 +0100." <3bbf2fe10711081135y3473817ejbc72574e3e8c763d@mail.gmail.com> Date: Sat, 10 Nov 2007 09:34:37 +0000 Message-ID: <63473.1194687277@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-arch@freebsd.org Subject: Re: [RFC] callout overhaul: part I 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, 10 Nov 2007 09:34:48 -0000 In message <3bbf2fe10711081135y3473817ejbc72574e3e8c763d@mail.gmail.com>, "Atti lio Rao" writes: First I'd like to thank you for doing something about this Attilio, I havn't had time for it recently. You are right in many of the points you make, RETURNUNLOCKED, different kinds of locks etc, and we should integrate that into my API proposal. You are also wrong in some places, and I'd like to discuss those. 1. About the name ------------------ In my proposal I used a generic XXX_ prefix, because nailing the name was not the bikeshed I wanted to paint. You have chosen "callout" but I'm not sure I like that very much, this is not really a callout facility, it is a timer facility. I don't like when core APIs have silly long names, that clutters up source code needlessly, so my preference would probably be to use a short prefix, something like "tmr", "when", "wake" or similar. But let's take that offline and not start a bikeshed here. 2. About XXX_instances ----------------------- You propose a XXX_arm() and a XXX_arm_cpu(). That is a pointless limitation. My API proposal said specifically: > The functions above will actually be wrappers for a more generic > set of the same family, which also takes a pointer to a callout-group. And I guess the meaning of this was too subtle, so I will elaborate: The fundamental function will be called XXX_arm_cg(struct xxx_group *cg, ...) The xxx_group argument can be NULL, in which case a group is chosen for you by unspecified means. XXX_arm(...) Is a macro wrapper that calls the above with a NULL argument, and we can make XXX_arm_cpu(...) call it with an argument of pcpu->callout_group if we like. But we do not want to limit ourselves to only those two options, for intance we may find it a benefit later to put long running non-likely callouts in their own group, optimized for such behaviour. (And we cannot settle the group earlier than xxx_arm() if we want to have the per-cpu option, so xxx_init() can't do it) 3. Two stage conversion ----------------------- You propose a two-stage conversion. That is a bad idea when we can do it as efficiently with a one-stage conversion. Having thought a bit more about the conversion, I think the right way to do this is parallel implementations: Lets add the new API and start converting critical code to use it. We may have to retain the old callout-wheel for a couple of releases for compat reasons anyway, and I'm not convinced that it is sensible to emulate the old API with the new, the cost in calculations and memory management may be too high. -- 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 Nov 10 10:35:48 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 0801F16A417; Sat, 10 Nov 2007 10:35:48 +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 78ACA13C4A8; Sat, 10 Nov 2007 10:35:47 +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 0F9E317105; Sat, 10 Nov 2007 10:04:22 +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 lAAA4MiP063672; Sat, 10 Nov 2007 10:04:22 GMT (envelope-from phk@critter.freebsd.dk) To: Alexander Leidinger From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 09 Nov 2007 12:44:21 +0100." <20071109124421.3c1901b1@deskjail> Date: Sat, 10 Nov 2007 10:04:22 +0000 Message-ID: <63671.1194689062@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: rwatson@freebsd.org, cnst@freebsd.org, imp@freebsd.org, arch@freebsd.org Subject: Re: sensors framework continued (architecture) 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, 10 Nov 2007 10:35:48 -0000 In message <20071109124421.3c1901b1@deskjail>, Alexander Leidinger writes: (sorry about the screwed up formatting, my mail-reader couldn't make sense of the incoming formatting) >The current state of affairs: > >We want a kernel sensors framework and a single-system sensors framework in > FreeBSD. > >For the kernel sensors framework phk proposes (Message-ID: <81952.119278686 >4@critter.freebsd.dk>, <82533.1192797289@critter.freebsd.dk>) a fd which su >pports select/poll/kevent as the interface between the kernel and the userl >and (Julian and Max also proposed an fd based interface without going into >as much details regarding events like Poul did). An ioctl() could be used t >o specify the polling intervall of sensors which are not event-driven. This > implies that we have to move the polling intervall code for non-event driv >en sensors from the userland to the kernel. No it does not. It would be prefectly sensible to have an ioctl(2) (or write(2)!) that says "poll this sensor now" to keep control in userland if that is desired. Some sensors however, are hardware timed, and for those it makes more sense to be able to tell them "we want one report every second" and not worry more about it. >Warner proposes to use an existing interface (devd) for event driven sensor >s (<20071019.100516.74722974.imp@bsdimp.com>). Poul agrees that events (lik >e "high temp" and similar, but not the actual raw data like "32=C2=B0C") co >uld be send to devd instead. I like to extend this so that it is send over >the devd socket, but that devd should not react to every sensor related eve >nt, but the signle-system sensor framework is supposed to handle such event >s. I'm on the fence on this one still. I don't know what the overhead of double-using the devd descriptor would be. It's certainly not an obviously good idea to mix the two functionalities too much, on the other hand, splitting them is not an obvious good idea either. Obviously a way to poke devd from sensord is required under all circumstances. (Which brings up the point that maybe devd(8) should have been called syseventd(8) ?) >Robert thinks that sysctl MIBs offer "a more semantically rich and, to be h >onest, better defined way of interacting with live subsystems than device f >iles do in a generic sense". Nobody objected to this opinion or provided re >asons why a fd based approach is better than a sysctl MIB based approach. R >icardo Nabinger Sanchez points out http://www.ietf.org/rfc/rfc3433.txt (RFC > for sensor MIBs). Please notice that the two are not exclusive, as devd(8) so clearly implements that. >The single-system sensors framework should be implemented in a library whic >h userland programs like systat, SNMP or other monitoring daemons use (jhb, > Message-Id: <200710181450.38224.jhb@freebsd.org>). The kernel-userland int >erface of the kernel sensors framework would be an internal interface of Fr >eeBSD and every program which wants access to a sensor would have to use th >e library as the official interface. Agreed 100%. >So to sum it up it looks like the architecture looks as follows: > - using sysctls for centralized exporting of sensor data from kernel > to userland (polling interface for userland polling code) I think you are jumping to conclusions here. > - using devctl_notify() for change-events (the userland can then > read the changed value via the sysctl interface) Agreed. > - writting a library (the single-system sensors framework backend) > which abstracts away the kernel-userland interface of the kernel > sensors framework and provides an official interface for userland > programs to all sensors in the system Agreed. >Did I got the architecture/summary right or did I miss a mail on arch@ whic >h made the fd based approach more beneficial than the sysctl+devctl based a >pproach? sysctl is by definition limited to polling, which, for any significant number of sensors, becomes very expensive compared the ability of an fd-based approach to queue and batch data. I'm sure that it is no accident that Warner used the fd based approach for devd(8). -- 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 Nov 10 14:05:16 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 E636116A420 for ; Sat, 10 Nov 2007 14:05:15 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.188]) by mx1.freebsd.org (Postfix) with ESMTP id F33F513C48D for ; Sat, 10 Nov 2007 14:05:14 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by mu-out-0910.google.com with SMTP id i10so964916mue for ; Sat, 10 Nov 2007 06:05:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=6ELJRaDcwkK5IU9JnufBGvOaiJ2KcOmc/nMqAydhh5I=; b=exsgbF/+HC5URVmbI38chxJgw+jXbYkx8wI6o79LEOF5o2/kDCJGze+FHcvwM06N7yYBwzKl8zW8mWKXkRNoI5Vvq4LloMZW1W2fdpkTLNYzREclLAXlqg6xz79FBbPfJfhJTIK14EYATJ6e5PWe6iENn8SKCpaLqKN4oY/3Fl4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=g9VwYZJxioAjUitlOF9hC6nOCvXT1NN+BROLuioCZACyyhe4pN7gFAPgHcZZ8Fpk8q972Wn51NoKLWF2x1vd+gcPbbpMemTz/i/rJKIg+oXa2tY7pRowOWfE84oHgY9QPSEY0OypQ0MJ2ZrK7Gp6Y0Ewj0tsC0DnCLIBztECziI= Received: by 10.86.50.8 with SMTP id x8mr2469876fgx.1194703502948; Sat, 10 Nov 2007 06:05:02 -0800 (PST) Received: by 10.86.90.4 with HTTP; Sat, 10 Nov 2007 06:05:02 -0800 (PST) Message-ID: <3bbf2fe10711100605h6b12238au7cc9d0fc6d1afde@mail.gmail.com> Date: Sat, 10 Nov 2007 15:05:02 +0100 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Poul-Henning Kamp" In-Reply-To: <63473.1194687277@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3bbf2fe10711081135y3473817ejbc72574e3e8c763d@mail.gmail.com> <63473.1194687277@critter.freebsd.dk> X-Google-Sender-Auth: 08240306476b2cdb Cc: freebsd-arch@freebsd.org Subject: Re: [RFC] callout overhaul: part I 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, 10 Nov 2007 14:05:16 -0000 2007/11/10, Poul-Henning Kamp : > 1. About the name > ------------------ > > In my proposal I used a generic XXX_ prefix, because nailing the > name was not the bikeshed I wanted to paint. > > You have chosen "callout" but I'm not sure I like that very much, > this is not really a callout facility, it is a timer facility. > > I don't like when core APIs have silly long names, that clutters > up source code needlessly, so my preference would probably be > to use a short prefix, something like "tmr", "when", "wake" or > similar. > > But let's take that offline and not start a bikeshed here. Well, I have no name preference really, so if you have something better in mind it is good. For the moment however, as I'm concentrating in adding "missing support" I want to remain more callout compliant. > 2. About XXX_instances > ----------------------- > > You propose a XXX_arm() and a XXX_arm_cpu(). That is a pointless > limitation. > > My API proposal said specifically: > > > The functions above will actually be wrappers for a more generic > > set of the same family, which also takes a pointer to a callout-group. > > And I guess the meaning of this was too subtle, so I will elaborate: > > The fundamental function will be called > > XXX_arm_cg(struct xxx_group *cg, ...) > > The xxx_group argument can be NULL, in which case a group is > chosen for you by unspecified means. Is this group, in your idea, sorta of a node of the heap you previously discussed in the thread? > 3. Two stage conversion > ----------------------- > > You propose a two-stage conversion. That is a bad idea when we > can do it as efficiently with a one-stage conversion. > > Having thought a bit more about the conversion, I think the right > way to do this is parallel implementations: Lets add the new > API and start converting critical code to use it. This is good. Speaking of which, perforce can really help in breaking commits in mealpieces. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-arch@FreeBSD.ORG Sat Nov 10 14:12:20 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 EB39216A418; Sat, 10 Nov 2007 14:12:20 +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 A3E4313C4A8; Sat, 10 Nov 2007 14:12:20 +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 3116517105; Sat, 10 Nov 2007 14:12: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 lAAEC7Wk064646; Sat, 10 Nov 2007 14:12:07 GMT (envelope-from phk@critter.freebsd.dk) To: "Attilio Rao" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 10 Nov 2007 15:05:02 +0100." <3bbf2fe10711100605h6b12238au7cc9d0fc6d1afde@mail.gmail.com> Date: Sat, 10 Nov 2007 14:12:07 +0000 Message-ID: <64645.1194703927@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-arch@freebsd.org Subject: Re: [RFC] callout overhaul: part I 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, 10 Nov 2007 14:12:21 -0000 In message <3bbf2fe10711100605h6b12238au7cc9d0fc6d1afde@mail.gmail.com>, "Attil io Rao" writes: >> 2. About XXX_instances >> ----------------------- >> >> You propose a XXX_arm() and a XXX_arm_cpu(). That is a pointless >> limitation. >> >> My API proposal said specifically: >> >> > The functions above will actually be wrappers for a more generic >> > set of the same family, which also takes a pointer to a callout-group. >> >> And I guess the meaning of this was too subtle, so I will elaborate: >> >> The fundamental function will be called >> >> XXX_arm_cg(struct xxx_group *cg, ...) >> >> The xxx_group argument can be NULL, in which case a group is >> chosen for you by unspecified means. > >Is this group, in your idea, sorta of a node of the heap you >previously discussed in the thread? It is the handle for the handler you want to use, whatever that is and however it is implemented. The binary heap will be one member of that struct I pressume, if the implementation does use a binary heap in the first place. Our first implementation would likely use the existing callout mechanism, so that the API conversion can be decoupled from the implementation of the new and smarter techniques. -- 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 Nov 10 19:33:05 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 05A6016A46B; Sat, 10 Nov 2007 19:33:05 +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 435ED13C4C1; Sat, 10 Nov 2007 19:33:04 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A5694F.dip.t-dialin.net [84.165.105.79]) by redbull.bpaserver.net (Postfix) with ESMTP id C05A02E2F7; Sat, 10 Nov 2007 20:32:33 +0100 (CET) Received: from deskjail (deskjail.Leidinger.net [192.168.1.109]) by outgoing.leidinger.net (Postfix) with ESMTP id 8795A3148AC6; Sat, 10 Nov 2007 20:32:30 +0100 (CET) Date: Sat, 10 Nov 2007 20:32:29 +0100 From: Alexander Leidinger To: "Poul-Henning Kamp" Message-ID: <20071110203229.64021d85@deskjail> In-Reply-To: <63671.1194689062@critter.freebsd.dk> References: <20071109124421.3c1901b1@deskjail> <63671.1194689062@critter.freebsd.dk> X-Mailer: Claws Mail 3.0.1 (GTK+ 2.10.14; i686-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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=3.354, required 8, BAYES_50 2.50, J_CHICKENPOX_66 0.60, RDNS_DYNAMIC 0.10, TW_PH 0.08, TW_VC 0.08) X-BPAnet-MailScanner-SpamScore: sss X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: rwatson@freebsd.org, cnst@freebsd.org, imp@freebsd.org, arch@freebsd.org Subject: Re: sensors framework continued (architecture) 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, 10 Nov 2007 19:33:05 -0000 Quoting "Poul-Henning Kamp" (Sat, 10 Nov 2007 10:04:22 +0000): > In message <20071109124421.3c1901b1@deskjail>, Alexander Leidinger writes: > > (sorry about the screwed up formatting, my mail-reader couldn't make > sense of the incoming formatting) Sorry, I included the text into my MUA after writting it in a normal editor. It seems the wordwrap wasn't done as usual in the MUA then. > >The current state of affairs: > > > >We want a kernel sensors framework and a single-system sensors framework in > > FreeBSD. > > > >For the kernel sensors framework phk proposes (Message-ID: <81952.119278686 > >4@critter.freebsd.dk>, <82533.1192797289@critter.freebsd.dk>) a fd which su > >pports select/poll/kevent as the interface between the kernel and the userl > >and (Julian and Max also proposed an fd based interface without going into > >as much details regarding events like Poul did). An ioctl() could be used t > >o specify the polling intervall of sensors which are not event-driven. This > > implies that we have to move the polling intervall code for non-event driv > >en sensors from the userland to the kernel. > > No it does not. > > It would be prefectly sensible to have an ioctl(2) (or write(2)!) > that says "poll this sensor now" to keep control in userland if > that is desired. > > Some sensors however, are hardware timed, and for those it makes > more sense to be able to tell them "we want one report every second" > and not worry more about it. Two kinds of behavior come into my mind when I read this. First behavior ("poll this sensor now"): If the userland application wants to poll the non-event driven sensors (or sensors which are not hardware timed), it has to issue 2 syscalls for each sensor, one to let it poll (ioctl), and one to read the data. The polling interval is handled by the userland. What I like here is, that the polling interval handling is in the userland for non-event driven and non-hardware-timed sensors (let's call those "simple" sensors). What I don't like is that we have to issue more than one syscall. Why not just do one syscall (be it read for a fd based solution, or sysctl, doesn't matter ATM) to get the data, and let the sensor decide if he returns a cached value (for event driven or hardware timed sensors), or does a real readout (for the simple sensors). This way you can read at any time (imagine an admin which not only has a network wide monitoring application, but also goes to the data center to do some work which involves checking one of the sensors on one machine with a local application), and get the benefit of event driven or hardware timed sensors too. When you tell "give me a value", you want the value now, and not when some event (e.g. the polling timer) triggers a data transfer to the userland. How recent the value can be, depends upon the sensor. For simple sensors it's the current value, for event driven sensors it's also the current value, only the data from hardware timed sensors may be not actual. If this is critical or not, depends upon the sensor and the use of the data from this sensor. I don't know of hardware timed sensors in normal PC hardware. I'm only aware of external devices which monitor machines ("machines" in the sense of "it's not a computer") which are hardware timed. I think such sensors (at least the advanced onces) can not be completely handled by a generic sensors framework and need some configuration interface (either via a driver specific command line tool, or via the sysctl MIB (dev.XXX) of this device, or whatever interface is suitable for the device, maybe to configure it you have to use a serial line) for the setup from a PC (if the setup is not handled on the sensor-device itself). Second behavior (your previous proposal to put the polling interval into the kernel via an ioctl): The userland does a syscall for a non-event driven and non-hardware-timed sensor to specify the polling interval and the application waits for events (select/kevent/...) from the sensors framework. This would mean that we need some polling code in the kernel which starts some timers (it may be the case that the admin has different interval requirements for different kinds of sensors) for the non-event driven and non-hardware-timed sensors. I don't like to have the polling code in the kernel. I would like to have it in the userland. See my proposal above, where I talk about reading cached values for event based sensors and doing a readout of the sensor data for simple sensors. For sensors where it is not good to readout the sensor data from the device too often, a cached value can also be returned. For those types we don't really need the polling code in the kernel. And for the "smart" sensors, you don't need the polling code at all. > >Warner proposes to use an existing interface (devd) for event driven sensor > >s (<20071019.100516.74722974.imp@bsdimp.com>). Poul agrees that events (lik > >e "high temp" and similar, but not the actual raw data like "32=C2=B0C") co > >uld be send to devd instead. I like to extend this so that it is send over > >the devd socket, but that devd should not react to every sensor related eve > >nt, but the signle-system sensor framework is supposed to handle such event > >s. > > I'm on the fence on this one still. I don't know what the overhead > of double-using the devd descriptor would be. It's certainly not an It obviously depends upon the amount of events which occur and how they are processes by the programs listening to events. Typically you don't want much events to happen. > obviously good idea to mix the two functionalities too much, on the > other hand, splitting them is not an obvious good idea either. > > Obviously a way to poke devd from sensord is required under all > circumstances. Really? I see devd as an action based daemon. He gets an event, and based upon his config he starts some more or less complex and configurable action (scripts) or not. A sensorsd (which could be bsnmpd) just consumes the data from the events (yes, an event triggers an action, namely reading the sensors data, but this is not configurable, and not complex at all). Both programs want to listen to events, but they don't need to interact. Both can listen on /dev/devctl (yes, the devctl access needs to be changed for this). > (Which brings up the point that maybe devd(8) should have been called > syseventd(8) ?) Currently devd could also be named eventactiond. I don't think devd should start an action for all sensor events (transfering data to sensorsd/snmpd). I could imagine a eventdispatcherd (if you don't want more than one program to access /dev/devctl) which has a fanin of 1 (devctl), and a fanout of N (eventactiond, sensorsd/snmpd, ...). But we're drifting away here, let's not continue here with this. > >Robert thinks that sysctl MIBs offer "a more semantically rich and, to be h > >onest, better defined way of interacting with live subsystems than device f > >iles do in a generic sense". Nobody objected to this opinion or provided re > >asons why a fd based approach is better than a sysctl MIB based approach. R > >icardo Nabinger Sanchez points out http://www.ietf.org/rfc/rfc3433.txt (RFC > > for sensor MIBs). > > Please notice that the two are not exclusive, as devd(8) so clearly > implements that. devd receives events. A sensorsd may want to get data for different sensors in different intervals. As written above I don't like to have the polling code in the kernel, so I still agree with Robert that a sysctl MIB looks better for this. > >So to sum it up it looks like the architecture looks as follows: > > - using sysctls for centralized exporting of sensor data from kernel > > to userland (polling interface for userland polling code) > > I think you are jumping to conclusions here. As written, nobody came up with strong arguments (actually there where no replies at all) to Roberts mail. Given the amount of mails in a short timeframe to this topic before, and the large amount of time without any reply to Roberts mail, it doesn't feel like jumping to conclusions. If you (or someone else) have some strong arguments, but not enough time ATM, feel free to tell us when you expect to have time to tell us about those arguments. I'm sure Robert (and others) are willing to listen to your arguments. > >Did I got the architecture/summary right or did I miss a mail on arch@ whic > >h made the fd based approach more beneficial than the sysctl+devctl based a > >pproach? > > sysctl is by definition limited to polling, which, for any significant > number of sensors, becomes very expensive compared the ability of > an fd-based approach to queue and batch data. See my caching argument above. > I'm sure that it is no accident that Warner used the fd based approach > for devd(8). You want to react to events fast. A sysctl doesn't not make sense for devd. For sensor monitoring most of the use cases are polling based. So having the generic case handled via a polling based interface makes sense. For the parts where it isn't polling based, I wrote about sensible ways to handle it: - devctl for events - caching of data where it makes sense (the driver and in some cases some configuration item knows best if caching is needed or not) The normal system startup procedure (rc.d) would be responsible to setup any smart sensor in a sensible way. Apart from this, maybe some of such smart sensors are better handled by the userland part of the single-system sensor framework, than by the kernel sensor framework. So far this approach covers all the use cases you presented here, without the need to have some polling code in the kernel and without the need of a more complex handling of the polling (higher amount of syscalls for the more common polling case). Bye, Alexander. -- No one wants war. -- Kirk, "Errand of Mercy", stardate 3201.7 http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-arch@FreeBSD.ORG Sat Nov 10 22:54:56 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 75FD516A421; Sat, 10 Nov 2007 22:54:56 +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 E462F13C4B5; Sat, 10 Nov 2007 22:54:55 +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 B788F17105; Sat, 10 Nov 2007 22:54:42 +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 lAAMsf0u001403; Sat, 10 Nov 2007 22:54:42 GMT (envelope-from phk@critter.freebsd.dk) To: Alexander Leidinger From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 10 Nov 2007 20:32:29 +0100." <20071110203229.64021d85@deskjail> Date: Sat, 10 Nov 2007 22:54:41 +0000 Message-ID: <1402.1194735281@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: rwatson@freebsd.org, cnst@freebsd.org, imp@freebsd.org, arch@freebsd.org Subject: Re: sensors framework continued (architecture) 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, 10 Nov 2007 22:54:56 -0000 In message <20071110203229.64021d85@deskjail>, Alexander Leidinger writes: >Quoting "Poul-Henning Kamp" (Sat, 10 Nov 2007 10:04:22 +0000): > >> >This >> > implies that we have to move the polling intervall code for non-event driv >> >en sensors from the userland to the kernel. >> >> No it does not. >> >> It would be prefectly sensible to have an ioctl(2) (or write(2)!) >> that says "poll this sensor now" to keep control in userland if >> that is desired. >> >> Some sensors however, are hardware timed, and for those it makes >> more sense to be able to tell them "we want one report every second" >> and not worry more about it. > >Two kinds of behavior come into my mind when I read this. > >First behavior ("poll this sensor now"): If the userland application >wants to poll the non-event driven sensors (or sensors which are not >hardware timed), it has to issue 2 syscalls for each sensor, one to let >it poll (ioctl), and one to read the data. The polling interval is >handled by the userland. > >What I like here is, that the polling interval handling is in the >userland for non-event driven and non-hardware-timed sensors (let's >call those "simple" sensors). What I don't like is that we have to issue >more than one syscall. But you forget that sensors may have considerable "conversion" time. It is a benefit for us to be able to start the sensor and not block on the syscall waiting for it to do its thing. >> >So to sum it up it looks like the architecture looks as follows: >> > - using sysctls for centralized exporting of sensor data from kernel >> > to userland (polling interface for userland polling code) >> >> I think you are jumping to conclusions here. > >As written, nobody came up with strong arguments (actually there where >no replies at all) to Roberts mail. You are reading waaay too much into Roberts email and overlooking that a fd based kernel interface can also be MIB based. >> sysctl is by definition limited to polling, which, for any significant >> number of sensors, becomes very expensive compared the ability of >> an fd-based approach to queue and batch data. > >See my caching argument above. Which just adds to the mess, because then you have to also pass along a timestamp to tell how old the returned value is. There are a lot of downsides to sysctls which you do not seem to be aware of, locking, access time, overhead and several other issues makes sysctl very undesirable for anything which isn't "ad-hoc" or really seldomly used. Poul-Henning -- 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.