From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 10 07:41:34 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CE67F16A421 for ; Sun, 10 Jun 2007 07:41:34 +0000 (UTC) (envelope-from dunceor@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.174]) by mx1.freebsd.org (Postfix) with ESMTP id 6B4DB13C487 for ; Sun, 10 Jun 2007 07:41:34 +0000 (UTC) (envelope-from dunceor@gmail.com) Received: by ug-out-1314.google.com with SMTP id u2so1421661uge for ; Sun, 10 Jun 2007 00:41:33 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=hwND15vzmUt3obYXl5A4Zbvw2Kf/oKmbLL5HIFUlPvAIh4c8u9EfUCcYATSjGGOL6/0D7NHmW3U1kvdxtonZwURFYXcl32sxl/dnP106ovW6f+CMaDsdYuvL6hRrcIuHQMPQP3PNVKJvdovVDx6+VO3sArHknKKgjUt9Y5O0MQo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=XVRGcrlyKaIOg4rqETIN64yrJQscLRmGHC5htU+irHHzVa6HK02UnEU2XIiyLa4LFNjbdvIladn38k6yD5K+Pf6N9aqXMOgS9UGygiolIyvJM253sJ/kS/CbyYetcuzhb/Nfh0uzD6BgOMy/w13vgRrHWZnGDYERnmLEJV5Vjys= Received: by 10.82.105.13 with SMTP id d13mr8462035buc.1181461293075; Sun, 10 Jun 2007 00:41:33 -0700 (PDT) Received: by 10.82.191.11 with HTTP; Sun, 10 Jun 2007 00:41:33 -0700 (PDT) Message-ID: <5d84cb30706100041r3dee5ff8s1731b62943c55538@mail.gmail.com> Date: Sun, 10 Jun 2007 09:41:33 +0200 From: "=?UTF-8?Q?Karl_Sj=C3=B6dahl_-_dunceor?=" To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: "Jun-ichiro itojun Hagino 2.0" Subject: IPv6 ANSI cleanup X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2007 07:41:34 -0000 Hello. I made diffs to ANSI the IPv6 stack in both OpenBSD and NetBSD and here comes my version for FreeBSD. NetBSD has already commited their diff and it would be good if all the *BSD have the same style for it. Diff can be found here: http://213.113.152.10/freebsd_ipv6.diff br dunceor From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 10 11:56:33 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EF45716A41F; Sun, 10 Jun 2007 11:56:33 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (vlk.vlakno.cz [62.168.28.247]) by mx1.freebsd.org (Postfix) with ESMTP id A91B113C45A; Sun, 10 Jun 2007 11:56:33 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id D26E68BDF4B; Sun, 10 Jun 2007 13:56:31 +0200 (CEST) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (vlk.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H3YTmxnyzh9y; Sun, 10 Jun 2007 13:56:30 +0200 (CEST) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id BC39D65B769; Sun, 10 Jun 2007 13:56:30 +0200 (CEST) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.13.8/8.13.8/Submit) id l5ABuUUh028544; Sun, 10 Jun 2007 13:56:30 +0200 (CEST) (envelope-from rdivacky) Date: Sun, 10 Jun 2007 13:56:30 +0200 From: Roman Divacky To: Ivan Voras Message-ID: <20070610115630.GA28518@freebsd.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: file(1) cannot detect UFS2? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2007 11:56:34 -0000 On Sun, Jun 10, 2007 at 12:41:31AM +0200, Ivan Voras wrote: > Hi! > > I'm trying to use file(1) to detect file system type on partitions, and > so far it's working for any file system I've cared to try (the usual MS > and Linux list) *except* UFS2. > > Detecting UFS1 works, though much more verbosely than it needs to be, > but UFS2 isn't detected at all. > > I'd like to ask someone familiar with UFS2 to take a quick peak and add > the appropriate rules to the file(1) magic database, if anyone's interested. > > At the very least, I need someone to commit this patch: well... yeah but not to freebsd :) I guess you want to forward the patch upstream to the maintainers of file. thnx for the work though From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 10 13:21:02 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A182D16A476 for ; Sun, 10 Jun 2007 13:21:02 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id DF69213C457 for ; Sun, 10 Jun 2007 13:21:01 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HxNKA-0007Fo-Lf for freebsd-hackers@freebsd.org; Sun, 10 Jun 2007 15:19:18 +0200 Received: from 78-0-92-215.adsl.net.t-com.hr ([78.0.92.215]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 10 Jun 2007 15:19:18 +0200 Received: from ivoras by 78-0-92-215.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 10 Jun 2007 15:19:18 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Date: Sun, 10 Jun 2007 15:16:12 +0200 Lines: 39 Message-ID: References: <20070610115630.GA28518@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig85221317F54B68E17862879E" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 78-0-92-215.adsl.net.t-com.hr User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) In-Reply-To: <20070610115630.GA28518@freebsd.org> X-Enigmail-Version: 0.94.3.0 Sender: news Cc: freebsd-fs@freebsd.org Subject: Re: file(1) cannot detect UFS2? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2007 13:21:02 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig85221317F54B68E17862879E Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Roman Divacky wrote: > well... yeah but not to freebsd :) I guess you want to forward the pat= ch upstream > to the maintainers of file. Thanks. By a happy coincedence, it's already there, in version 4.21! ---- 42332 belong 0x19540119 Unix Fast File system [v2] (big-endian) >&-1164 string x last mounted on %s, >&-696 string >\0 volume name %s, >&-304 beqldate x last written at %s, ---- Now there's only the matter of importing it :) --------------enig85221317F54B68E17862879E 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.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGa/moldnAQVacBcgRAjnzAJ44boWdavbjI3wyqTMQuipbupefbQCg1Yj8 8xI4zx+nO+zz2K2mIAA5y4s= =zsl/ -----END PGP SIGNATURE----- --------------enig85221317F54B68E17862879E-- From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 10 13:50:00 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2E6A116A46D for ; Sun, 10 Jun 2007 13:50:00 +0000 (UTC) (envelope-from maslanbsd@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.236]) by mx1.freebsd.org (Postfix) with ESMTP id E62A113C448 for ; Sun, 10 Jun 2007 13:49:59 +0000 (UTC) (envelope-from maslanbsd@gmail.com) Received: by nz-out-0506.google.com with SMTP id 14so889041nzn for ; Sun, 10 Jun 2007 06:49:58 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=r/ocK0G1G/rJey/a2NT60m70/vHM5oPPWVbPd3An24ROr/s0Wqtf64dLP0kukB0Ypj96Sco+31r3Z5hdKmQZbyDJHMkZOPXdmI9ZRAmzaW0F+STNZTxZ0c6vuiTxf/JuaE5Ol85/Ytgj1+3wKYgKl4MNYz1xXPl4ZX+j0SHki9c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=kxdOjrX2UNf32ce1euLqiVBM8x+0N1+fZDB2yK7FyPOfMKTr/AMpONC4CUk2tyzCdXXCNuNZlXV+opBIyNnjbQNxA9eAhs/yFUZyyiuT3yRyyj1O2FNY0mEcEv4uMVIA+F1273MySVvf8PmqrJvc3Nts2p78/tvZflq4lhmZxzc= Received: by 10.142.102.5 with SMTP id z5mr236200wfb.1181483398289; Sun, 10 Jun 2007 06:49:58 -0700 (PDT) Received: by 10.142.101.12 with HTTP; Sun, 10 Jun 2007 06:49:58 -0700 (PDT) Message-ID: <319cceca0706100649w110a5c5m18d96e2a91d909b@mail.gmail.com> Date: Sun, 10 Jun 2007 16:49:58 +0300 From: Maslan To: "FreeBSD Hackers" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Ricoh r5u870 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2007 13:50:00 -0000 Hi, Is there is any one working on Ricoh r5u870 webcam driver ? Ricoh r5u870 known as hp webcam. Thanks -- System Programmer I'm Searching For Perfection, So Even If U Need Potability U've To Use Assembly ;-) -- http://libosdk.berlios.de/wiki/ From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 10 13:50:22 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 05AB616A468; Sun, 10 Jun 2007 13:50:22 +0000 (UTC) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.freebsd.org (Postfix) with ESMTP id 7F35D13C448; Sun, 10 Jun 2007 13:50:21 +0000 (UTC) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: from ednmsw510.dsto.defence.gov.au (ednmsw510.dsto.defence.gov.au [131.185.68.11]) by digger1.defence.gov.au (8.13.8/8.13.8) with ESMTP id l5ADOog0020363; Sun, 10 Jun 2007 22:54:50 +0930 (CST) Received: from ednex510.dsto.defence.gov.au (ednex510.dsto.defence.gov.au) by ednmsw510.dsto.defence.gov.au (Clearswift SMTPRS 5.2.9) with ESMTP id ; Sun, 10 Jun 2007 23:04:40 +0930 Received: from obelix.dsto.defence.gov.au ([203.6.60.208]) by ednex510.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.1830); Sun, 10 Jun 2007 23:04:40 +0930 Received: from obelix.dsto.defence.gov.au (localhost [127.0.0.1]) by obelix.dsto.defence.gov.au (8.13.8/8.13.8) with ESMTP id l5ADYRLp024033; Sun, 10 Jun 2007 21:34:27 +0800 (WST) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by obelix.dsto.defence.gov.au (8.13.8/8.13.8/Submit) id l5ADYRKj024032; Sun, 10 Jun 2007 21:34:27 +0800 (WST) (envelope-from wilkinsa) Date: Sun, 10 Jun 2007 21:34:27 +0800 From: "Wilkinson, Alex" To: freebsd-hackers@freebsd.org, freebsd-fs@freebsd.org Message-ID: <20070610133427.GA24008@obelix.dsto.defence.gov.au> Mail-Followup-To: freebsd-hackers@freebsd.org, freebsd-fs@freebsd.org References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: Organisation: Defence Science Technology Organisation User-Agent: Mutt/1.5.15 (2007-04-06) X-OriginalArrivalTime: 10 Jun 2007 13:34:40.0849 (UTC) FILETIME=[1909A410:01C7AB64] X-TM-AS-Product-Ver: SMEX-7.0.0.1526-3.6.1039-15226.001 X-TM-AS-Result: No-1.528400-8.000000-31 Content-Transfer-Encoding: 7bit Cc: Subject: Re: file(1) cannot detect UFS2? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2007 13:50:22 -0000 0n Sun, Jun 10, 2007 at 12:41:31AM +0200, Ivan Voras wrote: >I'm trying to use file(1) to detect file system type on partitions, and >so far it's working for any file system I've cared to try (the usual MS >and Linux list) *except* UFS2. Not sure if what you're doing *has* to be done with file(1). However, you can what you want like so: #dumpfs ad0s1a | head -1 magic 19540119 (UFS2) time Sun Jun 10 21:30:45 2007 -aW IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 10 13:55:59 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D6DFD16A421 for ; Sun, 10 Jun 2007 13:55:59 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 8964813C46A for ; Sun, 10 Jun 2007 13:55:59 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HxNtT-0007Bu-NZ for freebsd-hackers@freebsd.org; Sun, 10 Jun 2007 15:55:47 +0200 Received: from 78-0-92-215.adsl.net.t-com.hr ([78.0.92.215]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 10 Jun 2007 15:55:47 +0200 Received: from ivoras by 78-0-92-215.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 10 Jun 2007 15:55:47 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Date: Sun, 10 Jun 2007 15:55:28 +0200 Lines: 39 Message-ID: References: <20070610133427.GA24008@obelix.dsto.defence.gov.au> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig52CBF69C654D8113FDC784EF" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 78-0-92-215.adsl.net.t-com.hr User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) In-Reply-To: <20070610133427.GA24008@obelix.dsto.defence.gov.au> X-Enigmail-Version: 0.94.3.0 Sender: news Cc: freebsd-fs@freebsd.org Subject: Re: file(1) cannot detect UFS2? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2007 13:55:59 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig52CBF69C654D8113FDC784EF Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Wilkinson, Alex wrote: > 0n Sun, Jun 10, 2007 at 12:41:31AM +0200, Ivan Voras wrote:=20 >=20 > >I'm trying to use file(1) to detect file system type on partitions= , and > >so far it's working for any file system I've cared to try (the usu= al MS > >and Linux list) *except* UFS2. >=20 > Not sure if what you're doing *has* to be done with file(1). > However, you can what you want like so: >=20 > #dumpfs ad0s1a | head -1 > magic 19540119 (UFS2) time Sun Jun 10 21:30:45 2007 So you're proposing one utility per possible file system instead of one utility total? :) --------------enig52CBF69C654D8113FDC784EF 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.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGbALQldnAQVacBcgRApW1AKCfQEPQVWXeM3qrXi2HbmD1hZRY8wCgipxM vwkmkElWbthVKrfkb9R0UbU= =Oy6m -----END PGP SIGNATURE----- --------------enig52CBF69C654D8113FDC784EF-- From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 10 14:46:18 2007 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E4DA216A400; Sun, 10 Jun 2007 14:46:18 +0000 (UTC) (envelope-from stsp@stsp.name) Received: from einhorn.in-berlin.de (einhorn.in-berlin.de [192.109.42.8]) by mx1.freebsd.org (Postfix) with ESMTP id 710E413C48C; Sun, 10 Jun 2007 14:46:18 +0000 (UTC) (envelope-from stsp@stsp.name) X-Envelope-From: stsp@stsp.name Received: from stsp.lan (stsp.in-vpn.de [217.197.85.96]) (authenticated bits=128) by einhorn.in-berlin.de (8.13.6/8.13.6/Debian-1) with ESMTP id l5AEk4EC005366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 10 Jun 2007 16:46:14 +0200 Received: from ted.stsp.lan (localhost [127.0.0.1]) by stsp.lan (8.13.8/8.13.8) with ESMTP id l5AEj6kQ008063; Sun, 10 Jun 2007 16:45:06 +0200 (CEST) (envelope-from stsp@stsp.name) Received: (from stsp@localhost) by ted.stsp.lan (8.13.8/8.13.8/Submit) id l5AEj4Tw008062; Sun, 10 Jun 2007 16:45:04 +0200 (CEST) (envelope-from stsp@stsp.name) X-Authentication-Warning: ted.stsp.lan: stsp set sender to stsp@stsp.name using -f Date: Sun, 10 Jun 2007 16:45:04 +0200 From: Stefan Sperling To: Edwin Mons , bug-followup@FreeBSD.org, freebsd-hackers@FreeBSD.org Message-ID: <20070610144504.GA7129@ted.stsp.lan> Mail-Followup-To: Edwin Mons , bug-followup@FreeBSD.org, freebsd-hackers@freebsd.org References: <466A6DF1.3020306@edwinm.ik.nu> <20070609103848.GA1465@ted.stsp.lan> <466AC23B.4040601@edwinm.ik.nu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dDRMvlgZJXvWKvBx" Content-Disposition: inline In-Reply-To: <466AC23B.4040601@edwinm.ik.nu> User-Agent: Mutt/1.5.15 (2007-04-06) X-Scanned-By: MIMEDefang_at_IN-Berlin_e.V. on 192.109.42.8 Cc: Subject: Re: kern/83807: [sis] [patch] if_sis: Wake On Lan support for FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2007 14:46:19 -0000 --dDRMvlgZJXvWKvBx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jun 09, 2007 at 05:07:39PM +0200, Edwin Mons wrote: > I currently have one -CURRENT machine, and several 6.2-STABLE machines. = For=20 > at least two of them (the -CURRENT and an x86 -STABLE machine) I'd reall= y=20 > like to have WoL support, as these are my workstation and a home server,= =20 > both of them really do not need to be on all the time, but I want to be = able=20 > to reach them when I need a file from them when I'm elsewhere. Yes, wake on lan, if used properly, makes computers a bit more friendly to the environment :-) > I usually use either if_em or if_xl chipsets, so I hoped landing this co= de=20 > in at least -CURRENT (should go there first, I guess) would result in mo= re=20 > chipsets supported ;) There is code for enabling wake on lan in the Linux drivers for both if_xl and if_em cards. See drivers/net/3c59x.c and drivers/net/e1000/e1000_ethtool.c in the linux source tree. So I don't think adding support for these cards is a problem. Just need to find some time to do it... If anyone has data sheets for these cards I'd like a copy if possible. By the way if anyone has data sheets for if_vr I'd like a copy as well please because there is something the Linux driver does that I do not understand because the code is not obvious enough. Specifically I need to understand what the hell they mean exactly by "patterns for WOL". > > If anyone has a card that does wake on lan after shutdown from Linux > > but not after shutdown from FreeBSD with my patch applied let me know. > > You may need to use the ethtool utility to enable WOL on Linux. >=20 > I don't run Linux on either machine. Perhaps I could do some tests on m= y=20 > workstation with a CD-based linux distribution. No need to test your cards with Linux since we know now there is code for this in Linux so it should work anyway. --=20 stefan http://stsp.name PGP Key: 0xF59D25F0 --dDRMvlgZJXvWKvBx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGbA5w5dMCc/WdJfARAsfRAKCAN99RWTQfOU94AG7q8DYcOkt40wCgxZmR gYO8dLu+kqvBDI3IQCpGg6E= =hPO/ -----END PGP SIGNATURE----- --dDRMvlgZJXvWKvBx-- From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 10 15:50:29 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A84FA16A468; Sun, 10 Jun 2007 15:50:29 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (vlk.vlakno.cz [62.168.28.247]) by mx1.freebsd.org (Postfix) with ESMTP id 6390A13C4B9; Sun, 10 Jun 2007 15:50:28 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id AF2778BDF3B; Sun, 10 Jun 2007 17:50:27 +0200 (CEST) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (vlk.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jRcmzXHf0M64; Sun, 10 Jun 2007 17:50:26 +0200 (CEST) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 6873065B769; Sun, 10 Jun 2007 17:50:26 +0200 (CEST) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.13.8/8.13.8/Submit) id l5AFoPip034066; Sun, 10 Jun 2007 17:50:25 +0200 (CEST) (envelope-from rdivacky) Date: Sun, 10 Jun 2007 17:50:25 +0200 From: Roman Divacky To: Ivan Voras Message-ID: <20070610155025.GA34035@freebsd.org> References: <20070610115630.GA28518@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: file(1) cannot detect UFS2? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2007 15:50:29 -0000 > Now there's only the matter of importing it :) > you mean... like was done 2 weeks ago? :) From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 10 16:10:20 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A067616A468 for ; Sun, 10 Jun 2007 16:10:20 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 55F9413C457 for ; Sun, 10 Jun 2007 16:10:20 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1HxPzO-0003tm-N7 for freebsd-hackers@freebsd.org; Sun, 10 Jun 2007 18:10:02 +0200 Received: from 78-0-92-215.adsl.net.t-com.hr ([78.0.92.215]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 10 Jun 2007 18:10:02 +0200 Received: from ivoras by 78-0-92-215.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 10 Jun 2007 18:10:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Date: Sun, 10 Jun 2007 18:06:00 +0200 Lines: 34 Message-ID: References: <20070610115630.GA28518@freebsd.org> <20070610155025.GA34035@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA5D3066BB03791E52F317BE0" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 78-0-92-215.adsl.net.t-com.hr User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) In-Reply-To: <20070610155025.GA34035@freebsd.org> X-Enigmail-Version: 0.94.3.0 Sender: news Cc: freebsd-fs@freebsd.org Subject: Re: file(1) cannot detect UFS2? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2007 16:10:20 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA5D3066BB03791E52F317BE0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Roman Divacky wrote: >> Now there's only the matter of importing it :) >> >=20 > you mean... like was done 2 weeks ago? :) Aargh. (it was done a few minutes after I've last cvsupped and started buildworld, so I've just missed it). Thanks and sorry for bogosity. --------------enigA5D3066BB03791E52F317BE0 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.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGbCFoldnAQVacBcgRAgRgAKCx7jes8aVOC2tEglWcZgN+oT+/VgCfV5yb 9C0GoudeT7BBDYKrbYuFmsE= =Mtg6 -----END PGP SIGNATURE----- --------------enigA5D3066BB03791E52F317BE0-- From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 10 17:52:43 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 25DBE16A46C; Sun, 10 Jun 2007 17:52:43 +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 D0FFF13C469; Sun, 10 Jun 2007 17:52:42 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.13.8/8.13.7) with ESMTP id l5AHqdT6035955; Sun, 10 Jun 2007 10:52:39 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.13.8/8.13.4/Submit) id l5AHqdE0035954; Sun, 10 Jun 2007 10:52:39 -0700 (PDT) Date: Sun, 10 Jun 2007 10:52:39 -0700 (PDT) From: Matthew Dillon Message-Id: <200706101752.l5AHqdE0035954@apollo.backplane.com> To: Marcel Moolenaar References: <4AB3C4C0-0DA1-482F-A4CD-375A53332F29@mac.com> <4D7CDA24-48FE-4319-A320-C8D7165E9EBC@mac.com> <200706092128.l59LSjRs027671@apollo.backplane.com> <57F8CCC1-1841-41AE-9F82-0C87FE53BE99@mac.com> Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, Ivan Voras , freebsd-geom@freebsd.org Subject: Re: GPT - (last) call for action X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2007 17:52:43 -0000 :Technically speaking, the MBR can only have a single partition of :type 0xEE that covers the whole disk. This is to protect the GPT :from MBR-specific tools that do not know about the GPT. This is :not a bootable slice by definition. : :Practice is different. To support bootcamp on Intel-based Macs, :the MBR will have real partitions that mirror GPT partitions or :otherwise describe partitions outside the GPT controlled area. :These can be bootable partitions and the protective partition :(the one with type 0xEE) will not cover the whole disk anymore. : :The nasty part is keeping MBR and GPT partitions in sync, so it :may be better to have the MBR partition fall outside the GPT :controlled area. This can be done because the GPT header contains :the LBA of the first and last sectors on the disk that can be :assigned to a partition. You can free up space for MBR partitions :after the primary GPT table by adjusting the first LBA. In the :MBR partition you can put a GPT aware boot loader that uses the :GPT to find the real partitions... : :-- :Marcel Moolenaar In the bootcamp approach, is the GPT (0xEE) slice the first slice, and the bootcamp slice the second slice? I'm assuming it is. Do they mirror a GPT partition or do they use the uncontrolled area approach? I like the mirroring approach, because I can make the label manager just treat the special MBR slice (s2) as being part of the integrated GPT spec (which it is). From the end-user's point of view he would just do something like 'gptlabel -e ad0' and one of the GPT partitions listed would be the 'boot' partition. gptlabel would recognize the special nature of the partition and automatically and silently adjust the special MBR slice (s2) to match it. I don't like the out-of-band approach... I definitely want the partitions to be within GPTs managed area, at least for newly minted disks. With the in-band approach the gpt labeling program can take care of any special compatibility cases in a fairly straightforward and controlled manner. -Matt Matthew Dillon From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 10 18:09:05 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8C91916A469; Sun, 10 Jun 2007 18:09:05 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.176]) by mx1.freebsd.org (Postfix) with ESMTP id 5586F13C44B; Sun, 10 Jun 2007 18:09:05 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (smtpin02-en2 [10.13.10.147]) by smtpout.mac.com (Xserve/smtpout06/MantshX 4.0) with ESMTP id l5AI92Cl023282; Sun, 10 Jun 2007 11:09:02 -0700 (PDT) Received: from [172.16.1.3] (209-128-86-226.bayarea.net [209.128.86.226]) (authenticated bits=0) by mac.com (Xserve/smtpin02/MantshX 4.0) with ESMTP id l5AI8wtZ006346 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 10 Jun 2007 11:09:00 -0700 (PDT) In-Reply-To: <200706101752.l5AHqdE0035954@apollo.backplane.com> References: <4AB3C4C0-0DA1-482F-A4CD-375A53332F29@mac.com> <4D7CDA24-48FE-4319-A320-C8D7165E9EBC@mac.com> <200706092128.l59LSjRs027671@apollo.backplane.com> <57F8CCC1-1841-41AE-9F82-0C87FE53BE99@mac.com> <200706101752.l5AHqdE0035954@apollo.backplane.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8B01C1EC-D61A-484F-B308-6D6C8EB00EE6@mac.com> Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Sun, 10 Jun 2007 11:08:47 -0700 To: Matthew Dillon X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, Ivan Voras , freebsd-geom@freebsd.org Subject: Re: GPT - (last) call for action X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2007 18:09:05 -0000 On Jun 10, 2007, at 10:52 AM, Matthew Dillon wrote: > :Technically speaking, the MBR can only have a single partition of > :type 0xEE that covers the whole disk. This is to protect the GPT > :from MBR-specific tools that do not know about the GPT. This is > :not a bootable slice by definition. > : > :Practice is different. To support bootcamp on Intel-based Macs, > :the MBR will have real partitions that mirror GPT partitions or > :otherwise describe partitions outside the GPT controlled area. > :These can be bootable partitions and the protective partition > :(the one with type 0xEE) will not cover the whole disk anymore. > : > :The nasty part is keeping MBR and GPT partitions in sync, so it > :may be better to have the MBR partition fall outside the GPT > :controlled area. This can be done because the GPT header contains > :the LBA of the first and last sectors on the disk that can be > :assigned to a partition. You can free up space for MBR partitions > :after the primary GPT table by adjusting the first LBA. In the > :MBR partition you can put a GPT aware boot loader that uses the > :GPT to find the real partitions... > : > :-- > :Marcel Moolenaar > > In the bootcamp approach, is the GPT (0xEE) slice the first slice, > and the bootcamp slice the second slice? I'm assuming it is. Do > they mirror a GPT partition or do they use the uncontrolled area > approach? I seem to recall that the 0xEE partition is not the first, but rather the second or third. It would make sense, because it has no function other than to have the disk appear used. Bootcamp uses the mirroring approach. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 10 18:40:17 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6FD6116A485 for ; Sun, 10 Jun 2007 18:40:17 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id EE33413C4B7 for ; Sun, 10 Jun 2007 18:40:16 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HxSKb-00016U-C7 for freebsd-hackers@freebsd.org; Sun, 10 Jun 2007 20:40:05 +0200 Received: from 78-0-92-215.adsl.net.t-com.hr ([78.0.92.215]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 10 Jun 2007 20:40:05 +0200 Received: from ivoras by 78-0-92-215.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 10 Jun 2007 20:40:05 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Date: Sun, 10 Jun 2007 20:39:51 +0200 Lines: 44 Message-ID: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig022CB04A79A8D162FDF5A501" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 78-0-92-215.adsl.net.t-com.hr User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) X-Enigmail-Version: 0.94.3.0 Sender: news Subject: Disable mutex spinning? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2007 18:40:17 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig022CB04A79A8D162FDF5A501 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi I'm not sure I'm thinking the right way here, so this could be just nonsense. Since I started using VMWare (and that was a long time ago) and other virtual machine applications, I've noticed FreeBSD spends a lot of time in system space (i.e. much time is allocated to "sys" in utilities like top and time) during IO intensive operations. At first I thought this is because the emulated IO devices are much slower than real devices, so IO requests take a long time to complete, leading to sys time. It occurred to me that this might be bogus thinking - yes, emulated IO devices take a long time to perform IO but during that time the system doesn't do anything, so that time should be effectively described as idle, waiting for IO completion... or does it? I'm thinking of experiment - removing all spinning from mutex-like code and try running such kernel in a VMWare machine. For start, is there anything else except turning off ADAPTIVE_MUTEXES, ADAPTIVE_GIANT and ADAPTIVE_RWLOCKS I can do via the kernel config file? If someone has more insight to share on this topic, I'm listening :) --------------enig022CB04A79A8D162FDF5A501 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.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGbEV3ldnAQVacBcgRAjuaAJ0b/2p/tX012hfAq90chaXVRu7nVwCcDskN pJWRRjcpdEEKFOfT2XQKzCY= =CvVJ -----END PGP SIGNATURE----- --------------enig022CB04A79A8D162FDF5A501-- From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 10 19:06:34 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0D8CD16A468 for ; Sun, 10 Jun 2007 19:06:34 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id BA0AF13C448 for ; Sun, 10 Jun 2007 19:06:33 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HxSk1-0004we-HK for freebsd-hackers@freebsd.org; Sun, 10 Jun 2007 21:06:21 +0200 Received: from 78-0-92-215.adsl.net.t-com.hr ([78.0.92.215]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 10 Jun 2007 21:06:21 +0200 Received: from ivoras by 78-0-92-215.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 10 Jun 2007 21:06:21 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Date: Sun, 10 Jun 2007 21:06:01 +0200 Lines: 32 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4E83DAA1DBAB31712CB55B5D" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 78-0-92-215.adsl.net.t-com.hr User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) In-Reply-To: X-Enigmail-Version: 0.94.3.0 Sender: news Subject: Re: Disable mutex spinning? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2007 19:06:34 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4E83DAA1DBAB31712CB55B5D Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ivan Voras wrote: > I'm thinking of experiment - removing all spinning from mutex-like code= > and try running such kernel in a VMWare machine. For start, is there > anything else except turning off ADAPTIVE_MUTEXES, ADAPTIVE_GIANT and > ADAPTIVE_RWLOCKS I can do via the kernel config file? Hmm, on second thought this wouldn't help at all unless there's much contention.... --------------enig4E83DAA1DBAB31712CB55B5D 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.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGbEuZldnAQVacBcgRAhrbAJ9PZzXzS7mdb7P7ZGn3SsQONYyKPwCg0g5q w+VwEPfO5jD8/BqSpl4/gI8= =h+5k -----END PGP SIGNATURE----- --------------enig4E83DAA1DBAB31712CB55B5D-- From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 10 21:43:34 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0C08A16A400; Sun, 10 Jun 2007 21:43:34 +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 DDC7B13C480; Sun, 10 Jun 2007 21:43:33 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.13.8/8.13.7) with ESMTP id l5ALhQ7L038341; Sun, 10 Jun 2007 14:43:29 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.13.8/8.13.4/Submit) id l5ALhQut038340; Sun, 10 Jun 2007 14:43:26 -0700 (PDT) Date: Sun, 10 Jun 2007 14:43:26 -0700 (PDT) From: Matthew Dillon Message-Id: <200706102143.l5ALhQut038340@apollo.backplane.com> To: Rui Paulo References: <4AB3C4C0-0DA1-482F-A4CD-375A53332F29@mac.com> <4D7CDA24-48FE-4319-A320-C8D7165E9EBC@mac.com> <200706092128.l59LSjRs027671@apollo.backplane.com> <57F8CCC1-1841-41AE-9F82-0C87FE53BE99@mac.com> <200706101752.l5AHqdE0035954@apollo.backplane.com> <8B01C1EC-D61A-484F-B308-6D6C8EB00EE6@mac.com> <861wgjwnrw.wl%rpaulo@fnop.net> Cc: freebsd-geom@freebsd.org, freebsd-hackers@freebsd.org, Marcel Moolenaar , Ivan Voras , freebsd-current@freebsd.org Subject: Re: GPT - (last) call for action X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2007 21:43:34 -0000 :No. :The first partition is the EFI GPT (0xee): : :% fdisk -1 :******* Working on device /dev/ad0 ******* :... :parameters to be used for BIOS calculations are: :cylinders=116280 heads=16 sectors/track=63 (1008 blks/cyl) : :Media sector size is 512 :Warning: BIOS sector numbering starts with sector 1 :Information from DOS bootblock is: :The data for partition 1 is: :sysid 238 (0xee),(EFI GPT) : start 40, size 409600 (200 Meg), flag 0 : beg: cyl 0/ head 0/ sector 41; : end: cyl 406/ head 6/ sector 14 I think I have it mostly figured out, but the 'start 40' in your output can't be right. The intel documentation says that the starting LBA in a PMBR record must be set to 1 by definition (table 11-7 in the 1.10 documentation). -Matt From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 10 23:49:50 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3B21716A400 for ; Sun, 10 Jun 2007 23:49:50 +0000 (UTC) (envelope-from antonfb@hesiod.org) Received: from paris.hesiod.org (cust.hesiod.org [66.219.69.76]) by mx1.freebsd.org (Postfix) with ESMTP id C1ECE13C45D for ; Sun, 10 Jun 2007 23:49:49 +0000 (UTC) (envelope-from antonfb@hesiod.org) Received: from atlas.hesiod.org (atlas.hesiod.org [192.168.1.9]) by paris.hesiod.org (8.13.8/8.13.6) with ESMTP id l5ANFSuU071454 for ; Sun, 10 Jun 2007 16:15:28 -0700 (PDT) (envelope-from antonfb@hesiod.org) Message-ID: <466C8611.5020009@hesiod.org> Date: Sun, 10 Jun 2007 16:15:29 -0700 From: Jeff Anton User-Agent: Thunderbird 2.0.0.0 (X11/20070528) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <20070610120017.645B116A4DA@hub.freebsd.org> In-Reply-To: <20070610120017.645B116A4DA@hub.freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: pkgdb -F calling portupgrade -a X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2007 23:49:50 -0000 I'm very surprised and upset that running pkgdb -F has started a whole upgrade of my stable machine. I'm sure hacker's isn't the right list for this but it is so amazing that I don't know what the right list would be and I think just calling attention to some very bizarre behavior is maybe the best thing. This machine should only have X11 clients... Anyhow output below... Jeff Anton ______________ paris.hesiod.org:root[62]: portversion Stale dependency: Xaw3d-1.5E_1 --> xf86dgaproto-2.0.2 -- manually run 'pkgdb -F' to fix, or specify -O to force. paris.hesiod.org:root[63]: pkgdb -F ---> Checking the package registry database Stale origin: 'x11/xorg-manpages': perhaps moved or obsoleted. -> The port 'x11/xorg-manpages' was removed on because: "X.org manual pages are now installed with every single port" -> Hint: xorg-manpages-6.9.0 is not required by any other package -> Hint: checking for overwritten files... -> No files installed by xorg-manpages-6.9.0 have been overwritten by other packages. Deinstall xorg-manpages-6.9.0 ? [no] yes ---> Deinstalling 'xorg-manpages-6.9.0' [Updating the pkgdb in /var/db/pkg ... - 70 packages found (-1 +0) (...) done] --> Done. Stale dependency: Xaw3d-1.5E_1 -> xf86dgaproto-2.0.2 (x11/xf86dgaproto): Install stale dependency? ([y]es/[n]o/[a]ll) [yes] n New dependency? (? to help): . Abort. 62.580u 41.058s 2:08.82 80.4% 157+2488k 1300+1603io 12pf+0w paris.hesiod.org:root[64]: pkgdb -F ---> Checking the package registry database Stale dependency: Xaw3d-1.5E_1 -> xf86dgaproto-2.0.2 (x11/xf86dgaproto): Install stale dependency? ([y]es/[n]o/[a]ll) [yes] n New dependency? (? to help): Delete this? ([y]es/[n]o/[a]ll) [yes] Deleted. Stale dependency: Xaw3d-1.5E_1 -> libXdamage-1.1.1 (x11/libXdamage): libXft-2.1.7_1 (score:25%) ? ([y]es/[n]o/[a]ll) [no] Install stale dependency? ([y]es/[n]o/[a]ll) [yes] n New dependency? (? to help): Delete this? ([y]es/[n]o/[a]ll) [yes] Deleted. Stale dependency: Xaw3d-1.5E_1 -> renderproto-0.9.2 (x11/renderproto): Install stale dependency? ([y]es/[n]o/[a]ll) [yes] n New dependency? (? to help): Delete this? ([y]es/[n]o/[a]ll) [yes] Deleted. Stale dependency: Xaw3d-1.5E_1 -> compositeproto-0.3.1 (x11/compositeproto): Install stale dependency? ([y]es/[n]o/[a]ll) [yes] n New dependency? (? to help): Delete this? ([y]es/[n]o/[a]ll) [yes] Deleted. Stale dependency: Xaw3d-1.5E_1 -> libXv-1.0.3,1 (x11/libXv): libXft-2.1.7_1 (score:22%) ? ([y]es/[n]o/[a]ll) [no] Install stale dependency? ([y]es/[n]o/[a]ll) [yes] n ---> Installing 'libXv-1.0.3,1' from a port (x11/libXv) ---> Building '/usr/ports/x11/libXv' ===> Cleaning for xextproto-7.0.2 ===> Cleaning for videoproto-2.2.2 ===> Cleaning for libX11-1.1.2,1 ^Z===> Cleaning for libXext-1.0.3,1 ===> Cleaning for pkg-config-0.21 ===> Cleaning for bigreqsproto-1.0.2 ===> Cleaning for xcmiscproto-1.1.2 ===> Cleaning for kbproto-1.0.3 ===> Cleaning for inputproto-1.3.2 ===> Cleaning for xf86bigfontproto-1.1.2 ===> Cleaning for libXau-1.0.3_2 ===> Cleaning for libXdmcp-1.0.2 ===> Cleaning for xtrans-1.0.3 ===> Cleaning for xproto-7.0.10 ===> Cleaning for libtool-1.5.22_4 ===> Cleaning for gmake-3.81_2 ===> Cleaning for gettext-0.16.1_3 ===> Cleaning for libiconv-1.9.2_2 ===> Cleaning for libXv-1.0.3,1 ===> Vulnerability check disabled, database not found => libXv-1.0.3.tar.bz2 doesn't seem to exist in /usr/ports/distfiles/xorg/lib. => Attempting to fetch from ftp://ftp.gwdg.de/pub/x11/x.org/pub/individual/lib/. libXv-1.0.3.tar.bz2 100% of 226 kB 98 kBps ===> Extracting for libXv-1.0.3,1 => MD5 Checksum OK for xorg/lib/libXv-1.0.3.tar.bz2. => SHA256 Checksum OK for xorg/lib/libXv-1.0.3.tar.bz2. ===> Patching for libXv-1.0.3,1 ===> libXv-1.0.3,1 depends on file: /usr/local/libdata/pkgconfig/xextproto.pc - not found ===> Verifying install for /usr/local/libdata/pkgconfig/xextproto.pc in /usr/ports/x11/xextproto ===> Vulnerability check disabled, database not found => xextproto-7.0.2.tar.bz2 doesn't seem to exist in /usr/ports/distfiles/xorg/proto. => Attempting to fetch from ftp://ftp.gwdg.de/pub/x11/x.org/pub/individual/proto/. xextproto-7.0.2.tar.bz2 100% of 66 kB 53 kBps ===> Extracting for xextproto-7.0.2 => MD5 Checksum OK for xorg/proto/xextproto-7.0.2.tar.bz2. => SHA256 Checksum OK for xorg/proto/xextproto-7.0.2.tar.bz2. ===> Patching for xextproto-7.0.2 ===> Configuring for xextproto-7.0.2 configure: WARNING: you should use --build, --host, --target checking for a BSD-compatible install... /usr/bin/install -c -o root -g wheel checking whether build environment is sane... yes checking for gawk... no checking for mawk... no checking for nawk... nawk checking whether make sets $(MAKE)... yes configure: creating ./config.status config.status: creating Makefile config.status: creating xextproto.pc ===> Building for xextproto-7.0.2 ===> Installing for xextproto-7.0.2 ===> Generating temporary packing list ===> Checking if x11/xextproto already installed /bin/sh ./mkinstalldirs /usr/local/libdata/pkgconfig install -o root -g wheel -m 444 xextproto.pc /usr/local/libdata/pkgconfig/xextproto.pc /bin/sh ./mkinstalldirs /usr/local/include/X11/extensions mkdir -p -- /usr/local/include/X11/extensions install -o root -g wheel -m 444 dpms.h /usr/local/include/X11/extensions/dpms.h install -o root -g wheel -m 444 dpmsstr.h /usr/local/include/X11/extensions/dpmsstr.h install -o root -g wheel -m 444 extutil.h /usr/local/include/X11/extensions/extutil.h install -o root -g wheel -m 444 lbxbuf.h /usr/local/include/X11/extensions/lbxbuf.h install -o root -g wheel -m 444 lbxbufstr.h /usr/local/include/X11/extensions/lbxbufstr.h install -o root -g wheel -m 444 lbxdeltastr.h /usr/local/include/X11/extensions/lbxdeltastr.h install -o root -g wheel -m 444 lbximage.h /usr/local/include/X11/extensions/lbximage.h install -o root -g wheel -m 444 lbxopts.h /usr/local/include/X11/extensions/lbxopts.h install -o root -g wheel -m 444 lbxstr.h /usr/local/include/X11/extensions/lbxstr.h install -o root -g wheel -m 444 lbxzlib.h /usr/local/include/X11/extensions/lbxzlib.h install -o root -g wheel -m 444 MITMisc.h /usr/local/include/X11/extensions/MITMisc.h install -o root -g wheel -m 444 mitmiscstr.h /usr/local/include/X11/extensions/mitmiscstr.h install -o root -g wheel -m 444 multibuf.h /usr/local/include/X11/extensions/multibuf.h install -o root -g wheel -m 444 multibufst.h /usr/local/include/X11/extensions/multibufst.h install -o root -g wheel -m 444 security.h /usr/local/include/X11/extensions/security.h install -o root -g wheel -m 444 securstr.h /usr/local/include/X11/extensions/securstr.h install -o root -g wheel -m 444 shape.h /usr/local/include/X11/extensions/shape.h install -o root -g wheel -m 444 shapestr.h /usr/local/include/X11/extensions/shapestr.h install -o root -g wheel -m 444 shmstr.h /usr/local/include/X11/extensions/shmstr.h install -o root -g wheel -m 444 sync.h /usr/local/include/X11/extensions/sync.h install -o root -g wheel -m 444 syncstr.h /usr/local/include/X11/extensions/syncstr.h install -o root -g wheel -m 444 Xag.h /usr/local/include/X11/extensions/Xag.h install -o root -g wheel -m 444 Xagsrv.h /usr/local/include/X11/extensions/Xagsrv.h install -o root -g wheel -m 444 Xagstr.h /usr/local/include/X11/extensions/Xagstr.h install -o root -g wheel -m 444 Xcup.h /usr/local/include/X11/extensions/Xcup.h install -o root -g wheel -m 444 Xcupstr.h /usr/local/include/X11/extensions/Xcupstr.h install -o root -g wheel -m 444 Xdbe.h /usr/local/include/X11/extensions/Xdbe.h install -o root -g wheel -m 444 Xdbeproto.h /usr/local/include/X11/extensions/Xdbeproto.h install -o root -g wheel -m 444 XEVI.h /usr/local/include/X11/extensions/XEVI.h install -o root -g wheel -m 444 XEVIstr.h /usr/local/include/X11/extensions/XEVIstr.h install -o root -g wheel -m 444 Xext.h /usr/local/include/X11/extensions/Xext.h install -o root -g wheel -m 444 XLbx.h /usr/local/include/X11/extensions/XLbx.h install -o root -g wheel -m 444 XShm.h /usr/local/include/X11/extensions/XShm.h install -o root -g wheel -m 444 xtestext1.h /usr/local/include/X11/extensions/xtestext1.h install -o root -g wheel -m 444 XTest.h /usr/local/include/X11/extensions/XTest.h install -o root -g wheel -m 444 xteststr.h /usr/local/include/X11/extensions/xteststr.h ===> Registering installation for xextproto-7.0.2 ===> Returning to build of libXv-1.0.3,1 ===> libXv-1.0.3,1 depends on file: /usr/local/libdata/pkgconfig/videoproto.pc - not found ===> Verifying install for /usr/local/libdata/pkgconfig/videoproto.pc in /usr/ports/x11/videoproto ===> Vulnerability check disabled, database not found => videoproto-2.2.2.tar.bz2 doesn't seem to exist in /usr/ports/distfiles/xorg/proto. => Attempting to fetch from ftp://ftp.gwdg.de/pub/x11/x.org/pub/individual/proto/. videoproto-2.2.2.tar.bz2 100% of 41 kB 40 kBps ===> Extracting for videoproto-2.2.2 => MD5 Checksum OK for xorg/proto/videoproto-2.2.2.tar.bz2. => SHA256 Checksum OK for xorg/proto/videoproto-2.2.2.tar.bz2. ===> Patching for videoproto-2.2.2 ===> Configuring for videoproto-2.2.2 configure: WARNING: you should use --build, --host, --target checking for a BSD-compatible install... /usr/bin/install -c -o root -g wheel checking whether build environment is sane... yes checking for gawk... no checking for mawk... no checking for nawk... nawk checking whether make sets $(MAKE)... yes configure: creating ./config.status config.status: creating Makefile config.status: creating videoproto.pc ===> Building for videoproto-2.2.2 ===> Installing for videoproto-2.2.2 ===> Generating temporary packing list ===> Checking if x11/videoproto already installed /bin/sh ./mkinstalldirs /usr/local/libdata/pkgconfig install -o root -g wheel -m 444 videoproto.pc /usr/local/libdata/pkgconfig/videoproto.pc /bin/sh ./mkinstalldirs /usr/local/include/X11/extensions install -o root -g wheel -m 444 vldXvMC.h /usr/local/include/X11/extensions/vldXvMC.h install -o root -g wheel -m 444 Xv.h /usr/local/include/X11/extensions/Xv.h install -o root -g wheel -m 444 XvMC.h /usr/local/include/X11/extensions/XvMC.h install -o root -g wheel -m 444 XvMCproto.h /usr/local/include/X11/extensions/XvMCproto.h install -o root -g wheel -m 444 Xvproto.h /usr/local/include/X11/extensions/Xvproto.h ===> Registering installation for videoproto-2.2.2 ===> Returning to build of libXv-1.0.3,1 ===> libXv-1.0.3,1 depends on file: /usr/local/libdata/pkgconfig/x11.pc - not found ===> Verifying install for /usr/local/libdata/pkgconfig/x11.pc in /usr/ports/x11/libX11 ===> Vulnerability check disabled, database not found => libX11-1.1.2.tar.bz2 doesn't seem to exist in /usr/ports/distfiles/xorg/lib. => Attempting to fetch from ftp://ftp.gwdg.de/pub/x11/x.org/pub/individual/lib/. libX11-1.1.2.tar.bz2 100% of 1487 kB 136 kBps 00m00s ===> Extracting for libX11-1.1.2,1 => MD5 Checksum OK for xorg/lib/libX11-1.1.2.tar.bz2. => SHA256 Checksum OK for xorg/lib/libX11-1.1.2.tar.bz2. ===> Patching for libX11-1.1.2,1 ===> libX11-1.1.2,1 depends on file: /usr/local/libdata/pkgconfig/bigreqsproto.pc - not found ===> Verifying install for /usr/local/libdata/pkgconfig/bigreqsproto.pc in /usr/ports/x11/bigreqsproto ===> Vulnerability check disabled, database not found => bigreqsproto-1.0.2.tar.bz2 doesn't seem to exist in /usr/ports/distfiles/xorg/proto. => Attempting to fetch from ftp://ftp.gwdg.de/pub/x11/x.org/pub/individual/proto/. bigreqsproto-1.0.2.tar.bz2 100% of 35 kB 37 kBps ===> Extracting for bigreqsproto-1.0.2 => MD5 Checksum OK for xorg/proto/bigreqsproto-1.0.2.tar.bz2. => SHA256 Checksum OK for xorg/proto/bigreqsproto-1.0.2.tar.bz2. ===> Patching for bigreqsproto-1.0.2 ===> Configuring for bigreqsproto-1.0.2 configure: WARNING: you should use --build, --host, --target checking for a BSD-compatible install... /usr/bin/install -c -o root -g wheel checking whether build environment is sane... yes checking for gawk... no checking for mawk... no checking for nawk... nawk checking whether make sets $(MAKE)... yes configure: creating ./config.status config.status: creating Makefile config.status: creating bigreqsproto.pc ===> Building for bigreqsproto-1.0.2 ===> Installing for bigreqsproto-1.0.2 ===> Generating temporary packing list ===> Checking if x11/bigreqsproto already installed /bin/sh ./mkinstalldirs /usr/local/include/X11/extensions install -o root -g wheel -m 444 bigreqstr.h /usr/local/include/X11/extensions/bigreqstr.h /bin/sh ./mkinstalldirs /usr/local/libdata/pkgconfig install -o root -g wheel -m 444 bigreqsproto.pc /usr/local/libdata/pkgconfig/bigreqsproto.pc ===> Registering installation for bigreqsproto-1.0.2 ===> Returning to build of libX11-1.1.2,1 ===> libX11-1.1.2,1 depends on file: /usr/local/libdata/pkgconfig/xextproto.pc - found ===> libX11-1.1.2,1 depends on file: /usr/local/libdata/pkgconfig/xcmiscproto.pc - not found ===> Verifying install for /usr/local/libdata/pkgconfig/xcmiscproto.pc in /usr/ports/x11/xcmiscproto ===> Vulnerability check disabled, database not found => xcmiscproto-1.1.2.tar.bz2 doesn't seem to exist in /usr/ports/distfiles/xorg/proto. => Attempting to fetch from ftp://ftp.gwdg.de/pub/x11/x.org/pub/individual/proto/. xcmiscproto-1.1.2.tar.bz2 100% of 35 kB 37 kBps ===> Extracting for xcmiscproto-1.1.2 => MD5 Checksum OK for xorg/proto/xcmiscproto-1.1.2.tar.bz2. => SHA256 Checksum OK for xorg/proto/xcmiscproto-1.1.2.tar.bz2. ===> Patching for xcmiscproto-1.1.2 ===> Configuring for xcmiscproto-1.1.2 configure: WARNING: you should use --build, --host, --target checking for a BSD-compatible install... /usr/bin/install -c -o root -g wheel checking whether build environment is sane... yes checking for gawk... no checking for mawk... no checking for nawk... nawk checking whether make sets $(MAKE)... yes configure: creating ./config.status config.status: creating Makefile config.status: creating xcmiscproto.pc ===> Building for xcmiscproto-1.1.2 ===> Installing for xcmiscproto-1.1.2 ===> Generating temporary packing list ===> Checking if x11/xcmiscproto already installed /bin/sh ./mkinstalldirs /usr/local/libdata/pkgconfig install -o root -g wheel -m 444 xcmiscproto.pc /usr/local/libdata/pkgconfig/xcmiscproto.pc /bin/sh ./mkinstalldirs /usr/local/include/X11/extensions install -o root -g wheel -m 444 xcmiscstr.h /usr/local/include/X11/extensions/xcmiscstr.h ===> Registering installation for xcmiscproto-1.1.2 ===> Returning to build of libX11-1.1.2,1 ===> libX11-1.1.2,1 depends on file: /usr/local/libdata/pkgconfig/kbproto.pc - not found ===> Verifying install for /usr/local/libdata/pkgconfig/kbproto.pc in /usr/ports/x11/kbproto ===> Vulnerability check disabled, database not found => kbproto-1.0.3.tar.bz2 doesn't seem to exist in /usr/ports/distfiles/xorg/proto. => Attempting to fetch from ftp://ftp.gwdg.de/pub/x11/x.org/pub/individual/proto/. ... From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 11 00:02:25 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 229F016A400 for ; Mon, 11 Jun 2007 00:02:25 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 00D7E13C455 for ; Mon, 11 Jun 2007 00:02:24 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 6A6F21A3C19; Sun, 10 Jun 2007 17:02:12 -0700 (PDT) Received: from rot13.obsecurity.org (rot13.obsecurity.org [192.168.1.5]) by obsecurity.dyndns.org (Postfix) with ESMTP id 014455119F; Sun, 10 Jun 2007 20:02:24 -0400 (EDT) Received: by rot13.obsecurity.org (Postfix, from userid 1001) id E94D3BC90; Sun, 10 Jun 2007 20:02:23 -0400 (EDT) Date: Sun, 10 Jun 2007 20:02:23 -0400 From: Kris Kennaway To: Jeff Anton Message-ID: <20070611000223.GA28536@rot13.obsecurity.org> References: <20070610120017.645B116A4DA@hub.freebsd.org> <466C8611.5020009@hesiod.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <466C8611.5020009@hesiod.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-hackers@freebsd.org Subject: Re: pkgdb -F calling portupgrade -a X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2007 00:02:25 -0000 On Sun, Jun 10, 2007 at 04:15:29PM -0700, Jeff Anton wrote: > I'm very surprised and upset that running pkgdb -F has started a whole > upgrade of my stable machine. Well, it didn't. > I'm sure hacker's isn't the right list for this Correct. > but it is so amazing that I don't know what the right list would be Ports problems go to the ports list. Problems with a particular port (e.g. portupgrade) go to that list and/or the port's maintainer. > Deinstall xorg-manpages-6.9.0 ? [no] yes > ---> Deinstalling 'xorg-manpages-6.9.0' > [Updating the pkgdb in /var/db/pkg ... - 70 packages > found (-1 +0) (...) done] > --> Done. > Stale dependency: Xaw3d-1.5E_1 -> xf86dgaproto-2.0.2 (x11/xf86dgaproto): > Install stale dependency? ([y]es/[n]o/[a]ll) [yes] n > New dependency? (? to help): . > Abort. > 62.580u 41.058s 2:08.82 80.4% 157+2488k 1300+1603io 12pf+0w You need to go through the xorg 7.2 upgrade. Most of what you chose to do was actually damaging your port installations, e.g. > ---> Checking the package registry database > Stale dependency: Xaw3d-1.5E_1 -> xf86dgaproto-2.0.2 (x11/xf86dgaproto): > Install stale dependency? ([y]es/[n]o/[a]ll) [yes] n ^ > New dependency? (? to help): > Delete this? ([y]es/[n]o/[a]ll) [yes] ^^^^ Whee, you've deleted metadata that was required for correctness of future upgrades. > Deleted. > Stale dependency: Xaw3d-1.5E_1 -> libXdamage-1.1.1 (x11/libXdamage): > libXft-2.1.7_1 (score:25%) ? ([y]es/[n]o/[a]ll) [no] > Install stale dependency? ([y]es/[n]o/[a]ll) [yes] n > New dependency? (? to help): > Delete this? ([y]es/[n]o/[a]ll) [yes] > Deleted. > Stale dependency: Xaw3d-1.5E_1 -> renderproto-0.9.2 (x11/renderproto): > Install stale dependency? ([y]es/[n]o/[a]ll) [yes] n > New dependency? (? to help): > Delete this? ([y]es/[n]o/[a]ll) [yes] > Deleted. > Stale dependency: Xaw3d-1.5E_1 -> compositeproto-0.3.1 (x11/compositeproto): > Install stale dependency? ([y]es/[n]o/[a]ll) [yes] n > New dependency? (? to help): > Delete this? ([y]es/[n]o/[a]ll) [yes] > Deleted. > Stale dependency: Xaw3d-1.5E_1 -> libXv-1.0.3,1 (x11/libXv): > libXft-2.1.7_1 (score:22%) ? ([y]es/[n]o/[a]ll) [no] > Install stale dependency? ([y]es/[n]o/[a]ll) [yes] n This is the only part that doesn't make sense. Are you sure you didn't do e.g. 'y^Hn' where that was not interpreted by the terminal as a backspace but as a string beginning with 'y'? It's the only way I can think that this would trigger the 'yes' branch. Anyway, it wasn't doing 'portupgrade -a' but trying to bring your system up to a consistent state. Really what you probably should have done was either leave your system alone (i.e. not answered 'yes' to requests to modify things), or go through the documented x.org 7.2 upgrade procedure to perform the upgrade correctly and completely. Kris From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 11 00:03:23 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9753E16A473 for ; Mon, 11 Jun 2007 00:03:23 +0000 (UTC) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: from mired.org (vpn.mired.org [66.92.153.74]) by mx1.freebsd.org (Postfix) with SMTP id 366D013C489 for ; Mon, 11 Jun 2007 00:01:23 +0000 (UTC) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: (qmail 49913 invoked by uid 1001); 10 Jun 2007 23:59:15 -0000 Received: by bhuda.mired.org (tmda-sendmail, from uid 1001); Sun, 10 Jun 2007 19:59:15 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18028.36946.981778.560346@bhuda.mired.org> Date: Sun, 10 Jun 2007 19:59:14 -0400 To: Jeff Anton In-Reply-To: <466C8611.5020009@hesiod.org> References: <20070610120017.645B116A4DA@hub.freebsd.org> <466C8611.5020009@hesiod.org> X-Mailer: VM 7.19 under Emacs 21.3.1 X-Primary-Address: mwm@mired.org X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`; h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ X-Delivery-Agent: TMDA/1.1.11 (Ladyburn) From: Mike Meyer Cc: freebsd-hackers@freebsd.org Subject: Re: pkgdb -F calling portupgrade -a X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2007 00:03:23 -0000 In <466C8611.5020009@hesiod.org>, Jeff Anton typed: > I'm very surprised and upset that running pkgdb -F has started a whole > upgrade of my stable machine. I'm sure hacker's isn't the right list > for this but it is so amazing that I don't know what the right list > would be and I think just calling attention to some very bizarre > behavior is maybe the best thing. This machine should only have X11 > clients... Anyhow output below... Hi Jeff, Long time no see. The only wierd thing I see is right here: > Stale dependency: Xaw3d-1.5E_1 -> libXv-1.0.3,1 (x11/libXv): > libXft-2.1.7_1 (score:22%) ? ([y]es/[n]o/[a]ll) [no] > Install stale dependency? ([y]es/[n]o/[a]ll) [yes] n > ---> Installing 'libXv-1.0.3,1' from a port (x11/libXv) > ---> Building '/usr/ports/x11/libXv' Where it starts installing the port even though you told it not to. That's a pkgdb issue, and the right person to talk to is the portupgrade maintainer, sem@FreeBSD.org. For the rest of it - you've apperently got x.org 6.9 installed on the system and x.org 7.0 in the ports tree. So once it starts installing ports, it's pretty much going to install the entire xorg ports set. Since they install in different prefixes (7.0 moved to /usr/local), that will actually work. I didn't see anything but client stuff in the output. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 11 00:07:10 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7DBE316A41F for ; Mon, 11 Jun 2007 00:07:10 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 69A1F13C4B7 for ; Mon, 11 Jun 2007 00:07:10 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id DC4821A4D90; Sun, 10 Jun 2007 17:06:57 -0700 (PDT) Received: from rot13.obsecurity.org (rot13.obsecurity.org [192.168.1.5]) by obsecurity.dyndns.org (Postfix) with ESMTP id C4D955119F; Sun, 10 Jun 2007 20:07:09 -0400 (EDT) Received: by rot13.obsecurity.org (Postfix, from userid 1001) id BA451BC90; Sun, 10 Jun 2007 20:07:09 -0400 (EDT) Date: Sun, 10 Jun 2007 20:07:09 -0400 From: Kris Kennaway To: Mike Meyer Message-ID: <20070611000709.GA30241@rot13.obsecurity.org> References: <20070610120017.645B116A4DA@hub.freebsd.org> <466C8611.5020009@hesiod.org> <18028.36946.981778.560346@bhuda.mired.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18028.36946.981778.560346@bhuda.mired.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-hackers@freebsd.org, Jeff Anton Subject: Re: pkgdb -F calling portupgrade -a X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2007 00:07:10 -0000 On Sun, Jun 10, 2007 at 07:59:14PM -0400, Mike Meyer wrote: > In <466C8611.5020009@hesiod.org>, Jeff Anton typed: > > I'm very surprised and upset that running pkgdb -F has started a whole > > upgrade of my stable machine. I'm sure hacker's isn't the right list > > for this but it is so amazing that I don't know what the right list > > would be and I think just calling attention to some very bizarre > > behavior is maybe the best thing. This machine should only have X11 > > clients... Anyhow output below... > > Hi Jeff, > > Long time no see. The only wierd thing I see is right here: > > > Stale dependency: Xaw3d-1.5E_1 -> libXv-1.0.3,1 (x11/libXv): > > libXft-2.1.7_1 (score:22%) ? ([y]es/[n]o/[a]ll) [no] > > Install stale dependency? ([y]es/[n]o/[a]ll) [yes] n > > ---> Installing 'libXv-1.0.3,1' from a port (x11/libXv) > > ---> Building '/usr/ports/x11/libXv' > > Where it starts installing the port even though you told it not > to. That's a pkgdb issue, and the right person to talk to is the > portupgrade maintainer, sem@FreeBSD.org. > > For the rest of it - you've apperently got x.org 6.9 installed on the > system and x.org 7.0 in the ports tree. So once it starts installing > ports, it's pretty much going to install the entire xorg ports > set. Since they install in different prefixes (7.0 moved to > /usr/local), that will actually work. Unfortunately it will not work and will actually lead to package database corruption due to a portupgrade bug. That's why the more extensive upgrade process in UPDATING is necessary. Kris From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 10 20:57:04 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CE18216A41F; Sun, 10 Jun 2007 20:57:04 +0000 (UTC) (envelope-from rpaulo@fnop.net) Received: from core.fnop.net (mx.fnop.net [82.102.11.82]) by mx1.freebsd.org (Postfix) with ESMTP id 59A0D13C46E; Sun, 10 Jun 2007 20:57:04 +0000 (UTC) (envelope-from rpaulo@fnop.net) Received: from core.fnop.net (mx.fnop.net [82.102.11.82]) by core.fnop.net (Postfix) with ESMTP id 26A43690A7A; Sun, 10 Jun 2007 21:33:08 +0100 (WEST) Received: by core.fnop.net (Postfix, from userid 1015) id DBA80690B56; Sun, 10 Jun 2007 21:33:07 +0100 (WEST) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on core.fnop.net X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,RCVD_IN_SORBS_DUL autolearn=no version=3.1.7 Received: from epsilon.local.fnop.net (87-196-125-90.net.novis.pt [87.196.125.90]) by core.fnop.net (Postfix) with ESMTP id 0B934690A7A; Sun, 10 Jun 2007 21:33:07 +0100 (WEST) Date: Sun, 10 Jun 2007 21:35:47 +0100 Message-ID: <861wgjwnrw.wl%rpaulo@fnop.net> From: Rui Paulo To: Marcel Moolenaar In-Reply-To: <8B01C1EC-D61A-484F-B308-6D6C8EB00EE6@mac.com> References: <4AB3C4C0-0DA1-482F-A4CD-375A53332F29@mac.com> <4D7CDA24-48FE-4319-A320-C8D7165E9EBC@mac.com> <200706092128.l59LSjRs027671@apollo.backplane.com> <57F8CCC1-1841-41AE-9F82-0C87FE53BE99@mac.com> <200706101752.l5AHqdE0035954@apollo.backplane.com> <8B01C1EC-D61A-484F-B308-6D6C8EB00EE6@mac.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/21.3 Mule/5.0 (SAKAKI) X-cite-me: rpaulo MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: ClamAV using ClamSMTP X-Mailman-Approved-At: Mon, 11 Jun 2007 00:16:43 +0000 Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, Ivan Voras , freebsd-geom@freebsd.org Subject: Re: GPT - (last) call for action X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2007 20:57:04 -0000 At Sun, 10 Jun 2007 11:08:47 -0700, Marcel Moolenaar wrote: > > > On Jun 10, 2007, at 10:52 AM, Matthew Dillon wrote: > > > :Technically speaking, the MBR can only have a single partition of > > :type 0xEE that covers the whole disk. This is to protect the GPT > > :from MBR-specific tools that do not know about the GPT. This is > > :not a bootable slice by definition. > > : > > :Practice is different. To support bootcamp on Intel-based Macs, > > :the MBR will have real partitions that mirror GPT partitions or > > :otherwise describe partitions outside the GPT controlled area. > > :These can be bootable partitions and the protective partition > > :(the one with type 0xEE) will not cover the whole disk anymore. > > : > > :The nasty part is keeping MBR and GPT partitions in sync, so it > > :may be better to have the MBR partition fall outside the GPT > > :controlled area. This can be done because the GPT header contains > > :the LBA of the first and last sectors on the disk that can be > > :assigned to a partition. You can free up space for MBR partitions > > :after the primary GPT table by adjusting the first LBA. In the > > :MBR partition you can put a GPT aware boot loader that uses the > > :GPT to find the real partitions... > > : > > :-- > > :Marcel Moolenaar > > > > In the bootcamp approach, is the GPT (0xEE) slice the first slice, > > and the bootcamp slice the second slice? I'm assuming it is. Do > > they mirror a GPT partition or do they use the uncontrolled area > > approach? > > I seem to recall that the 0xEE partition is not the first, but rather > the second or third. It would make sense, because it has no function > other than to have the disk appear used. Bootcamp uses the mirroring > approach. No. The first partition is the EFI GPT (0xee): % fdisk -1 ******* Working on device /dev/ad0 ******* parameters extracted from in-core disklabel are: cylinders=116280 heads=16 sectors/track=63 (1008 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=116280 heads=16 sectors/track=63 (1008 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 238 (0xee),(EFI GPT) start 40, size 409600 (200 Meg), flag 0 beg: cyl 0/ head 0/ sector 41; end: cyl 406/ head 6/ sector 14 % gpt -r show ad0 gpt show: ad0: Suspicious MBR at sector 0 start size index contents 0 1 MBR 1 1 Pri GPT header 2 32 Pri GPT table 34 6 40 409600 1 GPT part - EFI System 409640 41943040 2 GPT part - Apple HFS 42352680 74857527 3 GPT part - FreeBSD UFS/UFS2 117210207 32 Sec GPT table 117210239 1 Sec GPT header -- Rui Paulo From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 10 22:14:03 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1526A16A41F; Sun, 10 Jun 2007 22:14:03 +0000 (UTC) (envelope-from rpaulo@fnop.net) Received: from core.fnop.net (mx.fnop.net [82.102.11.82]) by mx1.freebsd.org (Postfix) with ESMTP id 7A41813C4BD; Sun, 10 Jun 2007 22:14:02 +0000 (UTC) (envelope-from rpaulo@fnop.net) Received: from core.fnop.net (mx.fnop.net [82.102.11.82]) by core.fnop.net (Postfix) with ESMTP id C8CF3690A7A; Sun, 10 Jun 2007 23:11:19 +0100 (WEST) Received: by core.fnop.net (Postfix, from userid 1015) id 949BD690AE9; Sun, 10 Jun 2007 23:11:19 +0100 (WEST) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on core.fnop.net X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,RCVD_IN_SORBS_DUL autolearn=no version=3.1.7 Received: from epsilon.local.fnop.net (87-196-125-90.net.novis.pt [87.196.125.90]) by core.fnop.net (Postfix) with ESMTP id EFEC2690A7A; Sun, 10 Jun 2007 23:11:18 +0100 (WEST) Date: Sun, 10 Jun 2007 23:13:59 +0100 Message-ID: <86zm37v4ns.wl%rpaulo@fnop.net> From: Rui Paulo To: Matthew Dillon In-Reply-To: <200706102143.l5ALhQut038340@apollo.backplane.com> References: <4AB3C4C0-0DA1-482F-A4CD-375A53332F29@mac.com> <4D7CDA24-48FE-4319-A320-C8D7165E9EBC@mac.com> <200706092128.l59LSjRs027671@apollo.backplane.com> <57F8CCC1-1841-41AE-9F82-0C87FE53BE99@mac.com> <200706101752.l5AHqdE0035954@apollo.backplane.com> <8B01C1EC-D61A-484F-B308-6D6C8EB00EE6@mac.com> <861wgjwnrw.wl%rpaulo@fnop.net> <200706102143.l5ALhQut038340@apollo.backplane.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/21.3 Mule/5.0 (SAKAKI) X-cite-me: rpaulo MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: ClamAV using ClamSMTP X-Mailman-Approved-At: Mon, 11 Jun 2007 00:16:43 +0000 Cc: freebsd-geom@freebsd.org, freebsd-hackers@freebsd.org, Marcel Moolenaar , freebsd-current@freebsd.org Subject: Re: GPT - (last) call for action X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2007 22:14:03 -0000 At Sun, 10 Jun 2007 14:43:26 -0700 (PDT), Matthew Dillon wrote: > > > :No. > :The first partition is the EFI GPT (0xee): > : > :% fdisk -1 > :******* Working on device /dev/ad0 ******* > :... > :parameters to be used for BIOS calculations are: > :cylinders=116280 heads=16 sectors/track=63 (1008 blks/cyl) > : > :Media sector size is 512 > :Warning: BIOS sector numbering starts with sector 1 > :Information from DOS bootblock is: > :The data for partition 1 is: > :sysid 238 (0xee),(EFI GPT) > : start 40, size 409600 (200 Meg), flag 0 > : beg: cyl 0/ head 0/ sector 41; > : end: cyl 406/ head 6/ sector 14 > > I think I have it mostly figured out, but the 'start 40' in your > output can't be right. The intel documentation says that the > starting LBA in a PMBR record must be set to 1 by definition > (table 11-7 in the 1.10 documentation). I don't know why Apple does that. -- Rui Paulo From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 11 00:17:42 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D212F16A468 for ; Mon, 11 Jun 2007 00:17:42 +0000 (UTC) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: from mired.org (vpn.mired.org [66.92.153.74]) by mx1.freebsd.org (Postfix) with SMTP id 5E92E13C48C for ; Mon, 11 Jun 2007 00:17:42 +0000 (UTC) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: (qmail 50266 invoked by uid 1001); 11 Jun 2007 00:15:33 -0000 Received: by bhuda.mired.org (tmda-sendmail, from uid 1001); Sun, 10 Jun 2007 20:15:33 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18028.37925.269776.104495@bhuda.mired.org> Date: Sun, 10 Jun 2007 20:15:33 -0400 To: Kris Kennaway In-Reply-To: <20070611000223.GA28536@rot13.obsecurity.org> References: <20070610120017.645B116A4DA@hub.freebsd.org> <466C8611.5020009@hesiod.org> <18028.36946.981778.560346@bhuda.mired.org> <20070611000709.GA30241@rot13.obsecurity.org> <20070611000223.GA28536@rot13.obsecurity.org> X-Mailer: VM 7.19 under Emacs 21.3.1 X-Primary-Address: mwm@mired.org X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`; h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ X-Delivery-Agent: TMDA/1.1.11 (Ladyburn) From: Mike Meyer Cc: freebsd-hackers@freebsd.org, Jeff Anton Subject: Re: pkgdb -F calling portupgrade -a X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2007 00:17:42 -0000 In <20070611000223.GA28536@rot13.obsecurity.org>, Kris Kennaway typed: > > ---> Checking the package registry database > > Stale dependency: Xaw3d-1.5E_1 -> xf86dgaproto-2.0.2 (x11/xf86dgaproto): > > Install stale dependency? ([y]es/[n]o/[a]ll) [yes] n > ^ > > New dependency? (? to help): > > Delete this? ([y]es/[n]o/[a]ll) [yes] > ^^^^ > Whee, you've deleted metadata that was required for correctness of > future upgrades. Just out of curiosity, what should he have done? Yes, the data was required for the correctness of future upgrades, but the data was broken in ways that the automated tools couldn't deal with. Installing the stale dependency would lead to incorrectly trying to install the new x.org 7 ports. There's no right-looking new dependency to use, or pkgdb would have suggested it. Leaving the dependency in place wouldn't solve the problem that pkgdb was run to fix in the first place. So what's the right alternative? http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 11 01:01:59 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7923716A41F for ; Mon, 11 Jun 2007 01:01:59 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 6340E13C43E for ; Mon, 11 Jun 2007 01:01:59 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id AA1261A4D84; Sun, 10 Jun 2007 18:01:46 -0700 (PDT) Received: from rot13.obsecurity.org (rot13.obsecurity.org [192.168.1.5]) by obsecurity.dyndns.org (Postfix) with ESMTP id B9A76511D0; Sun, 10 Jun 2007 21:01:58 -0400 (EDT) Received: by rot13.obsecurity.org (Postfix, from userid 1001) id 73E04BC90; Sun, 10 Jun 2007 21:01:58 -0400 (EDT) Date: Sun, 10 Jun 2007 21:01:58 -0400 From: Kris Kennaway To: Mike Meyer Message-ID: <20070611010158.GA36371@rot13.obsecurity.org> References: <20070610120017.645B116A4DA@hub.freebsd.org> <466C8611.5020009@hesiod.org> <18028.36946.981778.560346@bhuda.mired.org> <20070611000709.GA30241@rot13.obsecurity.org> <20070611000223.GA28536@rot13.obsecurity.org> <18028.37925.269776.104495@bhuda.mired.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18028.37925.269776.104495@bhuda.mired.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-hackers@freebsd.org, Jeff Anton , Kris Kennaway Subject: Re: pkgdb -F calling portupgrade -a X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2007 01:01:59 -0000 On Sun, Jun 10, 2007 at 08:15:33PM -0400, Mike Meyer wrote: > In <20070611000223.GA28536@rot13.obsecurity.org>, Kris Kennaway typed: > > > ---> Checking the package registry database > > > Stale dependency: Xaw3d-1.5E_1 -> xf86dgaproto-2.0.2 (x11/xf86dgaproto): > > > Install stale dependency? ([y]es/[n]o/[a]ll) [yes] n > > ^ > > > New dependency? (? to help): > > > Delete this? ([y]es/[n]o/[a]ll) [yes] > > ^^^^ > > Whee, you've deleted metadata that was required for correctness of > > future upgrades. > > Just out of curiosity, what should he have done? Yes, the data was > required for the correctness of future upgrades, but the data was > broken in ways that the automated tools couldn't deal with. Installing > the stale dependency would lead to incorrectly trying to install the > new x.org 7 ports. There's no right-looking new dependency to use, or > pkgdb would have suggested it. Leaving the dependency in place > wouldn't solve the problem that pkgdb was run to fix in the first > place. So what's the right alternative? I guess deleting it is probably the least bad alternative, followed by upgrading to xorg 7.2, followed by a pkgdb -L to repair the damage. Kris From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 11 06:53:28 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A5B8316A468 for ; Mon, 11 Jun 2007 06:53:28 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe13.swip.net [212.247.155.129]) by mx1.freebsd.org (Postfix) with ESMTP id 466B313C46E for ; Mon, 11 Jun 2007 06:53:28 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [194.248.135.20] (account mc467741@c2i.net HELO laptop.lan) by mailfe13.swip.net (CommuniGate Pro SMTP 5.1.9) with ESMTPA id 123591666; Mon, 11 Jun 2007 08:53:26 +0200 From: Hans Petter Selasky To: Garrett Cooper Date: Mon, 11 Jun 2007 08:53:21 +0200 User-Agent: KMail/1.9.5 References: <200706080848.36402.hselasky@c2i.net> <200706081217.19035.hselasky@c2i.net> <46697B3F.7080505@u.washington.edu> In-Reply-To: <46697B3F.7080505@u.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200706110853.21583.hselasky@c2i.net> Cc: freebsd-hackers@freebsd.org Subject: Re: Lost interrupts during boot X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2007 06:53:28 -0000 On Friday 08 June 2007 17:52, Garrett Cooper wrote: > Hans Petter Selasky wrote: > > On Friday 08 June 2007 11:43, Paolo Pisati wrote: > >>> I testing booting with a combo USB/Firewire carbus card, but no > >>> interrupts are > >>> genereated. If I plug the card in when the computer is not cold, it > >>> works fine. Any ideas? Does the cardbus driver generate a dummy > >>> interrupt to make > >>> sure that any outstanding interrupts are cleared? > >> > >> how old is your kernel? > >> can you see if there's a difference between a kernel > >> earlier than Thu May 31 19:29:20 2007 UTC and a recent one > >> (i.e. today)? > > > > I will try an update and let you know on Monday. > > > > --HPS > > Who makes your MB? Is it an nVidia chipset one? > -Garrett It is a laptop from Acer. BTW: I did not find time for testing this weekend. I will report back when I have tested current. --HPS From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 11 15:32:39 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BBDCB16A4FA for ; Mon, 11 Jun 2007 15:32:39 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id AE44813C469 for ; Mon, 11 Jun 2007 15:32:39 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id E0D121CC01C; Mon, 11 Jun 2007 08:16:20 -0700 (PDT) Date: Mon, 11 Jun 2007 08:16:20 -0700 From: Jeremy Chadwick To: freebsd-hackers@freebsd.org Message-ID: <20070611151620.GA17565@eos.sc1.parodius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.15 (2007-04-06) Subject: ASCII menu in loader/frames.4th X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2007 15:32:39 -0000 Just an idea I'd throw out there (-hackers seemed like the best place to discuss this): The current loader.conf defaults to having the fbsdbw logo and the menuing system appear. One of the "issues" is that the character set used to draw the menu box frames is CP437 ("IBM PC/DOS character set"). This doesn't look so great for those of us who choose to use ISO-8859-1 encoding or UTF-8 encoding; I mainly use PuTTY to connect to my FreeBSD boxes, and to get on serial console, use cu/tip or console. I think it would be useful to have a ASCII-ised version of the frame/menuing stuff in (I think?) frames.4th. The difference: CP437: ³ 3. Boot FreeBSD in Safe Mode ³ ³ 4. Boot FreeBSD in single user mode ³ ³ ³ ³ Select option, [Enter] for default ³ ³ or [Space] to pause timer 2 ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ASCII: | 3. Boot FreeBSD in Safe Mode | | 4. Boot FreeBSD in single user mode | | | | Select option, [Enter] for default | | or [Space] to pause timer 2 | +-----------------------------------------+ One could enable use of this with some loader.conf variable like loader_frames="ascii" or (default) loader_frames="cp437", possibly even a "vt100" type (using VT100 line-drawing characters). I'm not familiar with forth, otherwise I'd come up with a patch. Maybe I'll try learning it (argh, another language to learn...), or hack around a bit. Comments? -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 11 19:53:01 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 64CDB16A46F; Mon, 11 Jun 2007 19:53:01 +0000 (UTC) (envelope-from rpaulo@fnop.net) Received: from core.fnop.net (mx.fnop.net [82.102.11.82]) by mx1.freebsd.org (Postfix) with ESMTP id E125E13C45D; Mon, 11 Jun 2007 19:53:00 +0000 (UTC) (envelope-from rpaulo@fnop.net) Received: from core.fnop.net (mx.fnop.net [82.102.11.82]) by core.fnop.net (Postfix) with ESMTP id 05515690A7A; Mon, 11 Jun 2007 20:50:13 +0100 (WEST) Received: by core.fnop.net (Postfix, from userid 1015) id C56FF690AC5; Mon, 11 Jun 2007 20:50:12 +0100 (WEST) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on core.fnop.net X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=AWL, BAYES_00, FORGED_RCVD_HELO, RCVD_IN_DSBL,RCVD_IN_SORBS_DUL autolearn=no version=3.1.7 Received: from epsilon.local.fnop.net (87-196-57-209.net.novis.pt [87.196.57.209]) by core.fnop.net (Postfix) with ESMTP id 14DFC690A7A; Mon, 11 Jun 2007 20:50:11 +0100 (WEST) Date: Mon, 11 Jun 2007 20:52:54 +0100 Message-ID: <86lkeqxo89.wl%rpaulo@fnop.net> From: Rui Paulo To: Chuck Swiger In-Reply-To: References: <4AB3C4C0-0DA1-482F-A4CD-375A53332F29@mac.com> <4D7CDA24-48FE-4319-A320-C8D7165E9EBC@mac.com> <200706092128.l59LSjRs027671@apollo.backplane.com> <57F8CCC1-1841-41AE-9F82-0C87FE53BE99@mac.com> <200706101752.l5AHqdE0035954@apollo.backplane.com> <8B01C1EC-D61A-484F-B308-6D6C8EB00EE6@mac.com> <861wgjwnrw.wl%rpaulo@fnop.net> <200706102143.l5ALhQut038340@apollo.backplane.com> <86zm37v4ns.wl%rpaulo@fnop.net> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/21.3 Mule/5.0 (SAKAKI) X-cite-me: rpaulo MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: ClamAV using ClamSMTP X-Mailman-Approved-At: Mon, 11 Jun 2007 20:09:15 +0000 Cc: freebsd-hackers@freebsd.org, Marcel Moolenaar , freebsd-current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: GPT - (last) call for action X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2007 19:53:01 -0000 At Mon, 11 Jun 2007 12:41:18 -0700, Chuck Swiger wrote: > > Hi, all-- > > On Jun 10, 2007, at 3:13 PM, Rui Paulo wrote: > >> :Media sector size is 512 > >> :Warning: BIOS sector numbering starts with sector 1 > >> :Information from DOS bootblock is: > >> :The data for partition 1 is: > >> :sysid 238 (0xee),(EFI GPT) > >> : start 40, size 409600 (200 Meg), flag 0 > >> : beg: cyl 0/ head 0/ sector 41; > >> : end: cyl 406/ head 6/ sector 14 > >> > >> I think I have it mostly figured out, but the 'start 40' in your > >> output can't be right. The intel documentation says that the > >> starting LBA in a PMBR record must be set to 1 by definition > >> (table 11-7 in the 1.10 documentation). > > > > I don't know why Apple does that. > > The offset of 40 sectors sounds like it is pointing to the first > partition listed within the GPT? > > A typical Intel Mac system using GPT ought to look something like this: > > # fdisk /dev/rdisk0 > Disk: /dev/rdisk0 geometry: 9964/255/63 [160086528 sectors] > Signature: 0xAA55 > Starting Ending > #: id cyl hd sec - cyl hd sec [ start - size] > ------------------------------------------------------------------------ > 1: EE 1023 254 63 - 1023 254 63 [ 1 - 160086520] > 2: 00 0 0 0 - 0 0 0 [ 0 - 0] unused > 3: 00 0 0 0 - 0 0 0 [ 0 - 0] unused > 4: 00 0 0 0 - 0 0 0 [ 0 - 0] unused > > # gpt -r show /dev/rdisk0 > start size index contents > 0 1 PMBR > 1 1 Pri GPT header > 2 32 Pri GPT table > 34 6 > 40 409600 1 GPT part - C12A7328-F81F-11D2-BA4B- > xxxxxxxxxxxx > 409640 159414704 2 GPT part - 48465300-0000-11AA-AA11- > xxxxxxxxxxxx > 159824344 262151 > 160086495 32 Sec GPT table > 160086527 1 Sec GPT header Well, what's happening is that Boot Camp syncs the BIOS partition table with the GPT table, so the first partition should start at 40, just like the GPT. Why does it start at 40 ? Because you need room for the PMBR, the Primary GPT header and the Primary GPT table. Now, you don't seem to have used Boot Camp on your Mac, right? If you ever use it, fdisk /dev/rdisk0 will show things differently. The first partition with id 0xEE will should start at LBA 40 and end at LBA 409640. > The first, small partition is almost certainly a "boothfs" boot > partition, as described in the man page for Apple's version of > fdisk: I don't think so. The boothfs partition doesn't seem to be used on Intel Macs no longer. The EFI boot loader that comes with Intel Macs can read HFS+ without any help (actually it's an EFI module), so bootufs/boothfs partitions are no longer required. -- Rui Paulo From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 11 19:53:44 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 54B9016A41F; Mon, 11 Jun 2007 19:53:44 +0000 (UTC) (envelope-from rpaulo@fnop.net) Received: from core.fnop.net (mx.fnop.net [82.102.11.82]) by mx1.freebsd.org (Postfix) with ESMTP id D121213C447; Mon, 11 Jun 2007 19:53:43 +0000 (UTC) (envelope-from rpaulo@fnop.net) Received: from core.fnop.net (mx.fnop.net [82.102.11.82]) by core.fnop.net (Postfix) with ESMTP id A34E3690A7A; Mon, 11 Jun 2007 20:50:56 +0100 (WEST) Received: by core.fnop.net (Postfix, from userid 1015) id 710B4690AC5; Mon, 11 Jun 2007 20:50:56 +0100 (WEST) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on core.fnop.net X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=AWL, BAYES_00, FORGED_RCVD_HELO, RCVD_IN_DSBL,RCVD_IN_SORBS_DUL autolearn=no version=3.1.7 Received: from epsilon.local.fnop.net (87-196-57-209.net.novis.pt [87.196.57.209]) by core.fnop.net (Postfix) with ESMTP id EFABD690A7A; Mon, 11 Jun 2007 20:50:55 +0100 (WEST) Date: Mon, 11 Jun 2007 20:53:41 +0100 Message-ID: <86k5uaxo6y.wl%rpaulo@fnop.net> From: Rui Paulo To: Matthew Dillon In-Reply-To: <86zm37v4ns.wl%rpaulo@fnop.net> References: <4AB3C4C0-0DA1-482F-A4CD-375A53332F29@mac.com> <4D7CDA24-48FE-4319-A320-C8D7165E9EBC@mac.com> <200706092128.l59LSjRs027671@apollo.backplane.com> <57F8CCC1-1841-41AE-9F82-0C87FE53BE99@mac.com> <200706101752.l5AHqdE0035954@apollo.backplane.com> <8B01C1EC-D61A-484F-B308-6D6C8EB00EE6@mac.com> <861wgjwnrw.wl%rpaulo@fnop.net> <200706102143.l5ALhQut038340@apollo.backplane.com> <86zm37v4ns.wl%rpaulo@fnop.net> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/21.3 Mule/5.0 (SAKAKI) X-cite-me: rpaulo MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: ClamAV using ClamSMTP X-Mailman-Approved-At: Mon, 11 Jun 2007 20:09:15 +0000 Cc: freebsd-hackers@freebsd.org, Marcel Moolenaar , freebsd-current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: GPT - (last) call for action X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2007 19:53:44 -0000 At Sun, 10 Jun 2007 23:13:59 +0100, Rui Paulo wrote: > > At Sun, 10 Jun 2007 14:43:26 -0700 (PDT), > Matthew Dillon wrote: > > > > > > :No. > > :The first partition is the EFI GPT (0xee): > > : > > :% fdisk -1 > > :******* Working on device /dev/ad0 ******* > > :... > > :parameters to be used for BIOS calculations are: > > :cylinders=116280 heads=16 sectors/track=63 (1008 blks/cyl) > > : > > :Media sector size is 512 > > :Warning: BIOS sector numbering starts with sector 1 > > :Information from DOS bootblock is: > > :The data for partition 1 is: > > :sysid 238 (0xee),(EFI GPT) > > : start 40, size 409600 (200 Meg), flag 0 > > : beg: cyl 0/ head 0/ sector 41; > > : end: cyl 406/ head 6/ sector 14 > > > > I think I have it mostly figured out, but the 'start 40' in your > > output can't be right. The intel documentation says that the > > starting LBA in a PMBR record must be set to 1 by definition > > (table 11-7 in the 1.10 documentation). > > I don't know why Apple does that. Actually, I think I do. See my other email. Regards. -- Rui Paulo From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 11 19:58:04 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3718B16A47E; Mon, 11 Jun 2007 19:58:04 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by mx1.freebsd.org (Postfix) with ESMTP id 4B31813C4C7; Mon, 11 Jun 2007 19:58:02 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from relay7.apple.com (relay7.apple.com [17.128.113.37]) by mail-out3.apple.com (Postfix) with ESMTP id B4B08888FC5; Mon, 11 Jun 2007 12:40:14 -0700 (PDT) Received: from relay7.apple.com (unknown [127.0.0.1]) by relay7.apple.com (Symantec Mail Security) with ESMTP id 259E2300AC; Mon, 11 Jun 2007 12:41:19 -0700 (PDT) X-AuditID: 11807125-9ef62bb000000801-12-466da55eb1af Received: from [17.214.13.96] (cswiger1.apple.com [17.214.13.96]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay7.apple.com (Apple SCV relay) with ESMTP id E1EAD30063; Mon, 11 Jun 2007 12:41:18 -0700 (PDT) In-Reply-To: <86zm37v4ns.wl%rpaulo@fnop.net> References: <4AB3C4C0-0DA1-482F-A4CD-375A53332F29@mac.com> <4D7CDA24-48FE-4319-A320-C8D7165E9EBC@mac.com> <200706092128.l59LSjRs027671@apollo.backplane.com> <57F8CCC1-1841-41AE-9F82-0C87FE53BE99@mac.com> <200706101752.l5AHqdE0035954@apollo.backplane.com> <8B01C1EC-D61A-484F-B308-6D6C8EB00EE6@mac.com> <861wgjwnrw.wl%rpaulo@fnop.net> <200706102143.l5ALhQut038340@apollo.backplane.com> <86zm37v4ns.wl%rpaulo@fnop.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Chuck Swiger Date: Mon, 11 Jun 2007 12:41:18 -0700 To: Rui Paulo X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Mon, 11 Jun 2007 20:09:15 +0000 Cc: freebsd-hackers@freebsd.org, Marcel Moolenaar , freebsd-current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: GPT - (last) call for action X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2007 19:58:04 -0000 Hi, all-- On Jun 10, 2007, at 3:13 PM, Rui Paulo wrote: >> :Media sector size is 512 >> :Warning: BIOS sector numbering starts with sector 1 >> :Information from DOS bootblock is: >> :The data for partition 1 is: >> :sysid 238 (0xee),(EFI GPT) >> : start 40, size 409600 (200 Meg), flag 0 >> : beg: cyl 0/ head 0/ sector 41; >> : end: cyl 406/ head 6/ sector 14 >> >> I think I have it mostly figured out, but the 'start 40' in your >> output can't be right. The intel documentation says that the >> starting LBA in a PMBR record must be set to 1 by definition >> (table 11-7 in the 1.10 documentation). > > I don't know why Apple does that. The offset of 40 sectors sounds like it is pointing to the first partition listed within the GPT? A typical Intel Mac system using GPT ought to look something like this: # fdisk /dev/rdisk0 Disk: /dev/rdisk0 geometry: 9964/255/63 [160086528 sectors] Signature: 0xAA55 Starting Ending #: id cyl hd sec - cyl hd sec [ start - size] ------------------------------------------------------------------------ 1: EE 1023 254 63 - 1023 254 63 [ 1 - 160086520] 2: 00 0 0 0 - 0 0 0 [ 0 - 0] unused 3: 00 0 0 0 - 0 0 0 [ 0 - 0] unused 4: 00 0 0 0 - 0 0 0 [ 0 - 0] unused # gpt -r show /dev/rdisk0 start size index contents 0 1 PMBR 1 1 Pri GPT header 2 32 Pri GPT table 34 6 40 409600 1 GPT part - C12A7328-F81F-11D2-BA4B- xxxxxxxxxxxx 409640 159414704 2 GPT part - 48465300-0000-11AA-AA11- xxxxxxxxxxxx 159824344 262151 160086495 32 Sec GPT table 160086527 1 Sec GPT header The first, small partition is almost certainly a "boothfs" boot partition, as described in the man page for Apple's version of fdisk: " In the default template, partition number 1 will be configured as a Dar- win boot partition spanning from cylinder 0, head 1, sector 1, and extending for 8 megabytes. Partition number 2 will be configured as a Darwin HFS partition spanning the rest of the disk. This mode is designed to initialize an MBR the very first time, or when it has been corrupted beyond repair. You can specify other default partition styles with the -a flag. The available styles are: boothfs Creates an 8Mb boot partition (type AB hex) and makes the rest of the disk a Darwin HFS partition (type AF hex). bootufs Creates an 8Mb boot partition (type AB hex) and makes the rest of the disk a Darwin UFS partition (type A8 hex). hfs Makes the entire disk one Darwin UFS partition (type A8 hex). ufs Makes the entire disk one HFS+ partition (type AF hex). dos Makes the entire disk one DOS partition (type 0C hex). raid Makes the entire disk one type AC hex partition. The -u flag is used to update the MBR code on a given drive. The MBR code extends from offset 0x000 to the start of the partition table at offset 0x1BE. It is similar to the -i flag, except the existing parti- tion table is preserved. This is useful for writing new MBR code onto an existing drive, and is equivalent to the DOS command ``FDISK / MBR''. Note that this option will overwrite the NT disk signature, if present. The -u and -i flags may not be specified together." Also cf: http://en.wikipedia.org/wiki/GUID_Partition_Table -- -Chuck From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 11 20:12:06 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7485216A400; Mon, 11 Jun 2007 20:12:06 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by mx1.freebsd.org (Postfix) with ESMTP id 531DF13C45E; Mon, 11 Jun 2007 20:12:06 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from relay8.apple.com (relay8.apple.com [17.128.113.38]) by mail-out3.apple.com (Postfix) with ESMTP id B6863889BA9; Mon, 11 Jun 2007 13:11:01 -0700 (PDT) Received: from relay8.apple.com (unknown [127.0.0.1]) by relay8.apple.com (Symantec Mail Security) with ESMTP id 2DFDB40080; Mon, 11 Jun 2007 13:12:06 -0700 (PDT) X-AuditID: 11807126-9e882bb00000081c-dc-466dac95833b Received: from [17.214.13.96] (cswiger1.apple.com [17.214.13.96]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay8.apple.com (Apple SCV relay) with ESMTP id E89C240024; Mon, 11 Jun 2007 13:12:05 -0700 (PDT) In-Reply-To: <86lkeqxo89.wl%rpaulo@fnop.net> References: <4AB3C4C0-0DA1-482F-A4CD-375A53332F29@mac.com> <4D7CDA24-48FE-4319-A320-C8D7165E9EBC@mac.com> <200706092128.l59LSjRs027671@apollo.backplane.com> <57F8CCC1-1841-41AE-9F82-0C87FE53BE99@mac.com> <200706101752.l5AHqdE0035954@apollo.backplane.com> <8B01C1EC-D61A-484F-B308-6D6C8EB00EE6@mac.com> <861wgjwnrw.wl%rpaulo@fnop.net> <200706102143.l5ALhQut038340@apollo.backplane.com> <86zm37v4ns.wl%rpaulo@fnop.net> <86lkeqxo89.wl%rpaulo@fnop.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Chuck Swiger Date: Mon, 11 Jun 2007 13:12:04 -0700 To: Rui Paulo X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Mon, 11 Jun 2007 20:22:13 +0000 Cc: freebsd-hackers@freebsd.org, Marcel Moolenaar , freebsd-current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: GPT - (last) call for action X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2007 20:12:06 -0000 On Jun 11, 2007, at 12:52 PM, Rui Paulo wrote: >> A typical Intel Mac system using GPT ought to look something like >> this: >> >> # fdisk /dev/rdisk0 >> Disk: /dev/rdisk0 geometry: 9964/255/63 [160086528 sectors] >> Signature: 0xAA55 >> Starting Ending >> #: id cyl hd sec - cyl hd sec [ start - size] >> --------------------------------------------------------------------- >> --- >> 1: EE 1023 254 63 - 1023 254 63 [ 1 - 160086520] >> >> 2: 00 0 0 0 - 0 0 0 [ 0 - 0] unused >> 3: 00 0 0 0 - 0 0 0 [ 0 - 0] unused >> 4: 00 0 0 0 - 0 0 0 [ 0 - 0] unused >> >> # gpt -r show /dev/rdisk0 >> start size index contents >> 0 1 PMBR >> 1 1 Pri GPT header >> 2 32 Pri GPT table >> 34 6 >> 40 409600 1 GPT part - C12A7328-F81F-11D2-BA4B- >> xxxxxxxxxxxx >> 409640 159414704 2 GPT part - 48465300-0000-11AA-AA11- >> xxxxxxxxxxxx >> 159824344 262151 >> 160086495 32 Sec GPT table >> 160086527 1 Sec GPT header > > Well, what's happening is that Boot Camp syncs the BIOS partition > table with the GPT table, so the first partition should start at 40, > just like the GPT. > > Why does it start at 40 ? Because you need room for the PMBR, the > Primary GPT header and the Primary GPT table. Agreed, you need about 32 sectors for the GPT header+table. > Now, you don't seem to have used Boot Camp on your Mac, right? It's true that the machine in question has never used BootCamp, correct. > If you ever use it, fdisk /dev/rdisk0 will show things differently. > The first partition with id 0xEE will should start at LBA 40 and end > at LBA 409640. OK: although that surprises me a bit, perhaps trying to get Windows XP (which may not understand the ~32 sector GPT header+table) means that claiming the first partition in the MBR starts at 40 works better...? >> The first, small partition is almost certainly a "boothfs" boot >> partition, as described in the man page for Apple's version of >> fdisk: > > I don't think so. > The boothfs partition doesn't seem to be used on Intel Macs no > longer. The EFI boot loader that comes with Intel Macs can read HFS+ > without any help (actually it's an EFI module), so bootufs/boothfs > partitions are no longer required. It looks like you're right-- the OS-X formatting utilities still reserve space for the boot partition, but they just scribble enough to this space to indicate that the partition isn't actually bootable: # dd if=/dev/disk0s1 bs=512 count=409600 | hexdump -C 00000000 eb 58 90 42 53 44 20 20 34 2e 34 00 02 01 20 00 |.X.BSD 4.4... .| 00000010 02 00 00 00 00 f0 00 00 00 00 00 00 28 00 00 00 |............(...| 00000020 00 40 06 00 67 0c 00 00 00 00 00 00 02 00 00 00 |.@..g...........| 00000030 01 00 06 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000040 00 00 29 f4 11 60 28 45 46 49 20 20 20 20 20 20 |..)..` (EFI | 00000050 20 20 46 41 54 33 32 20 20 20 fa 31 c0 8e d0 bc | FAT32 .1....| 00000060 00 7c fb 8e d8 e8 00 00 5e 83 c6 19 bb 07 00 fc |.|......^.......| 00000070 ac 84 c0 74 06 b4 0e cd 10 eb f5 30 e4 cd 16 cd |...t.......0....| 00000080 19 0d 0a 4e 6f 6e 2d 73 79 73 74 65 6d 20 64 69 |...Non- system di| 00000090 73 6b 0d 0a 50 72 65 73 73 20 61 6e 79 20 6b 65 | sk..Press any ke| 000000a0 79 20 74 6f 20 72 65 62 6f 6f 74 0d 0a 00 00 00 |y to reboot.....| 000000b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.| 00000200 52 52 61 41 00 00 00 00 00 00 00 00 00 00 00 00 | RRaA............| 00000210 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 000003e0 00 00 00 00 72 72 41 61 ff ff ff ff ff ff ff ff |....rrAa........| 000003f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.| 00000400 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000c00 eb 58 90 42 53 44 20 20 34 2e 34 00 02 01 20 00 |.X.BSD 4.4... .| 00000c10 02 00 00 00 00 f0 00 00 00 00 00 00 28 00 00 00 |............(...| 00000c20 00 40 06 00 67 0c 00 00 00 00 00 00 02 00 00 00 |.@..g...........| 00000c30 01 00 06 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000c40 00 00 29 f4 11 60 28 45 46 49 20 20 20 20 20 20 |..)..` (EFI | 00000c50 20 20 46 41 54 33 32 20 20 20 fa 31 c0 8e d0 bc | FAT32 .1....| 00000c60 00 7c fb 8e d8 e8 00 00 5e 83 c6 19 bb 07 00 fc |.|......^.......| 00000c70 ac 84 c0 74 06 b4 0e cd 10 eb f5 30 e4 cd 16 cd |...t.......0....| 00000c80 19 0d 0a 4e 6f 6e 2d 73 79 73 74 65 6d 20 64 69 |...Non- system di| 00000c90 73 6b 0d 0a 50 72 65 73 73 20 61 6e 79 20 6b 65 | sk..Press any ke| 00000ca0 79 20 74 6f 20 72 65 62 6f 6f 74 0d 0a 00 00 00 |y to reboot.....| 00000cb0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000df0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.| 00000e00 52 52 61 41 00 00 00 00 00 00 00 00 00 00 00 00 | RRaA............| 00000e10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000fe0 00 00 00 00 72 72 41 61 ff ff ff ff ff ff ff ff |....rrAa........| 00000ff0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.| 00001000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00004000 f0 ff ff 0f ff ff ff 0f ff ff ff 0f 00 00 00 00 |................| 00004010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00190e00 f0 ff ff 0f ff ff ff 0f ff ff ff 0f 00 00 00 00 |................| 00190e10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 0031dc00 45 46 49 20 20 20 20 20 20 20 20 08 00 00 00 00 | EFI .....| 0031dc10 00 00 00 00 00 00 1b a7 85 35 00 00 00 00 00 00 |......... 5......| 0031dc20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 409600+0 records in 409600+0 records out -- -Chuck From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 11 20:33:48 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1684516A4A7; Mon, 11 Jun 2007 20:33:48 +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 C538A13C4C4; Mon, 11 Jun 2007 20:33:47 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.13.8/8.13.7) with ESMTP id l5BKXgiJ052684; Mon, 11 Jun 2007 13:33:42 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.13.8/8.13.4/Submit) id l5BKXgNf052683; Mon, 11 Jun 2007 13:33:42 -0700 (PDT) Date: Mon, 11 Jun 2007 13:33:42 -0700 (PDT) From: Matthew Dillon Message-Id: <200706112033.l5BKXgNf052683@apollo.backplane.com> To: Chuck Swiger References: <4AB3C4C0-0DA1-482F-A4CD-375A53332F29@mac.com> <4D7CDA24-48FE-4319-A320-C8D7165E9EBC@mac.com> <200706092128.l59LSjRs027671@apollo.backplane.com> <57F8CCC1-1841-41AE-9F82-0C87FE53BE99@mac.com> <200706101752.l5AHqdE0035954@apollo.backplane.com> <8B01C1EC-D61A-484F-B308-6D6C8EB00EE6@mac.com> <861wgjwnrw.wl%rpaulo@fnop.net> <200706102143.l5ALhQut038340@apollo.backplane.com> <86zm37v4ns.wl%rpaulo@fnop.net> <86lkeqxo89.wl%rpaulo@fnop.net> Cc: Rui Paulo , freebsd-hackers@freebsd.org, Marcel Moolenaar , freebsd-current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: GPT - (last) call for action X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2007 20:33:48 -0000 :>> # gpt -r show /dev/rdisk0 :>> start size index contents :>> 0 1 PMBR :>> 1 1 Pri GPT header :>> 2 32 Pri GPT table :>> 34 6 :>> 40 409600 1 GPT part - C12A7328-F81F-11D2-BA4B- :>> xxxxxxxxxxxx :>> 409640 159414704 2 GPT part - 48465300-0000-11AA-AA11- :>> xxxxxxxxxxxx :... :> Well, what's happening is that Boot Camp syncs the BIOS partition :> table with the GPT table, so the first partition should start at 40, :> just like the GPT. :> :> Why does it start at 40 ? Because you need room for the PMBR, the :> Primary GPT header and the Primary GPT table. : :Agreed, you need about 32 sectors for the GPT header+table. It makes sense for them to point the first MBR slice at the first partition in the GPT, even though the standard says something else. It really sounds like they are making an accomodation for BIOS booting or older Windows booting... or *something* of that sort. The fact that the bootability bit is not set in the MBR (I'm not sure about that, is it set or not?)... that seems to imply a compatibility issue with other OS's like Windows in a multi-boot environment. They are just doing it all with a single slice instead of having two slices. I'll bet they found that the two-slice method doesn't work in some cases and the one-slice method does. The standard document doesn't allow either method but it does seem to be a bit less insistent on the starting sector for slice 1 then it does on there only being one slice in the MBR, period. I can also see some OS's / disk managers barfing on having two slices which overlap each other. So it really does make sense for them to point the MBR at sector 40. The more I think about it, the more sense it makes. -Matt Matthew Dillon From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 11 21:42:31 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 64A0916A468 for ; Mon, 11 Jun 2007 21:42:31 +0000 (UTC) (envelope-from msaad@datapipe.com) Received: from exchfe01.datapipe-corp.net (exchfe01.datapipe-corp.net [64.106.130.69]) by mx1.freebsd.org (Postfix) with ESMTP id 3210213C468 for ; Mon, 11 Jun 2007 21:42:31 +0000 (UTC) (envelope-from msaad@datapipe.com) Received: from oceanspray.teb.datapipe.net (192.168.81.31) by exchfe01.datapipe-corp.net (64.106.130.71) with Microsoft SMTP Server (TLS) id 8.0.700.0; Mon, 11 Jun 2007 17:32:19 -0400 Message-ID: <466DBF4A.90303@datapipe.com> Date: Mon, 11 Jun 2007 17:31:54 -0400 From: Mark Saad User-Agent: Thunderbird 2.0.0.0 (X11/20070521) MIME-Version: 1.0 To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Subject: HP SmartArray ( CISS ) and CAMCONTROL X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: msaad@datapipe.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2007 21:42:31 -0000 Hello Hackers@ I have been searching around and I can not find an answer to a problem of mine . Does anyone know if its possible to make camcontrol show the drive health for drives in a HP SMART Array . Currently it will show the Array heath by running camcontrol devlist -v . jumpstart# camcontrol devlist -v scbus0 on ciss0 bus 0: at scbus0 target 0 lun 0 (pass0,da0) at scbus0 target 1 lun 0 (pass1,da1) scbus1 on ciss0 bus 32: scbus-1 on xpt0 bus 0: < > at scbus-1 target -1 lun -1 (xpt0) -- Mark Saad msaad@datapipe.com From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 11 22:11:57 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2D5D816A41F for ; Mon, 11 Jun 2007 22:11:57 +0000 (UTC) (envelope-from msaad@datapipe.com) Received: from exchfe01.datapipe-corp.net (exchfe01.datapipe-corp.net [64.106.130.69]) by mx1.freebsd.org (Postfix) with ESMTP id EC68013C44B for ; Mon, 11 Jun 2007 22:11:56 +0000 (UTC) (envelope-from msaad@datapipe.com) Received: from oceanspray.teb.datapipe.net (192.168.81.31) by exchfe01.datapipe-corp.net (64.106.130.71) with Microsoft SMTP Server (TLS) id 8.0.700.0; Mon, 11 Jun 2007 18:11:56 -0400 Message-ID: <466DC895.3030809@datapipe.com> Date: Mon, 11 Jun 2007 18:11:33 -0400 From: Mark Saad User-Agent: Thunderbird 2.0.0.0 (X11/20070521) MIME-Version: 1.0 To: Joao Barros References: <466DBF4A.90303@datapipe.com> <70e8236f0706111457o46c783d8k3a18dc2c633c043b@mail.gmail.com> In-Reply-To: <70e8236f0706111457o46c783d8k3a18dc2c633c043b@mail.gmail.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: HP SmartArray ( CISS ) and CAMCONTROL X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: msaad@datapipe.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2007 22:11:57 -0000 Sure I have lots of HP Gear, send me your patches. I have access to the SA 5i 6i, p400 p600 p800 and 641 and 642 cards. Also any idea if BIO would be able to help with The MPT SAS1060 ? Joao Barros wrote: > Hi, > > I'm porting bio(4) from OpenBSD to FreeBSD and lost access to a ciss > card after switching jobs. > I'm starting with support for amr as I own one. Would you be willing > to test patches for ciss later on? > > On 6/11/07, Mark Saad wrote: >> Hello Hackers@ >> >> I have been searching around and I can not find an answer to a >> problem of mine . Does anyone know if its possible >> to make camcontrol show the drive health for drives in a HP SMART Array >> . Currently it will show the Array heath >> by running camcontrol devlist -v . >> >> jumpstart# camcontrol devlist -v >> scbus0 on ciss0 bus 0: >> at scbus0 target 0 lun 0 (pass0,da0) >> at scbus0 target 1 lun 0 (pass1,da1) >> scbus1 on ciss0 bus 32: >> scbus-1 on xpt0 bus 0: >> < > at scbus-1 target -1 lun -1 (xpt0) >> >> >> >> >> >> -- >> Mark Saad >> msaad@datapipe.com >> >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to >> "freebsd-hackers-unsubscribe@freebsd.org" >> > > -- Mark Saad Managed UNIX Support DataPipe Managed Global IT Services msaad@datapipe.com 1.201.792.4847 (international) 1.888.749.5821 (toll free) From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 11 22:19:07 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B59BA16A400 for ; Mon, 11 Jun 2007 22:19:07 +0000 (UTC) (envelope-from mjacob@freebsd.org) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id 8189513C4B0 for ; Mon, 11 Jun 2007 22:19:07 +0000 (UTC) (envelope-from mjacob@freebsd.org) Received: from ns1.feral.com (localhost [127.0.0.1]) by ns1.feral.com (8.14.1/8.14.1) with ESMTP id l5BMIv8d051105; Mon, 11 Jun 2007 15:19:05 -0700 (PDT) (envelope-from mjacob@freebsd.org) Received: from localhost (mjacob@localhost) by ns1.feral.com (8.14.1/8.14.1/Submit) with ESMTP id l5BMIvFn051102; Mon, 11 Jun 2007 15:18:57 -0700 (PDT) (envelope-from mjacob@freebsd.org) X-Authentication-Warning: ns1.feral.com: mjacob owned process doing -bs Date: Mon, 11 Jun 2007 15:18:57 -0700 (PDT) From: mjacob@freebsd.org To: Mark Saad Message-ID: <20070611151747.W51099@ns1.feral.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org, Joao Barros Subject: Re: HP SmartArray ( CISS ) and CAMCONTROL X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mjacob@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2007 22:19:07 -0000 >Also any idea if BIO would be able to help with The MPT SAS1060 ? That's not likely the direction to go. LSIutil is being ported, and possibly MPTutil. From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 11 22:19:53 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DE01316A41F for ; Mon, 11 Jun 2007 22:19:53 +0000 (UTC) (envelope-from mjacob@freebsd.org) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id A834F13C45D for ; Mon, 11 Jun 2007 22:19:53 +0000 (UTC) (envelope-from mjacob@freebsd.org) Received: from ns1.feral.com (localhost [127.0.0.1]) by ns1.feral.com (8.14.1/8.14.1) with ESMTP id l5BMJSYd051112; Mon, 11 Jun 2007 15:19:36 -0700 (PDT) (envelope-from mjacob@freebsd.org) Received: from localhost (mjacob@localhost) by ns1.feral.com (8.14.1/8.14.1/Submit) with ESMTP id l5BMJSMR051109; Mon, 11 Jun 2007 15:19:28 -0700 (PDT) (envelope-from mjacob@freebsd.org) X-Authentication-Warning: ns1.feral.com: mjacob owned process doing -bs Date: Mon, 11 Jun 2007 15:19:28 -0700 (PDT) From: mjacob@freebsd.org To: Mark Saad In-Reply-To: <20070611151747.W51099@ns1.feral.com> Message-ID: <20070611151903.P51099@ns1.feral.com> References: <20070611151747.W51099@ns1.feral.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org, Joao Barros Subject: Re: HP SmartArray ( CISS ) and CAMCONTROL X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mjacob@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2007 22:19:53 -0000 On Mon, 11 Jun 2007, mjacob@freebsd.org wrote: > >> Also any idea if BIO would be able to help with The MPT SAS1060 ? > > That's not likely the direction to go. LSIutil is being ported, and possibly > MPTutil. > > Argh- mean 'raidutil'. -matt From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 11 22:26:19 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4500E16A400 for ; Mon, 11 Jun 2007 22:26:19 +0000 (UTC) (envelope-from joao.barros@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by mx1.freebsd.org (Postfix) with ESMTP id 8415C13C457 for ; Mon, 11 Jun 2007 22:26:18 +0000 (UTC) (envelope-from joao.barros@gmail.com) Received: by ug-out-1314.google.com with SMTP id u2so22263uge for ; Mon, 11 Jun 2007 15:26:17 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=depWHAoUK9XXKOX4H3aGHVXTd6ToBXJdzHFMU4lvxMd+1pWp+3Wt22tPmSG4MdXVPcbwyQ0XjyiMXzRYCsp6691TUBkkyxu5PRfcNwRekyKrcp6UY1xTLYsP79ie45sfqdKNmwnJnDSW65RNOiOg6cTFBwCnoNbV9+duNgHNFVg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=W0Pa0d0vaD1PNYSv2KznZ2YaJTe3Ypv6x/NOWaqBE/KYZUhFuDNpX057cF46Zj5fWvvSX42hvga2dJaBZFlTrv1NG92nORRBdNfoQEWTy9zxYV4Fc9mQlwmmc5SC9+xMnJxwQV/g58nNjvPbmmwHQpCLnPn1kkZFx/s9qSrvoak= Received: by 10.78.147.6 with SMTP id u6mr2411710hud.1181599029818; Mon, 11 Jun 2007 14:57:09 -0700 (PDT) Received: by 10.78.163.2 with HTTP; Mon, 11 Jun 2007 14:57:09 -0700 (PDT) Message-ID: <70e8236f0706111457o46c783d8k3a18dc2c633c043b@mail.gmail.com> Date: Mon, 11 Jun 2007 22:57:09 +0100 From: "Joao Barros" To: msaad@datapipe.com In-Reply-To: <466DBF4A.90303@datapipe.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <466DBF4A.90303@datapipe.com> Cc: freebsd-hackers@freebsd.org Subject: Re: HP SmartArray ( CISS ) and CAMCONTROL X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2007 22:26:19 -0000 Hi, I'm porting bio(4) from OpenBSD to FreeBSD and lost access to a ciss card after switching jobs. I'm starting with support for amr as I own one. Would you be willing to test patches for ciss later on? On 6/11/07, Mark Saad wrote: > Hello Hackers@ > > I have been searching around and I can not find an answer to a > problem of mine . Does anyone know if its possible > to make camcontrol show the drive health for drives in a HP SMART Array > . Currently it will show the Array heath > by running camcontrol devlist -v . > > jumpstart# camcontrol devlist -v > scbus0 on ciss0 bus 0: > at scbus0 target 0 lun 0 (pass0,da0) > at scbus0 target 1 lun 0 (pass1,da1) > scbus1 on ciss0 bus 32: > scbus-1 on xpt0 bus 0: > < > at scbus-1 target -1 lun -1 (xpt0) > > > > > > -- > Mark Saad > msaad@datapipe.com > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > -- Joao Barros From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 11 22:35:51 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B782C16A400 for ; Mon, 11 Jun 2007 22:35:51 +0000 (UTC) (envelope-from msaad@datapipe.com) Received: from exchfe01.datapipe-corp.net (exchfe01.datapipe-corp.net [64.106.130.69]) by mx1.freebsd.org (Postfix) with ESMTP id 80B4113C448 for ; Mon, 11 Jun 2007 22:35:51 +0000 (UTC) (envelope-from msaad@datapipe.com) Received: from oceanspray.teb.datapipe.net (192.168.81.31) by exchfe01.datapipe-corp.net (64.106.130.71) with Microsoft SMTP Server (TLS) id 8.0.700.0; Mon, 11 Jun 2007 18:35:51 -0400 Message-ID: <466DCE30.5020009@datapipe.com> Date: Mon, 11 Jun 2007 18:35:28 -0400 From: Mark Saad User-Agent: Thunderbird 2.0.0.0 (X11/20070521) MIME-Version: 1.0 To: References: <20070611151747.W51099@ns1.feral.com> <20070611151903.P51099@ns1.feral.com> In-Reply-To: <20070611151903.P51099@ns1.feral.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Joao Barros Subject: Re: HP SmartArray ( CISS ) and CAMCONTROL X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: msaad@datapipe.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2007 22:35:51 -0000 Matt What will raidutill offer ? Also does anyone know if HP provides hpacucli for FreeBSD ,but only to Japanese customers ? mjacob@freebsd.org wrote: > > > On Mon, 11 Jun 2007, mjacob@freebsd.org wrote: > >> >>> Also any idea if BIO would be able to help with The MPT SAS1060 ? >> >> That's not likely the direction to go. LSIutil is being ported, and >> possibly MPTutil. >> >> > > Argh- mean 'raidutil'. > > -matt > -- Mark Saad Managed UNIX Support DataPipe Managed Global IT Services msaad@datapipe.com 1.201.792.4847 (international) 1.888.749.5821 (toll free) From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 11 22:39:00 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 83E0116A41F; Mon, 11 Jun 2007 22:39:00 +0000 (UTC) (envelope-from mjacob@freebsd.org) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id 62C4413C43E; Mon, 11 Jun 2007 22:39:00 +0000 (UTC) (envelope-from mjacob@freebsd.org) Received: from ns1.feral.com (localhost [127.0.0.1]) by ns1.feral.com (8.14.1/8.14.1) with ESMTP id l5BMcoCQ051219; Mon, 11 Jun 2007 15:38:58 -0700 (PDT) (envelope-from mjacob@freebsd.org) Received: from localhost (mjacob@localhost) by ns1.feral.com (8.14.1/8.14.1/Submit) with ESMTP id l5BMcoJK051216; Mon, 11 Jun 2007 15:38:50 -0700 (PDT) (envelope-from mjacob@freebsd.org) X-Authentication-Warning: ns1.feral.com: mjacob owned process doing -bs Date: Mon, 11 Jun 2007 15:38:50 -0700 (PDT) From: mjacob@freebsd.org To: Mark Saad In-Reply-To: <466DCE30.5020009@datapipe.com> Message-ID: <20070611153748.U51202@ns1.feral.com> References: <20070611151747.W51099@ns1.feral.com> <20070611151903.P51099@ns1.feral.com> <466DCE30.5020009@datapipe.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org, Joao Barros , mjacob@freebsd.org Subject: Re: HP SmartArray ( CISS ) and CAMCONTROL X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mjacob@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2007 22:39:00 -0000 On Mon, 11 Jun 2007, Mark Saad wrote: > Matt > What will raidutill offer ? Like LSIutil, it's a utility from the vendor (LSI)- should provide at least CLI access to some RAID parameters otherwise unavailable. > Also does anyone know if HP provides > hpacucli for FreeBSD ,but only to Japanese customers ? > Not sure about this in the slightest. From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 11 22:56:21 2007 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.ORG Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AC2A716A46D; Mon, 11 Jun 2007 22:56:21 +0000 (UTC) (envelope-from msaad@datapipe.com) Received: from exchfe01.datapipe-corp.net (exchfe01.datapipe-corp.net [64.106.130.69]) by mx1.freebsd.org (Postfix) with ESMTP id 775CA13C44C; Mon, 11 Jun 2007 22:56:21 +0000 (UTC) (envelope-from msaad@datapipe.com) Received: from oceanspray.teb.datapipe.net (192.168.81.31) by exchfe01.datapipe-corp.net (64.106.130.71) with Microsoft SMTP Server (TLS) id 8.0.700.0; Mon, 11 Jun 2007 18:56:21 -0400 Message-ID: <466DD2FE.5040809@datapipe.com> Date: Mon, 11 Jun 2007 18:55:58 -0400 From: Mark Saad User-Agent: Thunderbird 2.0.0.0 (X11/20070521) MIME-Version: 1.0 To: Wilko Bulte References: <20070611151747.W51099@ns1.feral.com> <20070611151903.P51099@ns1.feral.com> <466DCE30.5020009@datapipe.com> <20070611224841.GA2484@freebie.xs4all.nl> In-Reply-To: <20070611224841.GA2484@freebie.xs4all.nl> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.ORG, Joao Barros , mjacob@FreeBSD.ORG Subject: Re: HP SmartArray ( CISS ) and CAMCONTROL X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: msaad@datapipe.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2007 22:56:21 -0000 Wilko Thats great to hear hpacucli and hpasm would rock. Wilko Bulte wrote: > On Mon, Jun 11, 2007 at 06:35:28PM -0400, Mark Saad wrote.. >> Matt >> What will raidutill offer ? Also does anyone know if HP provides >> hpacucli for FreeBSD ,but only to Japanese customers ? > > Well.. we just landed ourselves a new committer from HP India who > is sponsored by HP ISS in Houston to provide (binary only) Proliant > mgmt / monitoring tools for FreeBSD. > > In due time you will see his work I imagine. I hope this will > be the start of a fruitful vendor support. > -- Mark Saad Managed UNIX Support DataPipe Managed Global IT Services msaad@datapipe.com 1.201.792.4847 (international) 1.888.749.5821 (toll free) From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 11 23:00:03 2007 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.ORG Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D496B16A46E; Mon, 11 Jun 2007 23:00:03 +0000 (UTC) (envelope-from wb@freebie.xs4all.nl) Received: from smtp-vbr11.xs4all.nl (smtp-vbr11.xs4all.nl [194.109.24.31]) by mx1.freebsd.org (Postfix) with ESMTP id 6160D13C447; Mon, 11 Jun 2007 23:00:03 +0000 (UTC) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (obsolete.xs4all.nl [82.95.250.254]) by smtp-vbr11.xs4all.nl (8.13.8/8.13.8) with ESMTP id l5BMmgOw049394; Tue, 12 Jun 2007 00:48:43 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.13.8/8.13.3) with ESMTP id l5BMmgfi002518; Tue, 12 Jun 2007 00:48:42 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: (from wb@localhost) by freebie.xs4all.nl (8.13.8/8.13.6/Submit) id l5BMmgt7002513; Tue, 12 Jun 2007 00:48:42 +0200 (CEST) (envelope-from wb) Date: Tue, 12 Jun 2007 00:48:41 +0200 From: Wilko Bulte To: Mark Saad Message-ID: <20070611224841.GA2484@freebie.xs4all.nl> References: <20070611151747.W51099@ns1.feral.com> <20070611151903.P51099@ns1.feral.com> <466DCE30.5020009@datapipe.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <466DCE30.5020009@datapipe.com> User-Agent: Mutt/1.5.11 X-Virus-Scanned: by XS4ALL Virus Scanner Cc: freebsd-hackers@FreeBSD.ORG, Joao Barros , mjacob@FreeBSD.ORG Subject: Re: HP SmartArray ( CISS ) and CAMCONTROL X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2007 23:00:03 -0000 On Mon, Jun 11, 2007 at 06:35:28PM -0400, Mark Saad wrote.. > Matt > What will raidutill offer ? Also does anyone know if HP provides > hpacucli for FreeBSD ,but only to Japanese customers ? Well.. we just landed ourselves a new committer from HP India who is sponsored by HP ISS in Houston to provide (binary only) Proliant mgmt / monitoring tools for FreeBSD. In due time you will see his work I imagine. I hope this will be the start of a fruitful vendor support. -- Wilko Bulte wilko@FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 12 09:10:47 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 17B7716A41F for ; Tue, 12 Jun 2007 09:10:47 +0000 (UTC) (envelope-from vladimir.terziev@gbservices.biz) Received: from cat-btc.gbservices.biz (cat-btc.gbservices.biz [83.228.119.50]) by mx1.freebsd.org (Postfix) with ESMTP id C22EA13C4B0 for ; Tue, 12 Jun 2007 09:10:46 +0000 (UTC) (envelope-from vladimir.terziev@gbservices.biz) Received: from cat-btc.gbservices.biz (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id DC7E51FA068; Tue, 12 Jun 2007 11:10:45 +0200 (CEST) Received: from fs.gbs.gbdom.com (fs.gbs.gbdom.com [192.168.2.244]) by cat.gbs.gbdom.com (Postfix) with ESMTP id C18501FA067; Tue, 12 Jun 2007 11:10:45 +0200 (CEST) Received: from localhost (localhost.gbs.gbdom.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 68CBA28574; Tue, 12 Jun 2007 11:10:45 +0200 (CEST) Received: from daemon.gbs.gbdom.com (daemon.gbs.gbdom.com [192.168.2.104]) by fs.gbs.gbdom.com (Postfix) with SMTP id 0202828534; Tue, 12 Jun 2007 11:10:44 +0200 (CEST) Date: Tue, 12 Jun 2007 12:10:44 +0300 From: Vladimir Terziev To: freebsd-hackers@freebsd.org Message-Id: <20070612121044.65c445ff.vlady@gbservices.biz> Organization: GB Services Ltd. X-Mailer: Sylpheed 2.4.1 (GTK+ 2.6.4; i386-unknown-freebsd5.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV GBS-F X-Virus-Scanned: ClamAV GBS-C Cc: freebsd-hardware@freebsd.org Subject: SATA RAID problems X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2007 09:10:47 -0000 Hi hackers, i have an Intel Core 2 server with on-board pseudo hardware SATA RAID -- Intel MatrixRAID. The RAID itself is configured in RAID1. The server is running FreeBSD 6.2-Release/AMD64. Since several days i have being found the follwoing messages in the system log: DOH! ata_alloc_request failed! FAILURE - out of memory in ata_raid_init_request g_vfs_done():ar0s1a[WRITE(offset=5587025920, length=16384)]error = 5 DOH! ata_alloc_composite failed! The messages appear in the system log at one and the same time -- as a result of execution of one (no idea which one exactly) of the cron-jobs in /etc/periodic/daily . The atacontrol utility reports the RAID1 itself is in good status. Is my RAID controller going away ? Thanks in advance! Vladimir P.S. I do not receive mails from freebsd-hardware@freebsd.org, so please send responses to my e-mail directly! From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 12 10:57:59 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E4A6B16A468; Tue, 12 Jun 2007 10:57:59 +0000 (UTC) (envelope-from rpaulo@fnop.net) Received: from core.fnop.net (mx.fnop.net [82.102.11.82]) by mx1.freebsd.org (Postfix) with ESMTP id 6A61A13C489; Tue, 12 Jun 2007 10:57:59 +0000 (UTC) (envelope-from rpaulo@fnop.net) Received: from core.fnop.net (mx.fnop.net [82.102.11.82]) by core.fnop.net (Postfix) with ESMTP id F0ABE690A85; Tue, 12 Jun 2007 11:55:07 +0100 (WEST) Received: by core.fnop.net (Postfix, from userid 1015) id BD626690AC5; Tue, 12 Jun 2007 11:55:07 +0100 (WEST) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on core.fnop.net X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,RCVD_IN_SORBS_DUL autolearn=no version=3.1.7 Received: from epsilon.local.fnop.net (87-196-89-95.net.novis.pt [87.196.89.95]) by core.fnop.net (Postfix) with ESMTP id 31ACE690A85; Tue, 12 Jun 2007 11:55:07 +0100 (WEST) Date: Tue, 12 Jun 2007 11:57:55 +0100 Message-ID: <86ir9txwwc.wl%rpaulo@fnop.net> From: Rui Paulo To: Chuck Swiger In-Reply-To: References: <4AB3C4C0-0DA1-482F-A4CD-375A53332F29@mac.com> <4D7CDA24-48FE-4319-A320-C8D7165E9EBC@mac.com> <200706092128.l59LSjRs027671@apollo.backplane.com> <57F8CCC1-1841-41AE-9F82-0C87FE53BE99@mac.com> <200706101752.l5AHqdE0035954@apollo.backplane.com> <8B01C1EC-D61A-484F-B308-6D6C8EB00EE6@mac.com> <861wgjwnrw.wl%rpaulo@fnop.net> <200706102143.l5ALhQut038340@apollo.backplane.com> <86zm37v4ns.wl%rpaulo@fnop.net> <86lkeqxo89.wl%rpaulo@fnop.net> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/21.3 Mule/5.0 (SAKAKI) X-cite-me: rpaulo MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: ClamAV using ClamSMTP X-Mailman-Approved-At: Tue, 12 Jun 2007 11:26:48 +0000 Cc: freebsd-hackers@freebsd.org, Marcel Moolenaar , freebsd-current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: GPT - (last) call for action X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2007 10:58:00 -0000 At Mon, 11 Jun 2007 13:12:04 -0700, Chuck Swiger wrote: > > If you ever use it, fdisk /dev/rdisk0 will show things differently. > > The first partition with id 0xEE will should start at LBA 40 and end > > at LBA 409640. > > OK: although that surprises me a bit, perhaps trying to get Windows > XP (which may not understand the ~32 sector GPT header+table) means > that claiming the first partition in the MBR starts at 40 works > better...? Well, yes. I think it's like a safe keeping issue so that the user doesn't overwrite the GPT info. > > >> The first, small partition is almost certainly a "boothfs" boot > >> partition, as described in the man page for Apple's version of > >> fdisk: > > > > I don't think so. > > The boothfs partition doesn't seem to be used on Intel Macs no > > longer. The EFI boot loader that comes with Intel Macs can read HFS+ > > without any help (actually it's an EFI module), so bootufs/boothfs > > partitions are no longer required. > > It looks like you're right-- the OS-X formatting utilities still > reserve space for the boot partition, but they just scribble enough > to this space to indicate that the partition isn't actually bootable: > > # dd if=/dev/disk0s1 bs=512 count=409600 | hexdump -C Yes, this partition is just FAT32 without anything in it. -- Rui Paulo From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 12 11:30:12 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4114B16A468 for ; Tue, 12 Jun 2007 11:30:12 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id E3A6413C468 for ; Tue, 12 Jun 2007 11:30:11 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1Hy4ZW-0005hF-2o for freebsd-hackers@freebsd.org; Tue, 12 Jun 2007 13:30:02 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 12 Jun 2007 13:30:02 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 12 Jun 2007 13:30:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Date: Tue, 12 Jun 2007 13:20:32 +0200 Lines: 49 Message-ID: <466E8180.6090600@fer.hr> References: <4AB3C4C0-0DA1-482F-A4CD-375A53332F29@mac.com> <4D7CDA24-48FE-4319-A320-C8D7165E9EBC@mac.com> <200706092128.l59LSjRs027671@apollo.backplane.com> <57F8CCC1-1841-41AE-9F82-0C87FE53BE99@mac.com> <200706101752.l5AHqdE0035954@apollo.backplane.com> <8B01C1EC-D61A-484F-B308-6D6C8EB00EE6@mac.com> <861wgjwnrw.wl%rpaulo@fnop.net> <200706102143.l5ALhQut038340@apollo.backplane.com> <86zm37v4ns.wl%rpaulo@fnop.net> <86lkeqxo89.wl%rpaulo@fnop.net> <200706112033.l5BKXgNf052683@apollo.backplane.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig289831A78775945CD87CD84A" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 1.5.0.12 (X11/20060911) In-Reply-To: <200706112033.l5BKXgNf052683@apollo.backplane.com> X-Enigmail-Version: 0.94.2.0 Sender: news Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: GPT - (last) call for action X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2007 11:30:12 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig289831A78775945CD87CD84A Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Matthew Dillon wrote: > It really sounds like they are making an accomodation for BIOS > booting or older Windows booting... or *something* of that sort. T= he > fact that the bootability bit is not set in the MBR (I'm not sure a= bout > that, is it set or not?)... that seems to imply a compatibility iss= ue The spec forbids bootable flag in the "protective MBR" > with other OS's like Windows in a multi-boot environment. >=20 > They are just doing it all with a single slice instead of having > two slices. This is "more" conformant to the spec, which says the protective MBR=20 should have only one partition which covers the whole disk. I think that we can get away with > 1 fdisk slices which mirror the=20 first four GPT partitions on non-EFI machines. This would probably mean modifying the gpt utility and module to mirror=20 the EFI partitions in the PMBR, controlled by a flag so that real EFI=20 machines don't get choked. --------------enig289831A78775945CD87CD84A 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.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGboGKldnAQVacBcgRAlVrAJ0bZTsfRe+3Ydmbi4dsJMt4man6twCeP6OD wC1nzizf5G95YgR8pkwj7wY= =9nnm -----END PGP SIGNATURE----- --------------enig289831A78775945CD87CD84A-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 12 12:43:43 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 12B5416A400; Tue, 12 Jun 2007 12:43:43 +0000 (UTC) (envelope-from rpaulo@fnop.net) Received: from core.fnop.net (mx.fnop.net [82.102.11.82]) by mx1.freebsd.org (Postfix) with ESMTP id 8DF9F13C483; Tue, 12 Jun 2007 12:43:42 +0000 (UTC) (envelope-from rpaulo@fnop.net) Received: from core.fnop.net (mx.fnop.net [82.102.11.82]) by core.fnop.net (Postfix) with ESMTP id 7182B690A85; Tue, 12 Jun 2007 13:40:51 +0100 (WEST) Received: by core.fnop.net (Postfix, from userid 1015) id 26084690AE0; Tue, 12 Jun 2007 13:40:51 +0100 (WEST) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on core.fnop.net X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,RCVD_IN_SORBS_DUL autolearn=no version=3.1.7 Received: from epsilon.local.fnop.net (87-196-89-95.net.novis.pt [87.196.89.95]) by core.fnop.net (Postfix) with ESMTP id 2388A690A85; Tue, 12 Jun 2007 13:40:50 +0100 (WEST) Date: Tue, 12 Jun 2007 13:43:37 +0100 Message-ID: <86ejkhcphi.wl%rpaulo@fnop.net> From: Rui Paulo To: Matthew Dillon In-Reply-To: <200706112033.l5BKXgNf052683@apollo.backplane.com> References: <4AB3C4C0-0DA1-482F-A4CD-375A53332F29@mac.com> <4D7CDA24-48FE-4319-A320-C8D7165E9EBC@mac.com> <200706092128.l59LSjRs027671@apollo.backplane.com> <57F8CCC1-1841-41AE-9F82-0C87FE53BE99@mac.com> <200706101752.l5AHqdE0035954@apollo.backplane.com> <8B01C1EC-D61A-484F-B308-6D6C8EB00EE6@mac.com> <861wgjwnrw.wl%rpaulo@fnop.net> <200706102143.l5ALhQut038340@apollo.backplane.com> <86zm37v4ns.wl%rpaulo@fnop.net> <86lkeqxo89.wl%rpaulo@fnop.net> <200706112033.l5BKXgNf052683@apollo.backplane.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/21.3 Mule/5.0 (SAKAKI) X-cite-me: rpaulo MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: ClamAV using ClamSMTP X-Mailman-Approved-At: Tue, 12 Jun 2007 12:50:44 +0000 Cc: freebsd-geom@freebsd.org, freebsd-hackers@freebsd.org, Chuck Swiger , Marcel Moolenaar , freebsd-current@freebsd.org Subject: Re: GPT - (last) call for action X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2007 12:43:43 -0000 At Mon, 11 Jun 2007 13:33:42 -0700 (PDT), Matthew Dillon wrote: > > > :>> # gpt -r show /dev/rdisk0 > :>> start size index contents > :>> 0 1 PMBR > :>> 1 1 Pri GPT header > :>> 2 32 Pri GPT table > :>> 34 6 > :>> 40 409600 1 GPT part - C12A7328-F81F-11D2-BA4B- > :>> xxxxxxxxxxxx > :>> 409640 159414704 2 GPT part - 48465300-0000-11AA-AA11- > :>> xxxxxxxxxxxx > :... > :> Well, what's happening is that Boot Camp syncs the BIOS partition > :> table with the GPT table, so the first partition should start at 40, > :> just like the GPT. > :> > :> Why does it start at 40 ? Because you need room for the PMBR, the > :> Primary GPT header and the Primary GPT table. > : > :Agreed, you need about 32 sectors for the GPT header+table. > > It makes sense for them to point the first MBR slice at the first > partition in the GPT, even though the standard says something else. > > It really sounds like they are making an accomodation for BIOS > booting or older Windows booting... or *something* of that sort. The > fact that the bootability bit is not set in the MBR (I'm not sure about > that, is it set or not?)... that seems to imply a compatibility issue > with other OS's like Windows in a multi-boot environment. > > They are just doing it all with a single slice instead of having > two slices. > > I'll bet they found that the two-slice method doesn't work in some > cases and the one-slice method does. The standard document doesn't > allow either method but it does seem to be a bit less insistent on > the starting sector for slice 1 then it does on there only being > one slice in the MBR, period. I can also see some OS's / disk managers > barfing on having two slices which overlap each other. > > So it really does make sense for them to point the MBR at sector 40. > The more I think about it, the more sense it makes. And also, if they used two partitions that would mean you would only have one partition left for installing Windows. -- Rui Paulo From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 12 14:07:29 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1840716A41F for ; Tue, 12 Jun 2007 14:07:29 +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 BCD9313C46E for ; Tue, 12 Jun 2007 14:07:28 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 94FA320AB; Tue, 12 Jun 2007 16:07:24 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.0 (2007-05-01) on tim.des.no Received: from dwp.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 8806020A4; Tue, 12 Jun 2007 16:07:24 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 1001) id DDEBC592E; Tue, 12 Jun 2007 16:07:40 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Jeremy Chadwick References: <20070611151620.GA17565@eos.sc1.parodius.com> Date: Tue, 12 Jun 2007 16:07:40 +0200 In-Reply-To: <20070611151620.GA17565@eos.sc1.parodius.com> (Jeremy Chadwick's message of "Mon\, 11 Jun 2007 08\:16\:20 -0700") Message-ID: <86tztdp8pf.fsf@dwp.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: ASCII menu in loader/frames.4th X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2007 14:07:29 -0000 Jeremy Chadwick writes: > One could enable use of this with some loader.conf variable like > loader_frames=3D"ascii" or (default) loader_frames=3D"cp437", possibly > even a "vt100" type (using VT100 line-drawing characters). It should probably be the default. > I'm not familiar with forth, otherwise I'd come up with a patch. Maybe > I'll try learning it (argh, another language to learn...), or hack > around a bit. The box-drawing code is in frames.4th and should be fairly easy to understand and modify even if you don't know 4th. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 12 19:00:44 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A9E0E16A41F for ; Tue, 12 Jun 2007 19:00:44 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 9B95613C447 for ; Tue, 12 Jun 2007 19:00:44 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 52FC71CC044; Tue, 12 Jun 2007 12:00:44 -0700 (PDT) Date: Tue, 12 Jun 2007 12:00:44 -0700 From: Jeremy Chadwick To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= Message-ID: <20070612190044.GA83848@eos.sc1.parodius.com> References: <20070611151620.GA17565@eos.sc1.parodius.com> <86tztdp8pf.fsf@dwp.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <86tztdp8pf.fsf@dwp.des.no> User-Agent: Mutt/1.5.15 (2007-04-06) Cc: freebsd-hackers@freebsd.org Subject: Re: ASCII menu in loader/frames.4th X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2007 19:00:44 -0000 On Tue, Jun 12, 2007 at 04:07:40PM +0200, Dag-Erling Smørgrav wrote: > Jeremy Chadwick writes: > > One could enable use of this with some loader.conf variable like > > loader_frames="ascii" or (default) loader_frames="cp437", possibly > > even a "vt100" type (using VT100 line-drawing characters). > > It should probably be the default. Which should be the default? > > I'm not familiar with forth, otherwise I'd come up with a patch. Maybe > > I'll try learning it (argh, another language to learn...), or hack > > around a bit. > > The box-drawing code is in frames.4th and should be fairly easy to > understand and modify even if you don't know 4th. I'll spend some time this week hacking at it and do my best to provide patches once I manage to figure it out. Thanks for the encouragement, and the information. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 12 19:11:29 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1606F16A46B; Tue, 12 Jun 2007 19:11:29 +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 CABB313C465; Tue, 12 Jun 2007 19:11:28 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 07B7D20AF; Tue, 12 Jun 2007 21:11:25 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.0 (2007-05-01) on tim.des.no Received: from dwp.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id EFE8E20AB; Tue, 12 Jun 2007 21:11:24 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 1001) id 9F4605942; Tue, 12 Jun 2007 21:11:41 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Jeremy Chadwick References: <20070611151620.GA17565@eos.sc1.parodius.com> <86tztdp8pf.fsf@dwp.des.no> <20070612190044.GA83848@eos.sc1.parodius.com> Date: Tue, 12 Jun 2007 21:11:41 +0200 In-Reply-To: <20070612190044.GA83848@eos.sc1.parodius.com> (Jeremy Chadwick's message of "Tue\, 12 Jun 2007 12\:00\:44 -0700") Message-ID: <864pld2djm.fsf@dwp.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: ASCII menu in loader/frames.4th X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2007 19:11:29 -0000 Jeremy Chadwick writes: > On Tue, Jun 12, 2007 at 04:07:40PM +0200, Dag-Erling Sm=C3=B8rgrav wrote: > > Jeremy Chadwick writes: > > > One could enable use of this with some loader.conf variable like > > > loader_frames=3D"ascii" or (default) loader_frames=3D"cp437", possibly > > > even a "vt100" type (using VT100 line-drawing characters). > > It should probably be the default. > Which should be the default? The safe alternative, i.e. ASCII. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 12 20:45:25 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B318716A41F for ; Tue, 12 Jun 2007 20:45:25 +0000 (UTC) (envelope-from cole@opteqint.net) Received: from elektra.opteqint.net (elektra.opteqint.net [209.25.178.105]) by mx1.freebsd.org (Postfix) with ESMTP id 9598C13C4AD for ; Tue, 12 Jun 2007 20:45:25 +0000 (UTC) (envelope-from cole@opteqint.net) Received: from [196.209.59.252] (helo=deadmind) by elektra.opteqint.net with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.66 (FreeBSD)) (envelope-from ) id 1HyCwZ-000AQk-8M for freebsd-hackers@freebsd.org; Tue, 12 Jun 2007 13:27:07 -0700 From: "Cole" To: Date: Tue, 12 Jun 2007 22:23:51 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AcetL5aTJyjf2C9TTBKKkTv9I6JwXw== Message-Id: <20070612204525.9598C13C4AD@mx1.freebsd.org> Subject: Kqueue queries X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: cole@opteqint.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2007 20:45:25 -0000 Hi. I just have a few queries regarding kqueue. Ive read through the tutorial given on the netbsd page, as well as the pdf detailing kqueue. What I want to do is write a single threaded server for listening for connections, and then check if they are ready to be read from for each connection. Ive written the code for this already, and got it handling multiple connections, the problem comes in when the sockets close. This is my kevent call: nev = kevent(kq, events, number_events, changes, number_events, NULL); I wanted to know, what must be done when the sockets/file descriptors close. Do I need to decrease number_events and resort the events array so that all the active kevents are sequential without any closed sockets still in that array? Or, is it possible, to just keep increasing kevents and leave the closed socket/file descriptors in the events array, and just mark them as EV_DISABLED | EV_DELETE? When I detect a closed socket, I have tried the following, but to no evail: close(changes[i].ident); EV_SET(&changes[i],changes[i].ident,EVFILT_READ,EV_DISABLE | EV_DELETE ,0,0,0); kevent(kq, &changes[i], 1, NULL, 0, NULL); If I do the above, and just keep increasing number_events and just mark the kevent as EV_DISABLED or EV_DELETE then all it does is return that event as soon as I call kevent() with the following values: ident : 7, filter : -1, flags : 16384 Any suggestions/help would be appreciated, as well as pointing out if im doing something stupid here. Regards /Cole From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 12 21:15:04 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2252E16A400 for ; Tue, 12 Jun 2007 21:15:04 +0000 (UTC) (envelope-from jimmy@mammothcheese.ca) Received: from smtp103.rog.mail.re2.yahoo.com (smtp103.rog.mail.re2.yahoo.com [206.190.36.81]) by mx1.freebsd.org (Postfix) with SMTP id BA7DB13C45B for ; Tue, 12 Jun 2007 21:15:03 +0000 (UTC) (envelope-from jimmy@mammothcheese.ca) Received: (qmail 16676 invoked from network); 12 Jun 2007 21:08:23 -0000 Received: from unknown (HELO ?74.110.53.6?) (jazzturk@rogers.com@74.110.53.6 with plain) by smtp103.rog.mail.re2.yahoo.com with SMTP; 12 Jun 2007 21:08:23 -0000 X-YMail-OSG: 8qElVRYVM1kwHoBXn0EGe8llHFP7h0S8OXxP4mbaflEOCbdcvXNNDSawBe0ev.GhMg-- Message-ID: <466F0B46.5060106@mammothcheese.ca> Date: Tue, 12 Jun 2007 17:08:22 -0400 From: James Bailie User-Agent: Thunderbird 2.0.0.0 (X11/20070609) MIME-Version: 1.0 To: cole@opteqint.net References: <20070612204525.9598C13C4AD@mx1.freebsd.org> In-Reply-To: <20070612204525.9598C13C4AD@mx1.freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Kqueue queries X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2007 21:15:04 -0000 Cole wrote: > I wanted to know, what must be done when the sockets/file > descriptors close. Do I need to decrease number_events and > resort the events array so that all the active kevents are > sequential without any closed sockets still in that array? It occurs to me, you might be trying to use kqueue like select(), in that you are giving an input queue to every invocation of kevent(), in the same way that select needs descriptor map arguments for every invocation. If that's the case, you don't need to do this. You only need to set read events for a descriptor once. kevent() will keep returning read events while the descriptor is open and readable. -- James Bailie http://www.mammothcheese.ca From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 12 21:27:58 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3253716A468 for ; Tue, 12 Jun 2007 21:27:58 +0000 (UTC) (envelope-from jimmy@mammothcheese.ca) Received: from smtp100.rog.mail.re2.yahoo.com (smtp100.rog.mail.re2.yahoo.com [206.190.36.78]) by mx1.freebsd.org (Postfix) with SMTP id C4FB813C48C for ; Tue, 12 Jun 2007 21:27:57 +0000 (UTC) (envelope-from jimmy@mammothcheese.ca) Received: (qmail 15431 invoked from network); 12 Jun 2007 21:01:17 -0000 Received: from unknown (HELO ?74.110.53.6?) (jazzturk@rogers.com@74.110.53.6 with plain) by smtp100.rog.mail.re2.yahoo.com with SMTP; 12 Jun 2007 21:01:17 -0000 X-YMail-OSG: rsgrI.kVM1mEkfJ32L_cVJldNxbxbRAg4rJJ1a4FWeCPgONZUdXKuheTo_mrLPtcrQ-- Message-ID: <466F099B.5070801@mammothcheese.ca> Date: Tue, 12 Jun 2007 17:01:15 -0400 From: James Bailie User-Agent: Thunderbird 2.0.0.0 (X11/20070609) MIME-Version: 1.0 To: cole@opteqint.net, freebsd-hackers@freebsd.org References: <20070612204525.9598C13C4AD@mx1.freebsd.org> In-Reply-To: <20070612204525.9598C13C4AD@mx1.freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Kqueue queries X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2007 21:27:58 -0000 Cole wrote: > If I do the above, and just keep increasing number_events and > just mark the kevent as EV_DISABLED or EV_DELETE then all it > does is return that event as soon as I call kevent() with the > following values: ident : 7, filter : -1, flags : 16384 That flags value is EV_ERROR. It indicates your attempt to register an event on a closed descriptor. You do not need to disable or delete events manually if the descriptor is closed, if that was the intent. Closing a descriptor causes all events registered on it to be removed automatically. You need to get those events for closed descriptors out of your input queue. -- James Bailie http://www.mammothcheese.ca From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 13 05:25:37 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3070A16A46D for ; Wed, 13 Jun 2007 05:25:37 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout7.cac.washington.edu (mxout7.cac.washington.edu [140.142.32.178]) by mx1.freebsd.org (Postfix) with ESMTP id 13F5F13C447 for ; Wed, 13 Jun 2007 05:25:37 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.7] (may be forged)) by mxout7.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.05) with ESMTP id l5D5Pafe012808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 12 Jun 2007 22:25:36 -0700 X-Auth-Received: from [192.168.10.45] (c-24-10-12-194.hsd1.ca.comcast.net [24.10.12.194]) (authenticated authid=youshi10) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l5D5PZWG024028 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 12 Jun 2007 22:25:36 -0700 Message-ID: <466F7FD1.2020303@u.washington.edu> Date: Tue, 12 Jun 2007 22:25:37 -0700 From: Garrett Cooper User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.3.1.294258, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.6.12.220855 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' Subject: Reason for doing malloc / bzero over calloc? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2007 05:25:37 -0000 Title says it all -- is there a particular reason why malloc/bzero should be used instead of calloc? -Garrett From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 13 05:55:18 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C5D6716A400 for ; Wed, 13 Jun 2007 05:55:18 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by mx1.freebsd.org (Postfix) with ESMTP id A3FA513C45A for ; Wed, 13 Jun 2007 05:55:18 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.141] (may be forged)) by mxout1.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.05) with ESMTP id l5D5tI0b001852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 12 Jun 2007 22:55:18 -0700 X-Auth-Received: from [192.168.10.45] (c-24-10-12-194.hsd1.ca.comcast.net [24.10.12.194]) (authenticated authid=youshi10) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l5D5tHFT021388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 12 Jun 2007 22:55:17 -0700 Message-ID: <466F86C6.7010006@u.washington.edu> Date: Tue, 12 Jun 2007 22:55:18 -0700 From: Garrett Cooper User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.3.1.294258, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.6.12.223334 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' Cc: Subject: Using shell commands versus C equivalents X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2007 05:55:19 -0000 Another simple question (I hope): Is there any reason why shell commands should be used in place of a C command (in this case chmod via vsystem instead of the chmod(2) function)? It seems like the fork / exec would be more expensive with the shell command, but any area where code could be optimized is more than welcome I would think. Thanks, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 13 06:35:13 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 878D016A46C for ; Wed, 13 Jun 2007 06:35:13 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by mx1.freebsd.org (Postfix) with ESMTP id 6481113C469 for ; Wed, 13 Jun 2007 06:35:13 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.7] (may be forged)) by mxout3.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.05) with ESMTP id l5D6ZCs0026401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 12 Jun 2007 23:35:12 -0700 X-Auth-Received: from [192.168.10.45] (c-24-10-12-194.hsd1.ca.comcast.net [24.10.12.194]) (authenticated authid=youshi10) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l5D6ZBvt027132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 12 Jun 2007 23:35:12 -0700 Message-ID: <466F9020.9050306@u.washington.edu> Date: Tue, 12 Jun 2007 23:35:12 -0700 From: Garrett Cooper User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Alexander Leidinger References: <466F86C6.7010006@u.washington.edu> <20070613083046.atl5dyq3s488s0o8@webmail.leidinger.net> In-Reply-To: <20070613083046.atl5dyq3s488s0o8@webmail.leidinger.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.3.1.294258, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.6.12.231945 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' Cc: hackers@freebsd.org Subject: Re: Using shell commands versus C equivalents X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2007 06:35:13 -0000 Alexander Leidinger wrote: > Quoting Garrett Cooper (from Tue, 12 Jun > 2007 22:55:18 -0700): > >> Another simple question (I hope): >> Is there any reason why shell commands should be used in place of a >> C command (in this case chmod via vsystem instead of the chmod(2) >> function)? It seems like the fork / exec would be more expensive with >> the shell command, but any area where code could be optimized is more >> than welcome I would think. > > If it is just one file, I don't see the reason to use the shell > command, but if you need to reinvent "chmod -R", I don't see a reason > to forbid the use of the shell command (pragmatic programming). > > Bye, > Alexander. > Exactly my thinking (ch{own,mod} for one file, not reinventing the -R 'wheel'). After looking over style(7) I don't see anything about not doing that. Thanks for the reply :). -Garrett From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 13 06:37:31 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 25F7816A468 for ; Wed, 13 Jun 2007 06:37:31 +0000 (UTC) (envelope-from SRS0=L4wNFO=LN=vvelox.net=v.velox@yourhostingaccount.com) Received: from mailout20.yourhostingaccount.com (mailout20.yourhostingaccount.com [65.254.253.162]) by mx1.freebsd.org (Postfix) with ESMTP id EE0B713C46C for ; Wed, 13 Jun 2007 06:37:30 +0000 (UTC) (envelope-from SRS0=L4wNFO=LN=vvelox.net=v.velox@yourhostingaccount.com) Received: from mailscan19.yourhostingaccount.com ([10.1.15.19] helo=mailscan19.yourhostingaccount.com) by mailout20.yourhostingaccount.com with esmtp (Exim) id 1HyLzO-00067z-TK for freebsd-hackers@freebsd.org; Wed, 13 Jun 2007 02:05:55 -0400 Received: from authsmtp10.yourhostingaccount.com ([10.1.18.10] ident=exim) by mailscan19.yourhostingaccount.com with spamscanlookuphost (Exim) id 1HyLzO-00067y-Nx for freebsd-hackers@freebsd.org; Wed, 13 Jun 2007 02:05:54 -0400 Received: from authsmtp10.yourhostingaccount.com ([10.1.18.10] helo=authsmtp10.yourhostingaccount.com) by mailscan19.yourhostingaccount.com with esmtp (Exim) id 1HyLzO-00067v-9u for freebsd-hackers@freebsd.org; Wed, 13 Jun 2007 02:05:54 -0400 Received: from cpe-24-93-100-44.columbus.res.rr.com ([24.93.100.44] helo=vixen42) by authsmtp10.yourhostingaccount.com with esmtpa (Exim) id 1HyLzL-00088n-WA for freebsd-hackers@freebsd.org; Wed, 13 Jun 2007 02:05:52 -0400 Date: Wed, 13 Jun 2007 02:06:42 -0400 From: "Z.C.B." To: freebsd-hackers@freebsd.org Message-ID: <20070613020642.463afff4@vixen42> X-Mailer: Claws Mail 2.9.2 (GTK+ 2.10.12; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-EN-UserInfo: 0d1ca1697cdb7a831d4877828571b7ab:1570f0de6936c69fef9e164fffc541bc X-EN-AuthUser: vvelox2 Sender: "Z.C.B." X-EN-OrigIP: 24.93.100.44 X-EN-OrigHost: cpe-24-93-100-44.columbus.res.rr.com Subject: building images for running from flash X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2007 06:37:31 -0000 Just been looking at rebuilding my router. I understand building the image and etc, but the issue I am running into is what to do about ports. To solve this, I am looking at building the image and using mdconfig, unionfs, and jail to solve building ports. Also looking at the possibility of qemu. Any thoughts or suggestions? Another annoying issue is the muckery involved with /etc/make.conf... The issue I am running into that is the CPUTYPE? option is different for the build machine and router that the flash will be used on. Any nice way to deal with this? From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 13 07:38:38 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D99F216A479 for ; Wed, 13 Jun 2007 07:38:38 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by mx1.freebsd.org (Postfix) with ESMTP id AB3D013C4BD for ; Wed, 13 Jun 2007 07:38:38 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.141] (may be forged)) by mxout5.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.05) with ESMTP id l5D7ccM5029290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 13 Jun 2007 00:38:38 -0700 X-Auth-Received: from [192.168.10.45] (c-24-10-12-194.hsd1.ca.comcast.net [24.10.12.194]) (authenticated authid=youshi10) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l5D7cbLl025929 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 13 Jun 2007 00:38:38 -0700 Message-ID: <466F9EFE.9020402@u.washington.edu> Date: Wed, 13 Jun 2007 00:38:38 -0700 From: Garrett Cooper User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <466F7FD1.2020303@u.washington.edu> In-Reply-To: <466F7FD1.2020303@u.washington.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.3.1.294258, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.6.13.2438 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' Subject: Re: Reason for doing malloc / bzero over calloc (performance)? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2007 07:38:39 -0000 Garrett Cooper wrote: > Title says it all -- is there a particular reason why malloc/bzero > should be used instead of calloc? > -Garrett As someone just brought to my attention, I should do some Googling. Initial results brought up this: . I would like to provide results for CURRENT, but I don't know offhand what C interface right supports nanoseconds or microseconds precision timing in FreeBSD (apart from just doing nanosleeps, which isn't such a great idea and can drift I would think due to clock skew). The original author's solution is for Mac OSX only :(.. I think it's decided though -- calloc for now wins over malloc / bzero, so I'm going to change that alloc/bzero to reflect the change. -Garrett From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 13 08:03:36 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 29EE316A46B for ; Wed, 13 Jun 2007 08:03:36 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [83.98.131.211]) by mx1.freebsd.org (Postfix) with ESMTP id DCA8413C4AE for ; Wed, 13 Jun 2007 08:03:35 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 23E861CC2E; Wed, 13 Jun 2007 10:03:34 +0200 (CEST) Date: Wed, 13 Jun 2007 10:03:34 +0200 From: Ed Schouten To: Garrett Cooper Message-ID: <20070613080334.GR89502@hoeg.nl> References: <466F7FD1.2020303@u.washington.edu> <466F9EFE.9020402@u.washington.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="brdEIFGMNIjz5YJG" Content-Disposition: inline In-Reply-To: <466F9EFE.9020402@u.washington.edu> User-Agent: Mutt/1.5.15 (2007-04-06) Cc: FreeBSD Hackers Subject: Re: Reason for doing malloc / bzero over calloc (performance)? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2007 08:03:36 -0000 --brdEIFGMNIjz5YJG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Garrett Cooper wrote: > Garrett Cooper wrote: > > Title says it all -- is there a particular reason why malloc/bzero= =20 > > should be used instead of calloc? > > -Garrett > As someone just brought to my attention, I should do some Googling. >=20 > Initial results brought up this:=20 > . To be more precise; I took a look at the source code of calloc on my FreeBSD 6 box: | void * | calloc(num, size) | size_t num; | size_t size; | { | void *p; |=20 | if (size !=3D 0 && SIZE_T_MAX / size < num) { | errno =3D ENOMEM; | return (NULL); | } |=20 | size *=3D num; | if ( (p =3D malloc(size)) ) | bzero(p, size); | return(p); | } This means that the results on that website would be quite different than the the ones that the FreeBSD 6 malloc/calloc should give. There is even a difference between calloc'ing 10 block of 10 MB and 1 block of 100 MB, which shouldn't make a difference here. calloc doesn't have any performance-advantage here, because it just calls malloc/bzero. When looking at FreeBSD -CURRENT's calloc (won't paste it; too long), it just does a arena_malloc/memset (which is malloc/bzero) for small allocations but a huge_malloc for big allocations (say, multiple pages big). The latter one already returns pages that are zero'd by the kernel, so I suspect the calloc performance for big allocations on -CURRENT is a lot better than on FreeBSD 6. As with FreeBSD 6, it wouldn't matter if you calloc 10 pieces of 10 MB or one piece of 100 MB. Yours, --=20 Ed Schouten WWW: http://g-rave.nl/ --brdEIFGMNIjz5YJG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGb6TW52SDGA2eCwURAifxAJ4nfTZQ+i6ndb2Ngynv71kzMpNa8gCeO8mI sIHQmSo/zwL2OLtLMmXm2o8= =7pA7 -----END PGP SIGNATURE----- --brdEIFGMNIjz5YJG-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 13 06:58:34 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4E44016A400 for ; Wed, 13 Jun 2007 06:58:34 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id 064DE13C468 for ; Wed, 13 Jun 2007 06:58:33 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A5FA25.dip.t-dialin.net [84.165.250.37]) by redbull.bpaserver.net (Postfix) with ESMTP id 566642E169; Wed, 13 Jun 2007 08:31:04 +0200 (CEST) Received: from webmail.leidinger.net (webmail.Leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 8E8DB5B490D; Wed, 13 Jun 2007 08:30:46 +0200 (CEST) Received: (from www@localhost) by webmail.leidinger.net (8.13.8/8.13.8/Submit) id l5D6UkaI085687; Wed, 13 Jun 2007 08:30:46 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Wed, 13 Jun 2007 08:30:46 +0200 Message-ID: <20070613083046.atl5dyq3s488s0o8@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Wed, 13 Jun 2007 08:30:46 +0200 From: Alexander Leidinger To: Garrett Cooper References: <466F86C6.7010006@u.washington.edu> In-Reply-To: <466F86C6.7010006@u.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.1.4) / FreeBSD-7.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=2.601, required 8, BAYES_50 2.50, DKIM_POLICY_SIGNSOME 0.00, RDNS_DYNAMIC 0.10) X-BPAnet-MailScanner-SpamScore: ss X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No X-Mailman-Approved-At: Wed, 13 Jun 2007 11:42:53 +0000 Cc: hackers@freebsd.org Subject: Re: Using shell commands versus C equivalents X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2007 06:58:34 -0000 Quoting Garrett Cooper (from Tue, 12 Jun 2007 22:55:18 -0700): > Another simple question (I hope): > Is there any reason why shell commands should be used in place of a > C command (in this case chmod via vsystem instead of the chmod(2) > function)? It seems like the fork / exec would be more expensive with > the shell command, but any area where code could be optimized is more > than welcome I would think. If it is just one file, I don't see the reason to use the shell command, but if you need to reinvent "chmod -R", I don't see a reason to forbid the use of the shell command (pragmatic programming). Bye, Alexander. -- Revenge is a form of nostalgia. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 13 07:40:14 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0F5C416A400 for ; Wed, 13 Jun 2007 07:40:14 +0000 (UTC) (envelope-from eugen@www.svzserv.kemerovo.su) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.freebsd.org (Postfix) with ESMTP id 040CD13C4AE for ; Wed, 13 Jun 2007 07:40:12 +0000 (UTC) (envelope-from eugen@www.svzserv.kemerovo.su) Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id l5D7BGbw092139; Wed, 13 Jun 2007 15:11:16 +0800 (KRAST) (envelope-from eugen@www.svzserv.kemerovo.su) Received: (from eugen@localhost) by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id l5D7BFw4092138; Wed, 13 Jun 2007 15:11:16 +0800 (KRAST) (envelope-from eugen) Date: Wed, 13 Jun 2007 15:11:15 +0800 From: Eugene Grosbein To: "Z.C.B." Message-ID: <20070613071115.GA92114@svzserv.kemerovo.su> References: <20070613020642.463afff4@vixen42> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070613020642.463afff4@vixen42> User-Agent: Mutt/1.4.2.1i X-Mailman-Approved-At: Wed, 13 Jun 2007 11:42:53 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: building images for running from flash X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2007 07:40:14 -0000 On Wed, Jun 13, 2007 at 02:06:42AM -0400, Z.C.B. wrote: > Just been looking at rebuilding my router. I understand building the > image and etc, but the issue I am running into is what to do about > ports. To solve this, I am looking at building the image and using > mdconfig, unionfs, and jail to solve building ports. Also looking > at the possibility of qemu. Any thoughts or suggestions? > > Another annoying issue is the muckery involved with /etc/make.conf... > The issue I am running into that is the CPUTYPE? option is different > for the build machine and router that the flash will be used on. Any > nice way to deal with this? nanobsd(8) Eugene Grosbein From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 13 12:46:44 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DF9D916A468 for ; Wed, 13 Jun 2007 12:46:44 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.freebsd.org (Postfix) with ESMTP id 6D4D513C487 for ; Wed, 13 Jun 2007 12:46:44 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (localhost [127.0.0.1]) by bunrab.catwhisker.org (8.13.3/8.13.3) with ESMTP id l5DCWEC0002703; Wed, 13 Jun 2007 05:32:14 -0700 (PDT) (envelope-from david@bunrab.catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.13.3/8.13.1/Submit) id l5DCWDTc002702; Wed, 13 Jun 2007 05:32:13 -0700 (PDT) (envelope-from david) Date: Wed, 13 Jun 2007 05:32:13 -0700 From: David Wolfskill To: Garrett Cooper Message-ID: <20070613123213.GE98927@bunrab.catwhisker.org> References: <466F86C6.7010006@u.washington.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Rgf3q3z9SdmXC6oT" Content-Disposition: inline In-Reply-To: <466F86C6.7010006@u.washington.edu> User-Agent: Mutt/1.4.2.1i Cc: hackers@freebsd.org Subject: Re: Using shell commands versus C equivalents X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2007 12:46:45 -0000 --Rgf3q3z9SdmXC6oT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 12, 2007 at 10:55:18PM -0700, Garrett Cooper wrote: > Another simple question (I hope): > Is there any reason why shell commands should be used in place of a=20 > C command (in this case chmod via vsystem instead of the chmod(2)=20 > function)? It seems like the fork / exec would be more expensive with=20 > the shell command, but any area where code could be optimized is more=20 > than welcome I would think. There often are reasons to prefer using shell commands to C. There typically exist many tradeoffs involved in evaluating one over the other, and "machine efficiency" is not always the highest goal. (For example, it may be better to reduce complexity in favor of having a simpler structure that is easier for people to understand and maintain with confidence that the changes they make have the desired results. This is, of course, not to try to claim that shell scripts are inherently easier to understand than C code; that would be a silly stance to take.) I commend to your attention Geoff Collyer and Henry Spencer's "C News" (a successor to Rick Adams' "B News") implementation, a great deal of which was written as shell scripts (ca. 1988 or so). (Yes, I realize that that was almost 20 years ago, and that it didn't involve FreeBSD per se. Ignoring the lessons of history is rather short-sighted and foolish: despite using shell scripts for so much of the "code," the machine I was then running went from being extremely busy all the time to having a couple of bursts of activity per day for about an hour each time -- with more news flowing with C News vs. B News.) Peace, david --=20 David H. Wolfskill david@catwhisker.org Anything and everything is a (potential) cat toy. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --Rgf3q3z9SdmXC6oT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iEYEARECAAYFAkZv48wACgkQmprOCmdXAD2WDQCfUvmm3BFmpRypqnatSeHoMl17 BjsAnRY7KXZuDJ/xAedy5Xs8LR4bSQqG =CKZ9 -----END PGP SIGNATURE----- --Rgf3q3z9SdmXC6oT-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 13 13:07:07 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E6C7016A46E for ; Wed, 13 Jun 2007 13:07:07 +0000 (UTC) (envelope-from SRS0=L4wNFO=LN=vvelox.net=v.velox@yourhostingaccount.com) Received: from mailout07.yourhostingaccount.com (mailout07.yourhostingaccount.com [65.254.253.60]) by mx1.freebsd.org (Postfix) with ESMTP id 17DE613C4B9 for ; Wed, 13 Jun 2007 13:07:06 +0000 (UTC) (envelope-from SRS0=L4wNFO=LN=vvelox.net=v.velox@yourhostingaccount.com) Received: from mailscan38.yourhostingaccount.com ([10.1.15.38] helo=mailscan38.yourhostingaccount.com) by mailout07.yourhostingaccount.com with esmtp (Exim) id 1HySYy-0006xH-DO for freebsd-hackers@freebsd.org; Wed, 13 Jun 2007 09:07:04 -0400 Received: from authsmtp11.yourhostingaccount.com ([10.1.18.11] ident=exim) by mailscan38.yourhostingaccount.com with spamscanlookuphost (Exim) id 1HySYy-0004rg-63 for freebsd-hackers@freebsd.org; Wed, 13 Jun 2007 09:07:04 -0400 Received: from authsmtp11.yourhostingaccount.com ([10.1.18.11] helo=authsmtp11.yourhostingaccount.com) by mailscan38.yourhostingaccount.com with esmtp (Exim) id 1HySYv-0004qs-JI; Wed, 13 Jun 2007 09:07:01 -0400 Received: from cpe-24-93-100-44.columbus.res.rr.com ([24.93.100.44] helo=vixen42) by authsmtp11.yourhostingaccount.com with esmtpa (Exim) id 1HySYt-0003cc-S5; Wed, 13 Jun 2007 09:07:00 -0400 Date: Wed, 13 Jun 2007 09:07:45 -0400 From: "Z.C.B." To: Eugene Grosbein Message-ID: <20070613090745.4b7a1031@vixen42> In-Reply-To: <20070613071115.GA92114@svzserv.kemerovo.su> References: <20070613020642.463afff4@vixen42> <20070613071115.GA92114@svzserv.kemerovo.su> X-Mailer: Claws Mail 2.9.2 (GTK+ 2.10.12; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-EN-UserInfo: 0d1ca1697cdb7a831d4877828571b7ab:1570f0de6936c69fef9e164fffc541bc X-EN-AuthUser: vvelox2 Sender: "Z.C.B." X-EN-OrigIP: 24.93.100.44 X-EN-OrigHost: cpe-24-93-100-44.columbus.res.rr.com Cc: freebsd-hackers@freebsd.org Subject: Re: building images for running from flash X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2007 13:07:08 -0000 On Wed, 13 Jun 2007 15:11:15 +0800 Eugene Grosbein wrote: > On Wed, Jun 13, 2007 at 02:06:42AM -0400, Z.C.B. wrote: >=20 > > Just been looking at rebuilding my router. I understand building > > the image and etc, but the issue I am running into is what to do > > about ports. To solve this, I am looking at building the image > > and using mdconfig, unionfs, and jail to solve building ports. > > Also looking at the possibility of qemu. Any thoughts or > > suggestions? > >=20 > > Another annoying issue is the muckery involved > > with /etc/make.conf... The issue I am running into that is the > > CPUTYPE? option is different for the build machine and router > > that the flash will be used on. Any nice way to deal with this? >=20 > nanobsd(8) I am aware of it, but it does not cover what I need for either questions, except for possibly the make part. =46rom the looks of it, I assume I can override what make.conf is used using __MAKE_CONF? Also any thing to be aware of when using DESTDIR with make kernel? Just tried it here and it did not work. It just installed over my current one. From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 13 13:42:20 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 249D716A468 for ; Wed, 13 Jun 2007 13:42:20 +0000 (UTC) (envelope-from eugen@www.svzserv.kemerovo.su) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.freebsd.org (Postfix) with ESMTP id 6D13C13C48A for ; Wed, 13 Jun 2007 13:42:18 +0000 (UTC) (envelope-from eugen@www.svzserv.kemerovo.su) Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id l5DDgDwl013137 for ; Wed, 13 Jun 2007 21:42:13 +0800 (KRAST) (envelope-from eugen@www.svzserv.kemerovo.su) Received: (from eugen@localhost) by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id l5DDgD7M013136 for freebsd-hackers@freebsd.org; Wed, 13 Jun 2007 21:42:13 +0800 (KRAST) (envelope-from eugen) Date: Wed, 13 Jun 2007 21:42:12 +0800 From: Eugene Grosbein To: freebsd-hackers@freebsd.org Message-ID: <20070613134212.GA12944@svzserv.kemerovo.su> References: <20070613020642.463afff4@vixen42> <20070613071115.GA92114@svzserv.kemerovo.su> <20070613090745.4b7a1031@vixen42> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070613090745.4b7a1031@vixen42> User-Agent: Mutt/1.4.2.1i Subject: Re: building images for running from flash X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2007 13:42:20 -0000 On Wed, Jun 13, 2007 at 09:07:45AM -0400, Z.C.B. wrote: > > nanobsd(8) > > I am aware of it, but it does not cover what I need for either > questions, except for possibly the make part. It does. Eugene From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 13 13:48:34 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E161516A46D for ; Wed, 13 Jun 2007 13:48:34 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.freebsd.org (Postfix) with ESMTP id 99D2713C48C for ; Wed, 13 Jun 2007 13:48:34 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1HySxb-000PIg-89; Wed, 13 Jun 2007 16:32:31 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: David Wolfskill In-reply-to: <20070613123213.GE98927@bunrab.catwhisker.org> References: <466F86C6.7010006@u.washington.edu> <20070613123213.GE98927@bunrab.catwhisker.org> Comments: In-reply-to David Wolfskill message dated "Wed, 13 Jun 2007 05:32:13 -0700." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 13 Jun 2007 16:32:31 +0300 From: Danny Braniss Message-ID: Cc: Garrett Cooper , hackers@freebsd.org Subject: Re: Using shell commands versus C equivalents X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2007 13:48:35 -0000 > > --Rgf3q3z9SdmXC6oT > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > On Tue, Jun 12, 2007 at 10:55:18PM -0700, Garrett Cooper wrote: > > Another simple question (I hope): > > Is there any reason why shell commands should be used in place of a=20 > > C command (in this case chmod via vsystem instead of the chmod(2)=20 > > function)? It seems like the fork / exec would be more expensive with=20 > > the shell command, but any area where code could be optimized is more=20 > > than welcome I would think. > > There often are reasons to prefer using shell commands to C. > > There typically exist many tradeoffs involved in evaluating one over the > other, and "machine efficiency" is not always the highest goal. (For > example, it may be better to reduce complexity in favor of having a > simpler structure that is easier for people to understand and maintain > with confidence that the changes they make have the desired results. > This is, of course, not to try to claim that shell scripts are > inherently easier to understand than C code; that would be a silly > stance to take.) > > I commend to your attention Geoff Collyer and Henry Spencer's "C News" > (a successor to Rick Adams' "B News") implementation, a great deal of > which was written as shell scripts (ca. 1988 or so). > > (Yes, I realize that that was almost 20 years ago, and that it > didn't involve FreeBSD per se. Ignoring the lessons of history is > rather short-sighted and foolish: despite using shell scripts for > so much of the "code," the machine I was then running went from > being extremely busy all the time to having a couple of bursts of > activity per day for about an hour each time -- with more news > flowing with C News vs. B News.) > read the question again, though it is not absolutely clear/correct, the question was: chmod(path, mode) vs system("chmod ...") and not wheather to write a program or a shell script. danny From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 13 13:49:31 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8CA9916A474 for ; Wed, 13 Jun 2007 13:49:31 +0000 (UTC) (envelope-from SRS0=L4wNFO=LN=vvelox.net=v.velox@yourhostingaccount.com) Received: from mailout07.yourhostingaccount.com (mailout07.yourhostingaccount.com [65.254.253.60]) by mx1.freebsd.org (Postfix) with ESMTP id 5FCA113C4B7 for ; Wed, 13 Jun 2007 13:49:31 +0000 (UTC) (envelope-from SRS0=L4wNFO=LN=vvelox.net=v.velox@yourhostingaccount.com) Received: from mailscan39.yourhostingaccount.com ([10.1.15.39] helo=mailscan39.yourhostingaccount.com) by mailout07.yourhostingaccount.com with esmtp (Exim) id 1HyTE0-0004pm-G2 for freebsd-hackers@freebsd.org; Wed, 13 Jun 2007 09:49:29 -0400 Received: from authsmtp08.yourhostingaccount.com ([10.1.18.8] ident=exim) by mailscan39.yourhostingaccount.com with spamscanlookuphost (Exim) id 1HyTE0-0006Gc-9v for freebsd-hackers@freebsd.org; Wed, 13 Jun 2007 09:49:28 -0400 Received: from authsmtp08.yourhostingaccount.com ([10.1.18.8] helo=authsmtp08.yourhostingaccount.com) by mailscan39.yourhostingaccount.com with esmtp (Exim) id 1HyTDw-0006Fu-N3; Wed, 13 Jun 2007 09:49:24 -0400 Received: from cpe-24-93-100-44.columbus.res.rr.com ([24.93.100.44] helo=vixen42) by authsmtp08.yourhostingaccount.com with esmtpa (Exim) id 1HyTDu-0007IB-Nf; Wed, 13 Jun 2007 09:49:24 -0400 Date: Wed, 13 Jun 2007 09:50:11 -0400 From: "Z.C.B." To: Eugene Grosbein Message-ID: <20070613095011.5877ecfb@vixen42> In-Reply-To: <20070613134212.GA12944@svzserv.kemerovo.su> References: <20070613020642.463afff4@vixen42> <20070613071115.GA92114@svzserv.kemerovo.su> <20070613090745.4b7a1031@vixen42> <20070613134212.GA12944@svzserv.kemerovo.su> X-Mailer: Claws Mail 2.9.2 (GTK+ 2.10.12; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-EN-UserInfo: 0d1ca1697cdb7a831d4877828571b7ab:1570f0de6936c69fef9e164fffc541bc X-EN-AuthUser: vvelox2 Sender: "Z.C.B." X-EN-OrigIP: 24.93.100.44 X-EN-OrigHost: cpe-24-93-100-44.columbus.res.rr.com Cc: freebsd-hackers@freebsd.org Subject: Re: building images for running from flash X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2007 13:49:31 -0000 On Wed, 13 Jun 2007 21:42:12 +0800 Eugene Grosbein wrote: > On Wed, Jun 13, 2007 at 09:07:45AM -0400, Z.C.B. wrote: > > > > nanobsd(8) > > > > I am aware of it, but it does not cover what I need for either > > questions, except for possibly the make part. > > It does. Hmmm.... on a interesting note, make kernel with DESTDIR does not work, but installkernel does. From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 13 13:54:18 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B66B516A46D for ; Wed, 13 Jun 2007 13:54:18 +0000 (UTC) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: from mired.org (vpn.mired.org [66.92.153.74]) by mx1.freebsd.org (Postfix) with SMTP id 5E8DE13C469 for ; Wed, 13 Jun 2007 13:54:18 +0000 (UTC) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: (qmail 13183 invoked by uid 1001); 13 Jun 2007 13:52:14 -0000 Received: by bhuda.mired.org (tmda-sendmail, from uid 1001); Wed, 13 Jun 2007 09:52:13 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18031.63117.423936.99266@bhuda.mired.org> Date: Wed, 13 Jun 2007 09:52:13 -0400 To: Garrett Cooper In-Reply-To: <466F9020.9050306@u.washington.edu> References: <466F86C6.7010006@u.washington.edu> <20070613083046.atl5dyq3s488s0o8@webmail.leidinger.net> <466F9020.9050306@u.washington.edu> X-Mailer: VM 7.19 under Emacs 21.3.1 X-Primary-Address: mwm@mired.org X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`; h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ X-Delivery-Agent: TMDA/1.1.11 (Ladyburn) From: Mike Meyer Cc: Alexander Leidinger , hackers@freebsd.org Subject: Re: Using shell commands versus C equivalents X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2007 13:54:18 -0000 In <466F9020.9050306@u.washington.edu>, Garrett Cooper typed: > Alexander Leidinger wrote: > > Quoting Garrett Cooper (from Tue, 12 Jun > > 2007 22:55:18 -0700): > > > >> Another simple question (I hope): > >> Is there any reason why shell commands should be used in place of a > >> C command (in this case chmod via vsystem instead of the chmod(2) > >> function)? It seems like the fork / exec would be more expensive with > >> the shell command, but any area where code could be optimized is more > >> than welcome I would think. > > > > If it is just one file, I don't see the reason to use the shell > > command, but if you need to reinvent "chmod -R", I don't see a reason > > to forbid the use of the shell command (pragmatic programming). > > > > Bye, > > Alexander. > > > Exactly my thinking (ch{own,mod} for one file, not reinventing the > -R 'wheel'). After looking over style(7) I don't see anything about not > doing that. While I agree in principal - if chmod already implements some hard-to-implement functionality, then using it only makes sense - I don't think -R qualifies. It's implemented via the fts library, which makes recursing through a directory tree about as difficult as scanning a directory. In fact, fts has features that dir* doesn't, so there are instances where fts is preferable to the dir* routines for scanning a directory. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 13 14:00:55 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A114C16A468 for ; Wed, 13 Jun 2007 14:00:55 +0000 (UTC) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: from mired.org (vpn.mired.org [66.92.153.74]) by mx1.freebsd.org (Postfix) with SMTP id 3019F13C4C6 for ; Wed, 13 Jun 2007 14:00:55 +0000 (UTC) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: (qmail 17788 invoked by uid 1001); 13 Jun 2007 13:58:50 -0000 Received: by bhuda.mired.org (tmda-sendmail, from uid 1001); Wed, 13 Jun 2007 09:58:50 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18031.63514.578231.63127@bhuda.mired.org> Date: Wed, 13 Jun 2007 09:58:50 -0400 To: "Z.C.B." In-Reply-To: <20070613020642.463afff4@vixen42> References: <20070613020642.463afff4@vixen42> X-Mailer: VM 7.19 under Emacs 21.3.1 X-Primary-Address: mwm@mired.org X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`; h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ X-Delivery-Agent: TMDA/1.1.11 (Ladyburn) From: Mike Meyer Cc: freebsd-hackers@freebsd.org Subject: Re: building images for running from flash X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2007 14:00:55 -0000 In <20070613020642.463afff4@vixen42>, Z.C.B. typed: > Another annoying issue is the muckery involved with /etc/make.conf... > The issue I am running into that is the CPUTYPE? option is different > for the build machine and router that the flash will be used on. Any > nice way to deal with this? If they are different implementations of the same architecture, you can set CPUTYPE to the lower of the two. For the kernel and world, you can set TARGET_ARCH= on the make line, and it will cross-compile the world for you (assuming your compiler can generate code for that architecture. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 13 15:27:13 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 94BEF16A400 for ; Wed, 13 Jun 2007 15:27:13 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by mx1.freebsd.org (Postfix) with ESMTP id 72AB213C48A for ; Wed, 13 Jun 2007 15:27:13 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.141] (may be forged)) by mxout3.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.05) with ESMTP id l5DFQc17012476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 13 Jun 2007 08:26:38 -0700 X-Auth-Received: from [192.168.10.45] (c-24-10-12-194.hsd1.ca.comcast.net [24.10.12.194]) (authenticated authid=youshi10) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l5DFQbqg016282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 13 Jun 2007 08:26:38 -0700 Message-ID: <46700CAE.6020902@u.washington.edu> Date: Wed, 13 Jun 2007 08:26:38 -0700 From: Garrett Cooper User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Danny Braniss References: <466F86C6.7010006@u.washington.edu> <20070613123213.GE98927@bunrab.catwhisker.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.3.1.294258, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.6.13.80333 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' Cc: hackers@freebsd.org, David Wolfskill Subject: Re: Using shell commands versus C equivalents X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2007 15:27:13 -0000 Danny Braniss wrote: >> --Rgf3q3z9SdmXC6oT >> Content-Type: text/plain; charset=us-ascii >> Content-Disposition: inline >> Content-Transfer-Encoding: quoted-printable >> >> On Tue, Jun 12, 2007 at 10:55:18PM -0700, Garrett Cooper wrote: >> >>> Another simple question (I hope): >>> Is there any reason why shell commands should be used in place of a=20 >>> C command (in this case chmod via vsystem instead of the chmod(2)=20 >>> function)? It seems like the fork / exec would be more expensive with=20 >>> the shell command, but any area where code could be optimized is more=20 >>> than welcome I would think. >>> >> There often are reasons to prefer using shell commands to C. >> >> There typically exist many tradeoffs involved in evaluating one over the >> other, and "machine efficiency" is not always the highest goal. (For >> example, it may be better to reduce complexity in favor of having a >> simpler structure that is easier for people to understand and maintain >> with confidence that the changes they make have the desired results. >> This is, of course, not to try to claim that shell scripts are >> inherently easier to understand than C code; that would be a silly >> stance to take.) >> >> I commend to your attention Geoff Collyer and Henry Spencer's "C News" >> (a successor to Rick Adams' "B News") implementation, a great deal of >> which was written as shell scripts (ca. 1988 or so). >> >> (Yes, I realize that that was almost 20 years ago, and that it >> didn't involve FreeBSD per se. Ignoring the lessons of history is >> rather short-sighted and foolish: despite using shell scripts for >> so much of the "code," the machine I was then running went from >> being extremely busy all the time to having a couple of bursts of >> activity per day for about an hour each time -- with more news >> flowing with C News vs. B News.) >> >> > > read the question again, though it is not absolutely clear/correct, the question > was: > chmod(path, mode) > vs > system("chmod ...") > > and not wheather to write a program or a shell script. > > danny > > > Sorry -- actually I meant that (along similar lines), there was a program with the following lines: vsystem("/bin/chmod +x %s", filename); and I replaced it with: chmod(filename, (mode_t) ( S_IXUSR | S_IXGRP | S_IXOTH )); Probably won't yield much gain overall, but every drop counts and there are quite a few iterations performed in the pkg_* programs, in particular dealing with X.org. Next step, eliminating the linked list structure in favor or red-black trees, maybe. -Garrett From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 13 15:36:30 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A021716A46B for ; Wed, 13 Jun 2007 15:36:30 +0000 (UTC) (envelope-from joerg@britannica.bec.de) Received: from www.pkgsrc-box.org (www.ostsee-abc.de [62.206.222.50]) by mx1.freebsd.org (Postfix) with ESMTP id 253B213C465 for ; Wed, 13 Jun 2007 15:36:29 +0000 (UTC) (envelope-from joerg@britannica.bec.de) Received: from britannica.bec.de (www.pkgsrc-box.org [127.0.0.1]) by www.pkgsrc-box.org (Postfix) with ESMTP id B33CDE7A3F9; Wed, 13 Jun 2007 15:36:27 +0000 (UTC) Received: by britannica.bec.de (Postfix, from userid 1000) id E160F7D3C; Wed, 13 Jun 2007 17:35:56 +0200 (CEST) Date: Wed, 13 Jun 2007 17:35:55 +0200 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org, hackers@freebsd.org Message-ID: <20070613153555.GA4439@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org, hackers@freebsd.org References: <466F86C6.7010006@u.washington.edu> <20070613123213.GE98927@bunrab.catwhisker.org> <46700CAE.6020902@u.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46700CAE.6020902@u.washington.edu> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Subject: Re: Using shell commands versus C equivalents X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2007 15:36:30 -0000 On Wed, Jun 13, 2007 at 08:26:38AM -0700, Garrett Cooper wrote: > Sorry -- actually I meant that (along similar lines), there was a > program with the following lines: > > vsystem("/bin/chmod +x %s", filename); > > and I replaced it with: > > chmod(filename, (mode_t) ( S_IXUSR | S_IXGRP | S_IXOTH )); You supposedly mean stat + chmod here, right? Trivial errors like this are easy to make. > Next step, eliminating the linked list structure in favor or red-black > trees, maybe. Due to the way pkg_install works, this most likely is just adding complexity for no gain, it might actually slow it down. Joerg From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 13 15:57:34 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2074B16A46C for ; Wed, 13 Jun 2007 15:57:34 +0000 (UTC) (envelope-from joerg@britannica.bec.de) Received: from www.pkgsrc-box.org (www.ostsee-abc.de [62.206.222.50]) by mx1.freebsd.org (Postfix) with ESMTP id C8BFC13C45E for ; Wed, 13 Jun 2007 15:57:33 +0000 (UTC) (envelope-from joerg@britannica.bec.de) Received: from britannica.bec.de (www.pkgsrc-box.org [127.0.0.1]) by www.pkgsrc-box.org (Postfix) with ESMTP id B33CDE7A3F9; Wed, 13 Jun 2007 15:36:27 +0000 (UTC) Received: by britannica.bec.de (Postfix, from userid 1000) id E160F7D3C; Wed, 13 Jun 2007 17:35:56 +0200 (CEST) Date: Wed, 13 Jun 2007 17:35:55 +0200 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org, hackers@freebsd.org Message-ID: <20070613153555.GA4439@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org, hackers@freebsd.org References: <466F86C6.7010006@u.washington.edu> <20070613123213.GE98927@bunrab.catwhisker.org> <46700CAE.6020902@u.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46700CAE.6020902@u.washington.edu> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Subject: Re: Using shell commands versus C equivalents X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2007 15:57:34 -0000 On Wed, Jun 13, 2007 at 08:26:38AM -0700, Garrett Cooper wrote: > Sorry -- actually I meant that (along similar lines), there was a > program with the following lines: > > vsystem("/bin/chmod +x %s", filename); > > and I replaced it with: > > chmod(filename, (mode_t) ( S_IXUSR | S_IXGRP | S_IXOTH )); You supposedly mean stat + chmod here, right? Trivial errors like this are easy to make. > Next step, eliminating the linked list structure in favor or red-black > trees, maybe. Due to the way pkg_install works, this most likely is just adding complexity for no gain, it might actually slow it down. Joerg From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 13 15:58:45 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5D74C16A4E6 for ; Wed, 13 Jun 2007 15:58:45 +0000 (UTC) (envelope-from gshapiro@freebsd.org) Received: from gir.gshapiro.net (gir.gshapiro.net [209.246.26.16]) by mx1.freebsd.org (Postfix) with ESMTP id 39D2A13C4B0 for ; Wed, 13 Jun 2007 15:58:45 +0000 (UTC) (envelope-from gshapiro@freebsd.org) Received: from monkeyboy.local (c-67-164-3-230.hsd1.ca.comcast.net [67.164.3.230]) (authenticated bits=128) by gir.gshapiro.net (8.14.1/8.14.1) with ESMTP id l5DFc0rI085586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Jun 2007 08:38:02 -0700 (PDT) (envelope-from gshapiro@freebsd.org) X-DKIM: Sendmail DKIM Filter v1.0.0 gir.gshapiro.net l5DFc0rI085586 X-DomainKeys: Sendmail DomainKeys Filter v0.6.0 gir.gshapiro.net l5DFc0rI085586 Date: Wed, 13 Jun 2007 08:37:46 -0700 From: Gregory Shapiro To: Garrett Cooper Message-ID: <20070613153745.GF27029@monkeyboy.local> References: <466F86C6.7010006@u.washington.edu> <20070613123213.GE98927@bunrab.catwhisker.org> <46700CAE.6020902@u.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46700CAE.6020902@u.washington.edu> User-Agent: Mutt/1.5.15 (2007-04-06) Cc: hackers@freebsd.org Subject: Re: Using shell commands versus C equivalents X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2007 15:58:45 -0000 > Sorry -- actually I meant that (along similar lines), there was a program > with the following lines: > > vsystem("/bin/chmod +x %s", filename); > > and I replaced it with: > > chmod(filename, (mode_t) ( S_IXUSR | S_IXGRP | S_IXOTH )); Those two lines have different effects. The first adds the execute bit to the file. The second replaces the current permissions with only the execute bit. To have the same affect, you need to stat() the file, and then use bitwise-or to add the S_IXUSR | S_IXGRP | S_IXOTH bits to st_mode and use that new st_mode with chmod(). From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 13 16:16:01 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B59BC16A41F for ; Wed, 13 Jun 2007 16:16:01 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: from kiwi-computer.com (keira.kiwi-computer.com [63.224.10.3]) by mx1.freebsd.org (Postfix) with SMTP id 4549013C44C for ; Wed, 13 Jun 2007 16:15:56 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: (qmail 83837 invoked by uid 2001); 13 Jun 2007 16:15:52 -0000 Date: Wed, 13 Jun 2007 11:15:52 -0500 From: "Rick C. Petty" To: Garrett Cooper Message-ID: <20070613161552.GA83292@keira.kiwi-computer.com> References: <466F86C6.7010006@u.washington.edu> <20070613123213.GE98927@bunrab.catwhisker.org> <46700CAE.6020902@u.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46700CAE.6020902@u.washington.edu> User-Agent: Mutt/1.4.2.1i Cc: hackers@freebsd.org Subject: Re: Using shell commands versus C equivalents X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rick-freebsd@kiwi-computer.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2007 16:16:01 -0000 On Wed, Jun 13, 2007 at 08:26:38AM -0700, Garrett Cooper wrote: > > vsystem("/bin/chmod +x %s", filename); > > and I replaced it with: > > chmod(filename, (mode_t) ( S_IXUSR | S_IXGRP | S_IXOTH )); Another improvement made by using stat(2)/chmod(2) over chmod(1) using system(3) variants is the protection against malicious filenames. The original code should have used fork/execv instead anyway. But yeah, saving the fork, time to load and execute the shell, and parse and perform the chmod is probably worth the effort to use the syscalls directly from C, especially if this operation happens often enough. I agree with the other poster(s) who said that if it prevents complex code, it might be worth it. Your case isn't complex enough to warrant the spawning of a shell process, especially when one of your primary goals is to reduce total runtime. -- Rick C. Petty From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 13 16:26:34 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0765216A46D; Wed, 13 Jun 2007 16:26:34 +0000 (UTC) (envelope-from joerg@britannica.bec.de) Received: from www.pkgsrc-box.org (www.ostsee-abc.de [62.206.222.50]) by mx1.freebsd.org (Postfix) with ESMTP id AF29713C48C; Wed, 13 Jun 2007 16:26:33 +0000 (UTC) (envelope-from joerg@britannica.bec.de) Received: from britannica.bec.de (www.pkgsrc-box.org [127.0.0.1]) by www.pkgsrc-box.org (Postfix) with ESMTP id 1025DE7A3F9; Wed, 13 Jun 2007 16:26:31 +0000 (UTC) Received: by britannica.bec.de (Postfix, from userid 1000) id 4AF697D3C; Wed, 13 Jun 2007 18:26:00 +0200 (CEST) Date: Wed, 13 Jun 2007 18:25:59 +0200 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org, hackers@freebsd.org Message-ID: <20070613162559.GA5093@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org, hackers@freebsd.org References: <466F86C6.7010006@u.washington.edu> <20070613123213.GE98927@bunrab.catwhisker.org> <46700CAE.6020902@u.washington.edu> <20070613161552.GA83292@keira.kiwi-computer.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070613161552.GA83292@keira.kiwi-computer.com> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Subject: Re: Using shell commands versus C equivalents X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2007 16:26:34 -0000 On Wed, Jun 13, 2007 at 11:15:52AM -0500, Rick C. Petty wrote: > Another improvement made by using stat(2)/chmod(2) over chmod(1) using > system(3) variants is the protection against malicious filenames. The > original code should have used fork/execv instead anyway. To be precise, this case should use open/fstat/fchmod to avoid another bunch of race conditions. Joerg From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 13 16:26:34 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0765216A46D; Wed, 13 Jun 2007 16:26:34 +0000 (UTC) (envelope-from joerg@britannica.bec.de) Received: from www.pkgsrc-box.org (www.ostsee-abc.de [62.206.222.50]) by mx1.freebsd.org (Postfix) with ESMTP id AF29713C48C; Wed, 13 Jun 2007 16:26:33 +0000 (UTC) (envelope-from joerg@britannica.bec.de) Received: from britannica.bec.de (www.pkgsrc-box.org [127.0.0.1]) by www.pkgsrc-box.org (Postfix) with ESMTP id 1025DE7A3F9; Wed, 13 Jun 2007 16:26:31 +0000 (UTC) Received: by britannica.bec.de (Postfix, from userid 1000) id 4AF697D3C; Wed, 13 Jun 2007 18:26:00 +0200 (CEST) Date: Wed, 13 Jun 2007 18:25:59 +0200 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org, hackers@freebsd.org Message-ID: <20070613162559.GA5093@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org, hackers@freebsd.org References: <466F86C6.7010006@u.washington.edu> <20070613123213.GE98927@bunrab.catwhisker.org> <46700CAE.6020902@u.washington.edu> <20070613161552.GA83292@keira.kiwi-computer.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070613161552.GA83292@keira.kiwi-computer.com> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Subject: Re: Using shell commands versus C equivalents X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2007 16:26:34 -0000 On Wed, Jun 13, 2007 at 11:15:52AM -0500, Rick C. Petty wrote: > Another improvement made by using stat(2)/chmod(2) over chmod(1) using > system(3) variants is the protection against malicious filenames. The > original code should have used fork/execv instead anyway. To be precise, this case should use open/fstat/fchmod to avoid another bunch of race conditions. Joerg From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 13 17:18:12 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E3C0C16A400 for ; Wed, 13 Jun 2007 17:18:12 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by mx1.freebsd.org (Postfix) with ESMTP id C267813C4B0 for ; Wed, 13 Jun 2007 17:18:12 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from hymn01.u.washington.edu (hymn01.u.washington.edu [140.142.8.55]) by mxout3.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.05) with ESMTP id l5DHICK0022510 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 13 Jun 2007 10:18:12 -0700 Received: from localhost (localhost [127.0.0.1]) by hymn01.u.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l5DHICnf029939 for ; Wed, 13 Jun 2007 10:18:12 -0700 X-Auth-Received: from [192.55.52.2] by hymn01.u.washington.edu via HTTP; Wed, 13 Jun 2007 10:18:12 PDT Date: Wed, 13 Jun 2007 10:18:12 -0700 (PDT) From: youshi10@u.washington.edu To: hackers@freebsd.org In-Reply-To: <20070613153555.GA4439@britannica.bec.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.3.1.294258, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.6.13.95533 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='SUPERLONG_LINE 0.05, NO_REAL_NAME 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' Cc: Subject: Re: Using shell commands versus C equivalents X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2007 17:18:13 -0000 On Wed, 13 Jun 2007, Joerg Sonnenberger wrote: > On Wed, Jun 13, 2007 at 08:26:38AM -0700, Garrett Cooper wrote: >> Sorry -- actually I meant that (along similar lines), there was a >> program with the following lines: >> >> vsystem("/bin/chmod +x %s", filename); >> >> and I replaced it with: >> >> chmod(filename, (mode_t) ( S_IXUSR | S_IXGRP | S_IXOTH )); > > You supposedly mean stat + chmod here, right? Trivial errors like this > are easy to make. Yes ><. Good catch, thanks :). >> Next step, eliminating the linked list structure in favor or red-black >> trees, maybe. > > Due to the way pkg_install works, this most likely is just adding > complexity for no gain, it might actually slow it down. Hmmm... the only thing is that it does the linked list traversal a number of times per dependency. I'll take a look in gdb at the size of each dependency and then confer with Kirill (my mentor) about that a bit more. -Garrett From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 13 17:23:37 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3853D16A468 for ; Wed, 13 Jun 2007 17:23:37 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by mx1.freebsd.org (Postfix) with ESMTP id 1985E13C48A for ; Wed, 13 Jun 2007 17:23:37 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from hymn01.u.washington.edu (hymn01.u.washington.edu [140.142.8.55]) by mxout1.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.05) with ESMTP id l5DHNaDp005403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 13 Jun 2007 10:23:36 -0700 Received: from localhost (localhost [127.0.0.1]) by hymn01.u.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l5DHNaxE004704 for ; Wed, 13 Jun 2007 10:23:36 -0700 X-Auth-Received: from [192.55.52.2] by hymn01.u.washington.edu via HTTP; Wed, 13 Jun 2007 10:23:36 PDT Date: Wed, 13 Jun 2007 10:23:36 -0700 (PDT) From: youshi10@u.washington.edu To: hackers@freebsd.org In-Reply-To: <20070613162559.GA5093@britannica.bec.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.3.1.294258, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.6.13.100033 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='SUPERLONG_LINE 0.05, NO_REAL_NAME 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' Cc: Subject: Re: Using shell commands versus C equivalents X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2007 17:23:37 -0000 On Wed, 13 Jun 2007, Joerg Sonnenberger wrote: > On Wed, Jun 13, 2007 at 11:15:52AM -0500, Rick C. Petty wrote: >> Another improvement made by using stat(2)/chmod(2) over chmod(1) using >> system(3) variants is the protection against malicious filenames. The >> original code should have used fork/execv instead anyway. > > To be precise, this case should use open/fstat/fchmod to avoid another > bunch of race conditions. > > Joerg Should I briefly lock (flock) the file when running open/fstat/fchmod then to avoid issues? This may become a problem as pkg_*/make becomes more parallelized (another student's goals for his SoC project). Needless to say, pkg_* is by no means threadsafe in its current form though. It uses some global vars that are currently not mutex locked, and this type of file access is another issue (I wonder if spinlocking or sleeping waiting for flock to finish would be better in this case). -Garrett From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 13 17:25:30 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 925A916A46E for ; Wed, 13 Jun 2007 17:25:30 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout7.cac.washington.edu (mxout7.cac.washington.edu [140.142.32.178]) by mx1.freebsd.org (Postfix) with ESMTP id 73BCF13C489 for ; Wed, 13 Jun 2007 17:25:30 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from hymn01.u.washington.edu (hymn01.u.washington.edu [140.142.8.55]) by mxout7.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.05) with ESMTP id l5DHPTFl019385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 13 Jun 2007 10:25:30 -0700 Received: from localhost (localhost [127.0.0.1]) by hymn01.u.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l5DHPTYL007000 for ; Wed, 13 Jun 2007 10:25:29 -0700 X-Auth-Received: from [192.55.52.2] by hymn01.u.washington.edu via HTTP; Wed, 13 Jun 2007 10:25:29 PDT Date: Wed, 13 Jun 2007 10:25:29 -0700 (PDT) From: youshi10@u.washington.edu To: hackers@freebsd.org In-Reply-To: <20070613080334.GR89502@hoeg.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.3.1.294258, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.6.13.100033 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='NO_REAL_NAME 0, __CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' Cc: Subject: Re: Reason for doing malloc / bzero over calloc (performance)? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2007 17:25:30 -0000 On Wed, 13 Jun 2007, Ed Schouten wrote: > * Garrett Cooper wrote: >> Garrett Cooper wrote: >>> Title says it all -- is there a particular reason why malloc/bzero >>> should be used instead of calloc? >>> -Garrett >> As someone just brought to my attention, I should do some Googling. >> >> Initial results brought up this: >> . > > To be more precise; I took a look at the source code of calloc on my > FreeBSD 6 box: > > | void * > | calloc(num, size) > | size_t num; > | size_t size; > | { > | void *p; > | > | if (size != 0 && SIZE_T_MAX / size < num) { > | errno = ENOMEM; > | return (NULL); > | } > | > | size *= num; > | if ( (p = malloc(size)) ) > | bzero(p, size); > | return(p); > | } > > This means that the results on that website would be quite different > than the the ones that the FreeBSD 6 malloc/calloc should give. There is > even a difference between calloc'ing 10 block of 10 MB and 1 block of > 100 MB, which shouldn't make a difference here. calloc doesn't have any > performance-advantage here, because it just calls malloc/bzero. > > When looking at FreeBSD -CURRENT's calloc (won't paste it; too long), it > just does a arena_malloc/memset (which is malloc/bzero) for small > allocations but a huge_malloc for big allocations (say, multiple pages > big). The latter one already returns pages that are zero'd by the > kernel, so I suspect the calloc performance for big allocations on > -CURRENT is a lot better than on FreeBSD 6. As with FreeBSD 6, it > wouldn't matter if you calloc 10 pieces of 10 MB or one piece of 100 MB. > > Yours, > -- > Ed Schouten > WWW: http://g-rave.nl/ Hmmm... I wonder what the Mach kernel in OSX does to allocate memory then. I'll have to take a look at OpenDarwin's source sometime and see what it does. -Garrett From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 13 18:21:23 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 426B216A46C; Wed, 13 Jun 2007 18:21:23 +0000 (UTC) (envelope-from joerg@britannica.bec.de) Received: from www.pkgsrc-box.org (www.ostsee-abc.de [62.206.222.50]) by mx1.freebsd.org (Postfix) with ESMTP id F3DA613C469; Wed, 13 Jun 2007 18:21:22 +0000 (UTC) (envelope-from joerg@britannica.bec.de) Received: from britannica.bec.de (www.pkgsrc-box.org [127.0.0.1]) by www.pkgsrc-box.org (Postfix) with ESMTP id 3C16FE7A3FA; Wed, 13 Jun 2007 18:21:21 +0000 (UTC) Received: by britannica.bec.de (Postfix, from userid 1000) id 779A67D3C; Wed, 13 Jun 2007 20:20:48 +0200 (CEST) Date: Wed, 13 Jun 2007 20:20:47 +0200 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org, hackers@freebsd.org Message-ID: <20070613182046.GC8427@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org, hackers@freebsd.org References: <20070613162559.GA5093@britannica.bec.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Subject: Re: Using shell commands versus C equivalents X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2007 18:21:23 -0000 On Wed, Jun 13, 2007 at 10:23:36AM -0700, youshi10@u.washington.edu wrote: > Should I briefly lock (flock) the file when running open/fstat/fchmod then > to avoid issues? This may become a problem as pkg_*/make becomes more > parallelized (another student's goals for his SoC project). Looking does not change the issue. The problem here to protect against is that a process renames a file between the stat and the chmod. See the classic tmp file class of security vulnerabilities. > Needless to say, pkg_* is by no means threadsafe in its current form > though. It uses some global vars that are currently not mutex locked, and > this type of file access is another issue (I wonder if spinlocking or > sleeping waiting for flock to finish would be better in this case). I'm perfectly aware of the state of pkg_install. I also believe that it is a bad idea to parallelise it, but I don't want to argue with FreeBSD/Ports about that. Joerg From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 13 18:21:23 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 426B216A46C; Wed, 13 Jun 2007 18:21:23 +0000 (UTC) (envelope-from joerg@britannica.bec.de) Received: from www.pkgsrc-box.org (www.ostsee-abc.de [62.206.222.50]) by mx1.freebsd.org (Postfix) with ESMTP id F3DA613C469; Wed, 13 Jun 2007 18:21:22 +0000 (UTC) (envelope-from joerg@britannica.bec.de) Received: from britannica.bec.de (www.pkgsrc-box.org [127.0.0.1]) by www.pkgsrc-box.org (Postfix) with ESMTP id 3C16FE7A3FA; Wed, 13 Jun 2007 18:21:21 +0000 (UTC) Received: by britannica.bec.de (Postfix, from userid 1000) id 779A67D3C; Wed, 13 Jun 2007 20:20:48 +0200 (CEST) Date: Wed, 13 Jun 2007 20:20:47 +0200 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org, hackers@freebsd.org Message-ID: <20070613182046.GC8427@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org, hackers@freebsd.org References: <20070613162559.GA5093@britannica.bec.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Subject: Re: Using shell commands versus C equivalents X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2007 18:21:23 -0000 On Wed, Jun 13, 2007 at 10:23:36AM -0700, youshi10@u.washington.edu wrote: > Should I briefly lock (flock) the file when running open/fstat/fchmod then > to avoid issues? This may become a problem as pkg_*/make becomes more > parallelized (another student's goals for his SoC project). Looking does not change the issue. The problem here to protect against is that a process renames a file between the stat and the chmod. See the classic tmp file class of security vulnerabilities. > Needless to say, pkg_* is by no means threadsafe in its current form > though. It uses some global vars that are currently not mutex locked, and > this type of file access is another issue (I wonder if spinlocking or > sleeping waiting for flock to finish would be better in this case). I'm perfectly aware of the state of pkg_install. I also believe that it is a bad idea to parallelise it, but I don't want to argue with FreeBSD/Ports about that. Joerg From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 13 18:25:57 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3246716A469 for ; Wed, 13 Jun 2007 18:25:57 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: from kiwi-computer.com (keira.kiwi-computer.com [63.224.10.3]) by mx1.freebsd.org (Postfix) with SMTP id 839D513C469 for ; Wed, 13 Jun 2007 18:25:56 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: (qmail 86764 invoked by uid 2001); 13 Jun 2007 18:25:55 -0000 Date: Wed, 13 Jun 2007 13:25:55 -0500 From: "Rick C. Petty" To: youshi10@u.washington.edu Message-ID: <20070613182555.GA86571@keira.kiwi-computer.com> References: <20070613162559.GA5093@britannica.bec.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: hackers@freebsd.org Subject: Re: Using shell commands versus C equivalents X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rick-freebsd@kiwi-computer.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2007 18:25:57 -0000 On Wed, Jun 13, 2007 at 10:23:36AM -0700, youshi10@u.washington.edu wrote: > On Wed, 13 Jun 2007, Joerg Sonnenberger wrote: > > Should I briefly lock (flock) the file when running open/fstat/fchmod then > to avoid issues? This may become a problem as pkg_*/make becomes more > parallelized (another student's goals for his SoC project). I wouldn't bother. What issue are you trying to avoid? If one process is trying to chmod +x and another is trying to do a chmod -x, it shouldn't matter if you lock between the fstat/fchmod-- someone is going to win anyway. This operation is not something that needs to be thread-safe. > Needless to say, pkg_* is by no means threadsafe in its current form > though. It uses some global vars that are currently not mutex locked, and > this type of file access is another issue (I wonder if spinlocking or > sleeping waiting for flock to finish would be better in this case). Does pkg_* use multiple threads? I was under the impression each pkg tool used a single thread (i.e. no threads) to do its operations and that they wait for system(2)-type calls as needed. Maybe I'm not clear by what you mean when you say "global vars". Now another question is whether the pkg_* tools can handle multiple processes managing the ports at the same time. For the mostpart, this is true. Without looking at the code, I would expect that the only contentions would be when trying to update the +REQUIRED_BY files. Everything else should be just fine; you're not supposed to be installing the same port multiple times at the exact same time, but maybe a lock could be held on the package directory (i.e. /var/db/pkg/$PKG_NAME). Again, I don't believe this is strictly necessary. -- Rick C. Petty From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 13 18:47:51 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6BFCF16A484 for ; Wed, 13 Jun 2007 18:47:51 +0000 (UTC) (envelope-from egypcio@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.183]) by mx1.freebsd.org (Postfix) with ESMTP id 3B67913C4C8 for ; Wed, 13 Jun 2007 18:47:51 +0000 (UTC) (envelope-from egypcio@gmail.com) Received: by wa-out-1112.google.com with SMTP id j37so382104waf for ; Wed, 13 Jun 2007 11:47:50 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Tqi1NYt3yOWWUxscKl1qruMQNQZOIEGR7jYeLXGSt4wb90hqBglXe2LywKoVRJP2j8QIGUDC3+gdveKTmL2Hi3+JpokoirzrGJEozVVTSdwuW/BLF3WuoctJfCQUH2p2FUUoOyUzGRXyD7Xqi9GzL5oqpfITh16DXnlXid/1Fn8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=goju4W82vXsW93DyAZzBJ9xcsE2er0For5/YzJ5y2MEXM2pjLUvKW+/X6XLOOg20cCnZB7aL5osX7t7vJRU480hUrMqp2zXbBoNAMi6xFTOu85yz5MGldQvfdrljJW+02hxYtvkbcTtz45SCiOYwhnb2yi2O3MoqV7g+T7YBVsM= Received: by 10.114.210.2 with SMTP id i2mr935638wag.1181758837024; Wed, 13 Jun 2007 11:20:37 -0700 (PDT) Received: by 10.115.14.3 with HTTP; Wed, 13 Jun 2007 11:20:36 -0700 (PDT) Message-ID: <8b5ad0e10706131120m1f09b647o3fb055527682d4c@mail.gmail.com> Date: Wed, 13 Jun 2007 14:20:36 -0400 From: "=?ISO-8859-1?Q?Zavam,_Vin=EDcius?=" To: freebsd-hackers@freebsd.org In-Reply-To: <20070613020642.463afff4@vixen42> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20070613020642.463afff4@vixen42> Subject: Re: building images for running from flash X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2007 18:47:51 -0000 2007/6/13, Z.C.B. : > Just been looking at rebuilding my router. I understand building the > image and etc, but the issue I am running into is what to do about > ports. To solve this, I am looking at building the image and using > mdconfig, unionfs, and jail to solve building ports. Also looking > at the possibility of qemu. Any thoughts or suggestions? > > Another annoying issue is the muckery involved with /etc/make.conf... > The issue I am running into that is the CPUTYPE? option is different > for the build machine and router that the flash will be used on. Any > nice way to deal with this? tinybsd.org ;-) "ports/sysutils/tinybsd" --=20 Zavam, Vin=EDcius From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 13 19:30:45 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 52E0216A480 for ; Wed, 13 Jun 2007 19:30:45 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from kientzle.com (h-66-166-149-50.snvacaid.covad.net [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id EE1EA13C48C for ; Wed, 13 Jun 2007 19:30:44 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from [10.0.0.222] (p54.kientzle.com [66.166.149.54]) by kientzle.com (8.12.9/8.12.9) with ESMTP id l5DJ0vH7071350; Wed, 13 Jun 2007 12:00:57 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <46703EE9.1030804@freebsd.org> Date: Wed, 13 Jun 2007 12:00:57 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060422 X-Accept-Language: en-us, en MIME-Version: 1.0 To: youshi10@u.washington.edu References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org Subject: Re: Using shell commands versus C equivalents X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2007 19:30:45 -0000 >>> Next step, eliminating the linked list structure in favor or red-black >>> trees, maybe. >> >> Due to the way pkg_install works, this most likely is just adding >> complexity for no gain, it might actually slow it down. > > Hmmm... the only thing is that it does the linked list traversal a > number of times per dependency. I'll take a look in gdb at the size of > each dependency and then confer with Kirill (my mentor) about that a bit > more. If you tend to look for the same few items over and over, just move items to the front of the list as soon as you find them. Alternatively, if you know you won't look for this item ever again, move it to the end of the list or remove it from the list entirely. Simple tricks like this can greatly speed things up with almost no effort. Better yet, do easy things like this first; if they help, then look at more complex approaches. As Joerg said, though, you're not likely to gain much from this. pkg_install is almost entirely disk bound. I spent a lot of time recently in libarchive/bsdtar optimizing the disk handling; I can share lots of ideas for improving performance of disk-bound operations like this. Tim Kientzle From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 13 21:17:19 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5B89D16A41F for ; Wed, 13 Jun 2007 21:17:19 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by mx1.freebsd.org (Postfix) with ESMTP id 3AB5513C465 for ; Wed, 13 Jun 2007 21:17:19 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from hymn01.u.washington.edu (hymn01.u.washington.edu [140.142.8.55]) by mxout3.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.05) with ESMTP id l5DLHICu009213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 13 Jun 2007 14:17:18 -0700 Received: from localhost (localhost [127.0.0.1]) by hymn01.u.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l5DLHIMa028677 for ; Wed, 13 Jun 2007 14:17:18 -0700 X-Auth-Received: from [192.55.52.1] by hymn01.u.washington.edu via HTTP; Wed, 13 Jun 2007 14:17:18 PDT Date: Wed, 13 Jun 2007 14:17:18 -0700 (PDT) From: youshi10@u.washington.edu To: hackers@freebsd.org In-Reply-To: <20070613182555.GA86571@keira.kiwi-computer.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.3.1.294258, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.6.13.135634 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='SUPERLONG_LINE 0.05, NO_REAL_NAME 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' Cc: Subject: Re: Using shell commands versus C equivalents X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2007 21:17:19 -0000 On Wed, 13 Jun 2007, Rick C. Petty wrote: > On Wed, Jun 13, 2007 at 10:23:36AM -0700, youshi10@u.washington.edu wrote: >> On Wed, 13 Jun 2007, Joerg Sonnenberger wrote: >> >> Should I briefly lock (flock) the file when running open/fstat/fchmod then >> to avoid issues? This may become a problem as pkg_*/make becomes more >> parallelized (another student's goals for his SoC project). > > I wouldn't bother. What issue are you trying to avoid? If one process is > trying to chmod +x and another is trying to do a chmod -x, it shouldn't > matter if you lock between the fstat/fchmod-- someone is going to win > anyway. This operation is not something that needs to be thread-safe. > >> Needless to say, pkg_* is by no means threadsafe in its current form >> though. It uses some global vars that are currently not mutex locked, and >> this type of file access is another issue (I wonder if spinlocking or >> sleeping waiting for flock to finish would be better in this case). > > Does pkg_* use multiple threads? I was under the impression each pkg tool > used a single thread (i.e. no threads) to do its operations and that they > wait for system(2)-type calls as needed. Maybe I'm not clear by what you > mean when you say "global vars". Well, I mean that as it currently stands there are several variables used globally for setting attributes per package (I'm not at my machine right now so I can't look them up until ~6pm PST). > Now another question is whether the pkg_* tools can handle multiple > processes managing the ports at the same time. For the mostpart, this is > true. Without looking at the code, I would expect that the only > contentions would be when trying to update the +REQUIRED_BY files. > Everything else should be just fine; you're not supposed to be installing > the same port multiple times at the exact same time, but maybe a lock could > be held on the package directory (i.e. /var/db/pkg/$PKG_NAME). Again, I > don't believe this is strictly necessary. Currently, no, and this is a condition that's contingent for a fellow SoC'er's project. The mentor said that all that *should* occur is there should be an flock, but that was it. So instead of making more work for him and since I am modifying pkg_* already, I thought it would be best to just make my modifications to simplify his end (he still has a ways to go on the dependency tracking I think). It goes a bit deeper than the +REQUIRED_BY files, in particular with the +CONTENTS, etc files as the pkg_* tools are enumerating the packages currently on the system, their dependencies, owning files, etc. Perhaps a global .lock file of some kind in the package directories would be the way to go though. Thanks, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 13 21:21:01 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D5B4316A46B; Wed, 13 Jun 2007 21:21:01 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by mx1.freebsd.org (Postfix) with ESMTP id B061A13C4AE; Wed, 13 Jun 2007 21:21:01 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from hymn01.u.washington.edu (hymn01.u.washington.edu [140.142.8.55]) by mxout2.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.05) with ESMTP id l5DLL1YP004547 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Jun 2007 14:21:01 -0700 Received: from localhost (localhost [127.0.0.1]) by hymn01.u.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l5DLL1vU001849; Wed, 13 Jun 2007 14:21:01 -0700 X-Auth-Received: from [192.55.52.1] by hymn01.u.washington.edu via HTTP; Wed, 13 Jun 2007 14:21:00 PDT Date: Wed, 13 Jun 2007 14:21:00 -0700 (PDT) From: youshi10@u.washington.edu To: Tim Kientzle In-Reply-To: <46703EE9.1030804@freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.3.1.294258, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.6.13.140033 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='SUPERLONG_LINE 0.05, NO_REAL_NAME 0, __CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' Cc: hackers@freebsd.org Subject: Re: Using shell commands versus C equivalents X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2007 21:21:01 -0000 On Wed, 13 Jun 2007, Tim Kientzle wrote: >>>> Next step, eliminating the linked list structure in favor or red-black >>>> trees, maybe. >>> >>> Due to the way pkg_install works, this most likely is just adding >>> complexity for no gain, it might actually slow it down. >> >> Hmmm... the only thing is that it does the linked list traversal a number of >> times per dependency. I'll take a look in gdb at the size of each dependency >> and then confer with Kirill (my mentor) about that a bit more. > > If you tend to look for the same few items over and over, > just move items to the front of the list as soon as you > find them. Alternatively, if you know you won't look for > this item ever again, move it to the end of the list or > remove it from the list entirely. > > Simple tricks like this can greatly speed things up with > almost no effort. Better yet, do easy things like this first; > if they help, then look at more complex approaches. > > As Joerg said, though, you're not likely to gain much from > this. pkg_install is almost entirely disk bound. > > I spent a lot of time recently in libarchive/bsdtar optimizing > the disk handling; I can share lots of ideas for improving > performance of disk-bound operations like this. > > Tim Kientzle Thank you Tim. I'll definitely keep that in mind :). -Garrett PS I'm looking at pkg_install and pkg_version mostly, but I'll be looking into the other package utilities closely in the next couple weeks, evaluating what approaches I should take in solving some bottlenecks with installing packages and ports. My goals are up on , and will be modified soon. From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 13 22:28:35 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 96AF216A468 for ; Wed, 13 Jun 2007 22:28:35 +0000 (UTC) (envelope-from SRS0=L4wNFO=LN=vvelox.net=v.velox@yourhostingaccount.com) Received: from mailout12.yourhostingaccount.com (mailout12.yourhostingaccount.com [65.254.253.100]) by mx1.freebsd.org (Postfix) with ESMTP id 69B7813C483 for ; Wed, 13 Jun 2007 22:28:35 +0000 (UTC) (envelope-from SRS0=L4wNFO=LN=vvelox.net=v.velox@yourhostingaccount.com) Received: from mailscan10.yourhostingaccount.com ([10.1.15.10] helo=mailscan10.yourhostingaccount.com) by mailout12.yourhostingaccount.com with esmtp (Exim) id 1HybKM-0001d1-D5 for freebsd-hackers@freebsd.org; Wed, 13 Jun 2007 18:28:34 -0400 Received: from authsmtp09.yourhostingaccount.com ([10.1.18.9] ident=exim) by mailscan10.yourhostingaccount.com with spamscanlookuphost (Exim) id 1HybKM-0001cz-CY for freebsd-hackers@freebsd.org; Wed, 13 Jun 2007 18:28:34 -0400 Received: from authsmtp09.yourhostingaccount.com ([10.1.18.9] helo=authsmtp09.yourhostingaccount.com) by mailscan10.yourhostingaccount.com with esmtp (Exim) id 1HybKL-0001bj-9t; Wed, 13 Jun 2007 18:28:33 -0400 Received: from cpe-24-93-100-44.columbus.res.rr.com ([24.93.100.44] helo=vixen42) by authsmtp09.yourhostingaccount.com with esmtpa (Exim) id 1HybKJ-000174-Ua; Wed, 13 Jun 2007 18:28:33 -0400 Date: Wed, 13 Jun 2007 18:29:25 -0400 From: "Z.C.B." To: Mike Meyer Message-ID: <20070613182925.5b26696b@vixen42> In-Reply-To: <18031.63514.578231.63127@bhuda.mired.org> References: <20070613020642.463afff4@vixen42> <18031.63514.578231.63127@bhuda.mired.org> X-Mailer: Claws Mail 2.9.2 (GTK+ 2.10.12; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-EN-UserInfo: 0d1ca1697cdb7a831d4877828571b7ab:1570f0de6936c69fef9e164fffc541bc X-EN-AuthUser: vvelox2 Sender: "Z.C.B." X-EN-OrigIP: 24.93.100.44 X-EN-OrigHost: cpe-24-93-100-44.columbus.res.rr.com Cc: freebsd-hackers@freebsd.org Subject: Re: building images for running from flash X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2007 22:28:35 -0000 On Wed, 13 Jun 2007 09:58:50 -0400 Mike Meyer wrote: > In <20070613020642.463afff4@vixen42>, Z.C.B. > typed: > > Another annoying issue is the muckery involved > > with /etc/make.conf... The issue I am running into that is the > > CPUTYPE? option is different for the build machine and router > > that the flash will be used on. Any nice way to deal with this? > > If they are different implementations of the same architecture, you > can set CPUTYPE to the lower of the two. For the kernel and world, > you can set TARGET_ARCH= on the make line, and it will > cross-compile the world for you (assuming your compiler can > generate code for that architecture. Setting CPUTYPE in /etc/make.conf is exactly what I am trying to avoid. The big question is still what to do about the ports. From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 13 23:21:49 2007 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A5C3816A46C; Wed, 13 Jun 2007 23:21:49 +0000 (UTC) (envelope-from stsp@stsp.name) Received: from einhorn.in-berlin.de (einhorn.in-berlin.de [192.109.42.8]) by mx1.freebsd.org (Postfix) with ESMTP id 96EB013C455; Wed, 13 Jun 2007 23:21:48 +0000 (UTC) (envelope-from stsp@stsp.name) X-Envelope-From: stsp@stsp.name Received: from stsp.lan (stsp.in-vpn.de [217.197.85.96]) (authenticated bits=128) by einhorn.in-berlin.de (8.13.6/8.13.6/Debian-1) with ESMTP id l5DNLgoJ027735 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 14 Jun 2007 01:21:44 +0200 Received: from ted.stsp.lan (localhost [127.0.0.1]) by stsp.lan (8.13.8/8.13.8) with ESMTP id l5DNL50t056737; Thu, 14 Jun 2007 01:21:05 +0200 (CEST) (envelope-from stsp@stsp.name) Received: (from stsp@localhost) by ted.stsp.lan (8.13.8/8.13.8/Submit) id l5DNL4UN056736; Thu, 14 Jun 2007 01:21:04 +0200 (CEST) (envelope-from stsp@stsp.name) X-Authentication-Warning: ted.stsp.lan: stsp set sender to stsp@stsp.name using -f Date: Thu, 14 Jun 2007 01:21:03 +0200 From: Stefan Sperling To: Edwin Mons , bug-followup@FreeBSD.org, freebsd-hackers@FreeBSD.org Message-ID: <20070613232103.GA53373@ted.stsp.lan> Mail-Followup-To: Edwin Mons , bug-followup@FreeBSD.org, freebsd-hackers@FreeBSD.org References: <466A6DF1.3020306@edwinm.ik.nu> <20070609103848.GA1465@ted.stsp.lan> <466AC23B.4040601@edwinm.ik.nu> <20070610144504.GA7129@ted.stsp.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="s2ZSL+KKDSLx8OML" Content-Disposition: inline In-Reply-To: <20070610144504.GA7129@ted.stsp.lan> User-Agent: Mutt/1.5.15 (2007-04-06) X-Scanned-By: MIMEDefang_at_IN-Berlin_e.V. on 192.109.42.8 Cc: Subject: Re: kern/83807: [sis] [patch] if_sis: Wake On Lan support for FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2007 23:21:49 -0000 --s2ZSL+KKDSLx8OML Content-Type: multipart/mixed; boundary="X1bOJ3K7DJ5YkBrT" Content-Disposition: inline --X1bOJ3K7DJ5YkBrT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jun 10, 2007 at 04:45:04PM +0200, Stefan Sperling wrote: > > I usually use either if_em or if_xl chipsets, so I hoped landing this = code=20 > > in at least -CURRENT (should go there first, I guess) would result in = more=20 > > chipsets supported ;) >=20 > There is code for enabling wake on lan in the Linux drivers for both > if_xl and if_em cards. See drivers/net/3c59x.c and > drivers/net/e1000/e1000_ethtool.c in the linux source tree. >=20 > So I don't think adding support for these cards is a problem. > Just need to find some time to do it... Updated patch attached. Also available at http://stsp.name/wol/ Now contains untested support for if_xl. Please test. I have no such card so I cannot test this myself. Note that apparently only 3C905B type cards support wake on lan. And they only support magic packet events, no unicast, broadcast or multicast events. The patch is against RELENG_6_2. Sorry I have no -CURRENT system set up at the moment. I don't know if the patch even applies to -CURRENT. Once if_xl is working I'll look into getting if_em supported. If any nve users are reading this, I still need feedback on if_nve as well. I cannot test nve myself either. Thanks, --=20 stefan http://stsp.name PGP Key: 0xF59D25F0 --X1bOJ3K7DJ5YkBrT Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="FreeBSD-6.2-wol-2007-06-14.diff" Content-Transfer-Encoding: quoted-printable Index: sbin/ifconfig/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/local/ncvs/src/sbin/ifconfig/Makefile,v retrieving revision 1.29 diff -u -u -r1.29 Makefile --- sbin/ifconfig/Makefile 5 Jun 2005 03:32:51 -0000 1.29 +++ sbin/ifconfig/Makefile 6 May 2006 11:08:41 -0000 @@ -28,6 +28,8 @@ =20 SRCS+=3D ifbridge.c # bridge support =20 +SRCS+=3D ifwol.c # wake on lan support + .if !defined(RELEASE_CRUNCH) SRCS+=3D af_ipx.c # IPX support DPADD=3D ${LIBIPX} Index: sbin/ifconfig/ifconfig.8 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/local/ncvs/src/sbin/ifconfig/ifconfig.8,v retrieving revision 1.95.2.17 diff -u -u -r1.95.2.17 ifconfig.8 --- sbin/ifconfig/ifconfig.8 3 Nov 2006 09:14:24 -0000 1.95.2.17 +++ sbin/ifconfig/ifconfig.8 13 Jan 2007 12:18:33 -0000 @@ -939,6 +939,27 @@ If that is the case, then the first four keys (1-4) will be the standard temporary keys and any others will be adaptor specific keys such as permanent keys stored in NVRAM. +.It Cm wakeon Ar events +Enable Wake On Lan support, if available. The=20 +.Ar events +argument is a comma seperated list of package types that shall +trigger wake events. The set of valid package types is +.Dq Li unicast , +.Dq Li multicast , +.Dq Li broadcast , +and +.Dq Li magic . +These enable wake on unicast, multicast, broadcast and Magic Packet(tm), +respectively. +A SecureOn password, if supported, can be be enabled using the +.Dq Li sopasswd:=20 +event. +SecureOn passwords only work in combination with +.Dq Li magic . +The password must consist of 12 hexadecimal digits. +.It Fl wakeon +Disable Wake On Lan. +.Pp .It Cm wme Enable Wireless Multimedia Extensions (WME) support, if available, for the specified interface. @@ -946,7 +967,6 @@ efficient communication of realtime and multimedia data. To disable WME support, use .Fl wme . -.Pp The following parameters are meaningful only when WME support is in use. Parameters are specified per-AC (Access Category) and split into those that are used by a station when acting Index: sbin/ifconfig/ifwol.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: sbin/ifconfig/ifwol.c diff -N sbin/ifconfig/ifwol.c --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ sbin/ifconfig/ifwol.c 20 Oct 2006 10:29:10 -0000 @@ -0,0 +1,229 @@ +/* $Id$ */ + +/* + * Copyright (c) 2005 Stefan Sperling. + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. The name of the author may not be used to endorse or promote products + * derived from this software without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTI= ES + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. + * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, + * BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; + * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED + * AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, + * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "ifconfig.h" + +static void wol_status(int s); +static void setwol(const char *, int, int, const struct afswtch *); +static void parse_args(const char *, struct if_wolopts *); +static void parse_sopasswd(const char *, u_char *); +static void unsetwol(const char *, int, int, const struct afswtch *); +static void print_wol_events(uint32_t events); + +/* + * Print wake on lan capabilities and events the device currently heeds. + */ +static void +wol_status(int s) +{ + struct ifreq ifr; + + memset(&ifr, 0, sizeof(ifr)); + strlcpy(ifr.ifr_name, name, IFNAMSIZ); + + if (ioctl(s, SIOCGIFWOLSUPP, &ifr) < 0) + /* Device does not support wake on lan */ + return; + + printf("\tsupported wake events:"); + print_wol_events(ifr.ifr_wolopts.ifwol_supported); + printf("\n"); + + if (ioctl(s, SIOCGIFWOLOPTS, &ifr) < 0) + err(EX_USAGE, "SIOCGIFWOLOPTS"); + + if (ifr.ifr_wolopts.ifwol_events =3D=3D 0) + return; + + printf("\twill wake on:"); + print_wol_events(ifr.ifr_wolopts.ifwol_events); + printf("\n"); +} + +static void +print_wol_events(uint32_t events) +{ + if (events & IFWOL_WAKE_ON_UNICAST) + printf(" unicast"); + if (events & IFWOL_WAKE_ON_MULTICAST) + printf(" multicast"); + if (events & IFWOL_WAKE_ON_BROADCAST) + printf(" broadcast"); + if (events & IFWOL_WAKE_ON_MAGIC) { + printf(" magic"); + if (events & IFWOL_ENABLE_SOPASSWD) + printf("[SecureOn password]"); + } +} + +/* + * Set wake on lan events. + */ +static void +setwol(const char *val, int d, int s, const struct afswtch *afp) +{ + struct ifreq ifr; + + memset(&ifr, 0, sizeof(ifr)); + strlcpy(ifr.ifr_name, name, IFNAMSIZ); + + if (ioctl(s, SIOCGIFWOLSUPP, &ifr) < 0) + err(EX_USAGE, "device does not support wake on lan"); + + parse_args(val, &ifr.ifr_wolopts); + if (ioctl(s, SIOCSIFWOLOPTS, &ifr) < 0) + err(EX_USAGE, "SIOCSIFWOLOPTS"); +} + +/*=20 + * Parse the argument string, which may contain one or more of the + * following: + * =20 + * unicast,multicast,broadcast,magic,sopasswd:xxxxxxxxxxxx, + * + * and fill the wolopts structure accordingly. + *=20 + */ +static void +parse_args(const char* args, struct if_wolopts *wolopts) +{ + uint32_t wol_events =3D 0; + char* opt; + + for (opt =3D strdup(args); (opt =3D strtok(opt, ",")) !=3D NULL; opt =3D = NULL) { + if (strcmp(opt, "unicast") =3D=3D 0) + wol_events |=3D IFWOL_WAKE_ON_UNICAST; + else if (strcmp(opt, "multicast") =3D=3D 0) + wol_events |=3D IFWOL_WAKE_ON_MULTICAST; + else if (strcmp(opt, "broadcast") =3D=3D 0) + wol_events |=3D IFWOL_WAKE_ON_BROADCAST; + else if (strcmp(opt, "magic") =3D=3D 0) + wol_events |=3D IFWOL_WAKE_ON_MAGIC; + else if (strcmp(opt, "sopasswd") =3D=3D 0) + errx(EX_USAGE, "no SecureOn password specfied."); + else if (strncmp(opt, "sopasswd:", strlen("sopasswd:")) =3D=3D 0) { + wol_events |=3D IFWOL_ENABLE_SOPASSWD; + parse_sopasswd(opt + strlen("sopasswd:"), wolopts->ifwol_sopasswd); + } else { + errx(EX_USAGE, "unknown wake event %s", opt); + } + } + free(opt); + wolopts->ifwol_events =3D wol_events; +} + +/* SecureOn passwords are not like plain text passwords. Instead, they con= sist + * of 6 bytes (ie unsigned char). Try to prevent users from giving anythin= g other + * than a string of six concatenated unsigned chars in hex as password. + */ +static void +parse_sopasswd(const char *pw, u_char *dest) { + char substr[3]; + int len, i, n; + + len =3D strlen(pw) / 2; + if (len !=3D 6) + errx(EX_USAGE, "Invalid SecureOn password."); + + for (i =3D 0; i < len; i++) { + (void)strncpy(substr, pw, 2); + substr[2] =3D '\0'; + if (sscanf(substr, "%x", &n) !=3D 1) + errx(EX_USAGE, "Invalid SecureOn password."); + if (n < 0x0 || n > 0xff) + /* Should never happen, but just in case... */ + errx(EX_USAGE, "Invalid SecureOn password."); + *dest++ =3D (u_char)n; + pw +=3D 2; + } +} + +/* + * Unset all wake on lan events. + */ +static void +unsetwol(const char *val, int d, int s, const struct afswtch *afp) +{ + struct ifreq ifr; + + memset(&ifr, 0, sizeof(ifr)); + strlcpy(ifr.ifr_name, name, IFNAMSIZ); + + if (ioctl(s, SIOCGIFWOLSUPP, &ifr) < 0) + err(EX_USAGE, "device does not support wake on lan"); + + ifr.ifr_wolopts.ifwol_events =3D IFWOL_DISABLE; + if (ioctl(s, SIOCSIFWOLOPTS, &ifr) < 0) + err(EX_USAGE, "SIOCSIFWOLOPTS"); +} + +static struct cmd wol_cmds[] =3D { + DEF_CMD_ARG("wakeon", setwol), + DEF_CMD("-wakeon", 0, unsetwol) +}; +static struct afswtch af_wol =3D { + .af_name =3D "af_wol", + .af_af =3D AF_UNSPEC, + .af_other_status =3D wol_status, +}; + +static __constructor void +ifwol_ctor(void) +{ +#define N(a) (sizeof(a) / sizeof(a[0])) + int i; + + for (i =3D 0; i < N(wol_cmds); i++) + cmd_register(&wol_cmds[i]); + af_register(&af_wol); +#undef N +} Index: sys/dev/nve/if_nve.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/local/ncvs/src/sys/dev/nve/if_nve.c,v retrieving revision 1.7.2.11 diff -u -u -r1.7.2.11 if_nve.c --- sys/dev/nve/if_nve.c 13 Sep 2006 15:15:57 -0000 1.7.2.11 +++ sys/dev/nve/if_nve.c 13 Jan 2007 12:21:03 -0000 @@ -177,6 +177,10 @@ static NV_SINT32 nve_oslockrelease(PNV_VOID, NV_SINT32, PNV_VOID); static PNV_VOID nve_osreturnbufvirt(PNV_VOID, PNV_VOID); =20 +static void nve_enable_wol(struct nve_softc *); +static void nve_get_wolopts(struct nve_softc *, struct if_wolopts *); +static int nve_set_wolopts(struct nve_softc *, struct if_wolopts *); + static device_method_t nve_methods[] =3D { /* Device interface */ DEVMETHOD(device_probe, nve_probe), @@ -725,6 +729,10 @@ =20 sc =3D device_get_softc(dev); =20 + NVE_LOCK(sc); + nve_enable_wol(sc); + NVE_UNLOCK(sc); + /* Stop hardware activity */ NVE_LOCK(sc); nve_stop(sc); @@ -1036,6 +1044,21 @@ mii =3D device_get_softc(sc->miibus); error =3D ifmedia_ioctl(ifp, ifr, &mii->mii_media, command); break; + case SIOCGIFWOLSUPP: + ifr->ifr_wolopts.ifwol_supported =3D NVE_SUPPORTED_WOL_EVENTS; + error =3D 0; + break; + case SIOCGIFWOLOPTS: + NVE_LOCK(sc); + nve_get_wolopts(sc, &ifr->ifr_wolopts); + NVE_UNLOCK(sc); + error =3D 0; + break; + case SIOCSIFWOLOPTS: + NVE_LOCK(sc); + error =3D nve_set_wolopts(sc, &ifr->ifr_wolopts); + NVE_UNLOCK(sc); + break; =20 default: /* Everything else we forward to generic ether ioctl */ @@ -1775,3 +1798,49 @@ } =20 /* --- End on NVOSAPI interface --- */ + +/* + * Enable Wake On Lan. + */ +static void +nve_enable_wol(struct nve_softc *sc) +{ + ADAPTER_POWERSTATE pstate =3D {0}; + + if (sc->wol_events =3D=3D 0) + return; +=09 + if (sc->wol_events & IFWOL_WAKE_ON_MAGIC) { + pstate.ulPowerFlags =3D POWER_STATE_D3; + pstate.ulMagicPacketWakeUpFlags =3D POWER_STATE_ALL; + pstate.ulLinkChangeWakeUpFlags =3D 0; + pstate.ulPatternWakeUpFlags =3D 0; + sc->hwapi->pfnSetPowerState(sc->hwapi->pADCX, &pstate); + } +} + +/* + * Write current wake on lan settings into an if_wolopts structure. + */ +static void +nve_get_wolopts(struct nve_softc *sc, struct if_wolopts *wolopts) +{ + wolopts->ifwol_events =3D sc->wol_events; +} + +/* + * Set wake on lan options. + */ +static int +nve_set_wolopts(struct nve_softc *sc, struct if_wolopts *wolopts) +{ + if (wolopts->ifwol_events =3D=3D IFWOL_DISABLE) + sc->wol_events =3D 0; + else { + if ((wolopts->ifwol_events & ~NVE_SUPPORTED_WOL_EVENTS) !=3D 0) + return EINVAL; + sc->wol_events =3D wolopts->ifwol_events; + } + + return 0; +} Index: sys/dev/nve/if_nvereg.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/local/ncvs/src/sys/dev/nve/if_nvereg.h,v retrieving revision 1.3.2.2.2.1 diff -u -u -r1.3.2.2.2.1 if_nvereg.h --- sys/dev/nve/if_nvereg.h 7 Dec 2006 22:28:52 -0000 1.3.2.2.2.1 +++ sys/dev/nve/if_nvereg.h 13 Jan 2007 12:21:03 -0000 @@ -69,6 +69,8 @@ #define NVE_DEBUG_MII 0x0100 #define NVE_DEBUG_ALL 0xFFFF =20 +#define NVE_SUPPORTED_WOL_EVENTS IFWOL_WAKE_ON_MAGIC + #if NVE_DEBUG #define DEBUGOUT(level, fmt, args...) if (NVE_DEBUG & level) \ printf(fmt, ## args) @@ -143,6 +145,8 @@ =20 struct mtx mtx; =20 + uint32_t wol_events; + /* Stuff for dealing with the NVIDIA OS API */ struct callout ostimer; PTIMER_FUNC ostimer_func; Index: sys/net/if.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/local/ncvs/src/sys/net/if.c,v retrieving revision 1.234.2.17 diff -u -u -r1.234.2.17 if.c --- sys/net/if.c 6 Oct 2006 20:26:05 -0000 1.234.2.17 +++ sys/net/if.c 13 Jan 2007 12:23:17 -0000 @@ -1461,6 +1461,7 @@ case SIOCSLIFPHYADDR: case SIOCSIFMEDIA: case SIOCSIFGENERIC: + case SIOCSIFWOLOPTS: error =3D suser(td); if (error) return (error); @@ -1482,6 +1483,8 @@ case SIOCGLIFPHYADDR: case SIOCGIFMEDIA: case SIOCGIFGENERIC: + case SIOCGIFWOLOPTS: + case SIOCGIFWOLSUPP: if (ifp->if_ioctl =3D=3D NULL) return (EOPNOTSUPP); IFF_LOCKGIANT(ifp); Index: sys/net/if.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/local/ncvs/src/sys/net/if.h,v retrieving revision 1.96.2.4 diff -u -u -r1.96.2.4 if.h --- sys/net/if.h 15 Feb 2006 03:37:15 -0000 1.96.2.4 +++ sys/net/if.h 5 May 2006 23:05:57 -0000 @@ -254,6 +254,28 @@ #define IFAN_DEPARTURE 1 /* interface departure */ =20 /* + * Wake on Lan related options. + */ +struct if_wolopts { + uint32_t ifwol_supported;/* indicates wol capabilities */ + uint32_t ifwol_events; /* indicates desired wake events */ + + /* Supported wake on lan events. + * A given device may not support all of these, + * or even support wake events not listed here. + * If you add wake more events, make to sure to teach + * ifconfig about them too. */ +#define IFWOL_DISABLE 0x01 /* clears all other events */ +#define IFWOL_WAKE_ON_UNICAST 0x02 +#define IFWOL_WAKE_ON_MULTICAST 0x04 +#define IFWOL_WAKE_ON_BROADCAST 0x08 +#define IFWOL_WAKE_ON_MAGIC 0x10 /* wake on Magic Packet(tm) */ +#define IFWOL_ENABLE_SOPASSWD 0x20 /* whether to set SecureOn password */ + + u_char ifwol_sopasswd[6]; /* SecureOn password */ +}; + +/* * Interface request structure used for socket * ioctl's. All interface ioctl's must have parameter * definitions which begin with ifr_name. The @@ -265,6 +287,7 @@ struct sockaddr ifru_addr; struct sockaddr ifru_dstaddr; struct sockaddr ifru_broadaddr; + struct if_wolopts ifru_wolopts; short ifru_flags[2]; short ifru_index; int ifru_metric; @@ -277,6 +300,7 @@ #define ifr_addr ifr_ifru.ifru_addr /* address */ #define ifr_dstaddr ifr_ifru.ifru_dstaddr /* other end of p-to-p link */ #define ifr_broadaddr ifr_ifru.ifru_broadaddr /* broadcast address */ +#define ifr_wolopts ifr_ifru.ifru_wolopts /* wake on lan related options */ #define ifr_flags ifr_ifru.ifru_flags[0] /* flags (low 16 bits) */ #define ifr_flagshigh ifr_ifru.ifru_flags[1] /* flags (high 16 bits) */ #define ifr_metric ifr_ifru.ifru_metric /* metric */ Index: sys/pci/if_sis.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/local/ncvs/src/sys/pci/if_sis.c,v retrieving revision 1.132.2.7 diff -u -u -r1.132.2.7 if_sis.c --- sys/pci/if_sis.c 17 Mar 2006 21:30:57 -0000 1.132.2.7 +++ sys/pci/if_sis.c 5 May 2006 23:05:57 -0000 @@ -126,6 +126,10 @@ static void sis_startl(struct ifnet *); static void sis_stop(struct sis_softc *); static void sis_watchdog(struct ifnet *); +static void sis_get_wolopts(struct sis_softc *, struct if_wolopts *); +static int sis_set_wolopts(struct sis_softc *, struct if_wolopts *); +static void sis_enable_wol(struct sis_softc *); +static uint32_t sis_translate_wol_events(uint32_t); =20 #ifdef SIS_USEIOSPACE #define SIS_RES SYS_RES_IOPORT @@ -170,7 +174,7 @@ static void sis_dma_map_ring(void *arg, bus_dma_segment_t *segs, int nseg, int error) { - u_int32_t *p; + uint32_t *p; =20 p =3D arg; *p =3D segs->ds_addr; @@ -258,7 +262,7 @@ sis_eeprom_getword(struct sis_softc *sc, int addr, uint16_t *dest) { int i; - u_int16_t word =3D 0; + uint16_t word =3D 0; =20 /* Force EEPROM to idle state. */ sis_eeprom_idle(sc); @@ -301,11 +305,11 @@ sis_read_eeprom(struct sis_softc *sc, caddr_t dest, int off, int cnt, int = swap) { int i; - u_int16_t word =3D 0, *ptr; + uint16_t word =3D 0, *ptr; =20 for (i =3D 0; i < cnt; i++) { sis_eeprom_getword(sc, off + i, &word); - ptr =3D (u_int16_t *)(dest + (i * 2)); + ptr =3D (uint16_t *)(dest + (i * 2)); if (swap) *ptr =3D ntohs(word); else @@ -354,7 +358,7 @@ sis_read_cmos(struct sis_softc *sc, device_t dev, caddr_t dest, int off, i= nt cnt) { device_t bridge; - u_int8_t reg; + uint8_t reg; int i; bus_space_tag_t btag; =20 @@ -383,7 +387,7 @@ static void sis_read_mac(struct sis_softc *sc, device_t dev, caddr_t dest) { - u_int32_t filtsave, csrsave; + uint32_t filtsave, csrsave; =20 filtsave =3D CSR_READ_4(sc, SIS_RXFILT_CTL); csrsave =3D CSR_READ_4(sc, SIS_CSR); @@ -394,11 +398,11 @@ CSR_WRITE_4(sc, SIS_RXFILT_CTL, filtsave & ~SIS_RXFILTCTL_ENABLE); =20 CSR_WRITE_4(sc, SIS_RXFILT_CTL, SIS_FILTADDR_PAR0); - ((u_int16_t *)dest)[0] =3D CSR_READ_2(sc, SIS_RXFILT_DATA); + ((uint16_t *)dest)[0] =3D CSR_READ_2(sc, SIS_RXFILT_DATA); CSR_WRITE_4(sc, SIS_RXFILT_CTL,SIS_FILTADDR_PAR1); - ((u_int16_t *)dest)[1] =3D CSR_READ_2(sc, SIS_RXFILT_DATA); + ((uint16_t *)dest)[1] =3D CSR_READ_2(sc, SIS_RXFILT_DATA); CSR_WRITE_4(sc, SIS_RXFILT_CTL, SIS_FILTADDR_PAR2); - ((u_int16_t *)dest)[2] =3D CSR_READ_2(sc, SIS_RXFILT_DATA); + ((uint16_t *)dest)[2] =3D CSR_READ_2(sc, SIS_RXFILT_DATA); =20 CSR_WRITE_4(sc, SIS_RXFILT_CTL, filtsave); CSR_WRITE_4(sc, SIS_CSR, csrsave); @@ -731,7 +735,7 @@ { struct ifnet *ifp; struct ifmultiaddr *ifma; - u_int32_t h =3D 0, i, filtsave; + uint32_t h =3D 0, i, filtsave; int bit, index; =20 ifp =3D sc->sis_ifp; @@ -782,8 +786,8 @@ { struct ifnet *ifp; struct ifmultiaddr *ifma; - u_int32_t h, i, n, ctl; - u_int16_t hashes[16]; + uint32_t h, i, n, ctl; + uint16_t hashes[16]; =20 ifp =3D sc->sis_ifp; =20 @@ -984,7 +988,7 @@ * Why? Who the hell knows. */ { - u_int16_t tmp[4]; + uint16_t tmp[4]; =20 sis_read_eeprom(sc, (caddr_t)&tmp, NS_EE_NODEADDR, 4, 0); @@ -1406,7 +1410,7 @@ struct ifnet *ifp; struct sis_desc *cur_rx; int total_len =3D 0; - u_int32_t rxstat; + uint32_t rxstat; =20 SIS_LOCK_ASSERT(sc); =20 @@ -1501,7 +1505,7 @@ sis_txeof(struct sis_softc *sc) { struct ifnet *ifp; - u_int32_t idx; + uint32_t idx; =20 SIS_LOCK_ASSERT(sc); ifp =3D sc->sis_ifp; @@ -1605,7 +1609,7 @@ sis_startl(ifp); =20 if (sc->rxcycles > 0 || cmd =3D=3D POLL_AND_CHECK_STATUS) { - u_int32_t status; + uint32_t status; =20 /* Reading the ISR register clears all interrupts. */ status =3D CSR_READ_4(sc, SIS_ISR); @@ -1631,7 +1635,7 @@ { struct sis_softc *sc; struct ifnet *ifp; - u_int32_t status; + uint32_t status; =20 sc =3D arg; ifp =3D sc->sis_ifp; @@ -1785,7 +1789,7 @@ { struct sis_softc *sc; struct mbuf *m_head =3D NULL; - u_int32_t idx, queued =3D 0; + uint32_t idx, queued =3D 0; =20 sc =3D ifp->if_softc; =20 @@ -1872,23 +1876,23 @@ if (sc->sis_type =3D=3D SIS_TYPE_83815) { CSR_WRITE_4(sc, SIS_RXFILT_CTL, NS_FILTADDR_PAR0); CSR_WRITE_4(sc, SIS_RXFILT_DATA, - ((u_int16_t *)IFP2ENADDR(sc->sis_ifp))[0]); + ((uint16_t *)IFP2ENADDR(sc->sis_ifp))[0]); CSR_WRITE_4(sc, SIS_RXFILT_CTL, NS_FILTADDR_PAR1); CSR_WRITE_4(sc, SIS_RXFILT_DATA, - ((u_int16_t *)IFP2ENADDR(sc->sis_ifp))[1]); + ((uint16_t *)IFP2ENADDR(sc->sis_ifp))[1]); CSR_WRITE_4(sc, SIS_RXFILT_CTL, NS_FILTADDR_PAR2); CSR_WRITE_4(sc, SIS_RXFILT_DATA, - ((u_int16_t *)IFP2ENADDR(sc->sis_ifp))[2]); + ((uint16_t *)IFP2ENADDR(sc->sis_ifp))[2]); } else { CSR_WRITE_4(sc, SIS_RXFILT_CTL, SIS_FILTADDR_PAR0); CSR_WRITE_4(sc, SIS_RXFILT_DATA, - ((u_int16_t *)IFP2ENADDR(sc->sis_ifp))[0]); + ((uint16_t *)IFP2ENADDR(sc->sis_ifp))[0]); CSR_WRITE_4(sc, SIS_RXFILT_CTL, SIS_FILTADDR_PAR1); CSR_WRITE_4(sc, SIS_RXFILT_DATA, - ((u_int16_t *)IFP2ENADDR(sc->sis_ifp))[1]); + ((uint16_t *)IFP2ENADDR(sc->sis_ifp))[1]); CSR_WRITE_4(sc, SIS_RXFILT_CTL, SIS_FILTADDR_PAR2); CSR_WRITE_4(sc, SIS_RXFILT_DATA, - ((u_int16_t *)IFP2ENADDR(sc->sis_ifp))[2]); + ((uint16_t *)IFP2ENADDR(sc->sis_ifp))[2]); } =20 /* Init circular TX/RX lists. */ @@ -2162,6 +2166,21 @@ } #endif /* DEVICE_POLLING */ break; + case SIOCGIFWOLSUPP: + ifr->ifr_wolopts.ifwol_supported =3D NS_SUPPORTED_WOL_EVENTS; + error =3D 0; + break; + case SIOCGIFWOLOPTS: + SIS_LOCK(sc); + sis_get_wolopts(sc, &ifr->ifr_wolopts); + SIS_UNLOCK(sc); + error =3D 0; + break; + case SIOCSIFWOLOPTS: + SIS_LOCK(sc); + error =3D sis_set_wolopts(sc, &ifr->ifr_wolopts); + SIS_UNLOCK(sc); + break; default: error =3D ether_ioctl(ifp, command, data); break; @@ -2271,9 +2290,141 @@ SIS_LOCK(sc); sis_reset(sc); sis_stop(sc); + sis_enable_wol(sc); SIS_UNLOCK(sc); } =20 +/* + * Translate wake on lan events defined in if.h + * into flags the chip understands. + */ +static uint32_t +sis_translate_wol_events(uint32_t wol_events) +{ + uint32_t sis_wol_events =3D 0; +=09 + if (wol_events & IFWOL_WAKE_ON_UNICAST) + sis_wol_events |=3D NS_WCSR_WAKE_UCAST; + if (wol_events & IFWOL_WAKE_ON_MULTICAST) + sis_wol_events |=3D NS_WCSR_WAKE_MCAST; + if (wol_events & IFWOL_WAKE_ON_BROADCAST) + sis_wol_events |=3D NS_WCSR_WAKE_BCAST; + if (wol_events & IFWOL_WAKE_ON_MAGIC) + sis_wol_events |=3D NS_WCSR_WAKE_MAGIC; + + return sis_wol_events; +} + +/* + * Write current wake on lan settings into an if_wolopts structure. + * Note that the sopasswd field in the structure is cleared, because + * the password is confidential. + */ +static void +sis_get_wolopts(struct sis_softc *sc, struct if_wolopts *wolopts) +{ + int i; + + SIS_LOCK_ASSERT(sc); + + wolopts->ifwol_events =3D sc->ns_wol_events; +=09 + /* Do not disclose Secure On password. */ +#define N(a) (sizeof(a) / sizeof(a[0])) + for (i =3D 0; i < N(wolopts->ifwol_sopasswd); i++) + wolopts->ifwol_sopasswd[i] =3D '\0'; +#undef N +} +=09 +/* + * Set wake on lan options. + */ +static int +sis_set_wolopts(struct sis_softc *sc, struct if_wolopts *wolopts) +{ + SIS_LOCK_ASSERT(sc); + + /* FIXME: handle sopasswd */ + + if (wolopts->ifwol_events =3D=3D IFWOL_DISABLE) + sc->ns_wol_events =3D 0; + else { + if ((wolopts->ifwol_events & ~NS_SUPPORTED_WOL_EVENTS) !=3D 0) + return EINVAL; + sc->ns_wol_events =3D wolopts->ifwol_events; + } + + return 0; +} + +/*=20 + * Enable Wake On Lan on the DP83815, + * if any wake on lan options have been set. + */ +static void +sis_enable_wol(struct sis_softc *sc) +{ + SIS_LOCK_ASSERT(sc); +=09 + if (sc->sis_type !=3D SIS_TYPE_83815) + return; + + /* Check whether any wake on lan events have been set. */ + if (sc->ns_wol_events =3D=3D 0) + return; + + /* + * Configure the recieve filter to accept potential wake packets, + * configure wake events and enter low-power state. + */ + + /* Stop reciever. */ + SIS_SETBIT(sc, SIS_CSR, SIS_CSR_RX_DISABLE); +=09 + /* Reset recieve pointer */ + CSR_WRITE_4(sc, SIS_RX_LISTPTR, 0); + + /* Re-enable reciever (now in "silent recieve mode.") */ + SIS_SETBIT(sc, SIS_CSR, SIS_CSR_RX_ENABLE); + + /* Clear recieve filter register, so that the enable bit is unset. + * Other bits in this register can only be configured while the enable + * bit is zero. */ + CSR_WRITE_4(sc, SIS_RXFILT_CTL, 0); + + /*=20 + * Accept unicast packets. The datasheet seems to be inaccurate. + * It suggests simply setting the unicast bit in NS_RXFILTCTL, + * but this does not seem to work. Instead, we "perfect match" + * our own mac address, which makes the rx filter accept unicast + * packets. (section below copy pasted from sis_initl routine) + */ + CSR_WRITE_4(sc, SIS_RXFILT_CTL, NS_FILTADDR_PAR0); + CSR_WRITE_4(sc, SIS_RXFILT_DATA, + ((uint16_t *)IFP2ENADDR(sc->sis_ifp))[0]); + CSR_WRITE_4(sc, SIS_RXFILT_CTL, NS_FILTADDR_PAR1); + CSR_WRITE_4(sc, SIS_RXFILT_DATA, + ((uint16_t *)IFP2ENADDR(sc->sis_ifp))[1]); + CSR_WRITE_4(sc, SIS_RXFILT_CTL, NS_FILTADDR_PAR2); + CSR_WRITE_4(sc, SIS_RXFILT_DATA, + ((uint16_t *)IFP2ENADDR(sc->sis_ifp))[2]); + SIS_SETBIT(sc, SIS_RXFILT_CTL, NS_RXFILTCTL_PERFECT); + + /* Allow broadcast and multicast packets, too. */ + SIS_SETBIT(sc, SIS_RXFILT_CTL, SIS_RXFILTCTL_BROAD); + SIS_SETBIT(sc, SIS_RXFILT_CTL, SIS_RXFILTCTL_ALLMULTI); + + /* Re-enable RX filter. */ + SIS_SETBIT(sc, SIS_RXFILT_CTL, SIS_RXFILTCTL_ENABLE); + + /* Configure wake on lan events */ + CSR_WRITE_4(sc, NS_WCSR, sis_translate_wol_events(sc->ns_wol_events)); + + /* Set appropriate power state, so the card stays active + * after system shutdown. */ + CSR_WRITE_4(sc, NS_CLKRUN, NS_CLKRUN_PMESTS | NS_CLKRUN_PMEENB); +} + static device_method_t sis_methods[] =3D { /* Device interface */ DEVMETHOD(device_probe, sis_probe), Index: sys/pci/if_sisreg.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/local/ncvs/src/sys/pci/if_sisreg.h,v retrieving revision 1.33.2.1 diff -u -u -r1.33.2.1 if_sisreg.h --- sys/pci/if_sisreg.h 29 Sep 2005 18:52:21 -0000 1.33.2.1 +++ sys/pci/if_sisreg.h 6 May 2006 10:59:50 -0000 @@ -77,6 +77,7 @@ /* NS DP83815/6 registers */ #define NS_IHR 0x1C #define NS_CLKRUN 0x3C +#define NS_WCSR 0x40 #define NS_SRR 0x58 #define NS_BMCR 0x80 #define NS_BMSR 0x84 @@ -463,6 +464,7 @@ #endif int in_tick; struct mtx sis_mtx; + uint32_t ns_wol_events; }; =20 #define SIS_LOCK(_sc) mtx_lock(&(_sc)->sis_mtx) @@ -523,3 +525,17 @@ #define SIS_PSTATE_D3 0x0003 #define SIS_PME_EN 0x0010 #define SIS_PME_STATUS 0x8000 + +/* DP83815 pci config space power management register */ +#define NS_PMCSR 0x44 + +/* DP83815 Wake On Lan Command/Status register */ +#define NS_WCSR_WAKE_UCAST 0x00000002 +#define NS_WCSR_WAKE_MCAST 0x00000004 +#define NS_WCSR_WAKE_BCAST 0x00000008 +#define NS_WCSR_WAKE_MAGIC 0x00000200 + +/* FIXME: handle sopasswd */ +#define NS_SUPPORTED_WOL_EVENTS (IFWOL_WAKE_ON_UNICAST | IFWOL_WAKE_ON_MUL= TICAST \ + | IFWOL_WAKE_ON_BROADCAST | IFWOL_WAKE_ON_MAGIC) + Index: sys/pci/if_vr.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/local/ncvs/src/sys/pci/if_vr.c,v retrieving revision 1.104.2.6 diff -u -u -r1.104.2.6 if_vr.c --- sys/pci/if_vr.c 17 Mar 2006 21:30:57 -0000 1.104.2.6 +++ sys/pci/if_vr.c 13 Jun 2007 22:38:52 -0000 @@ -169,6 +169,10 @@ static int vr_list_rx_init(struct vr_softc *); static int vr_list_tx_init(struct vr_softc *); =20 +static int vr_set_wolopts(struct vr_softc *, struct if_wolopts *); +static void vr_get_wolopts(struct vr_softc *, struct if_wolopts *); +static void vr_enable_wol(struct vr_softc *); + #ifdef VR_USEIOSPACE #define VR_RES SYS_RES_IOPORT #define VR_RID VR_PCI_LOIO @@ -710,7 +714,7 @@ #endif =20 /* - * Windows may put the chip in suspend mode when it + * Windows or WOL may put the chip in suspend mode when it * shuts down. Be sure to kick it in the head to wake it * up again. */ @@ -761,6 +765,13 @@ =20 sc->suspended =3D 0; =20 + /* Check Wake on Lan support. */ + if (sc->vr_revid >=3D REV_ID_VT6102 ) { + sc->vr_wolsupport =3D 1; + if (sc->vr_revid >=3D REV_ID_VT6105_B0) + sc->vr_wol6patterns =3D 1; + } + /* Hook interrupt last to avoid having to lock softc */ error =3D bus_setup_intr(dev, sc->vr_irq, INTR_TYPE_NET | INTR_MPSAFE, vr_intr, sc, &sc->vr_intrhand); @@ -1618,6 +1629,21 @@ } #endif /* DEVICE_POLLING */ break; + case SIOCGIFWOLSUPP: + ifr->ifr_wolopts.ifwol_supported =3D VR_SUPPORTED_WOL_EVENTS; + error =3D 0; + break; + case SIOCGIFWOLOPTS: + VR_LOCK(sc); + vr_get_wolopts(sc, &ifr->ifr_wolopts); + VR_UNLOCK(sc); + error =3D 0; + break; + case SIOCSIFWOLOPTS: + VR_LOCK(sc); + error =3D vr_set_wolopts(sc, &ifr->ifr_wolopts); + VR_UNLOCK(sc); + break; default: error =3D ether_ioctl(ifp, command, data); break; @@ -1702,6 +1728,92 @@ static void vr_shutdown(device_t dev) { + struct vr_softc *sc; =20 + sc =3D device_get_softc(dev); + VR_LOCK(sc); + vr_enable_wol(sc); + VR_UNLOCK(sc); vr_detach(dev); } + +static void +vr_enable_wol(struct vr_softc *sc) +{ + VR_LOCK_ASSERT(sc); +=09 + /* Check whether wake on lan is available + * and whether events have been set. */ + if (!sc->vr_wolsupport || sc->vr_wolevents =3D=3D 0) + return; + + /* Set the chip to power state D0 */ + VR_CLRBIT(sc, VR_STICKHW, (VR_STICKHW_DS0|VR_STICKHW_DS1)); + + /* Clear WOL configuration */ + CSR_WRITE_1(sc, VR_WOLCRCLR, 0xFF); + if (sc->vr_wol6patterns) + CSR_WRITE_1(sc, VR_WOLCRCLR1, 0x03); + + /* Clear power-event status. */ + CSR_WRITE_1(sc, VR_PWRCSRCLR, 0xFF); + + /* Don't use extra patterns. */ + if (sc->vr_wol6patterns) + CSR_WRITE_1(sc, VR_WOLCGCLR, 0x04); +=09 + /* Set unicast wake event if applicable. */ + if (sc->vr_wolevents & IFWOL_WAKE_ON_UNICAST) + VR_SETBIT(sc, VR_WOLCRSET, VR_WAKE_UCAST); +=09 + /* Set magic wake event if applicable. */ + if (sc->vr_wolevents & IFWOL_WAKE_ON_MAGIC) { + VR_SETBIT(sc, VR_WOLCRSET, VR_WAKE_MAGIC); + /* enable EEPROM-controlled wake-up */ + VR_SETBIT(sc, VR_CONFIG, 0x03); + } +#if 0 + /* Set broadcast/multicast wake event if applicable. */ + /* Does not work for some reason :( */ + if (sc->vr_wolevents & IFWOL_WAKE_ON_BROADCAST || + sc->vr_wolevents & IFWOL_WAKE_ON_MULTICAST) + CSR_WRITE_1(sc, VR_WOLCGSET, VR_WAKE_BMCAST); +#endif + /* Enable Wake On Lan. */ + CSR_WRITE_1(sc, VR_PWCFGSET, 0x01); + VR_SETBIT(sc, VR_STICKHW, VR_STICKHW_WOL_ENB); + + /* Set power state to D3 */ + VR_SETBIT(sc, VR_STICKHW, (VR_STICKHW_DS0|VR_STICKHW_DS1)); +} + + +/* + * Write current wake on lan settings into an if_wolopts structure. + */ +static void +vr_get_wolopts(struct vr_softc *sc, struct if_wolopts *wolopts) +{ + VR_LOCK_ASSERT(sc); + wolopts->ifwol_events =3D sc->vr_wolevents; +} +=09 +/* + * Set wake on lan options. + */ +static int +vr_set_wolopts(struct vr_softc *sc, struct if_wolopts *wolopts) +{ + VR_LOCK_ASSERT(sc); + + if (wolopts->ifwol_events =3D=3D IFWOL_DISABLE) + sc->vr_wolevents =3D 0; + else { + if ((wolopts->ifwol_events & ~VR_SUPPORTED_WOL_EVENTS) !=3D 0) + return EINVAL; + sc->vr_wolevents =3D wolopts->ifwol_events; + } + + return 0; +} + Index: sys/pci/if_vrreg.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/local/ncvs/src/sys/pci/if_vrreg.h,v retrieving revision 1.22.2.1 diff -u -u -r1.22.2.1 if_vrreg.h --- sys/pci/if_vrreg.h 8 Nov 2005 16:05:56 -0000 1.22.2.1 +++ sys/pci/if_vrreg.h 13 Jun 2007 22:38:19 -0000 @@ -283,6 +283,21 @@ #define VR_STICKHW_WOL_STS 0x08 #define VR_STICKHW_LEGWOL_ENB 0x80 =20 +/* Wake on Lan definitions (snooped from Linux driver) */ +#define VR_WOLCRSET 0xA0 +#define VR_PWCFGSET 0xA1 +#define VR_WOLCGSET 0xA3 +#define VR_WOLCRCLR 0xA4 +#define VR_WOLCRCLR1 0xA6 +#define VR_WOLCGCLR 0xA7 +#define VR_PWRCSRCLR 0xAC +#define VR_WAKE_UCAST 0x10 +#define VR_WAKE_MAGIC 0x20 +#define VR_WAKE_BMCAST 0x30 +#define VR_WAKE_LINKON 0x40 +#define VR_WAKE_LINKOFF 0x80 +#define VR_SUPPORTED_WOL_EVENTS (IFWOL_WAKE_ON_UNICAST | IFWOL_WAKE_ON_MAG= IC) + /* * BCR0 register bits. (At least for the VT6102 chip.) */ @@ -471,6 +486,10 @@ #ifdef DEVICE_POLLING int rxcycles; #endif + int vr_wolsupport; /* Chip supports WOL. */ + uint32_t vr_wolevents; /* Wake on Lan satus */ + /* some chips have 6 "patterns" for WOL instead of 4 */ + int vr_wol6patterns; }; =20 #define VR_F_RESTART 0x01 /* Restart unit on next tick */ @@ -545,10 +564,14 @@ #define REV_ID_VT3065_A 0x40 #define REV_ID_VT3065_B 0x41 #define REV_ID_VT3065_C 0x42 +#define REV_ID_VT6102 0x40 #define REV_ID_VT6102_APOLLO 0x74 #define REV_ID_VT3106 0x80 #define REV_ID_VT3106_J 0x80 /* 0x80-0x8F */ #define REV_ID_VT3106_S 0x90 /* 0x90-0xA0 */ +#define REV_ID_VT6105 0x80 +#define REV_ID_VT6105_B0 0x83 + =20 /* * PCI low memory base and low I/O base register, and Index: sys/pci/if_xl.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/local/ncvs/src/sys/pci/if_xl.c,v retrieving revision 1.190.2.10 diff -u -u -r1.190.2.10 if_xl.c --- sys/pci/if_xl.c 17 Aug 2006 00:13:07 -0000 1.190.2.10 +++ sys/pci/if_xl.c 13 Jun 2007 23:00:35 -0000 @@ -249,6 +249,9 @@ static void xl_shutdown(device_t); static int xl_suspend(device_t); static int xl_resume(device_t); +static void xl_get_wolopts(struct xl_softc *, struct if_wolopts *); +static int xl_set_wolopts(struct xl_softc *, struct if_wolopts *); +static void xl_enable_wol(device_t dev); =20 #ifdef DEVICE_POLLING static void xl_poll(struct ifnet *ifp, enum poll_cmd cmd, int count); @@ -3218,6 +3221,25 @@ ifp->if_hwassist =3D 0; XL_UNLOCK(sc); break; + case SIOCGIFWOLSUPP: + if (sc->xl_type =3D=3D XL_TYPE_905B) + ifr->ifr_wolopts.ifwol_supported =3D + XL_SUPPORTED_WOL_EVENTS; + else + ifr->ifr_wolopts.ifwol_supported =3D 0; + error =3D 0; + break; + case SIOCGIFWOLOPTS: + XL_LOCK(sc); + xl_get_wolopts(sc, &ifr->ifr_wolopts); + XL_UNLOCK(sc); + error =3D 0; + break; + case SIOCSIFWOLOPTS: + XL_LOCK(sc); + error =3D xl_set_wolopts(sc, &ifr->ifr_wolopts); + XL_UNLOCK(sc); + break; default: error =3D ether_ioctl(ifp, command, data); break; @@ -3348,6 +3370,7 @@ XL_LOCK(sc); xl_reset(sc); xl_stop(sc); + xl_enable_wol(dev); XL_UNLOCK(sc); } =20 @@ -3384,3 +3407,80 @@ =20 return (0); } + +/* + * Write current wake on lan settings into an if_wolopts structure. + */ +static void +xl_get_wolopts(struct xl_softc *sc, struct if_wolopts *wolopts) +{ + XL_LOCK_ASSERT(sc); +=09 + if (sc->xl_type =3D=3D XL_TYPE_905B) + wolopts->ifwol_events =3D sc->xl_wol_events; + else + wolopts->ifwol_events =3D 0; +} + +/* + * Set wake on lan options. + */ +static int +xl_set_wolopts(struct xl_softc *sc, struct if_wolopts *wolopts) +{ + XL_LOCK_ASSERT(sc); + + if (sc->xl_type !=3D XL_TYPE_905B) + return ENOTSUP; + + if (wolopts->ifwol_events =3D=3D IFWOL_DISABLE) + sc->xl_wol_events =3D 0; + else { + if ((wolopts->ifwol_events & ~XL_SUPPORTED_WOL_EVENTS) !=3D 0) + return EINVAL; + sc->xl_wol_events =3D wolopts->ifwol_events; + } + + return 0; +} + +/*=20 + * Enable Wake On Lan if any wake on lan options have been set. + */ +static void +xl_enable_wol(device_t dev) +{ + u_int8_t rxfilt; + struct xl_softc *sc; + + sc =3D device_get_softc(dev); + + XL_LOCK_ASSERT(sc); + + if (sc->xl_type !=3D XL_TYPE_905B) + return; +=09 + /* Check whether any wake on lan events have been set. */ + if (sc->xl_wol_events =3D=3D 0) + return; + + /* Configure wake on lan events. */ + XL_SEL_WIN(7); + if (sc->xl_wol_events & IFWOL_WAKE_ON_MAGIC) + CSR_WRITE_2(sc, XL_W7_BM_WOL, XL_WAKE_ON_MAGIC); +=09 + /* Configure the recieve filter to accept WOL packets. + * We want to recieve everything. */ + XL_SEL_WIN(5); + rxfilt =3D CSR_READ_1(sc, XL_W5_RX_FILTER); + CSR_WRITE_1(sc, XL_W5_RX_FILTER, + rxfilt | XL_RXFILTER_INDIVIDUAL | XL_RXFILTER_ALLMULTI + | XL_RXFILTER_BROADCAST | XL_RXFILTER_ALLFRAMES); + + /* Make sure reciever is enabled. */ + CSR_WRITE_2(sc, XL_COMMAND, XL_CMD_RX_ENABLE); + + /* Set appropriate power state, so the card stays active + * after system shutdown. */ + pci_set_powerstate(dev, PCI_POWERSTATE_D3); +} Index: sys/pci/if_xlreg.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/local/ncvs/src/sys/pci/if_xlreg.h,v retrieving revision 1.55.2.1 diff -u -u -r1.55.2.1 if_xlreg.h --- sys/pci/if_xlreg.h 26 Aug 2005 14:46:22 -0000 1.55.2.1 +++ sys/pci/if_xlreg.h 13 Jun 2007 23:12:49 -0000 @@ -408,6 +408,7 @@ #define XL_W7_BM_LEN 0x06 #define XL_W7_BM_STATUS 0x0B #define XL_W7_BM_TIMEr 0x0A +#define XL_W7_BM_WOL 0x0C =20 /* * bus master control registers @@ -611,6 +612,7 @@ #ifdef DEVICE_POLLING int rxcycles; #endif + uint32_t xl_wol_events; }; =20 #define XL_LOCK(_sc) mtx_lock(&(_sc)->xl_mtx) @@ -739,3 +741,7 @@ #ifndef IFM_10_FL #define IFM_10_FL 13 /* 10baseFL - Fiber */ #endif + +#define XL_WAKE_ON_MAGIC 0x0002 +#define XL_SUPPORTED_WOL_EVENTS IFWOL_WAKE_ON_MAGIC + Index: sys/sys/sockio.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/local/ncvs/src/sys/sys/sockio.h,v retrieving revision 1.28.2.1 diff -u -u -r1.28.2.1 sockio.h --- sys/sys/sockio.h 15 Feb 2006 03:37:15 -0000 1.28.2.1 +++ sys/sys/sockio.h 5 May 2006 23:05:58 -0000 @@ -117,4 +117,11 @@ #define SIOCIFDESTROY _IOW('i', 121, struct ifreq) /* destroy clone if */ #define SIOCIFGCLONERS _IOWR('i', 120, struct if_clonereq) /* get cloners = */ =20 +#define SIOCGIFWOLOPTS _IOWR('i', 124, struct ifreq) /* get wake on lan + options */ +#define SIOCSIFWOLOPTS _IOW('i', 125, struct ifreq) /* set wake on lan + options */ +#define SIOCGIFWOLSUPP _IOWR('i', 126, struct ifreq) /* get wake on lan + modes supported by + device */ #endif /* !_SYS_SOCKIO_H_ */ --X1bOJ3K7DJ5YkBrT-- --s2ZSL+KKDSLx8OML Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGcHvf5dMCc/WdJfARAoD+AJ9EajUB3DOIafOuikyJt/7EJjAnDACg2NCC 4gZNYvE16OdgmRwfcrzM9BQ= =9bxq -----END PGP SIGNATURE----- --s2ZSL+KKDSLx8OML-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 14 00:52:48 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1931616A41F for ; Thu, 14 Jun 2007 00:52:48 +0000 (UTC) (envelope-from stephen@math.missouri.edu) Received: from math.missouri.edu (math.missouri.edu [128.206.184.200]) by mx1.freebsd.org (Postfix) with ESMTP id E06B613C468 for ; Thu, 14 Jun 2007 00:52:47 +0000 (UTC) (envelope-from stephen@math.missouri.edu) Received: from math.missouri.edu (localhost [127.0.0.1]) by math.missouri.edu (8.13.1/8.13.1) with ESMTP id l5E0qlWh028743; Wed, 13 Jun 2007 19:52:47 -0500 (CDT) (envelope-from stephen@math.missouri.edu) Received: from localhost (stephen@localhost) by math.missouri.edu (8.13.1/8.13.1/Submit) with ESMTP id l5E0qltf028740; Wed, 13 Jun 2007 19:52:47 -0500 (CDT) (envelope-from stephen@math.missouri.edu) Date: Wed, 13 Jun 2007 19:52:46 -0500 (CDT) From: Stephen Montgomery-Smith To: youshi10@u.washington.edu In-Reply-To: Message-ID: <20070613195143.G3312@math.missouri.edu> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: hackers@freebsd.org, Tim Kientzle Subject: Re: Using shell commands versus C equivalents X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2007 00:52:48 -0000 On Wed, 13 Jun 2007, youshi10@u.washington.edu wrote: > PS I'm looking at pkg_install and pkg_version mostly, but I'll be looking > into the other package utilities closely in the next couple weeks, evaluating > what approaches I should take in solving some bottlenecks with installing > packages and ports. My goals are up on > , and will be modified soon. Since you are interested in speeding up the pkg_* stuff, I thought I would bring these to your attention (speed ups to the pkg_create and port registration processes, not quite what you are doing, but related). http://www.freebsd.org/cgi/query-pr.cgi?pr=112765 http://www.freebsd.org/cgi/query-pr.cgi?pr=112630 Let me also wish you good luck in your speed improvements. I was rather encouraged by these two, but all my future searches proved somewhat negative. In particular I looked rather hard at trying to speed up "make" (required for pkg_version when it calls "make -V PKGNAME" multiple times). I can tell you that in that instance, replacing linear lists by berkeley DB made no difference at all - it was very disappointing. In short, you really want to do a lot of profiling and see where the speed bottlenecks really are before writing lots of code. Stephen From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 14 00:58:46 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1246816A468 for ; Thu, 14 Jun 2007 00:58:46 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by mx1.freebsd.org (Postfix) with ESMTP id E627413C458 for ; Thu, 14 Jun 2007 00:58:45 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from hymn01.u.washington.edu (hymn01.u.washington.edu [140.142.8.55]) by mxout4.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.05) with ESMTP id l5E0wjT3018751 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 13 Jun 2007 17:58:45 -0700 Received: from localhost (localhost [127.0.0.1]) by hymn01.u.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l5E0wjxT010360 for ; Wed, 13 Jun 2007 17:58:45 -0700 X-Auth-Received: from [192.55.52.1] by hymn01.u.washington.edu via HTTP; Wed, 13 Jun 2007 17:58:45 PDT Date: Wed, 13 Jun 2007 17:58:45 -0700 (PDT) From: youshi10@u.washington.edu To: hackers@freebsd.org In-Reply-To: <20070613195143.G3312@math.missouri.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.3.1.294258, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.6.13.173733 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='NO_REAL_NAME 0, __CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' Cc: Subject: Re: Using shell commands versus C equivalents X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2007 00:58:46 -0000 On Wed, 13 Jun 2007, Stephen Montgomery-Smith wrote: > > > On Wed, 13 Jun 2007, youshi10@u.washington.edu wrote: > >> PS I'm looking at pkg_install and pkg_version mostly, but I'll be looking >> into the other package utilities closely in the next couple weeks, >> evaluating what approaches I should take in solving some bottlenecks with >> installing packages and ports. My goals are up on >> , and will be modified soon. > > > Since you are interested in speeding up the pkg_* stuff, I thought I would > bring these to your attention (speed ups to the pkg_create and port > registration processes, not quite what you are doing, but related). > > http://www.freebsd.org/cgi/query-pr.cgi?pr=112765 > http://www.freebsd.org/cgi/query-pr.cgi?pr=112630 > > Let me also wish you good luck in your speed improvements. I was rather > encouraged by these two, but all my future searches proved somewhat negative. > In particular I looked rather hard at trying to speed up "make" (required for > pkg_version when it calls "make -V PKGNAME" multiple times). I can tell you > that in that instance, replacing linear lists by berkeley DB made no difference > at all - it was very disappointing. In short, you really want to do a lot of > profiling and see where the speed bottlenecks really are before writing lots of > code. > > Stephen Stephen, I have no control over the Makefile revisions, but I'll talk with Kirill about the pkg_* integration / testing, and be sure to note you on the change if it is integrated. I'll take your comments into consideration though :). -Garrett From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 14 03:34:20 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AF2A216A400 for ; Thu, 14 Jun 2007 03:34:20 +0000 (UTC) (envelope-from matthew@digitalstratum.com) Received: from mail.mundomateo.com (static-24-56-193-117.chrlmi.cablespeed.com [24.56.193.117]) by mx1.freebsd.org (Postfix) with ESMTP id 88E3213C447 for ; Thu, 14 Jun 2007 03:34:20 +0000 (UTC) (envelope-from matthew@digitalstratum.com) Received: from [10.0.81.13] (unknown [10.0.81.1]) by mail.mundomateo.com (Postfix) with ESMTP id ECF5DBDC45 for ; Wed, 13 Jun 2007 23:14:28 -0400 (EDT) Message-ID: <4670B27B.6060606@digitalstratum.com> Date: Wed, 13 Jun 2007 23:14:03 -0400 From: Matthew Hagerty Organization: Digital Stratum User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Disk block or sector to file mapping? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: matthew@digitalstratum.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2007 03:34:20 -0000 Greetings, I have a drive that failed and fsck and dump both report the failed sector or block (the term seems to be used interchangeably at times), but how can I find out what file(s) were using that block? I have a file-based backup and I could possibly replace the bad files if I know which ones were affected by the bad blocks. Thanks, Matthew From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 14 04:08:48 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9B61116A400 for ; Thu, 14 Jun 2007 04:08:48 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 8BEC513C447 for ; Thu, 14 Jun 2007 04:08:48 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 6ED151CC044; Wed, 13 Jun 2007 21:08:48 -0700 (PDT) Date: Wed, 13 Jun 2007 21:08:48 -0700 From: Jeremy Chadwick To: Matthew Hagerty Message-ID: <20070614040848.GA30741@eos.sc1.parodius.com> References: <4670B27B.6060606@digitalstratum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4670B27B.6060606@digitalstratum.com> User-Agent: Mutt/1.5.15 (2007-04-06) Cc: freebsd-hackers@freebsd.org Subject: Re: Disk block or sector to file mapping? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2007 04:08:48 -0000 On Wed, Jun 13, 2007 at 11:14:03PM -0400, Matthew Hagerty wrote: > Greetings, > > I have a drive that failed and fsck and dump both report the failed sector > or block (the term seems to be used interchangeably at times), but how can I > find out what file(s) were using that block? I have a file-based backup and > I could possibly replace the bad files if I know which ones were affected by > the bad blocks. There's apparently a way to work out what block on the disk is used by a specific inode using some math and numerous parameters taken from the drive, filesystems, and other such things. It might be mentioned in the URL I've included below (for Linux though, not BSD), so I'd peek there. Anyways, I'd do the following: * Run the disk manufacturer's native disk analysis utility. Many of them will do some extra magic (particularly for PATA/SATA disks; with SCSI there's no magic, you can do it yourself by manipulating the grown defect list) to try and work around a full bad block/remapped sector list. Besides, when RMA'ing the disk, the manu. will usually ask if you've run their analysis tool and what the result was. * You might be able to use smartctl (ports/sysutils/smartmontools) to run a selective LBA test (smartctl -t select,X-Y /dev/adN, where X-Y are starting and ending LBAs to do checks on). Not all drives support this though. If select isn't permitted, you can try -t long which should work on most disks, but scans the entire disk (takes a long time). Then you can use smartctl -a /dev/adN and see if the last test you ran was successful or if an error was encountered, hopefully what LBA it's at. This document might also come in handy: http://smartmontools.sourceforge.net/badblockhowto.html * There's also ports/sysutils/drivecheckd which I've never used, but looks like it might possibly provide more detailed info. * The purpose of doing any of the above is to try and get the drive mark the block in question as bad, thus not access it any longer. It may have already done that when the OS reported an issue[1]. That should (hopefully) cause fsck to notice inconsistencies in filesystem data, and give you a filename that used the aforementioned block, telling you the file is inaccessible or should move to lost+found and so on. (I'm sure someone will correct me on the last part :) ) * Now try fsck -f on each unmounted filesystem and see if any errors come up, with filenames referenced. Realistically, what we need on FreeBSD is a tool similar to Solaris's format(8) "analyze" command, which does a raw disk scan (r, r/w, and a couple other operations). For those not familiar with it, I'll include a sample session of a disk being analysed at the bottom of this Email. Sorry if this is too verbose, but I quite often deal with disks going bad during my day job. [1] - If the OS is seeing bad blocks on a PATA/SATA disk, usually it means that the internal remapping table is full, which means that there were other bad blocks on the disk which it has silently remapped for you to avoid pain -- and space for those blocks has been exhausted. Sometimes you can work around this as mentioned, but most of the time you can't, and you're stuck simply replacing the disk entirely. Bad blocks have a tendency to spread too... -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | bash# format Searching for disks...done AVAILABLE DISK SELECTIONS: 0. c0t0d0 /pci@0,0/pci8086,2543@2/pci8086,1460@1d/pci9005,ffff@4/sd@0,0 Specify disk (enter its number): 0 selecting c0t0d0 [disk formatted] Warning: Current Disk has mounted partitions. FORMAT MENU: disk - select a disk type - select (define) a disk type partition - select (define) a partition table current - describe the current disk format - format and analyze the disk fdisk - run the fdisk program repair - repair a defective sector label - write label to the disk analyze - surface analysis defect - defect list management backup - search for backup labels verify - read and display labels save - save new disk/partition definitions inquiry - show vendor, product and revision volname - set 8-character volume name ! - execute , then return quit format> analyze ANALYZE MENU: read - read only test (doesn't harm SunOS) refresh - read then write (doesn't harm data) test - pattern testing (doesn't harm data) write - write then read (corrupts data) compare - write, read, compare (corrupts data) purge - write, read, write (corrupts data) verify - write entire disk, then verify (corrupts data) print - display data buffer setup - set analysis parameters config - show analysis parameters ! - execute , then return quit analyze> setup Analyze entire disk[yes]? Loop continuously[no]? Enter number of passes[2]: Repair defective blocks[yes]? Stop after first error[no]? yes Use random bit patterns[no]? yes Enter number of blocks per transfer[126, 0/2/0]: Verify media after formatting[yes]? Enable extended messages[no]? Restore defect list[yes]? Restore disk label[yes]? analyze> read Ready to analyze (won't harm SunOS). This takes a long time, but is interruptable with CTRL-C. Continue? y pass 0 ^C 17/59/0 Total of 0 defective blocks repaired. analyze> From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 14 04:53:45 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0262E16A41F; Thu, 14 Jun 2007 04:53:45 +0000 (UTC) (envelope-from ulf@alameda.net) Received: from mail.alameda.net (mail.alameda.net [64.81.53.120]) by mx1.freebsd.org (Postfix) with ESMTP id D35D913C45A; Thu, 14 Jun 2007 04:53:44 +0000 (UTC) (envelope-from ulf@alameda.net) Received: by mail.alameda.net (Postfix, from userid 1000) id 4D04833CF4; Wed, 13 Jun 2007 21:22:15 -0700 (PDT) Date: Wed, 13 Jun 2007 21:22:15 -0700 From: Ulf Zimmermann To: Mark Saad Message-ID: <20070614042214.GE90777@evil.alameda.net> References: <20070611151747.W51099@ns1.feral.com> <20070611151903.P51099@ns1.feral.com> <466DCE30.5020009@datapipe.com> <20070611224841.GA2484@freebie.xs4all.nl> <466DD2FE.5040809@datapipe.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <466DD2FE.5040809@datapipe.com> User-Agent: Mutt/1.4.2.2i Organization: Alameda Networks, Inc. X-Operating-System: FreeBSD 5.3-STABLE X-ANI-MailScanner-Information: Please contact the ISP for more information X-ANI-MailScanner: Found to be clean X-ANI-MailScanner-From: ulf@alameda.net Cc: Wilko Bulte , Joao Barros , mjacob@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: HP SmartArray ( CISS ) and CAMCONTROL X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ulf@Alameda.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2007 04:53:45 -0000 On Mon, Jun 11, 2007 at 06:55:58PM -0400, Mark Saad wrote: > Wilko > Thats great to hear hpacucli and hpasm would rock. > > Wilko Bulte wrote: > >On Mon, Jun 11, 2007 at 06:35:28PM -0400, Mark Saad wrote.. > >>Matt > >> What will raidutill offer ? Also does anyone know if HP provides > >>hpacucli for FreeBSD ,but only to Japanese customers ? > > > >Well.. we just landed ourselves a new committer from HP India who > >is sponsored by HP ISS in Houston to provide (binary only) Proliant > >mgmt / monitoring tools for FreeBSD. > > > >In due time you will see his work I imagine. I hope this will > >be the start of a fruitful vendor support. > > Wooohohohohohooh! I would love to see those. It would give me reason to convert some linux boxes to FreeBSD. > > > -- > Mark Saad > Managed UNIX Support > DataPipe Managed Global IT Services > msaad@datapipe.com > 1.201.792.4847 (international) > 1.888.749.5821 (toll free) > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > -- Regards, Ulf. --------------------------------------------------------------------- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-865-0204 You can find my resume at: http://www.Alameda.net/~ulf/resume.html From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 14 04:56:51 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8BBA916A41F for ; Thu, 14 Jun 2007 04:56:51 +0000 (UTC) (envelope-from citrin@citrin.ru) Received: from mail.classis.ru (classis.ru [213.248.60.120]) by mx1.freebsd.org (Postfix) with ESMTP id D73F413C48C for ; Thu, 14 Jun 2007 04:56:50 +0000 (UTC) (envelope-from citrin@citrin.ru) Received: from CITRIN (ppp12-190.pppoe.mtu-net.ru [81.195.12.190]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: citrin.citrin.ru) by mail.classis.ru (Postfix) with ESMTP id B1F15122207F; Thu, 14 Jun 2007 08:46:05 +0400 (MSD) Date: Thu, 14 Jun 2007 08:46:02 +0400 From: Anton Yuzhaninov X-Mailer: The Bat! (v3.62.14) Professional Organization: Rambler X-Priority: 3 (Normal) Message-ID: <785068457.20070614084602@citrin.ru> To: Matthew Hagerty In-Reply-To: <4670B27B.6060606@digitalstratum.com> References: <4670B27B.6060606@digitalstratum.com> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="----------F31DD18F344C2B4C" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: Disk block or sector to file mapping? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2007 04:56:51 -0000 This is a cryptographically signed message in MIME format. ------------F31DD18F344C2B4C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hello Matthew, You wrote on Thursday, June 14, 2007, 7:14:03 AM: MH> I have a drive that failed and fsck and dump both report the failed=20 MH> sector or block (the term seems to be used interchangeably at times),= =20 MH> but how can I find out what file(s) were using that block? fsdb findblk disk_block_number --=20 Anton Yuzhaninov. ------------F31DD18F344C2B4C-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 14 05:30:34 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4B62316A46C for ; Thu, 14 Jun 2007 05:30:34 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from kientzle.com (h-66-166-149-50.snvacaid.covad.net [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id 2AD4513C448 for ; Thu, 14 Jun 2007 05:30:33 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from [10.0.0.222] (p54.kientzle.com [66.166.149.54]) by kientzle.com (8.12.9/8.12.9) with ESMTP id l5E5USH7074725; Wed, 13 Jun 2007 22:30:29 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <4670D274.60902@freebsd.org> Date: Wed, 13 Jun 2007 22:30:28 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060422 X-Accept-Language: en-us, en MIME-Version: 1.0 To: youshi10@u.washington.edu References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org Subject: Re: Using shell commands versus C equivalents X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2007 05:30:34 -0000 >> I spent a lot of time recently in libarchive/bsdtar optimizing >> the disk handling; I can share lots of ideas for improving >> performance of disk-bound operations like this. One thing you might find useful: libarchive has an API for "creating things on disk," which handles a lot of trivia (creating parent directories transparently, restoring permissions, users, file flags, etc.). It is, of course, especially useful if you're pulling things out of tar archives, but can be used separately from that. Since libarchive is a standard part of FreeBSD, you should feel free to use it. Tim K From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 14 07:54:44 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2DA9816A41F for ; Thu, 14 Jun 2007 07:54:44 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (vlk.vlakno.cz [62.168.28.247]) by mx1.freebsd.org (Postfix) with ESMTP id E15F213C447 for ; Thu, 14 Jun 2007 07:54:43 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id EEB998BE229 for ; Thu, 14 Jun 2007 09:54:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (vlk.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PcC6RrwvrsY0 for ; Thu, 14 Jun 2007 09:54:40 +0200 (CEST) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id A80B58BDBE9 for ; Thu, 14 Jun 2007 09:54:40 +0200 (CEST) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.13.8/8.13.8/Submit) id l5E7se9l071785 for hackers@freebsd.org; Thu, 14 Jun 2007 09:54:40 +0200 (CEST) (envelope-from rdivacky) Date: Thu, 14 Jun 2007 09:54:39 +0200 From: Roman Divacky To: hackers@freebsd.org Message-ID: <20070614075439.GA71601@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: [PATCH]: acct_process() locking and exit1() X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2007 07:54:44 -0000 hi currently in exit1() we call acct_process() with Giant held. I looked at the code and I think this is because of tty need for Giant locking. Because of this we have to release process limit in a separate PROC_LOCK()/UNLOCK() block. my just-to-look-at patch does this 1) moves the acct_process() in exit1() out of Giant locked block (upward) 2) acquires Giant in the acct_process() around tty handling 3) moves the p->p_limit to a different PROC_LOCK/UNLOCK block (upward) the result is saving 2 proc mtx operations in exit1() can you look at it and tell me if its correct or wrong or something like that? if it's correct is it worth committing? saving two mtx operations is a nice thing :) thank you roman From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 14 07:58:32 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6403E16A468 for ; Thu, 14 Jun 2007 07:58:32 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (vlk.vlakno.cz [62.168.28.247]) by mx1.freebsd.org (Postfix) with ESMTP id 20BBF13C455 for ; Thu, 14 Jun 2007 07:58:32 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 478EC8BE22B for ; Thu, 14 Jun 2007 09:58:31 +0200 (CEST) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (vlk.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aAWHtJ1C+FBO for ; Thu, 14 Jun 2007 09:58:30 +0200 (CEST) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 558FB8BE22E for ; Thu, 14 Jun 2007 09:58:30 +0200 (CEST) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.13.8/8.13.8/Submit) id l5E7wUFX071984 for hackers@freebsd.org; Thu, 14 Jun 2007 09:58:30 +0200 (CEST) (envelope-from rdivacky) Date: Thu, 14 Jun 2007 09:58:30 +0200 From: Roman Divacky To: hackers@freebsd.org Message-ID: <20070614075830.GA71887@freebsd.org> References: <20070614075439.GA71601@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070614075439.GA71601@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: Subject: Re: [PATCH]: acct_process() locking and exit1() X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2007 07:58:32 -0000 On Thu, Jun 14, 2007 at 09:54:39AM +0200, Roman Divacky wrote: > hi > > currently in exit1() we call acct_process() with Giant held. > I looked at the code and I think this is because of tty need > for Giant locking. Because of this we have to release process limit > in a separate PROC_LOCK()/UNLOCK() block. > > my just-to-look-at patch does this > > 1) moves the acct_process() in exit1() out of Giant locked block (upward) > 2) acquires Giant in the acct_process() around tty handling > 3) moves the p->p_limit to a different PROC_LOCK/UNLOCK block (upward) > > the result is saving 2 proc mtx operations in exit1() > > can you look at it and tell me if its correct or wrong or something like that? > > if it's correct is it worth committing? saving two mtx operations is a nice thing :) erm... two bugs ;) "saving two mtx operations..." in the typical case of accounting NOT being enabled. and forgot to show the patch ;) it's here www.vlakno.cz/~rdivacky/kern_acct.patch From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 14 08:08:08 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0EE4F16A41F for ; Thu, 14 Jun 2007 08:08:08 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.freebsd.org (Postfix) with ESMTP id BD77B13C4B7 for ; Thu, 14 Jun 2007 08:08:07 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1HykNA-000DN3-7A; Thu, 14 Jun 2007 11:08:04 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Garrett Cooper In-reply-to: <46700CAE.6020902@u.washington.edu> References: <466F86C6.7010006@u.washington.edu> <20070613123213.GE98927@bunrab.catwhisker.org> <46700CAE.6020902@u.washington.edu> Comments: In-reply-to Garrett Cooper message dated "Wed, 13 Jun 2007 08:26:38 -0700." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 14 Jun 2007 11:08:04 +0300 From: Danny Braniss Message-ID: Cc: hackers@freebsd.org Subject: Re: Using shell commands versus C equivalents X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2007 08:08:08 -0000 ... > Sorry -- actually I meant that (along similar lines), there was a > program with the following lines: > > vsystem("/bin/chmod +x %s", filename); > > and I replaced it with: > > chmod(filename, (mode_t) ( S_IXUSR | S_IXGRP | S_IXOTH )); > > Probably won't yield much gain overall, but every drop counts and there > are quite a few iterations performed in the pkg_* programs, in > particular dealing with X.org. chmod is one(1) system call, while system is many, for starters it's fork/exec, which btw, is quiet expensive, haven't counted, but my gut feeling it's in the 10s. So, if the program does this chmod once in a blue moon, there is no real argument, but if id does it many times, then one system call is a real winner, danny From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 14 08:52:33 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 25B7616A46B for ; Thu, 14 Jun 2007 08:52:33 +0000 (UTC) (envelope-from redcrash@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.226]) by mx1.freebsd.org (Postfix) with ESMTP id CB83C13C4B7 for ; Thu, 14 Jun 2007 08:52:32 +0000 (UTC) (envelope-from redcrash@gmail.com) Received: by wr-out-0506.google.com with SMTP id 70so387836wra for ; Thu, 14 Jun 2007 01:52:32 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=ktsd1cdOmRcwi3SJcVqqiJGhjWbsxSS3ealvSCD0OgtpF5Zw49VAbXRpwTGv0Wotv42Iw6mao3Q4PQezTgIkowN22EbQLeF74ES4utfyM8mtApEI0960mSYyJ0QL22sSzJoGbvGfPuWG1LcnI66g1OasDBypS2dUu9m89MY/m3E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=gqYiaJlyn4II1Hw/JUkgr/BgsI0hcaa/jD+EJmigJAqTcu67LWyxMcFWdNwV9xqdvoXkaN/suM1iS96u3+QsT4hoo+X43P4ujux3843Aycr00yXQdivI9mmDZH0AIaoSpBeAGj7ntCoLUyZo3ghjGPIOQo+GGLeIgDA+pczqxcs= Received: by 10.100.227.5 with SMTP id z5mr935252ang.1181811152095; Thu, 14 Jun 2007 01:52:32 -0700 (PDT) Received: by 10.100.141.3 with HTTP; Thu, 14 Jun 2007 01:52:32 -0700 (PDT) Message-ID: Date: Thu, 14 Jun 2007 10:52:32 +0200 From: "Harald Servat" To: freebsd-hackers@freebsd.org, freebsd-performance@freebsd.org, freebsd-hpc@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: PAPI in the ports X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2007 08:52:33 -0000 Hello, I'm glad to announce you that PAPI-3.5.0 has reached the FreeBSD ports tree and now it's generally available for all FreeBSD users. Port information is available at http://www.freebsd.org/cgi/ports.cgi?query=papi&stype=all&sektion=devel See http://code.google.com/p/papi-for-freebsd/wiki/HowToInstall for installation instructions. There are some issues with P4 processors that need to be fixed on PAPI_write / PAPI_reset routines, but the package have the minimal (and most important functionality) working fine for the rest of the substrates. Regards, -- _________________________________________________________________ Empty your memory, with a free()... like a pointer! If you cast a pointer to an integer, it becomes an integer, if you cast a pointer to a struct, it becomes a struct. The pointer can crash..., and can overflow. Be a pointer my friend... From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 14 08:02:10 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AF8D316A41F for ; Thu, 14 Jun 2007 08:02:10 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id 6841213C448 for ; Thu, 14 Jun 2007 08:02:10 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A5D884.dip.t-dialin.net [84.165.216.132]) by redbull.bpaserver.net (Postfix) with ESMTP id 4D16A2E23E; Thu, 14 Jun 2007 10:02:06 +0200 (CEST) Received: from webmail.leidinger.net (webmail.Leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 9E3075B490D; Thu, 14 Jun 2007 10:01:48 +0200 (CEST) Received: (from www@localhost) by webmail.leidinger.net (8.13.8/8.13.8/Submit) id l5E81mA2046018; Thu, 14 Jun 2007 10:01:48 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Thu, 14 Jun 2007 10:01:48 +0200 Message-ID: <20070614100148.1786o1akz4oss4g0@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Thu, 14 Jun 2007 10:01:48 +0200 From: Alexander Leidinger To: youshi10@u.washington.edu References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.4) / FreeBSD-7.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=2.519, required 8, DKIM_POLICY_SIGNSOME 0.00, J_CHICKENPOX_32 0.60, MIME_QP_LONG_LINE 1.82, RDNS_DYNAMIC 0.10) X-BPAnet-MailScanner-SpamScore: ss X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No X-Mailman-Approved-At: Thu, 14 Jun 2007 11:31:55 +0000 Cc: hackers@freebsd.org Subject: Re: Using shell commands versus C equivalents X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2007 08:02:10 -0000 Quoting youshi10@u.washington.edu (from Wed, 13 Jun 2007 14:17:18 =20 -0700 (PDT)): > On Wed, 13 Jun 2007, Rick C. Petty wrote: >> Now another question is whether the pkg_* tools can handle multiple >> processes managing the ports at the same time. For the mostpart, this is >> true. Without looking at the code, I would expect that the only >> contentions would be when trying to update the +REQUIRED_BY files. >> Everything else should be just fine; you're not supposed to be installin= g >> the same port multiple times at the exact same time, but maybe a lock cou= ld >> be held on the package directory (i.e. /var/db/pkg/$PKG_NAME). Again, I >> don't believe this is strictly necessary. > > Currently, no, and this is a condition that's contingent for a fellow > SoC'er's project. The mentor said that all that *should* occur is there > should be an flock, but that was it. So instead of making more work for > him and since I am modifying pkg_* already, I thought it would be best > to just make my modifications to simplify his end (he still has a ways > to go on the dependency tracking I think). > > It goes a bit deeper than the +REQUIRED_BY files, in particular with > the +CONTENTS, etc files as the pkg_* tools are enumerating the > packages currently on the system, their dependencies, owning files, > etc. Perhaps a global .lock file of some kind in the package > directories would be the way to go though. Stephen already pointed out the patches which speed up pkg_create and =20 bsd.port.mk. I want to highlight the bsd.port.mk change which takes =20 the package dependency info from the +CONTENTS file. So any changes by =20 the other student should take this into account... Bye, Alexander. --=20 Some rise by sin and some by virtue fall. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 14 16:17:04 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C2B9616A475 for ; Thu, 14 Jun 2007 16:17:04 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 7958513C468 for ; Thu, 14 Jun 2007 16:17:03 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Hyrzz-0006FD-Dc for freebsd-hackers@freebsd.org; Thu, 14 Jun 2007 18:16:40 +0200 Received: from 78-0-71-116.adsl.net.t-com.hr ([78.0.71.116]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 14 Jun 2007 18:16:39 +0200 Received: from ivoras by 78-0-71-116.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 14 Jun 2007 18:16:39 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Date: Thu, 14 Jun 2007 18:16:17 +0200 Lines: 32 Message-ID: References: <20070613080334.GR89502@hoeg.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6B7B45A5406C5DD96ADE7C60" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 78-0-71-116.adsl.net.t-com.hr User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) In-Reply-To: X-Enigmail-Version: 0.94.3.0 Sender: news Subject: Re: Reason for doing malloc / bzero over calloc (performance)? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2007 16:17:04 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6B7B45A5406C5DD96ADE7C60 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable youshi10@u.washington.edu wrote: > Hmmm... I wonder what the Mach kernel in OSX does to allocate memory > then. I'll have to take a look at OpenDarwin's source sometime and see > what it does. Following the link chain from the benchmark link posted in this thread I've come to the information that it's similar to -CURRENT: small allocations are carved from the local pool, big ones from prezeroed pages (from kernel). --------------enig6B7B45A5406C5DD96ADE7C60 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.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGcWnWldnAQVacBcgRAjZRAKDdNOcmX6zaUuNUqN9gVsN2jQ0TkQCgpHa4 E6oL4kOgo2bBffzDHmPZRKk= =OUXN -----END PGP SIGNATURE----- --------------enig6B7B45A5406C5DD96ADE7C60-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 14 17:04:30 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D562D16A400 for ; Thu, 14 Jun 2007 17:04:30 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by mx1.freebsd.org (Postfix) with ESMTP id B51FB13C457 for ; Thu, 14 Jun 2007 17:04:30 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from hymn01.u.washington.edu (hymn01.u.washington.edu [140.142.8.55]) by mxout1.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.05) with ESMTP id l5EH4RQa027123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Jun 2007 10:04:27 -0700 Received: from localhost (localhost [127.0.0.1]) by hymn01.u.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l5EH4QD8014467; Thu, 14 Jun 2007 10:04:26 -0700 X-Auth-Received: from [192.55.52.1] by hymn01.u.washington.edu via HTTP; Thu, 14 Jun 2007 10:04:26 PDT Date: Thu, 14 Jun 2007 10:04:26 -0700 (PDT) From: youshi10@u.washington.edu To: Ivan Voras In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.3.1.294258, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.6.14.94833 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='NO_REAL_NAME 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' Cc: hackers@freebsd.org Subject: Re: Reason for doing malloc / bzero over calloc (performance)? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2007 17:04:30 -0000 On Thu, 14 Jun 2007, Ivan Voras wrote: > youshi10@u.washington.edu wrote: > >> Hmmm... I wonder what the Mach kernel in OSX does to allocate memory >> then. I'll have to take a look at OpenDarwin's source sometime and see >> what it does. > > Following the link chain from the benchmark link posted in this thread > I've come to the information that it's similar to -CURRENT: small > allocations are carved from the local pool, big ones from prezeroed > pages (from kernel). > > Do you know if that's with malloc or calloc? What portion of the source demonstrates this? -Garrett From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 14 22:14:11 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6096416A468 for ; Thu, 14 Jun 2007 22:14:11 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id DC08613C487 for ; Thu, 14 Jun 2007 22:14:10 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HyxZU-0007fj-SC for freebsd-hackers@freebsd.org; Fri, 15 Jun 2007 00:13:41 +0200 Received: from 89-172-58-72.adsl.net.t-com.hr ([89.172.58.72]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 15 Jun 2007 00:13:40 +0200 Received: from ivoras by 89-172-58-72.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 15 Jun 2007 00:13:40 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Date: Fri, 15 Jun 2007 00:12:15 +0200 Lines: 70 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0B4229BF4F16084D61EAAD3A" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 89-172-58-72.adsl.net.t-com.hr User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) In-Reply-To: X-Enigmail-Version: 0.94.3.0 Sender: news Subject: Re: Reason for doing malloc / bzero over calloc (performance)? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2007 22:14:11 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0B4229BF4F16084D61EAAD3A Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable youshi10@u.washington.edu wrote: > Do you know if that's with malloc or calloc? What portion of the source= > demonstrates this? No source, but here's a quote from http://boredzo.org/blog/archives/2006-11-26/calloc-vs-malloc: For large blocks (where "large" is surprisingly small, something like 14 KB) Mac OS X's default malloc() will always go to the kernel for memory by calling vm_allocate(). vm_allocate() always returns zero-filled pages; otherwise, you might get back a chunk of physical RAM or swap space that had been written to by some root process, and you'd get privileged data. So for large blocks, we'd expect calloc() and malloc() to perform identically. Mach will reserve some memory but not physically allocate it until you read or write it. The pages can also be marked zero filled without having to write zeros to RAM. But the first time you read from the page, it has to allocate and then zero-fill it. Google lead me to this: http://developer.apple.com/documentation/Performance/Conceptual/ManagingM= emory/Articles/MemoryAlloc.html It's not conclusive: For allocations greater than a few virtual memory pages, malloc uses the vm_allocate routine to obtain a block of the requested size.The vm_allocate routine assigns an address range to the new block in the virtual memory space of the current process but does not allocate any physical memory. Instead, the malloc routine pages in the memory for the allocated block as it is used. The granularity of large memory blocks is 4096 bytes, the size of a virtual memory page. If you are allocating a large memory buffer, you should consider making it a multiple of this size. Note: Large memory allocations are guaranteed to be page-aligned. but: The calloc routine reserves the required virtual address space for the memory but waits until the memory is actually used before initializing it. This approach alleviates the need to map the pages into memory right away. It also lets the system initialize pages as they=E2=80=99re used, a= s opposed to all at once. --------------enig0B4229BF4F16084D61EAAD3A 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.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGcb1FldnAQVacBcgRAu8rAKCdVT4GhEK/il596F8qTt9t2wWGzACgi+cw IEr4q4KFdO3zC4dRIfCFmng= =spKr -----END PGP SIGNATURE----- --------------enig0B4229BF4F16084D61EAAD3A-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 15 01:04:34 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 809DF16A400 for ; Fri, 15 Jun 2007 01:04:34 +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 6901213C45A for ; Fri, 15 Jun 2007 01:04:34 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.13.8/8.13.7) with ESMTP id l5F14RET001011; Thu, 14 Jun 2007 18:04:27 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.13.8/8.13.4/Submit) id l5F14RjG001010; Thu, 14 Jun 2007 18:04:27 -0700 (PDT) Date: Thu, 14 Jun 2007 18:04:27 -0700 (PDT) From: Matthew Dillon Message-Id: <200706150104.l5F14RjG001010@apollo.backplane.com> To: Ivan Voras References: Cc: freebsd-hackers@freebsd.org Subject: Re: Reason for doing malloc / bzero over calloc (performance)? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2007 01:04:34 -0000 I'm going to throw a wrench in the works, because it all gets turned around the moment you find yourself in a SMP environment where several threads are running on different cpus at the same time, using the same shared VM space. The moment you have a situation like that where you are futzing with the page tables, i.e. using mmap() for demand-zero and munmap() to free, the operation becomes extremely expensive verses anything else because any update to the page table (specifically any removal of page table entries from the page table) requires a SMP synchronization to occur between all the cpu's actively sharing that VM space, and that's on top of the overhead of taking the page fault(s). This is true of any memory mapping the kernel has to do in kernel virtual memory (must be synchronized with ALL cpus) and any mapping the kernel does on behalf of userland for user memory (must be synchronized with any cpu's actively using that VM space, i.e. threaded user programs). The synchronization is required to properly invalidate stale mappings on other cpus and it must be done synchronously due to bugs in Intel/AMD related to changing page table entries on one cpu when instructions are executing using that memory on another cpu. There is no way to avoid it without tripping up on the Intel/AMD hardware bugs. From this point of view it is much, much better to bzero() memory that is already mapped then it is to map/unmap new memory. I recently audited DragonFly and found an insane number of IPIs flying about due to PAGE_SIZE'd kernel mallocs using the VM trick via kernel_map & kmem_alloc(). They all went away when I made the kernel malloc use the slab cache for allocations up to and including PAGE_SIZE*2 bytes. Fun, eh? -Matt Matthew Dillon From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 15 01:10:53 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 690BD16A41F for ; Fri, 15 Jun 2007 01:10:53 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout7.cac.washington.edu (mxout7.cac.washington.edu [140.142.32.178]) by mx1.freebsd.org (Postfix) with ESMTP id 4A2C213C468 for ; Fri, 15 Jun 2007 01:10:53 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from hymn01.u.washington.edu (hymn01.u.washington.edu [140.142.8.55]) by mxout7.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.05) with ESMTP id l5F1AnoN002145 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Jun 2007 18:10:49 -0700 Received: from localhost (localhost [127.0.0.1]) by hymn01.u.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l5F1AnAo024267; Thu, 14 Jun 2007 18:10:49 -0700 X-Auth-Received: from [192.55.52.1] by hymn01.u.washington.edu via HTTP; Thu, 14 Jun 2007 18:10:49 PDT Date: Thu, 14 Jun 2007 18:10:49 -0700 (PDT) From: youshi10@u.washington.edu To: Matthew Dillon In-Reply-To: <200706150104.l5F14RjG001010@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.3.1.294258, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.6.14.175233 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='SUPERLONG_LINE 0.05, NO_REAL_NAME 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' Cc: hackers@freebsd.org Subject: Re: Reason for doing malloc / bzero over calloc (performance)? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2007 01:10:53 -0000 On Thu, 14 Jun 2007, Matthew Dillon wrote: > I'm going to throw a wrench in the works, because it all gets turned > around the moment you find yourself in a SMP environment where several > threads are running on different cpus at the same time, using the > same shared VM space. > > The moment you have a situation like that where you are futzing with > the page tables, i.e. using mmap() for demand-zero and munmap() to > free, the operation becomes extremely expensive verses anything > else because any update to the page table (specifically any removal > of page table entries from the page table) requires a SMP synchronization > to occur between all the cpu's actively sharing that VM space, and > that's on top of the overhead of taking the page fault(s). > > This is true of any memory mapping the kernel has to do in kernel > virtual memory (must be synchronized with ALL cpus) and any mapping > the kernel does on behalf of userland for user memory (must be > synchronized with any cpu's actively using that VM space, i.e. threaded > user programs). The synchronization is required to properly invalidate > stale mappings on other cpus and it must be done synchronously due > to bugs in Intel/AMD related to changing page table entries on one > cpu when instructions are executing using that memory on another cpu. > There is no way to avoid it without tripping up on the Intel/AMD hardware > bugs. > > From this point of view it is much, much better to bzero() memory that > is already mapped then it is to map/unmap new memory. I recently > audited DragonFly and found an insane number of IPIs flying about due > to PAGE_SIZE'd kernel mallocs using the VM trick via kernel_map & > kmem_alloc(). They all went away when I made the kernel malloc use > the slab cache for allocations up to and including PAGE_SIZE*2 bytes. > > Fun, eh? > > -Matt > Matthew Dillon > I have no intention of using malloc/calloc with free, and then repeating the same procedure. It's better just to use the memory allocated, if possible, size permitting this. I wasn't thinking that closely though (ISA/hardware config versus OS implementation), but I had my suspicions since the AMD64 architecture is very different from the PowerPC architecture, in terms of word size, sychronization schemes, instruction count, etc. Interesting insight though. Thanks :). -Garrett From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 15 11:50:22 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E277416A400 for ; Fri, 15 Jun 2007 11:50:22 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-20-82.belrs4.nsw.optusnet.com.au [220.239.20.82]) by mx1.freebsd.org (Postfix) with ESMTP id 6D2BF13C458 for ; Fri, 15 Jun 2007 11:50:22 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.14.1/8.14.1) with ESMTP id l5FBoLuu001998; Fri, 15 Jun 2007 21:50:21 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.14.1/8.14.1/Submit) id l5FBoLIo001997; Fri, 15 Jun 2007 21:50:21 +1000 (EST) (envelope-from peter) Date: Fri, 15 Jun 2007 21:50:20 +1000 From: Peter Jeremy To: Jeremy Chadwick Message-ID: <20070615115020.GG1173@turion.vk2pj.dyndns.org> References: <4670B27B.6060606@digitalstratum.com> <20070614040848.GA30741@eos.sc1.parodius.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VrqPEDrXMn8OVzN4" Content-Disposition: inline In-Reply-To: <20070614040848.GA30741@eos.sc1.parodius.com> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.15 (2007-04-06) Cc: freebsd-hackers@freebsd.org Subject: Re: Disk block or sector to file mapping? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2007 11:50:23 -0000 --VrqPEDrXMn8OVzN4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2007-Jun-13 21:08:48 -0700, Jeremy Chadwick wrote: >Realistically, what we need on FreeBSD is a tool similar to Solaris's >format(8) "analyze" command, which does a raw disk scan (r, r/w, and a >couple other operations). The "analyze" function is just a pattern test with the ability to restore the original content. Writing one is trivial. >[1] - If the OS is seeing bad blocks on a PATA/SATA disk, usually it means >that the internal remapping table is full, which means that there were >other bad blocks on the disk which it has silently remapped for you to >avoid pain -- and space for those blocks has been exhausted. Re-mapping generally only works on writes. If you can't read existing data off the platter then you will get a bad block error irrespective of the remapping table. A sector that could not be read can often be written. >and you're stuck simply replacing the disk entirely. Bad blocks have a >tendency to spread too... Definitely - once the number of soft errors starts increasing, it's time to replace the disk. --=20 Peter Jeremy --VrqPEDrXMn8OVzN4 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGcnz8/opHv/APuIcRAgAvAJ0f+1b7PV2URU337bp24KyHbCCtBwCeMXbv XoTG5RMH++dBvtZR9bTDESY= =bApP -----END PGP SIGNATURE----- --VrqPEDrXMn8OVzN4-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 15 14:01:06 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CAEFD16A46E for ; Fri, 15 Jun 2007 14:01:06 +0000 (UTC) (envelope-from christian.kandeler@hob.de) Received: from mailgate.hob.de (mailgate.hob.de [212.185.199.3]) by mx1.freebsd.org (Postfix) with ESMTP id 3376913C46E for ; Fri, 15 Jun 2007 14:01:06 +0000 (UTC) (envelope-from christian.kandeler@hob.de) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailgate.hob.de (Postfix) with ESMTP id 6F7E428059 for ; Fri, 15 Jun 2007 15:41:56 +0200 (CEST) Received: from mailgate.hob.de ([127.0.0.1]) by localhost (mailgate.hob.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31035-07 for ; Fri, 15 Jun 2007 15:41:56 +0200 (CEST) Received: from imap.hob.de (mail2.hob.de [172.25.1.102]) by mailgate.hob.de (Postfix) with ESMTP id 4004928054 for ; Fri, 15 Jun 2007 15:41:56 +0200 (CEST) Received: from [172.22.0.190] (linux03.hob.de [172.22.0.190]) by imap.hob.de (Postfix on SuSE eMail Server 2.0) with ESMTP id CB206C493C for ; Fri, 15 Jun 2007 15:41:55 +0200 (CEST) From: Christian Kandeler Organization: HOB To: freebsd-hackers@freebsd.org Date: Fri, 15 Jun 2007 15:41:51 +0200 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200706151541.51913.christian.kandeler@hob.de> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at hob.de Subject: Question about serial console code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2007 14:01:06 -0000 Hi, I've spent some time figuring out the code path for user space output to a serial console, and there is one thing I don't understand. The code flow goes via write() and tty_write() to uart_tty_oproc(), which contains the following line: sc->sc_txdatasz = q_to_b(&tp->t_outq, sc->sc_txbuf, sc->sc_txfifosz); This copies at most sc->sc_txfifosz (the size of the UART's FIFO) bytes from tp->outq to sc->sc_txbuf. After that, UART_TRANSMIT is called and outputs the characters just copied to the serial device. Now obviously, the number of characters in tp->t_outq can be greater than the UART's FIFO size, but I can't for the life of me find a loop anywhere in the call tree. So what happens to the rest of the outq buffer? And what if the UART has no FIFO at all (e.g. 8250)? sc->sc_txfifosz is zero in that case, so how does anything ever get printed then? Regards, Christian Kandeler From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 15 15:47:43 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4C5FB16A400 for ; Fri, 15 Jun 2007 15:47:43 +0000 (UTC) (envelope-from joerg@britannica.bec.de) Received: from www.pkgsrc-box.org (www.ostsee-abc.de [62.206.222.50]) by mx1.freebsd.org (Postfix) with ESMTP id 0B34813C46E for ; Fri, 15 Jun 2007 15:47:42 +0000 (UTC) (envelope-from joerg@britannica.bec.de) Received: from britannica.bec.de (www.pkgsrc-box.org [127.0.0.1]) by www.pkgsrc-box.org (Postfix) with ESMTP id 7A93DE7A3F9 for ; Fri, 15 Jun 2007 15:47:34 +0000 (UTC) Received: by britannica.bec.de (Postfix, from userid 1000) id E4C2F7D31; Fri, 15 Jun 2007 17:47:03 +0200 (CEST) Date: Fri, 15 Jun 2007 17:47:03 +0200 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org Message-ID: <20070615154703.GA2247@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org References: <200706150104.l5F14RjG001010@apollo.backplane.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200706150104.l5F14RjG001010@apollo.backplane.com> User-Agent: Mutt/1.5.13 (2006-08-11) Subject: Re: Reason for doing malloc / bzero over calloc (performance)? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2007 15:47:43 -0000 On Thu, Jun 14, 2007 at 06:04:27PM -0700, Matthew Dillon wrote: > From this point of view it is much, much better to bzero() memory that > is already mapped then it is to map/unmap new memory. For kernel land, you are right. For userland, there's one big down-side to always bzero/memset newly allocated memory: it touches the page and thereby can add a lot of back pressure on you are not having that much memory. This can be completely uncessary at that point and at least one application of using calloc with large parameter values is creation of a hash table. Forcing it to consume memory is not such a good idea. Joerg From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 15 16:05:00 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8B8EA16A496 for ; Fri, 15 Jun 2007 16:05:00 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.186]) by mx1.freebsd.org (Postfix) with ESMTP id 7600313C44B for ; Fri, 15 Jun 2007 16:05:00 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (smtpin02-en2 [10.13.10.147]) by smtpout.mac.com (Xserve/smtpout16/MantshX 4.0) with ESMTP id l5FG4xZU025630; Fri, 15 Jun 2007 09:04:59 -0700 (PDT) Received: from [172.16.1.3] (209-128-86-226.bayarea.net [209.128.86.226]) (authenticated bits=0) by mac.com (Xserve/smtpin02/MantshX 4.0) with ESMTP id l5FG46f4026538 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 15 Jun 2007 09:04:25 -0700 (PDT) In-Reply-To: <200706151541.51913.christian.kandeler@hob.de> References: <200706151541.51913.christian.kandeler@hob.de> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8D1F83C2-C7A6-4C86-88BE-17DD516DA4D9@mac.com> Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Fri, 15 Jun 2007 09:03:50 -0700 To: Christian Kandeler X-Mailer: Apple Mail (2.752.3) Cc: freebsd-hackers@freebsd.org Subject: Re: Question about serial console code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2007 16:05:00 -0000 On Jun 15, 2007, at 6:41 AM, Christian Kandeler wrote: > sc->sc_txdatasz = q_to_b(&tp->t_outq, sc->sc_txbuf, sc->sc_txfifosz); > This copies at most sc->sc_txfifosz (the size of the UART's FIFO) > bytes from > tp->outq to sc->sc_txbuf. After that, UART_TRANSMIT is called and > outputs the > characters just copied to the serial device. Yes. > Now obviously, the number of > characters in tp->t_outq can be greater than the UART's FIFO size, > but I > can't for the life of me find a loop anywhere in the call tree. So > what > happens to the rest of the outq buffer? The loop is formed by the transmit interrupt of the UART. When UART_TRANSMIT() is called, the FIFO of the UART is written and transmission starts. Eventually the UART will raise a "transmission done" interrupt, which will trigger the next iteration. > And what if the UART has no FIFO at > all (e.g. 8250)? sc->sc_txfifosz is zero in that case, so how does > anything > ever get printed then? If the UART has no FIFO (in the 16550-sense), then sc_txfifosz is still 1. There's obviously always at least 1 8-bit register in the UART to which data can to be written or read. The use of FIFO in the uart(4) is not limited to its definition in PC hardware. FYI, -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 15 18:03:40 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CDA4016A41F for ; Fri, 15 Jun 2007 18:03:40 +0000 (UTC) (envelope-from mashtizadeh@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.225]) by mx1.freebsd.org (Postfix) with ESMTP id 7D63B13C48A for ; Fri, 15 Jun 2007 18:03:40 +0000 (UTC) (envelope-from mashtizadeh@gmail.com) Received: by nz-out-0506.google.com with SMTP id 14so883538nzn for ; Fri, 15 Jun 2007 11:03:40 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=ZfSagYzqLMHicGicws9+FK+LkJZCpPdw2b/UdoUTDsrUaWAkAG4SL9M+cdcPNJDIABZhsip4geEsZZUIvaF8AVDX91C0c015B/ISxu5I4LRNG65fVmC/aFEcaMqfp59hNBqBNyOdlcXlZiQnfww3OLVlsT9a1rnx2vYm2tBkzlY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=qjeZz+z5QU/IbC45Mhk4OPPoiSRLAKmy+lpCCDAgkX3qrtqLsMRoEUNHFGyz+WZHK8v+aow3wrTO3DFq8QHpT+oWPaOhsrKwMxf4gPI4VjTbW4tB77kn90pPcCgR6j1wQmzNUhQp7Ez+zrKpE1qaqBp+zJDZ/eTIYoW/LUXmUso= Received: by 10.142.105.14 with SMTP id d14mr170400wfc.1181930619701; Fri, 15 Jun 2007 11:03:39 -0700 (PDT) Received: by 10.143.19.7 with HTTP; Fri, 15 Jun 2007 11:03:39 -0700 (PDT) Message-ID: <440b3e930706151103n554c0671qc086671e9251e422@mail.gmail.com> Date: Fri, 15 Jun 2007 14:03:39 -0400 From: "Ali Mashtizadeh" To: freebsd-hackers@freebsd.org In-Reply-To: <880dece00706151014t229460b8j821cc4dea24788fe@mail.gmail.com> MIME-Version: 1.0 References: <880dece00706151014t229460b8j821cc4dea24788fe@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Fwd: AMD deciding _now_ what to do about Linux X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2007 18:03:40 -0000 SGV5IGV2ZXJ5b25lLAoKVGhpcyBlbWFpbCB3ZW50IG91dCBvbiBYb3JnIEkgdGhvdWdodCBpdCBt aWdodCBiZSB1c2VmdWwgZm9yIGFsbCBvZiB1cyBzdHVjawp3aXRoIEFUSSBjYXJkcy4gV2Ugc2hv dWxkIGFsbCBzaG93IG91ciBpbnRlcmVzdCBpbiBBTUQgaGVscGluZyBvdXQgdGhlIEJTRApjb21t dW5pdHkgYXMgd2VsbCEgSnVzdCBsaWtlIE52aWRpYSBoYXMgYmVlbiBkb2luZyEKCi0tIApBbGkg TWFzaHRpemFkZWgK2LnZhNuMINmF2LTYqtuMINiy2KfYr9mHCgoKLS0tLS0tLS0tLSBGb3J3YXJk ZWQgbWVzc2FnZSAtLS0tLS0tLS0tCkZyb206IERvdGFuIENvaGVuIDxkb3RhbmNvaGVuQGdtYWls LmNvbT4KRGF0ZTogSnVuIDE1LCAyMDA3IDE6MTQgUE0KU3ViamVjdDogQU1EIGRlY2lkaW5nIF9u b3dfIHdoYXQgdG8gZG8gYWJvdXQgTGludXgKVG86IHhvcmcgPHhvcmdAbGlzdHMuZnJlZWRlc2t0 b3Aub3JnPgoKSSB3cm90ZSB0byBBTUQgcmVnYXJkaW5nIHRoZSBzdGF0ZSBvZiBBVEkgTGludXgg ZHJpdmVycyBhbmQgdGhlCmNvbXBhbnkncyB2aWV3IG9mIHRoZSBMaW51eCBjb21tdW5pdHkuIFRo aXMgaXMgdGhlIHJlc3BvbnNlIEkgZ290OgoKIlRoYW5rcyAtIGNvdWxkIHlvdSBjb250YWN0IHVz IGFnYWluIGluIEp1bHk/ICBXZSdyZSByZXZpZXdpbmcgb3VyIExpbnV4CnN0cmF0ZWd5IHJpZ2h0 IG5vdywgc28gYW55dGhpbmcgSSB0ZWxsIHlvdSBrbm93IGNvdWxkIGJlIG91dCBvZiBkYXRlIGlu CndlZWtzLiIKCllvdSBjYW4gcmVhZCB0aGUgd2hvbGUgbWVzc2FnZSBoZXJlOgpodHRwOi8vZG90 YW5jb2hlbi5jb20vZW5nL2xpbnV4X2NvbXBhdGliaWxpdHkucGhwCkZlZWwgZnJlZSB0byBEaWdn IG9yIC8uIGl0LgoKRnJpZW5kcywgTk9XIGlzIHRoZSB0aW1lIHRvIGNvbnRhY3QgQU1EIGFuZCB0 byBsZXQgdGhlbSBrbm93IHRoYXQgd2UKbmVlZCB0aGVpciBzdXBwb3J0LiBQbGVhc2UsIHdyaXRl IHRvIHRoZW0sIGNhbGwgdGhlbSwgbm93IGlzIHRoZSB0aW1lLgpFdmVuIGZvciB0aG9zZSB3aG8g ZG9uJ3QgdXNlIEFNRCBwcm9kdWN0cywgdGhlIHByZWNlZGVudCBzZXQgaGVyZSB3aWxsCm1vc3Qg Y2VydGFpbmx5IGVjaG8gdGhyb3VnaG91dCB0aGUgaGFyZHdhcmUgd29ybGQuIFRha2UgdGhlIDUg bWludXRlcwphbmQgY29udmluY2UgQU1EIHRoYXQgdGhlIExpbnV4IGNvbW11bml0eSBjYW5ub3Qg YmUgaWdub3JlZC4KCk5vdGU6IEkgaGF2ZSBwb3N0ZWQgdGhpcyBsZXR0ZXIgdG8gc2V2ZXJhbCBt YWlsaW5nIGxpc3RzLiBUaG9zZSB3aG8Ka25vdyBtZSBmcm9tIHRob3NlIGxpc3RzIHdpbGwga25v dyB0aGF0IEkgZG9uJ3QsIGFzIGEgcnVsZSwgY3Jvc3Nwb3N0LgpIb3dldmVyLCBJIGZlbHQgdGhp cyB0byBiZSBpbXBvcnRhbnQgZW5vdWdoIHRvIGNyb3NzIHRoZSBsaW5lIGFuZApjcm9zc3Bvc3Qg dG8gdGhlIGxpc3RzIEkgZmVsdCB3b3VsZCBiZSBpbnRlcmVzdGVkLgoKRG90YW4gQ29oZW4KCmh0 dHA6Ly9seXJpY3NsaXN0LmNvbS8KaHR0cDovL3doYXQtaXMtd2hhdC5jb20vCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCnhvcmcgbWFpbGluZyBsaXN0Cnhv cmdAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHA6Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcvbWFp bG1hbi9saXN0aW5mby94b3JnCg== From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 15 18:56:15 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D028016A474 for ; Fri, 15 Jun 2007 18:56:15 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id C1DCC13C448 for ; Fri, 15 Jun 2007 18:56:15 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 86ADC1CC044; Fri, 15 Jun 2007 11:56:15 -0700 (PDT) Date: Fri, 15 Jun 2007 11:56:15 -0700 From: Jeremy Chadwick To: freebsd-hackers@freebsd.org Message-ID: <20070615185615.GA84136@eos.sc1.parodius.com> References: <880dece00706151014t229460b8j821cc4dea24788fe@mail.gmail.com> <440b3e930706151103n554c0671qc086671e9251e422@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <440b3e930706151103n554c0671qc086671e9251e422@mail.gmail.com> User-Agent: Mutt/1.5.15 (2007-04-06) Subject: Re: Fwd: AMD deciding _now_ what to do about Linux X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2007 18:56:15 -0000 On Fri, Jun 15, 2007 at 02:03:39PM -0400, Ali Mashtizadeh wrote: > Hey everyone, > > This email went out on Xorg I thought it might be useful for all of us stuck > with ATI cards. We should all show our interest in AMD helping out the BSD > community as well! Just like Nvidia has been doing! "Linux strategy" -- gotta love the use of the word "strategy", like they're playing chess or Risk or Daisenryaku. Yes, because supporting an operating system involves "strategy". Not to sound rude, but I wouldn't hold your breath over the statement. Yes, *absolutely* mail them and show support for the BSDs, and tell them you'll be happy to beta test whatever they put out (as long as they have a good feedback method for reporting those bugs; not some defunct HTML form web page that sends submissions to /dev/null). I believe AMD/ATI cares about providing a good driver base (for Linux and probably the BSDs), but no matter how many customers mail them, the reality of the situation is a disappointing one: managers and executives of sorts are who have say over all of this, who decide all of this, and who ultimately make the statements on all of this. As a Texan co-worker of mine says, "too many chiefs, not enough indians". nVidia has the same "problem", for what it's worth. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 15 19:29:28 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2D12116A46C for ; Fri, 15 Jun 2007 19:29:28 +0000 (UTC) (envelope-from mashtizadeh@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.230]) by mx1.freebsd.org (Postfix) with ESMTP id CB97113C4BC for ; Fri, 15 Jun 2007 19:29:27 +0000 (UTC) (envelope-from mashtizadeh@gmail.com) Received: by wr-out-0506.google.com with SMTP id 70so817895wra for ; Fri, 15 Jun 2007 12:29:27 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=EUXjRFqjoupWQ1xABsnE1LyDDMGaeBKRuL5GKDV733DrUlqvcdvGQT+0JDbTgHJHTNsHlLTrDR5E8/12E4COWW1xyitwlpW01hQe8gcykxHvEnmrOsfc0ndruLQQksZBhH92g0WIkxc4SWMcjTDl8l1M9B7TlrWRYMuQusdr/nM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=pfJpcWEhJmlFjBdZNXSpHOKb4n6a4M5g5kpJo/fur53k1t5vlbkMvM7rKKSMkBX4LXsI0COxSAeYtBqrbNRhfKx/WWq+vdeFI7Okb+usbV+qx8VwyYvmTnjio8vFy7+EvwmIW9Ft9Z8WcDui0NVx5tX1yzssQOgvtGHUcZeKop8= Received: by 10.142.80.7 with SMTP id d7mr173490wfb.1181935766683; Fri, 15 Jun 2007 12:29:26 -0700 (PDT) Received: by 10.143.19.7 with HTTP; Fri, 15 Jun 2007 12:29:26 -0700 (PDT) Message-ID: <440b3e930706151229q79a0f051jeca1d20550da599e@mail.gmail.com> Date: Fri, 15 Jun 2007 15:29:26 -0400 From: "Ali Mashtizadeh" To: "Jeremy Chadwick" In-Reply-To: <20070615185615.GA84136@eos.sc1.parodius.com> MIME-Version: 1.0 References: <880dece00706151014t229460b8j821cc4dea24788fe@mail.gmail.com> <440b3e930706151103n554c0671qc086671e9251e422@mail.gmail.com> <20070615185615.GA84136@eos.sc1.parodius.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: Fwd: AMD deciding _now_ what to do about Linux X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2007 19:29:28 -0000 SGksCgpTdW4ncyBwdXNoaW5nIEFUSS9BTUQgdG8gcHJvdmlkZSBnb29kIGRyaXZlcnMgZm9yIFNv bGFyaXMsIHNvIGl0IG1lYW5zIHRoZXkKd2lsbCBoYXZlIHRvIHdvcmsgb24gdGhlIHBvcnRhYmls aXR5IGlzc3VlIG9mIHRoZWlyIGRyaXZlcnMuIEl0IGlzIHByb2JhYmx5CnRoZSBiZXN0IHRpbWUg dG8gaW5mbHVlbmNlIEFNRCdzIGRlY2lzaW9uIHNpbmNlIHRoZXkgYXJlIGdvaW5nIHRvIGRvIHdo YXQKU3VuIHRlbGxzIHRoZW0uIE52aWRpYSBoYXMgYW4gZWFzaWVyIHRpbWUgcG9ydGluZyB0aGVp ciBkcml2ZXJzIHNpbmNlIHRoZQpjb3JlIG9mIHRoZSBkcml2ZXIgaXMgdGhlIHNhbWUgYWNyb3Nz IGFsbCBwbGF0Zm9ybXMgQUZBSUsuIEhvcGVmdWxseSwgdGhleQp3aWxsIHJlYWxpemUgdGhlIGJl c3Qgc3RyYXRlZGd5IGlzIHRvIG9wZW4gc291cmNlIHRoZWlyIGRyaXZlcnMsIHdoaWNoIHRoZXJl CmhhcyBiZWVuIHNvbWUgaGludHMgYWJvdXQgaXQgcmVjZW50bHkuCgotLSAKQWxpIE1hc2h0aXph ZGVoCti52YTbjCDZhdi02KrbjCDYstin2K/ZhwoKT24gNi8xNS8wNywgSmVyZW15IENoYWR3aWNr IDxrb2l0c3VAZnJlZWJzZC5vcmc+IHdyb3RlOgo+Cj4gT24gRnJpLCBKdW4gMTUsIDIwMDcgYXQg MDI6MDM6MzlQTSAtMDQwMCwgQWxpIE1hc2h0aXphZGVoIHdyb3RlOgo+ID4gIEhleSBldmVyeW9u ZSwKPiA+Cj4gPiAgVGhpcyBlbWFpbCB3ZW50IG91dCBvbiBYb3JnIEkgdGhvdWdodCBpdCBtaWdo dCBiZSB1c2VmdWwgZm9yIGFsbCBvZiB1cwo+IHN0dWNrCj4gPiAgd2l0aCBBVEkgY2FyZHMuIFdl IHNob3VsZCBhbGwgc2hvdyBvdXIgaW50ZXJlc3QgaW4gQU1EIGhlbHBpbmcgb3V0IHRoZQo+IEJT RAo+ID4gIGNvbW11bml0eSBhcyB3ZWxsISBKdXN0IGxpa2UgTnZpZGlhIGhhcyBiZWVuIGRvaW5n IQo+Cj4gIkxpbnV4IHN0cmF0ZWd5IiAtLSBnb3R0YSBsb3ZlIHRoZSB1c2Ugb2YgdGhlIHdvcmQg InN0cmF0ZWd5IiwgbGlrZQo+IHRoZXkncmUgcGxheWluZyBjaGVzcyBvciBSaXNrIG9yIERhaXNl bnJ5YWt1LiAgWWVzLCBiZWNhdXNlIHN1cHBvcnRpbmcKPiBhbiBvcGVyYXRpbmcgc3lzdGVtIGlu dm9sdmVzICJzdHJhdGVneSIuCj4KPiBOb3QgdG8gc291bmQgcnVkZSwgYnV0IEkgd291bGRuJ3Qg aG9sZCB5b3VyIGJyZWF0aCBvdmVyIHRoZSBzdGF0ZW1lbnQuCj4gWWVzLCAqYWJzb2x1dGVseSog bWFpbCB0aGVtIGFuZCBzaG93IHN1cHBvcnQgZm9yIHRoZSBCU0RzLCBhbmQgdGVsbCB0aGVtCj4g eW91J2xsIGJlIGhhcHB5IHRvIGJldGEgdGVzdCB3aGF0ZXZlciB0aGV5IHB1dCBvdXQgKGFzIGxv bmcgYXMgdGhleSBoYXZlCj4gYSBnb29kIGZlZWRiYWNrIG1ldGhvZCBmb3IgcmVwb3J0aW5nIHRo b3NlIGJ1Z3M7IG5vdCBzb21lIGRlZnVuY3QgSFRNTAo+IGZvcm0gd2ViIHBhZ2UgdGhhdCBzZW5k cyBzdWJtaXNzaW9ucyB0byAvZGV2L251bGwpLgo+Cj4gSSBiZWxpZXZlIEFNRC9BVEkgY2FyZXMg YWJvdXQgcHJvdmlkaW5nIGEgZ29vZCBkcml2ZXIgYmFzZSAoZm9yIExpbnV4Cj4gYW5kIHByb2Jh Ymx5IHRoZSBCU0RzKSwgYnV0IG5vIG1hdHRlciBob3cgbWFueSBjdXN0b21lcnMgbWFpbCB0aGVt LCB0aGUKPiByZWFsaXR5IG9mIHRoZSBzaXR1YXRpb24gaXMgYSBkaXNhcHBvaW50aW5nIG9uZTog bWFuYWdlcnMgYW5kIGV4ZWN1dGl2ZXMKPiBvZiBzb3J0cyBhcmUgd2hvIGhhdmUgc2F5IG92ZXIg YWxsIG9mIHRoaXMsIHdobyBkZWNpZGUgYWxsIG9mIHRoaXMsIGFuZAo+IHdobyB1bHRpbWF0ZWx5 IG1ha2UgdGhlIHN0YXRlbWVudHMgb24gYWxsIG9mIHRoaXMuICBBcyBhIFRleGFuIGNvLXdvcmtl cgo+IG9mIG1pbmUgc2F5cywgInRvbyBtYW55IGNoaWVmcywgbm90IGVub3VnaCBpbmRpYW5zIi4g IG5WaWRpYSBoYXMgdGhlCj4gc2FtZSAicHJvYmxlbSIsIGZvciB3aGF0IGl0J3Mgd29ydGguCj4K PiAtLQo+IHwgSmVyZW15IENoYWR3aWNrICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgamRjIGF0IHBhcm9kaXVzLmNvbSB8Cj4gfCBQYXJvZGl1cyBOZXR3b3JraW5nICAgICAgICAg ICAgICAgICAgICAgICAgICAgaHR0cDovL3d3dy5wYXJvZGl1cy5jb20vIHwKPiB8IFVOSVggU3lz dGVtcyBBZG1pbmlzdHJhdG9yICAgICAgICAgICAgICAgICAgICAgIE1vdW50YWluIFZpZXcsIENB LCBVU0EgfAo+IHwgTWFraW5nIGxpZmUgaGFyZCBmb3Igb3RoZXJzIHNpbmNlIDE5NzcuICAgICAg ICAgICAgICAgICAgUEdQOiA0QkQ2QzBDQiB8Cj4KPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXwo+IGZyZWVic2QtaGFja2Vyc0BmcmVlYnNkLm9yZyBtYWls aW5nIGxpc3QKPiBodHRwOi8vbGlzdHMuZnJlZWJzZC5vcmcvbWFpbG1hbi9saXN0aW5mby9mcmVl YnNkLWhhY2tlcnMKPiBUbyB1bnN1YnNjcmliZSwgc2VuZCBhbnkgbWFpbCB0byAiZnJlZWJzZC1o YWNrZXJzLXVuc3Vic2NyaWJlQGZyZWVic2Qub3JnIgo+Cg== From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 15 20:07:49 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 61ABD16A469 for ; Fri, 15 Jun 2007 20:07:49 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by mx1.freebsd.org (Postfix) with ESMTP id 3FB2713C447 for ; Fri, 15 Jun 2007 20:07:49 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from hymn01.u.washington.edu (hymn01.u.washington.edu [140.142.8.55]) by mxout4.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.05) with ESMTP id l5FK7meD020018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 15 Jun 2007 13:07:48 -0700 Received: from localhost (localhost [127.0.0.1]) by hymn01.u.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l5FK7mgd018664 for ; Fri, 15 Jun 2007 13:07:48 -0700 X-Auth-Received: from [192.55.52.1] by hymn01.u.washington.edu via HTTP; Fri, 15 Jun 2007 13:07:48 PDT Date: Fri, 15 Jun 2007 13:07:48 -0700 (PDT) From: youshi10@u.washington.edu To: hackers@freebsd.org In-Reply-To: <440b3e930706151229q79a0f051jeca1d20550da599e@mail.gmail.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE X-PMX-Version: 5.3.1.294258, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.6.15.124933 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='SUPERLONG_LINE 0.05, NO_REAL_NAME 0, __CP_MEDIA_BODY 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HIGHBITS 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __RUS_HASHBUSTER_KOI8R 0, __SANE_MSGID 0' Cc: Subject: Re: Fwd: AMD deciding _now_ what to do about Linux X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2007 20:07:49 -0000 On Fri, 15 Jun 2007, Ali Mashtizadeh wrote: > Hi, > > Sun's pushing ATI/AMD to provide good drivers for Solaris, so it means th= ey > will have to work on the portability issue of their drivers. It is probab= ly > the best time to influence AMD's decision since they are going to do what > Sun tells them. Nvidia has an easier time porting their drivers since the > core of the driver is the same across all platforms AFAIK. Hopefully, the= y > will realize the best stratedgy is to open source their drivers, which th= ere > has been some hints about it recently. > > --=20 > Ali Mashtizadeh > =D8=B9=D9=84=DB=8C =D9=85=D8=B4=D8=AA=DB=8C =D8=B2=D8=A7=D8=AF=D9=87 > > On 6/15/07, Jeremy Chadwick wrote: >> >> On Fri, Jun 15, 2007 at 02:03:39PM -0400, Ali Mashtizadeh wrote: >> > Hey everyone, >> > >> > This email went out on Xorg I thought it might be useful for all of u= s >> stuck >> > with ATI cards. We should all show our interest in AMD helping out th= e >> BSD >> > community as well! Just like Nvidia has been doing! >> >> "Linux strategy" -- gotta love the use of the word "strategy", like >> they're playing chess or Risk or Daisenryaku. Yes, because supporting >> an operating system involves "strategy". >> >> Not to sound rude, but I wouldn't hold your breath over the statement. >> Yes, *absolutely* mail them and show support for the BSDs, and tell them >> you'll be happy to beta test whatever they put out (as long as they have >> a good feedback method for reporting those bugs; not some defunct HTML >> form web page that sends submissions to /dev/null). >> >> I believe AMD/ATI cares about providing a good driver base (for Linux >> and probably the BSDs), but no matter how many customers mail them, the >> reality of the situation is a disappointing one: managers and executives >> of sorts are who have say over all of this, who decide all of this, and >> who ultimately make the statements on all of this. As a Texan co-worker >> of mine says, "too many chiefs, not enough indians". nVidia has the >> same "problem", for what it's worth. >> >> -- >> | Jeremy Chadwick jdc at parodius.com= | >> | Parodius Networking http://www.parodius.com/= | >> | UNIX Systems Administrator Mountain View, CA, USA= | >> | Making life hard for others since 1977. PGP: 4BD6C0CB= | 1. This shouldn't have been sent to the hackers@ list, because it's more of= a discussion than a technical topic. 2. Please top post. Disregarding those 2 comments, I have a few thoughts: 1. It doesn't matter which company you deal with, ATI/AMD, Intel, nVidia --= all are large corporations and swaying the interest of the execs and legal= depts to release corporate secrets and technologies is a big deal because = it's their competitive edges in the marketplace. 2. Intel did opensourced their graphics drivers, and of course there's been= a great deal of followup discussion about nVidia and ATI doing the same th= ing, but like Jeremy said I have little faith in the companies opensourcing= their drivers for at least 1-2 years because their secrets are their livel= ihood and they don't want competitors having access to them. 3. The ATI Linux drivers quite frankly suck right now. They're currently at= the stage that nVidia was 3-4 years ago with Linux (working, but not on al= l distros, quite a few hacks in place), and I wasn't impressed in the least= by them (hence I dumped my ATI card and purchased an nVidia one). 4. Sun is a lot different than Linux or FreeBSD. Sun is a software/hardware= vendor with plenty of financial collateral behind them, so their getting s= upport faster than FreeBSD is more likely, as long as the devs are there to= support Solaris. 5. I did email ATI about support and apparently I sent my message to the wr= ong section (I should have requested a driver enhancement, not filed bug --= I hate some online forms and their lack of clarity). But since I purchased= my nVidia card after the fact I never followed up on the reply I got from = ATI. I highly doubt your message gets shuffled away into nowhere; it would = create a bad corporate image to ignore current/potential customers ;). Cheers, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 16 12:23:40 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 121A216A46D for ; Sat, 16 Jun 2007 12:23:40 +0000 (UTC) (envelope-from naylor.b.david@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.231]) by mx1.freebsd.org (Postfix) with ESMTP id AF85113C44C for ; Sat, 16 Jun 2007 12:23:39 +0000 (UTC) (envelope-from naylor.b.david@gmail.com) Received: by wx-out-0506.google.com with SMTP id h28so958599wxd for ; Sat, 16 Jun 2007 05:23:39 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:mime-version:content-type:content-transfer-encoding:message-id:sender; b=YGJUF/wzGSsD4oBoUnT4lsMdb3GzxgqnRtU8eYQcbpJkB3VM1BLtv9w+rOjHtOnWylXlyM5AEyPNPYSrxTfCrkM/hOUjtOCQHLj2al4/NKaH0lUCVBxn8bD4ZK4IvVOnOnwqp1p9xTNVjdVebpCvibhfzdiGty0DgBUnvyW5oSY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:mime-version:content-type:content-transfer-encoding:message-id:sender; b=SppprmqTQPkmrynVngAnq104gWz+UYwIVQ2nkIwITUv2BScCLgN0XmbY2N/4z2lkKLEUTvTXQIZsQ1VG3eSfbI42114FshVtxKLxdDsL7NL+vv2w0kKrJ7ddGQyXqjru2SXC1RahksFAoR+ka9r6Lu/54VMGlysZtYf3jhzMWp8= Received: by 10.70.29.2 with SMTP id c2mr6355233wxc.1181996619051; Sat, 16 Jun 2007 05:23:39 -0700 (PDT) Received: from ?192.168.0.2? ( [196.34.241.123]) by mx.google.com with ESMTP id 34sm1016805wra.2007.06.16.05.23.34 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 16 Jun 2007 05:23:37 -0700 (PDT) From: David Naylor To: freebsd-hackers@freebsd.org Date: Sat, 16 Jun 2007 14:22:50 +0200 User-Agent: KMail/1.9.5 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1993640.CETo88zvLt"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200706161422.56694.blackdragon@highveldmail.co.za> Sender: David Naylor Subject: FreeBSD and Information handling X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jun 2007 12:23:40 -0000 --nextPart1993640.CETo88zvLt Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, I was wondering if there was any tool available in freebsd for handling=20 information, specifically configuration files, package information and such= =2E =20 I know all information is available via text files however in order to acce= ss=20 the information the program might have to hard code the retreval system (no= t=20 being able to use a shared library). =20 So: 1) What tools are there for accessing information (i.e. libraries)? 2) If so is there any unification of the interface? 3) If no to any of the above, is there a need for such tools and should it = be=20 a unified interface (not just specific subsets)? David --nextPart1993640.CETo88zvLt Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBGc9YgyqzxLKpyZI8RAmMTAJ9wD0H+pgLOf2I2vCF8cj3U+f3k7gCfe+TA HLAXF/h80g1HwLYsuQ+Kgxo= =NaqY -----END PGP SIGNATURE----- --nextPart1993640.CETo88zvLt-- From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 16 15:01:48 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 77B8816A400 for ; Sat, 16 Jun 2007 15:01:48 +0000 (UTC) (envelope-from quetzal@zone3000.net) Received: from mx1.sitevalley.com (sitevalley.com [209.67.60.43]) by mx1.freebsd.org (Postfix) with SMTP id 1707813C447 for ; Sat, 16 Jun 2007 15:01:47 +0000 (UTC) (envelope-from quetzal@zone3000.net) Received: from zone3000.kharkov.ua (HELO localhost) (217.144.69.37) by 0 with SMTP; 16 Jun 2007 15:01:47 -0000 Date: Sat, 16 Jun 2007 18:01:55 +0300 From: Nikolay Pavlov To: David Naylor Message-ID: <20070616150155.GA73039@zone3000.net> Mail-Followup-To: Nikolay Pavlov , David Naylor , freebsd-hackers@freebsd.org References: <200706161422.56694.blackdragon@highveldmail.co.za> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200706161422.56694.blackdragon@highveldmail.co.za> X-Operating-System: FreeBSD 6.2-RELEASE-p4 User-Agent: mutt-ng/devel-r804 (FreeBSD) Cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD and Information handling X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jun 2007 15:01:48 -0000 On Saturday, 16 June 2007 at 14:22:50 +0200, David Naylor wrote: > Hi, > > I was wondering if there was any tool available in freebsd for handling > information, specifically configuration files, package information and such. > I know all information is available via text files however in order to access > the information the program might have to hard code the retreval system (not > being able to use a shared library). > > So: > 1) What tools are there for accessing information (i.e. libraries)? > 2) If so is there any unification of the interface? > 3) If no to any of the above, is there a need for such tools and should it be > a unified interface (not just specific subsets)? > > David Hi David. If you want to automate your administrative task your might want to look at puppet or cfengine. -- ====================================================================== - Best regards, Nikolay Pavlov. <<<----------------------------------- ====================================================================== From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 16 18:05:01 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0C87916A47A for ; Sat, 16 Jun 2007 18:05:01 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id A4FCF13C4DD for ; Sat, 16 Jun 2007 18:05:00 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Hzcdk-0004d2-97 for freebsd-hackers@freebsd.org; Sat, 16 Jun 2007 20:04:48 +0200 Received: from 78-1-114-116.adsl.net.t-com.hr ([78.1.114.116]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 16 Jun 2007 20:04:48 +0200 Received: from ivoras by 78-1-114-116.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 16 Jun 2007 20:04:48 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Date: Sat, 16 Jun 2007 20:04:28 +0200 Lines: 37 Message-ID: References: <200706161422.56694.blackdragon@highveldmail.co.za> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig18AB7E5127245F044370E09E" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 78-1-114-116.adsl.net.t-com.hr User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) In-Reply-To: <200706161422.56694.blackdragon@highveldmail.co.za> X-Enigmail-Version: 0.94.3.0 Sender: news Subject: Re: FreeBSD and Information handling X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jun 2007 18:05:01 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig18AB7E5127245F044370E09E Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable David Naylor wrote: > So: > 1) What tools are there for accessing information (i.e. libraries)? > 2) If so is there any unification of the interface? > 3) If no to any of the above, is there a need for such tools and should= it be=20 > a unified interface (not just specific subsets)? If everything goes OK, the backend server from finstall could offer something like that. (http://wiki.freebsd.org/finstall). The lan is to finish the prototype in python, then rewrite it in C for inclusion in the base system (though this particular part needs some high-level discussion), so this is not something that will happen "soon". --------------enig18AB7E5127245F044370E09E 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.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGdCYwldnAQVacBcgRAtDaAJ0VertaqW+B4Z3uDNGvQ7UzsLK41QCfTI70 ccxCwswhY9ZYRgNlV+KpYCM= =i/fT -----END PGP SIGNATURE----- --------------enig18AB7E5127245F044370E09E-- From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 16 18:32:34 2007 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BB95916A468 for ; Sat, 16 Jun 2007 18:32:34 +0000 (UTC) (envelope-from freebsd@sopwith.solgatos.com) Received: from schitzo.solgatos.com (pool-71-117-239-32.ptldor.fios.verizon.net [71.117.239.32]) by mx1.freebsd.org (Postfix) with ESMTP id 9A8C813C4B9 for ; Sat, 16 Jun 2007 18:32:34 +0000 (UTC) (envelope-from freebsd@sopwith.solgatos.com) Received: from schitzo.solgatos.com (localhost.home.localnet [127.0.0.1]) by schitzo.solgatos.com (8.13.8/8.13.8) with ESMTP id l5GHZ0gP018499 for ; Sat, 16 Jun 2007 10:35:00 -0700 Received: from sopwith.solgatos.com (uucp@localhost) by schitzo.solgatos.com (8.13.8/8.13.4/Submit) with UUCP id l5GHZ0FQ018496 for freebsd-hackers@FreeBSD.org; Sat, 16 Jun 2007 10:35:00 -0700 Received: from localhost by sopwith.solgatos.com (8.8.8/6.24) id RAA14937; Sat, 16 Jun 2007 17:33:00 GMT Message-Id: <200706161733.RAA14937@sopwith.solgatos.com> To: freebsd-hackers@FreeBSD.org Date: Sat, 16 Jun 2007 10:33:00 +0100 From: Dieter X-Mailman-Approved-At: Sat, 16 Jun 2007 18:40:24 +0000 Cc: Subject: Re: Fwd: AMD deciding _now_ what to do about Linux X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd@sopwith.solgatos.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jun 2007 18:32:34 -0000 So who, exactly, is the best person to write to requesting docs for AMD/ATI graphics/video chips? We need to politely inform them that There are a lot of operating systems out there, and they all need high quality, fully functional drivers. FreeBSD, NetBSD, OpenBSD, Plan-9, Open-Solaris, ... We might want to add a ATI graphics/video card to a computer with a different CPU architecture (Alpha, Sparc, PPC, ...) Binary drivers are useless, because: Too many OSes. Too many CPU archs. Can't fix bugs. Can't fix security holes. Therefore we need documentation on how to program the chips. 2D is not enough. We need video decoding and 3D. If we can't have high quality, fully functional source code drivers for the OS and CPU arch of our choice, then there is no reason to buy the product. Have I left out anything? From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 16 19:17:25 2007 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.ORG Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2731016A400 for ; Sat, 16 Jun 2007 19:17:25 +0000 (UTC) (envelope-from wb@freebie.xs4all.nl) Received: from smtp-vbr15.xs4all.nl (smtp-vbr15.xs4all.nl [194.109.24.35]) by mx1.freebsd.org (Postfix) with ESMTP id B934813C45A for ; Sat, 16 Jun 2007 19:17:24 +0000 (UTC) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (obsolete.xs4all.nl [82.95.250.254]) by smtp-vbr15.xs4all.nl (8.13.8/8.13.8) with ESMTP id l5GJHFXD084929; Sat, 16 Jun 2007 21:17:23 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.13.8/8.13.3) with ESMTP id l5GJHEXa038529; Sat, 16 Jun 2007 21:17:14 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: (from wb@localhost) by freebie.xs4all.nl (8.13.8/8.13.6/Submit) id l5GJHE7Y038528; Sat, 16 Jun 2007 21:17:14 +0200 (CEST) (envelope-from wb) Date: Sat, 16 Jun 2007 21:17:14 +0200 From: Wilko Bulte To: Dieter Message-ID: <20070616191714.GA38504@freebie.xs4all.nl> References: <200706161733.RAA14937@sopwith.solgatos.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200706161733.RAA14937@sopwith.solgatos.com> User-Agent: Mutt/1.5.11 X-Virus-Scanned: by XS4ALL Virus Scanner Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Fwd: AMD deciding _now_ what to do about Linux X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jun 2007 19:17:25 -0000 On Sat, Jun 16, 2007 at 10:33:00AM +0100, Dieter wrote.. > So who, exactly, is the best person to write to requesting > docs for AMD/ATI graphics/video chips? > > We need to politely inform them that > > There are a lot of operating systems out there, > and they all need high quality, fully functional drivers. > FreeBSD, NetBSD, OpenBSD, Plan-9, Open-Solaris, ... > > We might want to add a ATI graphics/video card to a computer > with a different CPU architecture (Alpha, Sparc, PPC, ...) > > Binary drivers are useless, because: > Too many OSes. > Too many CPU archs. > Can't fix bugs. > Can't fix security holes. > Therefore we need documentation on how to program the chips. > > 2D is not enough. We need video decoding and 3D. > > If we can't have high quality, fully functional source code drivers > for the OS and CPU arch of our choice, then there is no reason to > buy the product. > > Have I left out anything? Well.. yes. "How much revenue ($$) AMD will loose when these open source projects do not get the chip docs". Ultimately the $$ question is what exec level management will ask. -- Wilko Bulte wilko@FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 16 21:16:55 2007 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.ORG Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EADB016A469; Sat, 16 Jun 2007 21:16:55 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by mx1.freebsd.org (Postfix) with ESMTP id C5FA613C45E; Sat, 16 Jun 2007 21:16:55 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9] (may be forged)) by mxout5.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.05) with ESMTP id l5GLGjFw018109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 16 Jun 2007 14:16:46 -0700 X-Auth-Received: from [192.168.10.45] (c-24-10-12-194.hsd1.ca.comcast.net [24.10.12.194]) (authenticated authid=youshi10) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l5GLGiJw011286 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 16 Jun 2007 14:16:45 -0700 Message-ID: <46745340.6090702@u.washington.edu> Date: Sat, 16 Jun 2007 14:16:48 -0700 From: Garrett Cooper User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Wilko Bulte References: <200706161733.RAA14937@sopwith.solgatos.com> <20070616191714.GA38504@freebie.xs4all.nl> In-Reply-To: <20070616191714.GA38504@freebie.xs4all.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.3.1.294258, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.6.16.135834 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_MEDIA_2_BODY 0, __CP_MEDIA_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' Cc: freebsd-hackers@FreeBSD.ORG, Dieter , chat@freebsd.org Subject: Re: Fwd: AMD deciding _now_ what to do about Linux X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jun 2007 21:16:56 -0000 Wilko Bulte wrote: > On Sat, Jun 16, 2007 at 10:33:00AM +0100, Dieter wrote.. > >> So who, exactly, is the best person to write to requesting >> docs for AMD/ATI graphics/video chips? >> >> We need to politely inform them that >> >> There are a lot of operating systems out there, >> and they all need high quality, fully functional drivers. >> FreeBSD, NetBSD, OpenBSD, Plan-9, Open-Solaris, ... >> >> We might want to add a ATI graphics/video card to a computer >> with a different CPU architecture (Alpha, Sparc, PPC, ...) >> >> Binary drivers are useless, because: >> Too many OSes. >> Too many CPU archs. >> Can't fix bugs. >> Can't fix security holes. >> Therefore we need documentation on how to program the chips. >> >> 2D is not enough. We need video decoding and 3D. >> >> If we can't have high quality, fully functional source code drivers >> for the OS and CPU arch of our choice, then there is no reason to >> buy the product. >> >> Have I left out anything? >> > > Well.. yes. "How much revenue ($$) AMD will loose when these open > source projects do not get the chip docs". > > Ultimately the $$ question is what exec level management will ask. > > Countering the above statements (the following are important questions to answer, and should be done by their business types with more hard data): How much money will AMD lose on competitive edge versus market segment share for the particular open source customer base? How much of the ATI drivers will they have to modify in order to ensure that they remain IP protected and the extremely proprietary sections don't get put out in the open by accident? -Garrett From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 16 21:30:18 2007 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.ORG Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B23AB16A400 for ; Sat, 16 Jun 2007 21:30:18 +0000 (UTC) (envelope-from wb@freebie.xs4all.nl) Received: from smtp-vbr2.xs4all.nl (smtp-vbr2.xs4all.nl [194.109.24.22]) by mx1.freebsd.org (Postfix) with ESMTP id 4C61C13C447 for ; Sat, 16 Jun 2007 21:30:17 +0000 (UTC) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (obsolete.xs4all.nl [82.95.250.254]) by smtp-vbr2.xs4all.nl (8.13.8/8.13.8) with ESMTP id l5GLU7p8087575; Sat, 16 Jun 2007 23:30:08 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.13.8/8.13.3) with ESMTP id l5GLU6kf039749; Sat, 16 Jun 2007 23:30:06 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: (from wb@localhost) by freebie.xs4all.nl (8.13.8/8.13.6/Submit) id l5GLU6PQ039746; Sat, 16 Jun 2007 23:30:06 +0200 (CEST) (envelope-from wb) Date: Sat, 16 Jun 2007 23:30:06 +0200 From: Wilko Bulte To: Garrett Cooper Message-ID: <20070616213006.GA39721@freebie.xs4all.nl> References: <200706161733.RAA14937@sopwith.solgatos.com> <20070616191714.GA38504@freebie.xs4all.nl> <46745340.6090702@u.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46745340.6090702@u.washington.edu> User-Agent: Mutt/1.5.11 X-Virus-Scanned: by XS4ALL Virus Scanner Cc: freebsd-hackers@FreeBSD.ORG, Dieter , chat@FreeBSD.ORG Subject: Re: Fwd: AMD deciding _now_ what to do about Linux X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jun 2007 21:30:18 -0000 On Sat, Jun 16, 2007 at 02:16:48PM -0700, Garrett Cooper wrote.. > Wilko Bulte wrote: > >On Sat, Jun 16, 2007 at 10:33:00AM +0100, Dieter wrote.. > > > >>So who, exactly, is the best person to write to requesting > >>docs for AMD/ATI graphics/video chips? > >> > >>We need to politely inform them that > >> > >> There are a lot of operating systems out there, > >> and they all need high quality, fully functional drivers. > >> FreeBSD, NetBSD, OpenBSD, Plan-9, Open-Solaris, ... > >> > >> We might want to add a ATI graphics/video card to a computer > >> with a different CPU architecture (Alpha, Sparc, PPC, ...) > >> > >> Binary drivers are useless, because: > >> Too many OSes. > >> Too many CPU archs. > >> Can't fix bugs. > >> Can't fix security holes. > >> Therefore we need documentation on how to program the chips. > >> > >> 2D is not enough. We need video decoding and 3D. > >> > >> If we can't have high quality, fully functional source code drivers > >> for the OS and CPU arch of our choice, then there is no reason to > >> buy the product. > >> > >>Have I left out anything? > >> > > > >Well.. yes. "How much revenue ($$) AMD will loose when these open > >source projects do not get the chip docs". > > > >Ultimately the $$ question is what exec level management will ask. > > > > > Countering the above statements (the following are important I would not call that countering, I think we agree? > questions to answer, and should be done by their business types with > more hard data): > How much money will AMD lose on competitive edge versus market > segment share for the particular open source customer base? And is that enough to be noticable in the grander (MS-Windows) scheme of things> > How much of the ATI drivers will they have to modify in order to > ensure that they remain IP protected and the extremely proprietary > sections don't get put out in the open by accident? The outcome might even be that this is not worthwhile for them.. (blackest possible outcome, I agree). > -Garrett -- Wilko Bulte wilko@FreeBSD.org