From owner-freebsd-arch@FreeBSD.ORG Sun Nov 25 02:10: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 5E04916A46E for ; Sun, 25 Nov 2007 02:10:16 +0000 (UTC) (envelope-from asmrookie@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 CA12B13C459 for ; Sun, 25 Nov 2007 02:10:15 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so253315nfb for ; Sat, 24 Nov 2007 18:10:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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=khjeeNtRUFWQgFeXwWwFNyjp0twWJLZp9yKpYIu5EEw=; b=BpUzLNtfipnY5P5i5zH+eHfXmfiBdoTQfcG1TT0uUySVbssSFIaFJrvBaO3NvmAUSVgVpyoP6e+OTu/B+TbdXHV2IVWn4LFotp1eZRRro2OJmNxl+qYTQ0oYfTVvjV9JYD9AnOVkr5fUz5ag2suYdm4L2tyNQQpbUkVX6PzkjOg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; 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=pzw08QQGgrREZRAnsZyRjxLrcCGfr/30RqjfuapvLgXTqES22t7ySR4g+opamKUN45iyxLQmsJTd9t2bfZXrDTWH5NxyvNCv6Feb3ufAFytKnvzqoCzxEAbHDcDJ8tcmx4w37ydFf6lwvxBABMMziqjjBvtPy7sDSrciqMf62VM= Received: by 10.86.49.13 with SMTP id w13mr1070069fgw.1195956606466; Sat, 24 Nov 2007 18:10:06 -0800 (PST) Received: by 10.86.28.19 with HTTP; Sat, 24 Nov 2007 18:10:06 -0800 (PST) Message-ID: <3bbf2fe10711241810o5b676b3ax330fda6a542b66da@mail.gmail.com> Date: Sun, 25 Nov 2007 03:10:06 +0100 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Robert Watson" In-Reply-To: <20071124162322.V14018@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20071121222319.GX44563@elvis.mu.org> <20071123082339.GN44563@elvis.mu.org> <47469328.8020404@freebsd.org> <20071123092415.GP44563@elvis.mu.org> <4746F858.4070301@freebsd.org> <20071123235346.E14018@fledge.watson.org> <3bbf2fe10711231930m459dc800wbbb894b9fd50ca13@mail.gmail.com> <20071124103231.A14018@fledge.watson.org> <3bbf2fe10711240553k1eb35a5au23cae8af08f5864c@mail.gmail.com> <20071124162322.V14018@fledge.watson.org> X-Google-Sender-Auth: 45f18262a6e5f8c1 Cc: Stephan Uphoff , Max Laier , Alfred Perlstein , freebsd-arch@freebsd.org Subject: Re: rwlocks, correctness over speed. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Nov 2007 02:10:16 -0000 2007/11/24, Robert Watson : > On Sat, 24 Nov 2007, Attilio Rao wrote: > > >> I must have missed recursion arriving then -- I'll modify uipc_usrreq.c to > >> set the recursion flag on the rwlock in UNIX domain sockets rather than > >> doing the nasty hack that was previously required. At the time, the hack > >> was added because it seemed recursion was not going to be added to rwlocks, > >> but sonewconn() behavior for listen sockets really ended up requiring it. > > > > attilio 2007-06-26 21:31:56 UTC > > > > FreeBSD src repository > > > > Modified files: > > sys/kern kern_rwlock.c > > sys/sys _rwlock.h rwlock.h > > Log: > > Introduce a new rwlocks initialization function: rw_init_flags. > > This is very similar to sx_init_flags: it initializes the rwlock using > > special flags passed as third argument (RW_DUPOK, RW_NOPROFILE, > > RW_NOWITNESS, RW_QUIET, RW_RECURSE). > > Among these, the most important new feature is probabilly that rwlocks > > can be acquired recursively now (for both shared and exclusive paths). > > Yes, that was four months after I added rw_wowned(9) to work around the lack > of recursion support. :-) However, it looks like the man page was never > updated? It contains the following rather explicit language: > > Another important property is that shared holders of rwlock can recurse, > but exclusive locks are not allowed to recurse. Ok, fix committed. Thanks to you and Skip for the report. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-arch@FreeBSD.ORG Mon Nov 26 12:34:51 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 ED27D16A420 for ; Mon, 26 Nov 2007 12:34:51 +0000 (UTC) (envelope-from qpadla@gmail.com) Received: from hu-out-0506.google.com (hu-out-0506.google.com [72.14.214.233]) by mx1.freebsd.org (Postfix) with ESMTP id 4E57813C4D3 for ; Mon, 26 Nov 2007 12:34:50 +0000 (UTC) (envelope-from qpadla@gmail.com) Received: by hu-out-0506.google.com with SMTP id 28so537799hub for ; Mon, 26 Nov 2007 04:34:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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=f4sTvQmXEp30E86suVu/uxvoPALy4J6/UyNb/bZGkCU=; b=aop7JxPJcq2J4EEeK2v8ozRJtmaMe/7WPASBtVLxp88HabEsMoEvBkh8VEjoTmlRVEHiZHnAytZfpd2uqP1DfV8R3v5lo81mHMxa7eaLp3Z2WVZIh23NJKf97PX5f7tajhVjqG3ZTOIe8aT54yON8+I9g8Q2FUE4W4NQDw2gWfw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; 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=gzVQ2+B6SDUou361kJNb1BOSGRBgnrtVKGueXeSgEhdhB46s9bWLoDZQtWyrXf4UypKp+2ErF+aXKh6MakjLq8fF4tYzjU7IRHboZOSE2dgF14PMUN3vxXxzbXXqxRa66hp4elAr1XXVx9yNVIBLkITujo2VbxnUji9D67HCMbY= Received: by 10.78.132.2 with SMTP id f2mr2739876hud.1196080488991; Mon, 26 Nov 2007 04:34:48 -0800 (PST) Received: from orion ( [89.162.141.1]) by mx.google.com with ESMTPS id d23sm1361817nfh.2007.11.26.04.34.46 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 26 Nov 2007 04:34:47 -0800 (PST) From: Nikolay Pavlov To: freebsd-arch@freebsd.org Date: Mon, 26 Nov 2007 14:34:40 +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="nextPart2467490.yFSCKo24dG"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200711261434.45765.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: Mon, 26 Nov 2007 12:34:52 -0000 --nextPart2467490.yFSCKo24dG Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Just want to mention that Linux lm-sensors 3.0.0 was released today. A few notes that could be interesting for us: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Quote =3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D * It is now a user-space-only package, it no longer contains kernel drivers. * The i2c tools have been moved to a separate package (surprisingly named i2c-tools). * libsensors' internal version was bumped to 4.0.0, as it has a completely new API we had to increase the .so version. This new library contains no chip-specific knowledge, it assumes that hardware monitoring drivers follow the standard sysfs interface. A very nice benefit of this is that the size of the library has been divided by 4 (down from 222 kB to 55 kB on i386). * Some kernel drivers still don't implement the standard interface for alarms, so alarm flags won't show. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Quote =3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D So as you can see it's fully userspace non chip-specific library, based on= =20 sysfs interface.=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 --nextPart2467490.yFSCKo24dG 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) iD8DBQBHSr1l/2R6KvEYGaIRAvkdAJ9YJ6HShCI3Ur4Y5oCfyGjtGw2TYgCdG/EB 9pBYh7SZ5bkBMIuO4jvBalw= =SeHz -----END PGP SIGNATURE----- --nextPart2467490.yFSCKo24dG-- From owner-freebsd-arch@FreeBSD.ORG Mon Nov 26 12:34:52 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 00B7116A421 for ; Mon, 26 Nov 2007 12:34:52 +0000 (UTC) (envelope-from qpadla@gmail.com) Received: from hu-out-0506.google.com (hu-out-0506.google.com [72.14.214.228]) by mx1.freebsd.org (Postfix) with ESMTP id 4F91513C4D9 for ; Mon, 26 Nov 2007 12:34:50 +0000 (UTC) (envelope-from qpadla@gmail.com) Received: by hu-out-0506.google.com with SMTP id 28so537795hub for ; Mon, 26 Nov 2007 04:34:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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=f4sTvQmXEp30E86suVu/uxvoPALy4J6/UyNb/bZGkCU=; b=aop7JxPJcq2J4EEeK2v8ozRJtmaMe/7WPASBtVLxp88HabEsMoEvBkh8VEjoTmlRVEHiZHnAytZfpd2uqP1DfV8R3v5lo81mHMxa7eaLp3Z2WVZIh23NJKf97PX5f7tajhVjqG3ZTOIe8aT54yON8+I9g8Q2FUE4W4NQDw2gWfw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; 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=gzVQ2+B6SDUou361kJNb1BOSGRBgnrtVKGueXeSgEhdhB46s9bWLoDZQtWyrXf4UypKp+2ErF+aXKh6MakjLq8fF4tYzjU7IRHboZOSE2dgF14PMUN3vxXxzbXXqxRa66hp4elAr1XXVx9yNVIBLkITujo2VbxnUji9D67HCMbY= Received: by 10.78.132.2 with SMTP id f2mr2739876hud.1196080488991; Mon, 26 Nov 2007 04:34:48 -0800 (PST) Received: from orion ( [89.162.141.1]) by mx.google.com with ESMTPS id d23sm1361817nfh.2007.11.26.04.34.46 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 26 Nov 2007 04:34:47 -0800 (PST) From: Nikolay Pavlov To: freebsd-arch@freebsd.org Date: Mon, 26 Nov 2007 14:34:40 +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="nextPart2467490.yFSCKo24dG"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200711261434.45765.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: Mon, 26 Nov 2007 12:34:52 -0000 --nextPart2467490.yFSCKo24dG Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Just want to mention that Linux lm-sensors 3.0.0 was released today. A few notes that could be interesting for us: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Quote =3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D * It is now a user-space-only package, it no longer contains kernel drivers. * The i2c tools have been moved to a separate package (surprisingly named i2c-tools). * libsensors' internal version was bumped to 4.0.0, as it has a completely new API we had to increase the .so version. This new library contains no chip-specific knowledge, it assumes that hardware monitoring drivers follow the standard sysfs interface. A very nice benefit of this is that the size of the library has been divided by 4 (down from 222 kB to 55 kB on i386). * Some kernel drivers still don't implement the standard interface for alarms, so alarm flags won't show. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Quote =3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D So as you can see it's fully userspace non chip-specific library, based on= =20 sysfs interface.=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 --nextPart2467490.yFSCKo24dG 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) iD8DBQBHSr1l/2R6KvEYGaIRAvkdAJ9YJ6HShCI3Ur4Y5oCfyGjtGw2TYgCdG/EB 9pBYh7SZ5bkBMIuO4jvBalw= =SeHz -----END PGP SIGNATURE----- --nextPart2467490.yFSCKo24dG-- From owner-freebsd-arch@FreeBSD.ORG Mon Nov 26 13:02: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 19B6C16A417; Mon, 26 Nov 2007 13:02:20 +0000 (UTC) (envelope-from brix@FreeBSD.org) Received: from solow.pil.dk (relay.pil.dk [195.41.47.164]) by mx1.freebsd.org (Postfix) with ESMTP id C5CD113C467; Mon, 26 Nov 2007 13:02:19 +0000 (UTC) (envelope-from brix@FreeBSD.org) Received: from tirith.brixandersen.dk (osgiliath.brixandersen.dk [87.53.223.189]) by solow.pil.dk (Postfix) with ESMTP id 648671CC0AF; Mon, 26 Nov 2007 13:44:40 +0100 (CET) Received: by tirith.brixandersen.dk (Postfix, from userid 1001) id 7115611436; Mon, 26 Nov 2007 13:44:39 +0100 (CET) Date: Mon, 26 Nov 2007 13:44:39 +0100 From: Henrik Brix Andersen To: Nikolay Pavlov Message-ID: <20071126124438.GA77230@tirith.brixandersen.dk> Mail-Followup-To: Nikolay Pavlov , freebsd-arch@freebsd.org, cnst@freebsd.org, arch@freebsd.org, rwatson@freebsd.org, Alexander Leidinger , imp@freebsd.org References: <20071109124421.3c1901b1@deskjail> <200711261434.45765.qpadla@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZPt4rx8FFjLCG7dd" Content-Disposition: inline In-Reply-To: <200711261434.45765.qpadla@gmail.com> X-PGP-Key: http://www.brixandersen.dk/files/HenrikBrixAndersen.asc User-Agent: Mutt/1.5.16 (2007-06-09) Cc: cnst@freebsd.org, arch@freebsd.org, rwatson@freebsd.org, freebsd-arch@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 List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2007 13:02:20 -0000 --ZPt4rx8FFjLCG7dd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 26, 2007 at 02:34:40PM +0200, Nikolay Pavlov wrote: > Just want to mention that Linux lm-sensors 3.0.0 was released today. > A few notes that could be interesting for us: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Quote =3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > * It is now a user-space-only package, it no longer contains kernel > drivers. > * The i2c tools have been moved to a separate package (surprisingly > named i2c-tools). > * libsensors' internal version was bumped to 4.0.0, as it has a > completely new API we had to increase the .so version. This new > library contains no chip-specific knowledge, it assumes that hardware > monitoring drivers follow the standard sysfs interface. A very nice > benefit of this is that the size of the library has been divided by > 4 (down from 222 kB to 55 kB on i386). > * Some kernel drivers still don't implement the standard interface > for alarms, so alarm flags won't show. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Quote =3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >=20 > So as you can see it's fully userspace non chip-specific library, based o= n=20 > sysfs interface.=20 And it has been for quite a while, unless you compiled it on an old Linux kernel (e.g. 2.4.x), which didn't have the required drivers. Brix --=20 Henrik Brix Andersen --ZPt4rx8FFjLCG7dd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: GnuPG signed iD8DBQFHSr+2v+Q4flTiePgRAk5rAKCSlHwSVTLPO9xFCL+g/zqhWZw6hwCgum1M +uLeNGb10lGBpLrTpiR9TKA= =1g2o -----END PGP SIGNATURE----- --ZPt4rx8FFjLCG7dd-- From owner-freebsd-arch@FreeBSD.ORG Mon Nov 26 13:02:20 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 19B6C16A417; Mon, 26 Nov 2007 13:02:20 +0000 (UTC) (envelope-from brix@FreeBSD.org) Received: from solow.pil.dk (relay.pil.dk [195.41.47.164]) by mx1.freebsd.org (Postfix) with ESMTP id C5CD113C467; Mon, 26 Nov 2007 13:02:19 +0000 (UTC) (envelope-from brix@FreeBSD.org) Received: from tirith.brixandersen.dk (osgiliath.brixandersen.dk [87.53.223.189]) by solow.pil.dk (Postfix) with ESMTP id 648671CC0AF; Mon, 26 Nov 2007 13:44:40 +0100 (CET) Received: by tirith.brixandersen.dk (Postfix, from userid 1001) id 7115611436; Mon, 26 Nov 2007 13:44:39 +0100 (CET) Date: Mon, 26 Nov 2007 13:44:39 +0100 From: Henrik Brix Andersen To: Nikolay Pavlov Message-ID: <20071126124438.GA77230@tirith.brixandersen.dk> Mail-Followup-To: Nikolay Pavlov , freebsd-arch@freebsd.org, cnst@freebsd.org, arch@freebsd.org, rwatson@freebsd.org, Alexander Leidinger , imp@freebsd.org References: <20071109124421.3c1901b1@deskjail> <200711261434.45765.qpadla@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZPt4rx8FFjLCG7dd" Content-Disposition: inline In-Reply-To: <200711261434.45765.qpadla@gmail.com> X-PGP-Key: http://www.brixandersen.dk/files/HenrikBrixAndersen.asc User-Agent: Mutt/1.5.16 (2007-06-09) Cc: cnst@freebsd.org, arch@freebsd.org, rwatson@freebsd.org, freebsd-arch@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 List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2007 13:02:20 -0000 --ZPt4rx8FFjLCG7dd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 26, 2007 at 02:34:40PM +0200, Nikolay Pavlov wrote: > Just want to mention that Linux lm-sensors 3.0.0 was released today. > A few notes that could be interesting for us: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Quote =3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > * It is now a user-space-only package, it no longer contains kernel > drivers. > * The i2c tools have been moved to a separate package (surprisingly > named i2c-tools). > * libsensors' internal version was bumped to 4.0.0, as it has a > completely new API we had to increase the .so version. This new > library contains no chip-specific knowledge, it assumes that hardware > monitoring drivers follow the standard sysfs interface. A very nice > benefit of this is that the size of the library has been divided by > 4 (down from 222 kB to 55 kB on i386). > * Some kernel drivers still don't implement the standard interface > for alarms, so alarm flags won't show. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Quote =3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >=20 > So as you can see it's fully userspace non chip-specific library, based o= n=20 > sysfs interface.=20 And it has been for quite a while, unless you compiled it on an old Linux kernel (e.g. 2.4.x), which didn't have the required drivers. Brix --=20 Henrik Brix Andersen --ZPt4rx8FFjLCG7dd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: GnuPG signed iD8DBQFHSr+2v+Q4flTiePgRAk5rAKCSlHwSVTLPO9xFCL+g/zqhWZw6hwCgum1M +uLeNGb10lGBpLrTpiR9TKA= =1g2o -----END PGP SIGNATURE----- --ZPt4rx8FFjLCG7dd-- From owner-freebsd-arch@FreeBSD.ORG Mon Nov 26 14:00: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 4E3D716A419; Mon, 26 Nov 2007 14:00:42 +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 B78B813C4EF; Mon, 26 Nov 2007 14:00:41 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A54FD6.dip.t-dialin.net [84.165.79.214]) by redbull.bpaserver.net (Postfix) with ESMTP id 72C0A2E4DD; Mon, 26 Nov 2007 14:33:23 +0100 (CET) Received: from webmail.leidinger.net (webmail.Leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id CBC3976A14; Mon, 26 Nov 2007 14:33:19 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1196083999; bh=mSTnr/yrDIBo6NsZ4JVQFx2nqK0azcmR/ Ac9QBhVY80=; h=Message-ID:X-Priority:Date:From:To:Cc:Subject: References:In-Reply-To:MIME-Version:Content-Type: Content-Disposition:Content-Transfer-Encoding:User-Agent; b=MyOMQW ESizI+6uFjW/7YLbFcg+PGZwxCjCYODdPKh2W+uEuNj48qnghTCqi/7ZNOpysQ5r7dC 88Fxug4Bi9rg84is37jDdx7vJvx8GcLLKRTsx8W2rhTyLbgUCQ0mBt2aXdLlCPALKx6 oTtbQYZo7ostgEcVk+/Rs21rDjstlWHR0cJCDSkAISXaLrT8czIIrWntisiZVsQSdsf sYTVW3ULmZpxscOaHhwqH5AwCZcljX01qe9A2bFHLTYC0+ftbbfUwnjmCG9r0X9kh9e KejuHXkcNj6EfVvaYAoHdT24DtRJp04rl1YM6mHTJzMTarfKiWvPjXGnXUpNDzrsH8I Q== Received: (from www@localhost) by webmail.leidinger.net (8.14.1/8.13.8/Submit) id lAQDXJOX022458; Mon, 26 Nov 2007 14:33:19 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Mon, 26 Nov 2007 14:33:19 +0100 Message-ID: <20071126143319.x9e9cezeo0ocso8k@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Mon, 26 Nov 2007 14:33:19 +0100 From: Alexander Leidinger To: Henrik Brix Andersen References: <20071109124421.3c1901b1@deskjail> <200711261434.45765.qpadla@gmail.com> <20071126124438.GA77230@tirith.brixandersen.dk> In-Reply-To: <20071126124438.GA77230@tirith.brixandersen.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.4) / FreeBSD-7.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=2.496, required 6, BAYES_20 1.00, DKIM_SIGNED 0.00, DKIM_VERIFIED -0.00, MIME_QP_LONG_LINE 1.40, RDNS_DYNAMIC 0.10) X-BPAnet-MailScanner-SpamScore: ss X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: cnst@FreeBSD.org, arch@FreeBSD.org, Nikolay Pavlov , 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: Mon, 26 Nov 2007 14:00:42 -0000 Quoting Henrik Brix Andersen (from Mon, 26 Nov 2007 =20 13:44:39 +0100): > On Mon, Nov 26, 2007 at 02:34:40PM +0200, Nikolay Pavlov wrote: >> Just want to mention that Linux lm-sensors 3.0.0 was released today. >> A few notes that could be interesting for us: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Quote =3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >> * It is now a user-space-only package, it no longer contains kernel >> drivers. >> * The i2c tools have been moved to a separate package (surprisingly >> named i2c-tools). >> * libsensors' internal version was bumped to 4.0.0, as it has a >> completely new API we had to increase the .so version. This new >> library contains no chip-specific knowledge, it assumes that hardware >> monitoring drivers follow the standard sysfs interface. A very nice >> benefit of this is that the size of the library has been divided by >> 4 (down from 222 kB to 55 kB on i386). >> * Some kernel drivers still don't implement the standard interface >> for alarms, so alarm flags won't show. >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Quote =3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >> >> So as you can see it's fully userspace non chip-specific library, based o= n >> sysfs interface. > > And it has been for quite a while, unless you compiled it on an old > Linux kernel (e.g. 2.4.x), which didn't have the required drivers. You are talking mostly about the userland part (the lib) which we =20 haven't discussed in this thread. What we discuss in this thread is the kernel<->userland interface. You =20 wrote that Linux uses sysfs as the kernel<->userland interface. Poul =20 proposes the /dev/sensors special file (not directory) as the =20 kernel<->userland interface, and I propose sysctl as the =20 kernel<->userland interface. Bye, Alexander. --=20 Joe's sister puts spaghetti in her shoes! http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 From owner-freebsd-arch@FreeBSD.ORG Mon Nov 26 14:00:42 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E3D716A419; Mon, 26 Nov 2007 14:00:42 +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 B78B813C4EF; Mon, 26 Nov 2007 14:00:41 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A54FD6.dip.t-dialin.net [84.165.79.214]) by redbull.bpaserver.net (Postfix) with ESMTP id 72C0A2E4DD; Mon, 26 Nov 2007 14:33:23 +0100 (CET) Received: from webmail.leidinger.net (webmail.Leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id CBC3976A14; Mon, 26 Nov 2007 14:33:19 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1196083999; bh=mSTnr/yrDIBo6NsZ4JVQFx2nqK0azcmR/ Ac9QBhVY80=; h=Message-ID:X-Priority:Date:From:To:Cc:Subject: References:In-Reply-To:MIME-Version:Content-Type: Content-Disposition:Content-Transfer-Encoding:User-Agent; b=MyOMQW ESizI+6uFjW/7YLbFcg+PGZwxCjCYODdPKh2W+uEuNj48qnghTCqi/7ZNOpysQ5r7dC 88Fxug4Bi9rg84is37jDdx7vJvx8GcLLKRTsx8W2rhTyLbgUCQ0mBt2aXdLlCPALKx6 oTtbQYZo7ostgEcVk+/Rs21rDjstlWHR0cJCDSkAISXaLrT8czIIrWntisiZVsQSdsf sYTVW3ULmZpxscOaHhwqH5AwCZcljX01qe9A2bFHLTYC0+ftbbfUwnjmCG9r0X9kh9e KejuHXkcNj6EfVvaYAoHdT24DtRJp04rl1YM6mHTJzMTarfKiWvPjXGnXUpNDzrsH8I Q== Received: (from www@localhost) by webmail.leidinger.net (8.14.1/8.13.8/Submit) id lAQDXJOX022458; Mon, 26 Nov 2007 14:33:19 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Mon, 26 Nov 2007 14:33:19 +0100 Message-ID: <20071126143319.x9e9cezeo0ocso8k@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Mon, 26 Nov 2007 14:33:19 +0100 From: Alexander Leidinger To: Henrik Brix Andersen References: <20071109124421.3c1901b1@deskjail> <200711261434.45765.qpadla@gmail.com> <20071126124438.GA77230@tirith.brixandersen.dk> In-Reply-To: <20071126124438.GA77230@tirith.brixandersen.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.4) / FreeBSD-7.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=2.496, required 6, BAYES_20 1.00, DKIM_SIGNED 0.00, DKIM_VERIFIED -0.00, MIME_QP_LONG_LINE 1.40, RDNS_DYNAMIC 0.10) X-BPAnet-MailScanner-SpamScore: ss X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: cnst@FreeBSD.org, arch@FreeBSD.org, Nikolay Pavlov , 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: Mon, 26 Nov 2007 14:00:42 -0000 Quoting Henrik Brix Andersen (from Mon, 26 Nov 2007 =20 13:44:39 +0100): > On Mon, Nov 26, 2007 at 02:34:40PM +0200, Nikolay Pavlov wrote: >> Just want to mention that Linux lm-sensors 3.0.0 was released today. >> A few notes that could be interesting for us: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Quote =3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >> * It is now a user-space-only package, it no longer contains kernel >> drivers. >> * The i2c tools have been moved to a separate package (surprisingly >> named i2c-tools). >> * libsensors' internal version was bumped to 4.0.0, as it has a >> completely new API we had to increase the .so version. This new >> library contains no chip-specific knowledge, it assumes that hardware >> monitoring drivers follow the standard sysfs interface. A very nice >> benefit of this is that the size of the library has been divided by >> 4 (down from 222 kB to 55 kB on i386). >> * Some kernel drivers still don't implement the standard interface >> for alarms, so alarm flags won't show. >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Quote =3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >> >> So as you can see it's fully userspace non chip-specific library, based o= n >> sysfs interface. > > And it has been for quite a while, unless you compiled it on an old > Linux kernel (e.g. 2.4.x), which didn't have the required drivers. You are talking mostly about the userland part (the lib) which we =20 haven't discussed in this thread. What we discuss in this thread is the kernel<->userland interface. You =20 wrote that Linux uses sysfs as the kernel<->userland interface. Poul =20 proposes the /dev/sensors special file (not directory) as the =20 kernel<->userland interface, and I propose sysctl as the =20 kernel<->userland interface. Bye, Alexander. --=20 Joe's sister puts spaghetti in her shoes! http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 From owner-freebsd-arch@FreeBSD.ORG Mon Nov 26 17:56:25 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C67BA16A46B for ; Mon, 26 Nov 2007 17:56:25 +0000 (UTC) (envelope-from qpadla@gmail.com) Received: from hu-out-0506.google.com (hu-out-0506.google.com [72.14.214.236]) by mx1.freebsd.org (Postfix) with ESMTP id 49BA213C447 for ; Mon, 26 Nov 2007 17:56:24 +0000 (UTC) (envelope-from qpadla@gmail.com) Received: by hu-out-0506.google.com with SMTP id 28so604351hub for ; Mon, 26 Nov 2007 09:56:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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=BEQGRTArIuqVVHmflLMC9ezdeojUX9nIs5CCgB4g2Wc=; b=E0tKeM5AiEkhq8vLEcPRGT7uzpNDrnDhb9oqAZw4d0NKiliIXrrwracdF2BRnBEkrYn0p5NbZhmTnJpWizfBnAP4nTPMnv8IJxXrpehHfq34kuvI1l1v/4T0c0UWXlHO+a031Nd5iT4At7THzcfoeYssJjMmksDabK1ljhHD8Ic= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; 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=w8Rv15edDM6h7WiVxhdVWL5F/srmLtGUuj4xJrOz5kD646CWWOi/1TxF0sC8A6zECIblY+VXsPRv4VwUeucNVGj21sGtOSoK4ltUBTolMrTMm/qpX2J+3ilRj1dDjFs3wV1U0WsTC3QlbcDTEwl3TKvOmI5oEPUMPs9QMnPhxo0= Received: by 10.82.184.2 with SMTP id h2mr7958833buf.1196099782852; Mon, 26 Nov 2007 09:56:22 -0800 (PST) Received: from orion ( [89.162.141.1]) by mx.google.com with ESMTPS id w5sm4404151mue.2007.11.26.09.56.16 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 26 Nov 2007 09:56:17 -0800 (PST) From: Nikolay Pavlov To: Alexander Leidinger Date: Mon, 26 Nov 2007 19:56:11 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <20071109124421.3c1901b1@deskjail> <20071126124438.GA77230@tirith.brixandersen.dk> <20071126143319.x9e9cezeo0ocso8k@webmail.leidinger.net> In-Reply-To: <20071126143319.x9e9cezeo0ocso8k@webmail.leidinger.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1264148.Zaef18taMb"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200711261956.15268.qpadla@gmail.com> Cc: cnst@freebsd.org, arch@freebsd.org, rwatson@freebsd.org, Henrik Brix Andersen , 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: Mon, 26 Nov 2007 17:56:25 -0000 --nextPart1264148.Zaef18taMb Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 26 November 2007 15:33:19 Alexander Leidinger wrote: > What we discuss in this thread is the kernel<->userland interface. You = =C2=A0 > wrote that Linux uses sysfs as the kernel<->userland interface. Poul =C2= =A0 > proposes the /dev/sensors special file (not directory) as the =C2=A0 > kernel<->userland interface, and I propose sysctl as the =C2=A0 > kernel<->userland interface. This is file descriptor based interface if i am not mistaken. But it uses=20 natural MIB-like directory structure. Isn't this is a compromise?=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 --nextPart1264148.Zaef18taMb 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) iD8DBQBHSwi//2R6KvEYGaIRAo3zAKDgs1h9RLnV3Oax77XYqfcBn3XzdACgx+tE 2FTrt4OIR620GL5O3yQRhLQ= =rLAZ -----END PGP SIGNATURE----- --nextPart1264148.Zaef18taMb-- From owner-freebsd-arch@FreeBSD.ORG Mon Nov 26 17:56: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 E2C7F16A419 for ; Mon, 26 Nov 2007 17:56:26 +0000 (UTC) (envelope-from qpadla@gmail.com) Received: from hu-out-0506.google.com (hu-out-0506.google.com [72.14.214.231]) by mx1.freebsd.org (Postfix) with ESMTP id 6434B13C455 for ; Mon, 26 Nov 2007 17:56:25 +0000 (UTC) (envelope-from qpadla@gmail.com) Received: by hu-out-0506.google.com with SMTP id 28so604355hub for ; Mon, 26 Nov 2007 09:56:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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=BEQGRTArIuqVVHmflLMC9ezdeojUX9nIs5CCgB4g2Wc=; b=E0tKeM5AiEkhq8vLEcPRGT7uzpNDrnDhb9oqAZw4d0NKiliIXrrwracdF2BRnBEkrYn0p5NbZhmTnJpWizfBnAP4nTPMnv8IJxXrpehHfq34kuvI1l1v/4T0c0UWXlHO+a031Nd5iT4At7THzcfoeYssJjMmksDabK1ljhHD8Ic= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; 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=w8Rv15edDM6h7WiVxhdVWL5F/srmLtGUuj4xJrOz5kD646CWWOi/1TxF0sC8A6zECIblY+VXsPRv4VwUeucNVGj21sGtOSoK4ltUBTolMrTMm/qpX2J+3ilRj1dDjFs3wV1U0WsTC3QlbcDTEwl3TKvOmI5oEPUMPs9QMnPhxo0= Received: by 10.82.184.2 with SMTP id h2mr7958833buf.1196099782852; Mon, 26 Nov 2007 09:56:22 -0800 (PST) Received: from orion ( [89.162.141.1]) by mx.google.com with ESMTPS id w5sm4404151mue.2007.11.26.09.56.16 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 26 Nov 2007 09:56:17 -0800 (PST) From: Nikolay Pavlov To: Alexander Leidinger Date: Mon, 26 Nov 2007 19:56:11 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <20071109124421.3c1901b1@deskjail> <20071126124438.GA77230@tirith.brixandersen.dk> <20071126143319.x9e9cezeo0ocso8k@webmail.leidinger.net> In-Reply-To: <20071126143319.x9e9cezeo0ocso8k@webmail.leidinger.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1264148.Zaef18taMb"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200711261956.15268.qpadla@gmail.com> Cc: cnst@freebsd.org, arch@freebsd.org, rwatson@freebsd.org, Henrik Brix Andersen , 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: Mon, 26 Nov 2007 17:56:27 -0000 --nextPart1264148.Zaef18taMb Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 26 November 2007 15:33:19 Alexander Leidinger wrote: > What we discuss in this thread is the kernel<->userland interface. You = =C2=A0 > wrote that Linux uses sysfs as the kernel<->userland interface. Poul =C2= =A0 > proposes the /dev/sensors special file (not directory) as the =C2=A0 > kernel<->userland interface, and I propose sysctl as the =C2=A0 > kernel<->userland interface. This is file descriptor based interface if i am not mistaken. But it uses=20 natural MIB-like directory structure. Isn't this is a compromise?=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 --nextPart1264148.Zaef18taMb 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) iD8DBQBHSwi//2R6KvEYGaIRAo3zAKDgs1h9RLnV3Oax77XYqfcBn3XzdACgx+tE 2FTrt4OIR620GL5O3yQRhLQ= =rLAZ -----END PGP SIGNATURE----- --nextPart1264148.Zaef18taMb-- From owner-freebsd-arch@FreeBSD.ORG Tue Nov 27 15:36: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 B435E16A420; Tue, 27 Nov 2007 15:36:16 +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 297FC13C46B; Tue, 27 Nov 2007 15:36:16 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A54D2C.dip.t-dialin.net [84.165.77.44]) by redbull.bpaserver.net (Postfix) with ESMTP id 716482E2A4; Tue, 27 Nov 2007 16:35:35 +0100 (CET) Received: from webmail.leidinger.net (webmail.Leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id E4CD3778DF; Tue, 27 Nov 2007 16:35:32 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1196177733; bh=ycccLfr3iMC5ZwKGVDW4za0FriAc6I2yJ KZThIOTf90=; h=Message-ID:X-Priority:Date:From:To:Cc:Subject: References:In-Reply-To:MIME-Version:Content-Type: Content-Disposition:Content-Transfer-Encoding:User-Agent; b=evzAnS Oe3TUtIwhFRTS8MQOQP3/rHl41PEQ8yU4U7CbyDe8Dg0rQyCtmvWxatCpBY799QkJBm fUDikhFwg/OUGCimJtukyysjA6gQAvxmWIR0T7J0enNmbSv667aeWJfzPyeFun6fVKh IkLQN9qTnYrM90HZa7PlORUYvUNc2mBSeLz5vqvG0OlyyMXg2cWE7DHV2Wjxyc06ycf Pga/Ore71VhfJVjk8T4LJONtqK/KU+q8hd627vKnBW6g6G0U1JrjFTKU/XQdjFDgdvf MqAvQ5DcoNfBw4CAWgMD4gkqR7Yb4OIx/A6zNL0rDXJQFNfDORQS8CPbgCK/BKd8zYA g== Received: (from www@localhost) by webmail.leidinger.net (8.14.1/8.13.8/Submit) id lARFZWC7045318; Tue, 27 Nov 2007 16:35:32 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Tue, 27 Nov 2007 16:35:32 +0100 Message-ID: <20071127163532.a7xrcya7fo0cg8ws@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Tue, 27 Nov 2007 16:35:32 +0100 From: Alexander Leidinger To: qpadla@gmail.com References: <20071109124421.3c1901b1@deskjail> <20071126124438.GA77230@tirith.brixandersen.dk> <20071126143319.x9e9cezeo0ocso8k@webmail.leidinger.net> <200711261956.15268.qpadla@gmail.com> In-Reply-To: <200711261956.15268.qpadla@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.4) / FreeBSD-7.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-14.9, required 6, BAYES_00 -15.00, DKIM_SIGNED 0.00, DKIM_VERIFIED -0.00, RDNS_DYNAMIC 0.10) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: cnst@freebsd.org, arch@freebsd.org, rwatson@freebsd.org, Henrik Brix Andersen , 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: Tue, 27 Nov 2007 15:36:16 -0000 Quoting Nikolay Pavlov (from Mon, 26 Nov 2007 =20 19:56:11 +0200): > On Monday 26 November 2007 15:33:19 Alexander Leidinger wrote: >> What we discuss in this thread is the kernel<->userland interface. You = =EF=BF=BD >> wrote that Linux uses sysfs as the kernel<->userland interface. Poul =EF= =BF=BD >> proposes the /dev/sensors special file (not directory) as the =EF=BF=BD >> kernel<->userland interface, and I propose sysctl as the =EF=BF=BD >> kernel<->userland interface. > > This is file descriptor based interface if i am not mistaken. But it uses > natural MIB-like directory structure. Isn't this is a compromise? It would be a compromise from the MIB point of view, but not from the =20 complexity point of view. For a directory structure you need to write =20 a pseudo-fs. This means everything has to go through the several =20 layers (vfs, pseudo-fs, ...). With sysctl you don't need to write that =20 much complex code, as you already have something which handles the MIB =20 thing and you don't go through that much complex layers. =3D> less code, =20 less to debug, less complexity. The discussion in this thread is, that =20 I think a FD based approach (and the additional things Poul proposes =20 to do in the kernel) is overly complex, it can be done in userland =20 (the additional things he proposes t put into the kernel) with =20 existing interfaces (sysctl). Bye, Alexander. --=20 If you sit down at a poker game and don't see a sucker, get up. You're the sucker. 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 Tue Nov 27 15:36:16 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 B435E16A420; Tue, 27 Nov 2007 15:36:16 +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 297FC13C46B; Tue, 27 Nov 2007 15:36:16 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A54D2C.dip.t-dialin.net [84.165.77.44]) by redbull.bpaserver.net (Postfix) with ESMTP id 716482E2A4; Tue, 27 Nov 2007 16:35:35 +0100 (CET) Received: from webmail.leidinger.net (webmail.Leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id E4CD3778DF; Tue, 27 Nov 2007 16:35:32 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1196177733; bh=ycccLfr3iMC5ZwKGVDW4za0FriAc6I2yJ KZThIOTf90=; h=Message-ID:X-Priority:Date:From:To:Cc:Subject: References:In-Reply-To:MIME-Version:Content-Type: Content-Disposition:Content-Transfer-Encoding:User-Agent; b=evzAnS Oe3TUtIwhFRTS8MQOQP3/rHl41PEQ8yU4U7CbyDe8Dg0rQyCtmvWxatCpBY799QkJBm fUDikhFwg/OUGCimJtukyysjA6gQAvxmWIR0T7J0enNmbSv667aeWJfzPyeFun6fVKh IkLQN9qTnYrM90HZa7PlORUYvUNc2mBSeLz5vqvG0OlyyMXg2cWE7DHV2Wjxyc06ycf Pga/Ore71VhfJVjk8T4LJONtqK/KU+q8hd627vKnBW6g6G0U1JrjFTKU/XQdjFDgdvf MqAvQ5DcoNfBw4CAWgMD4gkqR7Yb4OIx/A6zNL0rDXJQFNfDORQS8CPbgCK/BKd8zYA g== Received: (from www@localhost) by webmail.leidinger.net (8.14.1/8.13.8/Submit) id lARFZWC7045318; Tue, 27 Nov 2007 16:35:32 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Tue, 27 Nov 2007 16:35:32 +0100 Message-ID: <20071127163532.a7xrcya7fo0cg8ws@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Tue, 27 Nov 2007 16:35:32 +0100 From: Alexander Leidinger To: qpadla@gmail.com References: <20071109124421.3c1901b1@deskjail> <20071126124438.GA77230@tirith.brixandersen.dk> <20071126143319.x9e9cezeo0ocso8k@webmail.leidinger.net> <200711261956.15268.qpadla@gmail.com> In-Reply-To: <200711261956.15268.qpadla@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.4) / FreeBSD-7.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-14.9, required 6, BAYES_00 -15.00, DKIM_SIGNED 0.00, DKIM_VERIFIED -0.00, RDNS_DYNAMIC 0.10) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: cnst@freebsd.org, arch@freebsd.org, rwatson@freebsd.org, Henrik Brix Andersen , 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: Tue, 27 Nov 2007 15:36:16 -0000 Quoting Nikolay Pavlov (from Mon, 26 Nov 2007 =20 19:56:11 +0200): > On Monday 26 November 2007 15:33:19 Alexander Leidinger wrote: >> What we discuss in this thread is the kernel<->userland interface. You = =EF=BF=BD >> wrote that Linux uses sysfs as the kernel<->userland interface. Poul =EF= =BF=BD >> proposes the /dev/sensors special file (not directory) as the =EF=BF=BD >> kernel<->userland interface, and I propose sysctl as the =EF=BF=BD >> kernel<->userland interface. > > This is file descriptor based interface if i am not mistaken. But it uses > natural MIB-like directory structure. Isn't this is a compromise? It would be a compromise from the MIB point of view, but not from the =20 complexity point of view. For a directory structure you need to write =20 a pseudo-fs. This means everything has to go through the several =20 layers (vfs, pseudo-fs, ...). With sysctl you don't need to write that =20 much complex code, as you already have something which handles the MIB =20 thing and you don't go through that much complex layers. =3D> less code, =20 less to debug, less complexity. The discussion in this thread is, that =20 I think a FD based approach (and the additional things Poul proposes =20 to do in the kernel) is overly complex, it can be done in userland =20 (the additional things he proposes t put into the kernel) with =20 existing interfaces (sysctl). Bye, Alexander. --=20 If you sit down at a poker game and don't see a sucker, get up. You're the sucker. 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 Tue Nov 27 17:04:38 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 2C39916A41B for ; Tue, 27 Nov 2007 17:04:38 +0000 (UTC) (envelope-from mahsantp@gmail.com) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.233]) by mx1.freebsd.org (Postfix) with ESMTP id D5D3913C461 for ; Tue, 27 Nov 2007 17:04:37 +0000 (UTC) (envelope-from mahsantp@gmail.com) Received: by qb-out-0506.google.com with SMTP id a10so945781qbd for ; Tue, 27 Nov 2007 09:04:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:to:subject:date:mime-version:x-mailer:x-mimeole:thread-index:content-type:content-transfer-encoding:from; bh=Ur9bUJLxOjjqhRybSSjVeS2wfbJ9QRw2OZw825aKNRk=; b=a1PZQP1RGZLTqQ5QoBM2YUhC+7USm3uP4on6DE0XGl63GB0aU5FcPb6zFX1/lgBIvrvk4XZTxaLcR4WxoZKgAHzBzXTO62DLB7R+Co4iUJu5ChgdRzacTxvjbVgrjA0WhpMWT1KgoQMhTY7oYAKBfy/J/wUYchS2tcCRYQ5m4DI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:to:subject:date:mime-version:x-mailer:x-mimeole:thread-index:content-type:content-transfer-encoding:from; b=Uc8dF3GNGGJDyfZXiuTmq4VLXalohb2Koeoa+YP+3AuEF/BGjrjeMD6+ut1zF8ZGXJVIWI1hebZLR1QNiYTdWOWPGAzhqNakRnClXqiOCsaQlI57BcOR1f/3g0dJ//elOI5ql9v8ELNykVdFCOof8zHhCe2MlNImXHqxS9Ltma4= Received: by 10.67.29.20 with SMTP id g20mr1253662ugj.1196182118237; Tue, 27 Nov 2007 08:48:38 -0800 (PST) Received: from ?82.60.53.13? ( [82.60.53.13]) by mx.google.com with ESMTPS id c1sm2352206ugf.2007.11.27.08.48.31 (version=SSLv3 cipher=OTHER); Tue, 27 Nov 2007 08:48:37 -0800 (PST) Message-ID: To: Date: Tue, 27 Nov 2007 16:37:34 +0000 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: 5FtAfemIVNo45Ihluk4cxXN1RjVgIqs3nnLN Content-Type: text/plain; charset="Windows-1251" Content-Transfer-Encoding: 7bit From: still Subject: Men's pills at superior prices! dolmen 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, 27 Nov 2007 17:04:38 -0000 Everything a real man would ever need Enjoy secure ordering, lowest possible prices and almost instant shipment. PLANTDROP COM codification From owner-freebsd-arch@FreeBSD.ORG Wed Nov 28 21:10: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 9A38416A41A for ; Wed, 28 Nov 2007 21:10:23 +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 3B62D13C465 for ; Wed, 28 Nov 2007 21:10:23 +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 lASLAMs5074964 for ; Wed, 28 Nov 2007 15:10:22 -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 lASLAM0g074963 for freebsd-arch@freebsd.org; Wed, 28 Nov 2007 15:10:22 -0600 (CST) (envelope-from brooks) Date: Wed, 28 Nov 2007 15:10:22 -0600 From: Brooks Davis To: freebsd-arch@freebsd.org Message-ID: <20071128211022.GA74762@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yrj/dFKFPuw6o+aM" Content-Disposition: inline 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]); Wed, 28 Nov 2007 15:10:22 -0600 (CST) Subject: RFC: libkse*.a in 7.0 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, 28 Nov 2007 21:10:23 -0000 --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable A number of people have proposed a direction in 8.0 that would remove support for the syscalls and kernel data structures required by libkse. Apparently this would enable significant simplification of portions of the kernel, but I have no deeply held personal opinion. The intent is that if that happens, alternate versions of the necessicary dynamic libraries will be supplied in updated compat#x packages. This will address most consumers. The one set of consumers that would not be addressed is those who have statically linked, threaded binaries using libkse. Kris and I realized that if we went that route, life would be significantly easier if it was difficult to create statically linked, binaries using libkse under FreeBSD 7.x. As a result I would like to commit and MFC the following patch which disables building and installing libkse*.a in the default case. This would mean that significant effort would be required to create a statically linked application that uses the KSE syscalls. I believe that removing libkse*.a has little downside and leaves the way open for either removing or enhancing the KSE system and is the right thing to do. -- Brooks --- /home/brooks/working/freebsd/p4/freebsd/lib/libkse/Makefile 2007-10-29 = 10:43:55.000000000 -0500 +++ lib/libkse/Makefile 2007-11-20 20:39:22.000000000 -0600 @@ -10,12 +10,15 @@ =20 .include =20 -.if (${DEFAULT_THREAD_LIB} =3D=3D "libkse" || ${MK_LIBTHR} =3D=3D "no") &&= \ - ${SHLIBDIR} =3D=3D "/usr/lib" +.if (${DEFAULT_THREAD_LIB} =3D=3D "libkse" || ${MK_LIBTHR} =3D=3D "no") +LIB=3Dkse +.if ${SHLIBDIR} =3D=3D "/usr/lib" SHLIBDIR=3D /lib .endif +.else +SHLIB=3Dkse +.endif =20 -LIB=3Dkse SHLIB_MAJOR=3D 3 CFLAGS+=3D-DPTHREAD_KERNEL CFLAGS+=3D-I${.CURDIR}/../libc/include -I${.CURDIR}/thread \ --- /home/brooks/working/freebsd/p4/freebsd/ObsoleteFiles.inc 2007-11-18 04= :16:28.000000000 -0600 +++ ObsoleteFiles.inc 2007-11-20 20:37:39.000000000 -0600 @@ -14,6 +14,12 @@ # The file is partitioned: OLD_FILES first, then OLD_LIBS and OLD_DIRS las= t. # =20 +# 200711XX: Disabled installing static versions of libkse by default +.if ${DEFAULT_THREAD_LIB} !=3D "libkse" && ${MK_LIBTHR} !=3D "no" +OLD_FILES+=3Dusr/lib/libkse.a +OLD_FILES+=3Dusr/lib/libkse_p.a +OLD_FILES+=3Dusr/lib/libkse_pic.a +.endif # 20071108: Removed very crunch OLDCARD support file OLD_FILES+=3Detc/defaults/pccard.conf # 20071104: Removed bsdlabel, fdisk and gpt from rescue on ia64. --yrj/dFKFPuw6o+aM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFHTdk9XY6L6fI4GtQRAp/kAKDUnMXL1A5WBpvjR67qFKco/OVy3wCfYEfy IJyQ8hDs72ADfzvPxIz3TGU= =qnCD -----END PGP SIGNATURE----- --yrj/dFKFPuw6o+aM-- From owner-freebsd-arch@FreeBSD.ORG Wed Nov 28 21:22:54 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 644C116A417 for ; Wed, 28 Nov 2007 21:22:54 +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 5D54913C43E for ; Wed, 28 Nov 2007 21:22:54 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 0BC4A1A4D82; Wed, 28 Nov 2007 13:22:54 -0800 (PST) Date: Wed, 28 Nov 2007 13:22:53 -0800 From: Alfred Perlstein To: Brooks Davis Message-ID: <20071128212253.GO71382@elvis.mu.org> References: <20071128211022.GA74762@lor.one-eyed-alien.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071128211022.GA74762@lor.one-eyed-alien.net> User-Agent: Mutt/1.4.2.3i Cc: freebsd-arch@freebsd.org Subject: Re: RFC: libkse*.a in 7.0 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, 28 Nov 2007 21:22:54 -0000 I don't see the harm in this. If we do nuke it we will still not be able to run statics without some weird hooks to emulate it. * Brooks Davis [071128 13:10] wrote: > A number of people have proposed a direction in 8.0 that would remove > support for the syscalls and kernel data structures required by libkse. > Apparently this would enable significant simplification of portions of > the kernel, but I have no deeply held personal opinion. The intent is > that if that happens, alternate versions of the necessicary dynamic > libraries will be supplied in updated compat#x packages. This will > address most consumers. The one set of consumers that would not be > addressed is those who have statically linked, threaded binaries using > libkse. > > Kris and I realized that if we went that route, life would be > significantly easier if it was difficult to create statically linked, > binaries using libkse under FreeBSD 7.x. As a result I would like > to commit and MFC the following patch which disables building and > installing libkse*.a in the default case. This would mean that > significant effort would be required to create a statically linked > application that uses the KSE syscalls. > > I believe that removing libkse*.a has little downside and leaves the way > open for either removing or enhancing the KSE system and is the right > thing to do. > > -- Brooks > > --- /home/brooks/working/freebsd/p4/freebsd/lib/libkse/Makefile 2007-10-29 10:43:55.000000000 -0500 > +++ lib/libkse/Makefile 2007-11-20 20:39:22.000000000 -0600 > @@ -10,12 +10,15 @@ > > .include > > -.if (${DEFAULT_THREAD_LIB} == "libkse" || ${MK_LIBTHR} == "no") && \ > - ${SHLIBDIR} == "/usr/lib" > +.if (${DEFAULT_THREAD_LIB} == "libkse" || ${MK_LIBTHR} == "no") > +LIB=kse > +.if ${SHLIBDIR} == "/usr/lib" > SHLIBDIR= /lib > .endif > +.else > +SHLIB=kse > +.endif > > -LIB=kse > SHLIB_MAJOR= 3 > CFLAGS+=-DPTHREAD_KERNEL > CFLAGS+=-I${.CURDIR}/../libc/include -I${.CURDIR}/thread \ > --- /home/brooks/working/freebsd/p4/freebsd/ObsoleteFiles.inc 2007-11-18 04:16:28.000000000 -0600 > +++ ObsoleteFiles.inc 2007-11-20 20:37:39.000000000 -0600 > @@ -14,6 +14,12 @@ > # The file is partitioned: OLD_FILES first, then OLD_LIBS and OLD_DIRS last. > # > > +# 200711XX: Disabled installing static versions of libkse by default > +.if ${DEFAULT_THREAD_LIB} != "libkse" && ${MK_LIBTHR} != "no" > +OLD_FILES+=usr/lib/libkse.a > +OLD_FILES+=usr/lib/libkse_p.a > +OLD_FILES+=usr/lib/libkse_pic.a > +.endif > # 20071108: Removed very crunch OLDCARD support file > OLD_FILES+=etc/defaults/pccard.conf > # 20071104: Removed bsdlabel, fdisk and gpt from rescue on ia64. -- - Alfred Perlstein From owner-freebsd-arch@FreeBSD.ORG Wed Nov 28 21:37: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 004B116A475 for ; Wed, 28 Nov 2007 21:37:47 +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 A134513C4EE for ; Wed, 28 Nov 2007 21:37: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 E624A17106; Wed, 28 Nov 2007 21:37:45 +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 lASLbjUo001390; Wed, 28 Nov 2007 21:37:45 GMT (envelope-from phk@critter.freebsd.dk) To: Brooks Davis From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 28 Nov 2007 15:10:22 CST." <20071128211022.GA74762@lor.one-eyed-alien.net> Date: Wed, 28 Nov 2007 21:37:45 +0000 Message-ID: <1389.1196285865@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-arch@freebsd.org Subject: Re: RFC: libkse*.a in 7.0 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, 28 Nov 2007 21:37:48 -0000 In message <20071128211022.GA74762@lor.one-eyed-alien.net>, Brooks Davis writes : >The one set of consumers that would not be >addressed is those who have statically linked, threaded binaries using >libkse. I agree that we should make it hard to link such. But I also think that if that is what keeps people from upgrading from N.x to (N+1).x, then they have much bigger problems on their hands and are probably better served by staying on N.x >I believe that removing libkse*.a has little downside and leaves the way >open for either removing or enhancing the KSE system and is the right >thing to do. Fully agree. -- 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 Wed Nov 28 21:42: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 EC05416A417; Wed, 28 Nov 2007 21:42:17 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id CF51513C448; Wed, 28 Nov 2007 21:42:17 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 5FCA047157; Wed, 28 Nov 2007 16:46:13 -0500 (EST) Date: Wed, 28 Nov 2007 21:42:10 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Brooks Davis In-Reply-To: <20071128211022.GA74762@lor.one-eyed-alien.net> Message-ID: <20071128213947.Q7555@fledge.watson.org> References: <20071128211022.GA74762@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-arch@freebsd.org Subject: Re: RFC: libkse*.a in 7.0 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, 28 Nov 2007 21:42:18 -0000 On Wed, 28 Nov 2007, Brooks Davis wrote: > A number of people have proposed a direction in 8.0 that would remove > support for the syscalls and kernel data structures required by libkse. > Apparently this would enable significant simplification of portions of the > kernel, but I have no deeply held personal opinion. The intent is that if > that happens, alternate versions of the necessicary dynamic libraries will > be supplied in updated compat#x packages. This will address most consumers. > The one set of consumers that would not be addressed is those who have > statically linked, threaded binaries using libkse. It's worth noting that some other mainstream operating systems work hard to disallow static linking for precisely this sort of reason -- when I last checked, Mac OS X had only one statically linked binary, init, and it may well be that launchd is dynamically linked. This is part of a very explicit policy that the defined ABI for applications is *not* the system call layer, but rather, the library interfaces, which gives greater flexibility to modify the system call interface as needed. Robert N M Watson Computer Laboratory University of Cambridge > > Kris and I realized that if we went that route, life would be > significantly easier if it was difficult to create statically linked, > binaries using libkse under FreeBSD 7.x. As a result I would like > to commit and MFC the following patch which disables building and > installing libkse*.a in the default case. This would mean that > significant effort would be required to create a statically linked > application that uses the KSE syscalls. > > I believe that removing libkse*.a has little downside and leaves the way > open for either removing or enhancing the KSE system and is the right > thing to do. > > -- Brooks > > --- /home/brooks/working/freebsd/p4/freebsd/lib/libkse/Makefile 2007-10-29 10:43:55.000000000 -0500 > +++ lib/libkse/Makefile 2007-11-20 20:39:22.000000000 -0600 > @@ -10,12 +10,15 @@ > > .include > > -.if (${DEFAULT_THREAD_LIB} == "libkse" || ${MK_LIBTHR} == "no") && \ > - ${SHLIBDIR} == "/usr/lib" > +.if (${DEFAULT_THREAD_LIB} == "libkse" || ${MK_LIBTHR} == "no") > +LIB=kse > +.if ${SHLIBDIR} == "/usr/lib" > SHLIBDIR= /lib > .endif > +.else > +SHLIB=kse > +.endif > > -LIB=kse > SHLIB_MAJOR= 3 > CFLAGS+=-DPTHREAD_KERNEL > CFLAGS+=-I${.CURDIR}/../libc/include -I${.CURDIR}/thread \ > --- /home/brooks/working/freebsd/p4/freebsd/ObsoleteFiles.inc 2007-11-18 04:16:28.000000000 -0600 > +++ ObsoleteFiles.inc 2007-11-20 20:37:39.000000000 -0600 > @@ -14,6 +14,12 @@ > # The file is partitioned: OLD_FILES first, then OLD_LIBS and OLD_DIRS last. > # > > +# 200711XX: Disabled installing static versions of libkse by default > +.if ${DEFAULT_THREAD_LIB} != "libkse" && ${MK_LIBTHR} != "no" > +OLD_FILES+=usr/lib/libkse.a > +OLD_FILES+=usr/lib/libkse_p.a > +OLD_FILES+=usr/lib/libkse_pic.a > +.endif > # 20071108: Removed very crunch OLDCARD support file > OLD_FILES+=etc/defaults/pccard.conf > # 20071104: Removed bsdlabel, fdisk and gpt from rescue on ia64. > From owner-freebsd-arch@FreeBSD.ORG Wed Nov 28 21:49:38 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 0C71216A46C for ; Wed, 28 Nov 2007 21:49:38 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outL.internet-mail-service.net (outL.internet-mail-service.net [216.240.47.235]) by mx1.freebsd.org (Postfix) with ESMTP id C116213C4D9 for ; Wed, 28 Nov 2007 21:49:37 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Wed, 28 Nov 2007 13:49:36 -0800 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 7D3F9126B0E; Wed, 28 Nov 2007 13:49:36 -0800 (PST) Message-ID: <474DE26F.4000303@elischer.org> Date: Wed, 28 Nov 2007 13:49:35 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Brooks Davis References: <20071128211022.GA74762@lor.one-eyed-alien.net> In-Reply-To: <20071128211022.GA74762@lor.one-eyed-alien.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: RFC: libkse*.a in 7.0 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, 28 Nov 2007 21:49:38 -0000 Brooks Davis wrote: > A number of people have proposed a direction in 8.0 that would remove > support for the syscalls and kernel data structures required by libkse. > Apparently this would enable significant simplification of portions of > the kernel, but I have no deeply held personal opinion. The intent is > that if that happens, alternate versions of the necessicary dynamic > libraries will be supplied in updated compat#x packages. This will > address most consumers. The one set of consumers that would not be > addressed is those who have statically linked, threaded binaries using > libkse. Actually the simplifications in the kernel are almost negigable. KSE support is almost totally contained within kern_kse.c at this time. When KSEG support was removed, most of the changes outside of htis file were removed.. the remaining changes not in that file could be moved to that file relatively easily. > > Kris and I realized that if we went that route, life would be > significantly easier if it was difficult to create statically linked, > binaries using libkse under FreeBSD 7.x. As a result I would like > to commit and MFC the following patch which disables building and > installing libkse*.a in the default case. This would mean that > significant effort would be required to create a statically linked > application that uses the KSE syscalls. > > I believe that removing libkse*.a has little downside and leaves the way > open for either removing or enhancing the KSE system and is the right > thing to do. If you wish.. however the performance downside of KSE is that we have not run schedgraph on it and looked at what happens, rather than it being against a wall of some sort.. the fact that it is slower than thr in most cases is because there is a bug that stops it from scheduling correctly. As I have not had the time or extreme burst of energy needed to find this bug it has not been found, but the fact that it rarely schedules threads onto > 1 cpu at a time is not inherrent in the design. From owner-freebsd-arch@FreeBSD.ORG Wed Nov 28 22:01:04 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 E0FB616A420 for ; Wed, 28 Nov 2007 22:01:04 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from galain.elvandar.org (galain.elvandar.org [217.148.169.56]) by mx1.freebsd.org (Postfix) with ESMTP id B6D7413C467 for ; Wed, 28 Nov 2007 22:01:04 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from evilcoder.xs4all.nl ([195.64.94.120] helo=elvandar.local) by galain.elvandar.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1IxUKl-0000rn-Fk for freebsd-arch@freebsd.org; Wed, 28 Nov 2007 22:20:39 +0100 Message-ID: <474DDBC2.3030704@FreeBSD.org> Date: Wed, 28 Nov 2007 22:21:06 +0100 From: Remko Lodder User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: freebsd-arch@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Removal of /etc/skel, your opinions please 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, 28 Nov 2007 22:01:05 -0000 Dear arch@ members, I would like to remove /etc/skel from the BSD.root.dist mtree file since it is no longer being used and I would like to remove unused items. I understood from a PR (46062) that there are no references to this directory any longer. There is a proposal to symlink this; but I dont want to keep this alive at all where possible.. Does anyone have objections to this change? If so, please let me know why you have these objections so that I can take them into account. Thanks in advance for your time! -- /"\ Best regards, | remko@FreeBSD.org \ / Remko Lodder | remko@EFnet X http://www.evilcoder.org/ | / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-arch@FreeBSD.ORG Wed Nov 28 22:05:46 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 6CE3E16A417; Wed, 28 Nov 2007 22:05:46 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 3933113C448; Wed, 28 Nov 2007 22:05:46 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.2/8.14.2/NETPLEX) with ESMTP id lASLs54M022686; Wed, 28 Nov 2007 16:54:05 -0500 (EST) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.0 (mail.netplex.net [204.213.176.10]); Wed, 28 Nov 2007 16:54:06 -0500 (EST) Date: Wed, 28 Nov 2007 16:54:05 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Robert Watson In-Reply-To: <20071128213947.Q7555@fledge.watson.org> Message-ID: References: <20071128211022.GA74762@lor.one-eyed-alien.net> <20071128213947.Q7555@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Brooks Davis , freebsd-arch@freebsd.org Subject: Re: RFC: libkse*.a in 7.0 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2007 22:05:46 -0000 On Wed, 28 Nov 2007, Robert Watson wrote: > > On Wed, 28 Nov 2007, Brooks Davis wrote: > >> A number of people have proposed a direction in 8.0 that would remove >> support for the syscalls and kernel data structures required by libkse. >> Apparently this would enable significant simplification of portions of the >> kernel, but I have no deeply held personal opinion. The intent is that if >> that happens, alternate versions of the necessicary dynamic libraries will >> be supplied in updated compat#x packages. This will address most >> consumers. The one set of consumers that would not be addressed is those >> who have statically linked, threaded binaries using libkse. > > It's worth noting that some other mainstream operating systems work hard to > disallow static linking for precisely this sort of reason -- when I last > checked, Mac OS X had only one statically linked binary, init, and it may > well be that launchd is dynamically linked. This is part of a very explicit > policy that the defined ABI for applications is *not* the system call layer, > but rather, the library interfaces, which gives greater flexibility to modify > the system call interface as needed. I argued for removing libc.a as well as lib.a a couple of years ago and was met with opposition, mostly because statically linked applications are faster. I think we should remove libthr.a, libkse.a and libc.a, so flame on! -- DE From owner-freebsd-arch@FreeBSD.ORG Wed Nov 28 22:06: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 6671D16A474; Wed, 28 Nov 2007 22:06:37 +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 544DD13C447; Wed, 28 Nov 2007 22:06:37 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 0BAD01A4D81; Wed, 28 Nov 2007 14:06:37 -0800 (PST) Date: Wed, 28 Nov 2007 14:06:36 -0800 From: Alfred Perlstein To: Daniel Eischen Message-ID: <20071128220636.GQ71382@elvis.mu.org> References: <20071128211022.GA74762@lor.one-eyed-alien.net> <20071128213947.Q7555@fledge.watson.org> 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: Brooks Davis , Robert Watson , freebsd-arch@freebsd.org Subject: Re: RFC: libkse*.a in 7.0 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, 28 Nov 2007 22:06:37 -0000 * Daniel Eischen [071128 14:05] wrote: > On Wed, 28 Nov 2007, Robert Watson wrote: > > > > >On Wed, 28 Nov 2007, Brooks Davis wrote: > > > >>A number of people have proposed a direction in 8.0 that would remove > >>support for the syscalls and kernel data structures required by libkse. > >>Apparently this would enable significant simplification of portions of > >>the kernel, but I have no deeply held personal opinion. The intent is > >>that if that happens, alternate versions of the necessicary dynamic > >>libraries will be supplied in updated compat#x packages. This will > >>address most consumers. The one set of consumers that would not be > >>addressed is those who have statically linked, threaded binaries using > >>libkse. > > > >It's worth noting that some other mainstream operating systems work hard > >to disallow static linking for precisely this sort of reason -- when I > >last checked, Mac OS X had only one statically linked binary, init, and it > >may well be that launchd is dynamically linked. This is part of a very > >explicit policy that the defined ABI for applications is *not* the system > >call layer, but rather, the library interfaces, which gives greater > >flexibility to modify the system call interface as needed. > > I argued for removing libc.a as well as lib.a a couple of > years ago and was met with opposition, mostly because statically > linked applications are faster. > > I think we should remove libthr.a, libkse.a and libc.a, so flame on! I agree, as long as someone can flip a switch and turn it back on for ISVs. -Alfred From owner-freebsd-arch@FreeBSD.ORG Wed Nov 28 22:09:04 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 4EE7416A421; Wed, 28 Nov 2007 22:09:04 +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 F423513C45D; Wed, 28 Nov 2007 22:09:03 +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 99E6C17104; Wed, 28 Nov 2007 22:09:02 +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 lASM929C001667; Wed, 28 Nov 2007 22:09:02 GMT (envelope-from phk@critter.freebsd.dk) To: Daniel Eischen From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 28 Nov 2007 16:54:05 EST." Date: Wed, 28 Nov 2007 22:09:02 +0000 Message-ID: <1666.1196287742@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Brooks Davis , Robert Watson , freebsd-arch@freebsd.org Subject: Re: RFC: libkse*.a in 7.0 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, 28 Nov 2007 22:09:04 -0000 In message , Daniel Eischen wr ites: >I think we should remove libthr.a, libkse.a and libc.a, so flame on! I used to disagree, based on arguments about embedded systems. I may be about to change my mind on this, but won't know for sure until I get my hands dirty with 7.x on embedded platforms. I would suggest we put this question on the agenda for 8.x -- 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 Wed Nov 28 22:11:32 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 A47CD16A421 for ; Wed, 28 Nov 2007 22:11:32 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 597D913C459 for ; Wed, 28 Nov 2007 22:11:32 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.1/8.14.1) with ESMTP id lASM7ftU092444 for ; Wed, 28 Nov 2007 15:07:41 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 28 Nov 2007 15:10:21 -0700 (MST) Message-Id: <20071128.151021.709401576.imp@bsdimp.com> To: arch@FreeBSD.org From: "M. Warner Losh" X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: Code review request: small optimization to localtime.c 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, 28 Nov 2007 22:11:32 -0000 Please find enclosed some small optimizations. I know they make a couple lines too long, I'll correct that before I commit. They make the time functions do less redundant locking. However, in many places we do the following: pthread_mutex_lock(); if (!is_set) { is_set = true; // do something } pthread_mutex_unlock(); This is wasteful. We get locks ALL the time for every time operation, when in fact we need it more rarely. If we can tolerate losing a race, we can eliminate the locking in all but the startup case and those threads racing the startup: if (!is_set) { pthread_mutex_lock(); if (!is_set) { is_set = true; // do something } pthread_mutex_unlock(); } here, we know that is_set only ever changes from false to true. If it is already true, there's nothing to do. If it is false, we may need to do something, so we lock, check to see if we really need to do it, etc. Can anybody see a flaw in this logic? Warner Index: localtime.c =================================================================== RCS file: /cache/ncvs/src/lib/libc/stdtime/localtime.c,v retrieving revision 1.41 diff -u -r1.41 localtime.c --- localtime.c 19 Jan 2007 01:16:35 -0000 1.41 +++ localtime.c 28 Nov 2007 21:59:59 -0000 @@ -1093,14 +1093,16 @@ struct tm *p_tm; if (__isthreaded != 0) { - _pthread_mutex_lock(&localtime_mutex); if (localtime_key < 0) { - if (_pthread_key_create(&localtime_key, free) < 0) { - _pthread_mutex_unlock(&localtime_mutex); - return(NULL); + _pthread_mutex_lock(&localtime_mutex); + if (localtime_key < 0) { + if (_pthread_key_create(&localtime_key, free) < 0) { + _pthread_mutex_unlock(&localtime_mutex); + return(NULL); + } } + _pthread_mutex_unlock(&localtime_mutex); } - _pthread_mutex_unlock(&localtime_mutex); p_tm = _pthread_getspecific(localtime_key); if (p_tm == NULL) { if ((p_tm = (struct tm *)malloc(sizeof(struct tm))) @@ -1146,16 +1148,18 @@ const long offset; struct tm * const tmp; { - _MUTEX_LOCK(&gmt_mutex); if (!gmt_is_set) { - gmt_is_set = TRUE; + _MUTEX_LOCK(&gmt_mutex); + if (!gmt_is_set) { + gmt_is_set = TRUE; #ifdef ALL_STATE - gmtptr = (struct state *) malloc(sizeof *gmtptr); - if (gmtptr != NULL) + gmtptr = (struct state *) malloc(sizeof *gmtptr); + if (gmtptr != NULL) #endif /* defined ALL_STATE */ - gmtload(gmtptr); + gmtload(gmtptr); + } + _MUTEX_UNLOCK(&gmt_mutex); } - _MUTEX_UNLOCK(&gmt_mutex); timesub(timep, offset, gmtptr, tmp); #ifdef TM_ZONE /* @@ -1187,14 +1191,16 @@ struct tm *p_tm; if (__isthreaded != 0) { - _pthread_mutex_lock(&gmtime_mutex); if (gmtime_key < 0) { - if (_pthread_key_create(&gmtime_key, free) < 0) { - _pthread_mutex_unlock(&gmtime_mutex); - return(NULL); + _pthread_mutex_lock(&gmtime_mutex); + if (gmtime_key < 0) { + if (_pthread_key_create(&gmtime_key, free) < 0) { + _pthread_mutex_unlock(&gmtime_mutex); + return(NULL); + } } + _pthread_mutex_unlock(&gmtime_mutex); } - _pthread_mutex_unlock(&gmtime_mutex); /* * Changed to follow POSIX.1 threads standard, which * is what BSD currently has. From owner-freebsd-arch@FreeBSD.ORG Wed Nov 28 22:15: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 6734B16A419; Wed, 28 Nov 2007 22:15:48 +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 6015813C469; Wed, 28 Nov 2007 22:15:48 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 400A01A4D7E; Wed, 28 Nov 2007 14:15:48 -0800 (PST) Date: Wed, 28 Nov 2007 14:15:48 -0800 From: Alfred Perlstein To: Poul-Henning Kamp Message-ID: <20071128221548.GR71382@elvis.mu.org> References: <1666.1196287742@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1666.1196287742@critter.freebsd.dk> User-Agent: Mutt/1.4.2.3i Cc: Daniel Eischen , Brooks Davis , Robert Watson , freebsd-arch@freebsd.org Subject: Re: RFC: libkse*.a in 7.0 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, 28 Nov 2007 22:15:48 -0000 * Poul-Henning Kamp [071128 14:09] wrote: > In message , Daniel Eischen wr > ites: > > >I think we should remove libthr.a, libkse.a and libc.a, so flame on! > > I used to disagree, based on arguments about embedded systems. > > I may be about to change my mind on this, but won't know for sure > until I get my hands dirty with 7.x on embedded platforms. > > I would suggest we put this question on the agenda for 8.x I think one thing to commit to is to still support static linking, but just not to have it as the default for our users. -Alfred From owner-freebsd-arch@FreeBSD.ORG Wed Nov 28 22:17:24 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 BD1A516A417 for ; Wed, 28 Nov 2007 22:17:24 +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 AF3CA13C468 for ; Wed, 28 Nov 2007 22:17:24 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 8B2AC1A4D7E; Wed, 28 Nov 2007 14:17:24 -0800 (PST) Date: Wed, 28 Nov 2007 14:17:24 -0800 From: Alfred Perlstein To: "M. Warner Losh" Message-ID: <20071128221724.GS71382@elvis.mu.org> References: <20071128.151021.709401576.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071128.151021.709401576.imp@bsdimp.com> User-Agent: Mutt/1.4.2.3i Cc: arch@FreeBSD.org Subject: Re: Code review request: small optimization to localtime.c 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, 28 Nov 2007 22:17:24 -0000 See pthread_once... Without pthread_once this is how it's suggested you do things by just about every threading/smp book out there. One thing you have to do is to make sure not to set "is_set" until after the work is done. Just use pthread_once. -Alfred * M. Warner Losh [071128 14:11] wrote: > Please find enclosed some small optimizations. I know they make a > couple lines too long, I'll correct that before I commit. They make > the time functions do less redundant locking. > > However, in many places we do the following: > > pthread_mutex_lock(); > if (!is_set) { > is_set = true; > // do something > } > pthread_mutex_unlock(); > > This is wasteful. We get locks ALL the time for every time operation, > when in fact we need it more rarely. If we can tolerate losing a > race, we can eliminate the locking in all but the startup case and > those threads racing the startup: > > if (!is_set) { > pthread_mutex_lock(); > if (!is_set) { > is_set = true; > // do something > } > pthread_mutex_unlock(); > } > > here, we know that is_set only ever changes from false to true. If it > is already true, there's nothing to do. If it is false, we may need > to do something, so we lock, check to see if we really need to do it, > etc. > > Can anybody see a flaw in this logic? > > Warner > > Index: localtime.c > =================================================================== > RCS file: /cache/ncvs/src/lib/libc/stdtime/localtime.c,v > retrieving revision 1.41 > diff -u -r1.41 localtime.c > --- localtime.c 19 Jan 2007 01:16:35 -0000 1.41 > +++ localtime.c 28 Nov 2007 21:59:59 -0000 > @@ -1093,14 +1093,16 @@ > struct tm *p_tm; > > if (__isthreaded != 0) { > - _pthread_mutex_lock(&localtime_mutex); > if (localtime_key < 0) { > - if (_pthread_key_create(&localtime_key, free) < 0) { > - _pthread_mutex_unlock(&localtime_mutex); > - return(NULL); > + _pthread_mutex_lock(&localtime_mutex); > + if (localtime_key < 0) { > + if (_pthread_key_create(&localtime_key, free) < 0) { > + _pthread_mutex_unlock(&localtime_mutex); > + return(NULL); > + } > } > + _pthread_mutex_unlock(&localtime_mutex); > } > - _pthread_mutex_unlock(&localtime_mutex); > p_tm = _pthread_getspecific(localtime_key); > if (p_tm == NULL) { > if ((p_tm = (struct tm *)malloc(sizeof(struct tm))) > @@ -1146,16 +1148,18 @@ > const long offset; > struct tm * const tmp; > { > - _MUTEX_LOCK(&gmt_mutex); > if (!gmt_is_set) { > - gmt_is_set = TRUE; > + _MUTEX_LOCK(&gmt_mutex); > + if (!gmt_is_set) { > + gmt_is_set = TRUE; > #ifdef ALL_STATE > - gmtptr = (struct state *) malloc(sizeof *gmtptr); > - if (gmtptr != NULL) > + gmtptr = (struct state *) malloc(sizeof *gmtptr); > + if (gmtptr != NULL) > #endif /* defined ALL_STATE */ > - gmtload(gmtptr); > + gmtload(gmtptr); > + } > + _MUTEX_UNLOCK(&gmt_mutex); > } > - _MUTEX_UNLOCK(&gmt_mutex); > timesub(timep, offset, gmtptr, tmp); > #ifdef TM_ZONE > /* > @@ -1187,14 +1191,16 @@ > struct tm *p_tm; > > if (__isthreaded != 0) { > - _pthread_mutex_lock(&gmtime_mutex); > if (gmtime_key < 0) { > - if (_pthread_key_create(&gmtime_key, free) < 0) { > - _pthread_mutex_unlock(&gmtime_mutex); > - return(NULL); > + _pthread_mutex_lock(&gmtime_mutex); > + if (gmtime_key < 0) { > + if (_pthread_key_create(&gmtime_key, free) < 0) { > + _pthread_mutex_unlock(&gmtime_mutex); > + return(NULL); > + } > } > + _pthread_mutex_unlock(&gmtime_mutex); > } > - _pthread_mutex_unlock(&gmtime_mutex); > /* > * Changed to follow POSIX.1 threads standard, which > * is what BSD currently has. > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" -- - Alfred Perlstein From owner-freebsd-arch@FreeBSD.ORG Wed Nov 28 22:20: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 77E9D16A46C; Wed, 28 Nov 2007 22:20:24 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9F5E213C474; Wed, 28 Nov 2007 22:20:23 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <474DE9B1.2050408@FreeBSD.org> Date: Wed, 28 Nov 2007 23:20:33 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Julian Elischer References: <20071128211022.GA74762@lor.one-eyed-alien.net> <474DE26F.4000303@elischer.org> In-Reply-To: <474DE26F.4000303@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Brooks Davis , freebsd-arch@freebsd.org Subject: Re: RFC: libkse*.a in 7.0 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, 28 Nov 2007 22:20:24 -0000 Julian Elischer wrote: > Brooks Davis wrote: >> A number of people have proposed a direction in 8.0 that would remove >> support for the syscalls and kernel data structures required by libkse. >> Apparently this would enable significant simplification of portions of >> the kernel, but I have no deeply held personal opinion. The intent is >> that if that happens, alternate versions of the necessicary dynamic >> libraries will be supplied in updated compat#x packages. This will >> address most consumers. The one set of consumers that would not be >> addressed is those who have statically linked, threaded binaries using >> libkse. > > Actually the simplifications in the kernel are almost negigable. > KSE support is almost totally contained within kern_kse.c at this time. > When KSEG support was removed, most of the changes outside of htis file > were removed.. > > the remaining changes not in that file could be moved to that file > relatively easily. > >> >> Kris and I realized that if we went that route, life would be >> significantly easier if it was difficult to create statically linked, >> binaries using libkse under FreeBSD 7.x. As a result I would like >> to commit and MFC the following patch which disables building and >> installing libkse*.a in the default case. This would mean that >> significant effort would be required to create a statically linked >> application that uses the KSE syscalls. >> >> I believe that removing libkse*.a has little downside and leaves the way >> open for either removing or enhancing the KSE system and is the right >> thing to do. > > If you wish.. however the performance downside of KSE is that we have > not run schedgraph on it and looked at what happens, rather than it being > against a wall of some sort.. the fact that it is slower than thr in > most cases is because there is a bug that stops it from scheduling > correctly. > > As I have not had the time or extreme burst of energy needed to find > this bug > it has not been found, but the fact that it rarely schedules threads > onto > 1 cpu at a time is not inherrent in the design. Well I think that after N years with no-one working on fixing KSE performance it is not reasonable to expect that this will change in the near future. Absent that, and given that KSE is about 2 orders of magnitude slower than libthr on application benchmarks, and has shown no performance improvement at all since 5.x, I don't think there is any compelling argument to leave it in the tree in 8.0-RELEASE. Anyone who thinks otherwise still has some time to work on fixing the performance issues though, of course. Kris From owner-freebsd-arch@FreeBSD.ORG Wed Nov 28 22:26:12 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 EC85016A421; Wed, 28 Nov 2007 22:26:12 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id A2E9B13C461; Wed, 28 Nov 2007 22:26:12 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.1/8.14.1) with ESMTP id lASMMwpk092821; Wed, 28 Nov 2007 15:22:58 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 28 Nov 2007 15:25:38 -0700 (MST) Message-Id: <20071128.152538.255407024.imp@bsdimp.com> To: alfred@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <20071128221724.GS71382@elvis.mu.org> References: <20071128.151021.709401576.imp@bsdimp.com> <20071128221724.GS71382@elvis.mu.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org Subject: Re: Code review request: small optimization to localtime.c 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, 28 Nov 2007 22:26:13 -0000 In message: <20071128221724.GS71382@elvis.mu.org> Alfred Perlstein writes: : See pthread_once... Good point. Much of the time code tries hard to avoid thread related things, but in all but one of these cases pthread_once() would be better than what's there now. Warner From owner-freebsd-arch@FreeBSD.ORG Wed Nov 28 22:30:32 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 BA5A416A41A; Wed, 28 Nov 2007 22:30:32 +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 6E08E13C458; Wed, 28 Nov 2007 22:30:32 +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 E5B3517106; Wed, 28 Nov 2007 22:30:30 +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 lASMUUkD001815; Wed, 28 Nov 2007 22:30:30 GMT (envelope-from phk@critter.freebsd.dk) To: Kris Kennaway From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 28 Nov 2007 23:20:33 +0100." <474DE9B1.2050408@FreeBSD.org> Date: Wed, 28 Nov 2007 22:30:30 +0000 Message-ID: <1814.1196289030@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Brooks Davis , Julian Elischer , freebsd-arch@FreeBSD.org Subject: Re: RFC: libkse*.a in 7.0 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, 28 Nov 2007 22:30:32 -0000 In message <474DE9B1.2050408@FreeBSD.org>, Kris Kennaway writes: >Well I think that after N years with no-one working on fixing KSE >performance it is not reasonable to expect that this will change in the >near future. ...Not to mention that it crashes under heavy load. -- 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 Wed Nov 28 22:42:14 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 9F4E416A419 for ; Wed, 28 Nov 2007 22:42:14 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 7392013C45B for ; Wed, 28 Nov 2007 22:42:14 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.2/8.14.2/NETPLEX) with ESMTP id lASMJgnZ008341; Wed, 28 Nov 2007 17:19:42 -0500 (EST) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.0 (mail.netplex.net [204.213.176.10]); Wed, 28 Nov 2007 17:19:42 -0500 (EST) Date: Wed, 28 Nov 2007 17:19:42 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: "M. Warner Losh" In-Reply-To: <20071128.151021.709401576.imp@bsdimp.com> Message-ID: References: <20071128.151021.709401576.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org Subject: Re: Code review request: small optimization to localtime.c X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2007 22:42:14 -0000 On Wed, 28 Nov 2007, M. Warner Losh wrote: > Please find enclosed some small optimizations. I know they make a > couple lines too long, I'll correct that before I commit. They make > the time functions do less redundant locking. > > However, in many places we do the following: > > pthread_mutex_lock(); > if (!is_set) { > is_set = true; > // do something > } > pthread_mutex_unlock(); > > This is wasteful. We get locks ALL the time for every time operation, > when in fact we need it more rarely. If we can tolerate losing a > race, we can eliminate the locking in all but the startup case and > those threads racing the startup: > > if (!is_set) { > pthread_mutex_lock(); > if (!is_set) { > is_set = true; > // do something > } > pthread_mutex_unlock(); > } > > here, we know that is_set only ever changes from false to true. If it > is already true, there's nothing to do. If it is false, we may need > to do something, so we lock, check to see if we really need to do it, > etc. > > Can anybody see a flaw in this logic? Is this not a good place to use pthread_once() instead? -- DE From owner-freebsd-arch@FreeBSD.ORG Thu Nov 29 04:17: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 0E3FC16A418; Thu, 29 Nov 2007 04:17:16 +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 C0ECC13C459; Thu, 29 Nov 2007 04:17:15 +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 1Ixapr-0009aL-L7; Thu, 29 Nov 2007 06:17:14 +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 lAT4HBD2062916; Thu, 29 Nov 2007 06:17:11 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id lAT4HBhR062915; Thu, 29 Nov 2007 06:17:11 +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: Thu, 29 Nov 2007 06:17:11 +0200 From: Kostik Belousov To: Robert Watson Message-ID: <20071129041710.GC83121@deviant.kiev.zoral.com.ua> References: <20071128211022.GA74762@lor.one-eyed-alien.net> <20071128213947.Q7555@fledge.watson.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Bu8it7iiRSEf40bY" Content-Disposition: inline In-Reply-To: <20071128213947.Q7555@fledge.watson.org> User-Agent: Mutt/1.4.2.3i X-Scanner-Signature: 5e2df25549de819b25d1bfd51e9f52eb X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 1834 [Nov 29 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 Cc: Brooks Davis , freebsd-arch@freebsd.org Subject: Re: RFC: libkse*.a in 7.0 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, 29 Nov 2007 04:17:16 -0000 --Bu8it7iiRSEf40bY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 28, 2007 at 09:42:10PM +0000, Robert Watson wrote: >=20 > On Wed, 28 Nov 2007, Brooks Davis wrote: >=20 > >A number of people have proposed a direction in 8.0 that would remove=20 > >support for the syscalls and kernel data structures required by libkse.= =20 > >Apparently this would enable significant simplification of portions of t= he=20 > >kernel, but I have no deeply held personal opinion. The intent is that = if=20 > >that happens, alternate versions of the necessicary dynamic libraries wi= ll=20 > >be supplied in updated compat#x packages. This will address most=20 > >consumers. The one set of consumers that would not be addressed is those= =20 > >who have statically linked, threaded binaries using libkse. >=20 > It's worth noting that some other mainstream operating systems work hard = to=20 > disallow static linking for precisely this sort of reason -- when I last= =20 > checked, Mac OS X had only one statically linked binary, init, and it may= =20 > well be that launchd is dynamically linked. This is part of a very=20 > explicit policy that the defined ABI for applications is *not* the system= =20 > call layer, but rather, the library interfaces, which gives greater=20 > flexibility to modify the system call interface as needed. Some more other mainstream operating system did break the ABI at the syscall level precisely changing the threading model. Now, they have to implement separate project to be able to execute runtime for version 8 on the version 10. What is worst, they require a full zone to do this. FreeBSD ability to run the old binary is very valuable. --Bu8it7iiRSEf40bY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHTj1GC3+MBN1Mb4gRAlUeAKCI+nEYSVFgobChmp2QDidnAWD7qgCg4gCj 1nGhcvhmANi/CoEuN1DABK4= =vXXE -----END PGP SIGNATURE----- --Bu8it7iiRSEf40bY-- From owner-freebsd-arch@FreeBSD.ORG Thu Nov 29 09:49:51 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 5EC3316A418; Thu, 29 Nov 2007 09:49:51 +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 210DC13C467; Thu, 29 Nov 2007 09:49:51 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A5570B.dip.t-dialin.net [84.165.87.11]) by redbull.bpaserver.net (Postfix) with ESMTP id D258B2E2D1; Thu, 29 Nov 2007 10:47:28 +0100 (CET) Received: from webmail.leidinger.net (webmail.Leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 20DEE74EDA; Thu, 29 Nov 2007 10:47:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1196329646; bh=3PeqetMIlZBGcFQgC82jGsw/Y8acYtDee YZfgLxyETM=; h=Message-ID:X-Priority:Date:From:To:Cc:Subject: References:In-Reply-To:MIME-Version:Content-Type: Content-Disposition:Content-Transfer-Encoding:User-Agent; b=oL4J0m bWXiplQ9JliimeiUbqolNUAX7Qz4LtGPKY+0a1YPmdF0BkHDLp4fPyD0awrpqBubRcm Nrp7ALCLVIjOI0XzZV/yCcG7We7OxBFJb8lnnuj82tMF900SUIRJGSzxTFnDlJB78hu VAOB/M368J7Z4Ik9x2+ifMlEEWGRU6FMILtpB+67WL7bj+xhdTlN7+CfYPBckvMcGOM MJX2rGDoC/RIVVbATljkFLdx6UNcO6GUo+l74YL5SeRVVfIrbPAmNFGH7wRlDbicJ28 TBGqfjGe1gNNu8Cyj/aOt2P5YmYwo+jOQO5QYpgKUbTMMJOWdSvsUStULf3iMuOYVIC Q== Received: (from www@localhost) by webmail.leidinger.net (8.14.1/8.13.8/Submit) id lAT9lQTM031761; Thu, 29 Nov 2007 10:47:26 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Thu, 29 Nov 2007 10:47:25 +0100 Message-ID: <20071129104725.7txgka1j40k840cs@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Thu, 29 Nov 2007 10:47:25 +0100 From: Alexander Leidinger To: Remko Lodder References: <474DDBC2.3030704@FreeBSD.org> In-Reply-To: <474DDBC2.3030704@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.4) / FreeBSD-7.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-14.9, required 6, BAYES_00 -15.00, DKIM_SIGNED 0.00, DKIM_VERIFIED -0.00, RDNS_DYNAMIC 0.10) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: freebsd-arch@FreeBSD.org Subject: Re: Removal of /etc/skel, your opinions please 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, 29 Nov 2007 09:49:51 -0000 Quoting Remko Lodder (from Wed, 28 Nov 2007 =20 22:21:06 +0100): > > Dear arch@ members, > > I would like to remove /etc/skel from the BSD.root.dist mtree file > since it is no longer being used and I would like to remove unused > items. > > I understood from a PR (46062) that there are no references to this > directory any longer. There is a proposal to symlink this; but I dont > want to keep this alive at all where possible.. > > Does anyone have objections to this change? If so, please let me know > why you have these objections so that I can take them into account. Not an objection, just something to think about: Do we want to =20 deprecate the use of "adduser -k /etc/skel"? I know you said you just =20 want to remove the directory, and every admin is allowed to create it =20 again, but by removing the directory from the mtree file, we give a =20 signal into the direction of deprecation. Bye, Alexander. --=20 I have discovered the art of deceiving diplomats. I tell them the truth and they never believe me. =09=09-- Camillo Di Cavour 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 Thu Nov 29 15:07:50 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 EE0DC16A46C for ; Thu, 29 Nov 2007 15:07:50 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id B70A513C461 for ; Thu, 29 Nov 2007 15:07:50 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 038D42095; Thu, 29 Nov 2007 15:50:08 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.1/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id EAF892094; Thu, 29 Nov 2007 15:50:07 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id B473884498; Thu, 29 Nov 2007 15:50:07 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "M. Warner Losh" References: <20071128.151021.709401576.imp@bsdimp.com> Date: Thu, 29 Nov 2007 15:50:07 +0100 In-Reply-To: <20071128.151021.709401576.imp@bsdimp.com> (M. Warner Losh's message of "Wed\, 28 Nov 2007 15\:10\:21 -0700 \(MST\)") Message-ID: <86lk8hhzs0.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: arch@FreeBSD.org Subject: Re: Code review request: small optimization to localtime.c 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, 29 Nov 2007 15:07:51 -0000 "M. Warner Losh" writes: > Please find enclosed some small optimizations. [...] almost completely unrelated, but while you're at it: > if (__isthreaded !=3D 0) { __isthreaded is clearly (by its name) a predicate, comparing it explicitly to 0 is redundant and disrupts my flow of thought when reading the code. Instead of just reading "if is threaded", I have to take a second to parse the expression and check which way the comparison goes. We already have a policy (unwritten as far as I know) of using explicit comparisons for variables which are not clearly predicates, can we also have one of *not* using explicit comparisons for those that are? And document both cases in style(9)? DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Thu Nov 29 15:24: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 DDF4416A417; Thu, 29 Nov 2007 15:24:20 +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 7373513C4D1; Thu, 29 Nov 2007 15:24:20 +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 lATFOJic083101; Thu, 29 Nov 2007 09:24:19 -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 lATFOJAp083100; Thu, 29 Nov 2007 09:24:19 -0600 (CST) (envelope-from brooks) Date: Thu, 29 Nov 2007 09:24:18 -0600 From: Brooks Davis To: Remko Lodder Message-ID: <20071129152418.GA76737@lor.one-eyed-alien.net> References: <474DDBC2.3030704@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BXVAT5kNtrzKuDFl" Content-Disposition: inline In-Reply-To: <474DDBC2.3030704@FreeBSD.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]); Thu, 29 Nov 2007 09:24:19 -0600 (CST) Cc: freebsd-arch@freebsd.org Subject: Re: Removal of /etc/skel, your opinions please 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, 29 Nov 2007 15:24:21 -0000 --BXVAT5kNtrzKuDFl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 28, 2007 at 10:21:06PM +0100, Remko Lodder wrote: >=20 > Dear arch@ members, >=20 > I would like to remove /etc/skel from the BSD.root.dist mtree file > since it is no longer being used and I would like to remove unused > items. >=20 > I understood from a PR (46062) that there are no references to this > directory any longer. There is a proposal to symlink this; but I dont > want to keep this alive at all where possible.. >=20 > Does anyone have objections to this change? If so, please let me know > why you have these objections so that I can take them into account. >=20 > Thanks in advance for your time! After reading this I did some searching and was rather surprised to discover that adduser(8) points pw at /usr/share/skel by default. I've always thought of /etc/skel as the default location for skel files. It's true we're not populating /etc/skel by default, but /usr/share/skel isn't actually usable in production since it's overwritten by installworld. I don't see any value in removing the directory from mtree. -- Brooks --BXVAT5kNtrzKuDFl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFHTtmiXY6L6fI4GtQRAlvkAJ95pg5kaVK+Jg2b9S8p4DKqXIOQ8ACdEvRw P8YMgEKieZ3c3iRw7zik9oo= =xn3g -----END PGP SIGNATURE----- --BXVAT5kNtrzKuDFl-- From owner-freebsd-arch@FreeBSD.ORG Thu Nov 29 15:41:32 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 49EB716A469 for ; Thu, 29 Nov 2007 15:41:32 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 10E6313C4EF for ; Thu, 29 Nov 2007 15:41:31 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.1/8.14.1) with ESMTP id lATFcGYb011116; Thu, 29 Nov 2007 08:38:16 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 29 Nov 2007 08:41:08 -0700 (MST) Message-Id: <20071129.084108.-713549098.imp@bsdimp.com> To: des@des.no From: "M. Warner Losh" In-Reply-To: <86lk8hhzs0.fsf@ds4.des.no> References: <20071128.151021.709401576.imp@bsdimp.com> <86lk8hhzs0.fsf@ds4.des.no> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: arch@FreeBSD.org Subject: Re: Code review request: small optimization to localtime.c 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, 29 Nov 2007 15:41:32 -0000 In message: <86lk8hhzs0.fsf@ds4.des.no> Dag-Erling_Sm=F8rgrav writes: : "M. Warner Losh" writes: : > Please find enclosed some small optimizations. [...] : = : almost completely unrelated, but while you're at it: : = : > if (__isthreaded !=3D 0) { : = : __isthreaded is clearly (by its name) a predicate, comparing it : explicitly to 0 is redundant and disrupts my flow of thought when : reading the code. Instead of just reading "if is threaded", I have t= o : take a second to parse the expression and check which way the compari= son : goes. : = : We already have a policy (unwritten as far as I know) of using explic= it : comparisons for variables which are not clearly predicates, can we al= so : have one of *not* using explicit comparisons for those that are? And= : document both cases in style(9)? True, but very Brucian in the nature of the comment: I didn't change this in existing code. :-) I'll take a look at this sort of thing as well. Warner From owner-freebsd-arch@FreeBSD.ORG Thu Nov 29 18:24: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 84AD116A417; Thu, 29 Nov 2007 18:24:30 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from fallbackmx06.syd.optusnet.com.au (fallbackmx06.syd.optusnet.com.au [211.29.132.8]) by mx1.freebsd.org (Postfix) with ESMTP id 1F21C13C46B; Thu, 29 Nov 2007 18:24:29 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail06.syd.optusnet.com.au (mail06.syd.optusnet.com.au [211.29.132.187]) by fallbackmx06.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id lATAph4n007163; Thu, 29 Nov 2007 21:51:43 +1100 Received: from server.vk2pj.dyndns.org (c220-239-20-82.belrs4.nsw.optusnet.com.au [220.239.20.82]) by mail06.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id lATApYU2011542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Nov 2007 21:51:34 +1100 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.1/8.14.1) with ESMTP id lATApXxb028385; Thu, 29 Nov 2007 21:51:33 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.1/8.14.1/Submit) id lATApXw9028384; Thu, 29 Nov 2007 21:51:33 +1100 (EST) (envelope-from peter) Date: Thu, 29 Nov 2007 21:51:33 +1100 From: Peter Jeremy To: Daniel Eischen Message-ID: <20071129105133.GS50167@server.vk2pj.dyndns.org> References: <20071128211022.GA74762@lor.one-eyed-alien.net> <20071128213947.Q7555@fledge.watson.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dMdWWqg3F2Dv/qfw" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-arch@freebsd.org Subject: Re: RFC: libkse*.a in 7.0 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, 29 Nov 2007 18:24:30 -0000 --dMdWWqg3F2Dv/qfw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 28, 2007 at 04:54:05PM -0500, Daniel Eischen wrote: >I argued for removing libc.a as well as lib.a a couple of >years ago and was met with opposition, mostly because statically >linked applications are faster. There are two distinct pieces to this: 1) RTLD is an overhead for shared libraries. 2) Some CPUs don't natively support PIC and so PIC code is larger/slower. We can't get rid of either but maybe we should look at wiring .so's to preferred pre-linked addresses: If the library will map at it's desired location then most/all offsets offsets are pre-done so RTLD is much simpler. Linux used to do this (I'm not sure if it still does). Tru64 Unix supports it as an option. =20 >I think we should remove libthr.a, libkse.a and libc.a, so flame on! Note that much of the toolchain is currently statically linked so removing libc.a may expose some edge cases in buildworld/installworld. --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --dMdWWqg3F2Dv/qfw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHTpm1/opHv/APuIcRAl2sAJ98u2sWkvhNge2VZWrbAVgZCCFdJgCfe32n +RXPEf3PJS1nGio01aiPqv0= =EYUT -----END PGP SIGNATURE----- --dMdWWqg3F2Dv/qfw-- From owner-freebsd-arch@FreeBSD.ORG Thu Nov 29 20:39: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 D884E16A41B for ; Thu, 29 Nov 2007 20:39:23 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by mx1.freebsd.org (Postfix) with ESMTP id 4BFDF13C442 for ; Thu, 29 Nov 2007 20:39:21 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so1960061nfb for ; Thu, 29 Nov 2007 12:39:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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=5tPk+4Lx3gyDjwDZUHZWi+XX4elNgdWfcXiHPMjKaSY=; b=SEN6aD55rmvURq0rlEgrReleDuqXu87ta2G6nDBU2N6gk0Q8O3gH75XnnFN4mz7A+N22/O+NdWYYRwHGNc8aVtxXgSoeltn94ca0lQaupYxV+TmYCp0+lUjxD80WQpX4DxUnHJkANXrtlJlfCtBPu0RN2z5BIj63F5+uBtu/ukQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; 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=jtMYLhYuB2WMM7Q7U/1TR6Vss4Bnu0fgUARTB1U/yDJvceCQ0qEqBuKqAvhx++Q27oGwHJxScYv6XDg/5AUxc7AnB524rFmyc294DVkRWB3/HZEWBkZkzBLfZ3sAGGAQmkZ/KKM3jd7/TPrDc7xDCQQUkWsyVYUYI4fU/MPuMWA= Received: by 10.86.71.1 with SMTP id t1mr6447312fga.1196368760439; Thu, 29 Nov 2007 12:39:20 -0800 (PST) Received: by 10.86.28.19 with HTTP; Thu, 29 Nov 2007 12:39:20 -0800 (PST) Message-ID: <3bbf2fe10711291239p553af196ma406fc67fb1c350d@mail.gmail.com> Date: Thu, 29 Nov 2007 21:39:20 +0100 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Robert Watson" In-Reply-To: <3bbf2fe10711231635i72df8babucedd1e5bdef7175d@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20071121222319.GX44563@elvis.mu.org> <200711221641.02484.max@love2party.net> <3bbf2fe10711220753u435ff4cbxa94d5b682292b970@mail.gmail.com> <200711221726.27108.max@love2party.net> <20071123082339.GN44563@elvis.mu.org> <47469328.8020404@freebsd.org> <20071123092415.GP44563@elvis.mu.org> <4746F858.4070301@freebsd.org> <20071123235346.E14018@fledge.watson.org> <3bbf2fe10711231635i72df8babucedd1e5bdef7175d@mail.gmail.com> X-Google-Sender-Auth: 627131c92186db98 Cc: freebsd-smp@freebsd.org, Jeff Roberson , Alfred Perlstein , freebsd-arch@freebsd.org, Stephan Uphoff , Max Laier Subject: Re: rwlocks, correctness over speed. 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, 29 Nov 2007 20:39:23 -0000 2007/11/24, Attilio Rao : > 2007/11/24, Robert Watson : > > > > On Fri, 23 Nov 2007, Stephan Uphoff wrote: > > > > >>> I talked with Attilio about that on IRC. Most common cases of writer > > >>> starvation (but not all) could be solved by keeping a per thread count of > > >>> shared acquired rwlocks. If a rwlock is currently locked as shared/read > > >>> AND a thread is blocked on it to lock it exclusively/write - then new > > >>> shared/read locks will only be granted to thread that already has a shared > > >>> lock. (per thread shared counter is non zero) > > >>> > > >>> To be honest I am a bit twitchy about a lock without priority propagation > > >>> - especially since in FreeBSD threads run with user priority in kernel > > >>> space and can get preempted. > > >> > > >> That's an interesting hack, I guess it could be done. > > >> > > >> I would still like to disallow recursion. > > >> > > > Oh - I am all for disallowing recursion. In my opinion the only valid place > > > for a thread to acquire the same lock multiple times is inside a transaction > > > system with full deadlock detection. The question is if we can do that this > > > late in the game? Maybe we could make non recursive the default and add a > > > call rw_allow_recurse or rw_init_recurse to allow recursion on a lock if we > > > can't get away with the straight out removal of the option? (Or less > > > desirable - keep the current default and add functions to disallow > > > recursion) > > > > While I'm no great fan of recursion, the reality is that many of our kernel > > subsystems are not yet ready to disallow recursion on locks. Take a look at > > the cases where we explicitly enable recursive acquisition for mutexes--in > > practice, most network stack mutexes are recursive due to the recursive > > calling in the network stack. While someday I'd like to think we'll be able > > to eliminate some of that, but it won't be soon since it requires significant > > reworking of very complicated code. The current model in which recursion is > > explicitly enabled only where still required seems to work pretty well for the > > existing code, although it's hard to say yet in the code I've looked at > > whether read recursion would be required--the situations I have in mind would > > require purely write recursion. There's one case in the UNIX domain socket > > code where we do a locked test and conditional lock/unlock with an rwlock for > > exclusive locking because recursion isn't currently supported, and that's not > > a usage I'd like to encourage more of. > > I think however that Stephan is just referring to the readers > recursion (as we are doing) that if present should be just in few > points. > If we want todo a radical switch of this genre this is the right > moment, just before rwlock became too widespread. > > I have a patch against witness which would check for readers recursion > and panic, I will post in the night or tomorrow. So, this patch checks for recursive readers and will panic in case: http://people.freebsd.org/~attilio/recursion_checks.diff (I preferred to do in this way, but you can check for perforce commit number 129792 for an alternative way to achieve the same). What I'm looking for now is for people which can apply this patch, enable WITNESS with all the relevant options on and try to see if there are recursive readers in rwlocks somewhere (hopefully not after the pfil(9) switching to rmlock that mlaier did recently). Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-arch@FreeBSD.ORG Fri Nov 30 04:18:20 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 491B216A419 for ; Fri, 30 Nov 2007 04:18:20 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx10.syd.optusnet.com.au (fallbackmx10.syd.optusnet.com.au [211.29.132.251]) by mx1.freebsd.org (Postfix) with ESMTP id D715513C461 for ; Fri, 30 Nov 2007 04:18:18 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail05.syd.optusnet.com.au (mail05.syd.optusnet.com.au [211.29.132.186]) by fallbackmx10.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id lATN59Ji004420 for ; Fri, 30 Nov 2007 10:05:11 +1100 Received: from besplex.bde.org (c211-30-219-213.carlnfd3.nsw.optusnet.com.au [211.30.219.213]) by mail05.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id lATN4svY011397 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Nov 2007 10:04:58 +1100 Date: Fri, 30 Nov 2007 10:04:54 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: "M. Warner Losh" In-Reply-To: <20071129.084108.-713549098.imp@bsdimp.com> Message-ID: <20071130094705.E6718@besplex.bde.org> References: <20071128.151021.709401576.imp@bsdimp.com> <86lk8hhzs0.fsf@ds4.des.no> <20071129.084108.-713549098.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1458219190-1196377494=:6718" Cc: des@des.no, arch@freebsd.org Subject: Re: Code review request: small optimization to localtime.c 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, 30 Nov 2007 04:18:20 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1458219190-1196377494=:6718 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Thu, 29 Nov 2007, M. Warner Losh wrote: > In message: <86lk8hhzs0.fsf@ds4.des.no> > Dag-Erling_Sm=F8rgrav writes: > : "M. Warner Losh" writes: > : > Please find enclosed some small optimizations. [...] > : > : almost completely unrelated, but while you're at it: > : > : > =09if (__isthreaded !=3D 0) { > : > : __isthreaded is clearly (by its name) a predicate, comparing it > : explicitly to 0 is redundant and disrupts my flow of thought when > : reading the code. Instead of just reading "if is threaded", I have to > : take a second to parse the expression and check which way the compariso= n > : goes. > : > : We already have a policy (unwritten as far as I know) of using explicit > : comparisons for variables which are not clearly predicates, can we also > : have one of *not* using explicit comparisons for those that are? And > : document both cases in style(9)? > > True, but very Brucian in the nature of the comment: I didn't change > this in existing code. :-) KNF rules are sort of the opposite in some respects -- -- "if ((flags & MASK) !=3D 0)", which is like the above, is slightly more normal than "if (flags & MASK)".=20 -- The unary "!" operator is rarely used. "if (!isfoo)" and "if (!(flags & MASK))" are not normal. Anyway, there is too much existing code with bad style to change. I draw the line (for non-booleans) between !error and !strcmp(). Bruce --0-1458219190-1196377494=:6718-- From owner-freebsd-arch@FreeBSD.ORG Fri Nov 30 07:25: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 D7C2E16A417 for ; Fri, 30 Nov 2007 07:25:31 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from galain.elvandar.org (galain.elvandar.org [217.148.169.56]) by mx1.freebsd.org (Postfix) with ESMTP id 88E2413C44B for ; Fri, 30 Nov 2007 07:25:31 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from localhost.we-dare.net ([127.0.0.1] helo=galain.elvandar.org) by galain.elvandar.org with esmtpa (Exim 4.67) (envelope-from ) id 1Iy0Fe-000FZ2-M8; Fri, 30 Nov 2007 08:25:30 +0100 Received: from 194.74.82.3 (SquirrelMail authenticated user remko) by galain.elvandar.org with HTTP; Fri, 30 Nov 2007 08:25:30 +0100 (CET) Message-ID: <17978.194.74.82.3.1196407530.squirrel@galain.elvandar.org> Date: Fri, 30 Nov 2007 08:25:30 +0100 (CET) From: "Remko Lodder" To: "Alexander Leidinger" User-Agent: SquirrelMail/1.4.11 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-arch@freebsd.org Subject: Re: Removal of /etc/skel, your opinions please 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, 30 Nov 2007 07:25:31 -0000 On Thu, November 29, 2007 10:47 am, Alexander Leidinger wrote: > Quoting Remko Lodder (from Wed, 28 Nov 2007 > 22:21:06 +0100): > >> >> Dear arch@ members, >> >> I would like to remove /etc/skel from the BSD.root.dist mtree file >> since it is no longer being used and I would like to remove unused >> items. >> >> I understood from a PR (46062) that there are no references to this >> directory any longer. There is a proposal to symlink this; but I dont >> want to keep this alive at all where possible.. >> >> Does anyone have objections to this change? If so, please let me know >> why you have these objections so that I can take them into account. > > Not an objection, just something to think about: Do we want to > deprecate the use of "adduser -k /etc/skel"? I know you said you just > want to remove the directory, and every admin is allowed to create it > again, but by removing the directory from the mtree file, we give a > signal into the direction of deprecation. > > Bye, > Alexander. > > -- Hello Alexander, You do have a point there actually :-), what we can do in the install phase (initially "make distribution", later on when the system is already installed, manage this through "mergemaster") is install all files from /usr/share/skel to /etc/skel and actually use it. If we dont want to do that, why should we keep on carrying the directory then? Cheers remko -- /"\ Best regards, | remko@FreeBSD.org \ / Remko Lodder | remko@EFnet X http://www.evilcoder.org/ | / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-arch@FreeBSD.ORG Fri Nov 30 07:27:15 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 DDCE416A41A for ; Fri, 30 Nov 2007 07:27:15 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from galain.elvandar.org (galain.elvandar.org [217.148.169.56]) by mx1.freebsd.org (Postfix) with ESMTP id 8D67C13C44B for ; Fri, 30 Nov 2007 07:27:15 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from localhost.we-dare.net ([127.0.0.1] helo=galain.elvandar.org) by galain.elvandar.org with esmtpa (Exim 4.67) (envelope-from ) id 1Iy0HK-000Fa4-Df; Fri, 30 Nov 2007 08:27:14 +0100 Received: from 194.74.82.3 (SquirrelMail authenticated user remko) by galain.elvandar.org with HTTP; Fri, 30 Nov 2007 08:27:14 +0100 (CET) Message-ID: <18724.194.74.82.3.1196407634.squirrel@galain.elvandar.org> Date: Fri, 30 Nov 2007 08:27:14 +0100 (CET) From: "Remko Lodder" To: "Brooks Davis" User-Agent: SquirrelMail/1.4.11 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-arch@freebsd.org Subject: Re: Removal of /etc/skel, your opinions please 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, 30 Nov 2007 07:27:16 -0000 On Thu, November 29, 2007 4:24 pm, Brooks Davis wrote: > On Wed, Nov 28, 2007 at 10:21:06PM +0100, Remko Lodder wrote: >> >> Dear arch@ members, >> >> I would like to remove /etc/skel from the BSD.root.dist mtree file >> since it is no longer being used and I would like to remove unused >> items. >> >> I understood from a PR (46062) that there are no references to this >> directory any longer. There is a proposal to symlink this; but I dont >> want to keep this alive at all where possible.. >> >> Does anyone have objections to this change? If so, please let me know >> why you have these objections so that I can take them into account. >> >> Thanks in advance for your time! > > After reading this I did some searching and was rather surprised to > discover that adduser(8) points pw at /usr/share/skel by default. > I've always thought of /etc/skel as the default location for skel > files. It's true we're not populating /etc/skel by default, but > /usr/share/skel isn't actually usable in production since it's > overwritten by installworld. > > I don't see any value in removing the directory from mtree. > > -- Brooks > Hello Brooks, First of all thanks for your answer as well, I think the same applies here as I replied to Alexander, is that we should in that case fill /etc/skel with the distribution found in /usr/share/skel (or directly to reduce possible overhead in having it in two directories); if we are not going to persue that I dont see much points in keeping an empty directory? Cheers remko -- /"\ Best regards, | remko@FreeBSD.org \ / Remko Lodder | remko@EFnet X http://www.evilcoder.org/ | / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-arch@FreeBSD.ORG Fri Nov 30 09:17:13 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B902C16A418; Fri, 30 Nov 2007 09:17:13 +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 335BF13C447; Fri, 30 Nov 2007 09:17:12 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A54CE6.dip.t-dialin.net [84.165.76.230]) by redbull.bpaserver.net (Postfix) with ESMTP id 8AB3A2E2C7; Fri, 30 Nov 2007 10:16:54 +0100 (CET) Received: from webmail.leidinger.net (webmail.Leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 7F9AB77426; Fri, 30 Nov 2007 10:16:51 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1196414211; bh=dPpv1drrN0VhFf/Q2YNfxBfvmsyK/mUYG cCXGJXVPe8=; h=Message-ID:X-Priority:Date:From:To:Cc:Subject: References:In-Reply-To:MIME-Version:Content-Type: Content-Disposition:Content-Transfer-Encoding:User-Agent; b=OOGqLb orvSpbGj+wbkkhbXGNWtlXX2IREf2tl68+06bfhQ5CJczZbYyWMYwr6E06hj4vK7KGs h0t1L2KVXNekrAsoIomDVtGYIpSQ2w7cY+4ehxzu9HaIkA0jSiTk9XcRi1QEWF0T2gZ X1L/sBJgIq1QUtwy9Jj04L21+uH/xV6ZemYq2jz/S4CXxq30KlPdJ/TPXt10TfnDNzx nhghppiOYyNj2WY6kQ3hh3X/QtrVyqW7f+gcprI35lHYmXdJXtzEB0rZhdF9XueKQO2 5SL7hSzX3kagCUuKjXvO2nXhVbXzWtdDHN+nxP5P4oO4wGEG2oLKE5GoNAYzljFJHR+ g== Received: (from www@localhost) by webmail.leidinger.net (8.14.1/8.13.8/Submit) id lAU9Gp8f067919; Fri, 30 Nov 2007 10:16:51 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Fri, 30 Nov 2007 10:16:51 +0100 Message-ID: <20071130101651.4h9nvpztkwcg8o84@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Fri, 30 Nov 2007 10:16:51 +0100 From: Alexander Leidinger To: Remko Lodder References: <17978.194.74.82.3.1196407530.squirrel@galain.elvandar.org> In-Reply-To: <17978.194.74.82.3.1196407530.squirrel@galain.elvandar.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.4) / FreeBSD-7.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-15.4, required 6, autolearn=not spam, BAYES_00 -15.00, DKIM_SIGNED 0.00, DKIM_VERIFIED -0.00, RDNS_DYNAMIC 0.10, SMILEY -0.50) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: freebsd-arch@FreeBSD.org Subject: Re: Removal of /etc/skel, your opinions please 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, 30 Nov 2007 09:17:13 -0000 Quoting Remko Lodder (from Fri, 30 Nov 2007 =20 08:25:30 +0100 (CET)): > > On Thu, November 29, 2007 10:47 am, Alexander Leidinger wrote: >> Quoting Remko Lodder (from Wed, 28 Nov 2007 >> 22:21:06 +0100): >> >>> >>> Dear arch@ members, >>> >>> I would like to remove /etc/skel from the BSD.root.dist mtree file >>> since it is no longer being used and I would like to remove unused >>> items. >> Not an objection, just something to think about: Do we want to >> deprecate the use of "adduser -k /etc/skel"? I know you said you just >> want to remove the directory, and every admin is allowed to create it >> again, but by removing the directory from the mtree file, we give a >> signal into the direction of deprecation. > You do have a point there actually :-), what we can do in the install > phase (initially "make distribution", later on when the system is already > installed, manage this through "mergemaster") is install all files from > /usr/share/skel to /etc/skel and actually use it. > > If we dont want to do that, why should we keep on carrying the directory > then? I have a local patch to adduser which adds /usr/local/share/skel (so 2 =20 directories are used by default). Now I think it may be better to =20 change this to use /etc/skel instead, and to do it in a way that =20 /etc/skel overrides /usr/share/skel. Looks more usable to me. What do =20 you think? Bye, Alexander. --=20 The most winning woman I ever knew was hanged for poisoning three little children for their insurance money. =09=09-- Sherlock Holmes 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 30 11:46: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 B02BE16A417 for ; Fri, 30 Nov 2007 11:46:56 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 5DA2413C4DB for ; Fri, 30 Nov 2007 11:46:56 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 67B442085; Fri, 30 Nov 2007 12:46:46 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.1/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 57DFA2084; Fri, 30 Nov 2007 12:46:46 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id 5182A84485; Fri, 30 Nov 2007 12:46:46 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Bruce Evans References: <20071128.151021.709401576.imp@bsdimp.com> <86lk8hhzs0.fsf@ds4.des.no> <20071129.084108.-713549098.imp@bsdimp.com> <20071130094705.E6718@besplex.bde.org> Date: Fri, 30 Nov 2007 12:46:46 +0100 In-Reply-To: <20071130094705.E6718@besplex.bde.org> (Bruce Evans's message of "Fri\, 30 Nov 2007 10\:04\:54 +1100 \(EST\)") Message-ID: <86ve7kgdll.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: arch@freebsd.org Subject: Re: Code review request: small optimization to localtime.c 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, 30 Nov 2007 11:46:56 -0000 Bruce Evans writes: > KNF rules are sort of the opposite in some respects -- > -- "if ((flags & MASK) !=3D 0)", which is like the above, is slightly > more normal than "if (flags & MASK)". -- The unary "!" operator is > rarely used. "if (!isfoo)" and > "if (!(flags & MASK))" are not normal. This is not "opposite" - as I said, we have a rule about when we *should* use an explicit comparison, but we lack a rule about when we *should not*. I think we *should not* use an explicit comparison when the expression being tested is obviously a predicate, for instance when it is a variable or a call to a function whose name begins with "is", "can" or similar. A corollary is that variables and functions *should not* have names that begin with "is", "can" or similar unless they can be used correctly without an explicit comparison. You should never have to write something like "if (__isthreaded =3D=3D 5)". BTW, (flags & MASK) is a poor example; depending on the value of MASK, there may actually be several distinct non-zero values, so an explicit comparison is justified. > Anyway, there is too much existing code with bad style to change. I > draw the line (for non-booleans) between !error and !strcmp(). I loathe !strcmp(), but I also generally try to avoid !error. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Fri Nov 30 12:44:26 2007 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B652116A418; Fri, 30 Nov 2007 12:44:26 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 8155513C43E; Fri, 30 Nov 2007 12:44:26 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 5DD8B46EE2; Fri, 30 Nov 2007 07:48:37 -0500 (EST) Date: Fri, 30 Nov 2007 12:44:18 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Alexander Leidinger In-Reply-To: <20071130101651.4h9nvpztkwcg8o84@webmail.leidinger.net> Message-ID: <20071130124258.P56931@fledge.watson.org> References: <17978.194.74.82.3.1196407530.squirrel@galain.elvandar.org> <20071130101651.4h9nvpztkwcg8o84@webmail.leidinger.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Remko Lodder , freebsd-arch@FreeBSD.org Subject: Re: Removal of /etc/skel, your opinions please 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, 30 Nov 2007 12:44:26 -0000 On Fri, 30 Nov 2007, Alexander Leidinger wrote: > Quoting Remko Lodder (from Fri, 30 Nov 2007 08:25:30 > +0100 (CET)): > >> On Thu, November 29, 2007 10:47 am, Alexander Leidinger wrote: >>> Quoting Remko Lodder (from Wed, 28 Nov 2007 >>> 22:21:06 +0100): >>> >>>> Dear arch@ members, >>>> >>>> I would like to remove /etc/skel from the BSD.root.dist mtree file since >>>> it is no longer being used and I would like to remove unused items. > >>> Not an objection, just something to think about: Do we want to deprecate >>> the use of "adduser -k /etc/skel"? I know you said you just want to remove >>> the directory, and every admin is allowed to create it again, but by >>> removing the directory from the mtree file, we give a signal into the >>> direction of deprecation. > >> You do have a point there actually :-), what we can do in the install phase >> (initially "make distribution", later on when the system is already >> installed, manage this through "mergemaster") is install all files from >> /usr/share/skel to /etc/skel and actually use it. >> >> If we dont want to do that, why should we keep on carrying the directory >> then? > > I have a local patch to adduser which adds /usr/local/share/skel (so 2 > directories are used by default). Now I think it may be better to change > this to use /etc/skel instead, and to do it in a way that /etc/skel > overrides /usr/share/skel. Looks more usable to me. What do you think? Sounds like a quite reasonable argument could be made for having mergemaster install and manage /etc/skel so that when sites customize /etc/skel, mergemaster can be used to manage those customizations over time. Alternatively, mergemaster could manage /usr/share/skel. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-arch@FreeBSD.ORG Fri Nov 30 14:50:40 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DBEF416A417; Fri, 30 Nov 2007 14:50:40 +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 6EBBF13C43E; Fri, 30 Nov 2007 14:50:40 +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 lAUEodP9093313; Fri, 30 Nov 2007 08:50:39 -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 lAUEodVS093312; Fri, 30 Nov 2007 08:50:39 -0600 (CST) (envelope-from brooks) Date: Fri, 30 Nov 2007 08:50:38 -0600 From: Brooks Davis To: Robert Watson Message-ID: <20071130145038.GB87073@lor.one-eyed-alien.net> References: <17978.194.74.82.3.1196407530.squirrel@galain.elvandar.org> <20071130101651.4h9nvpztkwcg8o84@webmail.leidinger.net> <20071130124258.P56931@fledge.watson.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LpQ9ahxlCli8rRTG" Content-Disposition: inline In-Reply-To: <20071130124258.P56931@fledge.watson.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]); Fri, 30 Nov 2007 08:50:39 -0600 (CST) Cc: Alexander Leidinger , Remko Lodder , freebsd-arch@freebsd.org Subject: Re: Removal of /etc/skel, your opinions please 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, 30 Nov 2007 14:50:41 -0000 --LpQ9ahxlCli8rRTG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 30, 2007 at 12:44:18PM +0000, Robert Watson wrote: > On Fri, 30 Nov 2007, Alexander Leidinger wrote: >=20 >> Quoting Remko Lodder (from Fri, 30 Nov 2007 08:25:30= =20 >> +0100 (CET)): >>=20 >>> On Thu, November 29, 2007 10:47 am, Alexander Leidinger wrote: >>>> Quoting Remko Lodder (from Wed, 28 Nov 2007 >>>> 22:21:06 +0100): >>>>> Dear arch@ members, >>>>> I would like to remove /etc/skel from the BSD.root.dist mtree file=20 >>>>> since it is no longer being used and I would like to remove unused=20 >>>>> items. >>=20 >>>> Not an objection, just something to think about: Do we want to depreca= te=20 >>>> the use of "adduser -k /etc/skel"? I know you said you just want to=20 >>>> remove the directory, and every admin is allowed to create it again, b= ut=20 >>>> by removing the directory from the mtree file, we give a signal into t= he=20 >>>> direction of deprecation. >>=20 >>> You do have a point there actually :-), what we can do in the install= =20 >>> phase (initially "make distribution", later on when the system is alrea= dy=20 >>> installed, manage this through "mergemaster") is install all files from= =20 >>> /usr/share/skel to /etc/skel and actually use it. >>> If we dont want to do that, why should we keep on carrying the director= y=20 >>> then? >>=20 >> I have a local patch to adduser which adds /usr/local/share/skel (so 2= =20 >> directories are used by default). Now I think it may be better to change= =20 >> this to use /etc/skel instead, and to do it in a way that /etc/skel=20 >> overrides /usr/share/skel. Looks more usable to me. What do you think? >=20 > Sounds like a quite reasonable argument could be made for having=20 > mergemaster install and manage /etc/skel so that when sites customize=20 > /etc/skel, mergemaster can be used to manage those customizations over=20 > time. Alternatively, mergemaster could manage /usr/share/skel. I think that in addition to having "make distribution" populate /etc/skel we should change useradd to take files from there instead of or in addition to /usr/share/skel (I prefer "instead of" because at least two of the files in /usr/share/skel are useless for the 99.999% of unix users who don't read their mail with main(1)). -- Brooks [0] I've met one person who used main(1) with serious intent. --LpQ9ahxlCli8rRTG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFHUCM+XY6L6fI4GtQRAuf3AJ4hgJ0RYbFHIELQwyqnJK7P183/+wCeIZWm r+R7LK5ntAyQlFTN63XUVEg= =2T3D -----END PGP SIGNATURE----- --LpQ9ahxlCli8rRTG-- From owner-freebsd-arch@FreeBSD.ORG Fri Nov 30 19:57: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 0F9CB16A419; Fri, 30 Nov 2007 19:57: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 839E713C4F5; Fri, 30 Nov 2007 19:57:47 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A55984.dip.t-dialin.net [84.165.89.132]) by redbull.bpaserver.net (Postfix) with ESMTP id 917662E3AC; Fri, 30 Nov 2007 20:54:22 +0100 (CET) Received: from deskjail (deskjail.Leidinger.net [192.168.1.109]) by outgoing.leidinger.net (Postfix) with ESMTP id 581B0765ED; Fri, 30 Nov 2007 20:54:17 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1196452457; bh=8fwA3i7cqD3p3Ema2XPBaK12S2DGXs1QW FsxdCHt6Zc=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To: References:X-Mailer:Mime-Version:Content-Type: Content-Transfer-Encoding; b=m/p3BAsSofaVKP2sQZe4xhnbIEIjmW9RPHOWC QVU/DkLUrsnj7/jWbdy+MoF45QCxIY/Flne5gknXtduUHRSWbF+Hkx4tUnHJIsgnP3G PS6R9l/MwfWrhQnEEpIWWNzE8dnfdEfdNC9F6jrEMPECJ2hmPwvZQFeobqTTsZ0kkN2 pA+Jp0gM/wnOnGd5ZPQUZeJPq8m/Gql+sgENFBBrNK3lE7lXP5XZabp63NYUXwqjUpx /4PetGwGlNM1gq3Z9JjGRazJ4eL8qHYiRI4vnuac5gENZljz2LPt90t/pgHyf1jpI8/ GDE3K7hJEn6ObcBeYfI6aaLzwDKtxiYhpGIDA== Date: Fri, 30 Nov 2007 20:54:11 +0100 From: Alexander Leidinger To: Robert Watson Message-ID: <20071130205411.59046e41@deskjail> In-Reply-To: <20071130124258.P56931@fledge.watson.org> References: <17978.194.74.82.3.1196407530.squirrel@galain.elvandar.org> <20071130101651.4h9nvpztkwcg8o84@webmail.leidinger.net> <20071130124258.P56931@fledge.watson.org> 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.4, required 6, autolearn=not spam, BAYES_00 -15.00, DKIM_SIGNED 0.00, DKIM_VERIFIED -0.00, RDNS_DYNAMIC 0.10, SMILEY -0.50) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: Remko Lodder , freebsd-arch@FreeBSD.org Subject: Re: Removal of /etc/skel, your opinions please 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, 30 Nov 2007 19:57:48 -0000 Quoting Robert Watson (Fri, 30 Nov 2007 12:44:18 +0000 (GMT)): > On Fri, 30 Nov 2007, Alexander Leidinger wrote: > > > Quoting Remko Lodder (from Fri, 30 Nov 2007 08:25:30 > > +0100 (CET)): > > > >> On Thu, November 29, 2007 10:47 am, Alexander Leidinger wrote: > >>> Quoting Remko Lodder (from Wed, 28 Nov 2007 > >>> 22:21:06 +0100): > >>> > >>>> Dear arch@ members, > >>>> > >>>> I would like to remove /etc/skel from the BSD.root.dist mtree file since > >>>> it is no longer being used and I would like to remove unused items. > > > >>> Not an objection, just something to think about: Do we want to deprecate > >>> the use of "adduser -k /etc/skel"? I know you said you just want to remove > >>> the directory, and every admin is allowed to create it again, but by > >>> removing the directory from the mtree file, we give a signal into the > >>> direction of deprecation. > > > >> You do have a point there actually :-), what we can do in the install phase > >> (initially "make distribution", later on when the system is already > >> installed, manage this through "mergemaster") is install all files from > >> /usr/share/skel to /etc/skel and actually use it. > >> > >> If we dont want to do that, why should we keep on carrying the directory > >> then? > > > > I have a local patch to adduser which adds /usr/local/share/skel (so 2 > > directories are used by default). Now I think it may be better to change Ooops... I misremembered, the patch is not about -k, it adds plugins to adduser instead (execution of programs during the execution of adduser). > > this to use /etc/skel instead, and to do it in a way that /etc/skel > > overrides /usr/share/skel. Looks more usable to me. What do you think? > > Sounds like a quite reasonable argument could be made for having mergemaster > install and manage /etc/skel so that when sites customize /etc/skel, > mergemaster can be used to manage those customizations over time. > Alternatively, mergemaster could manage /usr/share/skel. Having /usr/share/skel managed my mergemaster is a little bit ... strange for me. I think I need to clarify what I wrote. My idea is to first look at /usr/share/skel and install those files, and then to look at /etc/skel and install these files. So if nobody changes something, you get the files we ship, and when you put a modification in /etc/skel, it will overwrite what was installed from /usr/share/skel. This doesn't handle the case where an admin removes a file from /usr/share/skel. This can be handled by putting such files with just a comment inside into /etc/skel. I looked at adduser.sh and it just gives the skel directory to pw, so pw needs to be changed for this. This way you wouldn't need to let mergemaster handle anything, as the installworld will install the /usr/share/skel part, and the admin can override what is installed. One drawback compared with the mergmaster handling is, that he has to look for changes himself in case he did only a small modification. I don't know about any complains from users regarding the current behavior in /usr/share/skel, so this small extension may be sufficient for us. I have no strong opinion about this part (often I use vipw instead of adduser for local users). Bye, Alexander. -- I'm mentally OVERDRAWN! What's that SIGNPOST up ahead? Where's ROD STERLING when you really need him? 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 30 22:32:18 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 A9B0916A468 for ; Fri, 30 Nov 2007 22:32:18 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.freebsd.org (Postfix) with ESMTP id 6725D13C469 for ; Fri, 30 Nov 2007 22:32:18 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id 7E555EBADA5; Sat, 1 Dec 2007 06:15:51 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id 5hdkyOzyBCXF; Sat, 1 Dec 2007 06:15:45 +0800 (CST) Received: from charlie.delphij.net (adsl-76-237-33-62.dsl.pltn13.sbcglobal.net [76.237.33.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 28724EB372B; Sat, 1 Dec 2007 06:15:43 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:subject:x-enigmail-version:content-type:content-transfer-encoding; b=WTL3ux3J+CvuML6dYc3FNY5E2KbIeddxklP57EHLAuwmK9ontAd/UL54lgl80FcJO svVyn8N0QDLtUrhzgXePA== Message-ID: <47508B81.4090705@delphij.net> Date: Fri, 30 Nov 2007 14:15:29 -0800 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: freebsd-arch@FreeBSD.org X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit Cc: Subject: "Rational" way of getting a number in human readable form? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2007 22:32:18 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, It seems that we have some code getenv_quad() that accepts numbers in "50M" "36G" alike form. Is it reasonable to add some sort of format characters to vsscanf(9) so that it would be able to handle this, or is it more appropriate to grow my own one? Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHUIuBhcUczkLqiksRAryZAKCqg9MeZtDzLElypUFJECr/fAANZwCgspwo E/dfG/16FdYaChVg8+4a/hs= =0Vo+ -----END PGP SIGNATURE----- From owner-freebsd-arch@FreeBSD.ORG Sat Dec 1 07:21: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 8840316A417 for ; Sat, 1 Dec 2007 07:21:30 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx09.syd.optusnet.com.au (fallbackmx09.syd.optusnet.com.au [211.29.132.242]) by mx1.freebsd.org (Postfix) with ESMTP id 6C81213C468 for ; Sat, 1 Dec 2007 07:21:29 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail18.syd.optusnet.com.au (mail18.syd.optusnet.com.au [211.29.132.199]) by fallbackmx09.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id lB11hqpq031653 for ; Sat, 1 Dec 2007 12:43:52 +1100 Received: from c211-30-219-213.carlnfd3.nsw.optusnet.com.au (c211-30-219-213.carlnfd3.nsw.optusnet.com.au [211.30.219.213]) by mail18.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id lB11haTC030163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 1 Dec 2007 12:43:39 +1100 Date: Sat, 1 Dec 2007 12:43:35 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: d@delphij.net In-Reply-To: <47508B81.4090705@delphij.net> Message-ID: <20071201121125.V15099@delplex.bde.org> References: <47508B81.4090705@delphij.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-arch@freebsd.org Subject: Re: "Rational" way of getting a number in human readable form? 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, 01 Dec 2007 07:21:30 -0000 On Fri, 30 Nov 2007, Xin LI wrote: > It seems that we have some code getenv_quad() that accepts numbers in > "50M" "36G" alike form. Is it reasonable to add some sort of format > characters to vsscanf(9) so that it would be able to handle this, or is > it more appropriate to grow my own one? No. The scanf family shouldn't exist except for compatibility in userland, since it gives uncontrollable undefined behaviour on numeric overflow, so it is unusable except for reading certain character data. The strto*() family should be used for reading numeric data. Unfortunately, strtol(9) has a broken API -- errno doesn't exist in the kernel, but the strto*() family depends on it for reporting overflow. getenv_quad() has its own overflow bugs (blind multiplication by the scale factors...) and shouldn't exist for other reasons. Bruce From owner-freebsd-arch@FreeBSD.ORG Sat Dec 1 22:19:07 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 B13E816A419 for ; Sat, 1 Dec 2007 22:19:07 +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 4B1B713C442 for ; Sat, 1 Dec 2007 22:19:07 +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 C79FB17105 for ; Sat, 1 Dec 2007 22:19:05 +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 lB1MJ5wA015392 for ; Sat, 1 Dec 2007 22:19:05 GMT (envelope-from phk@critter.freebsd.dk) To: arch@freebsd.org From: Poul-Henning Kamp Date: Sat, 01 Dec 2007 22:19:05 +0000 Message-ID: <15391.1196547545@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Subject: New "timeout" api, to replace callout 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, 01 Dec 2007 22:19:07 -0000 Here is my proposed new timeout API for 8.x. The primary objective is to make it possible to have multiple timeout "providers" of possibly different kind, so that we can have per-cpu or per-net-stack timeout handing. A secondary goal, is to shove the anti-race handling in destruction of timeouts back into the implemenation, rather than force users to spend 20+ lines doing that. A third goal is to enable deadline scheduling of timeouts using hardware like HPET when and where we have it. Comments in general (only B/W) and pointers to client code of particular interest is most welcome. Poul-Henning PS: I decided to revert to the old "timeout" prefix, so that we avoid redefining anything and can coexist with the callout_ API as long as necessary. /*- * Copyright (c) 2007 Poul-Henning Kamp * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * * $FreeBSD$ */ #ifndef _SYS_TIMEOUT_H_ #define _SYS_TIMEOUT_H_ /* * A provider of timeout services, opaque to users. * We are likely to have a "default" provider and possibly one for * each cpu, but subsystems might have their own provider instances as well. */ struct timeout_p; /* * A duration of time, represented in the optimal way for a given provider * or family of providers (ie: per cpu). */ typedef int timeout_time; /* * An instance of a timeout */ struct timeout; /* * Flag values, * can be used as return from the function or as argument to timeout_arm() */ #define TIMEOUT_REARM (1<<0) /* return: Rearm with timeout from last arming */ /* return + timeout_arm(): Likely to be rearmed when firing */ #define TIMEOUT_SAFE (1<<1) /* return: Do not rearm */ /* timeout_arm: Not likely to be rearmed when firing */ #define TIMEOUT_RETURNUNLOCKED (1<<2) /* return: released lock along the way */ #define TIMEOUT_UNLIKELY (1<<3) /* timeout_arm: Unlikely to fire before safed */ /* * The function prototype for timeout functions. * A mutex will be held over the call to this function, preventing * accidental use of msleep(9) and similar. * Calling timeout_arm() on itself is legal. * Manipulating other timeouts is illegal, (until documented need.) */ typedef int timeout_f(struct timeout *, void *priv); /* * The struct is defined here, so that allocations can be made at * compile-time as part of softc's etc. * No user-serviceable parts inside. */ struct timeout { timeout_p *_prov; timeout_time _time; timeout_f *_func; void *_priv; uintptr_t _reserved[4]; /* XXX: for some value of 4 */ }; /* * Convert various human compatible time-units to internal units * Since these are potentially expensive (as in multiple integer divisions) * caching the return value is adviced for heavy use. * Choice of function indicates level of precision requested, so * timeout_ms_time(1000) may be different from timeout_s_time(1), depending * on the implementation. */ timeout_time timeout_ns_time(struct timeout_p *, unsigned nsec); timeout_time timeout_us_time(struct timeout_p *, unsigned usec); timeout_time timeout_ms_time(struct timeout_p *, unsigned msec); timeout_time timeout_s_time(struct timeout_p *, unsigned sec); /* * Initialize a timeout to safed state. * Call timeout_cleanup() before calling again. */ void timeout_init(struct timeout_p *, struct timeout *, struct lock_object *, timeout_f *, void *); /* * Arm the timeout. * If timeout is already running, ignore its return value and any * timeout_arm() calls it makes on itself and wait (on a mutex) for it to * return. * The timeout will be armed with the parameters given on return. */ void timeout_arm(struct timeout *, timeout_time, int flags); /* * Safe the timeout. * If timeout is already running, ignore its return value and any * timeout_arm() calls it makes on itself and wait (on a mutex) for it to * return. * The timeout will always be safed on return. */ void timeout_safe(struct timeout *); /* * Cleanup the timeout. * Should always be called on any timeout ever armed. * Can be called on any timeout which have been init'ed. * Will timeout_safe the timeout if armed. * The memory backing the argument structure and the lock registered with * timeout_init() can be safely destroyed on return. */ void timeout_cleanup(struct timeout *); #endif /* _SYS_TIMEOUT_H_ */ -- 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.