From owner-freebsd-arch@FreeBSD.ORG Sun Aug 24 00:05:08 2008 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 2CA861065714 for ; Sun, 24 Aug 2008 00:05:08 +0000 (UTC) (envelope-from freebsd-arch@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id DFD338FC08 for ; Sun, 24 Aug 2008 00:05:07 +0000 (UTC) (envelope-from freebsd-arch@m.gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1KX36M-0005eD-7X for freebsd-arch@freebsd.org; Sun, 24 Aug 2008 00:05:02 +0000 Received: from 78-1-71-103.adsl.net.t-com.hr ([78.1.71.103]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 24 Aug 2008 00:05:02 +0000 Received: from ivoras by 78-1-71-103.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 24 Aug 2008 00:05:02 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-arch@freebsd.org From: Ivan Voras Date: Sun, 24 Aug 2008 02:04:18 +0200 Lines: 27 Message-ID: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig9BB1D000B3FF5E2AF9225758" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 78-1-71-103.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) X-Enigmail-Version: 0.95.7 Sender: news Subject: FreeBSD and DEP aka "NX bit"? 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, 24 Aug 2008 00:05:08 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9BB1D000B3FF5E2AF9225758 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I stumbled upon this Wikipedia page: http://en.wikipedia.org/wiki/Comparison_of_BSD_operating_systems#Security= _features and it mentions NX bit is supported in FreeBSD. Is this true? Is it enabled by default? --------------enig9BB1D000B3FF5E2AF9225758 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiwpYIACgkQldnAQVacBcgJwACg7EIZWgJKjDiFxisNS5oi8eAS bmEAoPUx8jpeJOJQ7AiYUXg6Bi1xU7mH =uWfx -----END PGP SIGNATURE----- --------------enig9BB1D000B3FF5E2AF9225758-- From owner-freebsd-arch@FreeBSD.ORG Sun Aug 24 00:41:03 2008 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 6F8E4106569D for ; Sun, 24 Aug 2008 00:41:03 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.225]) by mx1.freebsd.org (Postfix) with ESMTP id 457C48FC1C for ; Sun, 24 Aug 2008 00:41:03 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so1762777rvf.43 for ; Sat, 23 Aug 2008 17:41:02 -0700 (PDT) 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=H76XoxMXKlXq6CtXaXGdlgtZ7FCOjIFOYUzOhGVeZNs=; b=Rt/giRq0F0EpXxF5qZwZLNA1v62N8mP7UqXMEAXO47aiYjUZHaJzhMwKUv13kDUfHc 7lvED+T+9HFEqNzOh4Oj2wyb6BJy044+eFsQylAAVjJ1pWi6vpV88b59aJQ6ItW2PxiZ 11khd/Ihnt7Qhc56llxCpznIbRkkHOXAOp6f8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=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=hiaK7CuxPULF1VAx4Yd1AqNVV2eMKI0Hcx1mxhNQoMBRdO7i/UYCxyKO896QT6NQHv bOEloI8ihcAQAHcd/U1R8uJFWFahRdtsug2qu1UXgeHDSLPdqCE3cdqiFlHZpdfBz3SS pd4UzbniXu/I/qoYgSjs3x4DLyQPv9+f7kRog= Received: by 10.141.106.14 with SMTP id i14mr1351042rvm.152.1219538462782; Sat, 23 Aug 2008 17:41:02 -0700 (PDT) Received: by 10.141.153.13 with HTTP; Sat, 23 Aug 2008 17:41:02 -0700 (PDT) Message-ID: <9bbcef730808231741o5e765f3bh546475b28fe51f9b@mail.gmail.com> Date: Sun, 24 Aug 2008 02:41:02 +0200 From: "Ivan Voras" Sender: ivoras@gmail.com To: "Matthew Macy" In-Reply-To: <3c1674c90808231713x47e42de5oa9fc2f2f244d2e74@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3c1674c90808231713x47e42de5oa9fc2f2f244d2e74@mail.gmail.com> X-Google-Sender-Auth: 56a08b51e1d7f889 Cc: freebsd-arch@freebsd.org Subject: Re: FreeBSD and DEP aka "NX bit"? 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, 24 Aug 2008 00:41:03 -0000 2008/8/24 Matthew Macy : > On Sat, Aug 23, 2008 at 5:04 PM, Ivan Voras wrote: >> I stumbled upon this Wikipedia page: >> http://en.wikipedia.org/wiki/Comparison_of_BSD_operating_systems#Security_features >> and it mentions NX bit is supported in FreeBSD. Is this true? Is it >> enabled by default? > > Yes. However, it is in the upper word so it only works with PAE or > amd64. "jemalloc" maps the heap NX and thread stacks are mapped NX. > The default process stack currently needs to be executable because > sigcode is placed at the start of the stack at the time of process > creation. Thanks! How useful is it without protecting the default stack? IIRC wasn't stack protection one of the main (marketed) bonuses for NX? (I'm thinking of the majority of currently popular server software like apache (preforked) and PostgreSQL...) From owner-freebsd-arch@FreeBSD.ORG Sun Aug 24 00:43:02 2008 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 3BC1E1065688 for ; Sun, 24 Aug 2008 00:43:02 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by mx1.freebsd.org (Postfix) with ESMTP id 17DA88FC18 for ; Sun, 24 Aug 2008 00:43:01 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so1763444rvf.43 for ; Sat, 23 Aug 2008 17:43:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=ew2GUGjz9Po/UesA8264SqzycVywhMCoJl05azC5eOU=; b=Ju+nP5EDU+9BJTHhdqZFGfx5XbqWrka4wSTu5rc8XTwJPaMYD8DAVcS+GkyEX/k4jz hf1lmMP8rdhLfFOuNl7qDTNIGZNTRFeCFSKMD92X/xW3cdd4VKlyVaCWqD15hBAgBue/ 7XV2YQe12QTVFCn0kGStGWHCVc8mB1oGqx8FU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=g3cc0/ndB2IMExyB9CDDDqRkusdc2yNNdn5ZBsEl6MgRIn9oGW4lwDN5dx7e4oqOCk ArM+nQqQ4Feq99Hi8HaxO+ufUnjKr1irz3jomsijaYGYapJFkousGmNMjNZNBjguqsVf Vm1ct15PRyoAFI2O5Je4nU5WCpHrIFLGTEll4= Received: by 10.140.170.12 with SMTP id s12mr1350367rve.83.1219536810357; Sat, 23 Aug 2008 17:13:30 -0700 (PDT) Received: by 10.141.101.21 with HTTP; Sat, 23 Aug 2008 17:13:30 -0700 (PDT) Message-ID: <3c1674c90808231713x47e42de5oa9fc2f2f244d2e74@mail.gmail.com> Date: Sat, 23 Aug 2008 17:13:30 -0700 From: "Matthew Macy" To: "Ivan Voras" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Cc: freebsd-arch@freebsd.org Subject: Re: FreeBSD and DEP aka "NX bit"? 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, 24 Aug 2008 00:43:02 -0000 On Sat, Aug 23, 2008 at 5:04 PM, Ivan Voras wrote: > I stumbled upon this Wikipedia page: > http://en.wikipedia.org/wiki/Comparison_of_BSD_operating_systems#Security_features > and it mentions NX bit is supported in FreeBSD. Is this true? Is it > enabled by default? Yes. However, it is in the upper word so it only works with PAE or amd64. "jemalloc" maps the heap NX and thread stacks are mapped NX. The default process stack currently needs to be executable because sigcode is placed at the start of the stack at the time of process creation. -Kip From owner-freebsd-arch@FreeBSD.ORG Sun Aug 24 00:51:08 2008 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 C81B91065684 for ; Sun, 24 Aug 2008 00:51:08 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.231]) by mx1.freebsd.org (Postfix) with ESMTP id A091D8FC21 for ; Sun, 24 Aug 2008 00:51:08 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so1766273rvf.43 for ; Sat, 23 Aug 2008 17:51:07 -0700 (PDT) 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=eBiHuy0zueW6kV/WXAYUMNMLL4x+coNbGJH8mLCTik8=; b=knwoVcRXxPNYbrzzgAbDqDokYit2IbWEnAcI4IluGHaR6GB+GZom1bpnBB0nLIWdoK 6TqmFxGEdxyQMdrDj9Sbq4oV1kqzMM6/srOHYSNNNxaChNwax4aqD9BMv8m7JX0Dc96W cah5Wa7fyyg181/FDRiVIYkbdM8pOW8tr2u20= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=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=kgmVcP5AvFZLtWYjJ7EgBPUO8AoGPBcbRvICLCMHkiZdaUA6m4TkaN1I2IemrKExDD 0W4xkexS1x+c8bC1doAsb41iaEbIkFITpBxa+kAbkla5dSJ346I82MZvM15TZky3M5pr 5J/Fwrv4vG8Dk/RnjvrS1edOj6l5vQRrSsDiY= Received: by 10.141.29.21 with SMTP id g21mr1342861rvj.248.1219539067799; Sat, 23 Aug 2008 17:51:07 -0700 (PDT) Received: by 10.141.101.21 with HTTP; Sat, 23 Aug 2008 17:51:07 -0700 (PDT) Message-ID: <3c1674c90808231751h3d11d52at2eac1eb21cd8940b@mail.gmail.com> Date: Sat, 23 Aug 2008 17:51:07 -0700 From: "Kip Macy" Sender: mat.macy@gmail.com To: "Ivan Voras" In-Reply-To: <9bbcef730808231741o5e765f3bh546475b28fe51f9b@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3c1674c90808231713x47e42de5oa9fc2f2f244d2e74@mail.gmail.com> <9bbcef730808231741o5e765f3bh546475b28fe51f9b@mail.gmail.com> X-Google-Sender-Auth: 03fe686ac1e7b6b7 Cc: freebsd-arch@freebsd.org Subject: Re: FreeBSD and DEP aka "NX bit"? 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, 24 Aug 2008 00:51:08 -0000 On Sat, Aug 23, 2008 at 5:41 PM, Ivan Voras wrote: > 2008/8/24 Matthew Macy : >> On Sat, Aug 23, 2008 at 5:04 PM, Ivan Voras wrote: >>> I stumbled upon this Wikipedia page: >>> http://en.wikipedia.org/wiki/Comparison_of_BSD_operating_systems#Security_features >>> and it mentions NX bit is supported in FreeBSD. Is this true? Is it >>> enabled by default? >> >> Yes. However, it is in the upper word so it only works with PAE or >> amd64. "jemalloc" maps the heap NX and thread stacks are mapped NX. >> The default process stack currently needs to be executable because >> sigcode is placed at the start of the stack at the time of process >> creation. > > Thanks! > > How useful is it without protecting the default stack? IIRC wasn't > stack protection one of the main (marketed) bonuses for NX? (I'm > thinking of the majority of currently popular server software like > apache (preforked) and PostgreSQL...) FreeBSD could certainly take better advantage of it. It also doesn't help that the default process stack always starts at the same address. However, SSP does mitigate some of the risk. -Kip From owner-freebsd-arch@FreeBSD.ORG Mon Aug 25 04:28:54 2008 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 27D3E106566B; Mon, 25 Aug 2008 04:28:54 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from smtp13.yandex.ru (smtp13.yandex.ru [77.88.32.83]) by mx1.freebsd.org (Postfix) with ESMTP id 769D78FC0C; Mon, 25 Aug 2008 04:28:52 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from mail.kirov.so-cdu.ru ([77.72.136.145]:24567 "EHLO [127.0.0.1]" smtp-auth: "bu7cher" TLS-CIPHER: "DHE-RSA-AES256-SHA keybits 256/256 version TLSv1/SSLv3" TLS-PEER-CN1: ) by mail.yandex.ru with ESMTP id S1820148AbYHYE2l (ORCPT + 5 others); Mon, 25 Aug 2008 08:28:41 +0400 X-Yandex-Spam: 1 X-Yandex-Front: smtp13 X-Yandex-TimeMark: 1219638521 X-MsgDayCount: 9 X-Comment: RFC 2476 MSA function at smtp13.yandex.ru logged sender identity as: bu7cher Message-ID: <48B234F7.8070407@yandex.ru> Date: Mon, 25 Aug 2008 08:28:39 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: "M. Warner Losh" References: <20080823013912.GA19588@epsilon.local> <20080822.200511.1137957320.imp@bsdimp.com> <200808222241.52325.jhb@freebsd.org> <20080822.224404.691670281.imp@bsdimp.com> In-Reply-To: <20080822.224404.691670281.imp@bsdimp.com> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: brooks@FreeBSD.org, rpaulo@FreeBSD.org, jhb@FreeBSD.org, ivoras@FreeBSD.org, brueffer@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: Magic symlinks redux 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, 25 Aug 2008 04:28:54 -0000 M. Warner Losh wrote: > : The lookup table you have still requires patching source somewhere which > : probably defeats the purpose. > > That's the whole "less lame of getting data into the kernel" I was > talking about. The above was to show the concept, not an actual > implementation of the data. I don't like the hint idea so much, but > was looking for some other way to get the data into the kernel. What is about extending pciconf(8) (or making a pcictl(8) alias) for this purposes? -- WBR, Andrey V. Elsukov From owner-freebsd-arch@FreeBSD.ORG Mon Aug 25 04:43:59 2008 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 1C17C1065671; Mon, 25 Aug 2008 04:43:59 +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 EB5BE8FC0C; Mon, 25 Aug 2008 04:43:58 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m7P4gALD030655; Sun, 24 Aug 2008 22:42:10 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 24 Aug 2008 22:42:39 -0600 (MDT) Message-Id: <20080824.224239.-4055712.imp@bsdimp.com> To: bu7cher@yandex.ru From: "M. Warner Losh" In-Reply-To: <48B234F7.8070407@yandex.ru> References: <200808222241.52325.jhb@freebsd.org> <20080822.224404.691670281.imp@bsdimp.com> <48B234F7.8070407@yandex.ru> 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: brooks@FreeBSD.org, rpaulo@FreeBSD.org, jhb@FreeBSD.org, ivoras@FreeBSD.org, brueffer@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: Magic symlinks redux 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, 25 Aug 2008 04:43:59 -0000 In message: <48B234F7.8070407@yandex.ru> "Andrey V. Elsukov" writes: : M. Warner Losh wrote: : > : The lookup table you have still requires patching source somewhere which : > : probably defeats the purpose. : > : > That's the whole "less lame of getting data into the kernel" I was : > talking about. The above was to show the concept, not an actual : > implementation of the data. I don't like the hint idea so much, but : > was looking for some other way to get the data into the kernel. : : What is about extending pciconf(8) (or making a pcictl(8) alias) for : this purposes? Lots of things could... However, pciconf(8) likely runs too late... Warner From owner-freebsd-arch@FreeBSD.ORG Mon Aug 25 04:50:32 2008 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 D8F591065685; Mon, 25 Aug 2008 04:50:32 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from smtp14.yandex.ru (smtp14.yandex.ru [77.88.32.84]) by mx1.freebsd.org (Postfix) with ESMTP id D08FE8FC14; Mon, 25 Aug 2008 04:50:31 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from ns.kirov.so-cdu.ru ([77.72.136.145]:2553 "EHLO [127.0.0.1]" smtp-auth: "bu7cher" TLS-CIPHER: "DHE-RSA-AES256-SHA keybits 256/256 version TLSv1/SSLv3" TLS-PEER-CN1: ) by mail.yandex.ru with ESMTP id S5178776AbYHYEuY (ORCPT + 2 others); Mon, 25 Aug 2008 08:50:24 +0400 X-Yandex-Spam: 1 X-Yandex-Front: smtp14 X-Yandex-TimeMark: 1219639824 X-MsgDayCount: 12 X-Comment: RFC 2476 MSA function at smtp14.yandex.ru logged sender identity as: bu7cher Message-ID: <48B23A0E.1030700@yandex.ru> Date: Mon, 25 Aug 2008 08:50:22 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Ivan Voras References: <20080822150020.GA57443@lor.one-eyed-alien.net> <9bbcef730808220802pa84b597u457100a23b03a80c@mail.gmail.com> <20080822153945.GC57443@lor.one-eyed-alien.net> <9bbcef730808220853q22666b44n5ca2b7add991191f@mail.gmail.com> In-Reply-To: <9bbcef730808220853q22666b44n5ca2b7add991191f@mail.gmail.com> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: Brooks Davis , freebsd-arch@freebsd.org Subject: Re: Magic symlinks redux 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, 25 Aug 2008 04:50:32 -0000 Ivan Voras wrote: > Firstly, it might be useless for your purpose but there are others. > > If you read the NetBSD's documentation about magiclinks, you'll see > this set of supported variables: Originally I wanted to implement 4 layers: 1. System-wide (jail-wide)(global for all jails etc). Only root can set variables in this layer. 2. Kernel-wide. Variables in this layer can be set from KLD's. Some KPI needed for setting these variables (also all netbsd-like variables can be implemented in this layer). Superuser can override these variables via system-wide layer. 3. Per-user. 4. Per-process. -- WBR, Andrey V. Elsukov From owner-freebsd-arch@FreeBSD.ORG Mon Aug 25 06:26:18 2008 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 6BB381065675; Mon, 25 Aug 2008 06:26:18 +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 27A558FC14; Mon, 25 Aug 2008 06:26:18 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m7P6Mkco032343; Mon, 25 Aug 2008 00:22:46 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 25 Aug 2008 00:23:16 -0600 (MDT) Message-Id: <20080825.002316.-1548243307.imp@bsdimp.com> To: net@freebsd.org, 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: Multipart/Mixed; boundary="--Next_Part(Mon_Aug_25_00_23_16_2008_044)--" Content-Transfer-Encoding: 7bit Cc: Subject: Code review 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, 25 Aug 2008 06:26:18 -0000 ----Next_Part(Mon_Aug_25_00_23_16_2008_044)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit I did this a few years ago when trying to track down a problem with some realtek network chips that I was having problems with at Timing Solutions. I'd like to get this into the tree, since it was helpful then. Comments? Warner ----Next_Part(Mon_Aug_25_00_23_16_2008_044)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="rl.diff" diff -ur src/sys/pci/if_rl.c newcard/src/sys/pci/if_rl.c --- src/sys/pci/if_rl.c 2008-08-23 22:21:15.000000000 -0600 +++ newcard/src/sys/pci/if_rl.c 2008-08-23 22:26:09.000000000 -0600 @@ -1253,18 +1253,120 @@ } static void +rl_twister_update(struct rl_softc *sc) +{ + uint16_t linktest; + static const uint32_t param[4][4] = { + {0xcb39de43, 0xcb39ce43, 0xfb38de03, 0xcb38de43}, + {0xcb39de43, 0xcb39ce43, 0xcb39ce83, 0xcb39ce83}, + {0xcb39de43, 0xcb39ce43, 0xcb39ce83, 0xcb39ce83}, + {0xbb39de43, 0xbb39ce43, 0xbb39ce83, 0xbb39ce83} + }; + + /* + * Tune the so-called twister registers of the RTL8139. These + * are used to compensate for impendence mismatches. The + * method for tuning these registes is undocumented and the + * following proceedure is collected from public sources. + */ + switch (sc->rl_twister) + { + case CHK_LINK: + /* + * If we have a sufficent link, then we can proceed in + * the state machine to the next stage. If not, then + * disable further tuning after writing sane defaults. + */ + if (CSR_READ_2(sc, RL_CSCFG) & RL_CSCFG_LINK_OK) { + CSR_WRITE_2(sc, RL_CSCFG, RL_CSCFG_LINK_DOWN_OFF_CMD); + sc->rl_twister = FIND_ROW; + } else { + CSR_WRITE_2(sc, RL_CSCFG, RL_CSCFG_LINK_DOWN_CMD); + CSR_WRITE_4(sc, RL_NWAYTST, RL_NWAYTST_CBL_TEST); + CSR_WRITE_4(sc, RL_PARA78, RL_PARA78_DEF); + CSR_WRITE_4(sc, RL_PARA7C, RL_PARA7C_DEF); + sc->rl_twister = DONE; + } + break; + case FIND_ROW: + /* + * Read how long it took to see the echo to find the tuning + * row to use. + */ + linktest = CSR_READ_2(sc, RL_CSCFG) & RL_CSCFG_STATUS; + if (linktest == RL_CSCFG_ROW3) + sc->rl_twist_row = 3; + else if (linktest == RL_CSCFG_ROW2) + sc->rl_twist_row = 2; + else if (linktest == RL_CSCFG_ROW1) + sc->rl_twist_row = 1; + else + sc->rl_twist_row = 0; + sc->rl_twist_col = 0; + sc->rl_twister = SET_PARAM; + break; + case SET_PARAM: + if (sc->rl_twist_col == 0) + CSR_WRITE_4(sc, RL_NWAYTST, RL_NWAYTST_RESET); + CSR_WRITE_4(sc, RL_PARA7C, + param[sc->rl_twist_row][sc->rl_twist_col]); + if (++sc->rl_twist_col == 4) { + if (sc->rl_twist_row == 3) + sc->rl_twister = RECHK_LONG; + else + sc->rl_twister = DONE; + } + break; + case RECHK_LONG: + /* + * For long cables, we have to double check to make sure we + * don't mistune. + */ + linktest = CSR_READ_2(sc, RL_CSCFG) & RL_CSCFG_STATUS; + if (linktest == RL_CSCFG_ROW3) + sc->rl_twister = DONE; + else { + CSR_WRITE_4(sc, RL_PARA7C, RL_PARA7C_RETUNE); + sc->rl_twister = RETUNE; + } + break; + case RETUNE: + /* Retune for a shorter cable (try column 2) */ + CSR_WRITE_4(sc, RL_NWAYTST, RL_NWAYTST_CBL_TEST); + CSR_WRITE_4(sc, RL_PARA78, RL_PARA78_DEF); + CSR_WRITE_4(sc, RL_PARA7C, RL_PARA7C_DEF); + CSR_WRITE_4(sc, RL_NWAYTST, RL_NWAYTST_RESET); + sc->rl_twist_row--; + sc->rl_twist_col = 0; + sc->rl_twister = SET_PARAM; + break; + + case DONE: + break; + } + +} + +static void rl_tick(void *xsc) { struct rl_softc *sc = xsc; struct mii_data *mii; + int ticks; RL_LOCK_ASSERT(sc); mii = device_get_softc(sc->rl_miibus); mii_tick(mii); + if (sc->rl_twister != DONE) + rl_twister_update(sc); + if (sc->rl_twister != DONE) + ticks = hz / 10; + else + ticks = hz; rl_watchdog(sc); - callout_reset(&sc->rl_stat_callout, hz, rl_tick, sc); + callout_reset(&sc->rl_stat_callout, ticks, rl_tick, sc); } #ifdef DEVICE_POLLING @@ -1490,6 +1592,13 @@ rl_stop(sc); /* + * Reset twister register tuning state. The twister registers + * and their tuning are undocumented, but are necessary to cope + * with bad links. rl_twister = DONE here will disable this entirely. + */ + sc->rl_twister = CHK_LINK; + + /* * Init our MAC address. Even though the chipset * documentation doesn't mention it, we need to enter "Config * register write enable" mode to modify the ID registers. diff -ur src/sys/pci/if_rlreg.h newcard/src/sys/pci/if_rlreg.h --- src/sys/pci/if_rlreg.h 2008-08-23 22:21:15.000000000 -0600 +++ newcard/src/sys/pci/if_rlreg.h 2008-08-23 22:26:09.000000000 -0600 @@ -309,6 +309,27 @@ #define RL_CMD_RESET 0x0010 /* + * Twister register values. These are completely undocumented and derived + * from public sources. + */ +#define RL_CSCFG_LINK_OK 0x0400 +#define RL_CSCFG_CHANGE 0x0800 +#define RL_CSCFG_STATUS 0xf000 +#define RL_CSCFG_ROW3 0x7000 +#define RL_CSCFG_ROW2 0x3000 +#define RL_CSCFG_ROW1 0x1000 +#define RL_CSCFG_LINK_DOWN_OFF_CMD 0x03c0 +#define RL_CSCFG_LINK_DOWN_CMD 0xf3c0 + +#define RL_NWAYTST_RESET 0 +#define RL_NWAYTST_CBL_TEST 0x20 + +#define RL_PARA78 0x78 +#define RL_PARA78_DEF 0x78fa8388 +#define RL_PARA7C 0x7C +#define RL_PARA7C_DEF 0xcb38de43 +#define RL_PARA7C_RETUNE 0xfb38de03 +/* * EEPROM control register */ #define RL_EE_DATAOUT 0x01 /* Data out */ @@ -801,6 +822,8 @@ bus_addr_t rl_tx_list_addr; }; +enum rl_twist { DONE, CHK_LINK, FIND_ROW, SET_PARAM, RECHK_LONG, RETUNE }; + struct rl_softc { struct ifnet *rl_ifp; /* interface info */ bus_space_handle_t rl_bhandle; /* bus space handle */ @@ -830,6 +853,9 @@ uint32_t rl_rxlenmask; int rl_testmode; int rl_if_flags; + enum rl_twist rl_twister; + int rl_twist_row; + int rl_twist_col; int suspended; /* 0 = normal 1 = suspended */ #ifdef DEVICE_POLLING int rxcycles; @@ -850,6 +876,8 @@ #define RL_FLAG_LINK 0x8000 }; + + #define RL_LOCK(_sc) mtx_lock(&(_sc)->rl_mtx) #define RL_UNLOCK(_sc) mtx_unlock(&(_sc)->rl_mtx) #define RL_LOCK_ASSERT(_sc) mtx_assert(&(_sc)->rl_mtx, MA_OWNED) ----Next_Part(Mon_Aug_25_00_23_16_2008_044)---- From owner-freebsd-arch@FreeBSD.ORG Mon Aug 25 06:27:06 2008 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 978BE1065677 for ; Mon, 25 Aug 2008 06:27:06 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.freebsd.org (Postfix) with ESMTP id 847F68FC39 for ; Mon, 25 Aug 2008 06:27:06 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.14.1/8.14.1) with ESMTP id m7P6Gw7I055071 for ; Sun, 24 Aug 2008 23:16:58 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.14.1/8.13.4/Submit) id m7P6GwEa055070; Sun, 24 Aug 2008 23:16:58 -0700 (PDT) Date: Sun, 24 Aug 2008 23:16:58 -0700 (PDT) From: Matthew Dillon Message-Id: <200808250616.m7P6GwEa055070@apollo.backplane.com> To: freebsd-arch@freebsd.org References: <20080822150020.GA57443@lor.one-eyed-alien.net> <9bbcef730808220802pa84b597u457100a23b03a80c@mail.gmail.com> <20080822153945.GC57443@lor.one-eyed-alien.net> <9bbcef730808220853q22666b44n5ca2b7add991191f@mail.gmail.com> <48B23A0E.1030700@yandex.ru> Subject: Re: Magic symlinks redux 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, 25 Aug 2008 06:27:06 -0000 The only issue we hit with per-process varsyms is that to really be useful the shells need built-ins to set the process-space variables, since doing so as an exec'd subprocess will not effect the shell or its children. We have no plans to allow one process to modify another process's varsyms as that would cause significant security issues. In fact, even the per-user variables might have security issues (e.g. common-run 'nobody' user utilities, and so forth, for which a pseudo-userid has not been created). I'm kinda thinking of removing per-user variables despite the usefulness. There have been various circumstances where we've thought varsyms would be useful, but ended up not needing to use them. Right now we are looking at possibly using them to point /usr/lib and friends to select 32 or 64 bit ABI library paths, and have the kernel automatically set a varsym when exec'ing an ELF program to the program's ABI. Doing this would allow 32 and 64 bit program, library, and package sets to be run and maintained side-by-side. -Matt From owner-freebsd-arch@FreeBSD.ORG Mon Aug 25 07:13:59 2008 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 57921106566B; Mon, 25 Aug 2008 07:13:59 +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 16BE88FC15; Mon, 25 Aug 2008 07:13:59 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m7P7Cg4n032913; Mon, 25 Aug 2008 01:12:42 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 25 Aug 2008 01:13:12 -0600 (MDT) Message-Id: <20080825.011312.-1956307484.imp@bsdimp.com> To: arch@FreeBSD.org, ru@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: using ${.TARGET} instead of opt_*.h 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, 25 Aug 2008 07:13:59 -0000 I was cleaning out my tree, and noticed that I took a stab at solving the problem opt_*.h being explicitly named in rules rather than ${.TARGET} when building modules. Comments? Warner From owner-freebsd-arch@FreeBSD.ORG Mon Aug 25 07:16:59 2008 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 02E02106566B; Mon, 25 Aug 2008 07:16:59 +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 8999C8FC12; Mon, 25 Aug 2008 07:16:58 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m7P7Ei5c032983; Mon, 25 Aug 2008 01:14:44 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 25 Aug 2008 01:15:13 -0600 (MDT) Message-Id: <20080825.011513.-432836673.imp@bsdimp.com> To: arch@freebsd.org, ru@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: Multipart/Mixed; boundary="--Next_Part(Mon_Aug_25_01_15_13_2008_547)--" Content-Transfer-Encoding: 7bit Cc: Subject: Code review: using ${.TARGET} instead of opt_*.h 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, 25 Aug 2008 07:16:59 -0000 ----Next_Part(Mon_Aug_25_01_15_13_2008_547)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit [[ resent with attachment]] I was cleaning out my tree, and noticed that I took a stab at solving the problem opt_*.h being explicitly named in rules rather than ${.TARGET} when building modules. Comments? Warner ----Next_Part(Mon_Aug_25_01_15_13_2008_547)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="make-target.diff" Index: wlan_wep/Makefile =================================================================== --- wlan_wep/Makefile (revision 182150) +++ wlan_wep/Makefile (working copy) @@ -8,7 +8,7 @@ .if !defined(KERNBUILDDIR) opt_wlan.h: - echo "#define IEEE80211_DEBUG 1" > opt_wlan.h + echo "#define IEEE80211_DEBUG 1" > ${.TARGET} .endif .include Index: wlan_amrr/Makefile =================================================================== --- wlan_amrr/Makefile (revision 182150) +++ wlan_amrr/Makefile (working copy) @@ -8,7 +8,7 @@ .if !defined(KERNBUILDDIR) opt_wlan.h: - echo "#define IEEE80211_DEBUG 1" > opt_wlan.h + echo "#define IEEE80211_DEBUG 1" > ${.TARGET} .endif .include Index: digi/digi/Makefile =================================================================== --- digi/digi/Makefile (revision 182150) +++ digi/digi/Makefile (working copy) @@ -9,8 +9,8 @@ .if !defined(KERNBUILDDIR) opt_compat.h: - echo "#define COMPAT_43 1" > opt_compat.h - echo "#define COMPAT_FREEBSD6 1" >> opt_compat.h + echo "#define COMPAT_43 1" > ${.TARGET} + echo "#define COMPAT_FREEBSD6 1" >> ${.TARGET} .endif .include Index: wlan_acl/Makefile =================================================================== --- wlan_acl/Makefile (revision 182150) +++ wlan_acl/Makefile (working copy) @@ -8,7 +8,7 @@ .if !defined(KERNBUILDDIR) opt_wlan.h: - echo "#define IEEE80211_DEBUG 1" > opt_wlan.h + echo "#define IEEE80211_DEBUG 1" > ${.TARGET} .endif .include Index: netgraph/sync_ar/Makefile =================================================================== --- netgraph/sync_ar/Makefile (revision 182150) +++ netgraph/sync_ar/Makefile (working copy) @@ -1,13 +1,13 @@ # $FreeBSD$ - + .PATH: ${.CURDIR}/../../../dev/ar KMOD = ng_sync_ar SRCS = if_ar.c if_ar_isa.c if_ar_pci.c SRCS += device_if.h bus_if.h pci_if.h isa_if.h opt_netgraph.h - + .if !defined(KERNBUILDDIR) opt_netgraph.h: - echo "#define NETGRAPH" > opt_netgraph.h + echo "#define NETGRAPH" > ${.TARGET} .endif .include Index: netgraph/sync_sr/Makefile =================================================================== --- netgraph/sync_sr/Makefile (revision 182150) +++ netgraph/sync_sr/Makefile (working copy) @@ -1,13 +1,13 @@ # $FreeBSD$ - + .PATH: ${.CURDIR}/../../../dev/sr KMOD = ng_sync_sr SRCS = if_sr.c if_sr_isa.c if_sr_pci.c SRCS += device_if.h bus_if.h pci_if.h isa_if.h opt_netgraph.h - + .if !defined(KERNBUILDDIR) opt_netgraph.h: - echo "#define NETGRAPH" > opt_netgraph.h + echo "#define NETGRAPH" > ${.TARGET} .endif .include Index: aha/Makefile =================================================================== --- aha/Makefile (revision 182150) +++ aha/Makefile (working copy) @@ -8,7 +8,7 @@ .if !defined(KERNBUILDDIR) opt_scsi.h: - echo "#define SCSI_DELAY 15000" > opt_scsi.h + echo "#define SCSI_DELAY 15000" > ${.TARGET} .endif .include Index: ahb/Makefile =================================================================== --- ahb/Makefile (revision 182150) +++ ahb/Makefile (working copy) @@ -3,12 +3,11 @@ .PATH: ${.CURDIR}/../../dev/ahb KMOD= ahb -SRCS= ahb.c opt_cam.h device_if.h bus_if.h \ - eisa_if.h opt_scsi.h +SRCS= ahb.c opt_cam.h device_if.h bus_if.h eisa_if.h opt_scsi.h .if !defined(KERNBUILDDIR) opt_scsi.h: - echo "#define SCSI_DELAY 15000" > opt_scsi.h + echo "#define SCSI_DELAY 15000" > ${.TARGET} .endif .include Index: svr4/Makefile =================================================================== --- svr4/Makefile (revision 182150) +++ svr4/Makefile (working copy) @@ -26,11 +26,11 @@ .if !defined(KERNBUILDDIR) opt_compat.h: - echo "#define COMPAT_43 1" > opt_compat.h + echo "#define COMPAT_43 1" > ${.TARGET} .if defined(DEBUG) opt_svr4.h: - echo "#define DEBUG_SVR4 1" > opt_svr4.h + echo "#define DEBUG_SVR4 1" > ${.TARGET} .endif .endif Index: patm/Makefile =================================================================== --- patm/Makefile (revision 182150) +++ patm/Makefile (working copy) @@ -14,10 +14,10 @@ .if !defined(KERNBUILDDIR) opt_inet.h: - echo "#define INET 1" > opt_inet.h + echo "#define INET 1" > ${.TARGET} opt_natm.h: - echo "#define NATM 1" > opt_natm.h + echo "#define NATM 1" > ${.TARGET} .endif .include Index: trm/Makefile =================================================================== --- trm/Makefile (revision 182150) +++ trm/Makefile (working copy) @@ -8,7 +8,7 @@ .if !defined(KERNBUILDDIR) opt_scsi.h: - echo "#define SCSI_DELAY 15000" > opt_scsi.h + echo "#define SCSI_DELAY 15000" > ${.TARGET} .endif .include Index: wlan_rssadapt/Makefile =================================================================== --- wlan_rssadapt/Makefile (revision 182150) +++ wlan_rssadapt/Makefile (working copy) @@ -8,7 +8,7 @@ .if !defined(KERNBUILDDIR) opt_wlan.h: - echo "#define IEEE80211_DEBUG 1" > opt_wlan.h + echo "#define IEEE80211_DEBUG 1" > ${.TARGET} .endif .include Index: fatm/Makefile =================================================================== --- fatm/Makefile (revision 182150) +++ fatm/Makefile (working copy) @@ -11,10 +11,10 @@ .if !defined(KERNBUILDDIR) opt_inet.h: - echo "#define INET 1" > opt_inet.h + echo "#define INET 1" > ${.TARGET} opt_natm.h: - echo "#define NATM 1" > opt_natm.h + echo "#define NATM 1" > ${.TARGET} .endif .include Index: ubsec/Makefile =================================================================== --- ubsec/Makefile (revision 182150) +++ ubsec/Makefile (working copy) @@ -8,7 +8,7 @@ .if !defined(KERNBUILDDIR) opt_ubsec.h: - echo "#define UBSEC_DEBUG 1" > opt_ubsec.h + echo "#define UBSEC_DEBUG 1" > ${.TARGET} .endif .include Index: ath_rate_onoe/Makefile =================================================================== --- ath_rate_onoe/Makefile (revision 182150) +++ ath_rate_onoe/Makefile (working copy) @@ -61,8 +61,8 @@ .if !defined(KERNBUILDDIR) opt_wlan.h: - echo "#define IEEE80211_DEBUG 1" > opt_wlan.h -# echo > opt_wlan.h + echo "#define IEEE80211_DEBUG 1" > ${.TARGET} +# echo > ${.TARGET} .endif .include Index: pf/Makefile =================================================================== --- pf/Makefile (revision 182150) +++ pf/Makefile (working copy) @@ -15,20 +15,20 @@ .if !defined(KERNBUILDDIR) opt_inet.h: - echo "#define INET 1" > opt_inet.h + echo "#define INET 1" > ${.TARGET} .if ${MK_INET6_SUPPORT} != "no" opt_inet6.h: - echo "#define INET6 1" > opt_inet6.h + echo "#define INET6 1" > ${.TARGET} .endif opt_bpf.h: - echo "#define DEV_BPF 1" > opt_bpf.h + echo "#define DEV_BPF 1" > ${.TARGET} # pflog can be loaded as a module, have the additional checks turned on opt_pf.h: - echo "#define DEV_PF 1" > opt_pf.h - echo "#define DEF_PFLOG 1" >> opt_pf.h + echo "#define DEV_PF 1" > ${.TARGET} + echo "#define DEF_PFLOG 1" >> ${.TARGET} .endif .include Index: sppp/Makefile =================================================================== --- sppp/Makefile (revision 182150) +++ sppp/Makefile (working copy) @@ -17,13 +17,13 @@ .if !defined(KERNBUILDDIR) opt_inet.h: - echo "#define INET 1" > opt_inet.h + echo "#define INET 1" > ${.TARGET} opt_inet6.h: - echo "#define INET6 1" > opt_inet6.h + echo "#define INET6 1" > ${.TARGET} opt_ipx.h: - echo "#define IPX 1" > opt_ipx.h + echo "#define IPX 1" > ${.TARGET} .endif .include Index: an/Makefile =================================================================== --- an/Makefile (revision 182150) +++ an/Makefile (working copy) @@ -9,7 +9,7 @@ .if !defined(KERNBUILDDIR) opt_inet.h: - echo "#define INET 1" > opt_inet.h + echo "#define INET 1" > ${.TARGET} .endif .include Index: ar/Makefile =================================================================== --- ar/Makefile (revision 182150) +++ ar/Makefile (working copy) @@ -10,7 +10,7 @@ .if ${NETGRAPH} != 0 opt_netgraph.h: - echo "#define NETGRAPH ${NETGRAPH}" > opt_netgraph.h + echo "#define NETGRAPH ${NETGRAPH}" > ${.TARGET} .endif .endif Index: wlan_xauth/Makefile =================================================================== --- wlan_xauth/Makefile (revision 182150) +++ wlan_xauth/Makefile (working copy) @@ -8,7 +8,7 @@ .if !defined(KERNBUILDDIR) opt_wlan.h: - echo "#define IEEE80211_DEBUG 1" > opt_wlan.h + echo "#define IEEE80211_DEBUG 1" > ${.TARGET} .endif .include Index: ath_rate_sample/Makefile =================================================================== --- ath_rate_sample/Makefile (revision 182150) +++ ath_rate_sample/Makefile (working copy) @@ -61,8 +61,8 @@ .if !defined(KERNBUILDDIR) opt_wlan.h: -# echo "#define IEEE80211_DEBUG 1" > opt_wlan.h - echo > opt_wlan.h +# echo "#define IEEE80211_DEBUG 1" > ${.TARGET} + echo > ${.TARGET} .endif .include Index: rp/Makefile =================================================================== --- rp/Makefile (revision 182150) +++ rp/Makefile (working copy) @@ -7,7 +7,7 @@ .if !defined(KERNBUILDDIR) opt_compat.h: - echo "#define COMPAT_43 1" > opt_compat.h + echo "#define COMPAT_43 1" > ${.TARGET} .endif .include Index: ce/Makefile =================================================================== --- ce/Makefile (revision 182150) +++ ce/Makefile (working copy) @@ -16,12 +16,12 @@ .if ${NETGRAPH} != 0 opt_netgraph.h: - echo "#define NETGRAPH ${NETGRAPH}" > opt_netgraph.h + echo "#define NETGRAPH ${NETGRAPH}" > ${.TARGET} .endif .if ${NG_CRONYX} != 0 opt_ng_cronyx.h: - echo "#define NETGRAPH_CRONYX 1" > opt_ng_cronyx.h + echo "#define NETGRAPH_CRONYX 1" > ${.TARGET} .endif .endif Index: cp/Makefile =================================================================== --- cp/Makefile (revision 182150) +++ cp/Makefile (working copy) @@ -16,12 +16,12 @@ .if ${NETGRAPH} != 0 opt_netgraph.h: - echo "#define NETGRAPH ${NETGRAPH}" > opt_netgraph.h + echo "#define NETGRAPH ${NETGRAPH}" > ${.TARGET} .endif .if ${NG_CRONYX} != 0 opt_ng_cronyx.h: - echo "#define NETGRAPH_CRONYX 1" > opt_ng_cronyx.h + echo "#define NETGRAPH_CRONYX 1" > ${.TARGET} .endif .endif Index: pflog/Makefile =================================================================== --- pflog/Makefile (revision 182150) +++ pflog/Makefile (working copy) @@ -12,15 +12,15 @@ .if !defined(KERNBUILDDIR) opt_inet.h: - echo "#define INET 1" > opt_inet.h + echo "#define INET 1" > ${.TARGET} .if ${MK_INET6_SUPPORT} != "no" opt_inet6.h: - echo "#define INET6 1" > opt_inet6.h + echo "#define INET6 1" > ${.TARGET} .endif opt_bpf.h: - echo "#define DEV_BPF 1" > opt_bpf.h + echo "#define DEV_BPF 1" > ${.TARGET} .endif .include Index: cx/Makefile =================================================================== --- cx/Makefile (revision 182150) +++ cx/Makefile (working copy) @@ -15,12 +15,12 @@ .if ${NETGRAPH} != 0 opt_netgraph.h: - echo "#define NETGRAPH $(NETGRAPH)" > opt_netgraph.h + echo "#define NETGRAPH $(NETGRAPH)" > ${.TARGET} .endif .if ${NG_CRONYX} != 0 opt_ng_cronyx.h: - echo "#define NETGRAPH_CRONYX 1" > opt_ng_cronyx.h + echo "#define NETGRAPH_CRONYX 1" > ${.TARGET} .endif .endif Index: sr/Makefile =================================================================== --- sr/Makefile (revision 182150) +++ sr/Makefile (working copy) @@ -10,7 +10,7 @@ .if ${NETGRAPH} != 0 opt_netgraph.h: - echo "#define NETGRAPH ${NETGRAPH}" > opt_netgraph.h + echo "#define NETGRAPH ${NETGRAPH}" > ${.TARGET} .endif .endif Index: hatm/Makefile =================================================================== --- hatm/Makefile (revision 182150) +++ hatm/Makefile (working copy) @@ -13,10 +13,10 @@ .if !defined(KERNBUILDDIR) opt_inet.h: - echo "#define INET 1" > opt_inet.h + echo "#define INET 1" > ${.TARGET} opt_natm.h: - echo "#define NATM 1" > opt_natm.h + echo "#define NATM 1" > ${.TARGET} .endif .include Index: wlan/Makefile =================================================================== --- wlan/Makefile (revision 182150) +++ wlan/Makefile (working copy) @@ -14,14 +14,14 @@ .if !defined(KERNBUILDDIR) opt_wlan.h: - echo "#define IEEE80211_DEBUG 1" > opt_wlan.h - echo "#define IEEE80211_AMDPU_AGE 1" >> opt_wlan.h + echo "#define IEEE80211_DEBUG 1" > ${.TARGET} + echo "#define IEEE80211_AMDPU_AGE 1" >> ${.TARGET} opt_inet.h: - echo "#define INET 1" > opt_inet.h + echo "#define INET 1" > ${.TARGET} opt_ipx.h: - echo "#define IPX 1" > opt_ipx.h + echo "#define IPX 1" > ${.TARGET} .endif .include Index: ath_rate_amrr/Makefile =================================================================== --- ath_rate_amrr/Makefile (revision 182150) +++ ath_rate_amrr/Makefile (working copy) @@ -61,8 +61,8 @@ .if !defined(KERNBUILDDIR) opt_wlan.h: -# echo "#define IEEE80211_DEBUG 1" > opt_wlan.h - echo > opt_wlan.h +# echo "#define IEEE80211_DEBUG 1" > ${.TARGET} + echo > ${.TARGET} .endif .include Index: hifn/Makefile =================================================================== --- hifn/Makefile (revision 182150) +++ hifn/Makefile (working copy) @@ -8,7 +8,7 @@ .if !defined(KERNBUILDDIR) opt_hifn.h: - echo "#define HIFN_DEBUG 1" > opt_hifn.h + echo "#define HIFN_DEBUG 1" > ${.TARGET} .endif .include Index: wlan_tkip/Makefile =================================================================== --- wlan_tkip/Makefile (revision 182150) +++ wlan_tkip/Makefile (working copy) @@ -8,7 +8,7 @@ .if !defined(KERNBUILDDIR) opt_wlan.h: - echo "#define IEEE80211_DEBUG 1" > opt_wlan.h + echo "#define IEEE80211_DEBUG 1" > ${.TARGET} .endif .include Index: linux/Makefile =================================================================== --- linux/Makefile (revision 182150) +++ linux/Makefile (working copy) @@ -54,7 +54,7 @@ .if !defined(KERNBUILDDIR) opt_inet6.h: - echo "#define INET6 1" > opt_inet6.h + echo "#define INET6 1" > ${.TARGET} .endif .include Index: wlan_ccmp/Makefile =================================================================== --- wlan_ccmp/Makefile (revision 182150) +++ wlan_ccmp/Makefile (working copy) @@ -10,7 +10,7 @@ .if !defined(KERNBUILDDIR) opt_wlan.h: - echo "#define IEEE80211_DEBUG 1" > opt_wlan.h + echo "#define IEEE80211_DEBUG 1" > ${.TARGET} .endif .include Index: safe/Makefile =================================================================== --- safe/Makefile (revision 182150) +++ safe/Makefile (working copy) @@ -34,7 +34,7 @@ .if !defined(KERNBUILDDIR) opt_safe.h: - echo "#define SAFE_DEBUG 1" > opt_safe.h + echo "#define SAFE_DEBUG 1" > ${.TARGET} .endif .include Index: if_tap/Makefile =================================================================== --- if_tap/Makefile (revision 182150) +++ if_tap/Makefile (working copy) @@ -12,7 +12,7 @@ echo "#define COMPAT_FREEBSD6 1" > ${.TARGET} opt_inet.h: - echo "#define INET 1" > opt_inet.h + echo "#define INET 1" > ${.TARGET} .endif .include Index: ctau/Makefile =================================================================== --- ctau/Makefile (revision 182150) +++ ctau/Makefile (working copy) @@ -15,12 +15,12 @@ .if ${NETGRAPH} != 0 opt_netgraph.h: - echo "#define NETGRAPH $(NETGRAPH)" > opt_netgraph.h + echo "#define NETGRAPH $(NETGRAPH)" > ${.TARGET} .endif .if ${NG_CRONYX} != 0 opt_ng_cronyx.h: - echo "#define NETGRAPH_CRONYX 1" > opt_ng_cronyx.h + echo "#define NETGRAPH_CRONYX 1" > ${.TARGET} .endif .endif ----Next_Part(Mon_Aug_25_01_15_13_2008_547)---- From owner-freebsd-arch@FreeBSD.ORG Mon Aug 25 11:06:48 2008 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 1924D106568E for ; Mon, 25 Aug 2008 11:06:48 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 012A38FC33 for ; Mon, 25 Aug 2008 11:06:48 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m7PB6lHi027700 for ; Mon, 25 Aug 2008 11:06:47 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m7PB6lpq027696 for freebsd-arch@FreeBSD.org; Mon, 25 Aug 2008 11:06:47 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 25 Aug 2008 11:06:47 GMT Message-Id: <200808251106.m7PB6lpq027696@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-arch@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-arch@FreeBSD.org 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, 25 Aug 2008 11:06:48 -0000 Current FreeBSD problem reports Critical problems Serious problems Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/120749 arch [request] Suggest upping the default kern.ps_arg_cache 1 problem total. From owner-freebsd-arch@FreeBSD.ORG Mon Aug 25 20:04:44 2008 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 517821065678; Mon, 25 Aug 2008 20:04:44 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id DDE2E8FC0A; Mon, 25 Aug 2008 20:04:43 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m7PK4Y8K043991; Mon, 25 Aug 2008 16:04:34 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-arch@freebsd.org Date: Mon, 25 Aug 2008 10:37:10 -0400 User-Agent: KMail/1.9.7 References: <20080825.002316.-1548243307.imp@bsdimp.com> In-Reply-To: <20080825.002316.-1548243307.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200808251037.11126.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Mon, 25 Aug 2008 16:04:35 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8087/Mon Aug 25 14:40:37 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.3 required=4.2 tests=AWL,BAYES_00, DATE_IN_PAST_03_06,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: net@freebsd.org Subject: Re: Code review 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, 25 Aug 2008 20:04:44 -0000 On Monday 25 August 2008 02:23:16 am M. Warner Losh wrote: > I did this a few years ago when trying to track down a problem with > some realtek network chips that I was having problems with at Timing > Solutions. I'd like to get this into the tree, since it was helpful > then. > > Comments? When you are running a faster tick I think want to only call the mii and watchdog stuff once a second still. I know this will break the tx watchdog for example. Since it's kind of tricky to manage that I think you should just use a separate timer for the twister stuff. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Tue Aug 26 00:00:33 2008 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 859A0106567A for ; Tue, 26 Aug 2008 00:00:33 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from nskntmtas02p.mx.bigpond.com (nskntmtas02p.mx.bigpond.com [61.9.168.140]) by mx1.freebsd.org (Postfix) with ESMTP id 035048FC18 for ; Tue, 26 Aug 2008 00:00:32 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from nskntotgx02p.mx.bigpond.com ([124.188.162.219]) by nskntmtas02p.mx.bigpond.com with ESMTP id <20080826000030.DIPM26374.nskntmtas02p.mx.bigpond.com@nskntotgx02p.mx.bigpond.com> for ; Tue, 26 Aug 2008 00:00:30 +0000 Received: from areilly.bpa.nu ([124.188.162.219]) by nskntotgx02p.mx.bigpond.com with ESMTP id <20080826000025.FTUJ15766.nskntotgx02p.mx.bigpond.com@areilly.bpa.nu> for ; Tue, 26 Aug 2008 00:00:25 +0000 Received: (qmail 77808 invoked by uid 501); 26 Aug 2008 00:00:09 -0000 Date: Tue, 26 Aug 2008 10:00:09 +1000 From: Andrew Reilly To: Jeff Roberson Message-ID: <20080826000009.GA77044@duncan.reilly.home> References: <20080819025019.GA27997@duncan.reilly.home> <20080818215813.H952@desktop> <20080819134005.GA85664@duncan.reilly.home> <20080820214627.C30593@desktop> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080820214627.C30593@desktop> User-Agent: Mutt/1.4.2.3i X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150203.48B34799.00DB,ss=1,fgs=0 Cc: freebsd-multimedia@freebsd.org, freebsd-arch@freebsd.org Subject: Re: SCHED_ULE problem: slow single processor, realtime prio vs network stack 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, 26 Aug 2008 00:00:33 -0000 Hi Jeff, Sorry for the slow follow-up. It's actually quite a pain to tweak the kernel on that machine: it's often in use and it's slow at compiling kernels. Will see if I can get on to it soon. On Wed, Aug 20, 2008 at 09:47:01PM -1000, Jeff Roberson wrote: > On Tue, 19 Aug 2008, Andrew Reilly wrote: > > >On Mon, Aug 18, 2008 at 10:00:12PM -1000, Jeff Roberson wrote: > >>Can you tell me what % cpu the audio application uses while running? Have > >>you tried nice -20 instead of rtprio? > > > >It's currently using about 10%, maybe a bit more. I expect > >it to get heavier as I add more to it. I have hopes of it > >continuing to work even at 60 to 80% of CPU. > > > >I haven't tried nice -20 because I don't want the priority to > >drift or change, which is something that I thought the normal > >levels did. I'll give it a go though, and report back. > > With such a low cpu utilization I wouldn't expect it's the scheduling > algorithm. It may be a difference in preemption settings. Is preemption > enabled in both kernels? Yes, all of the premption and POSIX realtime options (that are usually on, aren't they?) are on in each case. Only difference is selection of scheduler: (This is the whole config file) include GENERIC ident GURNEY nocpu I486_CPU nocpu I586_CPU nooptions SCHED_ULE options SCHED_4BSD Cheers, Andrew From owner-freebsd-arch@FreeBSD.ORG Tue Aug 26 07:25:53 2008 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 D996B1065671; Tue, 26 Aug 2008 07:25:53 +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 9CB928FC0A; Tue, 26 Aug 2008 07:25:53 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m7Q7NRZ5057765; Tue, 26 Aug 2008 01:23:27 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 26 Aug 2008 01:23:57 -0600 (MDT) Message-Id: <20080826.012357.1973601375.imp@bsdimp.com> To: jhb@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <200808251037.11126.jhb@freebsd.org> References: <20080825.002316.-1548243307.imp@bsdimp.com> <200808251037.11126.jhb@freebsd.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: net@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: Code review 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, 26 Aug 2008 07:25:54 -0000 In message: <200808251037.11126.jhb@freebsd.org> John Baldwin writes: : On Monday 25 August 2008 02:23:16 am M. Warner Losh wrote: : > I did this a few years ago when trying to track down a problem with : > some realtek network chips that I was having problems with at Timing : > Solutions. I'd like to get this into the tree, since it was helpful : > then. : > : > Comments? : : When you are running a faster tick I think want to only call the mii and : watchdog stuff once a second still. I know this will break the tx watchdog : for example. Since it's kind of tricky to manage that I think you should : just use a separate timer for the twister stuff. Is this in general, or do you have a specific problem in mind with the rl change? In general, we're not transmitting during this exercise and it happens only once... Is it worth the extra hair? Warner From owner-freebsd-arch@FreeBSD.ORG Tue Aug 26 07:50:26 2008 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 C02A3106566B for ; Tue, 26 Aug 2008 07:50:26 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from nschwmtas05p.mx.bigpond.com (nschwmtas05p.mx.bigpond.com [61.9.189.149]) by mx1.freebsd.org (Postfix) with ESMTP id 5096E8FC21 for ; Tue, 26 Aug 2008 07:50:17 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from nschwotgx02p.mx.bigpond.com ([124.188.162.219]) by nschwmtas05p.mx.bigpond.com with ESMTP id <20080826074959.BJMG6339.nschwmtas05p.mx.bigpond.com@nschwotgx02p.mx.bigpond.com> for ; Tue, 26 Aug 2008 07:49:59 +0000 Received: from areilly.bpa.nu ([124.188.162.219]) by nschwotgx02p.mx.bigpond.com with ESMTP id <20080826074956.EBAD11844.nschwotgx02p.mx.bigpond.com@areilly.bpa.nu> for ; Tue, 26 Aug 2008 07:49:56 +0000 Received: (qmail 17150 invoked by uid 501); 26 Aug 2008 07:49:43 -0000 Date: Tue, 26 Aug 2008 17:49:43 +1000 From: Andrew Reilly To: Matthew Macy Message-ID: <20080826074943.GB85357@duncan.reilly.home> References: <3c1674c90808231713x47e42de5oa9fc2f2f244d2e74@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3c1674c90808231713x47e42de5oa9fc2f2f244d2e74@mail.gmail.com> User-Agent: Mutt/1.4.2.3i X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150203.48B3B5A4.0071,ss=1,fgs=0 Cc: Ivan Voras , freebsd-arch@freebsd.org Subject: Re: FreeBSD and DEP aka "NX bit"? 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, 26 Aug 2008 07:50:26 -0000 On Sat, Aug 23, 2008 at 05:13:30PM -0700, Matthew Macy wrote: > On Sat, Aug 23, 2008 at 5:04 PM, Ivan Voras wrote: > > I stumbled upon this Wikipedia page: > > http://en.wikipedia.org/wiki/Comparison_of_BSD_operating_systems#Security_features > > and it mentions NX bit is supported in FreeBSD. Is this true? Is it > > enabled by default? > > Yes. However, it is in the upper word so it only works with PAE or > amd64. "jemalloc" maps the heap NX and thread stacks are mapped NX. > The default process stack currently needs to be executable because > sigcode is placed at the start of the stack at the time of process > creation. Oh, I was looking into this a few months ago, and came to the conclusion that NX wasn't turned on at all. How do applications/languages that use JIT or other run-time code generation get around the non-executable heap? Just not use jemalloc? I've been using 7-STABLE on amd64 for a long time, and haven't noticed any problems with Java or SBCL lisp or PLT-scheme, all of which use JIT code generation (but probably neither use jemalloc?) Cheers, -- Andrew From owner-freebsd-arch@FreeBSD.ORG Tue Aug 26 16:28:07 2008 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 F0129106566C for ; Tue, 26 Aug 2008 16:28:07 +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 E01258FC13 for ; Tue, 26 Aug 2008 16:28:07 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id AB6FC1A4D84; Tue, 26 Aug 2008 09:28:07 -0700 (PDT) Date: Tue, 26 Aug 2008 09:28:07 -0700 From: Alfred Perlstein To: Andrew Reilly Message-ID: <20080826162807.GF16977@elvis.mu.org> References: <3c1674c90808231713x47e42de5oa9fc2f2f244d2e74@mail.gmail.com> <20080826074943.GB85357@duncan.reilly.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080826074943.GB85357@duncan.reilly.home> User-Agent: Mutt/1.4.2.3i Cc: freebsd-arch@freebsd.org, Ivan Voras , Matthew Macy Subject: Re: FreeBSD and DEP aka "NX bit"? 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, 26 Aug 2008 16:28:08 -0000 * Andrew Reilly [080826 00:51] wrote: > On Sat, Aug 23, 2008 at 05:13:30PM -0700, Matthew Macy wrote: > > On Sat, Aug 23, 2008 at 5:04 PM, Ivan Voras wrote: > > > I stumbled upon this Wikipedia page: > > > http://en.wikipedia.org/wiki/Comparison_of_BSD_operating_systems#Security_features > > > and it mentions NX bit is supported in FreeBSD. Is this true? Is it > > > enabled by default? > > > > Yes. However, it is in the upper word so it only works with PAE or > > amd64. "jemalloc" maps the heap NX and thread stacks are mapped NX. > > The default process stack currently needs to be executable because > > sigcode is placed at the start of the stack at the time of process > > creation. > > Oh, I was looking into this a few months ago, and came to the > conclusion that NX wasn't turned on at all. > > How do applications/languages that use JIT or other run-time > code generation get around the non-executable heap? Just not > use jemalloc? > > I've been using 7-STABLE on amd64 for a long time, and haven't > noticed any problems with Java or SBCL lisp or PLT-scheme, all > of which use JIT code generation (but probably neither use > jemalloc?) mprotect(2)? -- - Alfred Perlstein From owner-freebsd-arch@FreeBSD.ORG Tue Aug 26 18:02:53 2008 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 982581065675; Tue, 26 Aug 2008 18:02:53 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id EFF648FC15; Tue, 26 Aug 2008 18:02:52 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m7QI2giQ056781; Tue, 26 Aug 2008 14:02:43 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: "M. Warner Losh" Date: Tue, 26 Aug 2008 10:33:42 -0400 User-Agent: KMail/1.9.7 References: <20080825.002316.-1548243307.imp@bsdimp.com> <200808251037.11126.jhb@freebsd.org> <20080826.012357.1973601375.imp@bsdimp.com> In-Reply-To: <20080826.012357.1973601375.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200808261033.43091.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Tue, 26 Aug 2008 14:02:43 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8093/Tue Aug 26 12:01:30 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.3 required=4.2 tests=AWL,BAYES_00, DATE_IN_PAST_03_06,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: net@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Code review 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, 26 Aug 2008 18:02:53 -0000 On Tuesday 26 August 2008 03:23:57 am M. Warner Losh wrote: > In message: <200808251037.11126.jhb@freebsd.org> > John Baldwin writes: > : On Monday 25 August 2008 02:23:16 am M. Warner Losh wrote: > : > I did this a few years ago when trying to track down a problem with > : > some realtek network chips that I was having problems with at Timing > : > Solutions. I'd like to get this into the tree, since it was helpful > : > then. > : > > : > Comments? > : > : When you are running a faster tick I think want to only call the mii and > : watchdog stuff once a second still. I know this will break the tx watchdog > : for example. Since it's kind of tricky to manage that I think you should > : just use a separate timer for the twister stuff. > > Is this in general, or do you have a specific problem in mind with the > rl change? In general, we're not transmitting during this exercise > and it happens only once... Is it worth the extra hair? Worried more about the general case. Is mii_tick() going to be ok with being invoked more often? Also, if you are only doing this during attach or interface up, it might be simpler to have a private timer (shoot, if it's during attach the 'struct callout' can be on the stack) just for this bit. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Aug 27 01:20:24 2008 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 670761065678 for ; Wed, 27 Aug 2008 01:20:24 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from nskntmtas05p.mx.bigpond.com (nskntmtas05p.mx.bigpond.com [61.9.168.149]) by mx1.freebsd.org (Postfix) with ESMTP id CC5918FC1B for ; Wed, 27 Aug 2008 01:20:23 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from nskntotgx02p.mx.bigpond.com ([124.188.162.219]) by nskntmtas05p.mx.bigpond.com with ESMTP id <20080827012017.ZEGQ19244.nskntmtas05p.mx.bigpond.com@nskntotgx02p.mx.bigpond.com> for ; Wed, 27 Aug 2008 01:20:17 +0000 Received: from areilly.bpa.nu ([124.188.162.219]) by nskntotgx02p.mx.bigpond.com with ESMTP id <20080827012017.VAMZ15766.nskntotgx02p.mx.bigpond.com@areilly.bpa.nu> for ; Wed, 27 Aug 2008 01:20:17 +0000 Received: (qmail 98381 invoked by uid 501); 27 Aug 2008 01:19:49 -0000 Date: Wed, 27 Aug 2008 11:19:49 +1000 From: Andrew Reilly To: Alfred Perlstein Message-ID: <20080827011949.GA98242@duncan.reilly.home> References: <3c1674c90808231713x47e42de5oa9fc2f2f244d2e74@mail.gmail.com> <20080826074943.GB85357@duncan.reilly.home> <20080826162807.GF16977@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080826162807.GF16977@elvis.mu.org> User-Agent: Mutt/1.4.2.3i X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150204.48B4ABD1.005B,ss=1,fgs=0 Cc: freebsd-arch@freebsd.org, Ivan Voras , Matthew Macy Subject: Re: FreeBSD and DEP aka "NX bit"? 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, 27 Aug 2008 01:20:24 -0000 On Tue, Aug 26, 2008 at 09:28:07AM -0700, Alfred Perlstein wrote: > * Andrew Reilly [080826 00:51] wrote: > > I've been using 7-STABLE on amd64 for a long time, and haven't > > noticed any problems with Java or SBCL lisp or PLT-scheme, all > > of which use JIT code generation (but probably neither use > > jemalloc?) > > mprotect(2)? Fair enough. Good to know that it's actually tweaking the NX permissions, I guess. The man page seems a little vague about when it might succeed, and what effect it might have... Cheers, -- Andrew From owner-freebsd-arch@FreeBSD.ORG Wed Aug 27 09:10:56 2008 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 100AD106566C; Wed, 27 Aug 2008 09:10:56 +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 A8D5A8FC20; Wed, 27 Aug 2008 09:10:55 +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 26BBB46C99; Wed, 27 Aug 2008 05:10:55 -0400 (EDT) Date: Wed, 27 Aug 2008 10:10:55 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Andrew Reilly In-Reply-To: <20080827011949.GA98242@duncan.reilly.home> Message-ID: References: <3c1674c90808231713x47e42de5oa9fc2f2f244d2e74@mail.gmail.com> <20080826074943.GB85357@duncan.reilly.home> <20080826162807.GF16977@elvis.mu.org> <20080827011949.GA98242@duncan.reilly.home> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Matthew Macy , Alfred Perlstein , Ivan Voras , freebsd-arch@freebsd.org Subject: Re: FreeBSD and DEP aka "NX bit"? 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, 27 Aug 2008 09:10:56 -0000 On Wed, 27 Aug 2008, Andrew Reilly wrote: > On Tue, Aug 26, 2008 at 09:28:07AM -0700, Alfred Perlstein wrote: >> * Andrew Reilly [080826 00:51] >> wrote: >>> I've been using 7-STABLE on amd64 for a long time, and haven't noticed any >>> problems with Java or SBCL lisp or PLT-scheme, all of which use JIT code >>> generation (but probably neither use jemalloc?) >> >> mprotect(2)? > > Fair enough. Good to know that it's actually tweaking the NX permissions, I > guess. The man page seems a little vague about when it might succeed, and > what effect it might have... We're behind on the not-mapping-writable stuff, so for better (and worse) quite a few such things in application have been faulted in by other operating systems already. That doesn't mean there won't be issues, but does have the redeeming aspect that things should be less bumpy for us going forward. Hopefully we can start making that progress a bit more quickly... Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-arch@FreeBSD.ORG Wed Aug 27 16:55:55 2008 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 D5FC81065697 for ; Wed, 27 Aug 2008 16:55:55 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by mx1.freebsd.org (Postfix) with ESMTP id 650758FC1B for ; Wed, 27 Aug 2008 16:55:55 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so16146fgb.35 for ; Wed, 27 Aug 2008 09:55:54 -0700 (PDT) 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:mime-version:content-type:content-transfer-encoding :content-disposition:x-google-sender-auth; bh=sxlJ9RdAnFc9nWtLZnUyN2elnzx4B/xPtDzSpCCrlws=; b=Rk5VSRdLIRqL9ytuJVFIuvs/Ek9NJeQpfoqaWMPxFUjNgAVcI/rA2WTkSqF3DQaLkq ABEpiJO29f6bXi7I6eTqu2rxY4jJOoZuxn8ZhYQcazZJVPIC/JM8Ba9LL9yOXAptJesx wPtjAgLoQM4bJ5RdPiuuTv6gbWQBYMRbFAdOI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:mime-version:content-type :content-transfer-encoding:content-disposition:x-google-sender-auth; b=SRXmn149WUVuvFC0WFUVFerzxsZEPiUcqHqA3sQVuvbSrl+BlDAo07sE1k8wlgIwai MTF6vEB4SJNa2CZJGzAB2rJ/eNLgLvqSr0eDIzRpoWaPVuaQ86etMbfvVdqHQCzfhV2E A8+/c/E6mj9hc+iNIE5Ai06uzkCMhlEeM3g2I= Received: by 10.86.83.2 with SMTP id g2mr223585fgb.54.1219856153938; Wed, 27 Aug 2008 09:55:53 -0700 (PDT) Received: by 10.86.78.14 with HTTP; Wed, 27 Aug 2008 09:55:53 -0700 (PDT) Message-ID: <3bbf2fe10808270955y53b00587m1991e7bf898466e1@mail.gmail.com> Date: Wed, 27 Aug 2008 18:55:53 +0200 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "FreeBSD Arch" MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: a8f997d86184c67c Cc: Konstantin Belousov Subject: Kernel decontextualization -- idea and little proof-of-concept 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, 27 Aug 2008 16:55:55 -0000 Looking at VFS (but this is not a VFS-only e-mail), what immediately pops up is that KPI is rather heavy, someway complicated and too little user-friendly (in particular in regard of locking). Some of this heaviness cames from direct approaching some peculiar problems (vnodes recycling in primis) but another part is totally old-standing and cames out from wrong (or anyways acrossed) assumptions. One of this latter case is the widespread presence of "thread" arguments in the whole kernel. Among all the subsystems, the most plagued is the VFS. You can see a lot of unuseful (or partially, better explained later) thread passed all over the VOP_* functions, their consumers and their callee and this reflects on a lot of key structures too (uio, componentname, namei, etc.). My idea is that we should drop totally this thread bloat from our subsystems (and in particular from VFS) because it is nosense and it adds just obfuscation and overhead for eventual consumer of the KPI. This also will prepare a better ground for further VFS improvements like, for example, namei KPI refactoring and reorganization, file accessings, etc. Small Q&A about possible concerns: Q: Sometimes we need to pass a thread in order to get his credentials, how you will handle this? A: We will simply get the ucred pointed and will switch the thread argument to be a credential Q: curthread accesses are heavy, will this work penalyze kernel performances? A: This work is intended in order to drastically reduce thread pointers movement. This means that, ideally, this will get in having a lot less curthread accesses than the old code. Q: Ideally, you have to complete the whole work fastly but still keeping patches in mealpieces that people can review and test, how do you plan to handle this? A: There is not a simple solution for this. I will try to put a lot of effort in order to have good-sized patches and to do it as fast as I can. For an example, please, look at this patch: http://www.freebsd.org/~attilio/vfsattr.diff which does remove the thread argument from VOP_GETATTR / VOP_SETATTR couplet. There is still room for refinements here, but I need to cleanup other VOP_* functions before. Q: You have been good in avoiding the biggest concern, but here we go! What about MFC troubles caming from a massive KPI breakage? A: I know that MFC to 7 and 6 will became a PITA (in particular for VFS consumers) but this is a good moment in order to decide if we want to keep catering a old-standing (bogus) approach like that or if we want to operate a full cleanup. This will mean working also in the variety of consumers filesystem but with the help of a good line-up of testers I think I can handle this. Let me know what do you think about. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-arch@FreeBSD.ORG Wed Aug 27 17:28:22 2008 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 A89EA1065674 for ; Wed, 27 Aug 2008 17:28:22 +0000 (UTC) (envelope-from chuckr@telenix.org) Received: from mail4.sea5.speakeasy.net (mail4.sea5.speakeasy.net [69.17.117.6]) by mx1.freebsd.org (Postfix) with ESMTP id 8F4C88FC15 for ; Wed, 27 Aug 2008 17:28:22 +0000 (UTC) (envelope-from chuckr@telenix.org) Received: (qmail 12005 invoked from network); 27 Aug 2008 17:01:42 -0000 Received: from april.chuckr.org (HELO april.telenix.org) (chuckr@[66.92.151.30]) (envelope-sender ) by mail4.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 27 Aug 2008 17:01:41 -0000 Message-ID: <48B58846.6040400@telenix.org> Date: Wed, 27 Aug 2008 13:00:54 -0400 From: Chuck Robey User-Agent: Thunderbird 2.0.0.6 (X11/20071107) MIME-Version: 1.0 To: FreeBSD-arch@FreeBSD.org X-Enigmail-Version: 0.95.5 OpenPGP: id=F3DCA0E9; url=http://pgp.mit.edu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: an argument of make(1) 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, 27 Aug 2008 17:28:22 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am posting this to our arch list; if I'm wrong, we can move this. I want to argue for some changes to our great make(1) tool. I've long been a fan of make, and in particular, FreeBSD's make. In my own career, I've often had to do more custom creation of Makefiles, and while there are some folks here who definitely DO know our make better, I think I can honestly say I know it pretty well. In creating tools for customers, I've often been forced, unwillingly, to go to the GNU make tool. The reason is just one of compatibility. There are several different reasons for this, which I want to list: 1) while the GNU make has the -v to allow one to both identify the tool and the version, FreeBSD's make has no such facility, that I'm aware of. You can't test & capture the type of make here, except by the rather inadequate trapping of getting no response at all. 2) while some parts of our make don't advertise it, they can be made compatible to the gmake's tools. "include" is a good example (the FreeBSD "include" docs claim that it only works as ".include", but that's a prevarication (and a very good thing it is). What I'd like to argue for is that some things like "if" have their compatibility with gmake enhanced. No, don't make it a mirror image, just make it possible for a programmer to craft a limited set of tests that will work in both places. If you give programmers the ability to detect what make they're in, the ability to craft a limited set of compatible tests, and also the other side (endif stuff) then everything else for portability can be done by using those limits. If something like this were done, then it allows a programmer, finally, to write a REALLY portable makefile. It would still allow one to make use of all of make(1)'s great command set, but not to kill it's use in a gmake-only system. OK, that'st the major argument. I'm going to ask for one thing here, but it's truly extra, just my own bias's showing thru. I wish that a fair number of the changes that have gone into make be taken back. I'm not talking about those that enhanced it's operation, I'm talking about all of the changes that, while trying to increase the elegance of the code, have really destroyed it's porrting portability, in a major way. Make used to depend on a smaller set of libraries, and those libraries were largely those available on other systems, so the task for a programmer, to port our make(1) to a different platform wasn't all that hard to do. Nowadays, with a great number of the changes having been crafted to change dependencies to FreeBSD-only tools, it's a real bear to port it. The code involved is nearly all very, very portable; it's the way that the libraries have been constituted that makes porting this a really bad job. If someone would make up a libmake.so.1, which in itself could be make really portable, that would also go a great long way to improving the popularity of our make(1). I'm NOT asking to roll back any of the distinct improvements that have gone in, only the changes that ruined it's porting-ability (yea, that's portabilty, I just wanted to really point that out again). OK, if someone were to come up with swuch a set of changes, would they be dead on arrival? I know that no one gets prior approval for FreeBSD (I completely agree with that), just didn't want to be totally at odds with everyone, if I'm the only one who sees it this way. Thanks for your time. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAki1iEUACgkQz62J6PPcoOkniQCfWg+wlDrQ6rC+g2jGip12Q1VF koQAnRv4Sjs6xnebEEipKcGF1lXYZmRP =6ike -----END PGP SIGNATURE----- From owner-freebsd-arch@FreeBSD.ORG Wed Aug 27 17:45:30 2008 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 DBD4D106568C for ; Wed, 27 Aug 2008 17:45:30 +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 C6AE98FC1C for ; Wed, 27 Aug 2008 17:45:30 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 79F341A4D81; Wed, 27 Aug 2008 10:45:30 -0700 (PDT) Date: Wed, 27 Aug 2008 10:45:30 -0700 From: Alfred Perlstein To: Chuck Robey Message-ID: <20080827174530.GZ16977@elvis.mu.org> References: <48B58846.6040400@telenix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48B58846.6040400@telenix.org> User-Agent: Mutt/1.4.2.3i Cc: FreeBSD-arch@FreeBSD.org Subject: Re: an argument of make(1) 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, 27 Aug 2008 17:45:31 -0000 The only excuse I have for top posting here is that I agree with the entirety of this email. -Alfred * Chuck Robey [080827 10:28] wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I am posting this to our arch list; if I'm wrong, we can move this. I want to > argue for some changes to our great make(1) tool. > > I've long been a fan of make, and in particular, FreeBSD's make. In my own > career, I've often had to do more custom creation of Makefiles, and while there > are some folks here who definitely DO know our make better, I think I can > honestly say I know it pretty well. In creating tools for customers, I've > often been forced, unwillingly, to go to the GNU make tool. The reason is just > one of compatibility. There are several different reasons for this, which I > want to list: > > 1) while the GNU make has the -v to allow one to both identify the tool and the > version, FreeBSD's make has no such facility, that I'm aware of. You can't test > & capture the type of make here, except by the rather inadequate trapping of > getting no response at all. > > 2) while some parts of our make don't advertise it, they can be made compatible > to the gmake's tools. "include" is a good example (the FreeBSD "include" docs > claim that it only works as ".include", but that's a prevarication (and a very > good thing it is). What I'd like to argue for is that some things like "if" > have their compatibility with gmake enhanced. No, don't make it a mirror image, > just make it possible for a programmer to craft a limited set of tests that will > work in both places. > > If you give programmers the ability to detect what make they're in, the ability > to craft a limited set of compatible tests, and also the other side (endif > stuff) then everything else for portability can be done by using those limits. > > If something like this were done, then it allows a programmer, finally, to write > a REALLY portable makefile. It would still allow one to make use of all of > make(1)'s great command set, but not to kill it's use in a gmake-only system. > > OK, that'st the major argument. I'm going to ask for one thing here, but it's > truly extra, just my own bias's showing thru. I wish that a fair number of the > changes that have gone into make be taken back. I'm not talking about those > that enhanced it's operation, I'm talking about all of the changes that, while > trying to increase the elegance of the code, have really destroyed it's porrting > portability, in a major way. Make used to depend on a smaller set of libraries, > and those libraries were largely those available on other systems, so the task > for a programmer, to port our make(1) to a different platform wasn't all that > hard to do. Nowadays, with a great number of the changes having been crafted to > change dependencies to FreeBSD-only tools, it's a real bear to port it. > > The code involved is nearly all very, very portable; it's the way that the > libraries have been constituted that makes porting this a really bad job. If > someone would make up a libmake.so.1, which in itself could be make really > portable, that would also go a great long way to improving the popularity of our > make(1). I'm NOT asking to roll back any of the distinct improvements that have > gone in, only the changes that ruined it's porting-ability (yea, that's > portabilty, I just wanted to really point that out again). > > OK, if someone were to come up with swuch a set of changes, would they be dead > on arrival? I know that no one gets prior approval for FreeBSD (I completely > agree with that), just didn't want to be totally at odds with everyone, if I'm > the only one who sees it this way. > > Thanks for your time. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.9 (FreeBSD) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAki1iEUACgkQz62J6PPcoOkniQCfWg+wlDrQ6rC+g2jGip12Q1VF > koQAnRv4Sjs6xnebEEipKcGF1lXYZmRP > =6ike > -----END PGP SIGNATURE----- > _______________________________________________ > 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 Aug 27 20:13:02 2008 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 429291065681 for ; Wed, 27 Aug 2008 20:13:02 +0000 (UTC) (envelope-from peter@wemm.org) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.168]) by mx1.freebsd.org (Postfix) with ESMTP id 264108FC19 for ; Wed, 27 Aug 2008 20:13:02 +0000 (UTC) (envelope-from peter@wemm.org) Received: by wf-out-1314.google.com with SMTP id 24so28296wfg.7 for ; Wed, 27 Aug 2008 13:13:01 -0700 (PDT) Received: by 10.142.222.4 with SMTP id u4mr124530wfg.250.1219866300107; Wed, 27 Aug 2008 12:45:00 -0700 (PDT) Received: by 10.142.76.14 with HTTP; Wed, 27 Aug 2008 12:45:00 -0700 (PDT) Message-ID: Date: Wed, 27 Aug 2008 12:45:00 -0700 From: "Peter Wemm" To: "Robert Watson" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3c1674c90808231713x47e42de5oa9fc2f2f244d2e74@mail.gmail.com> <20080826074943.GB85357@duncan.reilly.home> <20080826162807.GF16977@elvis.mu.org> <20080827011949.GA98242@duncan.reilly.home> Cc: freebsd-arch@freebsd.org, Alfred Perlstein , Ivan Voras , Matthew Macy Subject: Re: FreeBSD and DEP aka "NX bit"? 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, 27 Aug 2008 20:13:02 -0000 On Wed, Aug 27, 2008 at 2:10 AM, Robert Watson wrote: > On Wed, 27 Aug 2008, Andrew Reilly wrote: > >> On Tue, Aug 26, 2008 at 09:28:07AM -0700, Alfred Perlstein wrote: >>> >>> * Andrew Reilly [080826 00:51] >>> wrote: >>>> >>>> I've been using 7-STABLE on amd64 for a long time, and haven't noticed >>>> any problems with Java or SBCL lisp or PLT-scheme, all of which use JIT code >>>> generation (but probably neither use jemalloc?) >>> >>> mprotect(2)? >> >> Fair enough. Good to know that it's actually tweaking the NX permissions, >> I guess. The man page seems a little vague about when it might succeed, and >> what effect it might have... > > We're behind on the not-mapping-writable stuff, so for better (and worse) > quite a few such things in application have been faulted in by other > operating systems already. That doesn't mean there won't be issues, but > does have the redeeming aspect that things should be less bumpy for us going > forward. Hopefully we can start making that progress a bit more quickly... I recall seeing config.h code chunks to turn sections of the stack on/off for execution on (I think) sparc64. It might have been for netbsd. If my memory serves correctly, libgcc grew code to do mprotect(), and the gcc code generator would call it as appropriate when it needed to do its magic. I think this was for an older version of gcc though. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell From owner-freebsd-arch@FreeBSD.ORG Wed Aug 27 23:39:02 2008 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 2C547106566B for ; Wed, 27 Aug 2008 23:39:02 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from nschwmtas03p.mx.bigpond.com (nschwmtas03p.mx.bigpond.com [61.9.189.143]) by mx1.freebsd.org (Postfix) with ESMTP id ACB2C8FC18 for ; Wed, 27 Aug 2008 23:39:01 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from nschwotgx03p.mx.bigpond.com ([124.188.162.219]) by nschwmtas03p.mx.bigpond.com with ESMTP id <20080827233845.ZAMW17360.nschwmtas03p.mx.bigpond.com@nschwotgx03p.mx.bigpond.com> for ; Wed, 27 Aug 2008 23:38:45 +0000 Received: from areilly.bpa.nu ([124.188.162.219]) by nschwotgx03p.mx.bigpond.com with ESMTP id <20080827233845.SHNC11041.nschwotgx03p.mx.bigpond.com@areilly.bpa.nu> for ; Wed, 27 Aug 2008 23:38:45 +0000 Received: (qmail 17871 invoked by uid 501); 27 Aug 2008 23:38:31 -0000 Date: Thu, 28 Aug 2008 09:38:31 +1000 From: Andrew Reilly To: Jeff Roberson Message-ID: <20080827233831.GA16705@duncan.reilly.home> References: <20080819025019.GA27997@duncan.reilly.home> <20080818215813.H952@desktop> <20080819134005.GA85664@duncan.reilly.home> <20080820214627.C30593@desktop> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080820214627.C30593@desktop> User-Agent: Mutt/1.4.2.3i X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150204.48B5E585.008B,ss=1,fgs=0 Cc: freebsd-multimedia@freebsd.org, freebsd-arch@freebsd.org Subject: Re: SCHED_ULE problem: slow single processor, realtime prio vs network stack 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, 27 Aug 2008 23:39:02 -0000 On Wed, Aug 20, 2008 at 09:47:01PM -1000, Jeff Roberson wrote: > On Tue, 19 Aug 2008, Andrew Reilly wrote: > >I haven't tried nice -20 because I don't want the priority to > >drift or change, which is something that I thought the normal > >levels did. I'll give it a go though, and report back. > > With such a low cpu utilization I wouldn't expect it's the scheduling > algorithm. It may be a difference in preemption settings. Is preemption > enabled in both kernels? I've just done a set of tests with setprio(... -20) vs rtprio(...10), and with SCHED_ULE vs SCHED_4BSD. The results are essentially as I reported before except that regular prio -20 seems to be just as reliable as rtprio 10 under 4BSD and just as unhelpful under _ULE. To summarise: SCHED_ULE: rtprio 10: network activity causes audio underruns SCHED_ULE: setprio -20: network activity causes audio underruns SCHED_4BSD: rtprio 10: no audio underruns SCHED_4BSD: setprio -20: no audio underruns For what it's worth, my audio buffering setup has a fragment size of 0.7ms, but several buffers. How is device driver activity prioritized? Does the scheduler in use effect how device interrupts are handled, as well as user-land tasks? I have kernels built with both schedulers sitting arround on this machine now, so it's easy to switch back and forth if there are some specific tests that I could do or other information that I could provide. Cheers, Andrew From owner-freebsd-arch@FreeBSD.ORG Thu Aug 28 01:26:11 2008 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 1EFC4106564A for ; Thu, 28 Aug 2008 01:26:11 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id A17228FC18 for ; Thu, 28 Aug 2008 01:26:10 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from kobe.laptop (adsl106-184.kln.forthnet.gr [77.49.225.184]) (authenticated bits=128) by igloo.linux.gr (8.14.3/8.14.3/Debian-5) with ESMTP id m7S1Cx0A007871 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 28 Aug 2008 04:13:05 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.2/8.14.2) with ESMTP id m7S1Cxue090781; Thu, 28 Aug 2008 04:12:59 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.14.2/8.14.2/Submit) id m7S1CwsH090780; Thu, 28 Aug 2008 04:12:58 +0300 (EEST) (envelope-from keramida@freebsd.org) From: Giorgos Keramidas To: Chuck Robey References: <48B58846.6040400@telenix.org> Date: Thu, 28 Aug 2008 04:12:58 +0300 In-Reply-To: <48B58846.6040400@telenix.org> (Chuck Robey's message of "Wed, 27 Aug 2008 13:00:54 -0400") Message-ID: <8763pmt011.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-MailScanner-ID: m7S1Cx0A007871 X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-4.29, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.11, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No Cc: FreeBSD-arch@freebsd.org Subject: Re: an argument of make(1) 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, 28 Aug 2008 01:26:11 -0000 On Wed, 27 Aug 2008 13:00:54 -0400, Chuck Robey wrote: > I am posting this to our arch list; if I'm wrong, we can move this. I > want to argue for some changes to our great make(1) tool. > > I've long been a fan of make, and in particular, FreeBSD's make. In > my own career, I've often had to do more custom creation of Makefiles, > and while there are some folks here who definitely DO know our make > better, I think I can honestly say I know it pretty well. In creating > tools for customers, I've often been forced, unwillingly, to go to the > GNU make tool. The reason is just one of compatibility. There are > several different reasons for this, which I want to list: I can certainly feel the `pain' of reluctantly choosing GNU make, or even of going the automake/autoconf/libtool way. I have written a fair amount of build glue myself too, and I know that I'd love to have BSD make in other systems too. Since the topic of (re)using FreeBSD make on non-BSD platforms seems to pop up more or less every 4-6 months the last year, I've started at least two attempts at porting 'FreeBSD make' to non BSD systems. The last attempt was aiming for a 'clean' set of minimal changes to the source of make. And it's done. At least the *binary* of make builds and tries to pull bsd.*.mk files on Linux and Solaris 10 here. The actual *source* code changes needed to build a BSD-make executable on Linux are pretty 'small': keramida@mithra:/home/keramida/tools$ uname -a Linux mithra 2.6.24-19-generic #1 SMP Fri Jul 11 23:41:49 UTC 2008 i686 GNU/Linux keramida@mithra:/home/keramida/tools$ hg short -r1 1:664527963082 | 2008-07-25 16:47 +0300 | keramida: Import FreeBSD make-20080724 snapshot (svn 180782) The diff from the first snapshot import of FreeBSD make touches only a few files: keramida@mithra:/home/keramida/tools$ hg diff -r 1:tip bin/make | diffstat -p1 bin/make/Makefile | 8 +++++- bin/make/compat.c | 67 +++++++++++++++++++++++++++++++++++++++++++++++++++ bin/make/compat.h | 36 +++++++++++++++++++++++++++ bin/make/job.c | 8 +++++- bin/make/main.c | 17 ++++++++++++ bin/make/pathnames.h | 2 - 6 files changed, 135 insertions(+), 3 deletions(-) keramida@mithra:/home/keramida/tools$ Now I'm looking for some spare time to clean-up the changes a bit and integrate them in `http://hg.hellug.gr/bmake/gker/'. The tricky part is, however, that a lot of the functionality of make(1) depends on the `share/mk/bsd.*.mk' files. I have finished writing the automake glue that installs these in `$prefix/share/mk' but now I am kind of stuck while thinking about a good way to make the bsd.*.mk files actually usable on, say, FreeBSD, Linux and Solaris. > 1) while the GNU make has the -v to allow one to both identify the > tool and the version, FreeBSD's make has no such facility, that I'm > aware of. You can't test & capture the type of make here, except by > the rather inadequate trapping of getting no response at all. Both -v and -V are taken, and I don't really like the idea of adding long options to make(1). Maybe we can partially ``hijack'' the -v option to also display a verbose version string, i.e.: % make -v FreeBSD make (version 5200408120) make: no target to make. % It's probably ok to print a version number when 'being extra verbose' :) > OK, that'st the major argument. I'm going to ask for one thing here, > but it's truly extra, just my own bias's showing thru. I wish that a > fair number of the changes that have gone into make be taken back. > I'm not talking about those that enhanced it's operation, I'm talking > about all of the changes that, while trying to increase the elegance > of the code, have really destroyed it's porrting portability, in a > major way. Make used to depend on a smaller set of libraries, and > those libraries were largely those available on other systems, so the > task for a programmer, to port our make(1) to a different platform > wasn't all that hard to do. Nowadays, with a great number of the > changes having been crafted to change dependencies to FreeBSD-only > tools, it's a real bear to port it. make(1) is actually pretty 'easy' to compile on, say, Linux, as I wrote above. The only bits that are missing on Linux are: * An errc() function. I added one in compat.c of my diffstat output above, and this accounts for most of the lines in the patches. * Our make(1) uses arc4random(). #ifdef HAVE_ARC4RANDOM and a few lines to call srandom() or srandomdev() and random() when it's unavailable are probably `ok' for this. * FreeBSD make uses getprogname(), but saving argv[0] and re-using that is trivial to add when HAVE_GETPROGNAME if undefined. * On FreeBSD/pc98 systems make tries to get the value of the "machdep.ispc98" by calling sysctlbyname("machdep.ispc98", ...). Since this part of the code is to be able to build make on pre-7.0 FreeBSD/pc98 systems, it may be ok to #ifdef HAVE_SYSCTLBYNAME and ignore this compatibility code on non-FreeBSD systems. This pretty much sums all the source code changes I had to make to build on Linux and Solaris. I'll see how much of the changes I can clean up and post online at `http://hg.hellug.gr/bmake/gker/'. It should be pretty easy, so please ping me in a couple of days if I haven't followed up with an "ACK, all done now". The 'porting' of share/mk/bsd.*.mk files may be a bit trickier, and it may even turn out to be much more difficult. I can certainly use all the help I can get there... - Giorgos From owner-freebsd-arch@FreeBSD.ORG Thu Aug 28 03:34:10 2008 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 16CBE1065670 for ; Thu, 28 Aug 2008 03:34:10 +0000 (UTC) (envelope-from joseph.koshy@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by mx1.freebsd.org (Postfix) with ESMTP id C70FF8FC12 for ; Thu, 28 Aug 2008 03:34:09 +0000 (UTC) (envelope-from joseph.koshy@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so108254yxb.13 for ; Wed, 27 Aug 2008 20:34:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=GG5tnENWxPSSuP9DOekXfXs8xkW8EDgNiH05AgdErUQ=; b=FWVXsgnPXY1s6pbTwkQNfoCVlveYY7JusVL9MkOBA2hfc2d02lcT/dwvcNe70et0Mz HtaOJ0TdihcqpK/4AMJD+AG1AhB2LJ76YmuwFMslT3dV2MXtxCzz0kEzRAdvJM16oSzB 6rWT+Ar9c5TiPVkL/P+2U6tvcFQ7E6elJCT1g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=KYbj4rvv25ZteMuKVptVLAqh8FL1jwPokH4+Peejpoatpw6hM+eFS5W7PfQYzu22WH n/P5+JQG+L93tZiVxBTZ72DGzhJ8IqQo3qtHlExzDtjdqUVB5SKAgKRfpBs6PFOB++pR xjI68kiyF9GKUIrV4TRQBb6XPwHql+fDsRd6g= Received: by 10.151.84.12 with SMTP id m12mr1336340ybl.11.1219892831146; Wed, 27 Aug 2008 20:07:11 -0700 (PDT) Received: by 10.150.92.17 with HTTP; Wed, 27 Aug 2008 20:07:11 -0700 (PDT) Message-ID: <84dead720808272007l9643d45idcbbafa384185370@mail.gmail.com> Date: Thu, 28 Aug 2008 08:37:11 +0530 From: "Joseph Koshy" To: "Chuck Robey" In-Reply-To: <48B58846.6040400@telenix.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48B58846.6040400@telenix.org> Cc: FreeBSD-arch@freebsd.org Subject: Re: an argument of make(1) 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, 28 Aug 2008 03:34:10 -0000 > hard to do. Nowadays, with a great number of the changes having been crafted to > change dependencies to FreeBSD-only tools, it's a real bear to port it. If you are looking for a portable BSD-compatible make(1) you could try the "portable" version of NetBSD's make(1). This is available at: http://www.crufty.net/help/sjg/bmake.html There are a small number of differences between the languages accepted by this make and FreeBSD make, but for the most part they are compatible. Koshy From owner-freebsd-arch@FreeBSD.ORG Thu Aug 28 10:37:13 2008 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 E5C61106568A; Thu, 28 Aug 2008 10:37:13 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout3.freenet.de (mout3.freenet.de [IPv6:2001:748:100:40::2:5]) by mx1.freebsd.org (Postfix) with ESMTP id 7F4CA8FC18; Thu, 28 Aug 2008 10:37:13 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from [195.4.92.18] (helo=8.mx.freenet.de) by mout3.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #19) id 1KYesI-0000en-M0; Thu, 28 Aug 2008 12:37:10 +0200 Received: from m84fa.m.pppool.de ([89.49.132.250]:49195 helo=peedub.jennejohn.org) by 8.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #12) id 1KYesI-0005K0-Db; Thu, 28 Aug 2008 12:37:10 +0200 Date: Thu, 28 Aug 2008 12:37:08 +0200 From: Gary Jennejohn To: Andrew Reilly Message-ID: <20080828123708.45964271@peedub.jennejohn.org> In-Reply-To: <20080827233831.GA16705@duncan.reilly.home> References: <20080819025019.GA27997@duncan.reilly.home> <20080818215813.H952@desktop> <20080819134005.GA85664@duncan.reilly.home> <20080820214627.C30593@desktop> <20080827233831.GA16705@duncan.reilly.home> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.10.14; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-multimedia@freebsd.org, freebsd-arch@freebsd.org Subject: Re: SCHED_ULE problem: slow single processor, realtime prio vs network stack X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2008 10:37:14 -0000 On Thu, 28 Aug 2008 09:38:31 +1000 Andrew Reilly wrote: > On Wed, Aug 20, 2008 at 09:47:01PM -1000, Jeff Roberson wrote: > > On Tue, 19 Aug 2008, Andrew Reilly wrote: > > >I haven't tried nice -20 because I don't want the priority to > > >drift or change, which is something that I thought the normal > > >levels did. I'll give it a go though, and report back. > > > > With such a low cpu utilization I wouldn't expect it's the scheduling > > algorithm. It may be a difference in preemption settings. Is preemption > > enabled in both kernels? > > I've just done a set of tests with setprio(... -20) vs > rtprio(...10), and with SCHED_ULE vs SCHED_4BSD. The results > are essentially as I reported before except that regular prio > -20 seems to be just as reliable as rtprio 10 under 4BSD and > just as unhelpful under _ULE. > > To summarise: > > SCHED_ULE: rtprio 10: network activity causes audio underruns > SCHED_ULE: setprio -20: network activity causes audio underruns > SCHED_4BSD: rtprio 10: no audio underruns > SCHED_4BSD: setprio -20: no audio underruns > > For what it's worth, my audio buffering setup has a fragment > size of 0.7ms, but several buffers. How is device driver > activity prioritized? Does the scheduler in use effect how > device interrupts are handled, as well as user-land tasks? > > I have kernels built with both schedulers sitting arround on > this machine now, so it's easy to switch back and forth if there > are some specific tests that I could do or other information > that I could provide. > Ah yes, but do you have options PREEMPTION set, which was Jeff's question? --- Gary Jennejohn From owner-freebsd-arch@FreeBSD.ORG Thu Aug 28 11:03:39 2008 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 507491065699 for ; Thu, 28 Aug 2008 11:03:39 +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 16DB18FC19 for ; Thu, 28 Aug 2008 11:03:39 +0000 (UTC) (envelope-from des@des.no) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 4D7D92049; Thu, 28 Aug 2008 13:03:38 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id 38A1884499; Thu, 28 Aug 2008 13:03:38 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Chuck Robey References: <48B58846.6040400@telenix.org> Date: Thu, 28 Aug 2008 13:03:38 +0200 In-Reply-To: <48B58846.6040400@telenix.org> (Chuck Robey's message of "Wed, 27 Aug 2008 13:00:54 -0400") Message-ID: <86zlmx4d11.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD-arch@FreeBSD.org Subject: Re: an argument of make(1) 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, 28 Aug 2008 11:03:39 -0000 Chuck Robey writes: > [BSD make should really be GNU make] cd /usr/ports/devel/automake110 make install clean DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Thu Aug 28 11:14:58 2008 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 772291065674; Thu, 28 Aug 2008 11:14:56 +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 4BFBE8FC32; Thu, 28 Aug 2008 11:14:56 +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 62CC946C8A; Thu, 28 Aug 2008 07:14:55 -0400 (EDT) Date: Thu, 28 Aug 2008 12:14:55 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Attilio Rao In-Reply-To: <3bbf2fe10808270955y53b00587m1991e7bf898466e1@mail.gmail.com> Message-ID: References: <3bbf2fe10808270955y53b00587m1991e7bf898466e1@mail.gmail.com> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Arch , Konstantin Belousov Subject: Re: Kernel decontextualization -- idea and little proof-of-concept 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, 28 Aug 2008 11:14:58 -0000 On Wed, 27 Aug 2008, Attilio Rao wrote: > Small Q&A about possible concerns: > Q: Sometimes we need to pass a thread in order to get his credentials, > how you will handle this? > A: We will simply get the ucred pointed and will switch the thread > argument to be a credential I tend to agree with the approach you are proposing, and have been considering similar changes for the network stack for much the same reasons. Thre points: (1) We may need to explicitly pass one or more credentials in places where we don't currently do so. This is certainly true in the network stack, and similar considerations in VFS wouldn't surprise me. Most frequently, this construct is used when work occurs in an asynchronous context from the requesting thread and use of the original authorizing credential is required. (2) Keep a careful eye out for cases where an implicit use of the passed thread is to establish context for copyin(9). You might argue that copyin(9) should accept an address space or thread argument and then assert that it is the current one... (3) Take a look at the on-going virtualization work, as we may want to apply the same virtualization techniques to VFS in the future, in which case we'll need to make sure that the approaches are compatible. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-arch@FreeBSD.ORG Thu Aug 28 14:28:33 2008 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 020FD1065685 for ; Thu, 28 Aug 2008 14:28:33 +0000 (UTC) (envelope-from andrew-freebsd@areilly.bpc-users.org) Received: from nschwqsrv02p.mx.bigpond.com (nschwqsrv02p.mx.bigpond.com [61.9.189.234]) by mx1.freebsd.org (Postfix) with ESMTP id 828AC8FC1E for ; Thu, 28 Aug 2008 14:28:32 +0000 (UTC) (envelope-from andrew-freebsd@areilly.bpc-users.org) Received: from nschwotgx02p.mx.bigpond.com ([124.188.162.219]) by nschwmtas05p.mx.bigpond.com with ESMTP id <20080828124221.LYAR6339.nschwmtas05p.mx.bigpond.com@nschwotgx02p.mx.bigpond.com> for ; Thu, 28 Aug 2008 12:42:21 +0000 Received: from areilly.bpa.nu ([124.188.162.219]) by nschwotgx02p.mx.bigpond.com with ESMTP id <20080828124215.LWER11844.nschwotgx02p.mx.bigpond.com@areilly.bpa.nu> for ; Thu, 28 Aug 2008 12:42:15 +0000 Received: (qmail 87941 invoked from network); 28 Aug 2008 12:41:29 -0000 Received: from localhost (HELO duncan.reilly.home) (127.0.0.1) by localhost with SMTP; 28 Aug 2008 12:41:29 -0000 Date: Thu, 28 Aug 2008 22:41:29 +1000 From: Andrew Reilly To: gary.jennejohn@freenet.de Message-ID: <20080828224129.5fa7c8da@duncan.reilly.home> In-Reply-To: <20080828123708.45964271@peedub.jennejohn.org> References: <20080819025019.GA27997@duncan.reilly.home> <20080818215813.H952@desktop> <20080819134005.GA85664@duncan.reilly.home> <20080820214627.C30593@desktop> <20080827233831.GA16705@duncan.reilly.home> <20080828123708.45964271@peedub.jennejohn.org> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; amd64-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150203.48B69D28.0054,ss=1,fgs=0 Cc: freebsd-multimedia@freebsd.org, freebsd-arch@freebsd.org Subject: Re: SCHED_ULE problem: slow single processor, realtime prio vs network stack 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, 28 Aug 2008 14:28:33 -0000 On Thu, 28 Aug 2008 12:37:08 +0200 Gary Jennejohn wrote: > Ah yes, but do you have options PREEMPTION set, which was Jeff's question? I believe that I answered that question in an earlier post, but for what it's worth, the answer is an emphatic "yes": PREEMPTION is turned on in GENERIC (along with _KPOSIX_PRIORITY_SCHEDULING and SMB), and my (posted) kernel config is essentially include GENERIC, turn off I486_CPU and I586_CPU, and override SCHED_ULE (or not). So unless the config include mechanism is broken, I've got PREEMPTION, (and so has nearly everyone else). Cheers, Andrew From owner-freebsd-arch@FreeBSD.ORG Thu Aug 28 22:53:13 2008 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 37E471065671 for ; Thu, 28 Aug 2008 22:53:13 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from nskntmtas04p.mx.bigpond.com (nskntmtas04p.mx.bigpond.com [61.9.168.146]) by mx1.freebsd.org (Postfix) with ESMTP id B0FA88FC0C for ; Thu, 28 Aug 2008 22:53:12 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from nskntotgx02p.mx.bigpond.com ([124.188.162.219]) by nskntmtas04p.mx.bigpond.com with ESMTP id <20080828225310.WLGK15769.nskntmtas04p.mx.bigpond.com@nskntotgx02p.mx.bigpond.com> for ; Thu, 28 Aug 2008 22:53:10 +0000 Received: from areilly.bpa.nu ([124.188.162.219]) by nskntotgx02p.mx.bigpond.com with ESMTP id <20080828225310.ZNII15766.nskntotgx02p.mx.bigpond.com@areilly.bpa.nu> for ; Thu, 28 Aug 2008 22:53:10 +0000 Received: (qmail 53783 invoked by uid 501); 28 Aug 2008 22:53:00 -0000 Date: Fri, 29 Aug 2008 08:53:00 +1000 From: Andrew Reilly To: =?utf-8?B?6YKx5YmR?= Message-ID: <20080828225300.GA51771@duncan.reilly.home> References: <20080827233831.GA16705@duncan.reilly.home> <000c01c908db$f78d9180$01000001@china.huawei.com> <20080828071804.GA54269@duncan.reilly.home> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20080828071804.GA54269@duncan.reilly.home> User-Agent: Mutt/1.4.2.3i X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150204.48B72C56.004A,ss=1,fgs=0 Cc: freebsd-multimedia@freebsd.org, freebsd-arch@freebsd.org Subject: Re: SCHED_ULE problem: slow single processor, realtime prio vs network stack 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, 28 Aug 2008 22:53:13 -0000 On Thu, Aug 28, 2008 at 05:18:04PM +1000, Andrew Reilly wrote: > Hi Jian, > > On Thu, Aug 28, 2008 at 03:01:59PM +0800, 邱剑 wrote: > > I found the network interrupt thread might take too long to run if > > net.isr.direct=1 > > > > I suspect your problem might be because the network kernel thread spend so > > long time that the sound interrupt could not find time slot to process. > > That sounds like what I think is happening, but I'm still > curious about why the same network stack manaages to be > interrupted by the audio driver when running the 4BSD scheduler, > but not the ULE sheduler. > > > You might just try to turn netisr off when running ULE > > > > sysctl -w net.isr.direct=0 > > I'll give that a try, as soon as possible. As promised to Jian, here's my report on how or whether that helped: no. If anything, it seemed to make the network-induced breakup of the audio timing a little worse, but I did no measurements to verify that impression. Thanks for the suggestion, though. Cheers, Andrew From owner-freebsd-arch@FreeBSD.ORG Thu Aug 28 23:53:34 2008 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 91B7910656A6 for ; Thu, 28 Aug 2008 23:53:34 +0000 (UTC) (envelope-from chuckr@telenix.org) Received: from mail7.sea5.speakeasy.net (mail7.sea5.speakeasy.net [69.17.117.9]) by mx1.freebsd.org (Postfix) with ESMTP id 4AB108FC1B for ; Thu, 28 Aug 2008 23:53:34 +0000 (UTC) (envelope-from chuckr@telenix.org) Received: (qmail 25838 invoked from network); 28 Aug 2008 23:53:34 -0000 Received: from april.chuckr.org (HELO april.telenix.org) (chuckr@[66.92.151.30]) (envelope-sender ) by mail7.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 28 Aug 2008 23:53:33 -0000 Message-ID: <48B73A0B.401@telenix.org> Date: Thu, 28 Aug 2008 19:51:39 -0400 From: Chuck Robey User-Agent: Thunderbird 2.0.0.6 (X11/20071107) MIME-Version: 1.0 To: Alfred Perlstein References: <48B58846.6040400@telenix.org> <20080827174530.GZ16977@elvis.mu.org> In-Reply-To: <20080827174530.GZ16977@elvis.mu.org> X-Enigmail-Version: 0.95.5 OpenPGP: id=F3DCA0E9; url=http://pgp.mit.edu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD-arch@FreeBSD.org Subject: Re: an argument of make(1) 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, 28 Aug 2008 23:53:34 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alfred Perlstein wrote: > The only excuse I have for top posting here is that I agree > with the entirety of this email. Well, thanks, I wanted to get a feeling if I was alone in feeling this way; I guess I'm not. With this in mind, I've ported our BSD make tool twice (I lost my first try, felt fairly stupid for having to do it twice). Now I have this much agreement, I feel good enough about this to begin my own effort to make all the changes I asked for. I intend to code up changes in separate patches, so folks won't get a "all or nothing" option from me. My only problem in this is, since my health went bad on me, now I'm kinda more disabled than I used to me, I can't work as many hours as I used to, so it's definitely going to make me longer than most others. On top of this, I honestly don't cooperate all that well. I can take orders fine, but I generally either do it all or let YOU do it all, I'm just not a really great team player. So, if you have the time, leave it to me, I'll get it done, but if you want it soon, well, you might want to do it yourself. Other than that, I don't much see where this needs more discussion right now, unless someone has some more suggestions about what changes you want. I'm only (myself) interested in code portability, version options, and make conditionals test capabilities. I don't really want to craft a copy of GNU make. We can discuss this more when I have patches to show off. Once again, thanks for the clear, rapid response. > > -Alfred > > * Chuck Robey [080827 10:28] wrote: > I am posting this to our arch list; if I'm wrong, we can move this. I want to > argue for some changes to our great make(1) tool. > > I've long been a fan of make, and in particular, FreeBSD's make. In my own > career, I've often had to do more custom creation of Makefiles, and while there > are some folks here who definitely DO know our make better, I think I can > honestly say I know it pretty well. In creating tools for customers, I've > often been forced, unwillingly, to go to the GNU make tool. The reason is just > one of compatibility. There are several different reasons for this, which I > want to list: > > 1) while the GNU make has the -v to allow one to both identify the tool and the > version, FreeBSD's make has no such facility, that I'm aware of. You can't test > & capture the type of make here, except by the rather inadequate trapping of > getting no response at all. > > 2) while some parts of our make don't advertise it, they can be made compatible > to the gmake's tools. "include" is a good example (the FreeBSD "include" docs > claim that it only works as ".include", but that's a prevarication (and a very > good thing it is). What I'd like to argue for is that some things like "if" > have their compatibility with gmake enhanced. No, don't make it a mirror image, > just make it possible for a programmer to craft a limited set of tests that will > work in both places. > > If you give programmers the ability to detect what make they're in, the ability > to craft a limited set of compatible tests, and also the other side (endif > stuff) then everything else for portability can be done by using those limits. > > If something like this were done, then it allows a programmer, finally, to write > a REALLY portable makefile. It would still allow one to make use of all of > make(1)'s great command set, but not to kill it's use in a gmake-only system. > > OK, that'st the major argument. I'm going to ask for one thing here, but it's > truly extra, just my own bias's showing thru. I wish that a fair number of the > changes that have gone into make be taken back. I'm not talking about those > that enhanced it's operation, I'm talking about all of the changes that, while > trying to increase the elegance of the code, have really destroyed it's porrting > portability, in a major way. Make used to depend on a smaller set of libraries, > and those libraries were largely those available on other systems, so the task > for a programmer, to port our make(1) to a different platform wasn't all that > hard to do. Nowadays, with a great number of the changes having been crafted to > change dependencies to FreeBSD-only tools, it's a real bear to port it. > > The code involved is nearly all very, very portable; it's the way that the > libraries have been constituted that makes porting this a really bad job. If > someone would make up a libmake.so.1, which in itself could be make really > portable, that would also go a great long way to improving the popularity of our > make(1). I'm NOT asking to roll back any of the distinct improvements that have > gone in, only the changes that ruined it's porting-ability (yea, that's > portabilty, I just wanted to really point that out again). > > OK, if someone were to come up with swuch a set of changes, would they be dead > on arrival? I know that no one gets prior approval for FreeBSD (I completely > agree with that), just didn't want to be totally at odds with everyone, if I'm > the only one who sees it this way. > > Thanks for your time. _______________________________________________ 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" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAki3OgsACgkQz62J6PPcoOl00gCgjo1YlwlDSrcahO8DK+VijWx/ w90An028vyzNklvjS97D/yv5qO+IDquP =ADNQ -----END PGP SIGNATURE-----