From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 15 00:17: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 E117316A40A; Sun, 15 Jul 2007 00:17: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 8CB8013C4A6; Sun, 15 Jul 2007 00:17:45 +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 l6F0HiH7003993; Sat, 14 Jul 2007 17:17:45 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <469967A8.3080901@freebsd.org> Date: Sat, 14 Jul 2007 17:17:44 -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: Garrett Cooper References: <468C96C0.1040603@u.washington.edu> <468C9718.1050108@u.washington.edu> <468E60E9.80507@freebsd.org> <468E6C81.4060908@u.washington.edu> <468E7192.8030105@freebsd.org> <4696C0D2.6010809@u.washington.edu> <4697A210.2020301@u.washington.edu> <4698ADB5.7080600@u.washington.edu> <4698F98A.6080908@freebsd.org> <4699587F.30703@u.washington.edu> In-Reply-To: <4699587F.30703@u.washington.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: ports@freebsd.org, hackers@freebsd.org, krion@freebsd.org Subject: Re: Finding slowdowns in pkg_install (continuations of previous threads) 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, 15 Jul 2007 00:17:46 -0000 > The following blog post has all of my commentary on the results I > have: > . > I tried to unroll strcmp a bit by checking for the first character of the > command, then run strcmp ... There's a somewhat more straightforward optimization that relies on this same idea: switch(cmd[0]) { case 'c': /* Commands that start with 'c' */ if (strcmp(cmd, 'cwd') == 0) return (CMD_CWD); /* FALLTHROUGH */ case 'd': /* Commands that start with 'd' */ .... etc.... /* FALLTHROUGH */ default: /* Unrecognized command. */ } This is a little cleaner and easier to read and may even be faster than the code you presented in your blog. Note that the fall through ensures that all unrecognized commands end up at the same place. If unrecognized commands are very rare (they should be), then the fallthrough is not a performance issue. > /** malloc buffer large enough to hold +CONTENTS **/ > > while(!feof(file_p)) { > > /** add content via fgetc **/ > } Yuck. Try this instead: struct stat st; int fd; char *buff; fd = open(file); fstat(fd, &st); buff = malloc(st.st_size + 1); read(fd, buff, st.st_size); buff[st.st_size] = '\0'; close(fd); Plus some error checking, of course. You can use stdio if you prefer: FILE *f; f = fopen(file, "r"); fstat(fileno(f), &st); buff = malloc(st.st_size + 1); fread(buff, 1, st.st_size, f); buff[st.st_size] = '\0'; fclose(f); Either way, this is a lot more efficient than tens of thousands of calls to fgetc(). Cheers, Tim Kientzle From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 15 00:39:28 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 A5E0816A402; Sun, 15 Jul 2007 00:39:28 +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 7F94613C4B5; Sun, 15 Jul 2007 00:39:28 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.141] (may be forged)) by mxout2.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.06) with ESMTP id l6F0dRHq017053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 14 Jul 2007 17:39:28 -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 l6F0dQ4U029544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 14 Jul 2007 17:39:27 -0700 Message-ID: <46996CBE.6050401@u.washington.edu> Date: Sat, 14 Jul 2007 17:39:26 -0700 From: Garrett Cooper User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Tim Kientzle References: <468C96C0.1040603@u.washington.edu> <468C9718.1050108@u.washington.edu> <468E60E9.80507@freebsd.org> <468E6C81.4060908@u.washington.edu> <468E7192.8030105@freebsd.org> <4696C0D2.6010809@u.washington.edu> <4697A210.2020301@u.washington.edu> <4698ADB5.7080600@u.washington.edu> <4698F98A.6080908@freebsd.org> <4699587F.30703@u.washington.edu> <469967A8.3080901@freebsd.org> In-Reply-To: <469967A8.3080901@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.3.2.304607, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.7.14.172533 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' Cc: ports@freebsd.org, hackers@freebsd.org, krion@freebsd.org Subject: Re: Finding slowdowns in pkg_install (continuations of previous threads) 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, 15 Jul 2007 00:39:28 -0000 Tim Kientzle wrote: >> The following blog post has all of my commentary on the results I >> have: >> . > > >> I tried to unroll strcmp a bit by checking for the first character of >> the > > command, then run strcmp ... > > There's a somewhat more straightforward optimization that > relies on this same idea: > > switch(cmd[0]) { > case 'c': > /* Commands that start with 'c' */ > if (strcmp(cmd, 'cwd') == 0) > return (CMD_CWD); > /* FALLTHROUGH */ > case 'd': > /* Commands that start with 'd' */ > > .... etc.... > /* FALLTHROUGH */ > default: > /* Unrecognized command. */ > } > > This is a little cleaner and easier to read > and may even be faster than the code you > presented in your blog. Note that the fall through > ensures that all unrecognized commands end up at > the same place. If unrecognized commands are > very rare (they should be), then the fallthrough > is not a performance issue. > >> /** malloc buffer large enough to hold +CONTENTS **/ >> >> while(!feof(file_p)) { >> >> /** add content via fgetc **/ >> } > > Yuck. Try this instead: > > struct stat st; > int fd; > char *buff; > > fd = open(file); > fstat(fd, &st); > buff = malloc(st.st_size + 1); > read(fd, buff, st.st_size); > buff[st.st_size] = '\0'; > close(fd); > > Plus some error checking, of course. You can > use stdio if you prefer: > > FILE *f; > > f = fopen(file, "r"); > fstat(fileno(f), &st); > buff = malloc(st.st_size + 1); > fread(buff, 1, st.st_size, f); > buff[st.st_size] = '\0'; > fclose(f); > > Either way, this is a lot more efficient than > tens of thousands of calls to fgetc(). > > Cheers, > > Tim Kientzle Tim, That was a very good call. I didn't even think of read(2) over fgetc(2). That decreased the overall time by 0.7 seconds in installing vim, which is just a little shy of a 10% speedup. -Garrett From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 15 00:41:59 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 5994616A400; Sun, 15 Jul 2007 00:41:59 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id BFCAE13C461; Sun, 15 Jul 2007 00:41:58 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from kobe.laptop (dialup188.ach.sch.gr [81.186.70.188]) (authenticated bits=128) by igloo.linux.gr (8.13.8/8.13.8/Debian-3) with ESMTP id l6F0RFak027033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 15 Jul 2007 03:27:26 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.1/8.14.1) with ESMTP id l6F0R9uf003751; Sun, 15 Jul 2007 03:27:09 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.14.1/8.14.1/Submit) id l6F0R8AN003750; Sun, 15 Jul 2007 03:27:08 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Date: Sun, 15 Jul 2007 03:27:08 +0300 From: Giorgos Keramidas To: Tim Kientzle Message-ID: <20070715002708.GA3665@kobe.laptop> References: <46992FFF.7010906@kientzle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46992FFF.7010906@kientzle.com> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.798, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.60, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Cc: hackers@freebsd.org, rwatson@freebsd.org, cperciva@freebsd.org Subject: Re: Tar output mode for installworld 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, 15 Jul 2007 00:41:59 -0000 On 2007-07-14 13:20, Tim Kientzle wrote: > I saw this project suggestion on www.freebsd.org: > > > > and thought I'd contribute a couple of ideas and notes: > > This is easy to implement using a trick that I stumbled across > a few years ago. The idea is to just build a description of > the final archive in a nice verbose text format such as: > > > > E.g., > > bin/sh file /usr/obj/usr/src/bin/sh > bin/sh uname root > bin/sh gname wheel > rescue/mkdir hardlink rescue/rescue > bin/sh mode 0666 > bin/rcp mode 04666 This looks vaguely similar to the package 'prototype' files which Solaris uses for creating packages. I've written quite a few of them at ${realjob}, so if it looks interesting as a 'file list' format, I can help with the details. A packaging list for one of the distributions I've built at work includes stuff like: # Misc command-line tools in @prefix@/bin/... d none @prefix@/bin 0755 root bin f none @prefix@/bin/progname-2.0 0755 root bin s none @prefix@/bin/progname=progname-2.0 Something like this, which includes all the bits for a single file in one line may be nice even for mtree and verification of files installed :) From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 15 02:46:02 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 B535116A400; Sun, 15 Jul 2007 02:46:02 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from kientzle.com (h-66-166-149-50.snvacaid.covad.net [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id 5AAE613C4AA; Sun, 15 Jul 2007 02:46:02 +0000 (UTC) (envelope-from tim@kientzle.com) 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 l6F2jwH7004642; Sat, 14 Jul 2007 19:45:58 -0700 (PDT) (envelope-from tim@kientzle.com) Message-ID: <46998A66.4030503@kientzle.com> Date: Sat, 14 Jul 2007 19:45:58 -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: Giorgos Keramidas References: <46992FFF.7010906@kientzle.com> <20070715002708.GA3665@kobe.laptop> In-Reply-To: <20070715002708.GA3665@kobe.laptop> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org, rwatson@freebsd.org, cperciva@freebsd.org Subject: Re: Tar output mode for installworld 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, 15 Jul 2007 02:46:02 -0000 On 2007-07-14 13:20, Tim Kientzle wrote: > >> >> >>This is easy to implement using a ... text format such as: >> bin/sh file /usr/obj/usr/src/bin/sh >> bin/sh uname root >> rescue/mkdir hardlink rescue/rescue >> bin/sh mode 0666 >> bin/rcp mode 04666 Giorgos Keramidas responds: > A packaging list for one of the distributions I've built at work > includes stuff like: > # Misc command-line tools in @prefix@/bin/... > d none @prefix@/bin 0755 root bin > f none @prefix@/bin/progname-2.0 0755 root bin > s none @prefix@/bin/progname=progname-2.0 My concern is that "all of the bits for one file" may not always be available at a single place in the build. Some programs use the "afterinstall" hook to set flags on the installed binary, for example. My version allows different information about a file to be output at different points in the build process. A simple 'sort' then collects information about each file together, making it easy to then build the final archive. Tim Kientzle From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 15 03:21: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 55C1616A401; Sun, 15 Jul 2007 03:21:49 +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 11F3313C461; Sun, 15 Jul 2007 03:21:48 +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 l6F3LkH7004767; Sat, 14 Jul 2007 20:21:46 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <469992CA.6000104@freebsd.org> Date: Sat, 14 Jul 2007 20:21:46 -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: Joerg Sonnenberger References: <46992FFF.7010906@kientzle.com> <20070714223853.GF16579@britannica.bec.de> In-Reply-To: <20070714223853.GF16579@britannica.bec.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, hackers@freebsd.org Subject: Re: Tar output mode for installworld 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, 15 Jul 2007 03:21:49 -0000 Joerg Sonnenberger wrote: > On Sat, Jul 14, 2007 at 01:20:15PM -0700, Tim Kientzle wrote: > >>This is easy to implement using a trick that I stumbled >>across a few years ago. The idea is to just build >>a description of the final archive in a nice verbose >>text format such as: > > ...which is done by NetBSD for the unprivileged release building via > build.sh. Anyone interested in working on this should possibly have a > look there. Interesting. I hadn't looked at NetBSD's unprivileged release build before. I just skimmed through some of it. Parts of it seems a little roundabout, but I like the use of a modified mtree format as the specification format: usr/bin/su type=file mode=04555 uname=root gname=wheel time=1057493599.102665 I would make two changes: 1) Add a contents= option. With this, DESTDIR is mostly irrelevant, since the path can just refer to the file in the build tree. 2) Allow multiple lines for any file. This complicates the consumer of this file a bit, but simplifies the build process, since you can emit separate information as you find it. For example, the regular install process could install rcp by emitting: bin/rcp type=file mode=04555 contents=/usr/obj/usr/src/bin/rcp and then a later point in the build process could add the flag by adding the line: bin/rcp flags=schg Hmmm... It would be easy for libarchive to parse this format and then bsdtar's existing "archive conversion" feature could trivially generate a tar.gz output from such a specification. Another idea would be to create an install program that accepted this format as the command line: mtree_install usr/bin/su type=file mode=04555 uname=root ... Then the build logic gets scary simple: A regular build sets INSTALL=mtree_install, a tar.gz build sets INSTALL=echo. (Hmmm... Maybe a tad more complex than this, but close.) (You could also modify the specification file so that the file specs mimicked 'install' options.) Tim Kientzle From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 15 03: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 55C1616A401; Sun, 15 Jul 2007 03:21:49 +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 11F3313C461; Sun, 15 Jul 2007 03:21:48 +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 l6F3LkH7004767; Sat, 14 Jul 2007 20:21:46 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <469992CA.6000104@freebsd.org> Date: Sat, 14 Jul 2007 20:21:46 -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: Joerg Sonnenberger References: <46992FFF.7010906@kientzle.com> <20070714223853.GF16579@britannica.bec.de> In-Reply-To: <20070714223853.GF16579@britannica.bec.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, hackers@freebsd.org Subject: Re: Tar output mode for installworld 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, 15 Jul 2007 03:21:49 -0000 Joerg Sonnenberger wrote: > On Sat, Jul 14, 2007 at 01:20:15PM -0700, Tim Kientzle wrote: > >>This is easy to implement using a trick that I stumbled >>across a few years ago. The idea is to just build >>a description of the final archive in a nice verbose >>text format such as: > > ...which is done by NetBSD for the unprivileged release building via > build.sh. Anyone interested in working on this should possibly have a > look there. Interesting. I hadn't looked at NetBSD's unprivileged release build before. I just skimmed through some of it. Parts of it seems a little roundabout, but I like the use of a modified mtree format as the specification format: usr/bin/su type=file mode=04555 uname=root gname=wheel time=1057493599.102665 I would make two changes: 1) Add a contents= option. With this, DESTDIR is mostly irrelevant, since the path can just refer to the file in the build tree. 2) Allow multiple lines for any file. This complicates the consumer of this file a bit, but simplifies the build process, since you can emit separate information as you find it. For example, the regular install process could install rcp by emitting: bin/rcp type=file mode=04555 contents=/usr/obj/usr/src/bin/rcp and then a later point in the build process could add the flag by adding the line: bin/rcp flags=schg Hmmm... It would be easy for libarchive to parse this format and then bsdtar's existing "archive conversion" feature could trivially generate a tar.gz output from such a specification. Another idea would be to create an install program that accepted this format as the command line: mtree_install usr/bin/su type=file mode=04555 uname=root ... Then the build logic gets scary simple: A regular build sets INSTALL=mtree_install, a tar.gz build sets INSTALL=echo. (Hmmm... Maybe a tad more complex than this, but close.) (You could also modify the specification file so that the file specs mimicked 'install' options.) Tim Kientzle From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 15 06:28:13 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 DC01D16A404; Sun, 15 Jul 2007 06:28:13 +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 6E8C013C4B2; Sun, 15 Jul 2007 06:28:13 +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 l6F6S5H7005450; Sat, 14 Jul 2007 23:28:05 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <4699BE75.2090808@freebsd.org> Date: Sat, 14 Jul 2007 23:28:05 -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: Tim Kientzle References: <46992FFF.7010906@kientzle.com> <20070714223853.GF16579@britannica.bec.de> <469992CA.6000104@freebsd.org> In-Reply-To: <469992CA.6000104@freebsd.org> Content-Type: multipart/mixed; boundary="------------030203060303050304050403" Cc: freebsd-hackers@freebsd.org, hackers@freebsd.org, Joerg Sonnenberger Subject: Re: Tar output mode for installworld 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, 15 Jul 2007 06:28:14 -0000 This is a multi-part message in MIME format. --------------030203060303050304050403 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit >>> This is easy to implement ... just build >>> a description of the final archive in a nice verbose >>> text format such as: >> >> ...which is done by NetBSD for the unprivileged release building via >> build.sh. Anyone interested in working on this should possibly have a >> look there. Here's a rough implementation of my core idea. Add the attached archive_read_support_format_ntree.c to libarchive and patch archive_read_support_format_all.c, then rebuild libarchive and bsdtar. You'll then be able to read, extract, etc, a format I'm calling "ntree" for now. This similar to NetBSD's "metalog" format, except: 1) First line must be "#%ntree". This is used as a file signature. 2) Blank lines and lines beginning with '#' are ignored. 3) All other lines have the following format: = = ... Where key is one of: time: decimal seconds since beginning of epoch gid,uid: decimal group/user ID gname,uname: textual group/user name mode: octal type: as in mtree, defaults to 'file' content: name of a file on disk E.g., #%ntree bin/echo uid=0 gid=0 group=wheel contents=my/bin/echo I think this should form a reasonable basis against which to implement tar output for installworld. I would actually suggest building the specification file at buildworld time, not at installworld time. You could then create a tarball with tar -czf system.tgz @specification.ntree or install directly from the specification file using tar -xvpf specification.ntree -C ${DESTDIR} Some work still remains: * Should allow multiple (consecutive) lines for a single file. * Need to support more keys, especially "flags" and "link". * Need to find a way to encode hardlinks. * Need to decide how/whether to reconcile this with mtree. (This could be extended to read regular mtree files, though it's unclear how to auto-detect the standard mtree format.) * Need to implement a test suite for this format and add it to libarchive_test. * Should be able to write these files. (A libarchive writer could even accumulate various hashes and include them, though the body per se would be lost.) Feedback appreciated, Tim Kientzle --------------030203060303050304050403 Content-Type: text/x-patch; name="archive_read_support_format_all.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="archive_read_support_format_all.patch" Index: archive_read_support_format_all.c =================================================================== --- archive_read_support_format_all.c (revision 398) +++ archive_read_support_format_all.c (working copy) @@ -35,6 +35,7 @@ archive_read_support_format_cpio(a); archive_read_support_format_empty(a); archive_read_support_format_iso9660(a); + archive_read_support_format_ntree(a); archive_read_support_format_tar(a); archive_read_support_format_zip(a); return (ARCHIVE_OK); --------------030203060303050304050403 Content-Type: text/plain; name="archive_read_support_format_ntree.c" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="archive_read_support_format_ntree.c" /*- * Copyright (c) 2003-2007 Tim Kientzle * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * * THIS SOFTWARE IS PROVIDED BY THE AUTHOR(S) ``AS IS'' AND ANY EXPRESS OR * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. * IN NO EVENT SHALL THE AUTHOR(S) 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 "archive_platform.h" __FBSDID("$FreeBSD$"); #ifdef HAVE_SYS_STAT_H #include #endif #ifdef HAVE_ERRNO_H #include #endif #ifdef HAVE_FCNTL_H #include #endif #include /* #include */ /* See archive_platform.h */ #ifdef HAVE_STDLIB_H #include #endif #ifdef HAVE_STRING_H #include #endif #include "archive.h" #include "archive_entry.h" #include "archive_private.h" #include "archive_read_private.h" struct ntree { struct archive_string line; size_t buffsize; char *buff; off_t offset; int fd; int bid; int filetype; }; static int bid(struct archive_read *); static int cleanup(struct archive_read *); static int parse_setting(struct archive_read *, struct ntree *, struct archive_entry *, char *, char *); static int read_data(struct archive_read *a, const void **buff, size_t *size, off_t *offset); static ssize_t readline(struct archive_read *, struct ntree *, char **); static int skip(struct archive_read *a); static int read_header(struct archive_read *, struct archive_entry *); static int64_t ntree_atol10(char **); static int64_t ntree_atol8(char **); int archive_read_support_format_ntree(struct archive *_a) { struct archive_read *a = (struct archive_read *)_a; struct ntree *ntree; int r; ntree = (struct ntree *)malloc(sizeof(*ntree)); if (ntree == NULL) { archive_set_error(&a->archive, ENOMEM, "Can't allocate ntree data"); return (ARCHIVE_FATAL); } memset(ntree, 0, sizeof(*ntree)); ntree->bid = -1; ntree->fd = -1; r = __archive_read_register_format(a, ntree, bid, read_header, read_data, skip, cleanup); if (r != ARCHIVE_OK) free(ntree); return (ARCHIVE_OK); } static int cleanup(struct archive_read *a) { struct ntree *ntree; ntree = (struct ntree *)(a->format->data); archive_string_free(&ntree->line); free(ntree->buff); free(ntree); (a->format->data) = NULL; return (ARCHIVE_OK); } static int bid(struct archive_read *a) { struct ntree *ntree; ssize_t bytes_read; const void *h; const char *signature = "#%ntree"; const char *p; ntree = (struct ntree *)(a->format->data); if (ntree->bid != -1) return (ntree->bid); /* Now let's look at the actual header and see if it matches. */ bytes_read = (a->decompressor->read_ahead)(a, &h, strlen(signature)); p = h; ntree->bid = 0; while (bytes_read > 0 && *signature != '\0') { if (*p != *signature) return (ntree->bid = 0); ntree->bid += 8; p++; signature++; } return (ntree->bid); } static int read_header(struct archive_read *a, struct archive_entry *entry) { struct ntree *ntree; char *p, *q, *end; ssize_t len; int r = ARCHIVE_OK, r1; ntree = (struct ntree *)(a->format->data); ntree->filetype = AE_IFREG; if (ntree->fd >= 0) { close(ntree->fd); ntree->fd = -1; } p = NULL; while (p == NULL) { len = readline(a, ntree, &p); if (len < 0) return (ARCHIVE_FATAL); if (len == 0) return (ARCHIVE_EOF); if (p[0] == '#') p = NULL; } end = p + len; /* Null-terminate each component. */ /* TODO: Allow spaces within filenames by using quotes. */ for (q = p; q < end; q++) if (*q == ' ' || *q == '\t' || *q == '\n') *q = '\0'; archive_entry_copy_pathname(entry, p); p += strlen(p); while (p < end) { q = p + strlen(p); r1 = parse_setting(a, ntree, entry, p, q); if (r1 != ARCHIVE_OK) r = r1; p = q + 1; } return r; } static int parse_setting(struct archive_read *a, struct ntree *ntree, struct archive_entry *entry, char *key, char *end) { struct stat st; char *val; if (end == key) return (ARCHIVE_OK); val = strchr(key, '='); if (val == NULL) { archive_set_error(&a->archive, ARCHIVE_ERRNO_FILE_FORMAT, "Malformed attribute \"%s\" (%d)", key, key[0]); return (ARCHIVE_WARN); } *val = '\0'; ++val; switch (key[0]) { case 'c': if (strcmp(key, "content") == 0) { ntree->fd = open(val, O_RDONLY); if (ntree->fd < 0) { archive_set_error(&a->archive, errno, "Can't open \"%s\"", val); return (ARCHIVE_WARN); } fstat(ntree->fd, &st); archive_entry_set_size(entry, st.st_size); break; } case 'g': if (strcmp(key, "gid") == 0) { archive_entry_set_gid(entry, ntree_atol10(&val)); break; } if (strcmp(key, "gname") == 0) { archive_entry_copy_gname(entry, val); break; } case 'm': if (strcmp(key, "mode") == 0) { if (val[0] == '0') { archive_entry_set_mode(entry, ntree->filetype | (07777 & ntree_atol8(&val))); } else archive_set_error(&a->archive, ARCHIVE_ERRNO_FILE_FORMAT, "Symbolic mode \"%s\" unsupported", val); break; } case 't': if (strcmp(key, "type") == 0) { switch (val[0]) { case 'b': if (strcmp(val, "block") == 0) { ntree->filetype = AE_IFBLK; break; } case 'c': if (strcmp(val, "char") == 0) { ntree->filetype = AE_IFCHR; break; } case 'd': if (strcmp(val, "dir") == 0) { ntree->filetype = AE_IFDIR; break; } case 'f': if (strcmp(val, "fifo") == 0) { ntree->filetype = AE_IFIFO; break; } if (strcmp(val, "file") == 0) { ntree->filetype = AE_IFREG; break; } case 'l': if (strcmp(val, "link") == 0) { ntree->filetype = AE_IFLNK; break; } default: archive_set_error(&a->archive, ARCHIVE_ERRNO_FILE_FORMAT, "Unrecognized file type \"%s\"", val); return (ARCHIVE_WARN); } archive_entry_set_filetype(entry, ntree->filetype); break; } if (strcmp(key, "time") == 0) { archive_entry_set_mtime(entry, ntree_atol10(&val), 0); break; } case 'u': if (strcmp(key, "uid") == 0) { archive_entry_set_uid(entry, ntree_atol10(&val)); break; } if (strcmp(key, "uname") == 0) { archive_entry_copy_uname(entry, val); break; } default: archive_set_error(&a->archive, ARCHIVE_ERRNO_FILE_FORMAT, "Unrecognized key %s=%s", key, val); return (ARCHIVE_WARN); } return (ARCHIVE_OK); } static int read_data(struct archive_read *a, const void **buff, size_t *size, off_t *offset) { ssize_t bytes_read; struct ntree *ntree; ntree = (struct ntree *)(a->format->data); if (ntree->fd < 0) { *buff = NULL; *offset = 0; *size = 0; return (ARCHIVE_EOF); } if (ntree->buff == NULL) { ntree->buffsize = 64 * 1024; ntree->buff = malloc(ntree->buffsize); if (ntree->buff == NULL) { archive_set_error(&a->archive, ENOMEM, "Can't allocate memory"); } } *buff = ntree->buff; *offset = ntree->offset; bytes_read = read(ntree->fd, ntree->buff, ntree->buffsize); if (bytes_read < 0) { archive_set_error(&a->archive, errno, "Can't read"); return (ARCHIVE_WARN); } if (bytes_read == 0) { *size = 0; return (ARCHIVE_EOF); } ntree->offset += bytes_read; *size = (size_t)bytes_read; return (ARCHIVE_OK); } /* Skip does nothing except possibly close the contents file. */ static int skip(struct archive_read *a) { struct ntree *ntree; ntree = (struct ntree *)(a->format->data); if (ntree->fd >= 0) { close(ntree->fd); ntree->fd = -1; } return (ARCHIVE_OK); } /* * Note that this implementation does not (and should not!) obey * locale settings; you cannot simply substitute strtol here, since * it does obey locale. */ static int64_t ntree_atol8(char **p) { int64_t l, limit, last_digit_limit; int digit, base; base = 8; limit = INT64_MAX / base; last_digit_limit = INT64_MAX % base; l = 0; digit = **p - '0'; while (digit >= 0 && digit < base) { if (l>limit || (l == limit && digit > last_digit_limit)) { l = INT64_MAX; /* Truncate on overflow. */ break; } l = (l * base) + digit; digit = *++(*p) - '0'; } return (l); } /* * Note that this implementation does not (and should not!) obey * locale settings; you cannot simply substitute strtol here, since * it does obey locale. */ static int64_t ntree_atol10(char **p) { int64_t l, limit, last_digit_limit; int base, digit, sign; base = 10; limit = INT64_MAX / base; last_digit_limit = INT64_MAX % base; if (**p == '-') { sign = -1; ++(*p); } else sign = 1; l = 0; digit = **p - '0'; while (digit >= 0 && digit < base) { if (l > limit || (l == limit && digit > last_digit_limit)) { l = UINT64_MAX; /* Truncate on overflow. */ break; } l = (l * base) + digit; digit = *++(*p) - '0'; } return (sign < 0) ? -l : l; } /* * Returns length of line (including trailing newline) * or negative on error. 'start' argument is updated to * point to first character of line. */ static ssize_t readline(struct archive_read *a, struct ntree *ntree, char **start) { ssize_t bytes_read; ssize_t total_size = 0; const void *t; const char *s; void *p; /* Accumulate line in a line buffer. */ for (;;) { /* Read some more. */ bytes_read = (a->decompressor->read_ahead)(a, &t, 1); if (bytes_read == 0) return (0); if (bytes_read < 0) return (ARCHIVE_FATAL); s = t; /* Start of line? */ p = memchr(t, '\n', bytes_read); /* If we found '\n', trim the read. */ if (p != NULL) { bytes_read = 1 + ((const char *)p) - s; } if (archive_string_ensure(&ntree->line, total_size + bytes_read) == NULL) { archive_set_error(&a->archive, ENOMEM, "Can't allocate working buffer"); return (ARCHIVE_FATAL); } memcpy(ntree->line.s + total_size, t, bytes_read); (a->decompressor->consume)(a, bytes_read); total_size += bytes_read; /* If we found '\n', clean up and return. */ if (p != NULL) { *start = ntree->line.s; return (total_size); } } } --------------030203060303050304050403-- From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 15 06:28: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 DC01D16A404; Sun, 15 Jul 2007 06:28:13 +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 6E8C013C4B2; Sun, 15 Jul 2007 06:28:13 +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 l6F6S5H7005450; Sat, 14 Jul 2007 23:28:05 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <4699BE75.2090808@freebsd.org> Date: Sat, 14 Jul 2007 23:28:05 -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: Tim Kientzle References: <46992FFF.7010906@kientzle.com> <20070714223853.GF16579@britannica.bec.de> <469992CA.6000104@freebsd.org> In-Reply-To: <469992CA.6000104@freebsd.org> Content-Type: multipart/mixed; boundary="------------030203060303050304050403" Cc: freebsd-hackers@freebsd.org, hackers@freebsd.org, Joerg Sonnenberger Subject: Re: Tar output mode for installworld 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, 15 Jul 2007 06:28:14 -0000 This is a multi-part message in MIME format. --------------030203060303050304050403 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit >>> This is easy to implement ... just build >>> a description of the final archive in a nice verbose >>> text format such as: >> >> ...which is done by NetBSD for the unprivileged release building via >> build.sh. Anyone interested in working on this should possibly have a >> look there. Here's a rough implementation of my core idea. Add the attached archive_read_support_format_ntree.c to libarchive and patch archive_read_support_format_all.c, then rebuild libarchive and bsdtar. You'll then be able to read, extract, etc, a format I'm calling "ntree" for now. This similar to NetBSD's "metalog" format, except: 1) First line must be "#%ntree". This is used as a file signature. 2) Blank lines and lines beginning with '#' are ignored. 3) All other lines have the following format: = = ... Where key is one of: time: decimal seconds since beginning of epoch gid,uid: decimal group/user ID gname,uname: textual group/user name mode: octal type: as in mtree, defaults to 'file' content: name of a file on disk E.g., #%ntree bin/echo uid=0 gid=0 group=wheel contents=my/bin/echo I think this should form a reasonable basis against which to implement tar output for installworld. I would actually suggest building the specification file at buildworld time, not at installworld time. You could then create a tarball with tar -czf system.tgz @specification.ntree or install directly from the specification file using tar -xvpf specification.ntree -C ${DESTDIR} Some work still remains: * Should allow multiple (consecutive) lines for a single file. * Need to support more keys, especially "flags" and "link". * Need to find a way to encode hardlinks. * Need to decide how/whether to reconcile this with mtree. (This could be extended to read regular mtree files, though it's unclear how to auto-detect the standard mtree format.) * Need to implement a test suite for this format and add it to libarchive_test. * Should be able to write these files. (A libarchive writer could even accumulate various hashes and include them, though the body per se would be lost.) Feedback appreciated, Tim Kientzle --------------030203060303050304050403 Content-Type: text/x-patch; name="archive_read_support_format_all.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="archive_read_support_format_all.patch" Index: archive_read_support_format_all.c =================================================================== --- archive_read_support_format_all.c (revision 398) +++ archive_read_support_format_all.c (working copy) @@ -35,6 +35,7 @@ archive_read_support_format_cpio(a); archive_read_support_format_empty(a); archive_read_support_format_iso9660(a); + archive_read_support_format_ntree(a); archive_read_support_format_tar(a); archive_read_support_format_zip(a); return (ARCHIVE_OK); --------------030203060303050304050403 Content-Type: text/plain; name="archive_read_support_format_ntree.c" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="archive_read_support_format_ntree.c" /*- * Copyright (c) 2003-2007 Tim Kientzle * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * * THIS SOFTWARE IS PROVIDED BY THE AUTHOR(S) ``AS IS'' AND ANY EXPRESS OR * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. * IN NO EVENT SHALL THE AUTHOR(S) 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 "archive_platform.h" __FBSDID("$FreeBSD$"); #ifdef HAVE_SYS_STAT_H #include #endif #ifdef HAVE_ERRNO_H #include #endif #ifdef HAVE_FCNTL_H #include #endif #include /* #include */ /* See archive_platform.h */ #ifdef HAVE_STDLIB_H #include #endif #ifdef HAVE_STRING_H #include #endif #include "archive.h" #include "archive_entry.h" #include "archive_private.h" #include "archive_read_private.h" struct ntree { struct archive_string line; size_t buffsize; char *buff; off_t offset; int fd; int bid; int filetype; }; static int bid(struct archive_read *); static int cleanup(struct archive_read *); static int parse_setting(struct archive_read *, struct ntree *, struct archive_entry *, char *, char *); static int read_data(struct archive_read *a, const void **buff, size_t *size, off_t *offset); static ssize_t readline(struct archive_read *, struct ntree *, char **); static int skip(struct archive_read *a); static int read_header(struct archive_read *, struct archive_entry *); static int64_t ntree_atol10(char **); static int64_t ntree_atol8(char **); int archive_read_support_format_ntree(struct archive *_a) { struct archive_read *a = (struct archive_read *)_a; struct ntree *ntree; int r; ntree = (struct ntree *)malloc(sizeof(*ntree)); if (ntree == NULL) { archive_set_error(&a->archive, ENOMEM, "Can't allocate ntree data"); return (ARCHIVE_FATAL); } memset(ntree, 0, sizeof(*ntree)); ntree->bid = -1; ntree->fd = -1; r = __archive_read_register_format(a, ntree, bid, read_header, read_data, skip, cleanup); if (r != ARCHIVE_OK) free(ntree); return (ARCHIVE_OK); } static int cleanup(struct archive_read *a) { struct ntree *ntree; ntree = (struct ntree *)(a->format->data); archive_string_free(&ntree->line); free(ntree->buff); free(ntree); (a->format->data) = NULL; return (ARCHIVE_OK); } static int bid(struct archive_read *a) { struct ntree *ntree; ssize_t bytes_read; const void *h; const char *signature = "#%ntree"; const char *p; ntree = (struct ntree *)(a->format->data); if (ntree->bid != -1) return (ntree->bid); /* Now let's look at the actual header and see if it matches. */ bytes_read = (a->decompressor->read_ahead)(a, &h, strlen(signature)); p = h; ntree->bid = 0; while (bytes_read > 0 && *signature != '\0') { if (*p != *signature) return (ntree->bid = 0); ntree->bid += 8; p++; signature++; } return (ntree->bid); } static int read_header(struct archive_read *a, struct archive_entry *entry) { struct ntree *ntree; char *p, *q, *end; ssize_t len; int r = ARCHIVE_OK, r1; ntree = (struct ntree *)(a->format->data); ntree->filetype = AE_IFREG; if (ntree->fd >= 0) { close(ntree->fd); ntree->fd = -1; } p = NULL; while (p == NULL) { len = readline(a, ntree, &p); if (len < 0) return (ARCHIVE_FATAL); if (len == 0) return (ARCHIVE_EOF); if (p[0] == '#') p = NULL; } end = p + len; /* Null-terminate each component. */ /* TODO: Allow spaces within filenames by using quotes. */ for (q = p; q < end; q++) if (*q == ' ' || *q == '\t' || *q == '\n') *q = '\0'; archive_entry_copy_pathname(entry, p); p += strlen(p); while (p < end) { q = p + strlen(p); r1 = parse_setting(a, ntree, entry, p, q); if (r1 != ARCHIVE_OK) r = r1; p = q + 1; } return r; } static int parse_setting(struct archive_read *a, struct ntree *ntree, struct archive_entry *entry, char *key, char *end) { struct stat st; char *val; if (end == key) return (ARCHIVE_OK); val = strchr(key, '='); if (val == NULL) { archive_set_error(&a->archive, ARCHIVE_ERRNO_FILE_FORMAT, "Malformed attribute \"%s\" (%d)", key, key[0]); return (ARCHIVE_WARN); } *val = '\0'; ++val; switch (key[0]) { case 'c': if (strcmp(key, "content") == 0) { ntree->fd = open(val, O_RDONLY); if (ntree->fd < 0) { archive_set_error(&a->archive, errno, "Can't open \"%s\"", val); return (ARCHIVE_WARN); } fstat(ntree->fd, &st); archive_entry_set_size(entry, st.st_size); break; } case 'g': if (strcmp(key, "gid") == 0) { archive_entry_set_gid(entry, ntree_atol10(&val)); break; } if (strcmp(key, "gname") == 0) { archive_entry_copy_gname(entry, val); break; } case 'm': if (strcmp(key, "mode") == 0) { if (val[0] == '0') { archive_entry_set_mode(entry, ntree->filetype | (07777 & ntree_atol8(&val))); } else archive_set_error(&a->archive, ARCHIVE_ERRNO_FILE_FORMAT, "Symbolic mode \"%s\" unsupported", val); break; } case 't': if (strcmp(key, "type") == 0) { switch (val[0]) { case 'b': if (strcmp(val, "block") == 0) { ntree->filetype = AE_IFBLK; break; } case 'c': if (strcmp(val, "char") == 0) { ntree->filetype = AE_IFCHR; break; } case 'd': if (strcmp(val, "dir") == 0) { ntree->filetype = AE_IFDIR; break; } case 'f': if (strcmp(val, "fifo") == 0) { ntree->filetype = AE_IFIFO; break; } if (strcmp(val, "file") == 0) { ntree->filetype = AE_IFREG; break; } case 'l': if (strcmp(val, "link") == 0) { ntree->filetype = AE_IFLNK; break; } default: archive_set_error(&a->archive, ARCHIVE_ERRNO_FILE_FORMAT, "Unrecognized file type \"%s\"", val); return (ARCHIVE_WARN); } archive_entry_set_filetype(entry, ntree->filetype); break; } if (strcmp(key, "time") == 0) { archive_entry_set_mtime(entry, ntree_atol10(&val), 0); break; } case 'u': if (strcmp(key, "uid") == 0) { archive_entry_set_uid(entry, ntree_atol10(&val)); break; } if (strcmp(key, "uname") == 0) { archive_entry_copy_uname(entry, val); break; } default: archive_set_error(&a->archive, ARCHIVE_ERRNO_FILE_FORMAT, "Unrecognized key %s=%s", key, val); return (ARCHIVE_WARN); } return (ARCHIVE_OK); } static int read_data(struct archive_read *a, const void **buff, size_t *size, off_t *offset) { ssize_t bytes_read; struct ntree *ntree; ntree = (struct ntree *)(a->format->data); if (ntree->fd < 0) { *buff = NULL; *offset = 0; *size = 0; return (ARCHIVE_EOF); } if (ntree->buff == NULL) { ntree->buffsize = 64 * 1024; ntree->buff = malloc(ntree->buffsize); if (ntree->buff == NULL) { archive_set_error(&a->archive, ENOMEM, "Can't allocate memory"); } } *buff = ntree->buff; *offset = ntree->offset; bytes_read = read(ntree->fd, ntree->buff, ntree->buffsize); if (bytes_read < 0) { archive_set_error(&a->archive, errno, "Can't read"); return (ARCHIVE_WARN); } if (bytes_read == 0) { *size = 0; return (ARCHIVE_EOF); } ntree->offset += bytes_read; *size = (size_t)bytes_read; return (ARCHIVE_OK); } /* Skip does nothing except possibly close the contents file. */ static int skip(struct archive_read *a) { struct ntree *ntree; ntree = (struct ntree *)(a->format->data); if (ntree->fd >= 0) { close(ntree->fd); ntree->fd = -1; } return (ARCHIVE_OK); } /* * Note that this implementation does not (and should not!) obey * locale settings; you cannot simply substitute strtol here, since * it does obey locale. */ static int64_t ntree_atol8(char **p) { int64_t l, limit, last_digit_limit; int digit, base; base = 8; limit = INT64_MAX / base; last_digit_limit = INT64_MAX % base; l = 0; digit = **p - '0'; while (digit >= 0 && digit < base) { if (l>limit || (l == limit && digit > last_digit_limit)) { l = INT64_MAX; /* Truncate on overflow. */ break; } l = (l * base) + digit; digit = *++(*p) - '0'; } return (l); } /* * Note that this implementation does not (and should not!) obey * locale settings; you cannot simply substitute strtol here, since * it does obey locale. */ static int64_t ntree_atol10(char **p) { int64_t l, limit, last_digit_limit; int base, digit, sign; base = 10; limit = INT64_MAX / base; last_digit_limit = INT64_MAX % base; if (**p == '-') { sign = -1; ++(*p); } else sign = 1; l = 0; digit = **p - '0'; while (digit >= 0 && digit < base) { if (l > limit || (l == limit && digit > last_digit_limit)) { l = UINT64_MAX; /* Truncate on overflow. */ break; } l = (l * base) + digit; digit = *++(*p) - '0'; } return (sign < 0) ? -l : l; } /* * Returns length of line (including trailing newline) * or negative on error. 'start' argument is updated to * point to first character of line. */ static ssize_t readline(struct archive_read *a, struct ntree *ntree, char **start) { ssize_t bytes_read; ssize_t total_size = 0; const void *t; const char *s; void *p; /* Accumulate line in a line buffer. */ for (;;) { /* Read some more. */ bytes_read = (a->decompressor->read_ahead)(a, &t, 1); if (bytes_read == 0) return (0); if (bytes_read < 0) return (ARCHIVE_FATAL); s = t; /* Start of line? */ p = memchr(t, '\n', bytes_read); /* If we found '\n', trim the read. */ if (p != NULL) { bytes_read = 1 + ((const char *)p) - s; } if (archive_string_ensure(&ntree->line, total_size + bytes_read) == NULL) { archive_set_error(&a->archive, ENOMEM, "Can't allocate working buffer"); return (ARCHIVE_FATAL); } memcpy(ntree->line.s + total_size, t, bytes_read); (a->decompressor->consume)(a, bytes_read); total_size += bytes_read; /* If we found '\n', clean up and return. */ if (p != NULL) { *start = ntree->line.s; return (total_size); } } } --------------030203060303050304050403-- From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 15 10:06:09 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 BA94C16A402 for ; Sun, 15 Jul 2007 10:06:09 +0000 (UTC) (envelope-from dominique.goncalves@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.230]) by mx1.freebsd.org (Postfix) with ESMTP id 779F113C48D for ; Sun, 15 Jul 2007 10:06:09 +0000 (UTC) (envelope-from dominique.goncalves@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so719604wxd for ; Sun, 15 Jul 2007 03:06:08 -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=Yf5YMQ/F+3uWnMpe6G7bTKwz3BVseQpe+xTC0rvfS9CuAvpfFxfhmbvJIY/s0htPl6a8mfuqiLD+yKO5yAxTAYG7K67jCqghHi1fuGM7Tm+Dmqx1trm4ViWiENZ16K8ViHFoq3jPm5prO5Itj1vz9xchPJELkcydYWYmc1Y1vhU= 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=iIV8jBRfjiaZnvL35j78tLc+0DQWrlq7S5pmZ9TxAB4zib1d2Sj4Oedq1g63XcfXLQgGTMbOPjhydhvzmpx6aBIm/zJYp2qpBmCOZojM1PxRfAlANCDFiU1FnnDARCoL6es0fBquuMyfoj/ThX+Vw4MXE2QHiWf0sBQkcaVh03E= Received: by 10.90.49.1 with SMTP id w1mr2505329agw.1184492277759; Sun, 15 Jul 2007 02:37:57 -0700 (PDT) Received: by 10.90.78.16 with HTTP; Sun, 15 Jul 2007 02:37:57 -0700 (PDT) Message-ID: <7daacbbe0707150237gc869abdi756d54219edb2577@mail.gmail.com> Date: Sun, 15 Jul 2007 11:37:57 +0200 From: "Dominique Goncalves" To: "Ivan Voras" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070709214216.GA72912@walton.maths.tcd.ie> <20070711132202.GA95487@walton.maths.tcd.ie> <20070712085135.GA5332@walton.maths.tcd.ie> Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: Debugging times 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, 15 Jul 2007 10:06:09 -0000 Hi, On 7/13/07, Ivan Voras wrote: > David Malone wrote: > > > Ah - that's interesting. Could you look for the comment in > > src/sys/i386/isa/clock.c that says: > > > > /* Should we set dow = -1 because some clocks don't set it correctly? */ > > > > and add a line afterwards to say: > > > > ct.dow = -1; > > > > and see if that helps? > > Yes, it does! Setting ct.dow to -1 fixes the time in a correct way. It works also for me with qemu 0.9.0. Thanks. > I vote this gets committed as soon as possible :) > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > Regards. -- There's this old saying: "Give a man a fish, feed him for a day. Teach a man to fish, feed him for life." From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 15 17:14:15 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 A548916A406 for ; Sun, 15 Jul 2007 17:14:15 +0000 (UTC) (envelope-from fb-hackers@psconsult.nl) Received: from ps226.psconsult.nl (ps226.psconsult.nl [213.222.19.226]) by mx1.freebsd.org (Postfix) with ESMTP id 2704013C48E for ; Sun, 15 Jul 2007 17:14:14 +0000 (UTC) (envelope-from fb-hackers@psconsult.nl) Received: from phuket.psconsult.nl (localhost [127.0.0.1]) by phuket.psconsult.nl (8.13.1/8.13.1) with ESMTP id l6FDUG8o058668; Sun, 15 Jul 2007 15:30:16 +0200 (CEST) (envelope-from fb-hackers@psconsult.nl) Received: (from paul@localhost) by phuket.psconsult.nl (8.13.1/8.13.1/Submit) id l6FDUGcV058667; Sun, 15 Jul 2007 15:30:16 +0200 (CEST) (envelope-from fb-hackers@psconsult.nl) Date: Sun, 15 Jul 2007 15:30:16 +0200 From: Paul Schenkeveld To: freebsd-hackers@freebsd.org, hackers@freebsd.org Message-ID: <20070715133016.GA53853@psconsult.nl> Mail-Followup-To: freebsd-hackers@freebsd.org, hackers@freebsd.org References: <46992FFF.7010906@kientzle.com> <20070714223853.GF16579@britannica.bec.de> <469992CA.6000104@freebsd.org> <4699BE75.2090808@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4699BE75.2090808@freebsd.org> User-Agent: Mutt/1.5.6i Cc: Subject: Re: Tar output mode for installworld 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, 15 Jul 2007 17:14:15 -0000 On Sat, Jul 14, 2007 at 11:28:05PM -0700, Tim Kientzle wrote: > >>>This is easy to implement ... just build > >>>a description of the final archive in a nice verbose > >>>text format such as: > >> > >>...which is done by NetBSD for the unprivileged release building via > >>build.sh. Anyone interested in working on this should possibly have a > >>look there. > > Here's a rough implementation of my core idea. Add the > attached archive_read_support_format_ntree.c to libarchive > and patch archive_read_support_format_all.c, then > rebuild libarchive and bsdtar. You'll then be able > to read, extract, etc, a format I'm calling "ntree" > for now. This similar to NetBSD's "metalog" format, except: > > 1) First line must be "#%ntree". This is used as a file signature. > > 2) Blank lines and lines beginning with '#' are ignored. > > 3) All other lines have the following format: > > = = ... > > Where key is one of: > time: decimal seconds since beginning of epoch > gid,uid: decimal group/user ID > gname,uname: textual group/user name > mode: octal > type: as in mtree, defaults to 'file' > content: name of a file on disk Great! This is exactly the next BIG step in (Free)BSD build/distribute/install that I have been waiting for. In the mean time I've been playing a lot with automating and customizing the build/distribute/install process of FreeBSD, partly inspired by nanobsd. Basically the process is something like: __MAKE_CONF=my_make.conf make buildworld __MAKE_CONF=my_make.conf make installworld DESTDIR=/some/place $CUSTOMIZATIONS /some/place tar czf tarball.tgz -C /some/place # Find a way to get the tarball.tgz to its destination tar xpf tarball.tgz # at the destination For the $CUSTOMIZATIONS to work it would be very nice to extend your proposal with the following features: - Allow scattered lines describing attributes of the same file but retain the order in which they appear so that $CUSTOMIZATIONS can override attributes set by make installworld. - Implement something like: remove to undo the installation of files (embedded systems hardly ever need stuff like documentation, NLS and so on but the make.conf and src.conf knobs are not fine-grained enough for all situations) - Implement something like: move= to allow $CUSTOMIZATIONS to move things around. A special case here should be observed: /bin/foo ... ... /bin/foo move=/bin/foo.orig /bin/foo ... here the $CUSTOMIZATIONS move some file so another place and installs a wrapper. Probably a sorting algorithm that retains the order in which /bin/foo lines appear does half the trick and libarchive should collect and accumulate lines with the same filename and only emit or extract a file after the last line with the same name OR when an move= key appears and reset file info immediately after this line. Having a file describing everything that gets installed would also benefit later upgrades to a system. In my experiments I've implemented a manifest that gets shipped with the tarball.tgs (still mean to put it inside but got some ENOTIME errors). My manifest also includes md5 and/or sha256 checksums for each file so the upgrade tool can easily detect which files were altered/moved/removed by the sysadmin an sensibly act accordingly. Again ENOTIME prevented me so far from writing the update tool but I can certainly help out here. If all works out well, this could also benefit ports where a package could be created without installing the port on the build system. Many hurdles to take, I know but certainly a goal to consider. -- Paul Schenkeveld From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 15 18:46: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 A9DC116A401; Sun, 15 Jul 2007 18:46:12 +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 503EA13C4C5; Sun, 15 Jul 2007 18:46:11 +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 l6FIkBH7009292; Sun, 15 Jul 2007 11:46:11 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <469A6B73.1030004@freebsd.org> Date: Sun, 15 Jul 2007 11:46:11 -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: Paul Schenkeveld References: <46992FFF.7010906@kientzle.com> <20070714223853.GF16579@britannica.bec.de> <469992CA.6000104@freebsd.org> <4699BE75.2090808@freebsd.org> <20070715133016.GA53853@psconsult.nl> In-Reply-To: <20070715133016.GA53853@psconsult.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, hackers@freebsd.org Subject: Re: Tar output mode for installworld 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, 15 Jul 2007 18:46:12 -0000 Paul Schenkeveld wrote: >>... read, extract, etc, a format I'm calling "ntree" >>for now. ... lines have the following format: >> = = ... >>Where key is one of: >> time ... gid,uid ... gname,uname ... mode ... content ... > ... I've been playing a lot with automating and customizing > the build/distribute/install process of FreeBSD ... Yes, there are a lot of interesting games you can play if you can build a description of a .tgz file and then handily generate a .tgz file from that description. I was pleased that bsdtar's already-existing "archive conversion" feature made this so simple to implement. > For the $CUSTOMIZATIONS to work it would be very nice to extend your > proposal with the following features: > - Allow scattered lines describing attributes of the same file but > retain the order in which they appear so that $CUSTOMIZATIONS can > override attributes set by make installworld. I already intend to support multiple lines for the same file to allow attributes to be specified separately: file1 type=file mode=04666 file1 uname=root gname=wheel file1 flags=noschg It's trivial to ensure that later options override earlier ones. The tricky part is the word "scattered." This either requires that libarchive read the entire description file into memory up front (awkward, but not particularly unreasonable) or that we have a separate tool that can move those scattered lines so they occur together. (My initial idea was that /usr/bin/sort would suffice, but I don't think it will. In particular, tar requires that hardlinks follow the object being linked to, which is not something that /usr/bin/sort is going to preserve.) > - Implement something like: remove Hmmm... Interesting idea. It would also be interesting to extend the tar format with a "whiteout" entry that erases an entry already on disk. Hmmm.... does this raise any security issues? I'll have to think about that one. Question: Should file1 type=file file1 remove only remove the file from this archive (i.e., not create file1) or should it also look on disk and remove file1 if it's there. Obviously, the latter can only be carried through a .tgz installation file if the tar format supports whiteouts. > - Implement something like: > move= > to allow $CUSTOMIZATIONS to move things around. > A special case here should be observed: > /bin/foo ... > ... > /bin/foo move=/bin/foo.orig > /bin/foo ... Implementable if libarchive read the entire description into memory up front, but otherwise very tricky. Looks like it will be mandatory for the libarchive support to read the entire description into memory so it can preprocess it before returning complete entries. > Having a file describing everything that gets installed would also benefit > later upgrades to a system. One of my questions: Does my proposed format suffice for these other purposes? If not, what other features would be required? Is it worth trying to design a single format that handles these various cases? > In my experiments I've implemented a manifest > that gets shipped with the tarball.tgs ... includes md5 and/or sha256 ... There is some real value to having md5 and/or sha256 checks in generic tar archives as well. I have a couple of ideas for supporting this using pax extensions, but it's tricky to implement robustly, so it's not going to happen for a little while. (In particular, the error check in the tar archive should include all of the headers, and you want to avoid a separate scan of the file to collect an error check before archiving it.) Tim Kientzle From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 15 18:46: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 A9DC116A401; Sun, 15 Jul 2007 18:46:12 +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 503EA13C4C5; Sun, 15 Jul 2007 18:46:11 +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 l6FIkBH7009292; Sun, 15 Jul 2007 11:46:11 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <469A6B73.1030004@freebsd.org> Date: Sun, 15 Jul 2007 11:46:11 -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: Paul Schenkeveld References: <46992FFF.7010906@kientzle.com> <20070714223853.GF16579@britannica.bec.de> <469992CA.6000104@freebsd.org> <4699BE75.2090808@freebsd.org> <20070715133016.GA53853@psconsult.nl> In-Reply-To: <20070715133016.GA53853@psconsult.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, hackers@freebsd.org Subject: Re: Tar output mode for installworld 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, 15 Jul 2007 18:46:12 -0000 Paul Schenkeveld wrote: >>... read, extract, etc, a format I'm calling "ntree" >>for now. ... lines have the following format: >> = = ... >>Where key is one of: >> time ... gid,uid ... gname,uname ... mode ... content ... > ... I've been playing a lot with automating and customizing > the build/distribute/install process of FreeBSD ... Yes, there are a lot of interesting games you can play if you can build a description of a .tgz file and then handily generate a .tgz file from that description. I was pleased that bsdtar's already-existing "archive conversion" feature made this so simple to implement. > For the $CUSTOMIZATIONS to work it would be very nice to extend your > proposal with the following features: > - Allow scattered lines describing attributes of the same file but > retain the order in which they appear so that $CUSTOMIZATIONS can > override attributes set by make installworld. I already intend to support multiple lines for the same file to allow attributes to be specified separately: file1 type=file mode=04666 file1 uname=root gname=wheel file1 flags=noschg It's trivial to ensure that later options override earlier ones. The tricky part is the word "scattered." This either requires that libarchive read the entire description file into memory up front (awkward, but not particularly unreasonable) or that we have a separate tool that can move those scattered lines so they occur together. (My initial idea was that /usr/bin/sort would suffice, but I don't think it will. In particular, tar requires that hardlinks follow the object being linked to, which is not something that /usr/bin/sort is going to preserve.) > - Implement something like: remove Hmmm... Interesting idea. It would also be interesting to extend the tar format with a "whiteout" entry that erases an entry already on disk. Hmmm.... does this raise any security issues? I'll have to think about that one. Question: Should file1 type=file file1 remove only remove the file from this archive (i.e., not create file1) or should it also look on disk and remove file1 if it's there. Obviously, the latter can only be carried through a .tgz installation file if the tar format supports whiteouts. > - Implement something like: > move= > to allow $CUSTOMIZATIONS to move things around. > A special case here should be observed: > /bin/foo ... > ... > /bin/foo move=/bin/foo.orig > /bin/foo ... Implementable if libarchive read the entire description into memory up front, but otherwise very tricky. Looks like it will be mandatory for the libarchive support to read the entire description into memory so it can preprocess it before returning complete entries. > Having a file describing everything that gets installed would also benefit > later upgrades to a system. One of my questions: Does my proposed format suffice for these other purposes? If not, what other features would be required? Is it worth trying to design a single format that handles these various cases? > In my experiments I've implemented a manifest > that gets shipped with the tarball.tgs ... includes md5 and/or sha256 ... There is some real value to having md5 and/or sha256 checks in generic tar archives as well. I have a couple of ideas for supporting this using pax extensions, but it's tricky to implement robustly, so it's not going to happen for a little while. (In particular, the error check in the tar archive should include all of the headers, and you want to avoid a separate scan of the file to collect an error check before archiving it.) Tim Kientzle From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 15 19:14: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 BB7C216A400 for ; Sun, 15 Jul 2007 19:14:53 +0000 (UTC) (envelope-from uspoerlein@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 4896313C471 for ; Sun, 15 Jul 2007 19:14:53 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: by ug-out-1314.google.com with SMTP id o4so957104uge for ; Sun, 15 Jul 2007 12:14:52 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=hKHg4gu23DzfaTO9+BWcpyX3lGGdRSQtggc15S7BVENvFmWsUz/kec/jxFQWchkOYQsookemx6WzNhwPuPtfv+FSSJcUEm/by8l5lX1XaT4nuhTLA2WsOEPKyEo5mvmwppLy3F4Z9r9N4n8gNExyMVcDogM+kp1rJoYUMTmcsG0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:cc:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=YXpnz+dYsvlLkTH61pnRPpCm88gW/4SUHIxs09JOTQhca8LKR6G2dge1A/GsuOrk4k+fvnxExCv6WseZZM6625MiZK1EdurWuY/j/NTQS0u0of5Yd2XnnmuE7QvuNB4ogOJaJLxoRX93eFYv1pOeDtq6kfWgau4B9hL7456/XJM= Received: by 10.86.58.3 with SMTP id g3mr3047249fga.1184525231432; Sun, 15 Jul 2007 11:47:11 -0700 (PDT) Received: from roadrunner.q.local ( [85.180.167.127]) by mx.google.com with ESMTP id v23sm8658388fkd.2007.07.15.11.47.10 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 15 Jul 2007 11:47:10 -0700 (PDT) Received: from roadrunner.q.local (localhost [127.0.0.1]) by roadrunner.q.local (8.14.1/8.14.1) with ESMTP id l6FIl3OH057030; Sun, 15 Jul 2007 20:47:03 +0200 (CEST) (envelope-from uspoerlein@gmail.com) Received: (from q@localhost) by roadrunner.q.local (8.14.1/8.14.1/Submit) id l6FIl3aS057029; Sun, 15 Jul 2007 20:47:03 +0200 (CEST) (envelope-from uspoerlein@gmail.com) Date: Sun, 15 Jul 2007 20:47:03 +0200 From: Ulrich Spoerlein To: Tim Kientzle Message-ID: <20070715184703.GK2819@roadrunner.q.local> Mail-Followup-To: Tim Kientzle , hackers@freebsd.org, Joerg Sonnenberger References: <46992FFF.7010906@kientzle.com> <20070714223853.GF16579@britannica.bec.de> <469992CA.6000104@freebsd.org> <4699BE75.2090808@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4699BE75.2090808@freebsd.org> User-Agent: Mutt/1.5.15 (2007-04-06) Cc: hackers@freebsd.org, Joerg Sonnenberger Subject: Re: Tar output mode for installworld 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, 15 Jul 2007 19:14:53 -0000 On Sat, 14.07.2007 at 23:28:05 -0700, Tim Kientzle wrote: > #%ntree > bin/echo uid=0 gid=0 group=wheel contents=my/bin/echo > > I think this should form a reasonable basis against which > to implement tar output for installworld. I would actually > suggest building the specification file at buildworld time, not > at installworld time. You could then create a tarball with > tar -czf system.tgz @specification.ntree > or install directly from the specification file using > tar -xvpf specification.ntree -C ${DESTDIR} This would be the perfect basis on which to build a live/install release CD. You boot it up on a cd9660 filesystem and put some unionfs hacks on top, to make it fully work as a live cd. After you've done the fdisk/bsdlabel/gmirror/zfs stuff manually or via some yet to be written installer, you then kick of the install through tar. Simple and elegant. It would also do away with those base.aa, base.ab, etc. madness. I like it! Cheers, Ulrich Spoerlein -- "The trouble with the dictionary is you have to know how the word is spelled before you can look it up to see how it is spelled." -- Will Cuppy From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 15 19:42: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 90B2716A400 for ; Sun, 15 Jul 2007 19:42:15 +0000 (UTC) (envelope-from soc@hbar.us) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by mx1.freebsd.org (Postfix) with ESMTP id 3040413C46B for ; Sun, 15 Jul 2007 19:42:13 +0000 (UTC) (envelope-from soc@hbar.us) Received: by ug-out-1314.google.com with SMTP id o4so960405uge for ; Sun, 15 Jul 2007 12:42:13 -0700 (PDT) Received: by 10.78.171.20 with SMTP id t20mr997206hue.1184526944134; Sun, 15 Jul 2007 12:15:44 -0700 (PDT) Received: by 10.78.138.5 with HTTP; Sun, 15 Jul 2007 12:15:44 -0700 (PDT) Message-ID: <47a4f3080707151215t42ed03adp3eab92984e8b670a@mail.gmail.com> Date: Sun, 15 Jul 2007 15:15:44 -0400 From: "Brian Chu" To: "=?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?=" In-Reply-To: <86abvm3k89.fsf@dwp.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <43801.64.117.137.69.1180473436.squirrel@webmail.ifxnw.cl> <86abvm3k89.fsf@dwp.des.no> Cc: freebsd-hackers@freebsd.org, dmw@unete.cl Subject: Re: Setting up development environment 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, 15 Jul 2007 19:42:15 -0000 I have a question about indentation. In the previously supplied .emacs hook, tabs are represented by 8 spaces. Most of the kernel code, however, actually uses the tab character. Are both forms acceptable? If not, anyone willing to share their tab-character-tabs .emacs c hook? Thanks, Brian On 5/30/07, Dag-Erling Sm=F8rgrav wrote: > "Daniel Molina Wegener" writes: > > Is there any official way to setup a development environment for > > FreeBSD. I mean, I want to contribute with FreeBSD development. All > > I know that there is a Developer's Handbook, but what about setting a > > development environment for FreeBSD-CURRENT and -STABLE including > > from official c-mode-hooks and c++-mode-hooks for emacs to environment > > variables for cross-compiling the FreeBSD source. > > Emacs setup (for both C and C++): > > (defun des-knf () > (interactive) > > ;; Basic indent is 8 spaces > (make-local-variable 'c-basic-offset) > (setq c-basic-offset 8) > > ;; Continuation lines are indented 4 spaces > (make-local-variable 'c-offsets-alist) > (c-set-offset 'arglist-cont 4) > (c-set-offset 'arglist-cont-nonempty 4) > (c-set-offset 'statement-cont 4) > > ;; Labels are flush to the left > (c-set-offset 'label [0]) > > ;; Fill column > (make-local-variable 'fill-column) > (setq fill-column 74)) > > (add-hook 'c-mode-common-hook 'des-knf) > > As for how to cross-build, read build(7). > > DES > -- > Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 15 19:44: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 0579F16A403; Sun, 15 Jul 2007 19:44:46 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 6467C13C4A6; Sun, 15 Jul 2007 19:44:45 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from kobe.laptop ([88.218.116.251]) (authenticated bits=128) by igloo.linux.gr (8.13.8/8.13.8/Debian-3) with ESMTP id l6FJiT4v005239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 15 Jul 2007 22:44:35 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.1/8.14.1) with ESMTP id l6FJiS9q007195; Sun, 15 Jul 2007 22:44:29 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.14.1/8.14.1/Submit) id l6FJiS60007194; Sun, 15 Jul 2007 22:44:28 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Date: Sun, 15 Jul 2007 22:44:28 +0300 From: Giorgos Keramidas To: Tim Kientzle Message-ID: <20070715194427.GB7126@kobe.laptop> References: <46992FFF.7010906@kientzle.com> <20070715002708.GA3665@kobe.laptop> <46998A66.4030503@kientzle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46998A66.4030503@kientzle.com> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.5, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.90, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Cc: hackers@FreeBSD.org, rwatson@FreeBSD.org, cperciva@FreeBSD.org Subject: Re: Tar output mode for installworld 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, 15 Jul 2007 19:44:46 -0000 On 2007-07-14 19:45, Tim Kientzle wrote: >On 2007-07-14 13:20, Tim Kientzle wrote: >>> >>> >>> This is easy to implement using a ... text format such as: >>> bin/sh file /usr/obj/usr/src/bin/sh >>> bin/sh uname root >>> rescue/mkdir hardlink rescue/rescue >>> bin/sh mode 0666 >>> bin/rcp mode 04666 > >Giorgos Keramidas responds: >> A packaging list for one of the distributions I've built at work >> includes stuff like: >> # Misc command-line tools in @prefix@/bin/... >> d none @prefix@/bin 0755 root bin >> f none @prefix@/bin/progname-2.0 0755 root bin >> s none @prefix@/bin/progname=progname-2.0 > > My concern is that "all of the bits for one file" may not always be > available at a single place in the build. Some programs use the > "afterinstall" hook to set flags on the installed binary, for example. Ah, I see now :-) Yes, that would not be easy to support with a single-line format, at least not without some sort of post-processing of the file list. But if we *are* going to need postprocessing, it may as well be a multiline format, like the one you suggested. - Giorgos From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 15 20:23: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 7FF0116A402; Sun, 15 Jul 2007 20:23:39 +0000 (UTC) (envelope-from dwmalone@maths.tcd.ie) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.freebsd.org (Postfix) with SMTP id AAB1A13C467; Sun, 15 Jul 2007 20:23:38 +0000 (UTC) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie ([134.226.81.10] helo=walton.maths.tcd.ie) by salmon.maths.tcd.ie with SMTP id ; 15 Jul 2007 21:23:37 +0100 (BST) Date: Sun, 15 Jul 2007 21:23:36 +0100 From: David Malone To: Dominique Goncalves Message-ID: <20070715202336.GA40121@walton.maths.tcd.ie> References: <20070709214216.GA72912@walton.maths.tcd.ie> <20070711132202.GA95487@walton.maths.tcd.ie> <20070712085135.GA5332@walton.maths.tcd.ie> <7daacbbe0707150237gc869abdi756d54219edb2577@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7daacbbe0707150237gc869abdi756d54219edb2577@mail.gmail.com> User-Agent: Mutt/1.5.6i Sender: dwmalone@maths.tcd.ie Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, Ivan Voras Subject: Re: Debugging times 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, 15 Jul 2007 20:23:39 -0000 On Sun, Jul 15, 2007 at 11:37:57AM +0200, Dominique Goncalves wrote: > >Yes, it does! Setting ct.dow to -1 fixes the time in a correct way. > It works also for me with qemu 0.9.0. Great - I'll work on getting it merged in. David. From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 15 20:35: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 01BD016A404 for ; Sun, 15 Jul 2007 20:35:14 +0000 (UTC) (envelope-from maslanbsd@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.227]) by mx1.freebsd.org (Postfix) with ESMTP id B9B3F13C441 for ; Sun, 15 Jul 2007 20:35:13 +0000 (UTC) (envelope-from maslanbsd@gmail.com) Received: by nz-out-0506.google.com with SMTP id l8so623452nzf for ; Sun, 15 Jul 2007 13:35:13 -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=cri5Souar3SB2Is0Br8GrraefZrwkCQCIFHejabIZ1YGrnAWlB58zVCLOq3WkUhx2OPl7ZPSLx7S9DS/mx/UuAgZCPkFWpWVR96wo3t6BR7RapVoe6EQZ0Ok1p358iAxGKKs/k8yi1ESCDGwvc0TcAfs3Uv57cmEzG3r4zEWiF4= 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=jLh5tYJVhpatLHcFJJpJBNMqszMrrAKwFsqjxz6zxr/BXG8u4F5ABSojgy9DLsMiQ6KgUAZAGMsS5xRC9Vl7FIwFqDQHF4dqMMrziUUO2K6P/4q+/ONUT4t9Jkd4bQKKZ+jtQae0gnkzdaVtKWRqYGeXLrlNm5x3P3yCc+R2S2I= Received: by 10.142.157.15 with SMTP id f15mr270068wfe.1184531712695; Sun, 15 Jul 2007 13:35:12 -0700 (PDT) Received: by 10.142.86.18 with HTTP; Sun, 15 Jul 2007 13:35:12 -0700 (PDT) Message-ID: <319cceca0707151335jd8aef89k635d7edb01d08691@mail.gmail.com> Date: Sun, 15 Jul 2007 23:35:12 +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: loading a firmware image 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, 15 Jul 2007 20:35:14 -0000 Hello, What is the best way to load a firmware image (microcode) ? AFAIK I've to load the image file first in memory then call firmware_register() but my problem is how should i load the image in memory ?? Thanks alot -- System Programmer -- I'm Searching For Perfection, So Even If U Need Portability U've To Use Assembly ;-) -- http://libosdk.berlios.de/wiki/ From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 15 21:12:24 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 E930616A400 for ; Sun, 15 Jul 2007 21:12:24 +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 A8E7413C441 for ; Sun, 15 Jul 2007 21:12:24 +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 BEBF020A4; Sun, 15 Jul 2007 23:12:20 +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 388F4208A; Sun, 15 Jul 2007 23:12:20 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 1001) id EEBC8511B; Sun, 15 Jul 2007 23:12:19 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Brian Chu" References: <43801.64.117.137.69.1180473436.squirrel@webmail.ifxnw.cl> <86abvm3k89.fsf@dwp.des.no> <47a4f3080707151215t42ed03adp3eab92984e8b670a@mail.gmail.com> Date: Sun, 15 Jul 2007 23:12:19 +0200 In-Reply-To: <47a4f3080707151215t42ed03adp3eab92984e8b670a@mail.gmail.com> (Brian Chu's message of "Sun\, 15 Jul 2007 15\:15\:44 -0400") Message-ID: <86myxxl6bw.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, dmw@unete.cl Subject: Re: Setting up development environment 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, 15 Jul 2007 21:12:25 -0000 "Brian Chu" writes: > I have a question about indentation. In the previously supplied > .emacs hook, tabs are represented by 8 spaces. No, Emacs automatically converts spaces to tabs according to the current setting of tab-width, which is normally 8. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 15 21:17: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 8019F16A402 for ; Sun, 15 Jul 2007 21:17:47 +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 44D5C13C49D for ; Sun, 15 Jul 2007 21:17:47 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 901131CCE9; Sun, 15 Jul 2007 23:15:49 +0200 (CEST) Date: Sun, 15 Jul 2007 23:15:49 +0200 From: Ed Schouten To: Julian Elischer Message-ID: <20070715211549.GB39075@hoeg.nl> References: <20070705122650.GE1302@britannica.bec.de> <468E16E6.6030608@delphij.net> <20070706112453.GA3217@hoeg.nl> <468E7007.5050607@elischer.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GID0FwUMdk1T2AWN" Content-Disposition: inline In-Reply-To: <468E7007.5050607@elischer.org> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: FreeBSD Hackers Subject: Re: add closefrom() call 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, 15 Jul 2007 21:17:47 -0000 --GID0FwUMdk1T2AWN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Julian Elischer wrote: > Ed Schouten wrote: >> Wouldn't it be better to just implement it through fcntl() and implement >> closefrom() in libc? > > that's a possibility but I personally thing the huge difference in=20 > efficiency > makes it worth putting it in the kernel. > Quite a few programs I know of could really help their startup time with= =20 > this as the first thing they do is "close the first 2000 file descriptors. Woops! Sorry for responding this late, but it looks like I didn't explain myself good enough. Sorry. :) To rephrase myself: Wouldn't it be better to just implement fcntl(..., F_CLOSEM, ...) in the kernel and make closefrom() a simple libc routine: void closefrom(int lowfd) { fcntl(lowfd, F_CLOSEM, NULL); } Similar to creat(2). --=20 Ed Schouten WWW: http://g-rave.nl/ --GID0FwUMdk1T2AWN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGmo6F52SDGA2eCwURAnI2AJ98yhDPAS1zfPnV2Q4oj9QBYQLT0QCfQYlS 8W47SRPeVhjywVixGGKPAFM= =PCd4 -----END PGP SIGNATURE----- --GID0FwUMdk1T2AWN-- From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 15 21:20: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 9A28F16A406 for ; Sun, 15 Jul 2007 21:20:18 +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 743C213C4C3 for ; Sun, 15 Jul 2007 21:20:18 +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 l6FLKHH7010070; Sun, 15 Jul 2007 14:20:18 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <469A8F91.7090509@freebsd.org> Date: Sun, 15 Jul 2007 14:20:17 -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: Ulrich Spoerlein References: <46992FFF.7010906@kientzle.com> <20070714223853.GF16579@britannica.bec.de> <469992CA.6000104@freebsd.org> <4699BE75.2090808@freebsd.org> <20070715184703.GK2819@roadrunner.q.local> In-Reply-To: <20070715184703.GK2819@roadrunner.q.local> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org Subject: Re: Tar output mode for installworld 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, 15 Jul 2007 21:20:18 -0000 Ulrich Spoerlein wrote: > On Sat, 14.07.2007 at 23:28:05 -0700, Tim Kientzle wrote: > >> #%ntree >> bin/echo uid=0 gid=0 group=wheel contents=my/bin/echo >> >> ... create a tarball with >> tar -czf system.tgz @specification.ntree >> or install directly from the specification file using >> tar -xvpf specification.ntree -C ${DESTDIR} > > This would be the perfect basis on which to build a live/install release > CD. You boot it up ... [do] the fdisk/bsdlabel/gmirror/zfs stuff ... > [and] then kick of the install through tar. > > Simple and elegant. It would also do away with those base.aa, base.ab, > etc. madness. I'm confused. base.aa, etc, are a tar file, so I don't entirely understand how this would be different? The current installer does the equivalent of cat base.* | tar -xf - I can see one advantage and one disadvantage of installing a specification file (which references other files) instead: Plus: The specification file can re-use the existing files on CD, so you don't have, e.g., one copy of /bin/sh on the live CD and another buried in base.tgz. This could save space. Minus: Installing a specification file this way would be slower because you then have to read a lot of small files off of CD. Or have I missed something? Tim Kientzle From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 15 21:20: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 63FB416A400 for ; Sun, 15 Jul 2007 21:20:58 +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 1D4C813C48E for ; Sun, 15 Jul 2007 21:20:57 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IABWS-00040k-Q7 for freebsd-hackers@freebsd.org; Sun, 15 Jul 2007 23:20:56 +0200 Received: from 78-0-74-218.adsl.net.t-com.hr ([78.0.74.218]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 15 Jul 2007 23:20:56 +0200 Received: from ivoras by 78-0-74-218.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 15 Jul 2007 23:20:56 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Date: Sun, 15 Jul 2007 23:20:41 +0200 Lines: 28 Message-ID: References: <319cceca0707151335jd8aef89k635d7edb01d08691@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigBC95EC71B32DF13FF4ABF401" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 78-0-74-218.adsl.net.t-com.hr User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) In-Reply-To: <319cceca0707151335jd8aef89k635d7edb01d08691@mail.gmail.com> X-Enigmail-Version: 0.94.3.0 Sender: news Subject: Re: loading a firmware image 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, 15 Jul 2007 21:20:58 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBC95EC71B32DF13FF4ABF401 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Maslan wrote: >my problem is how should i load the image in > memory ?? Have you seen the file2c(1) utility? --------------enigBC95EC71B32DF13FF4ABF401 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGmo+vldnAQVacBcgRAlK9AJ4ihEB09NDQUwdj4PdiJja3ZeKj3wCg2ueK 5wL8/smn4f45M4wzXxD7Xbo= =nPxb -----END PGP SIGNATURE----- --------------enigBC95EC71B32DF13FF4ABF401-- From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 15 21:41: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 8585A16A402 for ; Sun, 15 Jul 2007 21:41:40 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from heff.fud.org.nz (203-109-251-39.static.bliink.ihug.co.nz [203.109.251.39]) by mx1.freebsd.org (Postfix) with ESMTP id 33F7C13C481 for ; Sun, 15 Jul 2007 21:41:40 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id 3FBEE1CC58; Mon, 16 Jul 2007 09:27:57 +1200 (NZST) Date: Mon, 16 Jul 2007 09:27:57 +1200 From: Andrew Thompson To: Maslan Message-ID: <20070715212757.GA17029@heff.fud.org.nz> References: <319cceca0707151335jd8aef89k635d7edb01d08691@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <319cceca0707151335jd8aef89k635d7edb01d08691@mail.gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: FreeBSD Hackers Subject: Re: loading a firmware image 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, 15 Jul 2007 21:41:40 -0000 On Sun, Jul 15, 2007 at 11:35:12PM +0300, Maslan wrote: > Hello, > > What is the best way to load a firmware image (microcode) ? > AFAIK I've to load the image file first in memory then call > firmware_register() but my problem is how should i load the image in > memory ?? The firmware is bundled in a seperate kernel module that can be loaded, read and then unloaded. See src/sys/modules/iwifw/iwi_bss for an example of the Makefile magic that creates the kld. Andrew From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 15 22:13: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 E6D5E16A402 for ; Sun, 15 Jul 2007 22:13:49 +0000 (UTC) (envelope-from maslanbsd@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 A255213C4AC for ; Sun, 15 Jul 2007 22:13:49 +0000 (UTC) (envelope-from maslanbsd@gmail.com) Received: by nz-out-0506.google.com with SMTP id l8so629193nzf for ; Sun, 15 Jul 2007 15:13:48 -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=APzoLQHOJDE0CMj7DPGzdWFhCNmT2r0acUYXb9dtZcTJOaGIzdNUqwtVauHDlyqe/SAzfZIScsFaO1dmq5j4te23/MoEy+M9lb3sraQnz3wpazNo9+iWWmQYODZAnuxcW/NUmX7aceUHyJwQJ5k+OFl3JaDUVfbwD5oC8kB/b4w= 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=BUi0SFGYkvN5JLMnexlpPp1S1JgN0sPQ2vZljXF3xdO1QQICfewU8dI6b414LbTAzRNFzqzfkGOz9LyN60wNvh9WPCm7QASpnmvipgELJm48PMEQN2agtl8h9c1wp7C+cOFS6W4cfGn0zHrhZTn8GD8ClLpiPhDIRSXfsv09bF8= Received: by 10.142.102.5 with SMTP id z5mr272476wfb.1184537627666; Sun, 15 Jul 2007 15:13:47 -0700 (PDT) Received: by 10.142.86.18 with HTTP; Sun, 15 Jul 2007 15:13:47 -0700 (PDT) Message-ID: <319cceca0707151513u4f972f77udb14cb6a18eae6a2@mail.gmail.com> Date: Mon, 16 Jul 2007 01:13:47 +0300 From: Maslan To: "Ivan Voras" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <319cceca0707151335jd8aef89k635d7edb01d08691@mail.gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: loading a firmware image 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, 15 Jul 2007 22:13:50 -0000 > Have you seen the file2c(1) utility? I don't want to run into license troubles. -- System Programmer -- I'm Searching For Perfection, So Even If U Need Portability U've To Use Assembly ;-) -- http://libosdk.berlios.de/wiki/ From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 15 22:16: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 7567C16A524 for ; Sun, 15 Jul 2007 22:16:16 +0000 (UTC) (envelope-from maslanbsd@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.226]) by mx1.freebsd.org (Postfix) with ESMTP id 1499813C4B4 for ; Sun, 15 Jul 2007 22:16:15 +0000 (UTC) (envelope-from maslanbsd@gmail.com) Received: by nz-out-0506.google.com with SMTP id l8so629323nzf for ; Sun, 15 Jul 2007 15:16:15 -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=JIYYCxcFR1H35XbE7OCKKKrCrtVd6+fy5f7bPAwBF6MN3GFPeu0v3ZG58XL1LisVqrlIUYKhRu9kGQOpffYZl+1qT4wGzchYSYK7DPrNWvScAJNHKKGH0MbrnglNVC6NJ8V8cBlmlGCZMZZFYWyF4PtykMKyzt6g6HpM3k74KQQ= 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=NIg63MrdRNcBGuc9FtAfgr2q4lW4TrjZIEof8sMu29+xKNLGrxqcE0vCTTQW0OPml3v8xJaRt0BUjkxAsZ11/uqVKwvgs/T5hvMz9NXmCnROWmPEzq+KZfwYXKb2nXYWVbcHq68oiVyd2U8Db87fl+kOv3YbZDP2SM/PGbdBOQo= Received: by 10.143.42.3 with SMTP id u3mr275261wfj.1184537771530; Sun, 15 Jul 2007 15:16:11 -0700 (PDT) Received: by 10.142.86.18 with HTTP; Sun, 15 Jul 2007 15:16:11 -0700 (PDT) Message-ID: <319cceca0707151516h502fcf42hd7f68e2351120407@mail.gmail.com> Date: Mon, 16 Jul 2007 01:16:11 +0300 From: Maslan To: "Andrew Thompson" In-Reply-To: <20070715212757.GA17029@heff.fud.org.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <319cceca0707151335jd8aef89k635d7edb01d08691@mail.gmail.com> <20070715212757.GA17029@heff.fud.org.nz> Cc: FreeBSD Hackers Subject: Re: loading a firmware image 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, 15 Jul 2007 22:16:17 -0000 > The firmware is bundled in a seperate kernel module that can be loaded, > read and then unloaded. See src/sys/modules/iwifw/iwi_bss for an example > of the Makefile magic that creates the kld. if i wrote FIRMWS = filename:shortname:version in the Makefile then i should user firmware_get("shortname") rather than firmware_register(), is it right ?? -- System Programmer -- I'm Searching For Perfection, So Even If U Need Portability U've To Use Assembly ;-) -- http://libosdk.berlios.de/wiki/ From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 15 23:51: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 F049D16A402 for ; Sun, 15 Jul 2007 23:51:12 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outR.internet-mail-service.net (outR.internet-mail-service.net [216.240.47.241]) by mx1.freebsd.org (Postfix) with ESMTP id D982D13C478 for ; Sun, 15 Jul 2007 23:51:12 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Sun, 15 Jul 2007 16:51:12 -0700 Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 30811125ADC; Sun, 15 Jul 2007 16:51:11 -0700 (PDT) Message-ID: <469AB30A.5000001@elischer.org> Date: Sun, 15 Jul 2007 16:51:38 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Ed Schouten References: <20070705122650.GE1302@britannica.bec.de> <468E16E6.6030608@delphij.net> <20070706112453.GA3217@hoeg.nl> <468E7007.5050607@elischer.org> <20070715211549.GB39075@hoeg.nl> In-Reply-To: <20070715211549.GB39075@hoeg.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Hackers Subject: Re: add closefrom() call 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, 15 Jul 2007 23:51:13 -0000 Ed Schouten wrote: > * Julian Elischer wrote: >> Ed Schouten wrote: >>> Wouldn't it be better to just implement it through fcntl() and implement >>> closefrom() in libc? >> that's a possibility but I personally thing the huge difference in >> efficiency >> makes it worth putting it in the kernel. >> Quite a few programs I know of could really help their startup time with >> this as the first thing they do is "close the first 2000 file descriptors. > > Woops! Sorry for responding this late, but it looks like I didn't > explain myself good enough. Sorry. :) To rephrase myself: > > Wouldn't it be better to just implement fcntl(..., F_CLOSEM, ...) in the > kernel and make closefrom() a simple libc routine: > > void > closefrom(int lowfd) > { > fcntl(lowfd, F_CLOSEM, NULL); > } > what on earth would that achieve? (as opposed to just a simple syscall) > Similar to creat(2). > From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 16 00:32: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 7C1C516A401 for ; Mon, 16 Jul 2007 00:32:47 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 4B9D413C48E for ; Mon, 16 Jul 2007 00:32:47 +0000 (UTC) (envelope-from sam@errno.com) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id l6G0BDBZ056570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Jul 2007 17:11:13 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <469AB840.50103@errno.com> Date: Sun, 15 Jul 2007 17:13:52 -0700 From: Sam Leffler User-Agent: Thunderbird 2.0.0.0 (X11/20070530) MIME-Version: 1.0 To: Maslan References: <319cceca0707151335jd8aef89k635d7edb01d08691@mail.gmail.com> <20070715212757.GA17029@heff.fud.org.nz> <319cceca0707151516h502fcf42hd7f68e2351120407@mail.gmail.com> In-Reply-To: <319cceca0707151516h502fcf42hd7f68e2351120407@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Hackers , Andrew Thompson Subject: Re: loading a firmware image 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, 16 Jul 2007 00:32:47 -0000 Maslan wrote: >> The firmware is bundled in a seperate kernel module that can be loaded, >> read and then unloaded. See src/sys/modules/iwifw/iwi_bss for an example >> of the Makefile magic that creates the kld. > > if i wrote FIRMWS = filename:shortname:version in the Makefile > then i should user firmware_get("shortname") rather than > firmware_register(), is it right ?? > > firmware_register is emitted by the Makefile and used by the kld to register the firmware image under "shortname". Once the image is registered then other code in the kernel can get a reference to the image with firmware_get. firmware(9) is a pretty complete description of these facilities. Sam From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 16 01:14: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 7EB1F16A404 for ; Mon, 16 Jul 2007 01:14:39 +0000 (UTC) (envelope-from soc@hbar.us) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.173]) by mx1.freebsd.org (Postfix) with ESMTP id 1D26013C46B for ; Mon, 16 Jul 2007 01:14:38 +0000 (UTC) (envelope-from soc@hbar.us) Received: by ug-out-1314.google.com with SMTP id o4so991738uge for ; Sun, 15 Jul 2007 18:14:37 -0700 (PDT) Received: by 10.78.166.7 with SMTP id o7mr1049847hue.1184548477565; Sun, 15 Jul 2007 18:14:37 -0700 (PDT) Received: by 10.78.138.5 with HTTP; Sun, 15 Jul 2007 18:14:37 -0700 (PDT) Message-ID: <47a4f3080707151814w6a37a3c3pda244849efa507a8@mail.gmail.com> Date: Sun, 15 Jul 2007 21:14:37 -0400 From: "Brian Chu" To: "=?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?=" In-Reply-To: <86myxxl6bw.fsf@dwp.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <43801.64.117.137.69.1180473436.squirrel@webmail.ifxnw.cl> <86abvm3k89.fsf@dwp.des.no> <47a4f3080707151215t42ed03adp3eab92984e8b670a@mail.gmail.com> <86myxxl6bw.fsf@dwp.des.no> Cc: freebsd-hackers@freebsd.org, dmw@unete.cl Subject: Re: Setting up development environment 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, 16 Jul 2007 01:14:39 -0000 Hm. It doesn't always replace 8 spaces with tabs (for files that are heavily spaced-indented), but I suppose that using `M-x tabify` would do the trick. Thanks! Brian On 7/15/07, Dag-Erling Sm=F8rgrav wrote: > "Brian Chu" writes: > > I have a question about indentation. In the previously supplied > > .emacs hook, tabs are represented by 8 spaces. > > No, Emacs automatically converts spaces to tabs according to the current > setting of tab-width, which is normally 8. > > DES > -- > Dag-Erling Sm=F8rgrav - des@des.no > From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 16 02:17:50 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 C5BEA16A404; Mon, 16 Jul 2007 02:17:50 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from ns.trinitel.com (186.161.36.72.static.reverse.layeredtech.com [72.36.161.186]) by mx1.freebsd.org (Postfix) with ESMTP id 995BB13C4D1; Mon, 16 Jul 2007 02:17:50 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from neutrino.vnode.org (r74-193-81-203.pfvlcmta01.grtntx.tl.dh.suddenlink.net [74.193.81.203]) (authenticated bits=0) by ns.trinitel.com (8.14.1/8.14.1) with ESMTP id l6G21N6f009948 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Sun, 15 Jul 2007 21:01:23 -0500 (CDT) (envelope-from anderson@freebsd.org) Message-ID: <469AD16E.5050106@freebsd.org> Date: Sun, 15 Jul 2007 21:01:18 -0500 From: Eric Anderson User-Agent: Thunderbird 2.0.0.4 (X11/20070629) MIME-Version: 1.0 To: Tim Kientzle References: <46992FFF.7010906@kientzle.com> <20070714223853.GF16579@britannica.bec.de> <469992CA.6000104@freebsd.org> <4699BE75.2090808@freebsd.org> <20070715184703.GK2819@roadrunner.q.local> <469A8F91.7090509@freebsd.org> In-Reply-To: <469A8F91.7090509@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on ns.trinitel.com Cc: hackers@freebsd.org Subject: Re: Tar output mode for installworld 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, 16 Jul 2007 02:17:50 -0000 On 07/15/07 16:20, Tim Kientzle wrote: > Ulrich Spoerlein wrote: >> On Sat, 14.07.2007 at 23:28:05 -0700, Tim Kientzle wrote: >> >>> #%ntree >>> bin/echo uid=0 gid=0 group=wheel contents=my/bin/echo >>> >>> ... create a tarball with >>> tar -czf system.tgz @specification.ntree >>> or install directly from the specification file using >>> tar -xvpf specification.ntree -C ${DESTDIR} >> This would be the perfect basis on which to build a live/install release >> CD. You boot it up ... [do] the fdisk/bsdlabel/gmirror/zfs stuff ... > > [and] then kick of the install through tar. >> Simple and elegant. It would also do away with those base.aa, base.ab, >> etc. madness. > > I'm confused. base.aa, etc, are a tar file, so I don't > entirely understand how this would be different? The > current installer does the equivalent of > cat base.* | tar -xf - > > I can see one advantage and one disadvantage of installing > a specification file (which references other files) instead: > > Plus: The specification file can re-use the existing > files on CD, so you don't have, e.g., one copy of /bin/sh > on the live CD and another buried in base.tgz. This > could save space. > > Minus: Installing a specification file this way would > be slower because you then have to read a lot of small > files off of CD. > > Or have I missed something? Or, when the day comes that my tarfs implementation is in the tree and root booting enabled, you boot the tar file as the root fs, and use that same tar file to build the system too. :) Eric From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 16 03:31:07 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 AFB5616A406; Mon, 16 Jul 2007 03:31:07 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 608DB13C4B7; Mon, 16 Jul 2007 03:31:07 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.8/8.13.4) with ESMTP id l6G3UnAR020217; Sun, 15 Jul 2007 21:30:50 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 15 Jul 2007 21:30:54 -0600 (MDT) Message-Id: <20070715.213054.-593221341.imp@bsdimp.com> To: fb-hackers@psconsult.nl From: "M. Warner Losh" In-Reply-To: <20070715133016.GA53853@psconsult.nl> References: <469992CA.6000104@freebsd.org> <4699BE75.2090808@freebsd.org> <20070715133016.GA53853@psconsult.nl> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Sun, 15 Jul 2007 21:30:51 -0600 (MDT) Cc: freebsd-hackers@freebsd.org, hackers@freebsd.org Subject: Re: Tar output mode for installworld 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, 16 Jul 2007 03:31:07 -0000 In message: <20070715133016.GA53853@psconsult.nl> Paul Schenkeveld writes: : On Sat, Jul 14, 2007 at 11:28:05PM -0700, Tim Kientzle wrote: : > >>>This is easy to implement ... just build : > >>>a description of the final archive in a nice verbose : > >>>text format such as: : > >> : > >>...which is done by NetBSD for the unprivileged release building via : > >>build.sh. Anyone interested in working on this should possibly have a : > >>look there. : > : > Here's a rough implementation of my core idea. Add the : > attached archive_read_support_format_ntree.c to libarchive : > and patch archive_read_support_format_all.c, then : > rebuild libarchive and bsdtar. You'll then be able : > to read, extract, etc, a format I'm calling "ntree" : > for now. This similar to NetBSD's "metalog" format, except: : > : > 1) First line must be "#%ntree". This is used as a file signature. : > : > 2) Blank lines and lines beginning with '#' are ignored. : > : > 3) All other lines have the following format: : > : > = = ... : > : > Where key is one of: : > time: decimal seconds since beginning of epoch : > gid,uid: decimal group/user ID : > gname,uname: textual group/user name : > mode: octal : > type: as in mtree, defaults to 'file' : > content: name of a file on disk : : Great! : : This is exactly the next BIG step in (Free)BSD build/distribute/install : that I have been waiting for. In the mean time I've been playing a lot : with automating and customizing the build/distribute/install process : of FreeBSD, partly inspired by nanobsd. : : Basically the process is something like: : : __MAKE_CONF=my_make.conf make buildworld : __MAKE_CONF=my_make.conf make installworld DESTDIR=/some/place : $CUSTOMIZATIONS /some/place : tar czf tarball.tgz -C /some/place : # Find a way to get the tarball.tgz to its destination : tar xpf tarball.tgz # at the destination : : For the $CUSTOMIZATIONS to work it would be very nice to extend your : proposal with the following features: : : - Allow scattered lines describing attributes of the same file but : retain the order in which they appear so that $CUSTOMIZATIONS can : override attributes set by make installworld. : : - Implement something like: : remove : to undo the installation of files (embedded systems hardly ever : need stuff like documentation, NLS and so on but the make.conf and : src.conf knobs are not fine-grained enough for all situations) : : - Implement something like: : move= : to allow $CUSTOMIZATIONS to move things around. : A special case here should be observed: : /bin/foo ... : ... : /bin/foo move=/bin/foo.orig : /bin/foo ... : here the $CUSTOMIZATIONS move some file so another place and installs : a wrapper. Probably a sorting algorithm that retains the order in : which /bin/foo lines appear does half the trick and libarchive should : collect and accumulate lines with the same filename and only emit or : extract a file after the last line with the same name OR when an move= : key appears and reset file info immediately after this line. : : Having a file describing everything that gets installed would also benefit : later upgrades to a system. In my experiments I've implemented a manifest : that gets shipped with the tarball.tgs (still mean to put it inside but : got some ENOTIME errors). My manifest also includes md5 and/or sha256 : checksums for each file so the upgrade tool can easily detect which files : were altered/moved/removed by the sysadmin an sensibly act accordingly. : Again ENOTIME prevented me so far from writing the update tool but I can : certainly help out here. : : If all works out well, this could also benefit ports where a package : could be created without installing the port on the build system. Many : hurdles to take, I know but certainly a goal to consider. I've done something similar to what you suggest here. Let me recount what our build process does at work. I like the idea of having an unprivileged environment, but I see some problems with it. Maybe the problems I see are due to my experiences at work where we've been building 13-20MB freebsd systems for the past 8 years. First, we checkout a FreeBSD source tree into /some/place/chroot/usr/src. We do a buildworld, and installworld into /some/place/chroot. We then use that chroot to build our software. We do the chroot process for multiple reasons. First, we insulate the build process from the machine we're building on 100% this way. *EVERYTHING* builds inside the chroot, which means there's no chance of host contamination. Doing this 'heavy weight' solution has a large number of advantages, since one gets to tailor the ports and other packages installed very precisely. It also allows us to build different products at different revisions all on the same machine. It is not uncommon for me to have 15 different product versions being built at the same time, all of them with variant ports versions, ports configurations, and in some cases FreeBSD configurations. The other big advantage of doing this is that it requires no special tools, apart from the build harness. All the normal FreeBSD install processes work. All the ports install processes work. There's no need to worry that this one uses tar, and that one uses cpio and this other one uses bsdinstall. They all install into /some/place/chroot/image/... with the very low threshold of 'supports DESTDIR' or 'can be made to act like they support DESTDIR'. Since we do this, subsetting turns out to be trivial. One just needs to have a list of directories to do the install. One icky part of what we do is our mtree stuff. We lay down FreeBSD, with the subset of directories, and then use mtree files to remove all files that don't appear in the mtree file. We do this before we install the packages we build and the custom software we put onto the device. There's a second mtree pass that we use to put things like dev nodes (<= 4.x) and symlinks into place. All of these things are nice and easy, but many require root. We have to give all the developers on our servers root. This is OK for us because if we don't trust you with root, you wouldn't have a job with us (and if you repeatedly abuse it, you will be out the door too). We mitigate it by doing everything through sudo, which logs everything. While it would be nice to have it be done w/o privileges, chroot absolutely requires root. I'm guessing that it would be hard to have the nice benefits of a chroot in an unprivileged environment. You can get the simple 'use these files' stuff, but being able to reproduce files down to the same md5 even after upgrading the server is a bid advantage. Warner From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 16 03:31: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 AFB5616A406; Mon, 16 Jul 2007 03:31:07 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 608DB13C4B7; Mon, 16 Jul 2007 03:31:07 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.8/8.13.4) with ESMTP id l6G3UnAR020217; Sun, 15 Jul 2007 21:30:50 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 15 Jul 2007 21:30:54 -0600 (MDT) Message-Id: <20070715.213054.-593221341.imp@bsdimp.com> To: fb-hackers@psconsult.nl From: "M. Warner Losh" In-Reply-To: <20070715133016.GA53853@psconsult.nl> References: <469992CA.6000104@freebsd.org> <4699BE75.2090808@freebsd.org> <20070715133016.GA53853@psconsult.nl> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Sun, 15 Jul 2007 21:30:51 -0600 (MDT) Cc: freebsd-hackers@freebsd.org, hackers@freebsd.org Subject: Re: Tar output mode for installworld 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, 16 Jul 2007 03:31:07 -0000 In message: <20070715133016.GA53853@psconsult.nl> Paul Schenkeveld writes: : On Sat, Jul 14, 2007 at 11:28:05PM -0700, Tim Kientzle wrote: : > >>>This is easy to implement ... just build : > >>>a description of the final archive in a nice verbose : > >>>text format such as: : > >> : > >>...which is done by NetBSD for the unprivileged release building via : > >>build.sh. Anyone interested in working on this should possibly have a : > >>look there. : > : > Here's a rough implementation of my core idea. Add the : > attached archive_read_support_format_ntree.c to libarchive : > and patch archive_read_support_format_all.c, then : > rebuild libarchive and bsdtar. You'll then be able : > to read, extract, etc, a format I'm calling "ntree" : > for now. This similar to NetBSD's "metalog" format, except: : > : > 1) First line must be "#%ntree". This is used as a file signature. : > : > 2) Blank lines and lines beginning with '#' are ignored. : > : > 3) All other lines have the following format: : > : > = = ... : > : > Where key is one of: : > time: decimal seconds since beginning of epoch : > gid,uid: decimal group/user ID : > gname,uname: textual group/user name : > mode: octal : > type: as in mtree, defaults to 'file' : > content: name of a file on disk : : Great! : : This is exactly the next BIG step in (Free)BSD build/distribute/install : that I have been waiting for. In the mean time I've been playing a lot : with automating and customizing the build/distribute/install process : of FreeBSD, partly inspired by nanobsd. : : Basically the process is something like: : : __MAKE_CONF=my_make.conf make buildworld : __MAKE_CONF=my_make.conf make installworld DESTDIR=/some/place : $CUSTOMIZATIONS /some/place : tar czf tarball.tgz -C /some/place : # Find a way to get the tarball.tgz to its destination : tar xpf tarball.tgz # at the destination : : For the $CUSTOMIZATIONS to work it would be very nice to extend your : proposal with the following features: : : - Allow scattered lines describing attributes of the same file but : retain the order in which they appear so that $CUSTOMIZATIONS can : override attributes set by make installworld. : : - Implement something like: : remove : to undo the installation of files (embedded systems hardly ever : need stuff like documentation, NLS and so on but the make.conf and : src.conf knobs are not fine-grained enough for all situations) : : - Implement something like: : move= : to allow $CUSTOMIZATIONS to move things around. : A special case here should be observed: : /bin/foo ... : ... : /bin/foo move=/bin/foo.orig : /bin/foo ... : here the $CUSTOMIZATIONS move some file so another place and installs : a wrapper. Probably a sorting algorithm that retains the order in : which /bin/foo lines appear does half the trick and libarchive should : collect and accumulate lines with the same filename and only emit or : extract a file after the last line with the same name OR when an move= : key appears and reset file info immediately after this line. : : Having a file describing everything that gets installed would also benefit : later upgrades to a system. In my experiments I've implemented a manifest : that gets shipped with the tarball.tgs (still mean to put it inside but : got some ENOTIME errors). My manifest also includes md5 and/or sha256 : checksums for each file so the upgrade tool can easily detect which files : were altered/moved/removed by the sysadmin an sensibly act accordingly. : Again ENOTIME prevented me so far from writing the update tool but I can : certainly help out here. : : If all works out well, this could also benefit ports where a package : could be created without installing the port on the build system. Many : hurdles to take, I know but certainly a goal to consider. I've done something similar to what you suggest here. Let me recount what our build process does at work. I like the idea of having an unprivileged environment, but I see some problems with it. Maybe the problems I see are due to my experiences at work where we've been building 13-20MB freebsd systems for the past 8 years. First, we checkout a FreeBSD source tree into /some/place/chroot/usr/src. We do a buildworld, and installworld into /some/place/chroot. We then use that chroot to build our software. We do the chroot process for multiple reasons. First, we insulate the build process from the machine we're building on 100% this way. *EVERYTHING* builds inside the chroot, which means there's no chance of host contamination. Doing this 'heavy weight' solution has a large number of advantages, since one gets to tailor the ports and other packages installed very precisely. It also allows us to build different products at different revisions all on the same machine. It is not uncommon for me to have 15 different product versions being built at the same time, all of them with variant ports versions, ports configurations, and in some cases FreeBSD configurations. The other big advantage of doing this is that it requires no special tools, apart from the build harness. All the normal FreeBSD install processes work. All the ports install processes work. There's no need to worry that this one uses tar, and that one uses cpio and this other one uses bsdinstall. They all install into /some/place/chroot/image/... with the very low threshold of 'supports DESTDIR' or 'can be made to act like they support DESTDIR'. Since we do this, subsetting turns out to be trivial. One just needs to have a list of directories to do the install. One icky part of what we do is our mtree stuff. We lay down FreeBSD, with the subset of directories, and then use mtree files to remove all files that don't appear in the mtree file. We do this before we install the packages we build and the custom software we put onto the device. There's a second mtree pass that we use to put things like dev nodes (<= 4.x) and symlinks into place. All of these things are nice and easy, but many require root. We have to give all the developers on our servers root. This is OK for us because if we don't trust you with root, you wouldn't have a job with us (and if you repeatedly abuse it, you will be out the door too). We mitigate it by doing everything through sudo, which logs everything. While it would be nice to have it be done w/o privileges, chroot absolutely requires root. I'm guessing that it would be hard to have the nice benefits of a chroot in an unprivileged environment. You can get the simple 'use these files' stuff, but being able to reproduce files down to the same md5 even after upgrading the server is a bid advantage. Warner From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 16 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 D4B6716A404 for ; Mon, 16 Jul 2007 03:34:20 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 77CE713C46B for ; Mon, 16 Jul 2007 03:34:20 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.8/8.13.4) with ESMTP id l6G3Wpgt020224; Sun, 15 Jul 2007 21:32:54 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 15 Jul 2007 21:32:56 -0600 (MDT) Message-Id: <20070715.213256.-1947358182.imp@bsdimp.com> To: soc@hbar.us From: "M. Warner Losh" In-Reply-To: <47a4f3080707151215t42ed03adp3eab92984e8b670a@mail.gmail.com> References: <43801.64.117.137.69.1180473436.squirrel@webmail.ifxnw.cl> <86abvm3k89.fsf@dwp.des.no> <47a4f3080707151215t42ed03adp3eab92984e8b670a@mail.gmail.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Sun, 15 Jul 2007 21:32:55 -0600 (MDT) Cc: des@des.no, dmw@unete.cl, freebsd-hackers@freebsd.org Subject: Re: Setting up development environment 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, 16 Jul 2007 03:34:20 -0000 In message: <47a4f3080707151215t42ed03adp3eab92984e8b670a@mail.gmail.co= m> "Brian Chu" writes: : I have a question about indentation. In the previously supplied : .emacs hook, tabs are represented by 8 spaces. Most of the kernel : code, however, actually uses the tab character. : = : Are both forms acceptable? If not, anyone willing to share their : tab-character-tabs .emacs c hook? Use hard tabs. Don't use spaces, since they cause more problems than the tabs. The big problem is that emacs likes to 'reformat' adjacent lines if you have the settings to use spaces. Warner : Thanks, : Brian : = : On 5/30/07, Dag-Erling Sm=F8rgrav wrote: : > "Daniel Molina Wegener" writes: : > > Is there any official way to setup a development environment f= or : > > FreeBSD. I mean, I want to contribute with FreeBSD development. A= ll : > > I know that there is a Developer's Handbook, but what about setti= ng a : > > development environment for FreeBSD-CURRENT and -STABLE including= : > > from official c-mode-hooks and c++-mode-hooks for emacs to enviro= nment : > > variables for cross-compiling the FreeBSD source. : > : > Emacs setup (for both C and C++): : > : > (defun des-knf () : > (interactive) : > : > ;; Basic indent is 8 spaces : > (make-local-variable 'c-basic-offset) : > (setq c-basic-offset 8) : > : > ;; Continuation lines are indented 4 spaces : > (make-local-variable 'c-offsets-alist) : > (c-set-offset 'arglist-cont 4) : > (c-set-offset 'arglist-cont-nonempty 4) : > (c-set-offset 'statement-cont 4) : > : > ;; Labels are flush to the left : > (c-set-offset 'label [0]) : > : > ;; Fill column : > (make-local-variable 'fill-column) : > (setq fill-column 74)) : > : > (add-hook 'c-mode-common-hook 'des-knf) : > : > As for how to cross-build, read build(7). : > : > DES : > -- : > Dag-Erling Sm=F8rgrav - des@des.no : _______________________________________________ : 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" : = From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 16 04:24: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 95F0B16A400 for ; Mon, 16 Jul 2007 04:24:20 +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 5D39113C4A5 for ; Mon, 16 Jul 2007 04:24:20 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 681AE1CCE0; Mon, 16 Jul 2007 06:22:16 +0200 (CEST) Date: Mon, 16 Jul 2007 06:22:16 +0200 From: Ed Schouten To: Julian Elischer Message-ID: <20070716042216.GD39075@hoeg.nl> References: <20070705122650.GE1302@britannica.bec.de> <468E16E6.6030608@delphij.net> <20070706112453.GA3217@hoeg.nl> <468E7007.5050607@elischer.org> <20070715211549.GB39075@hoeg.nl> <469AB30A.5000001@elischer.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eqp4TxRxnD4KrmFZ" Content-Disposition: inline In-Reply-To: <469AB30A.5000001@elischer.org> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: FreeBSD Hackers Subject: Re: add closefrom() call 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, 16 Jul 2007 04:24:20 -0000 --eqp4TxRxnD4KrmFZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Julian Elischer wrote: > Ed Schouten wrote: >> Woops! Sorry for responding this late, but it looks like I didn't >> explain myself good enough. Sorry. :) To rephrase myself: >> Wouldn't it be better to just implement fcntl(..., F_CLOSEM, ...) in the >> kernel and make closefrom() a simple libc routine: >> void >> closefrom(int lowfd) >> { >> fcntl(lowfd, F_CLOSEM, NULL); >> } > > what on earth would that achieve? > (as opposed to just a simple syscall) Compatability with an existing implementation. --=20 Ed Schouten WWW: http://g-rave.nl/ --eqp4TxRxnD4KrmFZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGmvJ452SDGA2eCwURAur1AJ9e5Ft+T1fBTT4TQVMUMsu09cIlbACfQJw3 fsqdT2FgEfMFREZ/8FzcoGQ= =rXxf -----END PGP SIGNATURE----- --eqp4TxRxnD4KrmFZ-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 16 04:12: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 E441216A403; Mon, 16 Jul 2007 04:12:18 +0000 (UTC) (envelope-from snezhko@indorsoft.ru) Received: from indorsoft.ru (indor.net.tomline.ru [213.183.100.90]) by mx1.freebsd.org (Postfix) with ESMTP id 090D513C481; Mon, 16 Jul 2007 04:12:17 +0000 (UTC) (envelope-from snezhko@indorsoft.ru) Received: from SNEZHKO by indorsoft.ru (MDaemon.PRO.v7.2.2.R) with ESMTP id md50000220503.msg; Mon, 16 Jul 2007 11:12:12 +0700 From: Victor Snezhko To: David Malone References: <20070709214216.GA72912@walton.maths.tcd.ie> <20070711132202.GA95487@walton.maths.tcd.ie> Date: Mon, 16 Jul 2007 11:12:07 +0700 In-Reply-To: <20070711132202.GA95487@walton.maths.tcd.ie> (David Malone's message of "Wed, 11 Jul 2007 14:22:02 +0100") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (windows-nt) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Processed: indor.net.tomline.ru, Mon, 16 Jul 2007 11:12:13 +0700 (not processed: spam filter disabled) X-Return-Path: snezhko@indorsoft.ru X-Mailman-Approved-At: Mon, 16 Jul 2007 04:56:38 +0000 Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, Ivan Voras Subject: Re: Debugging times 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, 16 Jul 2007 04:12:19 -0000 David Malone writes: >> Yes, I'll test them. >> >> The problem is - the same kernel works when booted off a hard drive, so >> unless the VMWare BIOS is very messed up (it's the first time I see such >> problems) it may not help. Please, scatter debug printf's around so I >> can see what's going on :) > > Try the patch at: > > http://www.maths.tcd.ie/~dwmalone/clock.patch > > It checks the return values of the various clock reading functions > in the kernel and prints an error message if it finds that it can't > set the clock OK. Some machines have a BIOS that doesn't count the > day-of-week correctly, and recently FreeBSD has started treating > this as an error on some platforms. Just a "mee too" - I've been suffering from precisely this problem - on a hardware box, not vmware. I have instrumented clock_ts_to_ct in my kernel to see what happens, and yes, ct.dow is 0 today, on monday, and day_of_week(days) expects 1. I couldn't find on what day of week dow should be 0 anywhere in the specs - on sunday or on monday - so probably there are just bioses that behave differently in this respect. Thanks for clarifying the issue. Also, this was a surprise to an unexperienced me, but I have also found that vfs_mount initializes RTC with the latest timestamp found on local file systems - this explains why kernel "worked" for Ivan on a hard drive. It didn't actually work, but used timestamp which was stored on filesystem during unmount. -- WBR, Victor V. Snezhko E-mail: snezhko@indorsoft.ru From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 16 06:03: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 A5F3416A405 for ; Mon, 16 Jul 2007 06:03:14 +0000 (UTC) (envelope-from james.shank@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.244]) by mx1.freebsd.org (Postfix) with ESMTP id 572A513C4BB for ; Mon, 16 Jul 2007 06:03:14 +0000 (UTC) (envelope-from james.shank@gmail.com) Received: by an-out-0708.google.com with SMTP id c14so246981anc for ; Sun, 15 Jul 2007 23:03:13 -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=hgBhhVJG/CGdx/C3G1s++U43xEpmG8ae6pwk+L5LKxdhYzmLGedTMpM8jZWPIFKniz++3WGD5AB3WNQrc9QmXZ7MD9IFamQofwiehk2D9eol0f+ROROSrA1oKWXVbewzlsQYHcTx8cKU2RnFPyIQee8RQ1DppRUX/GuoICnpZqY= 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=rDrqx4z9TZuRrB+OqPhWako/y8futWClHNP+9aQAGITlwlOlDECJs7PhERbCL11tfjIrZcWXm5kCcQ5nafZFCQqdb22e0Pyw4w/oZiDByJE0ZbfBGoQCVFg70+IwfMFMSC9rQoSBzuYOsWV8+yfwewKhqOeMSShqKyLjmhnAv6w= Received: by 10.100.95.19 with SMTP id s19mr2114828anb.1184564260994; Sun, 15 Jul 2007 22:37:40 -0700 (PDT) Received: by 10.100.198.5 with HTTP; Sun, 15 Jul 2007 22:37:40 -0700 (PDT) Message-ID: Date: Mon, 16 Jul 2007 00:37:40 -0500 From: "James Shank" To: freebsd-hackers@freebsd.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_49325_7545213.1184564260951" References: Subject: Problem with Broadcom 5704 B1 on amd64 6.2 release 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, 16 Jul 2007 06:03:14 -0000 ------=_Part_49325_7545213.1184564260951 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Greetings, I've run into a problem with the onboard Broadcom 5704 NetXtreme nics on a Tyan S2891 Thunder K8SRE motherboard. Here is the relevant dmesg output to show the error: pcib5: at device 11.0 on pci8 pci10: on pcib5 pcib5: memory: end (de1fffff) < start (48739b2de100000) pcib5: memory: end (de1fffff) < start (dbca73fdde110000) bge0: mem 0x48739b2de100000-0x48739b2de10ffff irq 28 at device 9.0 on pci10 pcib5: memory: end (de1fffff) < start (48739b2de100000) bge0: couldn't map memory device_attach: bge0 attach returned 6 bge1: mem 0xdbca73fdde110000-0xdbca73fdde11ffff irq 29 at device 9.1 on pci10 pcib5: memory: end (de1fffff) < start (dbca73fdde110000) bge1: couldn't map memory device_attach: bge1 attach returned 6 It appears to me that the problem might be due to using a 32-bit int for end addresses where it looks like the start address uses 64-bit int. Any input on how to proceed would be greatly appreciated. I've also attached full dmesg output as well as pciconf -l -v output. Thanks! -James ------=_Part_49325_7545213.1184564260951 Content-Type: application/octet-stream; name=dmesg.out Content-Transfer-Encoding: base64 X-Attachment-Id: f_f42w1xce Content-Disposition: attachment; filename="dmesg.out" Q29weXJpZ2h0IChjKSAxOTkyLTIwMDcgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChj KSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAx OTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLgpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgVGhlIEZy ZWVCU0QgRm91bmRhdGlvbi4KRnJlZUJTRCA2LjItUkVMRUFTRSAjMDogVHVlIEp1bCAxMCAxNDo1 ODoxNCBVVEMgMjAwNwogICAgcm9vdEA6L3Vzci9zcmMvc3lzL2FtZDY0L2NvbXBpbGUvU01QCkFD UEkgQVBJQyBUYWJsZTogPFBUTFREICAJIEFQSUMgID4KVGltZWNvdW50ZXIgImk4MjU0IiBmcmVx dWVuY3kgMTE5MzE4MiBIeiBxdWFsaXR5IDAKQ1BVOiBEdWFsIENvcmUgQU1EIE9wdGVyb24odG0p IFByb2Nlc3NvciAyODUgKDI2MTIuMDUtTUh6IEs4LWNsYXNzIENQVSkKICBPcmlnaW4gPSAiQXV0 aGVudGljQU1EIiAgSWQgPSAweDIwZjEyICBTdGVwcGluZyA9IDIKICBGZWF0dXJlcz0weDE3OGJm YmZmPEZQVSxWTUUsREUsUFNFLFRTQyxNU1IsUEFFLE1DRSxDWDgsQVBJQyxTRVAsTVRSUixQR0Us TUNBLENNT1YsUEFULFBTRTM2LENMRkxVU0gsTU1YLEZYU1IsU1NFLFNTRTIsSFRUPgogIEZlYXR1 cmVzMj0weDE8U1NFMz4KICBBTUQgRmVhdHVyZXM9MHhlMjUwMDgwMDxTWVNDQUxMLE5YLE1NWCss RkZYU1IsTE0sM0ROb3crLDNETm93PgogIEFNRCBGZWF0dXJlczI9MHgzPExBSEYsQ01QPgogIENv cmVzIHBlciBwYWNrYWdlOiAyCnJlYWwgbWVtb3J5ICA9IDM0ODg2Nzc4ODggKDMzMjcgTUIpCmF2 YWlsIG1lbW9yeSA9IDMzNjM3OTQ5NDQgKDMyMDcgTUIpCkZyZWVCU0QvU01QOiBNdWx0aXByb2Nl c3NvciBTeXN0ZW0gRGV0ZWN0ZWQ6IDQgQ1BVcwogY3B1MCAoQlNQKTogQVBJQyBJRDogIDAKIGNw dTEgKEFQKTogQVBJQyBJRDogIDEKIGNwdTIgKEFQKTogQVBJQyBJRDogIDIKIGNwdTMgKEFQKTog QVBJQyBJRDogIDMKaW9hcGljMCA8VmVyc2lvbiAxLjE+IGlycXMgMC0yMyBvbiBtb3RoZXJib2Fy ZAppb2FwaWMxIDxWZXJzaW9uIDEuMT4gaXJxcyAyNC0yNyBvbiBtb3RoZXJib2FyZAppb2FwaWMy IDxWZXJzaW9uIDEuMT4gaXJxcyAyOC0zMSBvbiBtb3RoZXJib2FyZAprYmQxIGF0IGtiZG11eDAK YXRoX2hhbDogMC45LjE3LjIgKEFSNTIxMCwgQVI1MjExLCBBUjUyMTIsIFJGNTExMSwgUkY1MTEy LCBSRjI0MTMsIFJGNTQxMykKYWNwaTA6IDxQVExURCAgIFJTRFQ+IG9uIG1vdGhlcmJvYXJkCmFj cGkwOiBQb3dlciBCdXR0b24gKGZpeGVkKQpUaW1lY291bnRlciAiQUNQSS1mYXN0IiBmcmVxdWVu Y3kgMzU3OTU0NSBIeiBxdWFsaXR5IDEwMDAKYWNwaV90aW1lcjA6IDwyNC1iaXQgdGltZXIgYXQg My41Nzk1NDVNSHo+IHBvcnQgMHg4MDA4LTB4ODAwYiBvbiBhY3BpMApjcHUwOiA8QUNQSSBDUFU+ IG9uIGFjcGkwCmNwdTE6IDxBQ1BJIENQVT4gb24gYWNwaTAKY3B1MjogPEFDUEkgQ1BVPiBvbiBh Y3BpMApjcHUzOiA8QUNQSSBDUFU+IG9uIGFjcGkwCmFjcGlfYnV0dG9uMDogPFBvd2VyIEJ1dHRv bj4gb24gYWNwaTAKcGNpYjA6IDxBQ1BJIEhvc3QtUENJIGJyaWRnZT4gcG9ydCAweGNmOC0weGNm ZiBvbiBhY3BpMApwY2kwOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMApwY2kwOiA8bWVtb3J5PiBh dCBkZXZpY2UgMC4wIChubyBkcml2ZXIgYXR0YWNoZWQpCmlzYWIwOiA8UENJLUlTQSBicmlkZ2U+ IGF0IGRldmljZSAxLjAgb24gcGNpMAppc2EwOiA8SVNBIGJ1cz4gb24gaXNhYjAKcGNpMDogPHNl cmlhbCBidXMsIFNNQnVzPiBhdCBkZXZpY2UgMS4xIChubyBkcml2ZXIgYXR0YWNoZWQpCm9oY2kw OiA8T0hDSSAoZ2VuZXJpYykgVVNCIGNvbnRyb2xsZXI+IG1lbSAweGQ4MDAwMDAwLTB4ZDgwMDBm ZmYgaXJxIDIwIGF0IGRldmljZSAyLjAgb24gcGNpMApvaGNpMDogW0dJQU5ULUxPQ0tFRF0KdXNi MDogT0hDSSB2ZXJzaW9uIDEuMCwgbGVnYWN5IHN1cHBvcnQKdXNiMDogU01NIGRvZXMgbm90IHJl c3BvbmQsIHJlc2V0dGluZwp1c2IwOiA8T0hDSSAoZ2VuZXJpYykgVVNCIGNvbnRyb2xsZXI+IG9u IG9oY2kwCnVzYjA6IFVTQiByZXZpc2lvbiAxLjAKdWh1YjA6IG5WaWRpYSBPSENJIHJvb3QgaHVi LCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMQp1aHViMDogMTAgcG9ydHMgd2l0aCAx MCByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAplaGNpMDogPE5WSURJQSBuRm9yY2U0IFVTQiAyLjAg Y29udHJvbGxlcj4gbWVtIDB4ZDgwMDEwMDAtMHhkODAwMTBmZiBpcnEgMjEgYXQgZGV2aWNlIDIu MSBvbiBwY2kwCmVoY2kwOiBbR0lBTlQtTE9DS0VEXQp1c2IxOiBFSENJIHZlcnNpb24gMS4wCnVz YjE6IGNvbXBhbmlvbiBjb250cm9sbGVyLCA0IHBvcnRzIGVhY2g6IHVzYjAKdXNiMTogPE5WSURJ QSBuRm9yY2U0IFVTQiAyLjAgY29udHJvbGxlcj4gb24gZWhjaTAKdXNiMTogVVNCIHJldmlzaW9u IDIuMAp1aHViMTogblZpZGlhIEVIQ0kgcm9vdCBodWIsIGNsYXNzIDkvMCwgcmV2IDIuMDAvMS4w MCwgYWRkciAxCnVodWIxOiAxMCBwb3J0cyB3aXRoIDEwIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVk CmF0YXBjaTA6IDxuVmlkaWEgbkZvcmNlIENLODA0IFVETUExMzMgY29udHJvbGxlcj4gcG9ydCAw eDFmMC0weDFmNywweDNmNiwweDE3MC0weDE3NywweDM3NiwweDE0MDAtMHgxNDBmIGF0IGRldmlj ZSA2LjAgb24gcGNpMAphdGEwOiA8QVRBIGNoYW5uZWwgMD4gb24gYXRhcGNpMAphdGExOiA8QVRB IGNoYW5uZWwgMT4gb24gYXRhcGNpMApwY2liMTogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRl dmljZSA5LjAgb24gcGNpMApwY2kxOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMQpwY2kxOiA8ZGlz cGxheSwgVkdBPiBhdCBkZXZpY2UgNy4wIChubyBkcml2ZXIgYXR0YWNoZWQpCnBjaWIyOiA8QUNQ SSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDE0LjAgb24gcGNpMApwY2kyOiA8QUNQSSBQQ0kg YnVzPiBvbiBwY2liMgozd2FyZSBkZXZpY2UgZHJpdmVyIGZvciA5MDAwIHNlcmllcyBzdG9yYWdl IGNvbnRyb2xsZXJzLCB2ZXJzaW9uOiAzLjYwLjAzLjAwNgp0d2EwOiA8M3dhcmUgOTAwMCBzZXJp ZXMgU3RvcmFnZSBDb250cm9sbGVyPiBwb3J0IDB4MzAwMC0weDMwZmYgbWVtIDB4ZGMwMDAwMDAt MHhkZGZmZmZmZiwweGRhMDAxMDAwLTB4ZGEwMDFmZmYsMHhkYTAwMDAwMC0weGRhMDAwZmZmIGly cSAxNiBhdCBkZXZpY2UgMC4wIG9uIHBjaTIKdHdhMDogW0ZBU1RdCnR3YTA6IElORk86ICgweDA0 OiAweDAwNTMpOiBCYXR0ZXJ5IGNhcGFjaXR5IHRlc3QgaXMgb3ZlcmR1ZTogCnR3YTA6IElORk86 ICgweDE1OiAweDEzMDApOiBDb250cm9sbGVyIGRldGFpbHM6OiBNb2RlbCA5NjUwU0UtMTZNTCwg MTYgcG9ydHMsIEZpcm13YXJlIEZFOVggMy4wNi4wMC4wMDMsIEJJT1MgQkU5WCAzLjA2LjAwLjAw MgpwY2liMzogPEFDUEkgSG9zdC1QQ0kgYnJpZGdlPiBwb3J0IDB4Y2Y4LTB4Y2ZmIG9uIGFjcGkw CnBjaTg6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIzCnBjaWI0OiA8QUNQSSBQQ0ktUENJIGJyaWRn ZT4gYXQgZGV2aWNlIDEwLjAgb24gcGNpOApwY2k5OiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liNApw Y2k4OiA8YmFzZSBwZXJpcGhlcmFsLCBpbnRlcnJ1cHQgY29udHJvbGxlcj4gYXQgZGV2aWNlIDEw LjEgKG5vIGRyaXZlciBhdHRhY2hlZCkKcGNpYjU6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBk ZXZpY2UgMTEuMCBvbiBwY2k4CnBjaTEwOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liNQpwY2liNTog bWVtb3J5OiBlbmQgKGRlMWZmZmZmKSA8IHN0YXJ0ICg0ODczOWIyZGUxMDAwMDApCnBjaWI1OiBt ZW1vcnk6IGVuZCAoZGUxZmZmZmYpIDwgc3RhcnQgKGRiY2E3M2ZkZGUxMTAwMDApCmJnZTA6IDxC cm9hZGNvbSBCQ001NzA0IEIwLCBBU0lDIHJldi4gMHgyMTAwPiBtZW0gMHg0ODczOWIyZGUxMDAw MDAtMHg0ODczOWIyZGUxMGZmZmYgaXJxIDI4IGF0IGRldmljZSA5LjAgb24gcGNpMTAKcGNpYjU6 IG1lbW9yeTogZW5kIChkZTFmZmZmZikgPCBzdGFydCAoNDg3MzliMmRlMTAwMDAwKQpiZ2UwOiBj b3VsZG4ndCBtYXAgbWVtb3J5CmRldmljZV9hdHRhY2g6IGJnZTAgYXR0YWNoIHJldHVybmVkIDYK YmdlMTogPEJyb2FkY29tIEJDTTU3MDQgQjAsIEFTSUMgcmV2LiAweDIxMDA+IG1lbSAweGRiY2E3 M2ZkZGUxMTAwMDAtMHhkYmNhNzNmZGRlMTFmZmZmIGlycSAyOSBhdCBkZXZpY2UgOS4xIG9uIHBj aTEwCnBjaWI1OiBtZW1vcnk6IGVuZCAoZGUxZmZmZmYpIDwgc3RhcnQgKGRiY2E3M2ZkZGUxMTAw MDApCmJnZTE6IGNvdWxkbid0IG1hcCBtZW1vcnkKZGV2aWNlX2F0dGFjaDogYmdlMSBhdHRhY2gg cmV0dXJuZWQgNgpwY2k4OiA8YmFzZSBwZXJpcGhlcmFsLCBpbnRlcnJ1cHQgY29udHJvbGxlcj4g YXQgZGV2aWNlIDExLjEgKG5vIGRyaXZlciBhdHRhY2hlZCkKYXRrYmRjMDogPEtleWJvYXJkIGNv bnRyb2xsZXIgKGk4MDQyKT4gcG9ydCAweDYwLDB4NjQgaXJxIDEgb24gYWNwaTAKYXRrYmQwOiA8 QVQgS2V5Ym9hcmQ+IGlycSAxIG9uIGF0a2JkYzAKa2JkMCBhdCBhdGtiZDAKYXRrYmQwOiBbR0lB TlQtTE9DS0VEXQpzaW8wOiA8MTY1NTBBLWNvbXBhdGlibGUgQ09NIHBvcnQ+IHBvcnQgMHgzZjgt MHgzZmYgaXJxIDQgZmxhZ3MgMHgxMCBvbiBhY3BpMApzaW8wOiB0eXBlIDE2NTUwQQpzaW8xOiA8 MTY1NTBBLWNvbXBhdGlibGUgQ09NIHBvcnQ+IHBvcnQgMHgyZjgtMHgyZmYgaXJxIDMgb24gYWNw aTAKc2lvMTogdHlwZSAxNjU1MEEKZmRjMDogPGZsb3BweSBkcml2ZSBjb250cm9sbGVyPiBwb3J0 IDB4M2YwLTB4M2Y1LDB4M2Y3IGlycSA2IGRycSAyIG9uIGFjcGkwCmZkYzA6IFtGQVNUXQpmZDA6 IDwxNDQwLUtCIDMuNSIgZHJpdmU+IG9uIGZkYzAgZHJpdmUgMApwcGMwOiA8RUNQIHBhcmFsbGVs IHByaW50ZXIgcG9ydD4gcG9ydCAweDM3OC0weDM3ZiwweDc3OC0weDc3ZiBpcnEgNyBkcnEgMyBv biBhY3BpMApwcGMwOiBTTUMtbGlrZSBjaGlwc2V0IChFQ1AvRVBQL1BTMi9OSUJCTEUpIGluIENP TVBBVElCTEUgbW9kZQpwcGMwOiBGSUZPIHdpdGggMTYvMTYvOSBieXRlcyB0aHJlc2hvbGQKcHBi dXMwOiA8UGFyYWxsZWwgcG9ydCBidXM+IG9uIHBwYzAKcGxpcDA6IDxQTElQIG5ldHdvcmsgaW50 ZXJmYWNlPiBvbiBwcGJ1czAKbHB0MDogPFByaW50ZXI+IG9uIHBwYnVzMApscHQwOiBJbnRlcnJ1 cHQtZHJpdmVuIHBvcnQKcHBpMDogPFBhcmFsbGVsIEkvTz4gb24gcHBidXMwCm9ybTA6IDxJU0Eg T3B0aW9uIFJPTXM+IGF0IGlvbWVtIDB4YzAwMDAtMHhjN2ZmZiwweGM4MDAwLTB4Yzk3ZmYsMHhj OTgwMC0weGNhZmZmLDB4Y2IwMDAtMHhjYzdmZiBvbiBpc2EwCnNjMDogPFN5c3RlbSBjb25zb2xl PiBhdCBmbGFncyAweDEwMCBvbiBpc2EwCnNjMDogVkdBIDwxNiB2aXJ0dWFsIGNvbnNvbGVzLCBm bGFncz0weDMwMD4KdmdhMDogPEdlbmVyaWMgSVNBIFZHQT4gYXQgcG9ydCAweDNjMC0weDNkZiBp b21lbSAweGEwMDAwLTB4YmZmZmYgb24gaXNhMApUaW1lY291bnRlcnMgdGljayBldmVyeSAxLjAw MCBtc2VjCmFjZDA6IERNQSBsaW1pdGVkIHRvIFVETUEzMywgZGV2aWNlIGZvdW5kIG5vbi1BVEE2 NiBjYWJsZQphY2QwOiBEVkRSIDxMSVRFLU9OIERWRFJXIExILTIwQTFQL0tMMDI+IGF0IGF0YTAt bWFzdGVyIFVETUEzMwpkYTAgYXQgdHdhMCBidXMgMCB0YXJnZXQgMCBsdW4gMApkYTA6IDxBTUND IDk2NTBTRS0xNk0gRElTSyAzLjA2PiBGaXhlZCBEaXJlY3QgQWNjZXNzIFNDU0ktNSBkZXZpY2Ug CmRhMDogMTAwLjAwME1CL3MgdHJhbnNmZXJzCmRhMDogMTMxMDcxTUIgKDI2ODQzNTQ1NSA1MTIg Ynl0ZSBzZWN0b3JzOiAyNTVIIDYzUy9UIDE2NzA5QykKU01QOiBBUCBDUFUgIzEgTGF1bmNoZWQh ClNNUDogQVAgQ1BVICMzIExhdW5jaGVkIQpTTVA6IEFQIENQVSAjMiBMYXVuY2hlZCEKZGExIGF0 IHR3YTAgYnVzIDAgdGFyZ2V0IDAgbHVuIDEKZGExOiA8QU1DQyA5NjUwU0UtMTZNIERJU0sgMy4w Nj4gRml4ZWQgRGlyZWN0IEFjY2VzcyBTQ1NJLTUgZGV2aWNlIApkYTE6IDEwMC4wMDBNQi9zIHRy YW5zZmVycwpkYTE6IDk4ODIzNThNQiAoMjAyMzkwNjkxODUgNTEyIGJ5dGUgc2VjdG9yczogMjU1 SCA2M1MvVCAxMjU5ODIzQykK ------=_Part_49325_7545213.1184564260951 Content-Type: application/octet-stream; name=pciconf.out Content-Transfer-Encoding: base64 X-Attachment-Id: f_f42w24hs Content-Disposition: attachment; filename="pciconf.out" bm9uZTBAcGNpMDowOjA6CWNsYXNzPTB4MDU4MDAwIGNhcmQ9MHgyODkxMTBmMSBjaGlwPTB4MDA1 ZTEwZGUgcmV2PTB4YTMgaGRyPTB4MDAKICAgIHZlbmRvciAgID0gJ05WSURJQSBDb3Jwb3JhdGlv bicKICAgIGRldmljZSAgID0gJ25Gb3JjZTQgTWVtb3J5IENvbnRyb2xsZXInCiAgICBjbGFzcyAg ICA9IG1lbW9yeQppc2FiMEBwY2kwOjE6MDoJY2xhc3M9MHgwNjAxMDAgY2FyZD0weDI4OTExMGYx IGNoaXA9MHgwMDUxMTBkZSByZXY9MHhhMyBoZHI9MHgwMAogICAgdmVuZG9yICAgPSAnTlZJRElB IENvcnBvcmF0aW9uJwogICAgY2xhc3MgICAgPSBicmlkZ2UKICAgIHN1YmNsYXNzID0gUENJLUlT QQpub25lMUBwY2kwOjE6MToJY2xhc3M9MHgwYzA1MDAgY2FyZD0weDI4OTExMGYxIGNoaXA9MHgw MDUyMTBkZSByZXY9MHhhMiBoZHI9MHgwMAogICAgdmVuZG9yICAgPSAnTlZJRElBIENvcnBvcmF0 aW9uJwogICAgZGV2aWNlICAgPSAnbkZvcmNlNCBTTUJ1cycKICAgIGNsYXNzICAgID0gc2VyaWFs IGJ1cwogICAgc3ViY2xhc3MgPSBTTUJ1cwpvaGNpMEBwY2kwOjI6MDoJY2xhc3M9MHgwYzAzMTAg Y2FyZD0weDI4OTExMGYxIGNoaXA9MHgwMDVhMTBkZSByZXY9MHhhMiBoZHI9MHgwMAogICAgdmVu ZG9yICAgPSAnTlZJRElBIENvcnBvcmF0aW9uJwogICAgZGV2aWNlICAgPSAnbkZvcmNlNCBVU0Ig Q29udHJvbGxlcicKICAgIGNsYXNzICAgID0gc2VyaWFsIGJ1cwogICAgc3ViY2xhc3MgPSBVU0IK ZWhjaTBAcGNpMDoyOjE6CWNsYXNzPTB4MGMwMzIwIGNhcmQ9MHgyODkxMTBmMSBjaGlwPTB4MDA1 YjEwZGUgcmV2PTB4YTMgaGRyPTB4MDAKICAgIHZlbmRvciAgID0gJ05WSURJQSBDb3Jwb3JhdGlv bicKICAgIGRldmljZSAgID0gJ25Gb3JjZTQgVVNCIDIuMCBDb250cm9sbGVyJwogICAgY2xhc3Mg ICAgPSBzZXJpYWwgYnVzCiAgICBzdWJjbGFzcyA9IFVTQgphdGFwY2kwQHBjaTA6NjowOgljbGFz cz0weDAxMDE4YSBjYXJkPTB4Mjg5MTEwZjEgY2hpcD0weDAwNTMxMGRlIHJldj0weGYyIGhkcj0w eDAwCiAgICB2ZW5kb3IgICA9ICdOVklESUEgQ29ycG9yYXRpb24nCiAgICBkZXZpY2UgICA9ICdu Rm9yY2U0IFBhcmFsbGVsIEFUQSBDb250cm9sbGVyJwogICAgY2xhc3MgICAgPSBtYXNzIHN0b3Jh Z2UKICAgIHN1YmNsYXNzID0gQVRBCnBjaWIxQHBjaTA6OTowOgljbGFzcz0weDA2MDQwMCBjYXJk PTB4MDAwMDAwMDAgY2hpcD0weDAwNWMxMGRlIHJldj0weGEyIGhkcj0weDAxCiAgICB2ZW5kb3Ig ICA9ICdOVklESUEgQ29ycG9yYXRpb24nCiAgICBkZXZpY2UgICA9ICduRm9yY2U0IFBDSSBCcmlk Z2UnCiAgICBjbGFzcyAgICA9IGJyaWRnZQogICAgc3ViY2xhc3MgPSBQQ0ktUENJCnBjaWIyQHBj aTA6MTQ6MDoJY2xhc3M9MHgwNjA0MDAgY2FyZD0weDAwMDAwMDQwIGNoaXA9MHgwMDVkMTBkZSBy ZXY9MHhhMyBoZHI9MHgwMQogICAgdmVuZG9yICAgPSAnTlZJRElBIENvcnBvcmF0aW9uJwogICAg ZGV2aWNlICAgPSAnbkZvcmNlNCBQQ0kgRXhwcmVzcyBCcmlkZ2UnCiAgICBjbGFzcyAgICA9IGJy aWRnZQogICAgc3ViY2xhc3MgPSBQQ0ktUENJCmhvc3RiMEBwY2kwOjI0OjA6CWNsYXNzPTB4MDYw MDAwIGNhcmQ9MHgwMDAwMDAwMCBjaGlwPTB4MTEwMDEwMjIgcmV2PTB4MDAgaGRyPTB4MDAKICAg IHZlbmRvciAgID0gJ0FkdmFuY2VkIE1pY3JvIERldmljZXMgKEFNRCknCiAgICBkZXZpY2UgICA9 ICdBdGhsb24gNjQgLyBPcHRlcm9uIEh5cGVyVHJhbnNwb3J0IFRlY2hub2xvZ3kgQ29uZmlndXJh dGlvbicKICAgIGNsYXNzICAgID0gYnJpZGdlCiAgICBzdWJjbGFzcyA9IEhPU1QtUENJCmhvc3Ri MUBwY2kwOjI0OjE6CWNsYXNzPTB4MDYwMDAwIGNhcmQ9MHgwMDAwMDAwMCBjaGlwPTB4MTEwMTEw MjIgcmV2PTB4MDAgaGRyPTB4MDAKICAgIHZlbmRvciAgID0gJ0FkdmFuY2VkIE1pY3JvIERldmlj ZXMgKEFNRCknCiAgICBkZXZpY2UgICA9ICdBdGhsb24gNjQgLyBPcHRlcm9uIEFkZHJlc3MgTWFw JwogICAgY2xhc3MgICAgPSBicmlkZ2UKICAgIHN1YmNsYXNzID0gSE9TVC1QQ0kKaG9zdGIyQHBj aTA6MjQ6MjoJY2xhc3M9MHgwNjAwMDAgY2FyZD0weDAwMDAwMDAwIGNoaXA9MHgxMTAyMTAyMiBy ZXY9MHgwMCBoZHI9MHgwMAogICAgdmVuZG9yICAgPSAnQWR2YW5jZWQgTWljcm8gRGV2aWNlcyAo QU1EKScKICAgIGRldmljZSAgID0gJ0F0aGxvbiA2NCAvIE9wdGVyb24gRFJBTSBDb250cm9sbGVy JwogICAgY2xhc3MgICAgPSBicmlkZ2UKICAgIHN1YmNsYXNzID0gSE9TVC1QQ0kKaG9zdGIzQHBj aTA6MjQ6MzoJY2xhc3M9MHgwNjAwMDAgY2FyZD0weDAwMDAwMDAwIGNoaXA9MHgxMTAzMTAyMiBy ZXY9MHgwMCBoZHI9MHgwMAogICAgdmVuZG9yICAgPSAnQWR2YW5jZWQgTWljcm8gRGV2aWNlcyAo QU1EKScKICAgIGRldmljZSAgID0gJ0F0aGxvbiA2NCAvIE9wdGVyb24gTWlzY2VsbGFuZW91cyBD b250cm9sJwogICAgY2xhc3MgICAgPSBicmlkZ2UKICAgIHN1YmNsYXNzID0gSE9TVC1QQ0kKaG9z dGI0QHBjaTA6MjU6MDoJY2xhc3M9MHgwNjAwMDAgY2FyZD0weDAwMDAwMDAwIGNoaXA9MHgxMTAw MTAyMiByZXY9MHgwMCBoZHI9MHgwMAogICAgdmVuZG9yICAgPSAnQWR2YW5jZWQgTWljcm8gRGV2 aWNlcyAoQU1EKScKICAgIGRldmljZSAgID0gJ0F0aGxvbiA2NCAvIE9wdGVyb24gSHlwZXJUcmFu c3BvcnQgVGVjaG5vbG9neSBDb25maWd1cmF0aW9uJwogICAgY2xhc3MgICAgPSBicmlkZ2UKICAg IHN1YmNsYXNzID0gSE9TVC1QQ0kKaG9zdGI1QHBjaTA6MjU6MToJY2xhc3M9MHgwNjAwMDAgY2Fy ZD0weDAwMDAwMDAwIGNoaXA9MHgxMTAxMTAyMiByZXY9MHgwMCBoZHI9MHgwMAogICAgdmVuZG9y ICAgPSAnQWR2YW5jZWQgTWljcm8gRGV2aWNlcyAoQU1EKScKICAgIGRldmljZSAgID0gJ0F0aGxv biA2NCAvIE9wdGVyb24gQWRkcmVzcyBNYXAnCiAgICBjbGFzcyAgICA9IGJyaWRnZQogICAgc3Vi Y2xhc3MgPSBIT1NULVBDSQpob3N0YjZAcGNpMDoyNToyOgljbGFzcz0weDA2MDAwMCBjYXJkPTB4 MDAwMDAwMDAgY2hpcD0weDExMDIxMDIyIHJldj0weDAwIGhkcj0weDAwCiAgICB2ZW5kb3IgICA9 ICdBZHZhbmNlZCBNaWNybyBEZXZpY2VzIChBTUQpJwogICAgZGV2aWNlICAgPSAnQXRobG9uIDY0 IC8gT3B0ZXJvbiBEUkFNIENvbnRyb2xsZXInCiAgICBjbGFzcyAgICA9IGJyaWRnZQogICAgc3Vi Y2xhc3MgPSBIT1NULVBDSQpob3N0YjdAcGNpMDoyNTozOgljbGFzcz0weDA2MDAwMCBjYXJkPTB4 MDAwMDAwMDAgY2hpcD0weDExMDMxMDIyIHJldj0weDAwIGhkcj0weDAwCiAgICB2ZW5kb3IgICA9 ICdBZHZhbmNlZCBNaWNybyBEZXZpY2VzIChBTUQpJwogICAgZGV2aWNlICAgPSAnQXRobG9uIDY0 IC8gT3B0ZXJvbiBNaXNjZWxsYW5lb3VzIENvbnRyb2wnCiAgICBjbGFzcyAgICA9IGJyaWRnZQog ICAgc3ViY2xhc3MgPSBIT1NULVBDSQpub25lMkBwY2kxOjc6MDoJY2xhc3M9MHgwMzAwMDAgY2Fy ZD0weDgwMDgxMDAyIGNoaXA9MHg0NzUyMTAwMiByZXY9MHgyNyBoZHI9MHgwMAogICAgdmVuZG9y ICAgPSAnQVRJIFRlY2hub2xvZ2llcyBJbmMnCiAgICBkZXZpY2UgICA9ICdSYWdlIFhMIFBDSScK ICAgIGNsYXNzICAgID0gZGlzcGxheQogICAgc3ViY2xhc3MgPSBWR0EKdHdhMEBwY2kyOjA6MDoJ Y2xhc3M9MHgwMTA0MDAgY2FyZD0weDEwMDQxM2MxIGNoaXA9MHgxMDA0MTNjMSByZXY9MHgwMSBo ZHI9MHgwMAogICAgdmVuZG9yICAgPSAnM3dhcmUgSW5jLicKICAgIGNsYXNzICAgID0gbWFzcyBz dG9yYWdlCiAgICBzdWJjbGFzcyA9IFJBSUQKcGNpYjRAcGNpODoxMDowOgljbGFzcz0weDA2MDQw MCBjYXJkPTB4MDAwMDAwYTAgY2hpcD0weDc0NTAxMDIyIHJldj0weDEzIGhkcj0weDAxCiAgICB2 ZW5kb3IgICA9ICdBZHZhbmNlZCBNaWNybyBEZXZpY2VzIChBTUQpJwogICAgZGV2aWNlICAgPSAn QU1ELTgxMzEgUENJLVggQnJpZGdlJwogICAgY2xhc3MgICAgPSBicmlkZ2UKICAgIHN1YmNsYXNz ID0gUENJLVBDSQpub25lM0BwY2k4OjEwOjE6CWNsYXNzPTB4MDgwMDEwIGNhcmQ9MHgyODkxMTBm MSBjaGlwPTB4NzQ1MTEwMjIgcmV2PTB4MDEgaGRyPTB4MDAKICAgIHZlbmRvciAgID0gJ0FkdmFu Y2VkIE1pY3JvIERldmljZXMgKEFNRCknCiAgICBkZXZpY2UgICA9ICdBTUQtODEzMSBQQ0ktWCBJ T0FQSUMnCiAgICBjbGFzcyAgICA9IGJhc2UgcGVyaXBoZXJhbAogICAgc3ViY2xhc3MgPSBpbnRl cnJ1cHQgY29udHJvbGxlcgpwY2liNUBwY2k4OjExOjA6CWNsYXNzPTB4MDYwNDAwIGNhcmQ9MHgw MDAwMDBhMCBjaGlwPTB4NzQ1MDEwMjIgcmV2PTB4MTMgaGRyPTB4MDEKICAgIHZlbmRvciAgID0g J0FkdmFuY2VkIE1pY3JvIERldmljZXMgKEFNRCknCiAgICBkZXZpY2UgICA9ICdBTUQtODEzMSBQ Q0ktWCBCcmlkZ2UnCiAgICBjbGFzcyAgICA9IGJyaWRnZQogICAgc3ViY2xhc3MgPSBQQ0ktUENJ Cm5vbmU0QHBjaTg6MTE6MToJY2xhc3M9MHgwODAwMTAgY2FyZD0weDI4OTExMGYxIGNoaXA9MHg3 NDUxMTAyMiByZXY9MHgwMSBoZHI9MHgwMAogICAgdmVuZG9yICAgPSAnQWR2YW5jZWQgTWljcm8g RGV2aWNlcyAoQU1EKScKICAgIGRldmljZSAgID0gJ0FNRC04MTMxIFBDSS1YIElPQVBJQycKICAg IGNsYXNzICAgID0gYmFzZSBwZXJpcGhlcmFsCiAgICBzdWJjbGFzcyA9IGludGVycnVwdCBjb250 cm9sbGVyCmJnZTBAcGNpMTA6OTowOgljbGFzcz0weDAyMDAwMCBjYXJkPTB4MTY0NDE0ZTQgY2hp cD0weDE2NDgxNGU0IHJldj0weDEwIGhkcj0weDAwCiAgICB2ZW5kb3IgICA9ICdCcm9hZGNvbSBD b3Jwb3JhdGlvbicKICAgIGRldmljZSAgID0gJ0JDTTU3MDQgTmV0WHRyZW1lIER1YWwgR2lnYWJp dCBBZGFwdGVyJwogICAgY2xhc3MgICAgPSBuZXR3b3JrCiAgICBzdWJjbGFzcyA9IGV0aGVybmV0 CmJnZTFAcGNpMTA6OToxOgljbGFzcz0weDAyMDAwMCBjYXJkPTB4MTY0NDE0ZTQgY2hpcD0weDE2 NDgxNGU0IHJldj0weDEwIGhkcj0weDAwCiAgICB2ZW5kb3IgICA9ICdCcm9hZGNvbSBDb3Jwb3Jh dGlvbicKICAgIGRldmljZSAgID0gJ0JDTTU3MDQgTmV0WHRyZW1lIER1YWwgR2lnYWJpdCBBZGFw dGVyJwogICAgY2xhc3MgICAgPSBuZXR3b3JrCiAgICBzdWJjbGFzcyA9IGV0aGVybmV0Cg== ------=_Part_49325_7545213.1184564260951-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 16 06:56: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 A58B316A402 for ; Mon, 16 Jul 2007 06:56:48 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.170]) by mx1.freebsd.org (Postfix) with ESMTP id 3B31513C4BB for ; Mon, 16 Jul 2007 06:56:48 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: by ug-out-1314.google.com with SMTP id o4so1025238uge for ; Sun, 15 Jul 2007 23:56:46 -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=Uz/HWxwO6HFBDegfwdQsyxzBPHuVXwRCdoX1yIXkKHaWH8R+KCzfOK25jjFMOiv98DhizZ1J6i7zR6kKJgbPMafv5wOocmIL91wXGtq2o8405hQZeScttpKH7/NabEdLbs4um0Q9qAAC/2VAgzkQaLT5xEUH5rhSHtN93LAk70A= 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=dwt/+BUpINKGni1/h2WHw7RD3ALYkURxPU9B20qHdSGL9H6Kmq8khDUmri3pmfTwl13Wv8rXv7ELcTph1P2fCyKSpars5ibC8Nka6I/b6HFtB4kLlEfqB43WpSUlgoDQEgPZjwcksK516/s/HeKsiKOg4lp5VcjEzIP2NCBfExA= Received: by 10.78.206.9 with SMTP id d9mr1101934hug.1184569006679; Sun, 15 Jul 2007 23:56:46 -0700 (PDT) Received: by 10.78.171.6 with HTTP; Sun, 15 Jul 2007 23:56:46 -0700 (PDT) Message-ID: <7ad7ddd90707152356v6034352uf1f7a42ddb9c1166@mail.gmail.com> Date: Mon, 16 Jul 2007 08:56:46 +0200 From: "Ulrich Spoerlein" To: "Tim Kientzle" In-Reply-To: <469A8F91.7090509@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46992FFF.7010906@kientzle.com> <20070714223853.GF16579@britannica.bec.de> <469992CA.6000104@freebsd.org> <4699BE75.2090808@freebsd.org> <20070715184703.GK2819@roadrunner.q.local> <469A8F91.7090509@freebsd.org> Cc: hackers@freebsd.org Subject: Re: Tar output mode for installworld 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, 16 Jul 2007 06:56:48 -0000 On 7/15/07, Tim Kientzle wrote: > Ulrich Spoerlein wrote: > > Simple and elegant. It would also do away with those base.aa, base.ab, > > etc. madness. > > I'm confused. base.aa, etc, are a tar file, so I don't > entirely understand how this would be different? The > current installer does the equivalent of > cat base.* | tar -xf - > > I can see one advantage and one disadvantage of installing > a specification file (which references other files) instead: > > Plus: The specification file can re-use the existing > files on CD, so you don't have, e.g., one copy of /bin/sh > on the live CD and another buried in base.tgz. This > could save space. That is exactly what I was referring to above. And AFAIK DragonflyBSD does it in a similar way. They simply copy the live CD onto the HDD. > Minus: Installing a specification file this way would > be slower because you then have to read a lot of small > files off of CD. True, but couldn't we optimize the ISO layout so it will be a near sequential read of the CD? This should be done for every live CD anyway to avoid excessive seeks during boot up. Uli From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 16 08:08: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 6428616A401; Mon, 16 Jul 2007 08:08:51 +0000 (UTC) (envelope-from ivoras@fer.hr) Received: from pinus.cc.fer.hr (pinus.cc.fer.hr [161.53.73.18]) by mx1.freebsd.org (Postfix) with ESMTP id E5A4413C4A8; Mon, 16 Jul 2007 08:08:50 +0000 (UTC) (envelope-from ivoras@fer.hr) Received: from [161.53.72.113] (lara.cc.fer.hr [161.53.72.113]) by pinus.cc.fer.hr (8.12.2/8.12.2) with ESMTP id l6G8L13f022093; Mon, 16 Jul 2007 10:21:02 +0200 (MEST) Message-ID: <469B2787.9010302@fer.hr> Date: Mon, 16 Jul 2007 10:08:39 +0200 From: Ivan Voras User-Agent: Thunderbird 1.5.0.12 (X11/20060911) MIME-Version: 1.0 To: Victor Snezhko References: <20070709214216.GA72912@walton.maths.tcd.ie> <20070711132202.GA95487@walton.maths.tcd.ie> In-Reply-To: X-Enigmail-Version: 0.94.2.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig36AEAB1499DAB0A2D2865BE7" Cc: David Malone , freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: Debugging times 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, 16 Jul 2007 08:08:51 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig36AEAB1499DAB0A2D2865BE7 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Victor Snezhko wrote: > Also, this was a surprise to an unexperienced me, but I have also > found that vfs_mount initializes RTC with the latest timestamp found > on local file systems - this explains why kernel "worked" for Ivan on > a hard drive. It didn't actually work, but used timestamp which was > stored on filesystem during unmount. Wow - this is just astonishing - why would a file system have anything=20 to do with the RTC? --------------enig36AEAB1499DAB0A2D2865BE7 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 iD8DBQFGmyeNldnAQVacBcgRAgF6AJ9yLcgI2KNUXY0V0QXTxnwdaD6XxACfeFYJ x/CwIdfx3D05eqxE6HiPvyE= =XoDq -----END PGP SIGNATURE----- --------------enig36AEAB1499DAB0A2D2865BE7-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 16 08:26: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 9C7B716A400; Mon, 16 Jul 2007 08:26:33 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from smtp.infracaninophile.co.uk (smtp.infracaninophile.co.uk [81.187.76.162]) by mx1.freebsd.org (Postfix) with ESMTP id 009CE13C4C7; Mon, 16 Jul 2007 08:26:32 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from happy-idiot-talk.infracaninophile.co.uk (localhost.infracaninophile.co.uk [IPv6:::1]) by smtp.infracaninophile.co.uk (8.14.1/8.14.1) with ESMTP id l6G7rYdN061626; Mon, 16 Jul 2007 08:53:35 +0100 (BST) (envelope-from m.seaman@infracaninophile.co.uk) Authentication-Results: smtp.infracaninophile.co.uk from=m.seaman@infracaninophile.co.uk; sender-id=permerror; spf=permerror X-SenderID: Sendmail Sender-ID Filter v0.2.14 smtp.infracaninophile.co.uk l6G7rYdN061626 Message-ID: <469B23FE.8060608@infracaninophile.co.uk> Date: Mon, 16 Jul 2007 08:53:34 +0100 From: Matthew Seaman Organization: Infracaninophile User-Agent: Thunderbird 2.0.0.4 (X11/20070619) MIME-Version: 1.0 To: Tim Kientzle References: <46992FFF.7010906@kientzle.com> <20070714223853.GF16579@britannica.bec.de> <469992CA.6000104@freebsd.org> <4699BE75.2090808@freebsd.org> <20070715133016.GA53853@psconsult.nl> <469A6B73.1030004@freebsd.org> In-Reply-To: <469A6B73.1030004@freebsd.org> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (smtp.infracaninophile.co.uk [IPv6:::1]); Mon, 16 Jul 2007 08:53:45 +0100 (BST) X-Virus-Scanned: ClamAV 0.91/3679/Mon Jul 16 03:44:42 2007 on happy-idiot-talk.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00, DKIM_POLICY_SIGNSOME, DKIM_POLICY_TESTING,NO_RELAYS autolearn=ham version=3.2.1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on happy-idiot-talk.infracaninophile.co.uk Cc: freebsd-hackers@freebsd.org Subject: Re: Tar output mode for installworld 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, 16 Jul 2007 08:26:33 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Tim Kientzle wrote: > Paul Schenkeveld wrote: >> Having a file describing everything that gets installed would also >> benefit >> later upgrades to a system. > > One of my questions: Does my proposed format suffice for these > other purposes? If not, what other features would be required? > Is it worth trying to design a single format that handles these > various cases? Being able to record a series of incremental changes in a filesystem hierarchy, and then roll them back as required. That would be exceedingly useful, and I think your 'ntree' format has virtually everything necessary to do that. The most obvious missing bit I can see is creating a backup of a file before overwriting it with different content. Cheers, Matthew - -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGmyP+8Mjk52CukIwRCGaUAJ0c8j9l4h08dIRBY8bFuX0XA/v4HgCfR7iX F0BjIjIz0ds+EEV74H/JIBs= =J76U -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 16 10:52:08 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 F247916A400 for ; Mon, 16 Jul 2007 10:52:07 +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 AF60E13C442 for ; Mon, 16 Jul 2007 10:52:07 +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 6DE3C208A; Mon, 16 Jul 2007 12:52:01 +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 DDF572085; Mon, 16 Jul 2007 12:52:00 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 1001) id B02FD52E2; Mon, 16 Jul 2007 12:52:00 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Brian Chu" References: <43801.64.117.137.69.1180473436.squirrel@webmail.ifxnw.cl> <86abvm3k89.fsf@dwp.des.no> <47a4f3080707151215t42ed03adp3eab92984e8b670a@mail.gmail.com> <86myxxl6bw.fsf@dwp.des.no> <47a4f3080707151814w6a37a3c3pda244849efa507a8@mail.gmail.com> Date: Mon, 16 Jul 2007 12:52:00 +0200 In-Reply-To: <47a4f3080707151814w6a37a3c3pda244849efa507a8@mail.gmail.com> (Brian Chu's message of "Sun\, 15 Jul 2007 21\:14\:37 -0400") Message-ID: <86myxwd3jj.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, dmw@unete.cl Subject: Re: Setting up development environment 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, 16 Jul 2007 10:52:08 -0000 "Brian Chu" writes: > Dag-Erling Sm=C3=B8rgrav writes: > > "Brian Chu" writes: > > > I have a question about indentation. In the previously supplied > > > .emacs hook, tabs are represented by 8 spaces. > > No, Emacs automatically converts spaces to tabs according to the current > > setting of tab-width, which is normally 8. > Hm. It doesn't always replace 8 spaces with tabs (for files that are > heavily spaced-indented), but I suppose that using `M-x tabify` would > do the trick. The indentation code, which is what we were discussing, does. Please do not top-post. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 16 11:34:32 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 DCD6E16A409 for ; Mon, 16 Jul 2007 11:34:32 +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 67F7F13C47E for ; Mon, 16 Jul 2007 11:34:31 +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 l6GBYRE5066789; Mon, 16 Jul 2007 21:34:27 +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 l6GBYPaa066788; Mon, 16 Jul 2007 21:34:25 +1000 (EST) (envelope-from peter) Date: Mon, 16 Jul 2007 21:34:25 +1000 From: Peter Jeremy To: Julian Elischer Message-ID: <20070716113425.GC65937@turion.vk2pj.dyndns.org> References: <20070705122650.GE1302@britannica.bec.de> <468E16E6.6030608@delphij.net> <20070706112453.GA3217@hoeg.nl> <468E7007.5050607@elischer.org> <20070715211549.GB39075@hoeg.nl> <469AB30A.5000001@elischer.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="J/dobhs11T7y2rNN" Content-Disposition: inline In-Reply-To: <469AB30A.5000001@elischer.org> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.16 (2007-06-09) Cc: FreeBSD Hackers Subject: Re: add closefrom() call 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, 16 Jul 2007 11:34:33 -0000 --J/dobhs11T7y2rNN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2007-Jul-15 16:51:38 -0700, Julian Elischer wrote: >> void >> closefrom(int lowfd) >> { >> fcntl(lowfd, F_CLOSEM, NULL); >> } > >what on earth would that achieve? >(as opposed to just a simple syscall) The only benefit I can think of is minimising the number of syscalls. Is there any other benefit? --=20 Peter Jeremy --J/dobhs11T7y2rNN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGm1fB/opHv/APuIcRAkc6AKCbyJ+DbrIosG5rTcr3B25PVmrmgwCgjp76 X/2HU5d0DfwSwTnwwTfvYAE= =UJbg -----END PGP SIGNATURE----- --J/dobhs11T7y2rNN-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 16 09:57: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 289D416A402; Mon, 16 Jul 2007 09:57:33 +0000 (UTC) (envelope-from snezhko@indorsoft.ru) Received: from indorsoft.ru (indor.net.tomline.ru [213.183.100.90]) by mx1.freebsd.org (Postfix) with ESMTP id 39B2713C442; Mon, 16 Jul 2007 09:57:31 +0000 (UTC) (envelope-from snezhko@indorsoft.ru) Received: from SNEZHKO by indorsoft.ru (MDaemon.PRO.v7.2.2.R) with ESMTP id md50000220658.msg; Mon, 16 Jul 2007 16:57:26 +0700 From: Victor Snezhko To: Ivan Voras References: <20070709214216.GA72912@walton.maths.tcd.ie> <20070711132202.GA95487@walton.maths.tcd.ie> <469B2787.9010302@fer.hr> Date: Mon, 16 Jul 2007 16:57:20 +0700 In-Reply-To: <469B2787.9010302@fer.hr> (Ivan Voras's message of "Mon, 16 Jul 2007 10:08:39 +0200") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (windows-nt) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Processed: indor.net.tomline.ru, Mon, 16 Jul 2007 16:57:26 +0700 (not processed: spam filter disabled) X-Return-Path: snezhko@indorsoft.ru X-Mailman-Approved-At: Mon, 16 Jul 2007 11:38:19 +0000 Cc: David Malone , freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: Debugging times 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, 16 Jul 2007 09:57:33 -0000 Ivan Voras writes: >> Also, this was a surprise to an unexperienced me, but I have also >> found that vfs_mount initializes RTC with the latest timestamp found >> on local file systems - this explains why kernel "worked" for Ivan on >> a hard drive. It didn't actually work, but used timestamp which was >> stored on filesystem during unmount. > > Wow - this is just astonishing - why would a file system have anything > to do with the RTC? Sorry, some sloppy wording on my part. That was system clock, not RTC. The code which makes sure that system clock is initialized to root fs timestamp is in vfs_mount.c since 1.34. Initially it was commented as "sanity check". That might make some sense, although was a surprise to me. -- WBR, Victor V. Snezhko E-mail: snezhko@indorsoft.ru From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 16 12:07:00 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 214F016A403 for ; Mon, 16 Jul 2007 12:07:00 +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 F422A13C461 for ; Mon, 16 Jul 2007 12:06:59 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.141] (may be forged)) by mxout2.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.06) with ESMTP id l6GC6x4L012282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 16 Jul 2007 05:06:59 -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 l6GC6wtA032344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Jul 2007 05:06:59 -0700 Message-ID: <469B5F61.1060805@u.washington.edu> Date: Mon, 16 Jul 2007 05:06:57 -0700 From: Garrett Cooper User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) 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.2.304607, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.7.16.44533 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, __STOCK_SYMBOL1 0, __STOCK_SYMBOL_X1 0, __USER_AGENT 0' Cc: Subject: Large gap between fwrite and write, and fread and read 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, 16 Jul 2007 12:07:00 -0000 Hello again Hackers, I ran some tests and I noticed a large difference in the cumulative sums of fwrite(2) vs write(3) and fread(2) vs read(3) (3-fold differences on a real machine). Please download , take a look at README for some results, and read for more details on how you can run the tests as well if curious, and feel free to send me the results if desired. If you do run the tests, please don't use the /tmp disk at all on the machine as it will most likely skew parts of the test, and please pay heed to the warning, otherwise the test box may become unusable. One thing that has me puzzled though... why is there such a large difference? Is it because fread(2) allows object by object instantiation (i.e. preallocates objects according to sizeof and returns the number of allocated figures), whereas read(3) just reads in raw lengths and returns the amount of chars scanned in? Does the same logic apply for fwrite(2) and write(3)? Thanks, -Garrett -- I really need to go to bed earlier.. haha. From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 16 12:08:54 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 0EAB216A400 for ; Mon, 16 Jul 2007 12:08:54 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.189]) by mx1.freebsd.org (Postfix) with ESMTP id 8E2D613C4BD for ; Mon, 16 Jul 2007 12:08:53 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: by mu-out-0910.google.com with SMTP id w9so1400959mue for ; Mon, 16 Jul 2007 05:08:52 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=googlemail.com; s=beta; h=domainkey-signature:received:received:subject:from:to:cc:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer; b=l6PpbAezWILAJv1cozO4r1GYB/a3lRsC/udhGx3Kz7RPS7Cj5vEpjUi9/Db+7MqUlRFEwsexubaV7fNbUZ3iXtvBKmME/eY9LHcAh8v994robwuvrJvilHMksyHRIgPT1vRTZAY/o2O7NAVcbibT9cufza9MxWqxcKcf1fiv324= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=beta; h=received:subject:from:to:cc:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer; b=fYaeWIYPmqtvOO4j03WwWDBCQmyz0JR5ze2zKwh8Umx80IfsSMXb+S6tDJLzO9qOuxmvti29zWuPdMpEaFSRLILgRn8xrovCNOcTMgsxU6ZB7gseHSMJ9Da0RqJAFQR3VY9RQqFsCmqVcrK9CogOM3KI269y/pB/uU9H8aYcknc= Received: by 10.82.151.14 with SMTP id y14mr4565285bud.1184586177724; Mon, 16 Jul 2007 04:42:57 -0700 (PDT) Received: from ?127.0.0.1? ( [217.206.187.79]) by mx.google.com with ESMTP id 31sm27149364nfu.2007.07.16.04.42.55 (version=SSLv3 cipher=RC4-MD5); Mon, 16 Jul 2007 04:42:56 -0700 (PDT) From: Tom Evans To: Dag-Erling =?ISO-8859-1?Q?Sm=F8rgrav?= In-Reply-To: <86abvm3k89.fsf@dwp.des.no> References: <43801.64.117.137.69.1180473436.squirrel@webmail.ifxnw.cl> <86abvm3k89.fsf@dwp.des.no> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-wrb85RI9M0y35Czx+DZ+" Date: Mon, 16 Jul 2007 12:42:53 +0100 Message-Id: <1184586173.2017.5.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.10.2 FreeBSD GNOME Team Port Cc: freebsd-hackers@freebsd.org, dmw@unete.cl Subject: Re: Setting up development environment 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, 16 Jul 2007 12:08:54 -0000 --=-wrb85RI9M0y35Czx+DZ+ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, 2007-05-30 at 08:21 +0200, Dag-Erling Sm=C3=B8rgrav wrote: ... > Emacs setup (for both C and C++): >=20 > (defun des-knf () > (interactive) >=20 > ;; Basic indent is 8 spaces > (make-local-variable 'c-basic-offset) > (setq c-basic-offset 8) >=20 > ;; Continuation lines are indented 4 spaces > (make-local-variable 'c-offsets-alist) > (c-set-offset 'arglist-cont 4) > (c-set-offset 'arglist-cont-nonempty 4) > (c-set-offset 'statement-cont 4) >=20 > ;; Labels are flush to the left > (c-set-offset 'label [0]) >=20 > ;; Fill column > (make-local-variable 'fill-column) > (setq fill-column 74)) >=20 > (add-hook 'c-mode-common-hook 'des-knf) >=20 > As for how to cross-build, read build(7). >=20 > DES Before I start translating this/style(9), does anyone already have an equivalent for vim? Regards Tom --=-wrb85RI9M0y35Czx+DZ+ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQBGm1m4lcRvFfyds/cRAgTsAJ9oeEoZx3I99mvZ6R4NQuRrWWLR5gCghgc1 GgJ/7uZPgGE0mejHoQAS978= =E1cS -----END PGP SIGNATURE----- --=-wrb85RI9M0y35Czx+DZ+-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 16 12:43: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 5F8B116A40A; Mon, 16 Jul 2007 12:43:53 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id 91F9E13C4B9; Mon, 16 Jul 2007 12:43:52 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.7b8) with ESMTP id 196926955 for multiple; Mon, 16 Jul 2007 08:36:32 -0400 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l6GCSBkF031595; Mon, 16 Jul 2007 08:28:14 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Mon, 16 Jul 2007 07:41:41 -0400 User-Agent: KMail/1.9.6 References: <20070614075439.GA71601@freebsd.org> <20070614075830.GA71887@freebsd.org> In-Reply-To: <20070614075830.GA71887@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707160741.44094.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 16 Jul 2007 08:28:15 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3680/Mon Jul 16 01:49:06 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: Roman Divacky 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: Mon, 16 Jul 2007 12:43:53 -0000 On Thursday 14 June 2007 03:58:30 am Roman Divacky wrote: > 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 1) It would be nicer if lim_free() wasn't so far away from the rest of the limit freeing code (including the comment). Also, missing a blank line before the comment now. 2) acct_process() saves resource usage information, so the later it is in exit1() the more accurate it is going to be, so it's probably best to leave it as it is unless you observe a measurable change in a benchmark with this patch. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 16 12:44: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 1558A16A4AB for ; Mon, 16 Jul 2007 12:44:21 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id BEE1E13C4B9 for ; Mon, 16 Jul 2007 12:44:20 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.7b8) with ESMTP id 196926964 for multiple; Mon, 16 Jul 2007 08:36:34 -0400 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l6GCSBkG031595; Mon, 16 Jul 2007 08:28:16 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Mon, 16 Jul 2007 07:54:00 -0400 User-Agent: KMail/1.9.6 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707160754.01330.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 16 Jul 2007 08:28:16 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3680/Mon Jul 16 01:49:06 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: James Shank Subject: Re: Problem with Broadcom 5704 B1 on amd64 6.2 release 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, 16 Jul 2007 12:44:21 -0000 On Monday 16 July 2007 01:37:40 am James Shank wrote: > Greetings, > > I've run into a problem with the onboard Broadcom 5704 NetXtreme nics > on a Tyan S2891 Thunder K8SRE motherboard. > > Here is the relevant dmesg output to show the error: > > pcib5: at device 11.0 on pci8 > pci10: on pcib5 > pcib5: memory: end (de1fffff) < start (48739b2de100000) > pcib5: memory: end (de1fffff) < start (dbca73fdde110000) > bge0: mem > 0x48739b2de100000-0x48739b2de10ffff irq 28 at device 9.0 on pci10 > pcib5: memory: end (de1fffff) < start (48739b2de100000) > bge0: couldn't map memory > device_attach: bge0 attach returned 6 > bge1: mem > 0xdbca73fdde110000-0xdbca73fdde11ffff irq 29 at device 9.1 on pci10 > pcib5: memory: end (de1fffff) < start (dbca73fdde110000) > bge1: couldn't map memory > device_attach: bge1 attach returned 6 > > It appears to me that the problem might be due to using a 32-bit int > for end addresses where it looks like the start address uses 64-bit > int. > > Any input on how to proceed would be greatly appreciated. > > I've also attached full dmesg output as well as pciconf -l -v output. > > Thanks! Can you try a 7.0 snapshot? It has different handling of 64-bit BARs. If 7 works then we can look at backporting those changes to 6.x. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 16 12:45:46 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 4241216A405; Mon, 16 Jul 2007 12:45:46 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id 212AD13C4A7; Mon, 16 Jul 2007 12:45:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.7b8) with ESMTP id 196926975 for multiple; Mon, 16 Jul 2007 08:36:36 -0400 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l6GCSBkH031595; Mon, 16 Jul 2007 08:28:17 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Mon, 16 Jul 2007 07:55:13 -0400 User-Agent: KMail/1.9.6 References: <469B2787.9010302@fer.hr> In-Reply-To: <469B2787.9010302@fer.hr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707160755.14498.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 16 Jul 2007 08:28:18 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3680/Mon Jul 16 01:49:06 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: David Malone , freebsd-current@freebsd.org, Victor Snezhko , Ivan Voras Subject: Re: Debugging times 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, 16 Jul 2007 12:45:46 -0000 On Monday 16 July 2007 04:08:39 am Ivan Voras wrote: > Victor Snezhko wrote: > > > Also, this was a surprise to an unexperienced me, but I have also > > found that vfs_mount initializes RTC with the latest timestamp found > > on local file systems - this explains why kernel "worked" for Ivan on > > a hard drive. It didn't actually work, but used timestamp which was > > stored on filesystem during unmount. > > Wow - this is just astonishing - why would a file system have anything > to do with the RTC? It's more that we use the filesystem's timestamp as a way to validate the timestamp from the RTC and to do a fixup if the RTC appears to be dead. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 16 13:14:08 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 5DFF916A400; Mon, 16 Jul 2007 13:14:08 +0000 (UTC) (envelope-from ivoras@fer.hr) Received: from ls405.t-com.hr (ls405.t-com.hr [195.29.150.135]) by mx1.freebsd.org (Postfix) with ESMTP id 12B5A13C4A3; Mon, 16 Jul 2007 13:14:07 +0000 (UTC) (envelope-from ivoras@fer.hr) Received: from ls248.t-com.hr (ls248.t-com.hr [195.29.150.237]) by ls405.t-com.hr (Postfix) with ESMTP id 3F4F01488B3; Mon, 16 Jul 2007 15:14:06 +0200 (CEST) Received: from ls248.t-com.hr (localhost.localdomain [127.0.0.1]) by ls248.t-com.hr (Qmlai) with ESMTP id 3B4ACD50047; Mon, 16 Jul 2007 15:14:06 +0200 (CEST) Received: from ls248.t-com.hr (localhost.localdomain [127.0.0.1]) by ls248.t-com.hr (Qmlai) with ESMTP id 19A6AD50058; Mon, 16 Jul 2007 15:14:06 +0200 (CEST) X-Envelope-Sender-Info: g5URFa92gX9K/Rg9VFA/rMlfCnTWZGyid8wYf+70zpU6StkSH1j7CT0zJW9WjWDV X-Envelope-Sender: ivoras@fer.hr Received: from [10.0.0.100] (89-172-62-27.adsl.net.t-com.hr [89.172.62.27]) by ls248.t-com.hr (Qmali) with ESMTP id DB79A5E019C; Mon, 16 Jul 2007 15:14:05 +0200 (CEST) Message-ID: <469B6F1C.6020605@fer.hr> Date: Mon, 16 Jul 2007 15:14:04 +0200 From: Ivan Voras User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: John Baldwin References: <469B2787.9010302@fer.hr> <200707160755.14498.jhb@freebsd.org> In-Reply-To: <200707160755.14498.jhb@freebsd.org> X-Enigmail-Version: 0.94.3.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC9B5182C29B5F923AF200466" Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: Debugging times 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, 16 Jul 2007 13:14:08 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC9B5182C29B5F923AF200466 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable John Baldwin wrote: > It's more that we use the filesystem's timestamp as a way to validate t= he=20 > timestamp from the RTC and to do a fixup if the RTC appears to be dead.= Why not use something that doesn't depend on external factors, like kernel build time (AFAIK it's embedded somewhere - at least it's written on boot)? This way people using non-UFS file systems wouldn't get bitten.= --------------enigC9B5182C29B5F923AF200466 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGm28cldnAQVacBcgRApCLAJ9aD4S/KAIuowQ7FijtMYmpeENRNwCdHdYr zCXOTX3v05T2oISvwS4SyhQ= =/lvs -----END PGP SIGNATURE----- --------------enigC9B5182C29B5F923AF200466-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 16 14:58: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 D242116A403; Mon, 16 Jul 2007 14:58:14 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id 75C2313C4B2; Mon, 16 Jul 2007 14:58:14 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.7b8) with ESMTP id 196960712 for multiple; Mon, 16 Jul 2007 11:06:01 -0400 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l6GEvMLB032514; Mon, 16 Jul 2007 10:57:42 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Ivan Voras Date: Mon, 16 Jul 2007 10:49:27 -0400 User-Agent: KMail/1.9.6 References: <200707160755.14498.jhb@freebsd.org> <469B6F1C.6020605@fer.hr> In-Reply-To: <469B6F1C.6020605@fer.hr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707161049.27779.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 16 Jul 2007 10:57:42 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3681/Mon Jul 16 09:16:18 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: Debugging times 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, 16 Jul 2007 14:58:14 -0000 On Monday 16 July 2007 09:14:04 am Ivan Voras wrote: > John Baldwin wrote: > > > It's more that we use the filesystem's timestamp as a way to validate the > > timestamp from the RTC and to do a fixup if the RTC appears to be dead. > > Why not use something that doesn't depend on external factors, like > kernel build time (AFAIK it's embedded somewhere - at least it's written > on boot)? This way people using non-UFS file systems wouldn't get bitten. The kernel build time isn't updated if you leave a machine up for 2 years, but the filesystem mount time is. Also, the kernel build time is not stored in a raw date format, but as part of a string, so you'd have to import strftime(3) into the kernel. The kernel build time is also localized, so you'd have to import the timezone database into the kernel as well. This Would Be Bad (tm). -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 16 15:00: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 5A43516A409 for ; Mon, 16 Jul 2007 15:00:51 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from mail.farley.org (farley.org [67.64.95.201]) by mx1.freebsd.org (Postfix) with ESMTP id C5CCB13C4B8 for ; Mon, 16 Jul 2007 15:00:50 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from thor.farley.org (thor.farley.org [192.168.1.5]) by mail.farley.org (8.14.1/8.14.1) with ESMTP id l6GESw7U014348; Mon, 16 Jul 2007 09:28:58 -0500 (CDT) (envelope-from scf@FreeBSD.org) Date: Mon, 16 Jul 2007 09:26:50 -0500 (CDT) From: "Sean C. Farley" To: Tom Evans In-Reply-To: <1184586173.2017.5.camel@localhost> Message-ID: <20070716090646.V27236@thor.farley.org> References: <43801.64.117.137.69.1180473436.squirrel@webmail.ifxnw.cl> <86abvm3k89.fsf@dwp.des.no> <1184586173.2017.5.camel@localhost> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1498711889-1184596010=:27236" X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on mail.farley.org Cc: freebsd-hackers@FreeBSD.org Subject: Re: Setting up development environment 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, 16 Jul 2007 15:00:51 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1498711889-1184596010=:27236 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Mon, 16 Jul 2007, Tom Evans wrote: > On Wed, 2007-05-30 at 08:21 +0200, Dag-Erling Sm=F8rgrav wrote: > ... >> Emacs setup (for both C and C++): >> >> (defun des-knf () >> (interactive) >> >> ;; Basic indent is 8 spaces >> (make-local-variable 'c-basic-offset) >> (setq c-basic-offset 8) >> >> ;; Continuation lines are indented 4 spaces >> (make-local-variable 'c-offsets-alist) >> (c-set-offset 'arglist-cont 4) >> (c-set-offset 'arglist-cont-nonempty 4) >> (c-set-offset 'statement-cont 4) >> >> ;; Labels are flush to the left >> (c-set-offset 'label [0]) >> >> ;; Fill column >> (make-local-variable 'fill-column) >> (setq fill-column 74)) >> >> (add-hook 'c-mode-common-hook 'des-knf) >> >> As for how to cross-build, read build(7). >> >> DES > > Before I start translating this/style(9), does anyone already have an > equivalent for vim? I have not made a proper indent file out of this, but this is what I use. Before I work on BSD code I just run :call FreeBSD_Style(). The IgnoreParenIndent() function is needed to avoid vim's built-in cindent code when it comes to line-continuation after a parentheses. Better solutions are welcome. --------------------------------------------- set nocompatible set autoindent " Let vim determine the file type to be edited. "filetype plugin indent on " Ignore indents caused by parentheses in FreeBSD style. fun! IgnoreParenIndent() =09let indent =3D cindent(v:lnum) =09if indent > 4000 =09=09if cindent(v:lnum - 1) > 4000 =09=09=09return indent(v:lnum - 1) =09=09else =09=09=09return indent(v:lnum - 1) + 4 =09=09endif =09else =09=09return (indent) =09endif endfun " Conform to style(9). fun! FreeBSD_Style() =09setlocal cindent =09setlocal formatoptions=3Dclnoqrt =09setlocal textwidth=3D80 =09setlocal indentexpr=3DIgnoreParenIndent() =09setlocal indentkeys=3D0{,0},0),:,0#,!^F,o,O,e =09setlocal cinoptions=3D(4200,u4200,+0.5s,*500,t0,U4200 =09setlocal shiftwidth=3D8 =09setlocal tabstop=3D8 =09setlocal noexpandtab endfun --------------------------------------------- Sean --=20 scf@FreeBSD.org --0-1498711889-1184596010=:27236-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 16 15:18: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 0CA2216A405 for ; Mon, 16 Jul 2007 15:18:35 +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 72E7513C4A7 for ; Mon, 16 Jul 2007 15:18: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 l6GFIOH7015610; Mon, 16 Jul 2007 08:18:33 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <469B8C40.9020603@freebsd.org> Date: Mon, 16 Jul 2007 08:18:24 -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: Matthew Seaman References: <46992FFF.7010906@kientzle.com> <20070714223853.GF16579@britannica.bec.de> <469992CA.6000104@freebsd.org> <4699BE75.2090808@freebsd.org> <20070715133016.GA53853@psconsult.nl> <469A6B73.1030004@freebsd.org> <469B23FE.8060608@infracaninophile.co.uk> In-Reply-To: <469B23FE.8060608@infracaninophile.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Tar output mode for installworld 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, 16 Jul 2007 15:18:35 -0000 > Being able to record a series of incremental changes in a filesystem > hierarchy, and then roll them back as required. That would be > exceedingly useful, and I think your 'ntree' format has virtually > everything necessary to do that. The most obvious missing bit I can > see is creating a backup of a file before overwriting it with > different content. Is this something that requires changes to the specification file format, or just a feature of the tool that uses the specification file? If the former, what do you envision would be required? Tim Kientzle From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 16 15:30: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 3865216A401 for ; Mon, 16 Jul 2007 15:30:01 +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 9E13913C4B7 for ; Mon, 16 Jul 2007 15:30:00 +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 l6GFTtH7015663; Mon, 16 Jul 2007 08:29:59 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <469B8EF2.3010002@freebsd.org> Date: Mon, 16 Jul 2007 08:29:54 -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: Ulrich Spoerlein References: <46992FFF.7010906@kientzle.com> <20070714223853.GF16579@britannica.bec.de> <469992CA.6000104@freebsd.org> <4699BE75.2090808@freebsd.org> <20070715184703.GK2819@roadrunner.q.local> <469A8F91.7090509@freebsd.org> <7ad7ddd90707152356v6034352uf1f7a42ddb9c1166@mail.gmail.com> In-Reply-To: <7ad7ddd90707152356v6034352uf1f7a42ddb9c1166@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org Subject: Re: Tar output mode for installworld 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, 16 Jul 2007 15:30:01 -0000 Ulrich Spoerlein wrote: > On 7/15/07, Tim Kientzle wrote: > >> Plus: The specification file can re-use the existing >> files on CD, ... > > That is exactly what I was referring to above. And AFAIK DragonflyBSD > does it in a similar way. They simply copy the live CD onto the HDD. > >> Minus: Installing a specification file this way would >> be slower because you then have to read a lot of small >> files off of CD. > > True, but couldn't we optimize the ISO layout so it will be a near > sequential read of the CD? Hmmm... This might work. The prototype 'ntree' support I posted should be sufficient for people to experiment with these ideas. Cheers, Tim Kientzle From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 16 17:37: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 F3E7916A403; Mon, 16 Jul 2007 17:37:48 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from smtp.infracaninophile.co.uk (ns0.infracaninophile.co.uk [81.187.76.162]) by mx1.freebsd.org (Postfix) with ESMTP id 530D413C4B4; Mon, 16 Jul 2007 17:37:48 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from happy-idiot-talk.infracaninophile.co.uk (localhost.infracaninophile.co.uk [IPv6:::1]) by smtp.infracaninophile.co.uk (8.14.1/8.14.1) with ESMTP id l6GHbV5V066239; Mon, 16 Jul 2007 18:37:33 +0100 (BST) (envelope-from m.seaman@infracaninophile.co.uk) Authentication-Results: smtp.infracaninophile.co.uk from=m.seaman@infracaninophile.co.uk; sender-id=permerror; spf=permerror X-SenderID: Sendmail Sender-ID Filter v0.2.14 smtp.infracaninophile.co.uk l6GHbV5V066239 Message-ID: <469BACDB.1040608@infracaninophile.co.uk> Date: Mon, 16 Jul 2007 18:37:31 +0100 From: Matthew Seaman Organization: Infracaninophile User-Agent: Thunderbird 2.0.0.4 (X11/20070619) MIME-Version: 1.0 To: Tim Kientzle References: <46992FFF.7010906@kientzle.com> <20070714223853.GF16579@britannica.bec.de> <469992CA.6000104@freebsd.org> <4699BE75.2090808@freebsd.org> <20070715133016.GA53853@psconsult.nl> <469A6B73.1030004@freebsd.org> <469B23FE.8060608@infracaninophile.co.uk> <469B8C40.9020603@freebsd.org> In-Reply-To: <469B8C40.9020603@freebsd.org> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (smtp.infracaninophile.co.uk [IPv6:::1]); Mon, 16 Jul 2007 18:37:43 +0100 (BST) X-Virus-Scanned: ClamAV 0.91/3681/Mon Jul 16 14:16:18 2007 on happy-idiot-talk.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00, DKIM_POLICY_SIGNSOME, DKIM_POLICY_TESTING,NO_RELAYS autolearn=ham version=3.2.1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on happy-idiot-talk.infracaninophile.co.uk Cc: freebsd-hackers@freebsd.org Subject: Re: Tar output mode for installworld 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, 16 Jul 2007 17:37:49 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Tim Kientzle wrote: >> Being able to record a series of incremental changes in a filesystem >> hierarchy, and then roll them back as required. That would be >> exceedingly useful, and I think your 'ntree' format has virtually >> everything necessary to do that. The most obvious missing bit I can >> see is creating a backup of a file before overwriting it with >> different content. > > Is this something that requires changes to the specification > file format, or just a feature of the tool that uses the > specification file? > > If the former, what do you envision would be required? In your example earlier you said not entirely unlike the following: #%ntree bin/echo contents=my/bin/echo uid=0 gid=0 group=wheel I've taken the liberty of reordering it a bit, because then it can be interpreted (for example) as directly translating into a sequence of shell commands: cp my/bin/echo /bin/echo chown 0 /bin/echo chgrp 0 /bin/echo chgrp wheel /bin/echo This could be seen as a fragment of the process of building the /bin filesystem from scratch, or as a patch to an existing /bin filesystem, overlaying the echo command with a new version. Thinking of it as the latter, so long as you know where to copy the original /bin/echo to and how to record various other metadata then you can fairly readily write another ntree program that reverses the effect of this one[*]. The tool used to unpack the ntree file would have to record the original file metadata (presumably directly in ntree format), and you'ld probably need a reasonably cunning approach to storing the backup copies of files so you avoid accidentally overwriting them. (Use the checksum of the file as the name to store it under? Some sort of directory hashing probably useful too) Cheers, Matthew [*] almost literally by reversing the sense of each command and then reversing the order they are applied. Admittedly this is a trivial example, but I don't see why that approach shouldn't work in general. - -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGm6zb8Mjk52CukIwRCCTtAJ9cLxb13VEmr06WVKX4r7D3z9UkVQCePB94 SE++fRzlgNecWtv6svCYIzE= =o4XJ -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 16 18:25:13 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 8D72F16A402 for ; Mon, 16 Jul 2007 18:25:13 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outM.internet-mail-service.net (outM.internet-mail-service.net [216.240.47.236]) by mx1.freebsd.org (Postfix) with ESMTP id 7552613C48D for ; Mon, 16 Jul 2007 18:25:13 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Mon, 16 Jul 2007 11:25:12 -0700 Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 54904125AE6; Mon, 16 Jul 2007 11:25:12 -0700 (PDT) Message-ID: <469BB821.1010507@elischer.org> Date: Mon, 16 Jul 2007 11:25:37 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Peter Jeremy References: <20070705122650.GE1302@britannica.bec.de> <468E16E6.6030608@delphij.net> <20070706112453.GA3217@hoeg.nl> <468E7007.5050607@elischer.org> <20070715211549.GB39075@hoeg.nl> <469AB30A.5000001@elischer.org> <20070716113425.GC65937@turion.vk2pj.dyndns.org> In-Reply-To: <20070716113425.GC65937@turion.vk2pj.dyndns.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Hackers Subject: Re: add closefrom() call 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, 16 Jul 2007 18:25:13 -0000 Peter Jeremy wrote: > On 2007-Jul-15 16:51:38 -0700, Julian Elischer wrote: >>> void >>> closefrom(int lowfd) >>> { >>> fcntl(lowfd, F_CLOSEM, NULL); >>> } >> what on earth would that achieve? >> (as opposed to just a simple syscall) > > The only benefit I can think of is minimising the number of syscalls. > Is there any other benefit? > I don't think so.. it's less efficient, and harder to do.. syscalls are not in short supply. From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 16 22:35: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 BD15A16A409 for ; Mon, 16 Jul 2007 22:35:39 +0000 (UTC) (envelope-from james.shank@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.241]) by mx1.freebsd.org (Postfix) with ESMTP id 34BF813C4BC for ; Mon, 16 Jul 2007 22:35:39 +0000 (UTC) (envelope-from james.shank@gmail.com) Received: by an-out-0708.google.com with SMTP id c14so311530anc for ; Mon, 16 Jul 2007 15:35:38 -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=bFGEBiOXtqv02DvTE20Izg6/BtducPC/NcBD4lU3R8HflEA5dnZc2pYsl1NTjTXjL2nJVZl0/vngkz8IjSlO4Wyp+Ykj+1hv59xX9lOtpVhjXZVZUN8Z0UEvLovyz9goRzZY0Mr+rmMMBa6aBSMyiTNr/+tHKogUqZ1ZpLZADKE= 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=i36qp1jtCcQuQvijIFKsP59vNwifRKgh+mHfk0SPNxRKKsM2/uHWoOwaKumXimCQcU6VuWEXwWGFF89TyX3k8cFB9hUG9Rb2U9pBCKL4YREalUGFc2Q2bNJOo3IaA+fjkg7H1U3JRJbW8tbzJMAf6elPHQr5/Rd6lWqXuMdbo8k= Received: by 10.100.135.16 with SMTP id i16mr2560975and.1184625338389; Mon, 16 Jul 2007 15:35:38 -0700 (PDT) Received: by 10.100.198.5 with HTTP; Mon, 16 Jul 2007 15:35:38 -0700 (PDT) Message-ID: Date: Mon, 16 Jul 2007 17:35:38 -0500 From: "James Shank" To: "Stefan Esser" , freebsd-hackers@freebsd.org In-Reply-To: <469B2DB9.3090202@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_60975_25352783.1184625338313" References: <469B2DB9.3090202@FreeBSD.org> Cc: Subject: Re: Problem with Broadcom 5704 B1 on amd64 6.2 release 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, 16 Jul 2007 22:35:39 -0000 ------=_Part_60975_25352783.1184625338313 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Dear Stefan, Thanks for your help. I've attached the information you requested. In particular, here are the relevant sections of the dmesg output: pcib5: at device 11.0 on pci8 pcib5: secondary bus 10 pcib5: subordinate bus 10 pcib5: I/O decode 0xf000-0xfff pcib5: memory decode 0xde100000-0xde1fffff pcib5: prefetched decode 0xfff00000-0xfffff pci10: on pcib5 pci10: physical bus=10 found-> vendor=0x14e4, dev=0x1648, revid=0x10 bus=10, slot=9, func=0 class=02-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0116, statreg=0x02b0, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x40 (16000 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 8 messages, 64 bit map[10]: type 1, range 64, base de100000, size 16, enabled pcib5: memory: end (de1fffff) < start (49dbdf2de100000) pcib5: (null) requested unsupported memory range 0x0-0x0 (decoding 0xde100000-0xde1fffff, 0xfff00000-0xfffff) pcib5: matched entry for 10.9.INTA pcib5: slot 9 INTA hardwired to IRQ 28 found-> vendor=0x14e4, dev=0x1648, revid=0x10 bus=10, slot=9, func=1 class=02-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0116, statreg=0x02b0, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x40 (16000 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 8 messages, 64 bit map[10]: type 1, range 64, base de110000, size 16, enabled pcib5: memory: end (de1fffff) < start (dbfa72fdde110000) pcib5: (null) requested unsupported memory range 0x0-0x0 (decoding 0xde100000-0xde1fffff, 0xfff00000-0xfffff) pcib5: matched entry for 10.9.INTB pcib5: slot 9 INTB hardwired to IRQ 29 bge0: mem 0x49dbdf2de100000-0x49dbdf2de10ffff irq 28 at device 9.0 on pci10 pcib5: memory: end (de1fffff) < start (49dbdf2de100000) pcib5: bge0 requested unsupported memory range 0x0-0x0 (decoding 0xde100000-0xde1fffff, 0xfff00000-0xfffff) bge0: couldn't map memory device_attach: bge0 attach returned 6 bge1: mem 0xdbfa72fdde110000-0xdbfa72fdde11ffff irq 29 at device 9.1 on pci10 pcib5: memory: end (de1fffff) < start (dbfa72fdde110000) pcib5: bge1 requested unsupported memory range 0x0-0x0 (decoding 0xde100000-0xde1fffff, 0xfff00000-0xfffff) bge1: couldn't map memory device_attach: bge1 attach returned 6 pci8: at device 11.1 (no driver attached) Any help you could provide would be greatly appreciated! Thanks again, James On 7/16/07, Stefan Esser wrote: > James Shank schrieb: > > Greetings, > > > > I've run into a problem with the onboard Broadcom 5704 NetXtreme nics > > on a Tyan S2891 Thunder K8SRE motherboard. > > > > Here is the relevant dmesg output to show the error: > > > > pcib5: at device 11.0 on pci8 > > pci10: on pcib5 > > pcib5: memory: end (de1fffff) < start (48739b2de100000) > > pcib5: memory: end (de1fffff) < start (dbca73fdde110000) > > bge0: mem > > 0x48739b2de100000-0x48739b2de10ffff irq 28 at device 9.0 on pci10 > > pcib5: memory: end (de1fffff) < start (48739b2de100000) > > Hi James, > > the information that you provided is not sufficient to diagnose > this problem. You should post a *verbose* boot message log (via > the boot loader menu or the loader command "boot -v"). > > Please do also provide a dump of the config registers of the > PCI bridge for which the error condition is reported: > > # pciconf -r pci8:11:0 0:0x3f // device 11.0 on pci8 > > Not sure that I'll have time to look into this right today, but > others on the list will want the same information so you may > want to post it there ... > > This looks like a problem with the PCI bridge code, not the > device init code, actually. But just in case it is not, you > could also provide a register dump of the Ethernet chip: > > # pciconf -r pci10:9:0 0:0x3f > > Regards, STefan > ------=_Part_60975_25352783.1184625338313 Content-Type: application/octet-stream; name="dmesg.boot-v.out" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="dmesg.boot-v.out" X-Attachment-Id: f_f47j65n4 Q29weXJpZ2h0IChjKSAxOTkyLTIwMDcgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChj KSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAx OTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLgpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgVGhlIEZy ZWVCU0QgRm91bmRhdGlvbi4KRnJlZUJTRCA2LjItUkVMRUFTRSAjMDogVHVlIEp1bCAxMCAxNDo1 ODoxNCBVVEMgMjAwNwogICAgcm9vdEA6L3Vzci9zcmMvc3lzL2FtZDY0L2NvbXBpbGUvU01QClBy ZWxvYWRlZCBlbGYga2VybmVsICIvYm9vdC9rZXJuZWwva2VybmVsIiBhdCAweGZmZmZmZmZmODBh NjkwMDAuCklOVFI6IEFkZGluZyBsb2NhbCBBUElDIDAgYXMgYSB0YXJnZXQKQUNQSSBBUElDIFRh YmxlOiA8UFRMVEQgIAkgQVBJQyAgPgpDYWxpYnJhdGluZyBjbG9jayhzKSAuLi4gaTgyNTQgY2xv Y2s6IDExOTMyNzQgSHoKQ0xLX1VTRV9JODI1NF9DQUxJQlJBVElPTiBub3Qgc3BlY2lmaWVkIC0g dXNpbmcgZGVmYXVsdCBmcmVxdWVuY3kKVGltZWNvdW50ZXIgImk4MjU0IiBmcmVxdWVuY3kgMTE5 MzE4MiBIeiBxdWFsaXR5IDAKQ2FsaWJyYXRpbmcgVFNDIGNsb2NrIC4uLiBUU0MgY2xvY2s6IDI2 MTIwNTA5NzggSHoKQ1BVOiBEdWFsIENvcmUgQU1EIE9wdGVyb24odG0pIFByb2Nlc3NvciAyODUg KDI2MTIuMDUtTUh6IEs4LWNsYXNzIENQVSkKICBPcmlnaW4gPSAiQXV0aGVudGljQU1EIiAgSWQg PSAweDIwZjEyICBTdGVwcGluZyA9IDIKICBGZWF0dXJlcz0weDE3OGJmYmZmPEZQVSxWTUUsREUs UFNFLFRTQyxNU1IsUEFFLE1DRSxDWDgsQVBJQyxTRVAsTVRSUixQR0UsTUNBLENNT1YsUEFULFBT RTM2LENMRkxVU0gsTU1YLEZYU1IsU1NFLFNTRTIsSFRUPgogIEZlYXR1cmVzMj0weDE8U1NFMz4K ICBBTUQgRmVhdHVyZXM9MHhlMjUwMDgwMDxTWVNDQUxMLE5YLE1NWCssRkZYU1IsTE0sM0ROb3cr LDNETm93PgogIEFNRCBGZWF0dXJlczI9MHgzPExBSEYsQ01QPgogICAgSFRUIGJpdCBjbGVhcmVk IC0gRnJlZUJTRCBkb2VzIG5vdCBoYXZlIGxpY2Vuc2luZyBpc3N1ZXMgcmVxdWlyaW5nIGl0LgoK ICBDb3JlcyBwZXIgcGFja2FnZTogMgpMMSAyTUIgZGF0YSBUTEI6IDggZW50cmllcywgZnVsbHkg YXNzb2NpYXRpdmUKTDEgMk1CIGluc3RydWN0aW9uIFRMQjogOCBlbnRyaWVzLCBmdWxseSBhc3Nv Y2lhdGl2ZQpMMSA0S0IgZGF0YSBUTEI6IDMyIGVudHJpZXMsIGZ1bGx5IGFzc29jaWF0aXZlCkwx IDRLQiBpbnN0cnVjdGlvbiBUTEI6IDMyIGVudHJpZXMsIGZ1bGx5IGFzc29jaWF0aXZlCkwxIGRh dGEgY2FjaGU6IDY0IGtieXRlcywgNjQgYnl0ZXMvbGluZSwgMSBsaW5lcy90YWcsIDItd2F5IGFz c29jaWF0aXZlCkwxIGluc3RydWN0aW9uIGNhY2hlOiA2NCBrYnl0ZXMsIDY0IGJ5dGVzL2xpbmUs IDEgbGluZXMvdGFnLCAyLXdheSBhc3NvY2lhdGl2ZQpMMiAyTUIgdW5pZmllZCBUTEI6IDAgZW50 cmllcywgZGlzYWJsZWQvbm90IHByZXNlbnQKTDIgNEtCIGRhdGEgVExCOiA1MTIgZW50cmllcywg NC13YXkgYXNzb2NpYXRpdmUKTDIgNEtCIGluc3RydWN0aW9uIFRMQjogNTEyIGVudHJpZXMsIDQt d2F5IGFzc29jaWF0aXZlCkwyIHVuaWZpZWQgY2FjaGU6IDEwMjQga2J5dGVzLCA2NCBieXRlcy9s aW5lLCAxIGxpbmVzL3RhZywgMTYtd2F5IGFzc29jaWF0aXZlCnJlYWwgbWVtb3J5ICA9IDM0ODg2 Nzc4ODggKDMzMjcgTUIpClBoeXNpY2FsIG1lbW9yeSBjaHVuayhzKToKMHgwMDAwMDAwMDAwMDAx MDAwIC0gMHgwMDAwMDAwMDAwMDk5ZmZmLCA2MjY2ODggYnl0ZXMgKDE1MyBwYWdlcykKMHgwMDAw MDAwMDAwYjY2MDAwIC0gMHgwMDAwMDAwMGM5ZDNjZmZmLCAzMzc0MTQ5NjMyIGJ5dGVzICg4MjM3 NjcgcGFnZXMpCmF2YWlsIG1lbW9yeSA9IDMzNjM3OTQ5NDQgKDMyMDcgTUIpCklOVFI6IEFkZGlu ZyBsb2NhbCBBUElDIDEgYXMgYSB0YXJnZXQKSU5UUjogQWRkaW5nIGxvY2FsIEFQSUMgMiBhcyBh IHRhcmdldApJTlRSOiBBZGRpbmcgbG9jYWwgQVBJQyAzIGFzIGEgdGFyZ2V0CkZyZWVCU0QvU01Q OiBNdWx0aXByb2Nlc3NvciBTeXN0ZW0gRGV0ZWN0ZWQ6IDQgQ1BVcwogY3B1MCAoQlNQKTogQVBJ QyBJRDogIDAKIGNwdTEgKEFQKTogQVBJQyBJRDogIDEKIGNwdTIgKEFQKTogQVBJQyBJRDogIDIK IGNwdTMgKEFQKTogQVBJQyBJRDogIDMKQVBJQzogQ1BVIDAgaGFzIEFDUEkgSUQgMApBUElDOiBD UFUgMSBoYXMgQUNQSSBJRCAxCkFQSUM6IENQVSAyIGhhcyBBQ1BJIElEIDIKQVBJQzogQ1BVIDMg aGFzIEFDUEkgSUQgMwpNQURUOiBGb3VuZCBJTyBBUElDIElEIDQsIEludGVycnVwdCAwIGF0IDB4 ZmVjMDAwMDAKaW9hcGljMDogUm91dGluZyBleHRlcm5hbCA4MjU5QSdzIC0+IGludHBpbiAwCmlv YXBpYzA6IGludHBpbiAwIC0+IEV4dElOVCAoZWRnZSwgaGlnaCkKaW9hcGljMDogaW50cGluIDEg LT4gSVNBIElSUSAxIChlZGdlLCBoaWdoKQppb2FwaWMwOiBpbnRwaW4gMiAtPiBJU0EgSVJRIDIg KGVkZ2UsIGhpZ2gpCmlvYXBpYzA6IGludHBpbiAzIC0+IElTQSBJUlEgMyAoZWRnZSwgaGlnaCkK aW9hcGljMDogaW50cGluIDQgLT4gSVNBIElSUSA0IChlZGdlLCBoaWdoKQppb2FwaWMwOiBpbnRw aW4gNSAtPiBJU0EgSVJRIDUgKGVkZ2UsIGhpZ2gpCmlvYXBpYzA6IGludHBpbiA2IC0+IElTQSBJ UlEgNiAoZWRnZSwgaGlnaCkKaW9hcGljMDogaW50cGluIDcgLT4gSVNBIElSUSA3IChlZGdlLCBo aWdoKQppb2FwaWMwOiBpbnRwaW4gOCAtPiBJU0EgSVJRIDggKGVkZ2UsIGhpZ2gpCmlvYXBpYzA6 IGludHBpbiA5IC0+IElTQSBJUlEgOSAoZWRnZSwgaGlnaCkKaW9hcGljMDogaW50cGluIDEwIC0+ IElTQSBJUlEgMTAgKGVkZ2UsIGhpZ2gpCmlvYXBpYzA6IGludHBpbiAxMSAtPiBJU0EgSVJRIDEx IChlZGdlLCBoaWdoKQppb2FwaWMwOiBpbnRwaW4gMTIgLT4gSVNBIElSUSAxMiAoZWRnZSwgaGln aCkKaW9hcGljMDogaW50cGluIDEzIC0+IElTQSBJUlEgMTMgKGVkZ2UsIGhpZ2gpCmlvYXBpYzA6 IGludHBpbiAxNCAtPiBJU0EgSVJRIDE0IChlZGdlLCBoaWdoKQppb2FwaWMwOiBpbnRwaW4gMTUg LT4gSVNBIElSUSAxNSAoZWRnZSwgaGlnaCkKaW9hcGljMDogaW50cGluIDE2IC0+IFBDSSBJUlEg MTYgKGxldmVsLCBsb3cpCmlvYXBpYzA6IGludHBpbiAxNyAtPiBQQ0kgSVJRIDE3IChsZXZlbCwg bG93KQppb2FwaWMwOiBpbnRwaW4gMTggLT4gUENJIElSUSAxOCAobGV2ZWwsIGxvdykKaW9hcGlj MDogaW50cGluIDE5IC0+IFBDSSBJUlEgMTkgKGxldmVsLCBsb3cpCmlvYXBpYzA6IGludHBpbiAy MCAtPiBQQ0kgSVJRIDIwIChsZXZlbCwgbG93KQppb2FwaWMwOiBpbnRwaW4gMjEgLT4gUENJIElS USAyMSAobGV2ZWwsIGxvdykKaW9hcGljMDogaW50cGluIDIyIC0+IFBDSSBJUlEgMjIgKGxldmVs LCBsb3cpCmlvYXBpYzA6IGludHBpbiAyMyAtPiBQQ0kgSVJRIDIzIChsZXZlbCwgbG93KQpNQURU OiBGb3VuZCBJTyBBUElDIElEIDUsIEludGVycnVwdCAyNCBhdCAweGRlMDAwMDAwCmlvYXBpYzE6 IGludHBpbiAwIC0+IFBDSSBJUlEgMjQgKGxldmVsLCBsb3cpCmlvYXBpYzE6IGludHBpbiAxIC0+ IFBDSSBJUlEgMjUgKGxldmVsLCBsb3cpCmlvYXBpYzE6IGludHBpbiAyIC0+IFBDSSBJUlEgMjYg KGxldmVsLCBsb3cpCmlvYXBpYzE6IGludHBpbiAzIC0+IFBDSSBJUlEgMjcgKGxldmVsLCBsb3cp Ck1BRFQ6IEZvdW5kIElPIEFQSUMgSUQgNiwgSW50ZXJydXB0IDI4IGF0IDB4ZGUwMDEwMDAKaW9h cGljMjogaW50cGluIDAgLT4gUENJIElSUSAyOCAobGV2ZWwsIGxvdykKaW9hcGljMjogaW50cGlu IDEgLT4gUENJIElSUSAyOSAobGV2ZWwsIGxvdykKaW9hcGljMjogaW50cGluIDIgLT4gUENJIElS USAzMCAobGV2ZWwsIGxvdykKaW9hcGljMjogaW50cGluIDMgLT4gUENJIElSUSAzMSAobGV2ZWws IGxvdykKTUFEVDogSW50ZXJydXB0IG92ZXJyaWRlOiBzb3VyY2UgMCwgaXJxIDIKaW9hcGljMDog Um91dGluZyBJUlEgMCAtPiBpbnRwaW4gMgppb2FwaWMwOiBpbnRwaW4gMiB0cmlnZ2VyOiBlZGdl CmlvYXBpYzA6IGludHBpbiAyIHBvbGFyaXR5OiBoaWdoCk1BRFQ6IEludGVycnVwdCBvdmVycmlk ZTogc291cmNlIDksIGlycSA5CmlvYXBpYzA6IGludHBpbiA5IHRyaWdnZXI6IGxldmVsCmlvYXBp YzA6IGludHBpbiA5IHBvbGFyaXR5OiBsb3cKbGFwaWMwOiBSb3V0aW5nIE5NSSAtPiBMSU5UMQps YXBpYzA6IExJTlQxIHRyaWdnZXI6IGVkZ2UKbGFwaWMwOiBMSU5UMSBwb2xhcml0eTogaGlnaAps YXBpYzE6IFJvdXRpbmcgTk1JIC0+IExJTlQxCmxhcGljMTogTElOVDEgdHJpZ2dlcjogZWRnZQps YXBpYzE6IExJTlQxIHBvbGFyaXR5OiBoaWdoCmxhcGljMjogUm91dGluZyBOTUkgLT4gTElOVDEK bGFwaWMyOiBMSU5UMSB0cmlnZ2VyOiBlZGdlCmxhcGljMjogTElOVDEgcG9sYXJpdHk6IGhpZ2gK bGFwaWMzOiBSb3V0aW5nIE5NSSAtPiBMSU5UMQpsYXBpYzM6IExJTlQxIHRyaWdnZXI6IGVkZ2UK bGFwaWMzOiBMSU5UMSBwb2xhcml0eTogaGlnaAppb2FwaWMwIDxWZXJzaW9uIDEuMT4gaXJxcyAw LTIzIG9uIG1vdGhlcmJvYXJkCmlvYXBpYzEgPFZlcnNpb24gMS4xPiBpcnFzIDI0LTI3IG9uIG1v dGhlcmJvYXJkCmlvYXBpYzIgPFZlcnNpb24gMS4xPiBpcnFzIDI4LTMxIG9uIG1vdGhlcmJvYXJk CmNwdTAgQlNQOgogICAgIElEOiAweDAwMDAwMDAwICAgVkVSOiAweDAwMDQwMDEwIExEUjogMHgw MDAwMDAwMCBERlI6IDB4ZmZmZmZmZmYKICBsaW50MDogMHgwMDAxMDcwMCBsaW50MTogMHgwMDAw MDQwMCBUUFI6IDB4MDAwMDAwMDAgU1ZSOiAweDAwMDAwMWZmCiAgdGltZXI6IDB4MDAwMTAwZWYg dGhlcm06IDB4MDAwMDAwMDAgZXJyOiAweDAwMDEwMDAwIHBjbTogMHgwMDAxMDAwMAp3bGFuOiA8 ODAyLjExIExpbmsgTGF5ZXI+CmF0aF9yYXRlOiB2ZXJzaW9uIDEuMiA8U2FtcGxlUmF0ZSBiaXQt cmF0ZSBzZWxlY3Rpb24gYWxnb3JpdGhtPgpudWxsOiA8bnVsbCBkZXZpY2UsIHplcm8gZGV2aWNl PgpyYW5kb206IDxlbnRyb3B5IHNvdXJjZSwgU29mdHdhcmUsIFlhcnJvdz4KbmZzbG9jazogcHNl dWRvLWRldmljZQprYmQ6IG5ldyBhcnJheSBzaXplIDQKa2JkMSBhdCBrYmRtdXgwCm1lbTogPG1l bW9yeT4KaW86IDxJL08+CmF0aF9oYWw6IDAuOS4xNy4yIChBUjUyMTAsIEFSNTIxMSwgQVI1MjEy LCBSRjUxMTEsIFJGNTExMiwgUkYyNDEzLCBSRjU0MTMpCnJyMjMyeDogUm9ja2V0UkFJRCAyMzJ4 IGNvbnRyb2xsZXIgZHJpdmVyIHYxLjAyIChKdWwgMTAgMjAwNyAxNDo1NzozNikKYWNwaTA6IDxQ VExURCAgIFJTRFQ+IG9uIG1vdGhlcmJvYXJkCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDkgKElT QSBJUlEgOSkgdG8gdmVjdG9yIDQ4CmFjcGkwOiBbTVBTQUZFXQpwY2lfb3BlbigxKToJbW9kZSAx IGFkZHIgcG9ydCAoMHgwY2Y4KSBpcyAweDgwMDAzMDYwCnBjaV9vcGVuKDFhKToJbW9kZTFyZXM9 MHg4MDAwMDAwMCAoMHg4MDAwMDAwMCkKcGNpX2NmZ2NoZWNrOglkZXZpY2UgMCBbY2xhc3M9MDU4 MDAwXSBbaGRyPTAwXSBpcyB0aGVyZSAoaWQ9MDA1ZTEwZGUpCmFjcGlfYnVzX251bWJlcjogcm9v dCBidXMgaGFzIG5vIF9CQk4sIGFzc3VtaW5nIDAKQWNwaU9zRGVyaXZlUGNpSWQ6IGJ1cyAwIGRl diAxIGZ1bmMgMAphY3BpMDogUG93ZXIgQnV0dG9uIChmaXhlZCkKYWNwaV9idXNfbnVtYmVyOiBy b290IGJ1cyBoYXMgbm8gX0JCTiwgYXNzdW1pbmcgMApBY3BpT3NEZXJpdmVQY2lJZDogYnVzIDAg ZGV2IDEgZnVuYyAwCmFjcGlfYnVzX251bWJlcjogcm9vdCBidXMgaGFzIG5vIF9CQk4sIGFzc3Vt aW5nIDAKQWNwaU9zRGVyaXZlUGNpSWQ6IGJ1cyAwIGRldiAyNCBmdW5jIDEKYWNwaV9idXNfbnVt YmVyOiByb290IGJ1cyBoYXMgbm8gX0JCTiwgYXNzdW1pbmcgMApBY3BpT3NEZXJpdmVQY2lJZDog YnVzIDAgZGV2IDI0IGZ1bmMgMQphY3BpX2J1c19udW1iZXI6IHJvb3QgYnVzIGhhcyBubyBfQkJO LCBhc3N1bWluZyAwCkFjcGlPc0Rlcml2ZVBjaUlkOiBidXMgMCBkZXYgMSBmdW5jIDAKYWNwaV9i dXNfbnVtYmVyOiByb290IGJ1cyBoYXMgbm8gX0JCTiwgYXNzdW1pbmcgMApBY3BpT3NEZXJpdmVQ Y2lJZDogYnVzIDAgZGV2IDEgZnVuYyAwCmFjcGlfYnVzX251bWJlcjogcm9vdCBidXMgaGFzIG5v IF9CQk4sIGFzc3VtaW5nIDAKQWNwaU9zRGVyaXZlUGNpSWQ6IGJ1cyAwIGRldiAxIGZ1bmMgMAph Y3BpX2J1c19udW1iZXI6IHJvb3QgYnVzIGhhcyBubyBfQkJOLCBhc3N1bWluZyAwCkFjcGlPc0Rl cml2ZVBjaUlkOiBidXMgMCBkZXYgMSBmdW5jIDEKYWNwaV9idXNfbnVtYmVyOiByb290IGJ1cyBo YXMgbm8gX0JCTiwgYXNzdW1pbmcgMApBY3BpT3NEZXJpdmVQY2lJZDogYnVzIDAgZGV2IDEgZnVu YyAxCkFDUEkgdGltZXI6IDEvMSAxLzEgMS8xIDEvMSAxLzEgMS8xIDEvMSAxLzEgMS8xIDEvMSAt PiAxMApUaW1lY291bnRlciAiQUNQSS1mYXN0IiBmcmVxdWVuY3kgMzU3OTU0NSBIeiBxdWFsaXR5 IDEwMDAKYWNwaV90aW1lcjA6IDwyNC1iaXQgdGltZXIgYXQgMy41Nzk1NDVNSHo+IHBvcnQgMHg4 MDA4LTB4ODAwYiBvbiBhY3BpMApwY2lfbGluazA6IExpbmtzIGFmdGVyIGluaXRpYWwgcHJvYmU6 CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAyNTUgICBOICAgICAwICAxNiAxNyAx OCAxOQpwY2lfbGluazA6IExpbmtzIGFmdGVyIGluaXRpYWwgdmFsaWRhdGlvbjoKSW5kZXggIElS USAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAgIE4gICAgIDAgIDE2IDE3IDE4IDE5CnBjaV9s aW5rMDogTGlua3MgYWZ0ZXIgZGlzYWJsZToKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAg IDAgIDI1NSAgIE4gICAgIDAgIDE2IDE3IDE4IDE5CnBjaV9saW5rMTogTGlua3MgYWZ0ZXIgaW5p dGlhbCBwcm9iZToKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAgIE4gICAg IDAgIDE2IDE3IDE4IDE5CnBjaV9saW5rMTogTGlua3MgYWZ0ZXIgaW5pdGlhbCB2YWxpZGF0aW9u OgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgMjU1ICAgTiAgICAgMCAgMTYgMTcg MTggMTkKcGNpX2xpbmsxOiBMaW5rcyBhZnRlciBkaXNhYmxlOgpJbmRleCAgSVJRICBSdGQgIFJl ZiAgSVJRcwogICAgMCAgMjU1ICAgTiAgICAgMCAgMTYgMTcgMTggMTkKcGNpX2xpbmsyOiBMaW5r cyBhZnRlciBpbml0aWFsIHByb2JlOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAg MjU1ICAgTiAgICAgMCAgMTYgMTcgMTggMTkKcGNpX2xpbmsyOiBMaW5rcyBhZnRlciBpbml0aWFs IHZhbGlkYXRpb246CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAyNTUgICBOICAg ICAwICAxNiAxNyAxOCAxOQpwY2lfbGluazI6IExpbmtzIGFmdGVyIGRpc2FibGU6CkluZGV4ICBJ UlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAyNTUgICBOICAgICAwICAxNiAxNyAxOCAxOQpwY2lf bGluazM6IExpbmtzIGFmdGVyIGluaXRpYWwgcHJvYmU6CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJ UlFzCiAgICAwICAyNTUgICBOICAgICAwICAxNiAxNyAxOCAxOQpwY2lfbGluazM6IExpbmtzIGFm dGVyIGluaXRpYWwgdmFsaWRhdGlvbjoKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAg IDI1NSAgIE4gICAgIDAgIDE2IDE3IDE4IDE5CnBjaV9saW5rMzogTGlua3MgYWZ0ZXIgZGlzYWJs ZToKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAgIE4gICAgIDAgIDE2IDE3 IDE4IDE5CnBjaV9saW5rNDogTGlua3MgYWZ0ZXIgaW5pdGlhbCBwcm9iZToKSW5kZXggIElSUSAg UnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAgIE4gICAgIDAgIDE2IDE3IDE4IDE5CnBjaV9saW5r NDogTGlua3MgYWZ0ZXIgaW5pdGlhbCB2YWxpZGF0aW9uOgpJbmRleCAgSVJRICBSdGQgIFJlZiAg SVJRcwogICAgMCAgMjU1ICAgTiAgICAgMCAgMTYgMTcgMTggMTkKcGNpX2xpbms0OiBMaW5rcyBh ZnRlciBkaXNhYmxlOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgMjU1ICAgTiAg ICAgMCAgMTYgMTcgMTggMTkKcGNpX2xpbms1OiBMaW5rcyBhZnRlciBpbml0aWFsIHByb2JlOgpJ bmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgMjU1ICAgTiAgICAgMCAgMjAgMjEgMjIg MjMKcGNpX2xpbms1OiBMaW5rcyBhZnRlciBpbml0aWFsIHZhbGlkYXRpb246CkluZGV4ICBJUlEg IFJ0ZCAgUmVmICBJUlFzCiAgICAwICAyNTUgICBOICAgICAwICAyMCAyMSAyMiAyMwpwY2lfbGlu azU6IExpbmtzIGFmdGVyIGRpc2FibGU6CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAw ICAyNTUgICBOICAgICAwICAyMCAyMSAyMiAyMwpwY2lfbGluazY6IExpbmtzIGFmdGVyIGluaXRp YWwgcHJvYmU6CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAyNTUgICBOICAgICAw ICAyMCAyMSAyMiAyMwpwY2lfbGluazY6IExpbmtzIGFmdGVyIGluaXRpYWwgdmFsaWRhdGlvbjoK SW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAgIE4gICAgIDAgIDIwIDIxIDIy IDIzCnBjaV9saW5rNjogTGlua3MgYWZ0ZXIgZGlzYWJsZToKSW5kZXggIElSUSAgUnRkICBSZWYg IElSUXMKICAgIDAgIDI1NSAgIE4gICAgIDAgIDIwIDIxIDIyIDIzCnBjaV9saW5rNzogTGlua3Mg YWZ0ZXIgaW5pdGlhbCBwcm9iZToKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1 NSAgIE4gICAgIDAgIDIwIDIxIDIyIDIzCnBjaV9saW5rNzogTGlua3MgYWZ0ZXIgaW5pdGlhbCB2 YWxpZGF0aW9uOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgMjU1ICAgTiAgICAg MCAgMjAgMjEgMjIgMjMKcGNpX2xpbms3OiBMaW5rcyBhZnRlciBkaXNhYmxlOgpJbmRleCAgSVJR ICBSdGQgIFJlZiAgSVJRcwogICAgMCAgMjU1ICAgTiAgICAgMCAgMjAgMjEgMjIgMjMKcGNpX2xp bms4OiBMaW5rcyBhZnRlciBpbml0aWFsIHByb2JlOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJR cwogICAgMCAgMjU1ICAgTiAgICAgMCAgMjAgMjEgMjIgMjMKcGNpX2xpbms4OiBMaW5rcyBhZnRl ciBpbml0aWFsIHZhbGlkYXRpb246CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAy NTUgICBOICAgICAwICAyMCAyMSAyMiAyMwpwY2lfbGluazg6IExpbmtzIGFmdGVyIGRpc2FibGU6 CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAyNTUgICBOICAgICAwICAyMCAyMSAy MiAyMwpwY2lfbGluazk6IExpbmtzIGFmdGVyIGluaXRpYWwgcHJvYmU6CkluZGV4ICBJUlEgIFJ0 ZCAgUmVmICBJUlFzCiAgICAwICAyNTUgICBOICAgICAwICAyMCAyMSAyMiAyMwpwY2lfbGluazk6 IExpbmtzIGFmdGVyIGluaXRpYWwgdmFsaWRhdGlvbjoKSW5kZXggIElSUSAgUnRkICBSZWYgIElS UXMKICAgIDAgIDI1NSAgIE4gICAgIDAgIDIwIDIxIDIyIDIzCnBjaV9saW5rOTogTGlua3MgYWZ0 ZXIgZGlzYWJsZToKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAgIE4gICAg IDAgIDIwIDIxIDIyIDIzCnBjaV9saW5rMTA6IExpbmtzIGFmdGVyIGluaXRpYWwgcHJvYmU6Cklu ZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAyNTUgICBOICAgICAwICAyMCAyMSAyMiAy MwpwY2lfbGluazEwOiBMaW5rcyBhZnRlciBpbml0aWFsIHZhbGlkYXRpb246CkluZGV4ICBJUlEg IFJ0ZCAgUmVmICBJUlFzCiAgICAwICAyNTUgICBOICAgICAwICAyMCAyMSAyMiAyMwpwY2lfbGlu azEwOiBMaW5rcyBhZnRlciBkaXNhYmxlOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAg MCAgMjU1ICAgTiAgICAgMCAgMjAgMjEgMjIgMjMKcGNpX2xpbmsxMTogTGlua3MgYWZ0ZXIgaW5p dGlhbCBwcm9iZToKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAgIE4gICAg IDAgIDIwIDIxIDIyIDIzCnBjaV9saW5rMTE6IExpbmtzIGFmdGVyIGluaXRpYWwgdmFsaWRhdGlv bjoKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAgIE4gICAgIDAgIDIwIDIx IDIyIDIzCnBjaV9saW5rMTE6IExpbmtzIGFmdGVyIGRpc2FibGU6CkluZGV4ICBJUlEgIFJ0ZCAg UmVmICBJUlFzCiAgICAwICAyNTUgICBOICAgICAwICAyMCAyMSAyMiAyMwpwY2lfbGluazEyOiBM aW5rcyBhZnRlciBpbml0aWFsIHByb2JlOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAg MCAgMjU1ICAgTiAgICAgMCAgMjAgMjEgMjIgMjMKcGNpX2xpbmsxMjogTGlua3MgYWZ0ZXIgaW5p dGlhbCB2YWxpZGF0aW9uOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgMjU1ICAg TiAgICAgMCAgMjAgMjEgMjIgMjMKcGNpX2xpbmsxMjogTGlua3MgYWZ0ZXIgZGlzYWJsZToKSW5k ZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAgIE4gICAgIDAgIDIwIDIxIDIyIDIz CnBjaV9saW5rMTM6IExpbmtzIGFmdGVyIGluaXRpYWwgcHJvYmU6CkluZGV4ICBJUlEgIFJ0ZCAg UmVmICBJUlFzCiAgICAwICAyNTUgICBOICAgICAwICAyMCAyMSAyMiAyMwpwY2lfbGluazEzOiBM aW5rcyBhZnRlciBpbml0aWFsIHZhbGlkYXRpb246CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFz CiAgICAwICAyNTUgICBOICAgICAwICAyMCAyMSAyMiAyMwpwY2lfbGluazEzOiBMaW5rcyBhZnRl ciBkaXNhYmxlOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgMjU1ICAgTiAgICAg MCAgMjAgMjEgMjIgMjMKcGNpX2xpbmsxNDogTGlua3MgYWZ0ZXIgaW5pdGlhbCBwcm9iZToKSW5k ZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAgIE4gICAgIDAgIDIwIDIxIDIyIDIz CnBjaV9saW5rMTQ6IExpbmtzIGFmdGVyIGluaXRpYWwgdmFsaWRhdGlvbjoKSW5kZXggIElSUSAg UnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAgIE4gICAgIDAgIDIwIDIxIDIyIDIzCnBjaV9saW5r MTQ6IExpbmtzIGFmdGVyIGRpc2FibGU6CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAw ICAyNTUgICBOICAgICAwICAyMCAyMSAyMiAyMwpjcHUwOiA8QUNQSSBDUFU+IG9uIGFjcGkwCmNw dTE6IDxBQ1BJIENQVT4gb24gYWNwaTAKY3B1MjogPEFDUEkgQ1BVPiBvbiBhY3BpMApjcHUzOiA8 QUNQSSBDUFU+IG9uIGFjcGkwCmFjcGlfYnV0dG9uMDogPFBvd2VyIEJ1dHRvbj4gb24gYWNwaTAK cGNpYjA6IDxBQ1BJIEhvc3QtUENJIGJyaWRnZT4gcG9ydCAweGNmOC0weGNmZiBvbiBhY3BpMApw Y2kwOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMApwY2kwOiBwaHlzaWNhbCBidXM9MApmb3VuZC0+ CXZlbmRvcj0weDEwZGUsIGRldj0weDAwNWUsIHJldmlkPTB4YTMKCWJ1cz0wLCBzbG90PTAsIGZ1 bmM9MAoJY2xhc3M9MDUtODAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAw Niwgc3RhdHJlZz0weDAwYjAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgw IG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKZm91bmQtPgl2ZW5k b3I9MHgxMGRlLCBkZXY9MHgwMDUxLCByZXZpZD0weGEzCglidXM9MCwgc2xvdD0xLCBmdW5jPTAK CWNsYXNzPTA2LTAxLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKCWNtZHJlZz0weDAwMGYsIHN0 YXRyZWc9MHgwMGEwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyks IG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCgltYXBbMTBdOiB0eXBlIDQs IHJhbmdlIDMyLCBiYXNlIDAwMDA4YzAwLCBzaXplIDEwLCBlbmFibGVkCmZvdW5kLT4JdmVuZG9y PTB4MTBkZSwgZGV2PTB4MDA1MiwgcmV2aWQ9MHhhMgoJYnVzPTAsIHNsb3Q9MSwgZnVuYz0xCglj bGFzcz0wYy0wNS0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0xCgljbWRyZWc9MHgwMDAxLCBzdGF0 cmVnPTB4MDBiMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBt aW5nbnQ9MHgwMyAoNzUwIG5zKSwgbWF4bGF0PTB4MDEgKDI1MCBucykKCWludHBpbj1hLCBpcnE9 MjU1Cglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCW1hcFsxMF06IHR5 cGUgNCwgcmFuZ2UgMzIsIGJhc2UgMDAwMDAwMDAsIHNpemUgIDUsIGVuYWJsZWQKCW1hcFsyMF06 IHR5cGUgNCwgcmFuZ2UgMzIsIGJhc2UgMDAwMDUwMDAsIHNpemUgIDYsIGVuYWJsZWQKCW1hcFsy NF06IHR5cGUgNCwgcmFuZ2UgMzIsIGJhc2UgMDAwMDUwNDAsIHNpemUgIDYsIGVuYWJsZWQKZm91 bmQtPgl2ZW5kb3I9MHgxMGRlLCBkZXY9MHgwMDVhLCByZXZpZD0weGEyCglidXM9MCwgc2xvdD0y LCBmdW5jPTAKCWNsYXNzPTBjLTAzLTEwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKCWNtZHJlZz0w eDAwMDcsIHN0YXRyZWc9MHgwMGIwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgw MCAoMCBucyksIG1pbmdudD0weDAzICg3NTAgbnMpLCBtYXhsYXQ9MHgwMSAoMjUwIG5zKQoJaW50 cGluPWEsIGlycT0xMAoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQxIEQyIEQzICBjdXJyZW50 IEQwCgltYXBbMTBdOiB0eXBlIDEsIHJhbmdlIDMyLCBiYXNlIGQ4MDAwMDAwLCBzaXplIDEyLCBl bmFibGVkCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjIuSU5UQSAoc3JjIFxcX1NCXy5QQ0kw LkxVUzA6MCkKcGNpX2xpbms2OiBQaWNrZWQgSVJRIDIwIHdpdGggd2VpZ2h0IDAKaW9hcGljMDog Q2hhbmdpbmcgcG9sYXJpdHkgZm9yIHBpbiAyMCB0byBoaWdoCnBjaWIwOiBzbG90IDIgSU5UQSBy b3V0ZWQgdG8gaXJxIDIwIHZpYSBcXF9TQl8uUENJMC5MVVMwCmZvdW5kLT4JdmVuZG9yPTB4MTBk ZSwgZGV2PTB4MDA1YiwgcmV2aWQ9MHhhMwoJYnVzPTAsIHNsb3Q9MiwgZnVuYz0xCgljbGFzcz0w Yy0wMy0yMCwgaGRydHlwZT0weDAwLCBtZmRldj0xCgljbWRyZWc9MHgwMDA2LCBzdGF0cmVnPTB4 MDBiMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9 MHgwMyAoNzUwIG5zKSwgbWF4bGF0PTB4MDEgKDI1MCBucykKCWludHBpbj1iLCBpcnE9NQoJcG93 ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQxIEQyIEQzICBjdXJyZW50IEQwCgltYXBbMTBdOiB0eXBl IDEsIHJhbmdlIDMyLCBiYXNlIGQ4MDAxMDAwLCBzaXplICA4LCBlbmFibGVkCnBjaWIwOiBtYXRj aGVkIGVudHJ5IGZvciAwLjIuSU5UQiAoc3JjIFxcX1NCXy5QQ0kwLkxVUzI6MCkKcGNpX2xpbms3 OiBQaWNrZWQgSVJRIDIxIHdpdGggd2VpZ2h0IDAKaW9hcGljMDogQ2hhbmdpbmcgcG9sYXJpdHkg Zm9yIHBpbiAyMSB0byBoaWdoCnBjaWIwOiBzbG90IDIgSU5UQiByb3V0ZWQgdG8gaXJxIDIxIHZp YSBcXF9TQl8uUENJMC5MVVMyCmZvdW5kLT4JdmVuZG9yPTB4MTBkZSwgZGV2PTB4MDA1MywgcmV2 aWQ9MHhmMgoJYnVzPTAsIHNsb3Q9NiwgZnVuYz0wCgljbGFzcz0wMS0wMS04YSwgaGRydHlwZT0w eDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMDA1LCBzdGF0cmVnPTB4MDBiMCwgY2FjaGVsbnN6PTAg KGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMyAoNzUwIG5zKSwgbWF4 bGF0PTB4MDEgKDI1MCBucykKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBE MAoJbWFwWzIwXTogdHlwZSA0LCByYW5nZSAzMiwgYmFzZSAwMDAwMTQwMCwgc2l6ZSAgNCwgZW5h YmxlZApmb3VuZC0+CXZlbmRvcj0weDEwZGUsIGRldj0weDAwNWMsIHJldmlkPTB4YTIKCWJ1cz0w LCBzbG90PTksIGZ1bmM9MAoJY2xhc3M9MDYtMDQtMDAsIGhkcnR5cGU9MHgwMSwgbWZkZXY9MAoJ Y21kcmVnPTB4MDEwNywgc3RhdHJlZz0weDAwYTAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0 aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MGMgKDMwMDAgbnMpLCBtYXhsYXQ9MHgwMiAoNTAw IG5zKQpmb3VuZC0+CXZlbmRvcj0weDEwZGUsIGRldj0weDAwNWQsIHJldmlkPTB4YTMKCWJ1cz0w LCBzbG90PTE0LCBmdW5jPTAKCWNsYXNzPTA2LTA0LTAwLCBoZHJ0eXBlPTB4MDEsIG1mZGV2PTAK CWNtZHJlZz0weDAxMDcsIHN0YXRyZWc9MHgwMDEwLCBjYWNoZWxuc3o9MTYgKGR3b3JkcykKCWxh dHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwNCAoMTAwMCBucyksIG1heGxhdD0weDAwICgw IG5zKQpmb3VuZC0+CXZlbmRvcj0weDEwMjIsIGRldj0weDExMDAsIHJldmlkPTB4MDAKCWJ1cz0w LCBzbG90PTI0LCBmdW5jPTAKCWNsYXNzPTA2LTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEK CWNtZHJlZz0weDAwMDAsIHN0YXRyZWc9MHgwMDEwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0 dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMp CmZvdW5kLT4JdmVuZG9yPTB4MTAyMiwgZGV2PTB4MTEwMSwgcmV2aWQ9MHgwMAoJYnVzPTAsIHNs b3Q9MjQsIGZ1bmM9MQoJY2xhc3M9MDYtMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21k cmVnPTB4MDAwMCwgc3RhdHJlZz0weDAwMDAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1l cj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKZm91 bmQtPgl2ZW5kb3I9MHgxMDIyLCBkZXY9MHgxMTAyLCByZXZpZD0weDAwCglidXM9MCwgc2xvdD0y NCwgZnVuYz0yCgljbGFzcz0wNi0wMC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0xCgljbWRyZWc9 MHgwMDAwLCBzdGF0cmVnPTB4MDAwMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4 MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQpmb3VuZC0+ CXZlbmRvcj0weDEwMjIsIGRldj0weDExMDMsIHJldmlkPTB4MDAKCWJ1cz0wLCBzbG90PTI0LCBm dW5jPTMKCWNsYXNzPTA2LTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKCWNtZHJlZz0weDAw MDAsIHN0YXRyZWc9MHgwMDAwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAo MCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCmZvdW5kLT4JdmVu ZG9yPTB4MTAyMiwgZGV2PTB4MTEwMCwgcmV2aWQ9MHgwMAoJYnVzPTAsIHNsb3Q9MjUsIGZ1bmM9 MAoJY2xhc3M9MDYtMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDAwMCwg c3RhdHJlZz0weDAwMTAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5z KSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKZm91bmQtPgl2ZW5kb3I9 MHgxMDIyLCBkZXY9MHgxMTAxLCByZXZpZD0weDAwCglidXM9MCwgc2xvdD0yNSwgZnVuYz0xCglj bGFzcz0wNi0wMC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0xCgljbWRyZWc9MHgwMDAwLCBzdGF0 cmVnPTB4MDAwMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBt aW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQpmb3VuZC0+CXZlbmRvcj0weDEw MjIsIGRldj0weDExMDIsIHJldmlkPTB4MDAKCWJ1cz0wLCBzbG90PTI1LCBmdW5jPTIKCWNsYXNz PTA2LTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKCWNtZHJlZz0weDAwMDAsIHN0YXRyZWc9 MHgwMDAwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdu dD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCmZvdW5kLT4JdmVuZG9yPTB4MTAyMiwg ZGV2PTB4MTEwMywgcmV2aWQ9MHgwMAoJYnVzPTAsIHNsb3Q9MjUsIGZ1bmM9MwoJY2xhc3M9MDYt MDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDAwMCwgc3RhdHJlZz0weDAw MDAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4 MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKcGNpMDogPG1lbW9yeT4gYXQgZGV2aWNlIDAu MCAobm8gZHJpdmVyIGF0dGFjaGVkKQppc2FiMDogPFBDSS1JU0EgYnJpZGdlPiBhdCBkZXZpY2Ug MS4wIG9uIHBjaTAKaXNhMDogPElTQSBidXM+IG9uIGlzYWIwCnBjaTA6IDxzZXJpYWwgYnVzLCBT TUJ1cz4gYXQgZGV2aWNlIDEuMSAobm8gZHJpdmVyIGF0dGFjaGVkKQpvaGNpMDogPE9IQ0kgKGdl bmVyaWMpIFVTQiBjb250cm9sbGVyPiBtZW0gMHhkODAwMDAwMC0weGQ4MDAwZmZmIGlycSAyMCBh dCBkZXZpY2UgMi4wIG9uIHBjaTAKb2hjaTA6IFJlc2VydmVkIDB4MTAwMCBieXRlcyBmb3Igcmlk IDB4MTAgdHlwZSAzIGF0IDB4ZDgwMDAwMDAKaW9hcGljMDogcm91dGluZyBpbnRwaW4gMjAgKFBD SSBJUlEgMjApIHRvIHZlY3RvciA0OQpvaGNpMDogW0dJQU5ULUxPQ0tFRF0KdXNiMDogT0hDSSB2 ZXJzaW9uIDEuMCwgbGVnYWN5IHN1cHBvcnQKdXNiMDogU01NIGRvZXMgbm90IHJlc3BvbmQsIHJl c2V0dGluZwp1c2IwOiA8T0hDSSAoZ2VuZXJpYykgVVNCIGNvbnRyb2xsZXI+IG9uIG9oY2kwCnVz YjA6IFVTQiByZXZpc2lvbiAxLjAKdWh1YjA6IG5WaWRpYSBPSENJIHJvb3QgaHViLCBjbGFzcyA5 LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMQp1aHViMDogMTAgcG9ydHMgd2l0aCAxMCByZW1vdmFi bGUsIHNlbGYgcG93ZXJlZAplaGNpMDogPE5WSURJQSBuRm9yY2U0IFVTQiAyLjAgY29udHJvbGxl cj4gbWVtIDB4ZDgwMDEwMDAtMHhkODAwMTBmZiBpcnEgMjEgYXQgZGV2aWNlIDIuMSBvbiBwY2kw CmVoY2kwOiBSZXNlcnZlZCAweDEwMCBieXRlcyBmb3IgcmlkIDB4MTAgdHlwZSAzIGF0IDB4ZDgw MDEwMDAKaW9hcGljMDogcm91dGluZyBpbnRwaW4gMjEgKFBDSSBJUlEgMjEpIHRvIHZlY3RvciA1 MAplaGNpMDogW0dJQU5ULUxPQ0tFRF0KdXNiMTogRUhDSSB2ZXJzaW9uIDEuMAp1c2IxOiBjb21w YW5pb24gY29udHJvbGxlciwgNCBwb3J0cyBlYWNoOiB1c2IwCnVzYjE6IDxOVklESUEgbkZvcmNl NCBVU0IgMi4wIGNvbnRyb2xsZXI+IG9uIGVoY2kwCnVzYjE6IFVTQiByZXZpc2lvbiAyLjAKdWh1 YjE6IG5WaWRpYSBFSENJIHJvb3QgaHViLCBjbGFzcyA5LzAsIHJldiAyLjAwLzEuMDAsIGFkZHIg MQp1aHViMTogMTAgcG9ydHMgd2l0aCAxMCByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAphdGFwY2kw OiA8blZpZGlhIG5Gb3JjZSBDSzgwNCBVRE1BMTMzIGNvbnRyb2xsZXI+IHBvcnQgMHgxZjAtMHgx ZjcsMHgzZjYsMHgxNzAtMHgxNzcsMHgzNzYsMHgxNDAwLTB4MTQwZiBhdCBkZXZpY2UgNi4wIG9u IHBjaTAKYXRhcGNpMDogUmVzZXJ2ZWQgMHgxMCBieXRlcyBmb3IgcmlkIDB4MjAgdHlwZSA0IGF0 IDB4MTQwMAphdGEwOiA8QVRBIGNoYW5uZWwgMD4gb24gYXRhcGNpMAphdGFwY2kwOiBSZXNlcnZl ZCAweDggYnl0ZXMgZm9yIHJpZCAweDEwIHR5cGUgNCBhdCAweDFmMAphdGFwY2kwOiBSZXNlcnZl ZCAweDEgYnl0ZXMgZm9yIHJpZCAweDE0IHR5cGUgNCBhdCAweDNmNgphdGEwOiByZXNldCB0cDEg bWFzaz0wMyBvc3RhdDA9NTAgb3N0YXQxPTAwCmF0YTA6IHN0YXQwPTB4MDAgZXJyPTB4MDEgbHNi PTB4MTQgbXNiPTB4ZWIKYXRhMDogc3RhdDE9MHgwMCBlcnI9MHgwMCBsc2I9MHgwMCBtc2I9MHgw MAphdGEwOiByZXNldCB0cDIgc3RhdDA9MDAgc3RhdDE9MDAgZGV2aWNlcz0weDQ8QVRBUElfTUFT VEVSPgppb2FwaWMwOiByb3V0aW5nIGludHBpbiAxNCAoSVNBIElSUSAxNCkgdG8gdmVjdG9yIDUx CmF0YTA6IFtNUFNBRkVdCmF0YTE6IDxBVEEgY2hhbm5lbCAxPiBvbiBhdGFwY2kwCmF0YXBjaTA6 IFJlc2VydmVkIDB4OCBieXRlcyBmb3IgcmlkIDB4MTggdHlwZSA0IGF0IDB4MTcwCmF0YXBjaTA6 IFJlc2VydmVkIDB4MSBieXRlcyBmb3IgcmlkIDB4MWMgdHlwZSA0IGF0IDB4Mzc2CmF0YTE6IHJl c2V0IHRwMSBtYXNrPTAzIG9zdGF0MD02MCBvc3RhdDE9NzAKYXRhMTogc3RhdDA9MHgyMCBlcnI9 MHgyMCBsc2I9MHgyMCBtc2I9MHgyMAphdGExOiBzdGF0MT0weDMwIGVycj0weDMwIGxzYj0weDMw IG1zYj0weDMwCmF0YTE6IHJlc2V0IHRwMiBzdGF0MD0yMCBzdGF0MT0zMCBkZXZpY2VzPTB4MApp b2FwaWMwOiByb3V0aW5nIGludHBpbiAxNSAoSVNBIElSUSAxNSkgdG8gdmVjdG9yIDUyCmF0YTE6 IFtNUFNBRkVdCnBjaWIxOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDkuMCBvbiBw Y2kwCnBjaWIxOiAgIHNlY29uZGFyeSBidXMgICAgIDEKcGNpYjE6ICAgc3Vib3JkaW5hdGUgYnVz ICAgMQpwY2liMTogICBJL08gZGVjb2RlICAgICAgICAweDIwMDAtMHgyZmZmCnBjaWIxOiAgIG1l bW9yeSBkZWNvZGUgICAgIDB4ZDgxMDAwMDAtMHhkOWZmZmZmZgpwY2liMTogICBwcmVmZXRjaGVk IGRlY29kZSAweGZmZjAwMDAwLTB4ZmZmZmYKcGNpMTogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjEK cGNpMTogcGh5c2ljYWwgYnVzPTEKZm91bmQtPgl2ZW5kb3I9MHgxMDAyLCBkZXY9MHg0NzUyLCBy ZXZpZD0weDI3CglidXM9MSwgc2xvdD03LCBmdW5jPTAKCWNsYXNzPTAzLTAwLTAwLCBoZHJ0eXBl PTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAwODcsIHN0YXRyZWc9MHgwMjkwLCBjYWNoZWxuc3o9 MTYgKGR3b3JkcykKCWxhdHRpbWVyPTB4NDIgKDE5ODAgbnMpLCBtaW5nbnQ9MHgwOCAoMjAwMCBu cyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWEsIGlycT0xMQoJcG93ZXJzcGVjIDIgIHN1 cHBvcnRzIEQwIEQxIEQyIEQzICBjdXJyZW50IEQwCgltYXBbMTBdOiB0eXBlIDEsIHJhbmdlIDMy LCBiYXNlIGQ5MDAwMDAwLCBzaXplIDI0LCBlbmFibGVkCnBjaWIxOiAobnVsbCkgcmVxdWVzdGVk IG1lbW9yeSByYW5nZSAweGQ5MDAwMDAwLTB4ZDlmZmZmZmY6IGdvb2QKCW1hcFsxNF06IHR5cGUg NCwgcmFuZ2UgMzIsIGJhc2UgMDAwMDIwMDAsIHNpemUgIDgsIGVuYWJsZWQKcGNpYjE6IChudWxs KSByZXF1ZXN0ZWQgSS9PIHJhbmdlIDB4MjAwMC0weDIwZmY6IGluIHJhbmdlCgltYXBbMThdOiB0 eXBlIDEsIHJhbmdlIDMyLCBiYXNlIGQ4MTAwMDAwLCBzaXplIDEyLCBlbmFibGVkCnBjaWIxOiAo bnVsbCkgcmVxdWVzdGVkIG1lbW9yeSByYW5nZSAweGQ4MTAwMDAwLTB4ZDgxMDBmZmY6IGdvb2QK cGNpYjE6IG1hdGNoZWQgZW50cnkgZm9yIDEuNy5JTlRBIChzcmMgXFxfU0JfLlBDSTAuTE5LMzow KQpwY2lfbGluazI6IFBpY2tlZCBJUlEgMTYgd2l0aCB3ZWlnaHQgMAppb2FwaWMwOiBDaGFuZ2lu ZyBwb2xhcml0eSBmb3IgcGluIDE2IHRvIGhpZ2gKcGNpYjE6IHNsb3QgNyBJTlRBIHJvdXRlZCB0 byBpcnEgMTYgdmlhIFxcX1NCXy5QQ0kwLkxOSzMKcGNpMTogPGRpc3BsYXksIFZHQT4gYXQgZGV2 aWNlIDcuMCAobm8gZHJpdmVyIGF0dGFjaGVkKQpwY2liMjogPEFDUEkgUENJLVBDSSBicmlkZ2U+ IGF0IGRldmljZSAxNC4wIG9uIHBjaTAKcGNpYjI6ICAgc2Vjb25kYXJ5IGJ1cyAgICAgMgpwY2li MjogICBzdWJvcmRpbmF0ZSBidXMgICAyCnBjaWIyOiAgIEkvTyBkZWNvZGUgICAgICAgIDB4MzAw MC0weDNmZmYKcGNpYjI6ICAgbWVtb3J5IGRlY29kZSAgICAgMHhkYTAwMDAwMC0weGRhMGZmZmZm CnBjaWIyOiAgIHByZWZldGNoZWQgZGVjb2RlIDB4ZGMwMDAwMDAtMHhkZGZmZmZmZgpwY2kyOiA8 QUNQSSBQQ0kgYnVzPiBvbiBwY2liMgpwY2kyOiBwaHlzaWNhbCBidXM9Mgpmb3VuZC0+CXZlbmRv cj0weDEzYzEsIGRldj0weDEwMDQsIHJldmlkPTB4MDEKCWJ1cz0yLCBzbG90PTAsIGZ1bmM9MAoJ Y2xhc3M9MDEtMDQtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDEwNywgc3Rh dHJlZz0weDAwMTAsIGNhY2hlbG5zej0xNiAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyks IG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YSwgaXJxPTEx Cglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDEgRDIgRDMgIGN1cnJlbnQgRDAKCU1TSSBzdXBw b3J0cyAzMiBtZXNzYWdlcywgNjQgYml0CgltYXBbMTBdOiB0eXBlIDMsIHJhbmdlIDY0LCBiYXNl IGRjMDAwMDAwLCBzaXplIDI1LCBlbmFibGVkCnBjaWIyOiAobnVsbCkgcmVxdWVzdGVkIG1lbW9y eSByYW5nZSAweGRjMDAwMDAwLTB4ZGRmZmZmZmY6IGdvb2QKCW1hcFsxOF06IHR5cGUgMSwgcmFu Z2UgNjQsIGJhc2UgZGEwMDEwMDAsIHNpemUgMTIsIGVuYWJsZWQKcGNpYjI6IChudWxsKSByZXF1 ZXN0ZWQgbWVtb3J5IHJhbmdlIDB4ZGEwMDEwMDAtMHhkYTAwMWZmZjogZ29vZAoJbWFwWzIwXTog dHlwZSA0LCByYW5nZSAzMiwgYmFzZSAwMDAwMzAwMCwgc2l6ZSAgOCwgZW5hYmxlZApwY2liMjog KG51bGwpIHJlcXVlc3RlZCBJL08gcmFuZ2UgMHgzMDAwLTB4MzBmZjogaW4gcmFuZ2UKCW1hcFsy NF06IHR5cGUgMSwgcmFuZ2UgMzIsIGJhc2UgZGEwMDAwMDAsIHNpemUgMTIsIGVuYWJsZWQKcGNp YjI6IChudWxsKSByZXF1ZXN0ZWQgbWVtb3J5IHJhbmdlIDB4ZGEwMDAwMDAtMHhkYTAwMGZmZjog Z29vZApwY2liMjogbWF0Y2hlZCBlbnRyeSBmb3IgMi4wLklOVEEgKHNyYyBcXF9TQl8uUENJMC5M TkszOjApCnBjaWIyOiBzbG90IDAgSU5UQSByb3V0ZWQgdG8gaXJxIDE2IHZpYSBcXF9TQl8uUENJ MC5MTkszCjN3YXJlIGRldmljZSBkcml2ZXIgZm9yIDkwMDAgc2VyaWVzIHN0b3JhZ2UgY29udHJv bGxlcnMsIHZlcnNpb246IDMuNjAuMDMuMDA2CnR3YTA6IDwzd2FyZSA5MDAwIHNlcmllcyBTdG9y YWdlIENvbnRyb2xsZXI+IHBvcnQgMHgzMDAwLTB4MzBmZiBtZW0gMHhkYzAwMDAwMC0weGRkZmZm ZmZmLDB4ZGEwMDEwMDAtMHhkYTAwMWZmZiwweGRhMDAwMDAwLTB4ZGEwMDBmZmYgaXJxIDE2IGF0 IGRldmljZSAwLjAgb24gcGNpMgp0d2EwOiBSZXNlcnZlZCAweDEwMDAgYnl0ZXMgZm9yIHJpZCAw eDE4IHR5cGUgMyBhdCAweGRhMDAxMDAwCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDE2IChQQ0kg SVJRIDE2KSB0byB2ZWN0b3IgNTMKdHdhMDogW01QU0FGRV0KdHdhMDogW0ZBU1RdCnR3YTA6IElO Rk86ICgweDA0OiAweDAwNTMpOiBCYXR0ZXJ5IGNhcGFjaXR5IHRlc3QgaXMgb3ZlcmR1ZTogCnR3 YTA6IElORk86ICgweDE1OiAweDEzMDApOiBDb250cm9sbGVyIGRldGFpbHM6OiBNb2RlbCA5NjUw U0UtMTZNTCwgMTYgcG9ydHMsIEZpcm13YXJlIEZFOVggMy4wNi4wMC4wMDMsIEJJT1MgQkU5WCAz LjA2LjAwLjAwMgpwY2liMzogPEFDUEkgSG9zdC1QQ0kgYnJpZGdlPiBwb3J0IDB4Y2Y4LTB4Y2Zm IG9uIGFjcGkwCnBjaWIzOiBjb3VsZCBub3QgZ2V0IFBDSSBpbnRlcnJ1cHQgcm91dGluZyB0YWJs ZSBmb3IgXFxfU0JfLlBDSTIgLSBBRV9OT1RfRk9VTkQKcGNpODogPEFDUEkgUENJIGJ1cz4gb24g cGNpYjMKcGNpODogcGh5c2ljYWwgYnVzPTgKZm91bmQtPgl2ZW5kb3I9MHgxMDIyLCBkZXY9MHg3 NDUwLCByZXZpZD0weDEzCglidXM9OCwgc2xvdD0xMCwgZnVuYz0wCgljbGFzcz0wNi0wNC0wMCwg aGRydHlwZT0weDAxLCBtZmRldj0xCgljbWRyZWc9MHgwMTE3LCBzdGF0cmVnPTB4MDIzMCwgY2Fj aGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4NDAgKDE5MjAgbnMpLCBtaW5nbnQ9MHgwNCAo MTAwMCBucyksIG1heGxhdD0weDAwICgwIG5zKQpmb3VuZC0+CXZlbmRvcj0weDEwMjIsIGRldj0w eDc0NTEsIHJldmlkPTB4MDEKCWJ1cz04LCBzbG90PTEwLCBmdW5jPTEKCWNsYXNzPTA4LTAwLTEw LCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDYsIHN0YXRyZWc9MHgwMjAwLCBj YWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgw IG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCgltYXBbMTBdOiB0eXBlIDEsIHJhbmdlIDY0LCBiYXNl IGRlMDAwMDAwLCBzaXplIDEyLCBlbmFibGVkCmZvdW5kLT4JdmVuZG9yPTB4MTAyMiwgZGV2PTB4 NzQ1MCwgcmV2aWQ9MHgxMwoJYnVzPTgsIHNsb3Q9MTEsIGZ1bmM9MAoJY2xhc3M9MDYtMDQtMDAs IGhkcnR5cGU9MHgwMSwgbWZkZXY9MQoJY21kcmVnPTB4MDExNywgc3RhdHJlZz0weDAyMzAsIGNh Y2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDQwICgxOTIwIG5zKSwgbWluZ250PTB4MDQg KDEwMDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKZm91bmQtPgl2ZW5kb3I9MHgxMDIyLCBkZXY9 MHg3NDUxLCByZXZpZD0weDAxCglidXM9OCwgc2xvdD0xMSwgZnVuYz0xCgljbGFzcz0wOC0wMC0x MCwgaGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMDA2LCBzdGF0cmVnPTB4MDIwMCwg Y2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAo MCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJbWFwWzEwXTogdHlwZSAxLCByYW5nZSA2NCwgYmFz ZSBkZTAwMTAwMCwgc2l6ZSAxMiwgZW5hYmxlZApwY2liNDogPEFDUEkgUENJLVBDSSBicmlkZ2U+ IGF0IGRldmljZSAxMC4wIG9uIHBjaTgKcGNpYjQ6ICAgc2Vjb25kYXJ5IGJ1cyAgICAgOQpwY2li NDogICBzdWJvcmRpbmF0ZSBidXMgICA5CnBjaWI0OiAgIEkvTyBkZWNvZGUgICAgICAgIDB4ZjAw MC0weGZmZgpwY2liNDogICBtZW1vcnkgZGVjb2RlICAgICAweGZmZjAwMDAwLTB4ZmZmZmYKcGNp YjQ6ICAgcHJlZmV0Y2hlZCBkZWNvZGUgMHhmZmYwMDAwMC0weGZmZmZmCnBjaTk6IDxBQ1BJIFBD SSBidXM+IG9uIHBjaWI0CnBjaTk6IHBoeXNpY2FsIGJ1cz05CnBjaTg6IDxiYXNlIHBlcmlwaGVy YWwsIGludGVycnVwdCBjb250cm9sbGVyPiBhdCBkZXZpY2UgMTAuMSAobm8gZHJpdmVyIGF0dGFj aGVkKQpwY2liNTogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAxMS4wIG9uIHBjaTgK cGNpYjU6ICAgc2Vjb25kYXJ5IGJ1cyAgICAgMTAKcGNpYjU6ICAgc3Vib3JkaW5hdGUgYnVzICAg MTAKcGNpYjU6ICAgSS9PIGRlY29kZSAgICAgICAgMHhmMDAwLTB4ZmZmCnBjaWI1OiAgIG1lbW9y eSBkZWNvZGUgICAgIDB4ZGUxMDAwMDAtMHhkZTFmZmZmZgpwY2liNTogICBwcmVmZXRjaGVkIGRl Y29kZSAweGZmZjAwMDAwLTB4ZmZmZmYKcGNpMTA6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWI1CnBj aTEwOiBwaHlzaWNhbCBidXM9MTAKZm91bmQtPgl2ZW5kb3I9MHgxNGU0LCBkZXY9MHgxNjQ4LCBy ZXZpZD0weDEwCglidXM9MTAsIHNsb3Q9OSwgZnVuYz0wCgljbGFzcz0wMi0wMC0wMCwgaGRydHlw ZT0weDAwLCBtZmRldj0xCgljbWRyZWc9MHgwMTE2LCBzdGF0cmVnPTB4MDJiMCwgY2FjaGVsbnN6 PTE2IChkd29yZHMpCglsYXR0aW1lcj0weDQwICgxOTIwIG5zKSwgbWluZ250PTB4NDAgKDE2MDAw IG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YSwgaXJxPTEwCglwb3dlcnNwZWMgMiAg c3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCU1TSSBzdXBwb3J0cyA4IG1lc3NhZ2VzLCA2NCBi aXQKCW1hcFsxMF06IHR5cGUgMSwgcmFuZ2UgNjQsIGJhc2UgZGUxMDAwMDAsIHNpemUgMTYsIGVu YWJsZWQKcGNpYjU6IG1lbW9yeTogZW5kIChkZTFmZmZmZikgPCBzdGFydCAoNDlkYmRmMmRlMTAw MDAwKQpwY2liNTogKG51bGwpIHJlcXVlc3RlZCB1bnN1cHBvcnRlZCBtZW1vcnkgcmFuZ2UgMHgw LTB4MCAoZGVjb2RpbmcgMHhkZTEwMDAwMC0weGRlMWZmZmZmLCAweGZmZjAwMDAwLTB4ZmZmZmYp CnBjaWI1OiBtYXRjaGVkIGVudHJ5IGZvciAxMC45LklOVEEKcGNpYjU6IHNsb3QgOSBJTlRBIGhh cmR3aXJlZCB0byBJUlEgMjgKZm91bmQtPgl2ZW5kb3I9MHgxNGU0LCBkZXY9MHgxNjQ4LCByZXZp ZD0weDEwCglidXM9MTAsIHNsb3Q9OSwgZnVuYz0xCgljbGFzcz0wMi0wMC0wMCwgaGRydHlwZT0w eDAwLCBtZmRldj0xCgljbWRyZWc9MHgwMTE2LCBzdGF0cmVnPTB4MDJiMCwgY2FjaGVsbnN6PTE2 IChkd29yZHMpCglsYXR0aW1lcj0weDQwICgxOTIwIG5zKSwgbWluZ250PTB4NDAgKDE2MDAwIG5z KSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YiwgaXJxPTExCglwb3dlcnNwZWMgMiAgc3Vw cG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCU1TSSBzdXBwb3J0cyA4IG1lc3NhZ2VzLCA2NCBiaXQK CW1hcFsxMF06IHR5cGUgMSwgcmFuZ2UgNjQsIGJhc2UgZGUxMTAwMDAsIHNpemUgMTYsIGVuYWJs ZWQKcGNpYjU6IG1lbW9yeTogZW5kIChkZTFmZmZmZikgPCBzdGFydCAoZGJmYTcyZmRkZTExMDAw MCkKcGNpYjU6IChudWxsKSByZXF1ZXN0ZWQgdW5zdXBwb3J0ZWQgbWVtb3J5IHJhbmdlIDB4MC0w eDAgKGRlY29kaW5nIDB4ZGUxMDAwMDAtMHhkZTFmZmZmZiwgMHhmZmYwMDAwMC0weGZmZmZmKQpw Y2liNTogbWF0Y2hlZCBlbnRyeSBmb3IgMTAuOS5JTlRCCnBjaWI1OiBzbG90IDkgSU5UQiBoYXJk d2lyZWQgdG8gSVJRIDI5CmJnZTA6IDxCcm9hZGNvbSBCQ001NzA0IEIwLCBBU0lDIHJldi4gMHgy MTAwPiBtZW0gMHg0OWRiZGYyZGUxMDAwMDAtMHg0OWRiZGYyZGUxMGZmZmYgaXJxIDI4IGF0IGRl dmljZSA5LjAgb24gcGNpMTAKcGNpYjU6IG1lbW9yeTogZW5kIChkZTFmZmZmZikgPCBzdGFydCAo NDlkYmRmMmRlMTAwMDAwKQpwY2liNTogYmdlMCByZXF1ZXN0ZWQgdW5zdXBwb3J0ZWQgbWVtb3J5 IHJhbmdlIDB4MC0weDAgKGRlY29kaW5nIDB4ZGUxMDAwMDAtMHhkZTFmZmZmZiwgMHhmZmYwMDAw MC0weGZmZmZmKQpiZ2UwOiBjb3VsZG4ndCBtYXAgbWVtb3J5CmRldmljZV9hdHRhY2g6IGJnZTAg YXR0YWNoIHJldHVybmVkIDYKYmdlMTogPEJyb2FkY29tIEJDTTU3MDQgQjAsIEFTSUMgcmV2LiAw eDIxMDA+IG1lbSAweGRiZmE3MmZkZGUxMTAwMDAtMHhkYmZhNzJmZGRlMTFmZmZmIGlycSAyOSBh dCBkZXZpY2UgOS4xIG9uIHBjaTEwCnBjaWI1OiBtZW1vcnk6IGVuZCAoZGUxZmZmZmYpIDwgc3Rh cnQgKGRiZmE3MmZkZGUxMTAwMDApCnBjaWI1OiBiZ2UxIHJlcXVlc3RlZCB1bnN1cHBvcnRlZCBt ZW1vcnkgcmFuZ2UgMHgwLTB4MCAoZGVjb2RpbmcgMHhkZTEwMDAwMC0weGRlMWZmZmZmLCAweGZm ZjAwMDAwLTB4ZmZmZmYpCmJnZTE6IGNvdWxkbid0IG1hcCBtZW1vcnkKZGV2aWNlX2F0dGFjaDog YmdlMSBhdHRhY2ggcmV0dXJuZWQgNgpwY2k4OiA8YmFzZSBwZXJpcGhlcmFsLCBpbnRlcnJ1cHQg Y29udHJvbGxlcj4gYXQgZGV2aWNlIDExLjEgKG5vIGRyaXZlciBhdHRhY2hlZCkKcHNtY3BucDA6 IDxQUy8yIG1vdXNlIHBvcnQ+IGlycSAxMiBvbiBhY3BpMAphdGtiZGMwOiA8S2V5Ym9hcmQgY29u dHJvbGxlciAoaTgwNDIpPiBwb3J0IDB4NjAsMHg2NCBpcnEgMSBvbiBhY3BpMAphdGtiZDA6IDxB VCBLZXlib2FyZD4gaXJxIDEgb24gYXRrYmRjMAphdGtiZDogdGhlIGN1cnJlbnQga2JkIGNvbnRy b2xsZXIgY29tbWFuZCBieXRlIDAwNjcKYXRrYmQ6IGtleWJvYXJkIElEIDB4NDFhYiAoMikKa2Jk MCBhdCBhdGtiZDAKa2JkMDogYXRrYmQwLCBBVCAxMDEvMTAyICgyKSwgY29uZmlnOjB4MCwgZmxh Z3M6MHgzZDAwMDAKaW9hcGljMDogcm91dGluZyBpbnRwaW4gMSAoSVNBIElSUSAxKSB0byB2ZWN0 b3IgNTQKYXRrYmQwOiBbR0lBTlQtTE9DS0VEXQpwc20wOiBjdXJyZW50IGNvbW1hbmQgYnl0ZTow MDY3CnBzbTA6IGZhaWxlZCB0byByZXNldCB0aGUgYXV4IGRldmljZS4Kc2lvMDogaXJxIG1hcHM6 IDB4YzIxIDB4YzMxIDB4YzIxIDB4YzIxCnNpbzA6IDwxNjU1MEEtY29tcGF0aWJsZSBDT00gcG9y dD4gcG9ydCAweDNmOC0weDNmZiBpcnEgNCBmbGFncyAweDEwIG9uIGFjcGkwCnNpbzA6IHR5cGUg MTY1NTBBCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDQgKElTQSBJUlEgNCkgdG8gdmVjdG9yIDU1 CnNpbzE6IGlycSBtYXBzOiAweGMyMSAweGMyOSAweGMyMSAweGMyMQpzaW8xOiA8MTY1NTBBLWNv bXBhdGlibGUgQ09NIHBvcnQ+IHBvcnQgMHgyZjgtMHgyZmYgaXJxIDMgb24gYWNwaTAKc2lvMTog dHlwZSAxNjU1MEEKaW9hcGljMDogcm91dGluZyBpbnRwaW4gMyAoSVNBIElSUSAzKSB0byB2ZWN0 b3IgNTYKZmRjMDogPGZsb3BweSBkcml2ZSBjb250cm9sbGVyPiBwb3J0IDB4M2YwLTB4M2Y1LDB4 M2Y3IGlycSA2IGRycSAyIG9uIGFjcGkwCmZkYzA6IGljX3R5cGUgOTAgcGFydF9pZCA4MAppb2Fw aWMwOiByb3V0aW5nIGludHBpbiA2IChJU0EgSVJRIDYpIHRvIHZlY3RvciA1NwpmZGMwOiBbTVBT QUZFXQpmZGMwOiBbRkFTVF0KZmQwOiA8MTQ0MC1LQiAzLjUiIGRyaXZlPiBvbiBmZGMwIGRyaXZl IDAKcHBjMDogdXNpbmcgZXh0ZW5kZWQgSS9PIHBvcnQgcmFuZ2UKcHBjMDogRUNQIFNQUCBFQ1Ar RVBQIFNQUApwcGMwOiA8RUNQIHBhcmFsbGVsIHByaW50ZXIgcG9ydD4gcG9ydCAweDM3OC0weDM3 ZiwweDc3OC0weDc3ZiBpcnEgNyBkcnEgMyBvbiBhY3BpMApwcGMwOiBTTUMtbGlrZSBjaGlwc2V0 IChFQ1AvRVBQL1BTMi9OSUJCTEUpIGluIENPTVBBVElCTEUgbW9kZQpwcGMwOiBGSUZPIHdpdGgg MTYvMTYvOSBieXRlcyB0aHJlc2hvbGQKcHBidXMwOiA8UGFyYWxsZWwgcG9ydCBidXM+IG9uIHBw YzAKcGxpcDA6IDxQTElQIG5ldHdvcmsgaW50ZXJmYWNlPiBvbiBwcGJ1czAKcGxpcDA6IGJwZiBh dHRhY2hlZApscHQwOiA8UHJpbnRlcj4gb24gcHBidXMwCmxwdDA6IEludGVycnVwdC1kcml2ZW4g cG9ydApwcGkwOiA8UGFyYWxsZWwgSS9PPiBvbiBwcGJ1czAKaW9hcGljMDogcm91dGluZyBpbnRw aW4gNyAoSVNBIElSUSA3KSB0byB2ZWN0b3IgNTgKYWhjX2lzYV9wcm9iZSAwOiBpb3BvcnQgMHhj MDAgYWxsb2MgZmFpbGVkCmV4X2lzYV9pZGVudGlmeSgpCmF0a2JkYzogYXRrYmRjMCBhbHJlYWR5 IGV4aXN0czsgc2tpcHBpbmcgaXQKZmRjOiBmZGMwIGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBp dApwcGM6IHBwYzAgYWxyZWFkeSBleGlzdHM7IHNraXBwaW5nIGl0CnNpbzogc2lvMCBhbHJlYWR5 IGV4aXN0czsgc2tpcHBpbmcgaXQKc2lvOiBzaW8xIGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBp dApwbnBfaWRlbnRpZnk6IFRyeWluZyBSZWFkX1BvcnQgYXQgMjAzCnBucF9pZGVudGlmeTogVHJ5 aW5nIFJlYWRfUG9ydCBhdCAyNDMKcG5wX2lkZW50aWZ5OiBUcnlpbmcgUmVhZF9Qb3J0IGF0IDI4 MwpwbnBfaWRlbnRpZnk6IFRyeWluZyBSZWFkX1BvcnQgYXQgMmMzCnBucF9pZGVudGlmeTogVHJ5 aW5nIFJlYWRfUG9ydCBhdCAzMDMKcG5wX2lkZW50aWZ5OiBUcnlpbmcgUmVhZF9Qb3J0IGF0IDM0 MwpwbnBfaWRlbnRpZnk6IFRyeWluZyBSZWFkX1BvcnQgYXQgMzgzCnBucF9pZGVudGlmeTogVHJ5 aW5nIFJlYWRfUG9ydCBhdCAzYzMKUE5QIElkZW50aWZ5IGNvbXBsZXRlCnNjOiBzYzAgYWxyZWFk eSBleGlzdHM7IHNraXBwaW5nIGl0CnZnYTogdmdhMCBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcg aXQKaXNhX3Byb2JlX2NoaWxkcmVuOiBkaXNhYmxpbmcgUG5QIGRldmljZXMKaXNhX3Byb2JlX2No aWxkcmVuOiBwcm9iaW5nIG5vbi1QblAgZGV2aWNlcwpvcm0wOiA8SVNBIE9wdGlvbiBST01zPiBh dCBpb21lbSAweGMwMDAwLTB4YzdmZmYsMHhjODAwMC0weGM5N2ZmLDB4Yzk4MDAtMHhjYWZmZiww eGNiMDAwLTB4Y2M3ZmYgb24gaXNhMApzYzA6IDxTeXN0ZW0gY29uc29sZT4gYXQgZmxhZ3MgMHgx MDAgb24gaXNhMApzYzA6IFZHQSA8MTYgdmlydHVhbCBjb25zb2xlcywgZmxhZ3M9MHgzMDA+CnNj MDogZmIwLCBrYmQxLCB0ZXJtaW5hbCBlbXVsYXRvcjogc2MgKHN5c2NvbnMgdGVybWluYWwpCnNp bzI6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQpzaW8zOiBub3QgcHJvYmVkIChkaXNhYmxlZCkKdmdh MDogPEdlbmVyaWMgSVNBIFZHQT4gYXQgcG9ydCAweDNjMC0weDNkZiBpb21lbSAweGEwMDAwLTB4 YmZmZmYgb24gaXNhMAppc2FfcHJvYmVfY2hpbGRyZW46IHByb2JpbmcgUG5QIGRldmljZXMKRGV2 aWNlIGNvbmZpZ3VyYXRpb24gZmluaXNoZWQuClJlZHVjaW5nIGtlcm4ubWF4dm5vZGVzIDIxMjE0 NCAtPiAxMDAwMDAKbGlucHJvY2ZzIHJlZ2lzdGVyZWQKcHJvY2ZzIHJlZ2lzdGVyZWQKbGFwaWM6 IERpdmlzb3IgMiwgRnJlcXVlbmN5IDEwMDQ2MzE2MSBoegpUaW1lY291bnRlciAiVFNDIiBmcmVx dWVuY3kgMjYxMjA1MDk3OCBIeiBxdWFsaXR5IC0xMDAKVGltZWNvdW50ZXJzIHRpY2sgZXZlcnkg MS4wMDAgbXNlYwpMaW51eCBFTEYgZXhlYyBoYW5kbGVyIGluc3RhbGxlZApsbzA6IGJwZiBhdHRh Y2hlZApycjIzMng6IG5vIGNvbnRyb2xsZXIgZGV0ZWN0ZWQuCmF0YTAtbWFzdGVyOiBwaW89UElP NCB3ZG1hPVdETUEyIHVkbWE9VURNQTY2IGNhYmxlPTQwIHdpcmUKYWNkMDogc2V0dGluZyBQSU80 IG9uIG5Gb3JjZSBDSzgwNCBjaGlwCmFjZDA6IERNQSBsaW1pdGVkIHRvIFVETUEzMywgZGV2aWNl IGZvdW5kIG5vbi1BVEE2NiBjYWJsZQphY2QwOiBzZXR0aW5nIFVETUEzMyBvbiBuRm9yY2UgQ0s4 MDQgY2hpcAphY2QwOiA8TElURS1PTiBEVkRSVyBMSC0yMEExUC9LTDAyPiBEVkRSIGRyaXZlIGF0 IGF0YTAgYXMgbWFzdGVyCmFjZDA6IHJlYWQgODI2OEtCL3MgKDgyNjhLQi9zKSB3cml0ZSA4MjY4 S0IvcyAoODI2OEtCL3MpLCAyMDQ4S0IgYnVmZmVyLCBVRE1BMzMKYWNkMDogUmVhZHM6IENEUiwg Q0RSVywgQ0REQSBzdHJlYW0sIERWRFJPTSwgRFZEUiwgRFZEUkFNLCBwYWNrZXQKYWNkMDogV3Jp dGVzOiBDRFIsIENEUlcsIERWRFIsIERWRFJBTSwgdGVzdCB3cml0ZSwgYnVybnByb29mCmFjZDA6 IEF1ZGlvOiBwbGF5LCAyNTYgdm9sdW1lIGxldmVscwphY2QwOiBNZWNoYW5pc206IGVqZWN0YWJs ZSB0cmF5LCB1bmxvY2tlZAphY2QwOiBNZWRpdW06IENELVIgMTIwbW0gcGhvdG8gZGlzYwoocHJv YmUxOnR3YTA6MDoxOjApOiBlcnJvciAyMgoocHJvYmUxOnR3YTA6MDoxOjApOiBVbnJldHJ5YWJs ZSBFcnJvcgoocHJvYmUyOnR3YTA6MDoyOjApOiBlcnJvciAyMgoocHJvYmUyOnR3YTA6MDoyOjAp OiBVbnJldHJ5YWJsZSBFcnJvcgoocHJvYmUzOnR3YTA6MDozOjApOiBlcnJvciAyMgoocHJvYmUz OnR3YTA6MDozOjApOiBVbnJldHJ5YWJsZSBFcnJvcgoocHJvYmU0OnR3YTA6MDo0OjApOiBlcnJv ciAyMgoocHJvYmU0OnR3YTA6MDo0OjApOiBVbnJldHJ5YWJsZSBFcnJvcgoocHJvYmU1OnR3YTA6 MDo1OjApOiBlcnJvciAyMgoocHJvYmU1OnR3YTA6MDo1OjApOiBVbnJldHJ5YWJsZSBFcnJvcgoo cHJvYmU2OnR3YTA6MDo2OjApOiBlcnJvciAyMgoocHJvYmU2OnR3YTA6MDo2OjApOiBVbnJldHJ5 YWJsZSBFcnJvcgoocHJvYmU3OnR3YTA6MDo3OjApOiBlcnJvciAyMgoocHJvYmU3OnR3YTA6MDo3 OjApOiBVbnJldHJ5YWJsZSBFcnJvcgoocHJvYmU4OnR3YTA6MDo4OjApOiBlcnJvciAyMgoocHJv YmU4OnR3YTA6MDo4OjApOiBVbnJldHJ5YWJsZSBFcnJvcgoocHJvYmU5OnR3YTA6MDo5OjApOiBl cnJvciAyMgoocHJvYmU5OnR3YTA6MDo5OjApOiBVbnJldHJ5YWJsZSBFcnJvcgoocHJvYmUxMDp0 d2EwOjA6MTA6MCk6IGVycm9yIDIyCihwcm9iZTEwOnR3YTA6MDoxMDowKTogVW5yZXRyeWFibGUg RXJyb3IKKHByb2JlMTE6dHdhMDowOjExOjApOiBlcnJvciAyMgoocHJvYmUxMTp0d2EwOjA6MTE6 MCk6IFVucmV0cnlhYmxlIEVycm9yCihwcm9iZTEyOnR3YTA6MDoxMjowKTogZXJyb3IgMjIKKHBy b2JlMTI6dHdhMDowOjEyOjApOiBVbnJldHJ5YWJsZSBFcnJvcgoocHJvYmUxMzp0d2EwOjA6MTM6 MCk6IGVycm9yIDIyCihwcm9iZTEzOnR3YTA6MDoxMzowKTogVW5yZXRyeWFibGUgRXJyb3IKKHBy b2JlMTQ6dHdhMDowOjE0OjApOiBlcnJvciAyMgoocHJvYmUxNDp0d2EwOjA6MTQ6MCk6IFVucmV0 cnlhYmxlIEVycm9yCihwcm9iZTE1OnR3YTA6MDoxNTowKTogZXJyb3IgMjIKKHByb2JlMTU6dHdh MDowOjE1OjApOiBVbnJldHJ5YWJsZSBFcnJvcgoocHJvYmUxNjp0d2EwOjA6MTY6MCk6IGVycm9y IDIyCihwcm9iZTE2OnR3YTA6MDoxNjowKTogVW5yZXRyeWFibGUgRXJyb3IKKHByb2JlMTc6dHdh MDowOjE3OjApOiBlcnJvciAyMgoocHJvYmUxNzp0d2EwOjA6MTc6MCk6IFVucmV0cnlhYmxlIEVy cm9yCihwcm9iZTE4OnR3YTA6MDoxODowKTogZXJyb3IgMjIKKHByb2JlMTg6dHdhMDowOjE4OjAp OiBVbnJldHJ5YWJsZSBFcnJvcgoocHJvYmUxOTp0d2EwOjA6MTk6MCk6IGVycm9yIDIyCihwcm9i ZTE5OnR3YTA6MDoxOTowKTogVW5yZXRyeWFibGUgRXJyb3IKKHByb2JlMjA6dHdhMDowOjIwOjAp OiBlcnJvciAyMgoocHJvYmUyMDp0d2EwOjA6MjA6MCk6IFVucmV0cnlhYmxlIEVycm9yCihwcm9i ZTIxOnR3YTA6MDoyMTowKTogZXJyb3IgMjIKKHByb2JlMjE6dHdhMDowOjIxOjApOiBVbnJldHJ5 YWJsZSBFcnJvcgoocHJvYmUyMjp0d2EwOjA6MjI6MCk6IGVycm9yIDIyCihwcm9iZTIyOnR3YTA6 MDoyMjowKTogVW5yZXRyeWFibGUgRXJyb3IKKHByb2JlMjM6dHdhMDowOjIzOjApOiBlcnJvciAy MgoocHJvYmUyMzp0d2EwOjA6MjM6MCk6IFVucmV0cnlhYmxlIEVycm9yCihwcm9iZTI0OnR3YTA6 MDoyNDowKTogZXJyb3IgMjIKKHByb2JlMjQ6dHdhMDowOjI0OjApOiBVbnJldHJ5YWJsZSBFcnJv cgoocHJvYmUyNTp0d2EwOjA6MjU6MCk6IGVycm9yIDIyCihwcm9iZTI1OnR3YTA6MDoyNTowKTog VW5yZXRyeWFibGUgRXJyb3IKKHByb2JlMjY6dHdhMDowOjI2OjApOiBlcnJvciAyMgoocHJvYmUy Njp0d2EwOjA6MjY6MCk6IFVucmV0cnlhYmxlIEVycm9yCihwcm9iZTI3OnR3YTA6MDoyNzowKTog ZXJyb3IgMjIKKHByb2JlMjc6dHdhMDowOjI3OjApOiBVbnJldHJ5YWJsZSBFcnJvcgoocHJvYmUy ODp0d2EwOjA6Mjg6MCk6IGVycm9yIDIyCihwcm9iZTI4OnR3YTA6MDoyODowKTogVW5yZXRyeWFi bGUgRXJyb3IKKHByb2JlMjk6dHdhMDowOjI5OjApOiBlcnJvciAyMgoocHJvYmUyOTp0d2EwOjA6 Mjk6MCk6IFVucmV0cnlhYmxlIEVycm9yCihwcm9iZTMwOnR3YTA6MDozMDowKTogZXJyb3IgMjIK KHByb2JlMzA6dHdhMDowOjMwOjApOiBVbnJldHJ5YWJsZSBFcnJvcgoocHJvYmUzMTp0d2EwOjA6 MzE6MCk6IGVycm9yIDIyCihwcm9iZTMxOnR3YTA6MDozMTowKTogVW5yZXRyeWFibGUgRXJyb3IK KHByb2JlMTp0d2EwOjA6MTowKTogZXJyb3IgMjIKKHByb2JlMTp0d2EwOjA6MTowKTogVW5yZXRy eWFibGUgRXJyb3IKKHByb2JlMjp0d2EwOjA6MjowKTogZXJyb3IgMjIKKHByb2JlMjp0d2EwOjA6 MjowKTogVW5yZXRyeWFibGUgRXJyb3IKKHByb2JlMzp0d2EwOjA6MzowKTogZXJyb3IgMjIKKHBy b2JlMzp0d2EwOjA6MzowKTogVW5yZXRyeWFibGUgRXJyb3IKKHByb2JlNDp0d2EwOjA6NDowKTog ZXJyb3IgMjIKKHByb2JlNDp0d2EwOjA6NDowKTogVW5yZXRyeWFibGUgRXJyb3IKKHByb2JlNTp0 d2EwOjA6NTowKTogZXJyb3IgMjIKKHByb2JlNTp0d2EwOjA6NTowKTogVW5yZXRyeWFibGUgRXJy b3IKKHByb2JlNjp0d2EwOjA6NjowKTogZXJyb3IgMjIKKHByb2JlNjp0d2EwOjA6NjowKTogVW5y ZXRyeWFibGUgRXJyb3IKKHByb2JlNzp0d2EwOjA6NzowKTogZXJyb3IgMjIKKHByb2JlNzp0d2Ew OjA6NzowKTogVW5yZXRyeWFibGUgRXJyb3IKKHByb2JlODp0d2EwOjA6ODowKTogZXJyb3IgMjIK KHByb2JlODp0d2EwOjA6ODowKTogVW5yZXRyeWFibGUgRXJyb3IKKHByb2JlOTp0d2EwOjA6OTow KTogZXJyb3IgMjIKKHByb2JlOTp0d2EwOjA6OTowKTogVW5yZXRyeWFibGUgRXJyb3IKKHByb2Jl MTA6dHdhMDowOjEwOjApOiBlcnJvciAyMgoocHJvYmUxMDp0d2EwOjA6MTA6MCk6IFVucmV0cnlh YmxlIEVycm9yCihwcm9iZTExOnR3YTA6MDoxMTowKTogZXJyb3IgMjIKKHByb2JlMTE6dHdhMDow OjExOjApOiBVbnJldHJ5YWJsZSBFcnJvcgoocHJvYmUxMjp0d2EwOjA6MTI6MCk6IGVycm9yIDIy Cihwcm9iZTEyOnR3YTA6MDoxMjowKTogVW5yZXRyeWFibGUgRXJyb3IKKHByb2JlMTM6dHdhMDow OjEzOjApOiBlcnJvciAyMgoocHJvYmUxMzp0d2EwOjA6MTM6MCk6IFVucmV0cnlhYmxlIEVycm9y Cihwcm9iZTE0OnR3YTA6MDoxNDowKTogZXJyb3IgMjIKKHByb2JlMTQ6dHdhMDowOjE0OjApOiBV bnJldHJ5YWJsZSBFcnJvcgoocHJvYmUxNTp0d2EwOjA6MTU6MCk6IGVycm9yIDIyCihwcm9iZTE1 OnR3YTA6MDoxNTowKTogVW5yZXRyeWFibGUgRXJyb3IKKHByb2JlMTY6dHdhMDowOjE2OjApOiBl cnJvciAyMgoocHJvYmUxNjp0d2EwOjA6MTY6MCk6IFVucmV0cnlhYmxlIEVycm9yCihwcm9iZTE3 OnR3YTA6MDoxNzowKTogZXJyb3IgMjIKKHByb2JlMTc6dHdhMDowOjE3OjApOiBVbnJldHJ5YWJs ZSBFcnJvcgoocHJvYmUxODp0d2EwOjA6MTg6MCk6IGVycm9yIDIyCihwcm9iZTE4OnR3YTA6MDox ODowKTogVW5yZXRyeWFibGUgRXJyb3IKKHByb2JlMTk6dHdhMDowOjE5OjApOiBlcnJvciAyMgoo cHJvYmUxOTp0d2EwOjA6MTk6MCk6IFVucmV0cnlhYmxlIEVycm9yCihwcm9iZTIwOnR3YTA6MDoy MDowKTogZXJyb3IgMjIKKHByb2JlMjA6dHdhMDowOjIwOjApOiBVbnJldHJ5YWJsZSBFcnJvcgoo cHJvYmUyMTp0d2EwOjA6MjE6MCk6IGVycm9yIDIyCihwcm9iZTIxOnR3YTA6MDoyMTowKTogVW5y ZXRyeWFibGUgRXJyb3IKKHByb2JlMjI6dHdhMDowOjIyOjApOiBlcnJvciAyMgoocHJvYmUyMjp0 d2EwOjA6MjI6MCk6IFVucmV0cnlhYmxlIEVycm9yCihwcm9iZTIzOnR3YTA6MDoyMzowKTogZXJy b3IgMjIKKHByb2JlMjM6dHdhMDowOjIzOjApOiBVbnJldHJ5YWJsZSBFcnJvcgoocHJvYmUyNDp0 d2EwOjA6MjQ6MCk6IGVycm9yIDIyCihwcm9iZTI0OnR3YTA6MDoyNDowKTogVW5yZXRyeWFibGUg RXJyb3IKKHByb2JlMjU6dHdhMDowOjI1OjApOiBlcnJvciAyMgoocHJvYmUyNTp0d2EwOjA6MjU6 MCk6IFVucmV0cnlhYmxlIEVycm9yCihwcm9iZTI2OnR3YTA6MDoyNjowKTogZXJyb3IgMjIKKHBy b2JlMjY6dHdhMDowOjI2OjApOiBVbnJldHJ5YWJsZSBFcnJvcgoocHJvYmUyNzp0d2EwOjA6Mjc6 MCk6IGVycm9yIDIyCihwcm9iZTI3OnR3YTA6MDoyNzowKTogVW5yZXRyeWFibGUgRXJyb3IKKHBy b2JlMjg6dHdhMDowOjI4OjApOiBlcnJvciAyMgoocHJvYmUyODp0d2EwOjA6Mjg6MCk6IFVucmV0 cnlhYmxlIEVycm9yCihwcm9iZTI5OnR3YTA6MDoyOTowKTogZXJyb3IgMjIKKHByb2JlMjk6dHdh MDowOjI5OjApOiBVbnJldHJ5YWJsZSBFcnJvcgoocHJvYmUzMDp0d2EwOjA6MzA6MCk6IGVycm9y IDIyCihwcm9iZTMwOnR3YTA6MDozMDowKTogVW5yZXRyeWFibGUgRXJyb3IKKHByb2JlMzE6dHdh MDowOjMxOjApOiBlcnJvciAyMgoocHJvYmUzMTp0d2EwOjA6MzE6MCk6IFVucmV0cnlhYmxlIEVy cm9yCihwcm9iZTA6dHdhMDowOjA6MCk6IGVycm9yIDIyCihwcm9iZTA6dHdhMDowOjA6MCk6IFVu cmV0cnlhYmxlIEVycm9yCihwcm9iZTE6dHdhMDowOjA6MSk6IGVycm9yIDIyCihwcm9iZTE6dHdh MDowOjA6MSk6IFVucmV0cnlhYmxlIEVycm9yCihwcm9iZTA6dHdhMDowOjA6MCk6IGVycm9yIDIy Cihwcm9iZTA6dHdhMDowOjA6MCk6IFVucmV0cnlhYmxlIEVycm9yCihwcm9iZTA6dHdhMDowOjA6 Mik6IGVycm9yIDIyCihwcm9iZTA6dHdhMDowOjA6Mik6IFVucmV0cnlhYmxlIEVycm9yCihwcm9i ZTA6dHdhMDowOjA6Myk6IGVycm9yIDIyCihwcm9iZTA6dHdhMDowOjA6Myk6IFVucmV0cnlhYmxl IEVycm9yCihwcm9iZTE6dHdhMDowOjA6MSk6IGVycm9yIDIyCihwcm9iZTE6dHdhMDowOjA6MSk6 IFVucmV0cnlhYmxlIEVycm9yCihwcm9iZTA6dHdhMDowOjA6NCk6IGVycm9yIDIyCihwcm9iZTA6 dHdhMDowOjA6NCk6IFVucmV0cnlhYmxlIEVycm9yCihwcm9iZTA6dHdhMDowOjA6NSk6IGVycm9y IDIyCihwcm9iZTA6dHdhMDowOjA6NSk6IFVucmV0cnlhYmxlIEVycm9yCihwcm9iZTE6dHdhMDow OjA6Mik6IGVycm9yIDIyCihwcm9iZTE6dHdhMDowOjA6Mik6IFVucmV0cnlhYmxlIEVycm9yCihw cm9iZTA6dHdhMDowOjA6Nik6IGVycm9yIDIyCihwcm9iZTA6dHdhMDowOjA6Nik6IFVucmV0cnlh YmxlIEVycm9yCihwcm9iZTE6dHdhMDowOjA6Myk6IGVycm9yIDIyCihwcm9iZTE6dHdhMDowOjA6 Myk6IFVucmV0cnlhYmxlIEVycm9yCihwcm9iZTA6dHdhMDowOjA6Nyk6IGVycm9yIDIyCihwcm9i ZTA6dHdhMDowOjA6Nyk6IFVucmV0cnlhYmxlIEVycm9yCihwcm9iZTE6dHdhMDowOjA6NCk6IGVy cm9yIDIyCihwcm9iZTE6dHdhMDowOjA6NCk6IFVucmV0cnlhYmxlIEVycm9yCihwcm9iZTA6dHdh MDowOjA6NSk6IGVycm9yIDIyCihwcm9iZTA6dHdhMDowOjA6NSk6IFVucmV0cnlhYmxlIEVycm9y Cihwcm9iZTA6dHdhMDowOjA6Nik6IGVycm9yIDIyCihwcm9iZTA6dHdhMDowOjA6Nik6IFVucmV0 cnlhYmxlIEVycm9yCihwcm9iZTA6dHdhMDowOjA6Nyk6IGVycm9yIDIyCihwcm9iZTA6dHdhMDow OjA6Nyk6IFVucmV0cnlhYmxlIEVycm9yCnBhc3MwIGF0IHR3YTAgYnVzIDAgdGFyZ2V0IDAgbHVu IDAKcGFzczA6IDxBTUNDIDk2NTBTRS0xNk0gRElTSyAzLjA2PiBGaXhlZCBEaXJlY3QgQWNjZXNz IFNDU0ktNSBkZXZpY2UgCnBhc3MwOiBTZXJpYWwgTnVtYmVyIDNRRDBTUjFHOENBNzQ2MDAxMjZG CnBhc3MwOiAxMDAuMDAwTUIvcyB0cmFuc2ZlcnMKcGFzczEgYXQgdHdhMCBidXMgMCB0YXJnZXQg MCBsdW4gMQpwYXNzMTogPEFNQ0MgOTY1MFNFLTE2TSBESVNLIDMuMDY+IEZpeGVkIERpcmVjdCBB Y2Nlc3MgU0NTSS01IGRldmljZSAKcGFzczE6IFNlcmlhbCBOdW1iZXIgM1FEMFNSMUc4Q0E3NDYw MDEyNkYKcGFzczE6IDEwMC4wMDBNQi9zIHRyYW5zZmVycwpkYTAgYXQgdHdhMCBidXMgMCB0YXJn ZXQgMCBsdW4gMApkYTA6IDxBTUNDIDk2NTBTRS0xNk0gRElTSyAzLjA2PiBGaXhlZCBEaXJlY3Qg QWNjZXNzIFNDU0ktNSBkZXZpY2UgCmRhMDogU2VyaWFsIE51bWJlciAzUUQwU1IxRzhDQTc0NjAw MTI2RgpkYTA6IDEwMC4wMDBNQi9zIHRyYW5zZmVycwpkYTA6IDEzMTA3MU1CICgyNjg0MzU0NTUg NTEyIGJ5dGUgc2VjdG9yczogMjU1SCA2M1MvVCAxNjcwOUMpCkdFT006IG5ldyBkaXNrZGExIGF0 IHR3YTAgYnVzIDAgdGFyZ2V0IDAgbHVuIDEKZGExOiA8QU1DQyA5NjUwU0UtMTZNIERJU0sgMy4w Nj4gRml4ZWQgRGlyZWN0IEFjY2VzcyBTQ1NJLTUgZGV2aWNlIApkYTE6IFNlcmlhbCBOdW1iZXIg M1FEMFNSMUc4Q0E3NDYwMDEyNkYKZGExOiAxMDAuMDAwTUIvcyB0cmFuc2ZlcnMKZGExOiA5ODgy MzU4TUIgKDIwMjM5MDY5MTg1IDUxMiBieXRlIHNlY3RvcnM6IDI1NUggNjNTL1QgMTI1OTgyM0Mp CiBkYTAKR0VPTTogbmV3IGRpc2sgZGExCkFUQSBQc2V1ZG9SQUlEIGxvYWRlZApTTVA6IEFQIENQ VSAjMSBMYXVuY2hlZCEKY3B1MSBBUDoKICAgICBJRDogMHgwMTAwMDAwMCAgIFZFUjogMHgwMDA0 MDAxMCBMRFI6IDB4MDAwMDAwMDAgREZSOiAweGZmZmZmZmZmCiAgbGludDA6IDB4MDAwMTA3MDAg bGludDE6IDB4MDAwMDA0MDAgVFBSOiAweDAwMDAwMDAwIFNWUjogMHgwMDAwMDFmZgogIHRpbWVy OiAweDAwMDIwMGVmIHRoZXJtOiAweDAwMDAwMDAwIGVycjogMHgwMDAxMDAwMCBwY206IDB4MDAw MTAwMDAKU01QOiBBUCBDUFUgIzMgTGF1bmNoZWQhCmNwdTMgQVA6CiAgICAgSUQ6IDB4MDMwMDAw MDAgICBWRVI6IDB4MDAwNDAwMTAgTERSOiAweDAwMDAwMDAwIERGUjogMHhmZmZmZmZmZgogIGxp bnQwOiAweDAwMDEwNzAwIGxpbnQxOiAweDAwMDAwNDAwIFRQUjogMHgwMDAwMDAwMCBTVlI6IDB4 MDAwMDAxZmYKICB0aW1lcjogMHgwMDAyMDBlZiB0aGVybTogMHgwMDAwMDAwMCBlcnI6IDB4MDAw MTAwMDAgcGNtOiAweDAwMDEwMDAwClNNUDogQVAgQ1BVICMyIExhdW5jaGVkIQpjcHUyIEFQOgog ICAgIElEOiAweDAyMDAwMDAwICAgVkVSOiAweDAwMDQwMDEwIExEUjogMHgwMDAwMDAwMCBERlI6 IDB4ZmZmZmZmZmYKICBsaW50MDogMHgwMDAxMDcwMCBsaW50MTogMHgwMDAwMDQwMCBUUFI6IDB4 MDAwMDAwMDAgU1ZSOiAweDAwMDAwMWZmCiAgdGltZXI6IDB4MDAwMjAwZWYgdGhlcm06IDB4MDAw MDAwMDAgZXJyOiAweDAwMDEwMDAwIHBjbTogMHgwMDAxMDAwMApJTlRSOiBBc3NpZ25pbmcgSVJR IDEgdG8gbG9jYWwgQVBJQyAwCmlvYXBpYzA6IEFzc2lnbmluZyBJU0EgSVJRIDEgdG8gbG9jYWwg QVBJQyAwCklOVFI6IEFzc2lnbmluZyBJUlEgMyB0byBsb2NhbCBBUElDIDEKaW9hcGljMDogQXNz aWduaW5nIElTQSBJUlEgMyB0byBsb2NhbCBBUElDIDEKSU5UUjogQXNzaWduaW5nIElSUSA0IHRv IGxvY2FsIEFQSUMgMgppb2FwaWMwOiBBc3NpZ25pbmcgSVNBIElSUSA0IHRvIGxvY2FsIEFQSUMg MgpJTlRSOiBBc3NpZ25pbmcgSVJRIDYgdG8gbG9jYWwgQVBJQyAzCmlvYXBpYzA6IEFzc2lnbmlu ZyBJU0EgSVJRIDYgdG8gbG9jYWwgQVBJQyAzCklOVFI6IEFzc2lnbmluZyBJUlEgNyB0byBsb2Nh bCBBUElDIDAKaW9hcGljMDogQXNzaWduaW5nIElTQSBJUlEgNyB0byBsb2NhbCBBUElDIDAKSU5U UjogQXNzaWduaW5nIElSUSA5IHRvIGxvY2FsIEFQSUMgMQppb2FwaWMwOiBBc3NpZ25pbmcgSVNB IElSUSA5IHRvIGxvY2FsIEFQSUMgMQpJTlRSOiBBc3NpZ25pbmcgSVJRIDE0IHRvIGxvY2FsIEFQ SUMgMgppb2FwaWMwOiBBc3NpZ25pbmcgSVNBIElSUSAxNCB0byBsb2NhbCBBUElDIDIKSU5UUjog QXNzaWduaW5nIElSUSAxNSB0byBsb2NhbCBBUElDIDMKaW9hcGljMDogQXNzaWduaW5nIElTQSBJ UlEgMTUgdG8gbG9jYWwgQVBJQyAzCklOVFI6IEFzc2lnbmluZyBJUlEgMTYgdG8gbG9jYWwgQVBJ QyAwCmlvYXBpYzA6IEFzc2lnbmluZyBQQ0kgSVJRIDE2IHRvIGxvY2FsIEFQSUMgMApJTlRSOiBB c3NpZ25pbmcgSVJRIDIwIHRvIGxvY2FsIEFQSUMgMQppb2FwaWMwOiBBc3NpZ25pbmcgUENJIElS USAyMCB0byBsb2NhbCBBUElDIDEKSU5UUjogQXNzaWduaW5nIElSUSAyMSB0byBsb2NhbCBBUElD IDIKaW9hcGljMDogQXNzaWduaW5nIFBDSSBJUlEgMjEgdG8gbG9jYWwgQVBJQyAyClRyeWluZyB0 byBtb3VudCByb290IGZyb20gdWZzOi9kZXYvZGEwczFhCnN0YXJ0X2luaXQ6IHRyeWluZyAvc2Jp bi9pbml0Cg== ------=_Part_60975_25352783.1184625338313 Content-Type: application/octet-stream; name="pciconf-r.out" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pciconf-r.out" X-Attachment-Id: f_f47j6cbl U2NyaXB0IHN0YXJ0ZWQgb24gTW9uIEp1bCAxNiAxMjoyODozMSAyMDA3CiMgcGNpY29uZiAtciBw Y2k4OjExOjAgMDoweDNmDQ0KNzQ1MDEwMjIgMDIzMDAxMTcgMDYwNDAwMTMgMDA4MTQwMDANCjAw MDAwMDAwIDAwMDAwMDAwIDQwMGEwYTA4IDIyMjAwMWYxIA0KZGUxMGRlMTAgMDAwMWZmZjEgMDAw MDAwMDAgMDAwMDAwMDANCjAwMDAwMDAwIDAwMDAwMGEwIDAwMDAwMDAwIDAwMDQwMGZmIA0KIyBw Y2ljb25mIC1yIHBjaTg6MTE6MCAwOjB4M2YICAgICAgICBtbUBtbQDENDQo3NDUxMTAyMiAwMjAw MDAwNiAwODAwMTAwMSAwMDAwMDAwMA0KZGUwMDEwMDQgMDAwMDAwMDAgMDAwMDAwMDAgMDAwMDAw MDAgDQowMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAwMCAyODkxMTBmMQ0KMDAwMDAwMDAgMDAwMDAw MDAgMDAwMDAwMDAgMDAwMDAwMDAgDQojIHBjaWNvbmYgLXIgcGNpODoxMToxIDA6MHgzZggICAgI CAgICAgICAgbW1AbW0AxG1tAMDoxMQgbW1AIG1tQG1tAOToxCBtbUBtbQDANDQoxNjQ4MTRlNCAw MmIwMDExNiAwMjAwMDAxMCAwMDgwNDAxMA0KZGUxMDAwMDQgMDQ5ZGJkZjIgMDAwMDAwMDAgMDAw MDAwMDAgDQowMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAwMCAxNjQ0MTRlNA0KMDAwMDAwMDAgMDAw MDAwNDAgMDAwMDAwMDAgMDA0MDAxMWMgDQojIGV4aXQNDQpleGl0DQoKU2NyaXB0IGRvbmUgb24g TW9uIEp1bCAxNiAxMjoyOTowMSAyMDA3Cg== ------=_Part_60975_25352783.1184625338313-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 16 22:36: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 94FE816A403 for ; Mon, 16 Jul 2007 22:36:45 +0000 (UTC) (envelope-from james.shank@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.250]) by mx1.freebsd.org (Postfix) with ESMTP id 50B5713C4B6 for ; Mon, 16 Jul 2007 22:36:45 +0000 (UTC) (envelope-from james.shank@gmail.com) Received: by an-out-0708.google.com with SMTP id c14so311574anc for ; Mon, 16 Jul 2007 15:36:44 -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=JjIWp23EQxG99N5X2/e0CrhRFq8yiJWgmv/+x3wmAX0CSZV0UCxCTVqxa4VOW4sRgBdIafjpKiDFI/hJHOI1WlIraP2zkHGb5PdMHEJRU83JDqOe5QzgcEu0tF6BHlb25QLqnY7UaFCfAbzNgGCUIxGRV9/SI3xWmIHkwfpLOTA= 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=T4frd7CIz/Er3jgSZOUj/DyxjnM0pRs3WkJyEdGXs6I5+EnETPIeO0hKxDgWqKrNEwcrPegI5a3zQ34Vy1FkPA+i0+k7koOyDALl7KXHcA4PfmWz+RH/ygPlQpsxNIq/wS8IgHMKxtdW6YeL0EgAj3oNBocctMOA91nZfz9JPQ4= Received: by 10.100.8.18 with SMTP id 18mr2572723anh.1184625404625; Mon, 16 Jul 2007 15:36:44 -0700 (PDT) Received: by 10.100.198.5 with HTTP; Mon, 16 Jul 2007 15:36:44 -0700 (PDT) Message-ID: Date: Mon, 16 Jul 2007 17:36:44 -0500 From: "James Shank" To: "John Baldwin" In-Reply-To: <200707160754.01330.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200707160754.01330.jhb@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: Problem with Broadcom 5704 B1 on amd64 6.2 release 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, 16 Jul 2007 22:36:45 -0000 Dear John, Thanks for the suggestion. I tried the 7.0 livefs snapshot and had the same results as with the 6.2 release; identical errors on both. Thanks, James On 7/16/07, John Baldwin wrote: > On Monday 16 July 2007 01:37:40 am James Shank wrote: > > Greetings, > > > > I've run into a problem with the onboard Broadcom 5704 NetXtreme nics > > on a Tyan S2891 Thunder K8SRE motherboard. > > > > Here is the relevant dmesg output to show the error: > > > > pcib5: at device 11.0 on pci8 > > pci10: on pcib5 > > pcib5: memory: end (de1fffff) < start (48739b2de100000) > > pcib5: memory: end (de1fffff) < start (dbca73fdde110000) > > bge0: mem > > 0x48739b2de100000-0x48739b2de10ffff irq 28 at device 9.0 on pci10 > > pcib5: memory: end (de1fffff) < start (48739b2de100000) > > bge0: couldn't map memory > > device_attach: bge0 attach returned 6 > > bge1: mem > > 0xdbca73fdde110000-0xdbca73fdde11ffff irq 29 at device 9.1 on pci10 > > pcib5: memory: end (de1fffff) < start (dbca73fdde110000) > > bge1: couldn't map memory > > device_attach: bge1 attach returned 6 > > > > It appears to me that the problem might be due to using a 32-bit int > > for end addresses where it looks like the start address uses 64-bit > > int. > > > > Any input on how to proceed would be greatly appreciated. > > > > I've also attached full dmesg output as well as pciconf -l -v output. > > > > Thanks! > > Can you try a 7.0 snapshot? It has different handling of 64-bit BARs. If 7 > works then we can look at backporting those changes to 6.x. > > -- > John Baldwin > From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 16 22:39: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 0746C16A401 for ; Mon, 16 Jul 2007 22:39:23 +0000 (UTC) (envelope-from james.shank@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.242]) by mx1.freebsd.org (Postfix) with ESMTP id B745613C4BD for ; Mon, 16 Jul 2007 22:39:22 +0000 (UTC) (envelope-from james.shank@gmail.com) Received: by an-out-0708.google.com with SMTP id c14so311725anc for ; Mon, 16 Jul 2007 15:39:21 -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=eJ3uNDsD0o4wo4FdyKc8rWu9jDdUkK/vXzyA+ZLAP2JNfY484YJj6l1zbMpCcK6aJ+nOJ04KTpZAM8mgKqZOfDKtEXqBl+O4yp3vZHGHXaG4Ht0aQqMY0SwGS7BAhnpzWtbrh9WhFd2dNw/f83qo9U9GfAGGO8imFgbjl3UEjsA= 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=WhPlxGcjngMkolWcGjj1btEGNdKObZkdiCbk37fioyEjvUt5D9XnFfe0AtyOS+T67s7Trv+3JEbgH5nlnPy4weJYKRbcSG7suqHf6HCPAZLOrF66Xz12/im3Im1PVmVpZKMs41B0ltOtNTRq8dCP6mrPHyYhXB6v+04NKJi9Xqg= Received: by 10.100.9.19 with SMTP id 19mr2571514ani.1184625561533; Mon, 16 Jul 2007 15:39:21 -0700 (PDT) Received: by 10.100.198.5 with HTTP; Mon, 16 Jul 2007 15:39:21 -0700 (PDT) Message-ID: Date: Mon, 16 Jul 2007 17:39:21 -0500 From: "James Shank" To: "Stefan Esser" , freebsd-hackers@freebsd.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <469B2DB9.3090202@FreeBSD.org> Cc: Subject: Re: Problem with Broadcom 5704 B1 on amd64 6.2 release 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, 16 Jul 2007 22:39:23 -0000 Stefan, Another thing that might be helpful: When I last looked at the motherboard, I remember seeing the chip identified as a BCM 5704 B1. The BGE driver seems to think it is a B0. I don't know if this is significant, but I thought the more information I gave, the more you and the other smart people on here would have to work with. Thanks again, JAmes On 7/16/07, James Shank wrote: > Dear Stefan, > > Thanks for your help. I've attached the information you requested. > In particular, here are the relevant sections of the dmesg output: > > pcib5: at device 11.0 on pci8 > pcib5: secondary bus 10 > pcib5: subordinate bus 10 > pcib5: I/O decode 0xf000-0xfff > pcib5: memory decode 0xde100000-0xde1fffff > pcib5: prefetched decode 0xfff00000-0xfffff > pci10: on pcib5 > pci10: physical bus=10 > found-> vendor=0x14e4, dev=0x1648, revid=0x10 > bus=10, slot=9, func=0 > class=02-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0116, statreg=0x02b0, cachelnsz=16 (dwords) > lattimer=0x40 (1920 ns), mingnt=0x40 (16000 ns), maxlat=0x00 (0 ns) > intpin=a, irq=10 > powerspec 2 supports D0 D3 current D0 > MSI supports 8 messages, 64 bit > map[10]: type 1, range 64, base de100000, size 16, enabled > pcib5: memory: end (de1fffff) < start (49dbdf2de100000) > pcib5: (null) requested unsupported memory range 0x0-0x0 (decoding > 0xde100000-0xde1fffff, 0xfff00000-0xfffff) > pcib5: matched entry for 10.9.INTA > pcib5: slot 9 INTA hardwired to IRQ 28 > found-> vendor=0x14e4, dev=0x1648, revid=0x10 > bus=10, slot=9, func=1 > class=02-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0116, statreg=0x02b0, cachelnsz=16 (dwords) > lattimer=0x40 (1920 ns), mingnt=0x40 (16000 ns), maxlat=0x00 (0 ns) > intpin=b, irq=11 > powerspec 2 supports D0 D3 current D0 > MSI supports 8 messages, 64 bit > map[10]: type 1, range 64, base de110000, size 16, enabled > pcib5: memory: end (de1fffff) < start (dbfa72fdde110000) > pcib5: (null) requested unsupported memory range 0x0-0x0 (decoding > 0xde100000-0xde1fffff, 0xfff00000-0xfffff) > pcib5: matched entry for 10.9.INTB > pcib5: slot 9 INTB hardwired to IRQ 29 > bge0: mem > 0x49dbdf2de100000-0x49dbdf2de10ffff irq 28 at device 9.0 on pci10 > pcib5: memory: end (de1fffff) < start (49dbdf2de100000) > pcib5: bge0 requested unsupported memory range 0x0-0x0 (decoding > 0xde100000-0xde1fffff, 0xfff00000-0xfffff) > bge0: couldn't map memory > device_attach: bge0 attach returned 6 > bge1: mem > 0xdbfa72fdde110000-0xdbfa72fdde11ffff irq 29 at device 9.1 on pci10 > pcib5: memory: end (de1fffff) < start (dbfa72fdde110000) > pcib5: bge1 requested unsupported memory range 0x0-0x0 (decoding > 0xde100000-0xde1fffff, 0xfff00000-0xfffff) > bge1: couldn't map memory > device_attach: bge1 attach returned 6 > pci8: at device 11.1 (no > driver attached) > > > Any help you could provide would be greatly appreciated! > > Thanks again, > > James > > > On 7/16/07, Stefan Esser wrote: > > James Shank schrieb: > > > Greetings, > > > > > > I've run into a problem with the onboard Broadcom 5704 NetXtreme nics > > > on a Tyan S2891 Thunder K8SRE motherboard. > > > > > > Here is the relevant dmesg output to show the error: > > > > > > pcib5: at device 11.0 on pci8 > > > pci10: on pcib5 > > > pcib5: memory: end (de1fffff) < start (48739b2de100000) > > > pcib5: memory: end (de1fffff) < start (dbca73fdde110000) > > > bge0: mem > > > 0x48739b2de100000-0x48739b2de10ffff irq 28 at device 9.0 on pci10 > > > pcib5: memory: end (de1fffff) < start (48739b2de100000) > > > > Hi James, > > > > the information that you provided is not sufficient to diagnose > > this problem. You should post a *verbose* boot message log (via > > the boot loader menu or the loader command "boot -v"). > > > > Please do also provide a dump of the config registers of the > > PCI bridge for which the error condition is reported: > > > > # pciconf -r pci8:11:0 0:0x3f // device 11.0 on pci8 > > > > Not sure that I'll have time to look into this right today, but > > others on the list will want the same information so you may > > want to post it there ... > > > > This looks like a problem with the PCI bridge code, not the > > device init code, actually. But just in case it is not, you > > could also provide a register dump of the Ethernet chip: > > > > # pciconf -r pci10:9:0 0:0x3f > > > > Regards, STefan > > > > From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 16 23:21:42 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 C789016A401 for ; Mon, 16 Jul 2007 23:21:42 +0000 (UTC) (envelope-from mv@rulez.sk) Received: from mail.rulez.sk (DaEmoN.RuLeZ.sK [84.16.32.226]) by mx1.freebsd.org (Postfix) with ESMTP id 8AB7F13C4A3 for ; Mon, 16 Jul 2007 23:21:42 +0000 (UTC) (envelope-from mv@rulez.sk) Received: from localhost (localhost [127.0.0.1]) by mail.rulez.sk (Postfix) with ESMTP id 2350F5C37; Tue, 17 Jul 2007 01:04:22 +0200 (CEST) X-Virus-Scanned: by amavisd-new at mail.rulez.sk Received: by mail.rulez.sk (Postfix, from userid 1020) id 281755C36; Tue, 17 Jul 2007 01:04:19 +0200 (CEST) Date: Tue, 17 Jul 2007 01:04:19 +0200 From: Milos Vyletel To: youshi10@u.washington.edu Message-ID: <20070716230419.GA95219@rulez.sk> References: <20070716132326.GA28016@rulez.sk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Cc: hackers@freebsd.org Subject: Re: Large amounts of memory access operations cause panic under CURRENT (was "Large gap between fwrite and write, and fread and read") 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, 16 Jul 2007 23:21:42 -0000 > Go figure it'd cause panics for other people. > > I wasn't using zfs at all but it panicked anyhow once (my amd64 VM only, > not my i386 test server, surprisingly). I wish I'd gotten the panic but I > walked away to get a glass of water, and there wasn't a core dump because > the VM shut down completely instead of restarting. Heh. > > My virtual machine died around 90k on the first trial though. I'll be sure > to reduce the amount and see what happens, and I'll put nanosleeps or > usleeps between the read and write ops to see if that alleviates the race > condition seen, but I'll keep the problem code around for reference later > in case I've stimulated some sort of weird bug in FreeBSD, or otherwise. > > Both my VM and test server run almost no programs though other than samba > and rsync, so you'll probably see the panic faster / more frequently than I > will if you run a lot more programs resident in memory. > > Just curious, what scheduler are you using on CURRENT, what processor do > you have, and what are your memory specs? > > Thanks, > -Garrett > Hi Garrett, this is just my desktop where is running only Xorg, fluxbox, few aterms and firefox. But i can get the panic on console too, shortly after booting. I'm using SCHED_ULE. CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ (2205.01-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x20f32 Stepping = 2 Features=0x178bfbff Features2=0x1 AMD Features=0xe2500800 AMD Features2=0x3 Cores per package: 2 usable memory = 3211718656 (3062 MB) avail memory = 3105570816 (2961 MB) For the record, it crashes few times before it hit 100k iterations, before i put debug printf in your code and increase MAX_ITERATIONS to 1m. And as far as I can tell, I had pretty much the same results as you've measured. mv From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 17 00:18: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 EBFE716A404 for ; Tue, 17 Jul 2007 00:18:04 +0000 (UTC) (envelope-from wundram@beenic.net) Received: from mail.beenic.net (mail.beenic.net [83.246.72.40]) by mx1.freebsd.org (Postfix) with ESMTP id B12F513C48E for ; Tue, 17 Jul 2007 00:18:04 +0000 (UTC) (envelope-from wundram@beenic.net) Received: from phoenix (hnvr-4db2fdce.pool.einsundeins.de [77.178.253.206]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.beenic.net (Postfix) with ESMTP id 075BEA44529 for ; Tue, 17 Jul 2007 01:44:22 +0200 (CEST) From: "Heiko Wundram (Beenic)" Organization: Beenic Networks GmbH To: freebsd-hackers@freebsd.org Date: Tue, 17 Jul 2007 01:45:52 +0200 User-Agent: KMail/1.9.7 References: <469B5F61.1060805@u.washington.edu> In-Reply-To: <469B5F61.1060805@u.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200707170145.52781.wundram@beenic.net> Subject: Re: Large gap between fwrite and write, and fread and read 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, 17 Jul 2007 00:18:05 -0000 On Monday 16 July 2007 14:06:57 Garrett Cooper wrote: > I ran some tests and I noticed a large difference in the cumulative > sums of fwrite(2) vs write(3) and fread(2) vs read(3) (3-fold > differences on a real machine). This difference is at least partially explained when looking=20 at /usr/include/stdio.h, which defines the FILE structure: read/write on a= =20 file descriptor is (pretty much) a direct syscall with operating system=20 specific semantics on a wide range of behavior, such as buffering, flushing= =20 and seeking in read/write-opened files, whereas fread/fwrite on FILE*'s is= =20 an "abstraction" of file access for which the stdio-API defines semantics,= =20 such as buffering, the time flushing takes place and seeking in=20 read/write-opened files, across different flavors of POSIX-compatible libc'= s=20 equally. As the stdio-interface is a "wrapper" (with indirect calls calling the sysc= all=20 read at some point in time, see the FILE-structure definition), you'll have= =20 to expect a difference in runtime, too. (You mixed up f{read,write}(3) and {read,write}(2), just as a sidenote, whi= ch=20 is also indicative of the difference: man3 is indicative of a libc=20 implementation, whereas man2 generally contains syscall documentation) =2D-=20 Heiko Wundram Product & Application Development =2D------------------------------------ Office Germany - EXPO PARK HANNOVER =20 Beenic Networks GmbH Mail=E4nder Stra=DFe 2 30539 Hannover =20 =46on +49 511 / 590 935 - 15 =46ax +49 511 / 590 935 - 29 Mail wundram@beenic.net Beenic Networks GmbH =2D------------------------------------ Sitz der Gesellschaft: Hannover Gesch=E4ftsf=FChrer: Jorge Delgado Registernummer: HRB 61869 Registergericht: Amtsgericht Hannover From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 17 00:46:16 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 3C90216A401 for ; Tue, 17 Jul 2007 00:46:16 +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 1C71313C481 for ; Tue, 17 Jul 2007 00:46:16 +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.06) with ESMTP id l6H0k7oP003027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Jul 2007 17:46:08 -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 l6H0k7it011507; Mon, 16 Jul 2007 17:46:07 -0700 X-Auth-Received: from [192.55.52.3] by hymn01.u.washington.edu via HTTP; Mon, 16 Jul 2007 17:46:07 PDT Date: Mon, 16 Jul 2007 17:46:07 -0700 (PDT) From: youshi10@u.washington.edu To: "Heiko Wundram (Beenic)" In-Reply-To: <200707170145.52781.wundram@beenic.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.3.2.304607, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.7.16.172234 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: freebsd-hackers@freebsd.org Subject: Re: Large gap between fwrite and write, and fread and read 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, 17 Jul 2007 00:46:16 -0000 On Tue, 17 Jul 2007, Heiko Wundram (Beenic) wrote: > On Monday 16 July 2007 14:06:57 Garrett Cooper wrote: >> I ran some tests and I noticed a large difference in the cumulative >> sums of fwrite(2) vs write(3) and fread(2) vs read(3) (3-fold >> differences on a real machine). > > This difference is at least partially explained when looking > at /usr/include/stdio.h, which defines the FILE structure: read/write on a > file descriptor is (pretty much) a direct syscall with operating system > specific semantics on a wide range of behavior, such as buffering, flushing > and seeking in read/write-opened files, whereas fread/fwrite on FILE*'s is > an "abstraction" of file access for which the stdio-API defines semantics, > such as buffering, the time flushing takes place and seeking in > read/write-opened files, across different flavors of POSIX-compatible libc's > equally. > > As the stdio-interface is a "wrapper" (with indirect calls calling the syscall > read at some point in time, see the FILE-structure definition), you'll have > to expect a difference in runtime, too. > > (You mixed up f{read,write}(3) and {read,write}(2), just as a sidenote, which > is also indicative of the difference: man3 is indicative of a libc > implementation, whereas man2 generally contains syscall documentation) > > -- > Heiko Wundram Yeah, that's what I meant. I was rather tired when I made that post at 5:30 this morning. Heh. Thank you for the additional info though. That was brief, but comprehensive :). -Garrett From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 17 01:14: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 F047016A400 for ; Tue, 17 Jul 2007 01:14:12 +0000 (UTC) (envelope-from wundram@beenic.net) Received: from mail.beenic.net (mail.beenic.net [83.246.72.40]) by mx1.freebsd.org (Postfix) with ESMTP id B11B113C4B3 for ; Tue, 17 Jul 2007 01:14:12 +0000 (UTC) (envelope-from wundram@beenic.net) Received: from phoenix (hnvr-4db2fdce.pool.einsundeins.de [77.178.253.206]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.beenic.net (Postfix) with ESMTP id A5BFAA44529 for ; Tue, 17 Jul 2007 03:12:39 +0200 (CEST) From: "Heiko Wundram (Beenic)" Organization: Beenic Networks GmbH To: freebsd-hackers@freebsd.org Date: Tue, 17 Jul 2007 03:14:10 +0200 User-Agent: KMail/1.9.7 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200707170314.10188.wundram@beenic.net> Subject: Re: Large gap between fwrite and write, and fread and read 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, 17 Jul 2007 01:14:13 -0000 On Tuesday 17 July 2007 02:46:07 youshi10@u.washington.edu wrote: > Yeah, that's what I meant. I was rather tired when I made that post > at 5:30 this morning. Heh. Thank you for the additional info though. That > was brief, but comprehensive :). -Garrett =46or more comprehensive info, "check the (POSIX-)specs" (TM) ;-). =2D-=20 Heiko Wundram Product & Application Development =2D------------------------------------ Office Germany - EXPO PARK HANNOVER =20 Beenic Networks GmbH Mail=E4nder Stra=DFe 2 30539 Hannover =20 =46on +49 511 / 590 935 - 15 =46ax +49 511 / 590 935 - 29 Mail wundram@beenic.net Beenic Networks GmbH =2D------------------------------------ Sitz der Gesellschaft: Hannover Gesch=E4ftsf=FChrer: Jorge Delgado Registernummer: HRB 61869 Registergericht: Amtsgericht Hannover From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 17 14:45: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 9C46F16A404 for ; Tue, 17 Jul 2007 14:45:55 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id 4CCF113C4B4 for ; Tue, 17 Jul 2007 14:45:55 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.7b8) with ESMTP id 197191648 for multiple; Tue, 17 Jul 2007 10:54:11 -0400 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l6HEjkMB043598; Tue, 17 Jul 2007 10:45:48 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Tue, 17 Jul 2007 10:34:09 -0400 User-Agent: KMail/1.9.6 References: <20070716113425.GC65937@turion.vk2pj.dyndns.org> <469BB821.1010507@elischer.org> In-Reply-To: <469BB821.1010507@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707171034.09619.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Tue, 17 Jul 2007 10:45:49 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3689/Tue Jul 17 08:02:12 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: Julian Elischer Subject: Re: add closefrom() call 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, 17 Jul 2007 14:45:55 -0000 On Monday 16 July 2007 02:25:37 pm Julian Elischer wrote: > Peter Jeremy wrote: > > On 2007-Jul-15 16:51:38 -0700, Julian Elischer wrote: > >>> void > >>> closefrom(int lowfd) > >>> { > >>> fcntl(lowfd, F_CLOSEM, NULL); > >>> } > >> what on earth would that achieve? > >> (as opposed to just a simple syscall) > > > > The only benefit I can think of is minimising the number of syscalls. > > Is there any other benefit? > > > > I don't think so.. it's less efficient, and harder to do.. > syscalls are not in short supply. Actually, adding a new fcntl is about the same as adding a new system call except that you don't have to generate tables, etc. (so it might actually be simpler). I'm not sure it's such a bad idea to just have a fcntl to get the max open fd and do the loop in userland so you get better auditing of the individual close() operations. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 17 18:21:09 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 23E8B16A403; Tue, 17 Jul 2007 18:21:09 +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 0381A13C467; Tue, 17 Jul 2007 18:21:08 +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.06) with ESMTP id l6HIL8Fq004537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Jul 2007 11:21:08 -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 l6HIL7Ce030430; Tue, 17 Jul 2007 11:21:07 -0700 X-Auth-Received: from [192.55.52.10] by hymn01.u.washington.edu via HTTP; Tue, 17 Jul 2007 11:21:07 PDT Date: Tue, 17 Jul 2007 11:21:07 -0700 (PDT) From: youshi10@u.washington.edu To: Milos Vyletel In-Reply-To: <20070716231345.GA43427@rulez.sk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.3.2.304607, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.7.17.105933 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' Cc: hackers@freebsd.org, current@freebsd.org Subject: Re: Large amounts of memory access operations cause panic under CURRENT (was "Large gap between fwrite and write, and fread and read") 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, 17 Jul 2007 18:21:09 -0000 On Tue, 17 Jul 2007, Milos Vyletel wrote: >>> Go figure it'd cause panics for other people. >>> >>> I wasn't using zfs at all but it panicked anyhow once (my amd64 VM only, >>> not my i386 test server, surprisingly). I wish I'd gotten the panic but I >>> walked away to get a glass of water, and there wasn't a core dump because >>> the VM shut down completely instead of restarting. Heh. >>> >>> My virtual machine died around 90k on the first trial though. I'll be sure >>> to reduce the amount and see what happens, and I'll put nanosleeps or >>> usleeps between the read and write ops to see if that alleviates the race >>> condition seen, but I'll keep the problem code around for reference later >>> in case I've stimulated some sort of weird bug in FreeBSD, or otherwise. >>> >>> Both my VM and test server run almost no programs though other than samba >>> and rsync, so you'll probably see the panic faster / more frequently than I >>> will if you run a lot more programs resident in memory. >>> >>> Just curious, what scheduler are you using on CURRENT, what processor do >>> you have, and what are your memory specs? >>> >>> Thanks, >>> -Garrett >>> >> Hi Garrett, >> >> this is just my desktop where is running only Xorg, fluxbox, few aterms and >> firefox. But i can get the panic on console too, shortly after booting. I'm >> using SCHED_ULE. >> >> CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ (2205.01-MHz K8-class >> CPU) >> Origin = "AuthenticAMD" Id = 0x20f32 Stepping = 2 >> Features=0x178bfbff >> Features2=0x1 >> AMD Features=0xe2500800 >> AMD Features2=0x3 >> Cores per package: 2 >> usable memory = 3211718656 (3062 MB) >> avail memory = 3105570816 (2961 MB) >> >> For the record, it crashes few times before it hit 100k iterations, before i >> put >> debug printf in your code and increase MAX_ITERATIONS to 1m. And as far as I >> can tell, I had pretty much the same results as you've measured. >> >> mv > > Sorry for the noise, forgot to CC current@ This seems to be resolved with the latest CURRENT sources and ULE patches. -Garrett From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 17 18:34: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 1CCD616A400 for ; Tue, 17 Jul 2007 18:34:38 +0000 (UTC) (envelope-from maslanbsd@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.237]) by mx1.freebsd.org (Postfix) with ESMTP id CD36413C4AC for ; Tue, 17 Jul 2007 18:34:37 +0000 (UTC) (envelope-from maslanbsd@gmail.com) Received: by wr-out-0506.google.com with SMTP id i23so876763wra for ; Tue, 17 Jul 2007 11:34:37 -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=DGExvFAvV8hCKN/Nyyx3KsbpZRbo6aZJevFq0D7xY4FPNCMjGBEIZGowIQmYMN+sVr3UxpPfIZcYUnwGX6gUvpHQ43RAsRSi2TvlrdeSK5iSZWxvDUSloO36VD8Kq03je2pe9z1gvVkusXIGjS3rAjoCBRiK1AIyUbkuPKFCx0o= 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=MKl3qBdQPvwJkeWIr5pDnYNqnSGNCW4pPvWf5m9ldIVFSkfclrEfHqjo/0EwSpAaW/dx9JP9c3SmT0E/tiH40Gm8GhE3bgxrngBms0PQ6XqQ5VLWgDmMNhvvE9bijK0VqHXkbOiqSSDhn/I8CPP2K0vgX+umiaFm9y36RDb3xZY= Received: by 10.143.162.8 with SMTP id p8mr54317wfo.1184697276260; Tue, 17 Jul 2007 11:34:36 -0700 (PDT) Received: by 10.142.86.18 with HTTP; Tue, 17 Jul 2007 11:34:36 -0700 (PDT) Message-ID: <319cceca0707171134j27df3f48x43b75aa3855129c8@mail.gmail.com> Date: Tue, 17 Jul 2007 21:34:36 +0300 From: Maslan To: "Sam Leffler" In-Reply-To: <469AB840.50103@errno.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_62525_12174839.1184697276221" References: <319cceca0707151335jd8aef89k635d7edb01d08691@mail.gmail.com> <20070715212757.GA17029@heff.fud.org.nz> <319cceca0707151516h502fcf42hd7f68e2351120407@mail.gmail.com> <469AB840.50103@errno.com> X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Hackers , Andrew Thompson Subject: Re: loading a firmware image 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, 17 Jul 2007 18:34:38 -0000 ------=_Part_62525_12174839.1184697276221 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I've attached what i did Thanks -- System Programmer -- I'm Searching For Perfection, So Even If U Need Portability U've To Use Assembly ;-) -- http://developer.berlios.de/projects/libosdk ------=_Part_62525_12174839.1184697276221-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 17 20:14:03 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 85A6916A403; Tue, 17 Jul 2007 20:14:03 +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 1F1D913C4B9; Tue, 17 Jul 2007 20:14:03 +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 l6HK0Khh041975; Tue, 17 Jul 2007 13:00:20 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.13.8/8.13.4/Submit) id l6HK0KeS041974; Tue, 17 Jul 2007 13:00:20 -0700 (PDT) Date: Tue, 17 Jul 2007 13:00:20 -0700 (PDT) From: Matthew Dillon Message-Id: <200707172000.l6HK0KeS041974@apollo.backplane.com> To: Tim Kientzle References: <46992FFF.7010906@kientzle.com> <20070714223853.GF16579@britannica.bec.de> <469992CA.6000104@freebsd.org> <4699BE75.2090808@freebsd.org> <20070715184703.GK2819@roadrunner.q.local> <469A8F91.7090509@freebsd.org> <7ad7ddd90707152356v6034352uf1f7a42ddb9c1166@mail.gmail.com> <469B8EF2.3010002@freebsd.org> Cc: hackers@freebsd.org, Ulrich Spoerlein Subject: Re: Tar output mode for installworld 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, 17 Jul 2007 20:14:03 -0000 :... :>> files off of CD. :> :> True, but couldn't we optimize the ISO layout so it will be a near :> sequential read of the CD? : :Hmmm... This might work. The prototype 'ntree' support :I posted should be sufficient for people to experiment :with these ideas. : :Cheers, : :Tim Kientzle Probably the best way to do this is to pre-cache the data with an /etc/rc.d script. Write a little program to do it or build it as a script. Inode numbers for files on a CD tend to reflect the location of the file on the CD so a quick pre-scan of primary directories, extract the file paths used during the boot, sort by inode number, and then just open/read them to force them into the buffer cache ought to be sufficient. I would not try to optimize the layout of the ISO itself as such work would likely go stale in fairly short order and would be difficult to maintain. Personally speaking I think its a waste of time to worry about it. Sure the CD seeks around a bit, but most modern CD drives do have caches and it really isn't all that bad. Instead, we focus on streamlining the process so a person can go through a few quick menu items and then take a short coffee break while the installer does the rest of the work. -- I do recommend the 'copy the live CD to the hard disk' method of installation. It removes a lot of confusion from the release building process and makes it utterly trivial to add customizations. The only thing we can't copy directly is /etc, because the /etc on the CD is for the CD boot. So the DragonFly CD has a "/etc.hdd" directory for the version of /etc to be installed on the HD. Also, large chunks of the infrastructure will already be in the buffer cache just from booting the live CD so those bits don't have to be re-read. Doing a direct copy has always felt 'faster' to me then unpacking split up tar files. -Matt Matthew Dillon From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 18 01:06:09 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 1F16E16A400; Wed, 18 Jul 2007 01:06:09 +0000 (UTC) (envelope-from stephen@math.missouri.edu) Received: from cauchy.math.missouri.edu (cauchy.math.missouri.edu [128.206.184.213]) by mx1.freebsd.org (Postfix) with ESMTP id E5B0913C4C8; Wed, 18 Jul 2007 01:06:03 +0000 (UTC) (envelope-from stephen@math.missouri.edu) Received: from laptop2.gateway.2wire.net (cauchy.math.missouri.edu [128.206.184.213]) by cauchy.math.missouri.edu (8.14.1/8.13.4) with ESMTP id l6I0kCgG090382; Tue, 17 Jul 2007 19:46:12 -0500 (CDT) (envelope-from stephen@math.missouri.edu) Message-ID: <469D62D3.70908@math.missouri.edu> Date: Tue, 17 Jul 2007 19:46:11 -0500 From: Stephen Montgomery-Smith User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.4) Gecko/20070717 SeaMonkey/1.1.2 MIME-Version: 1.0 To: ports@freebsd.org, freebsd-hackers@freebsd.org Content-Type: multipart/mixed; boundary="------------010700020604010509030004" Cc: Subject: Slight problem with make actual-package-depends with 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: Wed, 18 Jul 2007 01:06:09 -0000 This is a multi-part message in MIME format. --------------010700020604010509030004 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I appreciate that most people won't have this problem, but it has bitten me. After you have made and installed a port, but don't clean it, and then made a bunch of other ports, if you go back to the original port and then do "make package", then +CONTENTS can be a bit messed up for the package. This is because the creation of other ports might disturb _LIB_RUN_DEPENDS and might put in some extra entries in +CONTENTS. This happens to me because I make all my ports on one machine and then copy them as packages to other machines. Then on the other machines, the structure of /var/db/pkg gets a bit messed up and pkg_delete -r malfunctions. It seems to me that the cure is to slightly change "make actual-package-depends" so that if the port is already installed, it just uses +CONTENTS. I enclose a patch. Unless I get a bunch of negative comments, I'll submit this as a PR as well. Stephen --------------010700020604010509030004 Content-Type: text/plain; name="ddd" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ddd" --- bsd.port.mk-old 2007-07-17 19:31:08.000000000 -0500 +++ bsd.port.mk 2007-07-17 19:29:16.000000000 -0500 @@ -5485,7 +5485,9 @@ done ACTUAL-PACKAGE-DEPENDS?= \ - if [ "${_LIB_RUN_DEPENDS}" != " " ]; then \ + if [ -e ${PKG_DBDIR}/${PKGNAME}/+CONTENTS ]; then \ + ${AWK} -F '( |:)' 'BEGIN { pkgname="broken_contents" } /@pkgdep / { pkgname=$$2 } /@comment DEPORIGIN:/ { printf "%s:%s\n", pkgname, $$3; pkgname="broken_contents" }' ${PKG_DBDIR}/${PKGNAME}/+CONTENTS; \ + elif [ "${_LIB_RUN_DEPENDS}" != " " ]; then \ origins=$$(for pkgname in ${PKG_DBDIR}/*; do \ if [ -e $$pkgname/+CONTENTS ]; then \ ${ECHO_CMD} $${pkgname\#\#*/}; \ --------------010700020604010509030004-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 18 01:33: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 B14A116A407 for ; Wed, 18 Jul 2007 01:33:04 +0000 (UTC) (envelope-from scubacuda@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178]) by mx1.freebsd.org (Postfix) with ESMTP id 8341213C4BA for ; Wed, 18 Jul 2007 01:33:04 +0000 (UTC) (envelope-from scubacuda@gmail.com) Received: by wa-out-1112.google.com with SMTP id j37so43251waf for ; Tue, 17 Jul 2007 18:33:04 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=XUqLTDRQzRrhpRFMgp01cgvreOAbeS04nmHH6gn3rVJxBLnpAZxGGBIR7KJ4i80u5qDMcRblWn5LgwWMCgt912qLTifkcc/oIMdgCvsCROxJiH8hKvP2zaIbVLWJO1zG5t7vREMomylByS2AZIg6PnzDXiAIVBSIxf6LkUdsInQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=fw/11GgNgfHePGVoGDK8zhXwTthwGupoz40WSpdy5gqUYX4JHjStQdVAoUa/RznVKtOTE0DMP3/+Llh2Cvl8sFsh1kJUljVhVbW26H++mOogA/cvTeHimAVZd7Qqcmi6GwcTJq53lhIwnGzrl1VHjc9q8j6BDcORxGDCGAtk/8M= Received: by 10.115.22.1 with SMTP id z1mr966111wai.1184720646412; Tue, 17 Jul 2007 18:04:06 -0700 (PDT) Received: by 10.114.149.17 with HTTP; Tue, 17 Jul 2007 18:04:06 -0700 (PDT) Message-ID: <2b7af7c40707171804p1cfd7201v5fae4057bb95d935@mail.gmail.com> Date: Tue, 17 Jul 2007 18:04:06 -0700 From: "Rogelio Bastardo" To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: permission denied to properly chmod'd files X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: scubacuda@gmail.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2007 01:33:04 -0000 Today while trying to create a Cacti graph (something I've been able to do with no problems on this box before), I got a "permission denied" error on the .rrd file that I was trying to access. I shelled into a FreeBSD box, only to find that the "/usr/local/share/cacti/rrd" folder was properly chmod'd and chown'd with the Cacti user. I'm relatively new to FreeBSD (compared to other distros) and unfortunately cannot get any good information out of anyone about what changed on this server. (It seemed to be working a few weeks ago). Might there be some sort of BSD version of SELinux going on here? No one has any info on what "changed" on the box to make it not work. I've never had this problem on Cacti on the other distros I've worked with (mostly Debian and RHEL/CentOS) and am wondering if it is a FreeBSD oddity that I'm not understanding. If FreeBSD is off the hook, then I'll go bug the Cacti crowd. Thanks in advance From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 18 02:47: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 0F95216A400 for ; Wed, 18 Jul 2007 02:47:53 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from ns.trinitel.com (186.161.36.72.static.reverse.layeredtech.com [72.36.161.186]) by mx1.freebsd.org (Postfix) with ESMTP id DA17C13C481 for ; Wed, 18 Jul 2007 02:47:50 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from neutrino.vnode.org (r74-193-81-203.pfvlcmta01.grtntx.tl.dh.suddenlink.net [74.193.81.203]) (authenticated bits=0) by ns.trinitel.com (8.14.1/8.14.1) with ESMTP id l6I2a6HE031257 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Tue, 17 Jul 2007 21:36:07 -0500 (CDT) (envelope-from anderson@freebsd.org) Message-ID: <469D7C98.2070508@freebsd.org> Date: Tue, 17 Jul 2007 21:36:08 -0500 From: Eric Anderson User-Agent: Thunderbird 2.0.0.4 (X11/20070629) MIME-Version: 1.0 To: scubacuda@gmail.com References: <2b7af7c40707171804p1cfd7201v5fae4057bb95d935@mail.gmail.com> In-Reply-To: <2b7af7c40707171804p1cfd7201v5fae4057bb95d935@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on ns.trinitel.com Cc: freebsd-hackers@freebsd.org Subject: Re: permission denied to properly chmod'd files 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, 18 Jul 2007 02:47:53 -0000 On 07/17/07 20:04, Rogelio Bastardo wrote: > Today while trying to create a Cacti graph (something I've been able > to do with no problems on this box before), I got a "permission > denied" error on the .rrd file that I was trying to access. > > I shelled into a FreeBSD box, only to find that the > "/usr/local/share/cacti/rrd" folder was properly chmod'd and chown'd > with the Cacti user. > > I'm relatively new to FreeBSD (compared to other distros) and > unfortunately cannot get any good information out of anyone about what > changed on this server. (It seemed to be working a few weeks ago). > > Might there be some sort of BSD version of SELinux going on here? No > one has any info on what "changed" on the box to make it not work. > I've never had this problem on Cacti on the other distros I've worked > with (mostly Debian and RHEL/CentOS) and am wondering if it is a > FreeBSD oddity that I'm not understanding. > > If FreeBSD is off the hook, then I'll go bug the Cacti crowd. Are you using NFS at all? If so, check your locking. Otherwise, some more debugging would help - can you become the cacti user, and then access it? How about doing a ktrace on the rrd process as it fails? Eric From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 18 04:08: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 3829016A400 for ; Wed, 18 Jul 2007 04:08:14 +0000 (UTC) (envelope-from wundram@beenic.net) Received: from mail.beenic.net (mail.beenic.net [83.246.72.40]) by mx1.freebsd.org (Postfix) with ESMTP id F1B5C13C46B for ; Wed, 18 Jul 2007 04:08:13 +0000 (UTC) (envelope-from wundram@beenic.net) Received: from [192.168.1.37] (a89-182-28-88.net-htp.de [89.182.28.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.beenic.net (Postfix) with ESMTP id D2EF0A44529 for ; Wed, 18 Jul 2007 06:06:37 +0200 (CEST) From: "Heiko Wundram (Beenic)" Organization: Beenic Networks GmbH To: freebsd-hackers@freebsd.org Date: Wed, 18 Jul 2007 06:08:09 +0200 User-Agent: KMail/1.9.7 References: <2b7af7c40707171804p1cfd7201v5fae4057bb95d935@mail.gmail.com> <469D7C98.2070508@freebsd.org> In-Reply-To: <469D7C98.2070508@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200707180608.10350.wundram@beenic.net> Subject: Re: permission denied to properly chmod'd files 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, 18 Jul 2007 04:08:14 -0000 On Wednesday 18 July 2007 04:36:08 Eric Anderson wrote: > On 07/17/07 20:04, Rogelio Bastardo wrote: > > Might there be some sort of BSD version of SELinux going on here? No > > one has any info on what "changed" on the box to make it not work. > > I've never had this problem on Cacti on the other distros I've worked > > with (mostly Debian and RHEL/CentOS) and am wondering if it is a > > FreeBSD oddity that I'm not understanding. > Just because you didn't say: FreeBSD is not a Linux distribution... :-) =2D-=20 Heiko Wundram Product & Application Development =2D------------------------------------ Office Germany - EXPO PARK HANNOVER =20 Beenic Networks GmbH Mail=E4nder Stra=DFe 2 30539 Hannover =20 =46on +49 511 / 590 935 - 15 =46ax +49 511 / 590 935 - 29 Mail wundram@beenic.net Beenic Networks GmbH =2D------------------------------------ Sitz der Gesellschaft: Hannover Gesch=E4ftsf=FChrer: Jorge Delgado Registernummer: HRB 61869 Registergericht: Amtsgericht Hannover From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 18 04:20:09 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 3BE7E16A40B for ; Wed, 18 Jul 2007 04:20:09 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with SMTP id BB6D113C4C8 for ; Wed, 18 Jul 2007 04:20:08 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 16375 invoked by uid 399); 18 Jul 2007 03:53:28 -0000 Received: from localhost (HELO ?192.168.0.4?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTP; 18 Jul 2007 03:53:28 -0000 X-Originating-IP: 127.0.0.1 Message-ID: <469D8EB0.7030603@FreeBSD.org> Date: Tue, 17 Jul 2007 20:53:20 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Stephen Montgomery-Smith References: <469D62D3.70908@math.missouri.edu> In-Reply-To: <469D62D3.70908@math.missouri.edu> X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ports@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Slight problem with make actual-package-depends with 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: Wed, 18 Jul 2007 04:20:09 -0000 Stephen Montgomery-Smith wrote: > I appreciate that most people won't have this problem, but it has bitten > me. > > After you have made and installed a port, but don't clean it, and then > made a bunch of other ports, if you go back to the original port and > then do "make package", then +CONTENTS can be a bit messed up for the > package. This is because the creation of other ports might disturb > _LIB_RUN_DEPENDS and might put in some extra entries in +CONTENTS. "Doctor, it hurts when I do THIS." "Well, don't do that." :) Doug -- This .signature sanitized for your protection From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 18 05:03: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 2173C16A400; Wed, 18 Jul 2007 05:03:00 +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 0045713C4B5; Wed, 18 Jul 2007 05:02:59 +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.06) with ESMTP id l6I52xfP024008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 17 Jul 2007 22:02:59 -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 l6I52wVY003687 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 17 Jul 2007 22:02:59 -0700 Message-ID: <469D9F01.6090204@u.washington.edu> Date: Tue, 17 Jul 2007 22:02:57 -0700 From: Garrett Cooper User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Doug Barton References: <469D62D3.70908@math.missouri.edu> <469D8EB0.7030603@FreeBSD.org> In-Reply-To: <469D8EB0.7030603@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.3.2.304607, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.7.17.214533 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: ports@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Slight problem with make actual-package-depends with 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: Wed, 18 Jul 2007 05:03:00 -0000 Doug Barton wrote: > Stephen Montgomery-Smith wrote: > >> I appreciate that most people won't have this problem, but it has bitten >> me. >> >> After you have made and installed a port, but don't clean it, and then >> made a bunch of other ports, if you go back to the original port and >> then do "make package", then +CONTENTS can be a bit messed up for the >> package. This is because the creation of other ports might disturb >> _LIB_RUN_DEPENDS and might put in some extra entries in +CONTENTS. >> > > "Doctor, it hurts when I do THIS." > "Well, don't do that." :) > > Doug Heh. That can't be as bad as when I was fubar'ing pkg_install last week after creating accidental segfault conditions. Not being able to install ports for 1-2 days sucked :P. -Garrett From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 18 06:31:08 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 57EDD16A410; Wed, 18 Jul 2007 06:31:08 +0000 (UTC) (envelope-from fbsd-hackers@mawer.org) Received: from webmail.icp-qv1-irony2.iinet.net.au (webmail.icp-qv1-irony2.iinet.net.au [203.59.1.107]) by mx1.freebsd.org (Postfix) with ESMTP id 8BE6413C4AC; Wed, 18 Jul 2007 06:31:07 +0000 (UTC) (envelope-from fbsd-hackers@mawer.org) Received: from 203-206-173-235.perm.iinet.net.au (HELO [10.24.1.1]) ([203.206.173.235]) by outbound.icp-qv1-irony-out2.iinet.net.au with ESMTP; 18 Jul 2007 14:01:45 +0800 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAADxJnUbLzq3r/2dsb2JhbAAN X-IronPort-AV: i="4.16,549,1175443200"; d="scan'208"; a="161298055:sNHT398666430" Message-ID: <469DAC63.3020708@mawer.org> Date: Wed, 18 Jul 2007 16:00:03 +1000 From: Antony Mawer User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Stephen Montgomery-Smith References: <469D62D3.70908@math.missouri.edu> In-Reply-To: <469D62D3.70908@math.missouri.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ports@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Slight problem with make actual-package-depends with 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: Wed, 18 Jul 2007 06:31:08 -0000 On 18/07/2007 10:46 AM, Stephen Montgomery-Smith wrote: > I appreciate that most people won't have this problem, but it has bitten > me. > > After you have made and installed a port, but don't clean it, and then > made a bunch of other ports, if you go back to the original port and > then do "make package", then +CONTENTS can be a bit messed up for the > package. This is because the creation of other ports might disturb > _LIB_RUN_DEPENDS and might put in some extra entries in +CONTENTS. > > This happens to me because I make all my ports on one machine and then > copy them as packages to other machines. Then on the other machines, > the structure of /var/db/pkg gets a bit messed up and pkg_delete -r > malfunctions. > > It seems to me that the cure is to slightly change "make > actual-package-depends" so that if the port is already installed, it > just uses +CONTENTS. I can't comment on the particular approach taken in your patch, but can certainly attest to experiencing the same problem and it being frustrating to identify what was going on. It was only after much hair-pulling that I discovered that doing a 'make clean' at the appropriate time before package building fixed the problem. Otherwise I was winding up with plenty of seemingly OK packages that were missing critical files (in this instance, various PHP5 extension ports that were "installing" but missing the actual .so files!) --Antony From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 18 07:44:26 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 7C45416A401; Wed, 18 Jul 2007 07:44:26 +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 59C7513C4AC; Wed, 18 Jul 2007 07:44:26 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout3.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.06) with ESMTP id l6I7iP6R018823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 18 Jul 2007 00:44:25 -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 l6I7iOkA025193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 18 Jul 2007 00:44:25 -0700 Message-ID: <469DC4D7.5050102@u.washington.edu> Date: Wed, 18 Jul 2007 00:44:23 -0700 From: Garrett Cooper User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Antony Mawer References: <469D62D3.70908@math.missouri.edu> <469DAC63.3020708@mawer.org> In-Reply-To: <469DAC63.3020708@mawer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.3.2.304607, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.7.18.1939 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: ports@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Slight problem with make actual-package-depends with 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: Wed, 18 Jul 2007 07:44:26 -0000 Antony Mawer wrote: > On 18/07/2007 10:46 AM, Stephen Montgomery-Smith wrote: >> I appreciate that most people won't have this problem, but it has >> bitten me. >> >> After you have made and installed a port, but don't clean it, and >> then made a bunch of other ports, if you go back to the original port >> and then do "make package", then +CONTENTS can be a bit messed up for >> the package. This is because the creation of other ports might >> disturb _LIB_RUN_DEPENDS and might put in some extra entries in >> +CONTENTS. >> >> This happens to me because I make all my ports on one machine and >> then copy them as packages to other machines. Then on the other >> machines, the structure of /var/db/pkg gets a bit messed up and >> pkg_delete -r malfunctions. >> >> It seems to me that the cure is to slightly change "make >> actual-package-depends" so that if the port is already installed, it >> just uses +CONTENTS. > > I can't comment on the particular approach taken in your patch, but > can certainly attest to experiencing the same problem and it being > frustrating to identify what was going on. It was only after much > hair-pulling that I discovered that doing a 'make clean' at the > appropriate time before package building fixed the problem. > > Otherwise I was winding up with plenty of seemingly OK packages that > were missing critical files (in this instance, various PHP5 extension > ports that were "installing" but missing the actual .so files!) > > --Antony Installing ports registers them on the machine as packages, by simulating a package install via stdin. Was that forgotten? -Garrett From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 18 09:49:24 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 E418E16A401 for ; Wed, 18 Jul 2007 09:49:24 +0000 (UTC) (envelope-from theom.rad@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178]) by mx1.freebsd.org (Postfix) with ESMTP id C114F13C428 for ; Wed, 18 Jul 2007 09:49:24 +0000 (UTC) (envelope-from theom.rad@gmail.com) Received: by wa-out-1112.google.com with SMTP id j37so168905waf for ; Wed, 18 Jul 2007 02:49:24 -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=JXAoQUg9peCTh9g2GqdSKgu46fCiJheW0QYurCWLwOYKRiCrZDo4xIcSsY/JPds9V9qd7ZvViuuyxxSiM9S80z6FfMFBFzHC7doMd7LcvTr6c6ugCFGGceO7whijGTkMrAOGsHHyE7Th5+L9t5e4kc1ygDsO7Zf4l/BPryxQkeI= 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=Bjg80KgROlOyT3sfQ7TW01xVr5oxri3MWiuvTH0RX03m5sQ2pb3UuS1oGE37/0REQAvXOvIUxb9EPDWU7W73uYkkVRVwNKibPs4V95TwR1h4MgBuHHYKkf37fZY8yWufePrfApbdRe3eEBy17/PjFbKm2dFwtUHkQ8ZiJDyi564= Received: by 10.114.92.2 with SMTP id p2mr1294073wab.1184750719220; Wed, 18 Jul 2007 02:25:19 -0700 (PDT) Received: by 10.114.211.2 with HTTP; Wed, 18 Jul 2007 02:25:19 -0700 (PDT) Message-ID: <89377a270707180225p2beb6529j3444c940d39b5f08@mail.gmail.com> Date: Wed, 18 Jul 2007 17:25:19 +0800 From: "Theom Rad" To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: hi, I'm a hacker!!! 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, 18 Jul 2007 09:49:25 -0000 ha ha ha!!! From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 18 10:08: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 95DBE16A404; Wed, 18 Jul 2007 10:08:01 +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 7009613C4C6; Wed, 18 Jul 2007 10:08:01 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.7] (may be forged)) by mxout1.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.06) with ESMTP id l6IA80wP020046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 18 Jul 2007 03:08:01 -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 l6IA7xeN017308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 18 Jul 2007 03:08:00 -0700 Message-ID: <469DE67F.5030801@u.washington.edu> Date: Wed, 18 Jul 2007 03:07:59 -0700 From: Garrett Cooper User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: krion@freebsd.org, hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.3.2.304607, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.7.18.24433 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: Proposal for alleviating disk read / write time 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, 18 Jul 2007 10:08:01 -0000 Hello Kirill and Hackers, After reviewing the changes I made last weekend to pkg_install I'm seeing slight improvements, but not a large amount of improvement in overall program operation. I haven't implemented mmap(2) yet as John Baldwin suggested (need to do some reading about fcntl(2) tomorrow because I want to implement locking), so I should see a large boost then, but I was wondering if I should do something similar to the following to reduce redundant disk accesses. 1. Lock +CONTENTS and related files exclusively for writes. Allow shared reads among separate pkg_install (and derivative programs) processes, and derivative packing lists with a limited set and use a LRU type algorithm to move packing lists in and out of shared memory. 2. If shared memory amongst separate processes is possible, share the ports INDEX's entire package list as a global object, and update only if the INDEX's real and virtual copy get out of sync (i.e. local copy is replaced, modified, or touch(1)'ed). +CONTENTS and INDEX are read frequently (once per process set) and although modifying pkg_install won't benefit overall operation speed without implementing a different data structure setup (still aiming for something like red-black trees for larger package lists like INDEX has, and linked lists for the smaller package lists), I think that the above changes would reduce wait times as pkg_install and installing ports becomes more and more concurrent. Clarifications and comments are more than welcome. I really appreciate it. Also, if someone can point me to the unofficial locking guidelines page (I remember it coming up twice in the past, but I'm busy now and wondering if someone can quickly point me to the page), it'd be more than appreciated. Thanks! -Garrett From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 18 09:17: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 A13BE16A404; Wed, 18 Jul 2007 09:17:58 +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 5CD0213C491; Wed, 18 Jul 2007 09:17:58 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A56F83.dip.t-dialin.net [84.165.111.131]) by redbull.bpaserver.net (Postfix) with ESMTP id 81DA22E1AA; Wed, 18 Jul 2007 11:17:44 +0200 (CEST) Received: from deskjail (deskjail.Leidinger.net [192.168.1.109]) by outgoing.leidinger.net (Postfix) with ESMTP id A04595B547D; Wed, 18 Jul 2007 11:15:32 +0200 (CEST) Date: Wed, 18 Jul 2007 11:19:20 +0200 From: Alexander Leidinger To: Stephen Montgomery-Smith Message-ID: <20070718111920.43c198e3@deskjail> In-Reply-To: <469D62D3.70908@math.missouri.edu> References: <469D62D3.70908@math.missouri.edu> X-Mailer: Claws Mail 2.9.2 (GTK+ 2.10.13; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-14.9, required 8, BAYES_00 -15.00, DKIM_POLICY_SIGNSOME 0.00, RDNS_DYNAMIC 0.10) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No X-Mailman-Approved-At: Wed, 18 Jul 2007 12:41:06 +0000 Cc: ports@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Slight problem with make actual-package-depends with 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: Wed, 18 Jul 2007 09:17:58 -0000 Quoting Stephen Montgomery-Smith (Tue, 17 Jul 2007 19:46:11 -0500): > I appreciate that most people won't have this problem, but it has bitten me. > > After you have made and installed a port, but don't clean it, and then > made a bunch of other ports, if you go back to the original port and > then do "make package", then +CONTENTS can be a bit messed up for the > package. This is because the creation of other ports might disturb Can you please give an example what "messed up" means in this context, e.g. post a diff between a good an a bad contents file? And what actions you did to get this difference? > _LIB_RUN_DEPENDS and might put in some extra entries in +CONTENTS. You mean that if you create a leaf package and then rebuild a package which is in the middle of the dependency tree with options which change the dependency graph of the leaf package you get problems? If yes: this has to be expected. You need to rebuild the packages in the right order. > This happens to me because I make all my ports on one machine and then > copy them as packages to other machines. Then on the other machines, > the structure of /var/db/pkg gets a bit messed up and pkg_delete -r > malfunctions. I have a lot of jails where I use the packages build in other jails. I haven't seen a problem there. The package install doesn't change the +CONTENTS files, so /var/db/pkg should be messed up on the build machine too... > It seems to me that the cure is to slightly change "make > actual-package-depends" so that if the port is already installed, it > just uses +CONTENTS. This is wrong. What if you have a port installed and you want to rebuild the same version with other OPTIONS which changes the +CONTENTS file? If I read your patch right, it will use the wrong contents... Bye, Alexander. -- I wonder if I should put myself in ESCROW!! 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 Jul 18 14:16: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 8F55C16A400; Wed, 18 Jul 2007 14:16:57 +0000 (UTC) (envelope-from stephen@math.missouri.edu) Received: from cauchy.math.missouri.edu (cauchy.math.missouri.edu [128.206.184.213]) by mx1.freebsd.org (Postfix) with ESMTP id 6164613C4B6; Wed, 18 Jul 2007 14:16:57 +0000 (UTC) (envelope-from stephen@math.missouri.edu) Received: from laptop2.gateway.2wire.net (cauchy.math.missouri.edu [128.206.184.213]) by cauchy.math.missouri.edu (8.14.1/8.13.4) with ESMTP id l6IEGuMx094840; Wed, 18 Jul 2007 09:16:56 -0500 (CDT) (envelope-from stephen@math.missouri.edu) Message-ID: <469E20D8.2020408@math.missouri.edu> Date: Wed, 18 Jul 2007 09:16:56 -0500 From: Stephen Montgomery-Smith User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.4) Gecko/20070717 SeaMonkey/1.1.2 MIME-Version: 1.0 To: Alexander Leidinger References: <469D62D3.70908@math.missouri.edu> <20070718111920.43c198e3@deskjail> In-Reply-To: <20070718111920.43c198e3@deskjail> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ports@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Slight problem with make actual-package-depends with 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: Wed, 18 Jul 2007 14:16:57 -0000 Alexander Leidinger wrote: > Quoting Stephen Montgomery-Smith (Tue, 17 Jul 2007 19:46:11 -0500): > >> I appreciate that most people won't have this problem, but it has bitten me. >> >> After you have made and installed a port, but don't clean it, and then >> made a bunch of other ports, if you go back to the original port and >> then do "make package", then +CONTENTS can be a bit messed up for the >> package. This is because the creation of other ports might disturb > > Can you please give an example what "messed up" means in this context, > e.g. post a diff between a good an a bad contents file? And what > actions you did to get this difference? I don't have an example to hand right now. > >> _LIB_RUN_DEPENDS and might put in some extra entries in +CONTENTS. > > You mean that if you create a leaf package and then rebuild a package > which is in the middle of the dependency tree with options which change > the dependency graph of the leaf package you get problems? > > If yes: this has to be expected. You need to rebuild the packages in > the right order. > >> This happens to me because I make all my ports on one machine and then >> copy them as packages to other machines. Then on the other machines, >> the structure of /var/db/pkg gets a bit messed up and pkg_delete -r >> malfunctions. > > I have a lot of jails where I use the packages build in other jails. I > haven't seen a problem there. The package install doesn't change the > +CONTENTS files, so /var/db/pkg should be messed up on the build > machine too... > >> It seems to me that the cure is to slightly change "make >> actual-package-depends" so that if the port is already installed, it >> just uses +CONTENTS. > > This is wrong. What if you have a port installed and you want to > rebuild the same version with other OPTIONS which changes the +CONTENTS > file? If I read your patch right, it will use the wrong contents... You cannot install the port until you have first deinstalled it (unless you use some kind of "FORCE" option, and it is reasonable that this would mess things up). Thus at installation time, +CONTENTS will never exist. But I take your point if perhaps you do need to use some kind of FORCE option. From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 18 15:11: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 38F1216A408; Wed, 18 Jul 2007 15:11:49 +0000 (UTC) (envelope-from stephen@math.missouri.edu) Received: from cauchy.math.missouri.edu (cauchy.math.missouri.edu [128.206.184.213]) by mx1.freebsd.org (Postfix) with ESMTP id AB05913C4D5; Wed, 18 Jul 2007 15:11:48 +0000 (UTC) (envelope-from stephen@math.missouri.edu) Received: from laptop2.gateway.2wire.net (cauchy.math.missouri.edu [128.206.184.213]) by cauchy.math.missouri.edu (8.14.1/8.13.4) with ESMTP id l6IFBlr1096027; Wed, 18 Jul 2007 10:11:47 -0500 (CDT) (envelope-from stephen@math.missouri.edu) Message-ID: <469E2DB3.8080605@math.missouri.edu> Date: Wed, 18 Jul 2007 10:11:47 -0500 From: Stephen Montgomery-Smith User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.4) Gecko/20070717 SeaMonkey/1.1.2 MIME-Version: 1.0 To: Alexander Leidinger References: <469D62D3.70908@math.missouri.edu> <20070718111920.43c198e3@deskjail> In-Reply-To: <20070718111920.43c198e3@deskjail> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ports@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Slight problem with make actual-package-depends with 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: Wed, 18 Jul 2007 15:11:49 -0000 Alexander Leidinger wrote: > Quoting Stephen Montgomery-Smith (Tue, 17 Jul 2007 19:46:11 -0500): > >> I appreciate that most people won't have this problem, but it has bitten me. >> >> After you have made and installed a port, but don't clean it, and then >> made a bunch of other ports, if you go back to the original port and >> then do "make package", then +CONTENTS can be a bit messed up for the >> package. This is because the creation of other ports might disturb > > Can you please give an example what "messed up" means in this context, > e.g. post a diff between a good an a bad contents file? And what > actions you did to get this difference? > >> _LIB_RUN_DEPENDS and might put in some extra entries in +CONTENTS. > > You mean that if you create a leaf package and then rebuild a package > which is in the middle of the dependency tree with options which change > the dependency graph of the leaf package you get problems? > > If yes: this has to be expected. You need to rebuild the packages in > the right order. In other words, you have to perform the "make package" right after the "make install" before you install any other ports. Otherwise you have to use "pkg_create -b" (which I have recently started doing). > >> This happens to me because I make all my ports on one machine and then >> copy them as packages to other machines. Then on the other machines, >> the structure of /var/db/pkg gets a bit messed up and pkg_delete -r >> malfunctions. > > I have a lot of jails where I use the packages build in other jails. I > haven't seen a problem there. The package install doesn't change the > +CONTENTS files, so /var/db/pkg should be messed up on the build > machine too... > >> It seems to me that the cure is to slightly change "make >> actual-package-depends" so that if the port is already installed, it >> just uses +CONTENTS. > > This is wrong. What if you have a port installed and you want to > rebuild the same version with other OPTIONS which changes the +CONTENTS > file? If I read your patch right, it will use the wrong contents... The other option (to allow the users to do "make package" much later than "make install") would be to have two different actual-package-depends, one for "make install", and the other for "make package." However if this is perceived to be a non-problem by everyone else, I am going to withdraw my suggestion. I'll just leave a note here in case anyone else has this problem (as indeed it seems at least one other person did), that you must do the "make package" right after the "make install." (I did file a PR - committers should close it if they feel it is not an issue. But I leave it with them.) Best regards, Stephen From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 18 17:13: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 2D3A816A401 for ; Wed, 18 Jul 2007 17:13:37 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from ik-out-1112.google.com (ik-out-1112.google.com [66.249.90.179]) by mx1.freebsd.org (Postfix) with ESMTP id A788813C471 for ; Wed, 18 Jul 2007 17:13:36 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: by ik-out-1112.google.com with SMTP id c21so295241ika for ; Wed, 18 Jul 2007 10:13:35 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=hjvNgo1B9XsmXto7UyUSXtJSmOKKVpFSGCzg4HgwY5kIHPDseApveji82gnLUl4Ugd97vx5fLczVD0St7bVbkAp0C0xoN+8Gmzuliuc1f2gufEwN/2I+3L6Ixci3FjaDUK7iMLg0O2i797DIDNeb8MHmFs9WIwpQlgedKLwC6K8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:cc:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=HD7hfJ962Z6uXhJK4p6pts/N07fQyJ011i0fXhlHq6XbPj09vFxfPkZmG1SnaNHrlkYvz7YLoOVb2G86Z4aKQOi27+2t+MzDoRadwOgBcsxoyHqSsf/e2EotinYtbZq7BZFkjwy0Vn3MDWhQCBQx8geDRaeazJQoFPOGPWkxsHE= Received: by 10.86.58.3 with SMTP id g3mr1269125fga.1184778815252; Wed, 18 Jul 2007 10:13:35 -0700 (PDT) Received: from roadrunner.q.local ( [85.180.173.101]) by mx.google.com with ESMTPS id g8sm3555248muf.2007.07.18.10.13.34 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 18 Jul 2007 10:13:34 -0700 (PDT) Received: from roadrunner.q.local (localhost [127.0.0.1]) by roadrunner.q.local (8.14.1/8.14.1) with ESMTP id l6IHDST3002474; Wed, 18 Jul 2007 19:13:28 +0200 (CEST) (envelope-from uspoerlein@gmail.com) Received: (from q@localhost) by roadrunner.q.local (8.14.1/8.14.1/Submit) id l6IHDSHg002473; Wed, 18 Jul 2007 19:13:28 +0200 (CEST) (envelope-from uspoerlein@gmail.com) Date: Wed, 18 Jul 2007 19:13:28 +0200 From: Ulrich Spoerlein To: Matthew Dillon Message-ID: <20070718171328.GA1413@roadrunner.q.local> Mail-Followup-To: Matthew Dillon , Tim Kientzle , hackers@freebsd.org References: <46992FFF.7010906@kientzle.com> <20070714223853.GF16579@britannica.bec.de> <469992CA.6000104@freebsd.org> <4699BE75.2090808@freebsd.org> <20070715184703.GK2819@roadrunner.q.local> <469A8F91.7090509@freebsd.org> <7ad7ddd90707152356v6034352uf1f7a42ddb9c1166@mail.gmail.com> <469B8EF2.3010002@freebsd.org> <200707172000.l6HK0KeS041974@apollo.backplane.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200707172000.l6HK0KeS041974@apollo.backplane.com> User-Agent: Mutt/1.5.15 (2007-04-06) Cc: hackers@freebsd.org, Tim Kientzle Subject: Re: Tar output mode for installworld 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, 18 Jul 2007 17:13:37 -0000 On Tue, 17.07.2007 at 13:00:20 -0700, Matthew Dillon wrote: > Probably the best way to do this is to pre-cache the data with an > /etc/rc.d script. Write a little program to do it or build it as a > script. Inode numbers for files on a CD tend to reflect the location That is an interesting project in itself. This could be used to speed up the boot process on any FreeBSD installation and I think MacOS' new init system is where I got the idea from. What I envisioned (quick n dirty): - Init runs rc inside a ktrace session - after the rc scripts have finished, you turn off ktrace - kdump and read all files which were read during rc[2] - do some magic to sort the list based on their hard disk location - put this list in /var/db/precache.db - /etc/rc.d/precache (which will run very early[1]): (for file; cat $file >/dev/null)&; sleep 3 yes, it will be run in the background Problems with this naive approach: It reads entire files, not blocks. The filelist has to be kept small and only "small" files should appear in the list. With direct kernel support one could do a lot more, I guess. I'm running on a fast laptop with a crappy 4800RPM hard disk which is dog slow. I have the feeling my bootup time could be reduced drastically by this approach. Perhaps some day I get around to prototyping it. [1] I know this is hard to decide. [2] To make this self-tuning, the output of the precache script must not appear in the ktrace/kdump list. Cheers, Ulrich Spoerlein -- "The trouble with the dictionary is you have to know how the word is spelled before you can look it up to see how it is spelled." -- Will Cuppy From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 18 17:33:13 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 F15B316A404 for ; Wed, 18 Jul 2007 17:33:13 +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 A7BEC13C47E for ; Wed, 18 Jul 2007 17:33:13 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IBDOe-0001c1-N1 for freebsd-hackers@freebsd.org; Wed, 18 Jul 2007 19:33:08 +0200 Received: from 78-0-79-182.adsl.net.t-com.hr ([78.0.79.182]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 18 Jul 2007 19:33:08 +0200 Received: from ivoras by 78-0-79-182.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 18 Jul 2007 19:33:08 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Date: Wed, 18 Jul 2007 19:32:54 +0200 Lines: 30 Message-ID: References: <469DE67F.5030801@u.washington.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1DB51281D2728D3C5AEB269F" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 78-0-79-182.adsl.net.t-com.hr User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) In-Reply-To: <469DE67F.5030801@u.washington.edu> X-Enigmail-Version: 0.94.3.0 Sender: news Subject: Re: Proposal for alleviating disk read / write time 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, 18 Jul 2007 17:33:14 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1DB51281D2728D3C5AEB269F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Garrett Cooper wrote: > Clarifications and comments are more than welcome. I really > appreciate it. Hmm, your requirements look more and more like a... database? :) [whistling away...] --------------enig1DB51281D2728D3C5AEB269F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGnk7MldnAQVacBcgRAmOdAJ40Z32u6eF2hupEeWP1/tB19EHyXwCg10Vl CjMOF1327FAjhUt+W4AQkHM= =oLw8 -----END PGP SIGNATURE----- --------------enig1DB51281D2728D3C5AEB269F-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 18 18:06: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 9EE5F16A405 for ; Wed, 18 Jul 2007 18:06:25 +0000 (UTC) (envelope-from oxy@field.hu) Received: from green.field.hu (green.field.hu [217.20.130.28]) by mx1.freebsd.org (Postfix) with ESMTP id 3910313C4C7 for ; Wed, 18 Jul 2007 18:06:24 +0000 (UTC) (envelope-from oxy@field.hu) Received: from localhost (green.field.hu [217.20.130.28]) by green.field.hu (Postfix) with ESMTP id E6D856D437 for ; Wed, 18 Jul 2007 19:47:45 +0200 (CEST) X-Virus-Scanned: by Amavisd-new (Spamassassin+Razor2+Pyzor+DCC+Bayes db, Clamd Antivirus) at field.hu Received: from green.field.hu ([217.20.130.28]) by localhost (green.field.hu [217.20.130.28]) (amavisd-new, port 10024) with ESMTP id KMjBzh0sXBFZ for ; Wed, 18 Jul 2007 19:47:43 +0200 (CEST) Received: from [192.168.1.2] (dsl77-234-78-86.pool.tvnet.hu [77.234.78.86]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by green.field.hu (Postfix) with ESMTP id 842FF6D400 for ; Wed, 18 Jul 2007 19:47:43 +0200 (CEST) Message-ID: <469E524B.1010001@field.hu> Date: Wed, 18 Jul 2007 19:47:55 +0200 From: oxy User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Subject: ttyd0 permission denied problem 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, 18 Jul 2007 18:06:25 -0000 hi! i have exactly the same problem: http://unix.derkeiler.com/Mailing-Lists/FreeBSD/questions/2006-07/msg00050.html is there any solution? i need serial console, and i can't figure out what's wrong.. From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 18 18:15:08 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 157E016A400 for ; Wed, 18 Jul 2007 18:15:08 +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 06C9C13C48D for ; Wed, 18 Jul 2007 18:15:07 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id CF26A1CC050; Wed, 18 Jul 2007 11:15:07 -0700 (PDT) Date: Wed, 18 Jul 2007 11:15:07 -0700 From: Jeremy Chadwick To: oxy Message-ID: <20070718181507.GA13344@eos.sc1.parodius.com> References: <469E524B.1010001@field.hu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <469E524B.1010001@field.hu> User-Agent: Mutt/1.5.15 (2007-04-06) Cc: freebsd-hackers@freebsd.org Subject: Re: ttyd0 permission denied problem 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, 18 Jul 2007 18:15:08 -0000 On Wed, Jul 18, 2007 at 07:47:55PM +0200, oxy wrote: > hi! > > i have exactly the same problem: > http://unix.derkeiler.com/Mailing-Lists/FreeBSD/questions/2006-07/msg00050.html > > is there any solution? i need serial console, and i can't figure out what's > wrong.. Do you see the same behaviour if you use cu or tip? -- | 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 Wed Jul 18 18:16: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 F180416A401 for ; Wed, 18 Jul 2007 18:16:40 +0000 (UTC) (envelope-from rh@matriplex.com) Received: from edurus.com (mail.accessgeek.com [66.224.198.10]) by mx1.freebsd.org (Postfix) with ESMTP id C214013C46B for ; Wed, 18 Jul 2007 18:16:40 +0000 (UTC) (envelope-from rh@matriplex.com) Received: from lark.hodges.org by edurus.com (MDaemon PRO v9.0.5) with ESMTP id md50002276674.msg for ; Wed, 18 Jul 2007 11:05:59 -0700 From: Richard Hodges To: freebsd-hackers@freebsd.org Date: Wed, 18 Jul 2007 12:06:35 -0600 User-Agent: KMail/1.8.2 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5676419.k3EZgrb2d2"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200707181206.52765.rh@matriplex.com> X-Authenticated-Sender: richard@hodges.org X-Spam-Processed: edurus.com, Wed, 18 Jul 2007 11:05:59 -0700 (not processed: message from trusted or authenticated source) X-MDRemoteIP: 72.36.38.114 X-Return-Path: rh@matriplex.com X-Envelope-From: rh@matriplex.com X-MDaemon-Deliver-To: freebsd-hackers@freebsd.org X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Rijndael sanity check? 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, 18 Jul 2007 18:16:41 -0000 --nextPart5676419.k3EZgrb2d2 Content-Type: multipart/mixed; boundary="Boundary-01=_3alnG3DPVpU1/lH" Content-Transfer-Encoding: 7bit Content-Disposition: inline --Boundary-01=_3alnG3DPVpU1/lH Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Okay, I am a little bit puzzled. I have been working with AES/Rijndael for= a=20 couple months now, and I have just run into something interesting. I have written two AES 128-bit implementations, one in C and one for a=20 microcontroller. I have carefully studied various references, including=20 =46IPS-197 and its test vectors. I have tested the C-language encryption a= nd=20 decryption functions with untold millions of pseudo-random blocks, checking= =20 that the encrypted blocks decrypt back to the originals, and also using the= =20 =46reeBSD rijndael functions (in libssh) as an arms-length comparison. I h= ave=20 also compared the results from my assembly language functions with those on= =20 my FreeBSD box, but not as extensively. So with three different code=20 implementations seemingly in agreement, I _thought_ things were just fine. Now I have run across an "interesting" situation. It appears that I have t= wo=20 different plaintext blocks that encrypt into the same cipher text. =20 Obviously, decryption will only provide one of the two original blocks. It= =20 was my understanding that one (and only) one plaintext will encrypt into a= =20 particular cipher text, and vice versa. So that is why I am puzzled. It also appears that I may have many more examples, if one is not enough. Here is my AES 128 bit key: 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c Here is plaintext #1: 920F0CE0A9A96BB9D8416962BDBBAA7C Here is plaintext #2: c74601001001000000000054006b51FF With my two implementations and the FreeBSD SSH library, I get: Encrypted result: c93d42187034cea8671b88431000d18c I have attached a test program that demonstrates this with the FreeBSD=20 Rijndael library. I have tested this on 6.0/AMD64 and 6.2/I386 with the sa= me=20 results. For 6.0, the ssh_ prefix is removed from the rijndael function=20 calls. > cc -Wall -O2 aes_test.c -o aes_test -l ssh aes_test.c: In function `encrypt_1': aes_test.c:136: warning: implicit declaration of function=20 `ssh_rijndael_set_key' aes_test.c:137: warning: implicit declaration of function=20 `ssh_rijndael_encrypt' > ./aes_test Using key: 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c 920F0CE0A9A96BB9D8416962BDBBAA7C decr: 92 0f 0c e0 a9 a9 6b b9 d8 41 69 62 bd bb aa 7c encr: c9 3d 42 18 70 34 ce a8 67 1b 88 43 10 00 d1 8c c74601001001000000000054006b51FF decr: c7 46 01 00 10 01 00 00 00 00 00 54 00 6b 51 ff encr: c9 3d 42 18 70 34 ce a8 67 1b 88 43 10 a2 d1 8c So I am asking if anyone can point out if I made an "obvious mistake",=20 duplicate my results on your own system, or provide some other useful=20 information on this. Many thanks! =2DRichard --Boundary-01=_3alnG3DPVpU1/lH-- --nextPart5676419.k3EZgrb2d2 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBGnla84jpbt0KuB24RAik9AKCkXd4gpWeZ+XcM6eaaDEc+RWQ89ACfSSt6 XQY2MiCWSvYlF4CDWlTpiTE= =ST/G -----END PGP SIGNATURE----- --nextPart5676419.k3EZgrb2d2-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 18 18:38:56 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 C16F916A403 for ; Wed, 18 Jul 2007 18:38:56 +0000 (UTC) (envelope-from rh@matriplex.com) Received: from edurus.com (mail.accessgeek.com [66.224.198.10]) by mx1.freebsd.org (Postfix) with ESMTP id 9DE2C13C4C1 for ; Wed, 18 Jul 2007 18:38:56 +0000 (UTC) (envelope-from rh@matriplex.com) Received: from lark.hodges.org by edurus.com (MDaemon PRO v9.0.5) with ESMTP id md50002276848.msg for ; Wed, 18 Jul 2007 11:38:56 -0700 From: Richard Hodges To: Stefan Farfeleder Date: Wed, 18 Jul 2007 12:39:47 -0600 User-Agent: KMail/1.8.2 References: <200707181206.52765.rh@matriplex.com> <20070718182657.GG975@lizard.fafoe.narf.at> In-Reply-To: <20070718182657.GG975@lizard.fafoe.narf.at> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707181239.52037.rh@matriplex.com> X-Authenticated-Sender: richard@hodges.org X-Spam-Processed: edurus.com, Wed, 18 Jul 2007 11:38:56 -0700 (not processed: message from trusted or authenticated source) X-MDRemoteIP: 72.36.38.114 X-Return-Path: rh@matriplex.com X-Envelope-From: rh@matriplex.com X-MDaemon-Deliver-To: freebsd-hackers@freebsd.org Cc: freebsd-hackers@freebsd.org Subject: Re: Rijndael sanity check? 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, 18 Jul 2007 18:38:56 -0000 On Wednesday 18 July 2007 12:26 pm, Stefan Farfeleder wrote: > On Wed, Jul 18, 2007 at 12:06:35PM -0600, Richard Hodges wrote: > > > ./aes_test > > > > Using key: 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c > > > > 920F0CE0A9A96BB9D8416962BDBBAA7C > > decr: 92 0f 0c e0 a9 a9 6b b9 d8 41 69 62 bd bb aa 7c > > encr: c9 3d 42 18 70 34 ce a8 67 1b 88 43 10 00 d1 8c > > ^^ > > > c74601001001000000000054006b51FF > > decr: c7 46 01 00 10 01 00 00 00 00 00 54 00 6b 51 ff > > encr: c9 3d 42 18 70 34 ce a8 67 1b 88 43 10 a2 d1 8c > > ^^ > It seems to be different. Good eye, and thanks! It did not occur to me that the difference would be so subtle as three bits, as I normally expect encryption to propagate even small bit differences across the entire block. Oops! Bad assumption! Now it looks like I have a bug to find in my own code, but that is so much better than suspecting a problem somewhere else! :) Thanks again, -Richard From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 18 18:53: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 A409816A41A for ; Wed, 18 Jul 2007 18:53:36 +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 907D213C4E7 for ; Wed, 18 Jul 2007 18:53:36 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 6908F1CC050; Wed, 18 Jul 2007 11:53:36 -0700 (PDT) Date: Wed, 18 Jul 2007 11:53:36 -0700 From: Jeremy Chadwick To: oxy Message-ID: <20070718185336.GA14375@eos.sc1.parodius.com> References: <469E524B.1010001@field.hu> <20070718181507.GA13344@eos.sc1.parodius.com> <469E5B8A.9070104@field.hu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <469E5B8A.9070104@field.hu> User-Agent: Mutt/1.5.15 (2007-04-06) Cc: freebsd-hackers@freebsd.org Subject: Re: ttyd0 permission denied problem 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, 18 Jul 2007 18:53:36 -0000 On Wed, Jul 18, 2007 at 08:27:22PM +0200, oxy wrote: > [root@bluebox /dev]# cu -l /dev/ttyd0 -s 115200 > Connected > > so my problem is minicom? how can i give permission for it? > when i did: 'chown uucp:dialer /dev/ttyd0' than it worked for > a couple minutes, than system changed back owner to root:wheel I don't use minicom, so I don't know. It does sound specific to that program, however. The permissions and ownership changing are probably induced by devfs or devfs.conf, but this is speculation on my part. Also, please do not remove the mailing list from your responses; it's good to provide details to everyone on the list so that others know where the problem is, and future mailing list searches can reveal clues. :-) Thanks. -- | 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 Wed Jul 18 19:42: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 0DA2416A412; Wed, 18 Jul 2007 19:42:12 +0000 (UTC) (envelope-from oxy@field.hu) Received: from green.field.hu (green.field.hu [217.20.130.28]) by mx1.freebsd.org (Postfix) with ESMTP id B9DE913C467; Wed, 18 Jul 2007 19:42:11 +0000 (UTC) (envelope-from oxy@field.hu) Received: from localhost (green.field.hu [217.20.130.28]) by green.field.hu (Postfix) with ESMTP id 837586D514; Wed, 18 Jul 2007 21:41:56 +0200 (CEST) X-Virus-Scanned: by Amavisd-new (Spamassassin+Razor2+Pyzor+DCC+Bayes db, Clamd Antivirus) at field.hu Received: from green.field.hu ([217.20.130.28]) by localhost (green.field.hu [217.20.130.28]) (amavisd-new, port 10024) with ESMTP id g7XpZ-WoOLTV; Wed, 18 Jul 2007 21:41:53 +0200 (CEST) Received: from [192.168.1.2] (dsl77-234-78-86.pool.tvnet.hu [77.234.78.86]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by green.field.hu (Postfix) with ESMTP id C240C6D515; Wed, 18 Jul 2007 21:41:52 +0200 (CEST) Message-ID: <469E6D0C.4020100@field.hu> Date: Wed, 18 Jul 2007 21:42:04 +0200 From: oxy User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Jeremy Chadwick References: <469E524B.1010001@field.hu> <20070718181507.GA13344@eos.sc1.parodius.com> <469E5B8A.9070104@field.hu> <20070718185336.GA14375@eos.sc1.parodius.com> In-Reply-To: <20070718185336.GA14375@eos.sc1.parodius.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@freebsd.org Subject: Re: ttyd0 permission denied problem 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, 18 Jul 2007 19:42:12 -0000 sorry, miss-clicked :) thanks for your help Jeremy Chadwick írta: > On Wed, Jul 18, 2007 at 08:27:22PM +0200, oxy wrote: >> [root@bluebox /dev]# cu -l /dev/ttyd0 -s 115200 >> Connected >> >> so my problem is minicom? how can i give permission for it? >> when i did: 'chown uucp:dialer /dev/ttyd0' than it worked for >> a couple minutes, than system changed back owner to root:wheel > > I don't use minicom, so I don't know. It does sound specific to > that program, however. > > The permissions and ownership changing are probably induced by devfs > or devfs.conf, but this is speculation on my part. > > Also, please do not remove the mailing list from your responses; > it's good to provide details to everyone on the list so that others > know where the problem is, and future mailing list searches can > reveal clues. :-) Thanks. > From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 18 20:56:50 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 5FD1C16A406 for ; Wed, 18 Jul 2007 20:56:50 +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 34CFE13C467 for ; Wed, 18 Jul 2007 20:56:49 +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 l6IKunq3051205; Wed, 18 Jul 2007 15:56:49 -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 l6IKun53051202; Wed, 18 Jul 2007 15:56:49 -0500 (CDT) (envelope-from stephen@math.missouri.edu) Date: Wed, 18 Jul 2007 15:56:49 -0500 (CDT) From: Stephen Montgomery-Smith To: ports@freebsd.org, hackers@freebsd.org Message-ID: <20070718154452.B3091@math.missouri.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: Problems with +CONTENTS being messed up by pkg_delete -f 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, 18 Jul 2007 20:56:50 -0000 If you "pkg_delete -f" a package and then install the port again (but after it has been bumped up a version), then the +CONTENTS of ports that require the original port will be incorrect. This apparently messes up programs like portmanager. There is a sense in which one should never do "pkg_delete -f" and expect /var/db/pkg to keep its integrety - on the other hand this is exactly what "make deinstall" does. My feeling is that the integrety of /var/db/pkg should be maintained across a "make deinstall" and subsequent "make install" of a bumped version of the port. This is my suggestion. When a "pkg_delete -f" is executed, it looks through +REQUIRED_BY of the port it is going to delete, and modifies the +CONTENTS file of each of them, replacing lines like @pkgdep xineramaproto-1.1.2 @comment DEPORIGIN:x11/xineramaproto to maybe something like @comment DELDEPORIGIN:x11/xineramaproto ("deleted dependency origin"). A subsequent "make install" of x11/xineramaproto should look through the +CONTENTS of all entries in /var/db/pkg and change these lines to something like @pkgdep xineramaproto-1.1.3 @comment DEPORIGIN:x11/xineramaproto A further benefit of this approach is that one could also accurately reconstruct the +REQUIRED_BY of the port just reinstalled - right now this is left empty and thus inaccurate. What do you guys think? I know I could write the code for this quite quickly, but I want some feedback before I work on it. Stephen From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 18 22:50: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 42AC016A403; Wed, 18 Jul 2007 22:50:37 +0000 (UTC) (envelope-from fbsd-hackers@mawer.org) Received: from webmail.icp-qv1-irony2.iinet.net.au (webmail.icp-qv1-irony2.iinet.net.au [203.59.1.107]) by mx1.freebsd.org (Postfix) with ESMTP id 8496213C4C4; Wed, 18 Jul 2007 22:50:36 +0000 (UTC) (envelope-from fbsd-hackers@mawer.org) Received: from 203-206-173-235.perm.iinet.net.au (HELO [10.24.1.1]) ([203.206.173.235]) by outbound.icp-qv1-irony-out2.iinet.net.au with ESMTP; 19 Jul 2007 06:50:34 +0800 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAPQ1nkbLzq3r/2dsb2JhbAAN X-IronPort-AV: i="4.16,552,1175443200"; d="scan'208"; a="162237212:sNHT9140826" Message-ID: <469E990C.4030007@mawer.org> Date: Thu, 19 Jul 2007 08:49:48 +1000 From: Antony Mawer User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Garrett Cooper References: <469D62D3.70908@math.missouri.edu> <469DAC63.3020708@mawer.org> <469DC4D7.5050102@u.washington.edu> In-Reply-To: <469DC4D7.5050102@u.washington.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ports@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Slight problem with make actual-package-depends with 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: Wed, 18 Jul 2007 22:50:37 -0000 On 18/07/2007 5:44 PM, Garrett Cooper wrote: > Antony Mawer wrote: >> On 18/07/2007 10:46 AM, Stephen Montgomery-Smith wrote: >>> I appreciate that most people won't have this problem, but it has >>> bitten me. >>> >>> After you have made and installed a port, but don't clean it, and >>> then made a bunch of other ports, if you go back to the original port >>> and then do "make package", then +CONTENTS can be a bit messed up for >>> the package. This is because the creation of other ports might >>> disturb _LIB_RUN_DEPENDS and might put in some extra entries in >>> +CONTENTS. >>> >>> This happens to me because I make all my ports on one machine and >>> then copy them as packages to other machines. Then on the other >>> machines, the structure of /var/db/pkg gets a bit messed up and >>> pkg_delete -r malfunctions. >>> >>> It seems to me that the cure is to slightly change "make >>> actual-package-depends" so that if the port is already installed, it >>> just uses +CONTENTS. >> >> I can't comment on the particular approach taken in your patch, but >> can certainly attest to experiencing the same problem and it being >> frustrating to identify what was going on. It was only after much >> hair-pulling that I discovered that doing a 'make clean' at the >> appropriate time before package building fixed the problem. >> >> Otherwise I was winding up with plenty of seemingly OK packages that >> were missing critical files (in this instance, various PHP5 extension >> ports that were "installing" but missing the actual .so files!) >> >> --Antony > > Installing ports registers them on the machine as packages, by > simulating a package install via stdin. Was that forgotten? > -Garrett The packages were definitely installed, by working through and doing "make install" on the desired ports... I was aiming to uninstall existing PHP5 packages on deployed servers, and then install from a freshly updated set. The new ports were successfully installed, but for whatever reason some of the packages created were missing the .so files. I removed all the installed packages, make clean'd everything, then started again and the next respin worked fine (without updating the ports tree). Unfortunately I can't recall the exact thing that solved it; I seem to recall a "make clean" was involved, but don't recall whether it was explicitly running one before or after a "make package", or whether it was *avoiding* running one...! --Antony From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 18 23:08:26 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 77FC716A40F for ; Wed, 18 Jul 2007 23:08:26 +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 57D9213C4B2 for ; Wed, 18 Jul 2007 23:08:26 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from hymn01.u.washington.edu (hymn01.u.washington.edu [140.142.8.55]) by mxout5.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.06) with ESMTP id l6IN8KNv003427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Jul 2007 16:08:21 -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 l6IN8Kdr006128; Wed, 18 Jul 2007 16:08:20 -0700 X-Auth-Received: from [192.55.52.3] by hymn01.u.washington.edu via HTTP; Wed, 18 Jul 2007 16:08:20 PDT Date: Wed, 18 Jul 2007 16:08:20 -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.2.304607, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.7.18.154033 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: freebsd-hackers@freebsd.org Subject: Re: Proposal for alleviating disk read / write time 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, 18 Jul 2007 23:08:26 -0000 On Wed, 18 Jul 2007, Ivan Voras wrote: > Garrett Cooper wrote: > >> Clarifications and comments are more than welcome. I really >> appreciate it. > > Hmm, your requirements look more and more like a... database? :) > > [whistling away...] I know. The only catch is that the last time I brought up databases it turned into a big discussion, where I got the following (paraphrased) opinions: 1. MySQL rules -- BDB sucks! 2. It'll be a cold day in %$#@ before SQL is included in the base system -- even SQL-Lite. 3. BDB isn't non-atomic and not stable. Unless something more constructive is going to be discussed, I'm not going to pursue that semi-bikeshed topic again. -Garrett From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 18 22: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 6ADB016A402 for ; Wed, 18 Jul 2007 22:40:14 +0000 (UTC) (envelope-from x0dapara@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.228]) by mx1.freebsd.org (Postfix) with ESMTP id 2640413C491 for ; Wed, 18 Jul 2007 22:40:14 +0000 (UTC) (envelope-from x0dapara@gmail.com) Received: by nz-out-0506.google.com with SMTP id l8so283019nzf for ; Wed, 18 Jul 2007 15:40:14 -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=TopHEri9Z6j4UTAuzsks/tJ2G21eG4lPSPp+fGr8RyYJ1lGnt5uS4FCquFs3p9Tsfhwe+u+WkVFcVxDIc8/bjydgsgBAUCpF8cYaDtZAO4wWS8OTzIyDsU+CCkECJv5/SeBJdxiUKxQgqkTR/l0yvG0gtXNYNHnxNK+SXLQIyso= 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=dUBxkEKNORz5vuaU4CaGxdaPiyjcwFRA+fzV0Cgm9kD4sfJu8glUByNTZmZBq70du+2hgfSRlMRRst39gxg7IhiJ49N54lDW/X+szJuQSHYwR0mOTBd6jKGQIhIejWcze5tQAV6kh2KgFQ/W2UXpNZCVJmOVAAO8QBo+uxfGDGI= Received: by 10.142.103.6 with SMTP id a6mr159973wfc.1184796778243; Wed, 18 Jul 2007 15:12:58 -0700 (PDT) Received: by 10.143.44.2 with HTTP; Wed, 18 Jul 2007 15:12:57 -0700 (PDT) Message-ID: <2f0146460707181512x3841af57l588e4d6e67bd5884@mail.gmail.com> Date: Wed, 18 Jul 2007 23:12:57 +0100 From: "Michael Vaughn" To: freebsd-questions@freebsd.org, freebsd-performance@freebsd.org, freebsd-hackers@freebsd.org MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 18 Jul 2007 23:43:43 +0000 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: FreeBSD 6.2-STABLE && apache 2.2.4 = bad performance. Help! 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, 18 Jul 2007 22:40:14 -0000 Hello everyone, I am contacting -performance, -questions, and -hackers in the hope someone helps me troubleshoot a problem with FreeBSD 6.2 and apache 2.2.4 uname: FreeBSD 6.2-STABLE Fri Jun 22 12:17:03 UTC 2007 amd64 installed php modules: php5-5.2.3 PHP Scripting Language (Apache Module and CLI) php5-gd-5.2.3 The gd shared extension for php php5-mysql-5.2.3 The mysql shared extension for php php5-pcre-5.2.3 The pcre shared extension for php php5-session-5.2.3 The session shared extension for php php5-simplexml-5.2.3 The simplexml shared extension for php php5-tokenizer-5.2.3 The tokenizer shared extension for php php5-xml-5.2.3 The xml shared extension for php apache version: apache-2.2.4_2 Version 2.2 of Apache web server with prefork MPM. system: real memory = 5100273664 (4864 MB) avail memory = 4120178688 (3929 MB) CPU: Intel(R) Xeon(TM) CPU 2.66GHz (2666.78-MHz K8-class CPU) Logical CPUs per core: 2 FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs The problem: Right after starting apache, the loads on the server will climb to 10-40's and the application will become unacceptably slow. This will go on until few users are using the said application. (note: other servers running older FreeBSD versions on dual cpus running the same code don't exhibit this system% problem) top shows more than 60% of the CPU time is spent on system: CPU states: 19.9% user, 0.0% nice, 73.7% system, 1.7% interrupt, 4.7% idle Mem: 398M Active, 2226M Inact, 253M Wired, 202M Cache, 214M Buf, 567M Free The apache processes look like: PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 56882 www 1 103 0 139M 17516K select 0 0:03 12.66% httpd 56862 www 1 100 0 139M 21168K CPU2 6 0:06 11.87% httpd 56830 www 1 99 0 138M 19684K select 2 0:09 10.76% httpd 56887 www 1 105 0 139M 17488K select 6 0:01 10.49% httpd 56852 www 1 99 0 138M 20352K select 4 0:06 10.26% httpd 56889 www 1 106 0 139M 17548K select 6 0:01 10.04% httpd 56894 www 1 109 0 139M 17024K select 6 0:01 9.79% httpd 56839 www 1 99 0 138M 21216K select 6 0:06 9.36% httpd 56866 www 1 99 0 138M 17664K select 6 0:04 9.36% httpd 56890 www 1 108 0 138M 16180K select 4 0:01 9.29% httpd 56848 www 1 99 0 138M 20460K select 2 0:06 9.27% httpd 56865 www 1 99 0 138M 18920K select 2 0:05 9.23% httpd 56883 www 1 102 0 138M 16744K select 4 0:02 8.99% httpd 56870 www 1 100 0 139M 18440K select 2 0:03 8.86% httpd 56850 www 1 98 0 138M 21284K select 6 0:05 8.84% httpd 56860 www 1 99 0 138M 19584K select 0 0:05 8.70% httpd 56864 www 1 99 0 139M 18028K select 2 0:04 8.23% httpd 56854 www 1 99 0 138M 20696K select 6 0:05 8.23% httpd 56853 www 1 98 0 138M 19564K select 4 0:06 8.11% httpd 56835 www 1 98 0 139M 20276K CPU6 4 0:07 8.10% httpd 56849 www 1 98 0 138M 19532K select 0 0:05 7.95% httpd 56851 www 1 98 0 139M 20252K select 4 0:05 7.35% httpd 56888 www 1 4 0 139M 17100K sbwait 6 0:01 7.31% httpd 56869 www 1 100 0 139M 18632K select 4 0:02 6.75% httpd 56861 www 1 98 0 139M 18404K select 0 0:04 6.58% httpd 56863 www 1 98 0 139M 20220K select 2 0:03 6.40% httpd 56867 www 1 99 0 138M 17452K select 6 0:03 6.39% httpd 56868 www 1 99 0 138M 18376K select 0 0:03 6.20% httpd 56893 www 1 107 0 138M 12964K select 0 0:00 5.62% httpd 56878 www 1 100 0 138M 16732K select 6 0:02 5.27% httpd 56881 www 1 100 0 138M 16288K select 6 0:01 2.18% httpd I had to lower MaxClients on apache substancially from 128 to 32, or loads would quickly go to 40+. (Other servers with dual cpus instead of quad and apache 1.3 on freebsd 6.0 don't have this problem) vmstat 1: procs memory page disks faults cpu r b w avm fre flt re pi po fr sr ad4 ad6 in sy cs us sy id 0 1 0 1380860 787212 1365 0 0 0 1312 1 0 0 486 559 842 13 22 65 1 1 0 1384588 787128 2724 0 0 0 2581 0 0 88 3038 82956 48776 19 38 43 4 1 0 1399232 782936 3328 0 0 0 2112 0 0 97 3592 101093 66497 24 50 26 0 1 2 1400200 781628 3726 0 0 0 2910 0 0 99 3529 100289 81531 23 58 19 19 1 0 1404000 778556 2263 0 0 0 1141 0 0 62 2964 73572 101432 19 76 5 15 1 1 1402452 776800 2499 0 0 0 1714 0 7 74 2965 68441 102276 19 78 3 15 1 0 1401548 777112 2213 0 0 0 2103 0 0 42 2491 105584 109418 15 79 6 8 1 1 1403324 778856 2606 0 0 0 2748 0 0 84 2996 75288 91676 22 76 2 0 1 3 1396864 781344 2764 0 0 0 3010 0 0 86 3393 90765 85952 25 70 5 1 2 0 1395520 782604 2774 0 0 0 2978 0 0 79 3195 88251 92623 20 63 17 6 1 0 1396096 781832 2641 0 0 0 2195 0 1 82 3347 96322 55942 21 42 37 iostat 1: tty ad4 ad6 ad8 cpu tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id 0 28 13.94 4 0.06 16.13 48 0.75 13.94 4 0.06 13 0 21 1 65 0 231 0.00 0 0.00 16.00 68 1.06 0.00 0 0.00 19 0 74 1 5 0 77 0.00 0 0.00 16.00 90 1.40 0.00 0 0.00 17 0 77 2 4 0 77 0.50 1 0.00 16.00 46 0.72 0.50 1 0.00 14 0 82 1 4 0 77 0.00 0 0.00 16.00 83 1.30 0.00 0 0.00 21 0 65 2 12 0 77 0.00 0 0.00 16.00 37 0.58 0.00 0 0.00 18 0 76 1 5 0 77 0.00 0 0.00 16.00 82 1.28 0.00 0 0.00 20 0 74 2 4 0 77 0.00 0 0.00 16.00 68 1.06 0.00 0 0.00 21 0 47 2 30 0 77 0.00 0 0.00 16.00 61 0.95 0.00 0 0.00 20 0 33 1 46 0 77 0.00 0 0.00 16.00 71 1.11 0.00 0 0.00 21 0 44 2 33 0 77 0.00 0 0.00 16.00 62 0.97 0.00 0 0.00 22 0 46 2 30 The kernel is custom built, with the following added (relevant) options: options PMAP_SHPGPERPROC=4096 options ACCEPT_FILTER_HTTP /boot/loader.conf: kern.maxproc=32768 kern.ipc.shmmni=4096 kern.ipc.shmseg=2048 kern.ipc.semmns=960 kern.ipc.semmni=160 kern.ipc.semume=160 kern.ipc.semmnu=480 mysqld is also running on this server, altough it never goes past 8-10% CPU usage. It is separated from apache on I/O, via jails and gmirror: mirror/gm0 COMPLETE ad4 ad8 mirror/gm1 COMPLETE ad6 ad10 Now this web application isn't the best code out there, but this is a quad cpu server and it's performing a lot worse than some servers I have running with 6.0 with apache 1.3 for over 400 days. Am I the only one getting terrible performance with apache2 on FreeBSD 6 ? p.s: cc me, I am not subscribed to any of the lists. Regards, Mark From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 18 23:11:04 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 0D76716A405; Wed, 18 Jul 2007 23:11:04 +0000 (UTC) (envelope-from rnoland@2hip.net) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id D015013C4E1; Wed, 18 Jul 2007 23:11:03 +0000 (UTC) (envelope-from rnoland@2hip.net) Received: from [63.251.67.21] (rnoland-ibm.acs.internap.com [63.251.67.21]) (authenticated bits=0) by gizmo.2hip.net (8.13.8/8.13.8) with ESMTP id l6IMotW2041387 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 18 Jul 2007 18:50:55 -0400 (EDT) (envelope-from rnoland@2hip.net) From: Robert Noland To: Stephen Montgomery-Smith In-Reply-To: <20070718154452.B3091@math.missouri.edu> References: <20070718154452.B3091@math.missouri.edu> Content-Type: text/plain Date: Wed, 18 Jul 2007 18:50:50 -0400 Message-Id: <1184799050.33981.66.camel@rnoland-ibm.acs.internap.com> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on gizmo.2hip.net X-Mailman-Approved-At: Wed, 18 Jul 2007 23:43:43 +0000 Cc: ports@freebsd.org, hackers@freebsd.org Subject: Re: Problems with +CONTENTS being messed up by pkg_delete -f 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, 18 Jul 2007 23:11:04 -0000 On Wed, 2007-07-18 at 15:56 -0500, Stephen Montgomery-Smith wrote: > If you "pkg_delete -f" a package and then install the port again (but > after it has been bumped up a version), then the +CONTENTS of ports that > require the original port will be incorrect. This apparently messes up > programs like portmanager. There is a sense in which one should never do > "pkg_delete -f" and expect /var/db/pkg to keep its integrety - on the > other hand this is exactly what "make deinstall" does. > > My feeling is that the integrety of /var/db/pkg should be maintained > across a "make deinstall" and subsequent "make install" of a bumped > version of the port. > > This is my suggestion. When a "pkg_delete -f" is executed, it looks > through +REQUIRED_BY of the port it is going to delete, and modifies the > +CONTENTS file of each of them, replacing lines like > @pkgdep xineramaproto-1.1.2 > @comment DEPORIGIN:x11/xineramaproto > > to maybe something like > @comment DELDEPORIGIN:x11/xineramaproto > > ("deleted dependency origin"). A subsequent "make install" of > x11/xineramaproto should look through the +CONTENTS of all entries in > /var/db/pkg and change these lines to something like > > @pkgdep xineramaproto-1.1.3 > @comment DEPORIGIN:x11/xineramaproto Hrm, not quite what I had in mind... I don't want to misrepresent that a port was built against a newer version of a dependency. What I was hoping for would be that a port when reinstalled would not list both the current version of a dependency as well as a previous version of the same origin (which it aquired via the +CONTENTS of some other direct dependency). It should only list the currently installed version of that origin. That way it is still possible to determine that the interim port was built against an older version. I just want the +CONTENTS file to accurately list the versions that a given port was built against. robert. > A further benefit of this approach is that one could also accurately > reconstruct the +REQUIRED_BY of the port just reinstalled - right now this > is left empty and thus inaccurate. > > What do you guys think? I know I could write the code for this quite > quickly, but I want some feedback before I work on it. > > Stephen > > _______________________________________________ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 19 00:47: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 A977F16A400 for ; Thu, 19 Jul 2007 00:47:48 +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 89B8913C471 for ; Thu, 19 Jul 2007 00:47:48 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from hymn01.u.washington.edu (hymn01.u.washington.edu [140.142.8.55]) by mxout5.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.06) with ESMTP id l6J0lmGe028907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 18 Jul 2007 17:47: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 l6J0llSP011839 for ; Wed, 18 Jul 2007 17:47:47 -0700 X-Auth-Received: from [192.55.52.3] by hymn01.u.washington.edu via HTTP; Wed, 18 Jul 2007 17:47:47 PDT Date: Wed, 18 Jul 2007 17:47:47 -0700 (PDT) From: youshi10@u.washington.edu To: hackers@freebsd.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.3.2.304607, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.7.18.172500 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: Proposal for alleviating disk read / write time 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, 19 Jul 2007 00:47:48 -0000 On Wed, 18 Jul 2007 youshi10@u.washington.edu wrote: > On Wed, 18 Jul 2007, Ivan Voras wrote: > >> Garrett Cooper wrote: >> >>> Clarifications and comments are more than welcome. I really >>> appreciate it. >> >> Hmm, your requirements look more and more like a... database? :) >> >> [whistling away...] > > I know. The only catch is that the last time I brought up databases it turned > into a big discussion, where I got the following (paraphrased) opinions: > > 1. MySQL rules -- BDB sucks! > 2. It'll be a cold day in %$#@ before SQL is included in the base system -- > even SQL-Lite. > 3. BDB isn't non-atomic and not stable. > > Unless something more constructive is going to be discussed, I'm not going to > pursue that semi-bikeshed topic again. > > -Garrett The other problem is that using a database technology in place of flat text files will force less intelligent tools without access to lower level DB manipulation APIs (portmaster for instance) to depend on other apps to do the data store translation legwork for them. But maybe that isn't a bad idea? -Garrett From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 19 02:36:04 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 743E516A408 for ; Thu, 19 Jul 2007 02:36:04 +0000 (UTC) (envelope-from stephen@math.missouri.edu) Received: from cauchy.math.missouri.edu (cauchy.math.missouri.edu [128.206.184.213]) by mx1.freebsd.org (Postfix) with ESMTP id 4033A13C4B2 for ; Thu, 19 Jul 2007 02:36:04 +0000 (UTC) (envelope-from stephen@math.missouri.edu) Received: from laptop2.gateway.2wire.net (cauchy.math.missouri.edu [128.206.184.213]) by cauchy.math.missouri.edu (8.14.1/8.13.4) with ESMTP id l6J2EjbT008815; Wed, 18 Jul 2007 21:14:45 -0500 (CDT) (envelope-from stephen@math.missouri.edu) Message-ID: <469EC915.7010006@math.missouri.edu> Date: Wed, 18 Jul 2007 21:14:45 -0500 From: Stephen Montgomery-Smith User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.4) Gecko/20070717 SeaMonkey/1.1.2 MIME-Version: 1.0 To: Robert Noland References: <20070718154452.B3091@math.missouri.edu> <1184799050.33981.66.camel@rnoland-ibm.acs.internap.com> In-Reply-To: <1184799050.33981.66.camel@rnoland-ibm.acs.internap.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ports@freebsd.org, hackers@freebsd.org Subject: Re: Problems with +CONTENTS being messed up by pkg_delete -f 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, 19 Jul 2007 02:36:04 -0000 Robert Noland wrote: > On Wed, 2007-07-18 at 15:56 -0500, Stephen Montgomery-Smith wrote: >> If you "pkg_delete -f" a package and then install the port again (but >> after it has been bumped up a version), then the +CONTENTS of ports that >> require the original port will be incorrect. This apparently messes up >> programs like portmanager. There is a sense in which one should never do >> "pkg_delete -f" and expect /var/db/pkg to keep its integrety - on the >> other hand this is exactly what "make deinstall" does. >> >> My feeling is that the integrety of /var/db/pkg should be maintained >> across a "make deinstall" and subsequent "make install" of a bumped >> version of the port. >> >> This is my suggestion. When a "pkg_delete -f" is executed, it looks >> through +REQUIRED_BY of the port it is going to delete, and modifies the >> +CONTENTS file of each of them, replacing lines like >> @pkgdep xineramaproto-1.1.2 >> @comment DEPORIGIN:x11/xineramaproto >> >> to maybe something like >> @comment DELDEPORIGIN:x11/xineramaproto >> >> ("deleted dependency origin"). A subsequent "make install" of >> x11/xineramaproto should look through the +CONTENTS of all entries in >> /var/db/pkg and change these lines to something like >> >> @pkgdep xineramaproto-1.1.3 >> @comment DEPORIGIN:x11/xineramaproto > > Hrm, not quite what I had in mind... I don't want to misrepresent that > a port was built against a newer version of a dependency. What I was > hoping for would be that a port when reinstalled would not list both the > current version of a dependency as well as a previous version of the > same origin (which it aquired via the +CONTENTS of some other direct > dependency). It should only list the currently installed version of > that origin. > > That way it is still possible to determine that the interim port was > built against an older version. I just want the +CONTENTS file to > accurately list the versions that a given port was built against. I think I was not understanding your problem, nor how portmanager works. Sorry about that. In general, I do really like how the present "actual-package-depends" works, and so I would rather see this kept, and portmanager modified to accomodate, rather than the other way around. Robert sent me some private emails about how "actual-package-depends" was messing up portmanager. Probably he should send the problem descriptions to the mailing lists, and maybe someone else could solve them. I thought I had some ideas for quick fixes, but it seems I was looking before I was leaping. I don't really have enough time right now for long fixes, so someone else will have to figure it out. I have to say that I simply don't use portmanager or portsinstall or anything like that, so I don't know how they work. (Rather I use my own home brew tools for doing the same thing, and since they are home brew and only for my use, they don't need to get everything right everytime, they can be simple, and they don't have to be at all user-friendly.) Best regards, Stephen From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 19 02:50: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 F3A2916A402 for ; Thu, 19 Jul 2007 02:50:58 +0000 (UTC) (envelope-from mv@thebeastie.org) Received: from p4.roq.com (ns1.ecoms.com [207.44.130.137]) by mx1.freebsd.org (Postfix) with ESMTP id CC0EC13C478 for ; Thu, 19 Jul 2007 02:50:58 +0000 (UTC) (envelope-from mv@thebeastie.org) Received: from p4.roq.com (localhost.roq.com [127.0.0.1]) by p4.roq.com (Postfix) with ESMTP id 4D2AF4CE61 for ; Thu, 19 Jul 2007 02:21:01 +0000 (GMT) Received: from smitch7.jumbuck.com (p82.jumbuck.com [206.112.99.82]) by p4.roq.com (Postfix) with ESMTP id 254DC4CE39 for ; Thu, 19 Jul 2007 02:21:01 +0000 (GMT) Received: from smitch7.jumbuck.com (mail.jumbuck.com [206.112.99.82]) by smitch7.jumbuck.com (Postfix) with ESMTP id 8F190410C8B; Thu, 19 Jul 2007 02:19:54 +0000 (UTC) Received: from beaste5.jumbuck.com (ppp198-18.static.internode.on.net [59.167.198.18]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by smitch7.jumbuck.com (Postfix) with ESMTP id 404F9410C06; Thu, 19 Jul 2007 02:19:54 +0000 (UTC) Received: from beaste5.jumbuck.com (beast5 [192.168.46.105]) by beaste5.jumbuck.com (Postfix) with ESMTP id 79EF0209D1A9; Thu, 19 Jul 2007 12:19:53 +1000 (EST) Received: from [192.168.46.102] (unknown [192.168.46.102]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by beaste5.jumbuck.com (Postfix) with ESMTP id 52EAD209D195; Thu, 19 Jul 2007 12:19:53 +1000 (EST) Message-ID: <469ECA49.8050101@thebeastie.org> Date: Thu, 19 Jul 2007 12:19:53 +1000 From: Michael Vince User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.8.1.4) Gecko/20070604 SeaMonkey/1.1.2 MIME-Version: 1.0 To: Julian Elischer References: <200706051149.45787.rapopp@eastcentral.edu> <4665B28A.7060608@elischer.org> In-Reply-To: <4665B28A.7060608@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-hackers@freebsd.org, rapopp@eastcentral.edu Subject: Re: kern.ngroups question 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, 19 Jul 2007 02:50:59 -0000 Julian Elischer wrote: > Reuben A. Popp wrote: >> Hello all, >> >> Can someone explain to me the rationale behind having ngroups_max set >> to 16 by default? >> > > NFS only supports this much by default (from memory). > > Samba (in the guise of Jeremy Allison) > has asked us to follow Linux's lead and support an arbitrary number of > Groups > but it hasn't happened yet, Partly due to the question of "what to do > about NFS" and partly just due to ENOTIME. I think at the very least that there should be some more obvious warnings about this potentially serious limitation in either release notes of FreeBSD and or Samba. I just had to deal with this limitation and it was quite annoying to say the least, it appears Samba is somewhat deliberately designed to give you a hard time when you run into this limit, because as soon as you add a user to more than 16 groups it declares the group file unreadable and as a security measure shuts down all shares and authentication which wrecks a network which relies on Samba. Also as far as I know Solaris and Linux has long gone past this limitation. Mike From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 19 01:44:27 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 B48DF16A400; Thu, 19 Jul 2007 01:44:27 +0000 (UTC) (envelope-from bsd-unix@earthlink.net) Received: from fall-lakeland.atl.sa.earthlink.net (fall-lakeland.atl.sa.earthlink.net [207.69.195.103]) by mx1.freebsd.org (Postfix) with ESMTP id 7A90013C4BB; Thu, 19 Jul 2007 01:44:27 +0000 (UTC) (envelope-from bsd-unix@earthlink.net) Received: from pop-satin.atl.sa.earthlink.net ([207.69.195.63]) by fall-lakeland.atl.sa.earthlink.net with esmtp (Exim 4.34) id 1IBIK9-0007Ql-UX; Wed, 18 Jul 2007 18:48:49 -0400 Received: from fl-76-1-181-252.dhcp.embarqhsd.net ([76.1.181.252] helo=kt.weeeble.com) by pop-satin.atl.sa.earthlink.net with smtp (Exim 3.36 #1) id 1IBIK7-0005PK-00; Wed, 18 Jul 2007 18:48:48 -0400 Date: Wed, 18 Jul 2007 18:48:46 -0400 From: Randy Pratt To: Stephen Montgomery-Smith Message-Id: <20070718184846.8a08e2f6.bsd-unix@earthlink.net> In-Reply-To: <20070718154452.B3091@math.missouri.edu> References: <20070718154452.B3091@math.missouri.edu> X-Mailer: Sylpheed 2.4.3 (GTK+ 2.10.14; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 19 Jul 2007 03:51:27 +0000 Cc: ports@freebsd.org, hackers@freebsd.org Subject: Re: Problems with +CONTENTS being messed up by pkg_delete -f 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, 19 Jul 2007 01:44:27 -0000 On Wed, 18 Jul 2007 15:56:49 -0500 (CDT) Stephen Montgomery-Smith wrote: > > If you "pkg_delete -f" a package and then install the port again (but > after it has been bumped up a version), then the +CONTENTS of ports that > require the original port will be incorrect. This apparently messes up > programs like portmanager. There is a sense in which one should never do > "pkg_delete -f" and expect /var/db/pkg to keep its integrety - on the > other hand this is exactly what "make deinstall" does. > > My feeling is that the integrety of /var/db/pkg should be maintained > across a "make deinstall" and subsequent "make install" of a bumped > version of the port. > > This is my suggestion. When a "pkg_delete -f" is executed, it looks > through +REQUIRED_BY of the port it is going to delete, and modifies the > +CONTENTS file of each of them, replacing lines like > @pkgdep xineramaproto-1.1.2 > @comment DEPORIGIN:x11/xineramaproto > > to maybe something like > @comment DELDEPORIGIN:x11/xineramaproto > > ("deleted dependency origin"). A subsequent "make install" of > x11/xineramaproto should look through the +CONTENTS of all entries in > /var/db/pkg and change these lines to something like > > @pkgdep xineramaproto-1.1.3 > @comment DEPORIGIN:x11/xineramaproto > > A further benefit of this approach is that one could also accurately > reconstruct the +REQUIRED_BY of the port just reinstalled - right now this > is left empty and thus inaccurate. > > What do you guys think? I know I could write the code for this quite > quickly, but I want some feedback before I work on it. I've not read this thread in detail but I think "pkgdb -L" could be of use in this situation. It will check and restore lost dependencies against the ports tree. It has worked for me on several occasions. As far as package set creation for distribution on my systems, I use the "pkg_create -b" instead of "make package". I have only used "make package" to check a port that is being created for local use (as per Porters Handbook). Just ignore me if I've misunderstood the thread ;-) Randy -- From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 19 07:30:27 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 2720F16A400; Thu, 19 Jul 2007 07:30:27 +0000 (UTC) (envelope-from helge.oldach@atosorigin.com) Received: from smtp1.mail.atosorigin.com (smtp1.mail.atosorigin.com [160.92.103.80]) by mx1.freebsd.org (Postfix) with ESMTP id ACC3A13C4B6; Thu, 19 Jul 2007 07:30:26 +0000 (UTC) (envelope-from helge.oldach@atosorigin.com) Received: from filter.atosorigin.com (localhost [127.0.0.1]) by mxfed001 (Postfix) with ESMTP id 630EB26396CB; Thu, 19 Jul 2007 09:02:40 +0200 (CEST) Received: from miram.origin-it.net (mail.de.atosorigin.com [194.8.96.226]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by mxfed001 (Postfix) with ESMTP id 37AC726396C6; Thu, 19 Jul 2007 09:02:40 +0200 (CEST) Received: from markab.hbg.de.int.atosorigin.com (avior.origin-it.net [213.70.176.177]) by miram.origin-it.net (8.14.1/8.14.1/hmo020206) with ESMTP id l6J72dOa068427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Jul 2007 09:02:39 +0200 (CEST) (envelope-from helge.oldach@atosorigin.com) Received: from DEHHX001.deuser.de.intra (dehhx001.hbg.de.int.atosorigin.com [161.90.164.121]) by markab.hbg.de.int.atosorigin.com (8.14.1/8.14.1/hmo020206) with ESMTP id l6J72cFk015081; Thu, 19 Jul 2007 09:02:38 +0200 (CEST) (envelope-from helge.oldach@atosorigin.com) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 19 Jul 2007 09:02:33 +0200 Message-ID: <39AFDF50473FED469B15B6DFF2262F7A03070D27@DEHHX001.deuser.de.intra> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Problems with +CONTENTS being messed up by pkg_delete -f Thread-Index: AcfJfkoBUDvvCXMdRYGBoenPARk+yAAUvekg References: <20070718154452.B3091@math.missouri.edu> From: To: , , X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (miram.origin-it.net [194.8.96.226]); Thu, 19 Jul 2007 09:02:39 +0200 (CEST) X-Bogolevel: not-spam X-fed-spamrating: 0.055155 Cc: Subject: RE: Problems with +CONTENTS being messed up by pkg_delete -f 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, 19 Jul 2007 07:30:27 -0000 Stephen Montgomery-Smith: > If you "pkg_delete -f" a package and then install the port again (but > after it has been bumped up a version), then the +CONTENTS of ports = that > require the original port will be incorrect. This apparently messes = up > programs like portmanager. There is a sense in which one should never = do > "pkg_delete -f" and expect /var/db/pkg to keep its integrety - on the > other hand this is exactly what "make deinstall" does. >=20 > My feeling is that the integrety of /var/db/pkg should be maintained > across a "make deinstall" and subsequent "make install" of a bumped > version of the port.=20 The tricky point is when the dependencies change with a version bump. It = will also be difficult if the user changes "make config" options (which = commonly affect dependencies - consider my favorite WITHOUT_NLS knob) and = reinstalls. My feeling is that tackling this with a general solution would be nice = to have - but the details and corner cases are pretty difficult. > A further benefit of this approach is that one could also accurately > reconstruct the +REQUIRED_BY of the port just reinstalled - right now = this > is left empty and thus inaccurate. Well. This is true, but on the other hand +REQUIRED_BY basically just = duplicates information that we already have in the ports tree. Most ports = management packages that we have (including my homegrown perl script) don't rely on information contained in +REQUIRED_BY, but just start with what is = already in the ports tree. Which leads to the question whether +REQUIRED_BY is still of much value = at all... Helge Atos Origin GmbH, Theodor-Althoff-Str. 47, D-45133 Essen, Postfach 100 123, D-45001 Essen Telefon: +49 201 4305 0, Fax: +49 201 4305 689095, www.atosorigin.de Dresdner Bank AG, Hamburg: Kto. 0954411200, BLZ 200 800 00, Swift Code DRESDEFF200, IBAN DE69200800000954411200 Geschäftsführer: Dominique Illien, Handelsregister Essen HRB 19354, Ust.-ID.-Nr.: DE147861238 From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 19 07:14: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 5D47B16A401; Thu, 19 Jul 2007 07:14:47 +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 10C2B13C494; Thu, 19 Jul 2007 07:14:47 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A56A79.dip.t-dialin.net [84.165.106.121]) by redbull.bpaserver.net (Postfix) with ESMTP id 8FCA62E173; Thu, 19 Jul 2007 09:14:39 +0200 (CEST) Received: from deskjail (deskjail.Leidinger.net [192.168.1.109]) by outgoing.leidinger.net (Postfix) with ESMTP id A8F4D5B5B7F; Thu, 19 Jul 2007 09:12:27 +0200 (CEST) Date: Thu, 19 Jul 2007 09:16:17 +0200 From: Alexander Leidinger To: Stephen Montgomery-Smith Message-ID: <20070719091617.3c10cc53@deskjail> In-Reply-To: <469E20D8.2020408@math.missouri.edu> References: <469D62D3.70908@math.missouri.edu> <20070718111920.43c198e3@deskjail> <469E20D8.2020408@math.missouri.edu> X-Mailer: Claws Mail 2.9.2 (GTK+ 2.10.13; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-14.9, required 8, BAYES_00 -15.00, DKIM_POLICY_SIGNSOME 0.00, RDNS_DYNAMIC 0.10) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No X-Mailman-Approved-At: Thu, 19 Jul 2007 13:04:48 +0000 Cc: ports@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Slight problem with make actual-package-depends with 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, 19 Jul 2007 07:14:47 -0000 Quoting Stephen Montgomery-Smith (Wed, 18 Jul 2007 09:16:56 -0500): > Alexander Leidinger wrote: > > Quoting Stephen Montgomery-Smith (Tue, 17 Jul 2007 19:46:11 -0500): > >> It seems to me that the cure is to slightly change "make > >> actual-package-depends" so that if the port is already installed, it > >> just uses +CONTENTS. > > > > This is wrong. What if you have a port installed and you want to > > rebuild the same version with other OPTIONS which changes the +CONTENTS > > file? If I read your patch right, it will use the wrong contents... > > You cannot install the port until you have first deinstalled it (unless > you use some kind of "FORCE" option, and it is reasonable that this > would mess things up). Thus at installation time, +CONTENTS will never > exist. > > But I take your point if perhaps you do need to use some kind of FORCE > option. Yes, sorry for not being clear. Sometimes I use FORCE_PKG_REGISTER in case I really know what I'm doing. With the change you proposed, this would be only ok, if you install the port with the same options again, but not when you install with options which change the plist. Bye, Alexander. -- 1) You can't win 2) You can't break even 3) You can't even quit the game 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 Thu Jul 19 07:18:24 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 9E68A16A40F; Thu, 19 Jul 2007 07:18:24 +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 2A65313C4C6; Thu, 19 Jul 2007 07:18:24 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A56A79.dip.t-dialin.net [84.165.106.121]) by redbull.bpaserver.net (Postfix) with ESMTP id D6E2C2E23E; Thu, 19 Jul 2007 09:18:14 +0200 (CEST) Received: from deskjail (deskjail.Leidinger.net [192.168.1.109]) by outgoing.leidinger.net (Postfix) with ESMTP id DF7E45B5B7F; Thu, 19 Jul 2007 09:16:02 +0200 (CEST) Date: Thu, 19 Jul 2007 09:19:52 +0200 From: Alexander Leidinger To: Stephen Montgomery-Smith Message-ID: <20070719091952.71a9e26e@deskjail> In-Reply-To: <469E2DB3.8080605@math.missouri.edu> References: <469D62D3.70908@math.missouri.edu> <20070718111920.43c198e3@deskjail> <469E2DB3.8080605@math.missouri.edu> X-Mailer: Claws Mail 2.9.2 (GTK+ 2.10.13; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-14.9, required 8, BAYES_00 -15.00, DKIM_POLICY_SIGNSOME 0.00, RDNS_DYNAMIC 0.10) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No X-Mailman-Approved-At: Thu, 19 Jul 2007 13:04:48 +0000 Cc: ports@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Slight problem with make actual-package-depends with 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, 19 Jul 2007 07:18:24 -0000 Quoting Stephen Montgomery-Smith (Wed, 18 Jul 2007 10:11:47 -0500): > Alexander Leidinger wrote: > > Quoting Stephen Montgomery-Smith (Tue, 17 Jul 2007 19:46:11 -0500): > > > >> I appreciate that most people won't have this problem, but it has bitten me. > >> > >> After you have made and installed a port, but don't clean it, and then > >> made a bunch of other ports, if you go back to the original port and > >> then do "make package", then +CONTENTS can be a bit messed up for the > >> package. This is because the creation of other ports might disturb > > > > Can you please give an example what "messed up" means in this context, > > e.g. post a diff between a good an a bad contents file? And what > > actions you did to get this difference? > > > >> _LIB_RUN_DEPENDS and might put in some extra entries in +CONTENTS. > > > > You mean that if you create a leaf package and then rebuild a package > > which is in the middle of the dependency tree with options which change > > the dependency graph of the leaf package you get problems? > > > > If yes: this has to be expected. You need to rebuild the packages in > > the right order. > > In other words, you have to perform the "make package" right after the > "make install" before you install any other ports. Otherwise you have > to use "pkg_create -b" (which I have recently started doing). I think the old version of getting the package dependency should fail in a similar way if you don't issue "make package" before installing other ports (where you change the options in a way that the dependency list changes). > >> This happens to me because I make all my ports on one machine and then > >> copy them as packages to other machines. Then on the other machines, > >> the structure of /var/db/pkg gets a bit messed up and pkg_delete -r > >> malfunctions. > > > > I have a lot of jails where I use the packages build in other jails. I > > haven't seen a problem there. The package install doesn't change the > > +CONTENTS files, so /var/db/pkg should be messed up on the build > > machine too... > > > >> It seems to me that the cure is to slightly change "make > >> actual-package-depends" so that if the port is already installed, it > >> just uses +CONTENTS. > > > > This is wrong. What if you have a port installed and you want to > > rebuild the same version with other OPTIONS which changes the +CONTENTS > > file? If I read your patch right, it will use the wrong contents... > > The other option (to allow the users to do "make package" much later > than "make install") would be to have two different > actual-package-depends, one for "make install", and the other for "make > package." It may be good to compare the way you do the package creation by hand with the way bsd.port.mk is doing it. Maybe something can be improved... Bye, Alexander. -- You can search for documentation on a keyword by typing apropos keyword 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 Thu Jul 19 14:56: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 ADC6316A402 for ; Thu, 19 Jul 2007 14:56:55 +0000 (UTC) (envelope-from mail25@bzerk.org) Received: from ei.bzerk.org (ei.xs4all.nl [82.95.223.12]) by mx1.freebsd.org (Postfix) with ESMTP id 3D4FD13C491 for ; Thu, 19 Jul 2007 14:56:55 +0000 (UTC) (envelope-from mail25@bzerk.org) Received: from ei.bzerk.org (BOFH@localhost [127.0.0.1]) by ei.bzerk.org (8.13.8/8.13.8) with ESMTP id l6JEX8j6009169; Thu, 19 Jul 2007 16:33:08 +0200 (CEST) (envelope-from mail25@bzerk.org) Received: (from bulk@localhost) by ei.bzerk.org (8.13.8/8.13.8/Submit) id l6JEX7AS009168; Thu, 19 Jul 2007 16:33:07 +0200 (CEST) (envelope-from mail25@bzerk.org) Date: Thu, 19 Jul 2007 16:33:07 +0200 From: Ruben de Groot To: Michael Vince Message-ID: <20070719143307.GA8861@ei.bzerk.org> Mail-Followup-To: Ruben de Groot , Michael Vince , Julian Elischer , freebsd-hackers@freebsd.org, rapopp@eastcentral.edu References: <200706051149.45787.rapopp@eastcentral.edu> <4665B28A.7060608@elischer.org> <469ECA49.8050101@thebeastie.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <469ECA49.8050101@thebeastie.org> User-Agent: Mutt/1.4.2.2i X-Spam-Status: No, score=-4.1 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, J_CHICKENPOX_47 autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on ei.bzerk.org X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (ei.bzerk.org [127.0.0.1]); Thu, 19 Jul 2007 16:33:11 +0200 (CEST) X-Mailman-Approved-At: Thu, 19 Jul 2007 15:07:33 +0000 Cc: freebsd-hackers@freebsd.org, Julian Elischer , rapopp@eastcentral.edu Subject: Re: kern.ngroups question 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, 19 Jul 2007 14:56:55 -0000 On Thu, Jul 19, 2007 at 12:19:53PM +1000, Michael Vince typed: > > I just had to deal with this limitation and it was quite annoying to say > the least, it appears Samba is somewhat deliberately designed to give > you a hard time when you run into this limit, because as soon as you add > a user to more than 16 groups it declares the group file unreadable and > as a security measure shuts down all shares and authentication which > wrecks a network which relies on Samba. > > Also as far as I know Solaris and Linux has long gone past this limitation. Linux maybe, but not Solaris: $ uname -sr SunOS 5.10 $ grep groups /usr/include/limits.h #define NGROUPS_MAX 16 /* max number of groups for a user */ cheers, Ruben > Mike > > > _______________________________________________ > 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" From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 19 16:08: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 F2E3216A401 for ; Thu, 19 Jul 2007 16:08:39 +0000 (UTC) (envelope-from rapopp@eastcentral.edu) Received: from ecmail.eastcentral.edu (ecmail.eastcentral.edu [198.209.216.1]) by mx1.freebsd.org (Postfix) with ESMTP id D252913C46B for ; Thu, 19 Jul 2007 16:08:39 +0000 (UTC) (envelope-from rapopp@eastcentral.edu) Received: from barbados.eastcentral.edu (unknown [10.15.0.132]) by ecmail.eastcentral.edu (Postfix) with ESMTP id 1E9F339949; Thu, 19 Jul 2007 10:51:13 -0500 (CDT) From: "Reuben A. Popp" To: Michael Vince Date: Thu, 19 Jul 2007 10:54:00 -0500 User-Agent: KMail/1.9.4 References: <200706051149.45787.rapopp@eastcentral.edu> <4665B28A.7060608@elischer.org> <469ECA49.8050101@thebeastie.org> In-Reply-To: <469ECA49.8050101@thebeastie.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707191054.02109.rapopp@eastcentral.edu> X-Mailman-Approved-At: Thu, 19 Jul 2007 16:26:01 +0000 Cc: freebsd-hackers@freebsd.org, Julian Elischer Subject: Re: kern.ngroups question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rapopp@eastcentral.edu List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2007 16:08:40 -0000 On Wednesday 18 July 2007 21:19, Michael Vince wrote: > Julian Elischer wrote: > > Reuben A. Popp wrote: > >> Hello all, > >> > >> Can someone explain to me the rationale behind having ngroups_max set > >> to 16 by default? > > > > NFS only supports this much by default (from memory). > > > > Samba (in the guise of Jeremy Allison) > > has asked us to follow Linux's lead and support an arbitrary number of > > Groups > > but it hasn't happened yet, Partly due to the question of "what to do > > about NFS" and partly just due to ENOTIME. > > I think at the very least that there should be some more obvious > warnings about this potentially serious limitation in either release > notes of FreeBSD and or Samba. > > I just had to deal with this limitation and it was quite annoying to say > the least, it appears Samba is somewhat deliberately designed to give > you a hard time when you run into this limit, because as soon as you add > a user to more than 16 groups it declares the group file unreadable and > as a security measure shuts down all shares and authentication which > wrecks a network which relies on Samba. > > Also as far as I know Solaris and Linux has long gone past this limitation. > > Mike Running into a problem nearly identical to Mike's is what caused me to start researching ngroups in the first place. Granted, in our Samba implementation, there isn't really anyone who hits the limitation (short of the admin), but the problem is still a definite show stopper. I imagine this will become even more of an issue once Samba 4.x is completed and sees deployment. Maybe this weekend I can write a small blurb for the handbook I guess the next question I have would be about the limit in NFS. I did a little sleuthing and found out that the actual culprit is not necessarily NFS, but the underlying RPC calls. IF I'm reading this correctly (excuse me if I'm wrong.. I'm just now getting my feet wet with c/c++), the limit is set in the auth_unix structure (taken from RFC 1057): struct auth_unix { unsigned int stamp; string machinename<255>; unsigned int uid; unsigned int gid; unsigned int gids<16>; }; If the value for gids were to be changed, that obviously would mean that the RPC implementation would be out of whack with the standard. How then are the other *nixes getting around this issue? Thanks again Reuben A. Popp Just a note: As I said above, I'm still just now getting my feet wet in any kind of programming (other than shell scripting). If I make an incorrect assumption or a pretty stupid mistake, all I ask is to be kind :) -- Reuben A. Popp Systems Administrator Information Technology Department East Central College 1+ 636 583 5195 x2480 From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 19 22:47: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 5576A16A407 for ; Thu, 19 Jul 2007 22:47:29 +0000 (UTC) (envelope-from scubacuda@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.234]) by mx1.freebsd.org (Postfix) with ESMTP id 14D4813C49D for ; Thu, 19 Jul 2007 22:47:28 +0000 (UTC) (envelope-from scubacuda@gmail.com) Received: by nz-out-0506.google.com with SMTP id l8so570482nzf for ; Thu, 19 Jul 2007 15:47: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:reply-to:to:subject:mime-version:content-type; b=Oyil3rLfFFMFM18COheZ4rQjxVEqFyPYYOfpNiBhgdGpT8tdEF6ympC3mQgzH97/DFqEVxC98OhEmnzyju3uo+UJlyr0cTdWtIsFjPuxOQqFfHbSvlFI1IvL3CwCN7NkIAOSnSK+rALiG/u6/2W4PmKEd37Gkn+faPHqOlw/UA0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type; b=lwfqKYYaeHZ/usVmsb/YnL70aBnkL+F0aE8VS0dazwVlOgID+cMP7U4Tn8kp8aZkXw/7g47DWTX2iX40HrRmgnzPwtL8G9Z5+OPhKOQwmTNJVcLEKF9Q3zPmRZBb2B0B7r8RHzMxb29Z2vTiZj13BGP/fgS+Ma3Yn3GOLrBK0A8= Received: by 10.115.79.1 with SMTP id g1mr3044662wal.1184885247205; Thu, 19 Jul 2007 15:47:27 -0700 (PDT) Received: by 10.114.149.17 with HTTP; Thu, 19 Jul 2007 15:47:27 -0700 (PDT) Message-ID: <2b7af7c40707191547x1dd0b7c9w3b2d776461b81589@mail.gmail.com> Date: Thu, 19 Jul 2007 15:47:27 -0700 From: "Rogelio Bastardo" To: freebsd-hackers@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 Subject: change control on FreeBSD servers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: scubacuda@gmail.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2007 22:47:29 -0000 I'm looking for some sort of change control solution. On several Cacti/Nagios servers, I would like to take a snapshot of what I did, back it up, and if something changes, run something that shows me what files / permissions were changed since I last worked on the server. If it were just me, then I would just make copies of the files. But since there are other people in there doing all sorts of weird configs, I want to make sure that I document what they did since I last logged in. Any suggestions would be greatly appreciated. From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 20 00:20:33 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 278B316A417 for ; Fri, 20 Jul 2007 00:20:33 +0000 (UTC) (envelope-from raj@csub.edu) Received: from mailhub.csub.edu (mailhub.csub.edu [136.168.1.56]) by mx1.freebsd.org (Postfix) with ESMTP id 04DAC13C459 for ; Fri, 20 Jul 2007 00:20:32 +0000 (UTC) (envelope-from raj@csub.edu) Received: from cserv65.csub.edu (cserv65.csub.edu [136.168.10.65]) (authenticated bits=0) by mailhub.csub.edu (8.13.8/8.13.8) with ESMTP id l6JNmVsP067212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Jul 2007 16:48:31 -0700 (PDT) (envelope-from raj@csub.edu) Message-ID: <469FF84F.6020707@csub.edu> Date: Thu, 19 Jul 2007 16:48:31 -0700 From: Russell Jackson User-Agent: Thunderbird 2.0.0.4 (X11/20070717) MIME-Version: 1.0 To: scubacuda@gmail.com References: <2b7af7c40707191547x1dd0b7c9w3b2d776461b81589@mail.gmail.com> In-Reply-To: <2b7af7c40707191547x1dd0b7c9w3b2d776461b81589@mail.gmail.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080300060808020309050906" Cc: freebsd-hackers@freebsd.org Subject: Re: change control on FreeBSD servers 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, 20 Jul 2007 00:20:33 -0000 This is a cryptographically signed message in MIME format. --------------ms080300060808020309050906 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Rogelio Bastardo wrote: > I'm looking for some sort of change control solution. On several > Cacti/Nagios servers, I would like to take a snapshot of what I did, back it > up, and if something changes, run something that shows me what files / > permissions were changed since I last worked on the server. > > If it were just me, then I would just make copies of the files. But since > there are other people in there doing all sorts of weird configs, I want to > make sure that I document what they did since I last logged in. > If it's plain text, stick everything in CVS/Subversion and use cfengine/puppet/commit-hook to push changes out. Cacti uses MySQL for configuration; I'm not sure what to do about that. -- Russell A. Jackson Network Analyst California State University, Bakersfield Tonight you will pay the wages of sin; Don't forget to leave a tip. --------------ms080300060808020309050906 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILzDCC BeIwggTKoAMCAQICChEYRCsAAAAADREwDQYJKoZIhvcNAQEFBQAwUTETMBEGCgmSJomT8ixk ARkWA2VkdTEUMBIGCgmSJomT8ixkARkWBGNzdWIxEjAQBgoJkiaJk/IsZAEZFgJhZDEQMA4G A1UEAxMHYWQtY3N1YjAeFw0wNzAyMjAwMDAyNDJaFw0wODAyMjAwMDAyNDJaMIGAMRMwEQYK CZImiZPyLGQBGRYDZWR1MRQwEgYKCZImiZPyLGQBGRYEY3N1YjESMBAGCgmSJomT8ixkARkW AmFkMQ4wDAYDVQQDEwVVc2VyczESMBAGA1UEAxMJcmphY2tzb24zMRswGQYJKoZIhvcNAQkB FgxyYWpAY3N1Yi5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAK7yJnIQLPM0LkRL XWhWTTKPeiXX8iMzsuxjzOBaZUzR3uNcmSPBo2Xvuq80jEAbhcOTjfGMkGYL3mVVEWuLqYtF QDHiUxN1aqC+8NCHxZyPXczQOL+3pPJyQgLsqi6RuamYpnrgjrShSwfbanTLvBeqxzw0Ju3t bGHBNPhiao8PAgMBAAGjggMOMIIDCjALBgNVHQ8EBAMCBaAwNgYJKoZIhvcNAQkPBCkwJzAN BggqhkiG9w0DAgIBODANBggqhkiG9w0DBAIBODAHBgUrDgMCBzAdBgNVHQ4EFgQULSptv9XA 3aFTWIMBzTPVEx8qf5cwFwYJKwYBBAGCNxQCBAoeCABVAHMAZQByMB8GA1UdIwQYMBaAFHiI nPYST6Rc1KuvHYS3uc+3Sl6JMIHzBgNVHR8EgeswgegwgeWggeKggd+Gga1sZGFwOi8vL0NO PWFkLWNzdWIsQ049YWQyLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1T ZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWFkLERDPWNzdWIsREM9ZWR1P2NlcnRpZmlj YXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2lu dIYtaHR0cDovL2FkMi5hZC5jc3ViLmVkdS9DZXJ0RW5yb2xsL2FkLWNzdWIuY3JsMIIBBwYI KwYBBQUHAQEEgfowgfcwgakGCCsGAQUFBzAChoGcbGRhcDovLy9DTj1hZC1jc3ViLENOPUFJ QSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0 aW9uLERDPWFkLERDPWNzdWIsREM9ZWR1P2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MEkGCCsGAQUFBzAChj1odHRwOi8vYWQyLmFkLmNz dWIuZWR1L0NlcnRFbnJvbGwvYWQyLmFkLmNzdWIuZWR1X2FkLWNzdWIuY3J0MCkGA1UdJQQi MCAGCisGAQQBgjcKAwQGCCsGAQUFBwMEBggrBgEFBQcDAjA+BgNVHREENzA1oCUGCisGAQQB gjcUAgOgFwwVcmphY2tzb24zQGFkLmNzdWIuZWR1gQxyYWpAY3N1Yi5lZHUwDQYJKoZIhvcN AQEFBQADggEBAEnGoKETs7b3xz0ecwk0MKGHipy8zFEeGkv3kHSCRP/0YUBciYgT4q/zAikU v9jfYTKsA9jD/0MeChHh3AYsG7RCZ+n6tZLTfhomXyC7EbiPkl2NxW+r2DE6L3JrNf7kCJqz jxdQeoY6EGx8IC4KV+zhrMaaYSv4wxGevm4kl69yJflBVwlJ2MR/5opdoyHSiJN6ogY10Imp JnvvR0KIt+5jHrWCeTqxeH4HCPqNCPxdbPxx0S1NAYg/Jyjcz5+4iRhwqWowtgzPo3uZV4+/ 0eOVPBXS50MLE+yuPghIqJjEF3kJ2ZvoCbZnM8pBDIs6e2qk2Fe3VdxtmpulhqCYJoswggXi MIIEyqADAgECAgoRGEQrAAAAAA0RMA0GCSqGSIb3DQEBBQUAMFExEzARBgoJkiaJk/IsZAEZ FgNlZHUxFDASBgoJkiaJk/IsZAEZFgRjc3ViMRIwEAYKCZImiZPyLGQBGRYCYWQxEDAOBgNV BAMTB2FkLWNzdWIwHhcNMDcwMjIwMDAwMjQyWhcNMDgwMjIwMDAwMjQyWjCBgDETMBEGCgmS JomT8ixkARkWA2VkdTEUMBIGCgmSJomT8ixkARkWBGNzdWIxEjAQBgoJkiaJk/IsZAEZFgJh ZDEOMAwGA1UEAxMFVXNlcnMxEjAQBgNVBAMTCXJqYWNrc29uMzEbMBkGCSqGSIb3DQEJARYM cmFqQGNzdWIuZWR1MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCu8iZyECzzNC5ES11o Vk0yj3ol1/IjM7LsY8zgWmVM0d7jXJkjwaNl77qvNIxAG4XDk43xjJBmC95lVRFri6mLRUAx 4lMTdWqgvvDQh8Wcj13M0Di/t6TyckIC7KoukbmpmKZ64I60oUsH22p0y7wXqsc8NCbt7Wxh wTT4YmqPDwIDAQABo4IDDjCCAwowCwYDVR0PBAQDAgWgMDYGCSqGSIb3DQEJDwQpMCcwDQYI KoZIhvcNAwICATgwDQYIKoZIhvcNAwQCATgwBwYFKw4DAgcwHQYDVR0OBBYEFC0qbb/VwN2h U1iDAc0z1RMfKn+XMBcGCSsGAQQBgjcUAgQKHggAVQBzAGUAcjAfBgNVHSMEGDAWgBR4iJz2 Ek+kXNSrrx2Et7nPt0peiTCB8wYDVR0fBIHrMIHoMIHloIHioIHfhoGtbGRhcDovLy9DTj1h ZC1jc3ViLENOPWFkMixDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2Vy dmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1hZCxEQz1jc3ViLERDPWVkdT9jZXJ0aWZpY2F0 ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSG LWh0dHA6Ly9hZDIuYWQuY3N1Yi5lZHUvQ2VydEVucm9sbC9hZC1jc3ViLmNybDCCAQcGCCsG AQUFBwEBBIH6MIH3MIGpBggrBgEFBQcwAoaBnGxkYXA6Ly8vQ049YWQtY3N1YixDTj1BSUEs Q049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlv bixEQz1hZCxEQz1jc3ViLERDPWVkdT9jQUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9 Y2VydGlmaWNhdGlvbkF1dGhvcml0eTBJBggrBgEFBQcwAoY9aHR0cDovL2FkMi5hZC5jc3Vi LmVkdS9DZXJ0RW5yb2xsL2FkMi5hZC5jc3ViLmVkdV9hZC1jc3ViLmNydDApBgNVHSUEIjAg BgorBgEEAYI3CgMEBggrBgEFBQcDBAYIKwYBBQUHAwIwPgYDVR0RBDcwNaAlBgorBgEEAYI3 FAIDoBcMFXJqYWNrc29uM0BhZC5jc3ViLmVkdYEMcmFqQGNzdWIuZWR1MA0GCSqGSIb3DQEB BQUAA4IBAQBJxqChE7O298c9HnMJNDChh4qcvMxRHhpL95B0gkT/9GFAXImIE+Kv8wIpFL/Y 32EyrAPYw/9DHgoR4dwGLBu0Qmfp+rWS034aJl8guxG4j5JdjcVvq9gxOi9yazX+5Aias48X UHqGOhBsfCAuClfs4azGmmEr+MMRnr5uJJevciX5QVcJSdjEf+aKXaMh0oiTeqIGNdCJqSZ7 70dCiLfuYx61gnk6sXh+Bwj6jQj8XWz8cdEtTQGIPyco3M+fuIkYcKlqMLYMz6N7mVePv9Hj lTwV0udDCxPsrj4ISKiYxBd5Cdmb6Am2ZzPKQQyLOntqpNhXt1XcbZqbpYagmCaLMYICnDCC ApgCAQEwXzBRMRMwEQYKCZImiZPyLGQBGRYDZWR1MRQwEgYKCZImiZPyLGQBGRYEY3N1YjES MBAGCgmSJomT8ixkARkWAmFkMRAwDgYDVQQDEwdhZC1jc3ViAgoRGEQrAAAAAA0RMAkGBSsO AwIaBQCgggGTMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA3 MDcxOTIzNDgzMVowIwYJKoZIhvcNAQkEMRYEFCfCeNwyuMO5jPgDz/anZFnYQbOgMFIGCSqG SIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMG4GCSsGAQQBgjcQBDFhMF8wUTETMBEGCgmSJomT 8ixkARkWA2VkdTEUMBIGCgmSJomT8ixkARkWBGNzdWIxEjAQBgoJkiaJk/IsZAEZFgJhZDEQ MA4GA1UEAxMHYWQtY3N1YgIKERhEKwAAAAANETBwBgsqhkiG9w0BCRACCzFhoF8wUTETMBEG CgmSJomT8ixkARkWA2VkdTEUMBIGCgmSJomT8ixkARkWBGNzdWIxEjAQBgoJkiaJk/IsZAEZ FgJhZDEQMA4GA1UEAxMHYWQtY3N1YgIKERhEKwAAAAANETANBgkqhkiG9w0BAQEFAASBgH7f i0NqlOY2Hxp31Eh0Z5PzdnHJrpLTqhtpp1RdUuvQYMvFK0mxB+Kcml5+l9O1Y3VaDAYCRdwR pVeTMRrYgaJGIbEY+2oYZ5FgjCTmXbVJhdsiwJETIeq4sxj7qUh7YdBEmYJ07NP+C2YUEHtq +MjvZYLKDRd+m17GczjPvxE7AAAAAAAA --------------ms080300060808020309050906-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 20 00:52:32 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0554F16A418 for ; Fri, 20 Jul 2007 00:52:32 +0000 (UTC) (envelope-from ioplex@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.225]) by mx1.freebsd.org (Postfix) with ESMTP id B82D113C44C for ; Fri, 20 Jul 2007 00:52:31 +0000 (UTC) (envelope-from ioplex@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so595845wxd for ; Thu, 19 Jul 2007 17:52:31 -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=QNEGsk7GICdfsnG55enyGw5AGo0awFqgcQIh0dZMAOlpGlQxdPbL9jPWsDP2BY0C294A/DivimyHQV4Sw8Av7SQsuV39zBHJJ6UVJVrOSgfz4WXXl7HR9uryfTlUuY34KqDkcoUDsdgP5gpKd8S9QvO9XfoAo/0WPAZhLmui6HQ= 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=oPs9UOyApiG4fxCRA6cNogCPpxn3C9MMf72byghtES3BsWEbvcEuvwWN4LYK7LZQlH+twkZ+kX2M990O8YkEouJkpNP+7A42OlBfA+D33Yjnl0AmmQVT9CsEf07S6VULl6ONqhLmMqKx2b/LN/jOsS3inOKwhrvq6OD14RFDdl0= Received: by 10.70.96.3 with SMTP id t3mr3678698wxb.1184891127220; Thu, 19 Jul 2007 17:25:27 -0700 (PDT) Received: by 10.70.38.11 with HTTP; Thu, 19 Jul 2007 17:25:27 -0700 (PDT) Message-ID: <78c6bd860707191725r14b8bfe3sf15c1f0e30cf82ca@mail.gmail.com> Date: Thu, 19 Jul 2007 20:25:27 -0400 From: "Michael B Allen" 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: Path to executable of current process? 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, 20 Jul 2007 00:52:32 -0000 Hello, I'm looking for an example that uses kvm_getargv but from just googling around I can't seem to find an example. Can someone give me a pointer? Actually what I'm *really* trying to do is port some code that invokes GDB to do a backtrace and I need to give GDB the path to the executable of the current process (e.g. on linux this is /proc//exe) and the pid of the process to trace (easy - getpid). The first argument is trickey since FreeBSD frequently does not have a /proc filesystem. So it seems kvm_getargv should have this path no? Mike From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 20 02:00:24 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D527816A417 for ; Fri, 20 Jul 2007 02:00:24 +0000 (UTC) (envelope-from ioplex@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.226]) by mx1.freebsd.org (Postfix) with ESMTP id 8FAB613C467 for ; Fri, 20 Jul 2007 02:00:24 +0000 (UTC) (envelope-from ioplex@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so605983wxd for ; Thu, 19 Jul 2007 19:00:23 -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=uRJg4mIudyr4uXJcP3qeUseU+YMr1j6iZ0V3ap1Nlq2g1yVoND66EULE3GRJQrqAUOBOqe0cfGro3t+4cuPk9MsJ3hwTivViASfdOBBk/qaQu+8nErBNFf5z9fTd7gM534ZFJrppi+Kt0PRgY0cNn61lUX+HJRKkDs7K3qGsuiI= 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=q4ZWUyuUFXGpM2v3Kqzyd9UDtRCt0ZHaupsbZRcVkRn5YFpV124OeA9wEXSEBvHHP8vYj/IWnGUfYDwPFembVK8lAdQCJhzslTGOKLNmjMJz4xr09uRgBrP/onID7YjeU4Cypkf5YGl8NuKo1owjnxvcHC5GwhuGtetrRs7BG6M= Received: by 10.70.17.1 with SMTP id 1mr5382102wxq.1184896823855; Thu, 19 Jul 2007 19:00:23 -0700 (PDT) Received: by 10.70.38.11 with HTTP; Thu, 19 Jul 2007 19:00:23 -0700 (PDT) Message-ID: <78c6bd860707191900g375f98ado8315603feac50247@mail.gmail.com> Date: Thu, 19 Jul 2007 22:00:23 -0400 From: "Michael B Allen" To: freebsd-hackers In-Reply-To: <78c6bd860707191725r14b8bfe3sf15c1f0e30cf82ca@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <78c6bd860707191725r14b8bfe3sf15c1f0e30cf82ca@mail.gmail.com> Subject: Re: Path to executable of current process? 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, 20 Jul 2007 02:00:24 -0000 On 7/19/07, Michael B Allen wrote: > Hello, > > I'm looking for an example that uses kvm_getargv but from just > googling around I can't seem to find an example. Can someone give me a > pointer? > > Actually what I'm *really* trying to do is port some code that invokes > GDB to do a backtrace and I need to give GDB the path to the > executable of the current process (e.g. on linux this is > /proc//exe) and the pid of the process to trace (easy - getpid). > The first argument is trickey since FreeBSD frequently does not have a > /proc filesystem. So it seems kvm_getargv should have this path no? Well I figured out how to get kvm_getargv working. Unfortunately it seems only root can call kvm_open so the faulting process can't backtrace unless it so happens to be running as root (which it's not). Is there any way to get argv[0] for the current process without being root? Mike From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 20 03:23:47 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 26F9816A418 for ; Fri, 20 Jul 2007 03:23:47 +0000 (UTC) (envelope-from ioplex@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.234]) by mx1.freebsd.org (Postfix) with ESMTP id D794413C461 for ; Fri, 20 Jul 2007 03:23:46 +0000 (UTC) (envelope-from ioplex@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so618447wxd for ; Thu, 19 Jul 2007 20:23:46 -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=GhDWsQ7prcPRQDlKQrIdAjVU/1f78jZMPJhUCfyBBiVrUn2uT7+7mm+RzuegQJD5GShjBiAL2hmYkMAGHDavvjnOKHvdL+VRwfji6Rj4wTwAoBJuzH8PRZe8v9xRT578HHnGTwwLqXqQP6w2T7ERcD/vQz0A1P5DkEv9GXbCLzM= 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=UPLCuZYYow1v0fvO8GXbsXJOae73YImb/JRNOVfirlngt3Eg4dR/EvY63OxnZYkkffb2LmsGCxQSCXwHlKwh8iqmS0jW2L11Q43d2Gyd8jyNLbcSbh9t+rkXQnLVDXvXvK5n0ia5pkx7+4KN/IY2RIzAmVPjK+m+QJ0qpgleu4U= Received: by 10.70.9.8 with SMTP id 8mr79325wxi.1184901825930; Thu, 19 Jul 2007 20:23:45 -0700 (PDT) Received: by 10.70.38.11 with HTTP; Thu, 19 Jul 2007 20:23:45 -0700 (PDT) Message-ID: <78c6bd860707192023u645a3c39ua713cc4384c3b876@mail.gmail.com> Date: Thu, 19 Jul 2007 23:23:45 -0400 From: "Michael B Allen" To: freebsd-hackers In-Reply-To: <78c6bd860707191900g375f98ado8315603feac50247@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <78c6bd860707191725r14b8bfe3sf15c1f0e30cf82ca@mail.gmail.com> <78c6bd860707191900g375f98ado8315603feac50247@mail.gmail.com> Subject: Re: Path to executable of current process? 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, 20 Jul 2007 03:23:47 -0000 > Is there any way to get argv[0] for [a particular] process without being root? After more digging I see sysctl seems to be the way to do this but can I get the full path to the executable form kinfo_proc? How does ps do this? static const char * getcmdline(pid_t pid) { static struct kinfo_proc ki_proc; int mib[4], len; mib[0] = CTL_KERN; mib[1] = KERN_PROC; mib[2] = KERN_PROC_PID; mib[3] = pid; len = sizeof(struct kinfo_proc); if (sysctl(mib, 4, &ki_proc, &len, NULL, 0) == -1) return NULL; return ki_proc.ki_??? } Mike From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 20 04:01:42 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A81BF16A418 for ; Fri, 20 Jul 2007 04:01:42 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-3.dlr.de (smtp-3.dlr.de [195.37.61.187]) by mx1.freebsd.org (Postfix) with ESMTP id 430CE13C459 for ; Fri, 20 Jul 2007 04:01:42 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from [192.168.2.100] ([172.21.151.2]) by smtp-3.dlr.de with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 22:51:12 +0200 Message-ID: <469FCEC6.8090600@dlr.de> Date: Thu, 19 Jul 2007 22:51:18 +0200 From: Hartmut Brandt Organization: German Aerospace Center User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: rapopp@eastcentral.edu References: <200706051149.45787.rapopp@eastcentral.edu> <4665B28A.7060608@elischer.org> <469ECA49.8050101@thebeastie.org> <200707191054.02109.rapopp@eastcentral.edu> In-Reply-To: <200707191054.02109.rapopp@eastcentral.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jul 2007 20:51:12.0314 (UTC) FILETIME=[8A7A49A0:01C7CA46] Cc: freebsd-hackers@freebsd.org, Julian Elischer , Michael Vince Subject: Re: kern.ngroups question 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, 20 Jul 2007 04:01:42 -0000 Reuben A. Popp wrote: > On Wednesday 18 July 2007 21:19, Michael Vince wrote: >> Julian Elischer wrote: >>> Reuben A. Popp wrote: >>>> Hello all, >>>> >>>> Can someone explain to me the rationale behind having ngroups_max set >>>> to 16 by default? >>> NFS only supports this much by default (from memory). >>> >>> Samba (in the guise of Jeremy Allison) >>> has asked us to follow Linux's lead and support an arbitrary number of >>> Groups >>> but it hasn't happened yet, Partly due to the question of "what to do >>> about NFS" and partly just due to ENOTIME. >> I think at the very least that there should be some more obvious >> warnings about this potentially serious limitation in either release >> notes of FreeBSD and or Samba. >> >> I just had to deal with this limitation and it was quite annoying to say >> the least, it appears Samba is somewhat deliberately designed to give >> you a hard time when you run into this limit, because as soon as you add >> a user to more than 16 groups it declares the group file unreadable and >> as a security measure shuts down all shares and authentication which >> wrecks a network which relies on Samba. >> >> Also as far as I know Solaris and Linux has long gone past this limitation. >> >> Mike > > Running into a problem nearly identical to Mike's is what caused me to start > researching ngroups in the first place. Granted, in our Samba > implementation, there isn't really anyone who hits the limitation (short of > the admin), but the problem is still a definite show stopper. > > I imagine this will become even more of an issue once Samba 4.x is completed > and sees deployment. Maybe this weekend I can write a small blurb for the > handbook > > I guess the next question I have would be about the limit in NFS. I did a > little sleuthing and found out that the actual culprit is not necessarily > NFS, but the underlying RPC calls. IF I'm reading this correctly (excuse me > if I'm wrong.. I'm just now getting my feet wet with c/c++), the limit is set > in the auth_unix structure (taken from RFC 1057): > > struct auth_unix { > unsigned int stamp; > string machinename<255>; > unsigned int uid; > unsigned int gid; > unsigned int gids<16>; > }; > > If the value for gids were to be changed, that obviously would mean that the > RPC implementation would be out of whack with the standard. How then are the > other *nixes getting around this issue? > > Thanks again > Reuben A. Popp > > Just a note: As I said above, I'm still just now getting my feet wet in any > kind of programming (other than shell scripting). If I make an incorrect > assumption or a pretty stupid mistake, all I ask is to be kind :) > I'm somewhat getting tired to repeat that you may raise ngroups if you want. I fixed a couple of bugs with this, and I run ngroups=64 for almost 2 years (with authenticating against an AD with users in a lot of groups). For NFS the code just passed the first 16 groups, so you might not get access to files that you should get access to based on group memberships. A problem might be when you NFS export a filesystem with deny ACLs. Then a user might get access to a file he should not. I would think of this as a good reason not to make ngroups > 16 the default. harti From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 20 09:29:17 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A93A16A419; Fri, 20 Jul 2007 09:29:17 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from com1.ht-systems.ru (com1.ht-systems.ru [83.97.104.204]) by mx1.freebsd.org (Postfix) with ESMTP id 052E213C457; Fri, 20 Jul 2007 09:29:16 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from [85.21.245.235] (helo=phonon.SpringDaemons.com) by com1.ht-systems.ru with esmtpa (Exim 4.62) (envelope-from ) id 1IBonS-0003lh-7n; Fri, 20 Jul 2007 13:29:15 +0400 Received: from localhost (localhost [127.0.0.1]) by phonon.SpringDaemons.com (Postfix) with SMTP id 02D7511404; Fri, 20 Jul 2007 13:28:40 +0400 (MSD) Date: Fri, 20 Jul 2007 13:28:31 +0400 From: Stanislav Sedov To: "Michael Vaughn" Message-Id: <20070720132831.87cd008f.stas@FreeBSD.org> In-Reply-To: <2f0146460707181512x3841af57l588e4d6e67bd5884@mail.gmail.com> References: <2f0146460707181512x3841af57l588e4d6e67bd5884@mail.gmail.com> Organization: The FreeBSD Project X-Mailer: carrier-pigeon X-Voice: +7 916 849 20 23 X-XMPP: ssedov@jabber.ru X-ICQ: 208105021 X-Yahoo: stanislav_sedov X-PGP-Fingerprint: F21E D6CC 5626 9609 6CE2 A385 2BF5 5993 EB26 9581 X-University: MEPhI Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Fri__20_Jul_2007_13_28_31_+0400_gtJnMl+38.=FuSxv" X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona 1.6.0 Cc: freebsd-hackers@freebsd.org, freebsd-performance@freebsd.org, freebsd-questions@freebsd.org Subject: Re: FreeBSD 6.2-STABLE && apache 2.2.4 = bad performance. Help! 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, 20 Jul 2007 09:29:17 -0000 --Signature=_Fri__20_Jul_2007_13_28_31_+0400_gtJnMl+38.=FuSxv Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, 18 Jul 2007 23:12:57 +0100 "Michael Vaughn" mentioned: > Hello everyone, >=20 > I am contacting -performance, -questions, and -hackers in the hope someone > helps me troubleshoot a problem with FreeBSD 6.2 and apache 2.2.4 >=20 Try to run truss(1) on any of apache processes and look what it's doing. --=20 Stanislav Sedov ST4096-RIPE --Signature=_Fri__20_Jul_2007_13_28_31_+0400_gtJnMl+38.=FuSxv Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFGoIBHK/VZk+smlYERAqEHAJ9P0ig41tc5wcnZ9VR3wlpIHI+0HQCghDSh Q7On7AP5rtfF3D1yl+8Nvxk= =mxbR -----END PGP SIGNATURE----- --Signature=_Fri__20_Jul_2007_13_28_31_+0400_gtJnMl+38.=FuSxv-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 20 11:12:12 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2262016A418 for ; Fri, 20 Jul 2007 11:12:12 +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 8356413C46E for ; Fri, 20 Jul 2007 11:12:11 +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 l6KBC9dY001906; Fri, 20 Jul 2007 21:12:09 +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 l6KBC9XO001905; Fri, 20 Jul 2007 21:12:09 +1000 (EST) (envelope-from peter) Date: Fri, 20 Jul 2007 21:12:09 +1000 From: Peter Jeremy To: Michael B Allen Message-ID: <20070720111209.GV1176@turion.vk2pj.dyndns.org> References: <78c6bd860707191725r14b8bfe3sf15c1f0e30cf82ca@mail.gmail.com> <78c6bd860707191900g375f98ado8315603feac50247@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="h31gzZEtNLTqOjlF" Content-Disposition: inline In-Reply-To: <78c6bd860707191900g375f98ado8315603feac50247@mail.gmail.com> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-hackers Subject: Re: Path to executable of current process? 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, 20 Jul 2007 11:12:12 -0000 --h31gzZEtNLTqOjlF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2007-Jul-19 22:00:23 -0400, Michael B Allen wrote: >Well I figured out how to get kvm_getargv working. Unfortunately it >seems only root can call kvm_open so the faulting process can't >backtrace unless it so happens to be running as root (which it's not). > >Is there any way to get argv[0] for the current process without being root? I suggest you have a look at the source to ps - it does not run with elevated privileges. Note that argv[0] is not necessarily a full pathname - it is whatever the program was invoked with. Even if it _is_ a full pathname, there is no guarantee that it points to the same object - the executable may be in a chroot environment or that pathname may have been replaced. The only guaranteed way to access the executable associated with a running process is via procfs. As you point out earlier, this is not mounted by default on FreeBSD because none of the base system utilities need it (apart from 'ps -e') - you will need to arrange for it to be mounted. On 2007-Jul-19 23:23:45 -0400, Michael B Allen wrote: >After more digging I see sysctl seems to be the way to do this but can I= =20 >get the full path to the executable form kinfo_proc? > >How does ps do this? It uses kvm_getargv(3). If you want to do it directly via sysctl(2), I suggest you examine /usr/src/lib/libkvm/kvm_proc.c. > mib[2] =3D KERN_PROC_PID; This should be KERN_PROC_ARGS > len =3D sizeof(struct kinfo_proc); > if (sysctl(mib, 4, &ki_proc, &len, NULL, 0) =3D=3D -1) And the buffer argument should be char[], not struct kinfo_proc. --=20 Peter Jeremy --h31gzZEtNLTqOjlF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGoJiJ/opHv/APuIcRAtcpAJ9/zq/z9vLxlJgeM5Q9w1ck7KSdsACgqoqP fGvVxElsOLM2YYC3/SHEH/0= =7xI6 -----END PGP SIGNATURE----- --h31gzZEtNLTqOjlF-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 20 06:32:37 2007 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A16C116A419 for ; Fri, 20 Jul 2007 06:32:37 +0000 (UTC) (envelope-from news@Watt.COM) Received: from wattres.watt.com (wattres.watt.com [66.93.133.130]) by mx1.freebsd.org (Postfix) with ESMTP id 8073F13C468 for ; Fri, 20 Jul 2007 06:32:37 +0000 (UTC) (envelope-from news@Watt.COM) Received: from wattres.watt.com (localhost.watt.com [127.0.0.1]) by wattres.watt.com (8.13.8/8.13.8) with ESMTP id l6K6MBOV004760 for ; Thu, 19 Jul 2007 23:22:16 -0700 (PDT) (envelope-from news@wattres.watt.com) Received: (from news@localhost) by wattres.watt.com (8.13.8/8.13.8/Submit) id l6K6MBB9004759 for hackers@freebsd.org; Thu, 19 Jul 2007 23:22:11 -0700 (PDT) (envelope-from news) To: hackers@freebsd.org Path: not-for-mail From: Steve Watt Newsgroups: local.freebsd-hackers Date: Fri, 20 Jul 2007 06:22:11 +0000 (UTC) Organization: Watt Consultants, San Jose, CA, USA Lines: 19 Message-ID: References: <78c6bd860707191725r14b8bfe3sf15c1f0e30cf82ca@mail.gmail.com> NNTP-Posting-Host: localhost.watt.com X-Trace: wattres.Watt.COM 1184912531 4245 127.0.0.1 (20 Jul 2007 06:22:11 GMT) X-Complaints-To: usenet@wattres.Watt.COM NNTP-Posting-Date: Fri, 20 Jul 2007 06:22:11 +0000 (UTC) X-Newsreader: trn 4.0-test76 (Apr 2, 2001) Originator: steve@Watt.COM (Steve Watt) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (wattres.watt.com [127.0.0.1]); Thu, 19 Jul 2007 23:22:16 -0700 (PDT) X-Archived: 1184912536.695686415@wattres.Watt.COM X-Mailman-Approved-At: Fri, 20 Jul 2007 11:23:25 +0000 Cc: Subject: Re: Path to executable of current process? 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, 20 Jul 2007 06:32:37 -0000 In <78c6bd860707191725r14b8bfe3sf15c1f0e30cf82ca@mail.gmail.com>, Michael B Allen wrote: >Actually what I'm *really* trying to do is port some code that invokes >GDB to do a backtrace and I need to give GDB the path to the >executable of the current process (e.g. on linux this is >/proc//exe) and the pid of the process to trace (easy - getpid). >The first argument is trickey since FreeBSD frequently does not have a >/proc filesystem. So it seems kvm_getargv should have this path no? # mount_procfs proc /proc # /bin/ls -l /proc//file Note that if the executable on disk gets replaced, this won't work. -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.5" / 37N 20' 15.3" Internet: steve @ Watt.COM Whois: SW32-ARIN Free time? There's no such thing. It just comes in varying prices... From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 20 15:15:26 2007 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F0C716A417 for ; Fri, 20 Jul 2007 15:15:26 +0000 (UTC) (envelope-from maxim@macomnet.ru) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.freebsd.org (Postfix) with ESMTP id 9ECFD13C46E for ; Fri, 20 Jul 2007 15:15:25 +0000 (UTC) (envelope-from maxim@macomnet.ru) Received: from localhost (localhost.int.ru [127.0.0.1] (may be forged)) by mp2.macomnet.net (8.13.7/8.13.8) with ESMTP id l6KFFNMd005556 for ; Fri, 20 Jul 2007 19:15:23 +0400 (MSD) (envelope-from maxim@macomnet.ru) Date: Fri, 20 Jul 2007 19:15:23 +0400 (MSD) From: Maxim Konovalov To: hackers@freebsd.org Message-ID: <20070720185101.F20123@mp2.macomnet.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Subject: tunefs.8 oddity 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, 20 Jul 2007 15:15:26 -0000 Hello, after spending a half an hour trying to help a friend of mine to turn soft updates on the root filesystem on I'd like to revert a part of rev. 1.21 just because it makes life of an average sysadmin easier: Index: tunefs.8 =================================================================== RCS file: /home/ncvs/src/sbin/tunefs/tunefs.8,v retrieving revision 1.37 diff -u -p -r1.37 tunefs.8 --- tunefs.8 31 Oct 2006 21:52:28 -0000 1.37 +++ tunefs.8 20 Jul 2007 14:57:30 -0000 @@ -165,6 +165,8 @@ utility appeared in .Bx 4.2 . .Sh BUGS This utility should work on active file systems. +To change the root filesystem, the system must be rebooted +after the filesystem is tuned. .\" Take this out and a Unix Daemon will dog your steps from now until .\" the time_t's wrap around. .Pp %%% Any objections? -- Maxim Konovalov From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 20 15:31:15 2007 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6CCE516A41B for ; Fri, 20 Jul 2007 15:31:15 +0000 (UTC) (envelope-from maxim@macomnet.ru) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.freebsd.org (Postfix) with ESMTP id F050713C458 for ; Fri, 20 Jul 2007 15:31:14 +0000 (UTC) (envelope-from maxim@macomnet.ru) Received: from localhost (localhost.int.ru [127.0.0.1] (may be forged)) by mp2.macomnet.net (8.13.7/8.13.8) with ESMTP id l6KFV2hj006001; Fri, 20 Jul 2007 19:31:03 +0400 (MSD) (envelope-from maxim@macomnet.ru) Date: Fri, 20 Jul 2007 19:31:02 +0400 (MSD) From: Maxim Konovalov To: Xin LI In-Reply-To: <46A0D313.8010904@delphij.net> Message-ID: <20070720192830.C20123@mp2.macomnet.net> References: <20070720185101.F20123@mp2.macomnet.net> <46A0D313.8010904@delphij.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: hackers@freebsd.org Subject: Re: tunefs.8 oddity 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, 20 Jul 2007 15:31:15 -0000 On Fri, 20 Jul 2007, 23:21+0800, Xin LI wrote: > Maxim Konovalov wrote: > > Hello, > > > > after spending a half an hour trying to help a friend of mine to turn > > soft updates on the root filesystem on I'd like to revert a part of > > rev. 1.21 just because it makes life of an average sysadmin easier: > > > > Index: tunefs.8 > > =================================================================== > > RCS file: /home/ncvs/src/sbin/tunefs/tunefs.8,v > > retrieving revision 1.37 > > diff -u -p -r1.37 tunefs.8 > > --- tunefs.8 31 Oct 2006 21:52:28 -0000 1.37 > > +++ tunefs.8 20 Jul 2007 14:57:30 -0000 > > @@ -165,6 +165,8 @@ utility appeared in > > .Bx 4.2 . > > .Sh BUGS > > This utility should work on active file systems. > > +To change the root filesystem, the system must be rebooted > > +after the filesystem is tuned. > > .\" Take this out and a Unix Daemon will dog your steps from now until > > .\" the time_t's wrap around. > > .Pp > > %%% > > Any chance that we resolve the bug instead of documenting it? :-) > Personally, I have no energy/time for that. It was documented for ages, it is still documented in other BSDs. -- Maxim Konovalov From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 20 15:38:50 2007 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0EDC16A418 for ; Fri, 20 Jul 2007 15:38:50 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.freebsd.org (Postfix) with ESMTP id A9F0013C47E for ; Fri, 20 Jul 2007 15:38:50 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id CD838EB1B66; Fri, 20 Jul 2007 23:22:00 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id GIPNJRUdE158; Fri, 20 Jul 2007 23:21:56 +0800 (CST) Received: from charlie.delphij.net (unknown [221.216.126.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id CA93BEB1B0C; Fri, 20 Jul 2007 23:21:56 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=RoOF5+MNTkgHZ93CytfcVPlda3rie9Yb1jxtWBVk8G5EnjvhCEnTZlIN6/2MEjH8s NKACxQ71Q7GmMLjoncxDg== Message-ID: <46A0D313.8010904@delphij.net> Date: Fri, 20 Jul 2007 23:21:55 +0800 From: Xin LI User-Agent: Thunderbird 2.0.0.4 (X11/20070711) MIME-Version: 1.0 To: Maxim Konovalov References: <20070720185101.F20123@mp2.macomnet.net> In-Reply-To: <20070720185101.F20123@mp2.macomnet.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org Subject: Re: tunefs.8 oddity 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, 20 Jul 2007 15:38:51 -0000 Maxim Konovalov wrote: > Hello, > > after spending a half an hour trying to help a friend of mine to turn > soft updates on the root filesystem on I'd like to revert a part of > rev. 1.21 just because it makes life of an average sysadmin easier: > > Index: tunefs.8 > =================================================================== > RCS file: /home/ncvs/src/sbin/tunefs/tunefs.8,v > retrieving revision 1.37 > diff -u -p -r1.37 tunefs.8 > --- tunefs.8 31 Oct 2006 21:52:28 -0000 1.37 > +++ tunefs.8 20 Jul 2007 14:57:30 -0000 > @@ -165,6 +165,8 @@ utility appeared in > .Bx 4.2 . > .Sh BUGS > This utility should work on active file systems. > +To change the root filesystem, the system must be rebooted > +after the filesystem is tuned. > .\" Take this out and a Unix Daemon will dog your steps from now until > .\" the time_t's wrap around. > .Pp > %%% Any chance that we resolve the bug instead of documenting it? :-) Cheers, From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 20 19:14:07 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C664916A41F for ; Fri, 20 Jul 2007 19:14:07 +0000 (UTC) (envelope-from romain@blogreen.org) Received: from postfix1-g20.free.fr (postfix1-g20.free.fr [212.27.60.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5B29C13C45D for ; Fri, 20 Jul 2007 19:14:07 +0000 (UTC) (envelope-from romain@blogreen.org) Received: from smtp3-g19.free.fr (smtp3-g19.free.fr [212.27.42.29]) by postfix1-g20.free.fr (Postfix) with ESMTP id 9043E1724F25 for ; Fri, 20 Jul 2007 20:50:11 +0200 (CEST) Received: from marvin.blogreen.org (marvin.blogreen.org [82.247.213.140]) by smtp3-g19.free.fr (Postfix) with ESMTP id 071448196 for ; Fri, 20 Jul 2007 20:50:09 +0200 (CEST) Received: by marvin.blogreen.org (Postfix, from userid 1001) id 8F1435C04E; Fri, 20 Jul 2007 20:50:09 +0200 (CEST) Date: Fri, 20 Jul 2007 20:50:09 +0200 From: Romain =?iso-8859-1?Q?Tarti=E8re?= To: freebsd-hackers Message-ID: <20070720185009.GA79090@marvin.blogreen.org> Mail-Followup-To: freebsd-hackers Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Dxnq1zWXvFF0Q93v" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: Insufficient locking in log() / kvprintf() / somewhere? 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, 20 Jul 2007 19:14:07 -0000 --Dxnq1zWXvFF0Q93v Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello FreeBSD hackers! I recently got some apache problems (maybe just forgetting to restart it after an update, but it is not the interest of this e-mail) and each httpd process was segfaulting as soon as created. I got surprising things like that in my systems log: =3D=3D=3D begin snippet =3D=3D=3D > pid 85055 (httpd), uid 80: exited on signal 11 > pid 85063 (httpd), uid 80: exited on signal 11 > pid 85064 (httpd), uid 80: exited on signal 11 > pid 85066 (httpd), uid 80: exited on signal 11 > pid 85065 (httpd), uid 80: exited on signal 11 > <<66>>ppiidd 8580506678 ((hhtttptdp)d,), uuid id8 0: 8ex0: eixteidt eo= d no ns isginganla l 111 > 1 >=20 > pid 85070 (httpd), uid 80: exited on signal 11 > pid 85069 (httpd), uid 80: exited on signal 11 =3D=3D=3D end snippet =3D=3D=3D (uname: FreeBSD 6.2-STABLE #4: Thu Jun 7 00:56:26 CEST 2007 i386) Obviously, having two processes on a dual core machine crashing simultaneously produce weird stuff. I poked a bit around in /usr/src/sys/kern: > % grep -n 'exited on signal' * > kern_sig.c:2452: "pid %d (%s), uid %d: exited on signal %d%s\n", The code in void sigexit(td, sig) is as follow: > if (kern_logsigexit) > log(LOG_INFO, > "pid %d (%s), uid %d: exited on signal %d%s\n", > p->p_pid, p->p_comm, > td->td_ucred ? td->td_ucred->cr_uid : -1, > sig &~ WCOREFLAG, > sig & WCOREFLAG ? " (core dumped)" : ""); The log() function is declared in /usr/src/sys/kern/subr_prf.c:229 as this: > void > log(int level, const char *fmt, ...) > { > va_list ap; > struct putchar_arg pca; > > pca.tty =3D NULL; > pca.pri =3D level; > pca.flags =3D log_open ? TOLOG : TOCONS; > > va_start(ap, fmt); > kvprintf(fmt, putchar, &pca, 10, ap); > va_end(ap); > > msgbuftrigger =3D 1; > } =2E.. so basically is calls kvprintf witch actually writes the message AFAIK. The issue is maybe a weird case-corner, but maybe some kind of locking may have sense to avoid this? Kind regards, Romain --=20 Romain Tarti=E8re http://romain.blogreen.org/ pgp: 8DAB A124 0DA4 7024 F82A E748 D8E9 A33F FF56 FF43 (ID: 0xFF56FF43) (plain text =3Dnon-HTML=3D PGP/GPG encrypted/signed e-mail much appreciated) --Dxnq1zWXvFF0Q93v Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFGoQPh2OmjP/9W/0MRAuOwAJwNFiMgvmI2qoIETzvlfyU7wehlwgCfQxXh MJvLYctf4kltW1gVlZYNKQ8= =WPjV -----END PGP SIGNATURE----- --Dxnq1zWXvFF0Q93v-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 20 21:10:21 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18AC016A419 for ; Fri, 20 Jul 2007 21:10:21 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from smtp801.mail.ird.yahoo.com (smtp801.mail.ird.yahoo.com [217.146.188.61]) by mx1.freebsd.org (Postfix) with SMTP id 8649D13C45A for ; Fri, 20 Jul 2007 21:10:20 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: (qmail 86755 invoked from network); 20 Jul 2007 20:43:39 -0000 Received: from unknown (HELO ?192.168.1.2?) (thomasjudge@btinternet.com@86.140.28.215 with plain) by smtp801.mail.ird.yahoo.com with SMTP; 20 Jul 2007 20:43:38 -0000 X-YMail-OSG: vc7dN0EVM1k0YZMKBDpNQXrniA0zml24DAcXMAWQJnIlarGd Message-ID: <46A12CD3.4000600@tomjudge.com> Date: Fri, 20 Jul 2007 22:44:51 +0100 From: Tom Judge User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: freebsd-hackers References: <20070720185009.GA79090@marvin.blogreen.org> In-Reply-To: <20070720185009.GA79090@marvin.blogreen.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: Insufficient locking in log() / kvprintf() / somewhere? 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, 20 Jul 2007 21:10:21 -0000 Romain Tartière wrote: > Hello FreeBSD hackers! > > I recently got some apache problems (maybe just forgetting to restart it > after an update, but it is not the interest of this e-mail) and each > httpd process was segfaulting as soon as created. I got surprising > things like that in my systems log: > > === begin snippet === >> pid 85055 (httpd), uid 80: exited on signal 11 >> pid 85063 (httpd), uid 80: exited on signal 11 >> pid 85064 (httpd), uid 80: exited on signal 11 >> pid 85066 (httpd), uid 80: exited on signal 11 >> pid 85065 (httpd), uid 80: exited on signal 11 >> <<66>>ppiidd 8580506678 ((hhtttptdp)d,), uuid id8 0: 8ex0: eixteidt eod no ns isginganla l 111 >> 1 >> >> pid 85070 (httpd), uid 80: exited on signal 11 >> pid 85069 (httpd), uid 80: exited on signal 11 > === end snippet === > > (uname: FreeBSD 6.2-STABLE #4: Thu Jun 7 00:56:26 CEST 2007 i386) > > Obviously, having two processes on a dual core machine crashing > simultaneously produce weird stuff. I poked a bit around in > /usr/src/sys/kern: > >> % grep -n 'exited on signal' * >> kern_sig.c:2452: "pid %d (%s), uid %d: exited on signal %d%s\n", > > The code in void sigexit(td, sig) is as follow: >> if (kern_logsigexit) >> log(LOG_INFO, >> "pid %d (%s), uid %d: exited on signal %d%s\n", >> p->p_pid, p->p_comm, >> td->td_ucred ? td->td_ucred->cr_uid : -1, >> sig &~ WCOREFLAG, >> sig & WCOREFLAG ? " (core dumped)" : ""); > > The log() function is declared in /usr/src/sys/kern/subr_prf.c:229 as this: >> void >> log(int level, const char *fmt, ...) >> { >> va_list ap; >> struct putchar_arg pca; >> >> pca.tty = NULL; >> pca.pri = level; >> pca.flags = log_open ? TOLOG : TOCONS; >> >> va_start(ap, fmt); >> kvprintf(fmt, putchar, &pca, 10, ap); >> va_end(ap); >> >> msgbuftrigger = 1; >> } > ... so basically is calls kvprintf witch actually writes the message > AFAIK. > > The issue is maybe a weird case-corner, but maybe some kind of locking > may have sense to avoid this? > > Kind regards, > Romain > I have seen this problem a lot where certain apache server modules have been miss configured causing apache children to call abort and dump core as soon as they are spawned. (Makes for a lot of messages) I have also seen it produced by network drivers with large quantities of debug messages enabled. Its kind of annoying to see messages interleaved like this. Tom From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 20 22:55:14 2007 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F91C16A417 for ; Fri, 20 Jul 2007 22:55:14 +0000 (UTC) (envelope-from SRS0=Naq8=MS=FreeBSD.org=se@srs.kundenserver.de) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.174]) by mx1.freebsd.org (Postfix) with ESMTP id BEE6413C45A for ; Fri, 20 Jul 2007 22:55:13 +0000 (UTC) (envelope-from SRS0=Naq8=MS=FreeBSD.org=se@srs.kundenserver.de) Received: from [80.135.167.244] (helo=[192.168.0.12]) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis), id 0ML25U-1IC1AB16tk-0004UO; Sat, 21 Jul 2007 00:41:32 +0200 Message-ID: <46A13A10.8070108@FreeBSD.org> Date: Sat, 21 Jul 2007 00:41:20 +0200 From: Stefan Esser User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Maxim Konovalov References: <20070720185101.F20123@mp2.macomnet.net> <46A0D313.8010904@delphij.net> <20070720192830.C20123@mp2.macomnet.net> In-Reply-To: <20070720192830.C20123@mp2.macomnet.net> X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX1+lsx36NZRRxmemc06YjFopYQwatYgC3MLBPi3 HSiL61WzQbrq/GsnrS7G0eQBt6TYwF7qjxO86mR/3m4syZN+BW JfS5hDVvY6GrDlSnU+6rg== Cc: hackers@freebsd.org, Xin LI Subject: Re: tunefs.8 oddity 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, 20 Jul 2007 22:55:14 -0000 Maxim Konovalov schrieb: > On Fri, 20 Jul 2007, 23:21+0800, Xin LI wrote: > >> Maxim Konovalov wrote: >>> Hello, >>> >>> after spending a half an hour trying to help a friend of mine to turn >>> soft updates on the root filesystem on I'd like to revert a part of >>> rev. 1.21 just because it makes life of an average sysadmin easier: >>> >>> Index: tunefs.8 >>> =================================================================== >>> RCS file: /home/ncvs/src/sbin/tunefs/tunefs.8,v >>> retrieving revision 1.37 >>> diff -u -p -r1.37 tunefs.8 >>> --- tunefs.8 31 Oct 2006 21:52:28 -0000 1.37 >>> +++ tunefs.8 20 Jul 2007 14:57:30 -0000 >>> @@ -165,6 +165,8 @@ utility appeared in >>> .Bx 4.2 . >>> .Sh BUGS >>> This utility should work on active file systems. >>> +To change the root filesystem, the system must be rebooted >>> +after the filesystem is tuned. >>> .\" Take this out and a Unix Daemon will dog your steps from now until >>> .\" the time_t's wrap around. >>> .Pp >>> %%% >> Any chance that we resolve the bug instead of documenting it? :-) >> > Personally, I have no energy/time for that. It was documented for > ages, it is still documented in other BSDs. It has long ago been converted to a mount option instead of a tunefs command in NetBSD. My FreeBSD systems are patched that way since shortly after soft-updates was committed (long before it became available in NetBSD, IIRC); I have not checked whether they used the (very simple) patches I had posted at that time. Controlling soft-updates during mount has many advantages (not only if you decide to enable it on a root file-system that had been created without it) and no disadvantages. Regards, STefan From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 20 23:23:45 2007 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA30416A41B for ; Fri, 20 Jul 2007 23:23:45 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outH.internet-mail-service.net (outH.internet-mail-service.net [216.240.47.231]) by mx1.freebsd.org (Postfix) with ESMTP id 7F6EA13C465 for ; Fri, 20 Jul 2007 23:23:45 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Fri, 20 Jul 2007 16:10:39 -0700 Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 95DFC125ADE; Fri, 20 Jul 2007 16:10:38 -0700 (PDT) Message-ID: <46A1410F.3080703@elischer.org> Date: Fri, 20 Jul 2007 16:11:11 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Stefan Esser References: <20070720185101.F20123@mp2.macomnet.net> <46A0D313.8010904@delphij.net> <20070720192830.C20123@mp2.macomnet.net> <46A13A10.8070108@FreeBSD.org> In-Reply-To: <46A13A10.8070108@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org, Xin LI Subject: Re: tunefs.8 oddity 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, 20 Jul 2007 23:23:45 -0000 Stefan Esser wrote: > Maxim Konovalov schrieb: >> On Fri, 20 Jul 2007, 23:21+0800, Xin LI wrote: >> >>> Maxim Konovalov wrote: >>>> Hello, >>>> >>>> after spending a half an hour trying to help a friend of mine to turn >>>> soft updates on the root filesystem on I'd like to revert a part of >>>> rev. 1.21 just because it makes life of an average sysadmin easier: >>>> >>>> Index: tunefs.8 >>>> =================================================================== >>>> RCS file: /home/ncvs/src/sbin/tunefs/tunefs.8,v >>>> retrieving revision 1.37 >>>> diff -u -p -r1.37 tunefs.8 >>>> --- tunefs.8 31 Oct 2006 21:52:28 -0000 1.37 >>>> +++ tunefs.8 20 Jul 2007 14:57:30 -0000 >>>> @@ -165,6 +165,8 @@ utility appeared in >>>> .Bx 4.2 . >>>> .Sh BUGS >>>> This utility should work on active file systems. >>>> +To change the root filesystem, the system must be rebooted >>>> +after the filesystem is tuned. >>>> .\" Take this out and a Unix Daemon will dog your steps from now until >>>> .\" the time_t's wrap around. >>>> .Pp >>>> %%% >>> Any chance that we resolve the bug instead of documenting it? :-) >>> >> Personally, I have no energy/time for that. It was documented for >> ages, it is still documented in other BSDs. > > It has long ago been converted to a mount option instead of a > tunefs command in NetBSD. My FreeBSD systems are patched that > way since shortly after soft-updates was committed (long before > it became available in NetBSD, IIRC); I have not checked whether > they used the (very simple) patches I had posted at that time. > > Controlling soft-updates during mount has many advantages (not > only if you decide to enable it on a root file-system that had > been created without it) and no disadvantages. > As the person who added this originally on behalf of Kirk, I think the time for this has probably come. I think even Kirk has said this might now make sense but I'd check with him first. > Regards, STefan > _______________________________________________ > 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" From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 21 00:31:04 2007 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2EE8C16A41A for ; Sat, 21 Jul 2007 00:31:04 +0000 (UTC) (envelope-from SRS0=VL66=MT=FreeBSD.org=se@srs.kundenserver.de) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.177]) by mx1.freebsd.org (Postfix) with ESMTP id BAD4313C468 for ; Sat, 21 Jul 2007 00:31:03 +0000 (UTC) (envelope-from SRS0=VL66=MT=FreeBSD.org=se@srs.kundenserver.de) Received: from [80.135.167.244] (helo=[192.168.0.12]) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis), id 0MKwtQ-1IC2er3Vg7-0006sj; Sat, 21 Jul 2007 02:17:21 +0200 Message-ID: <46A15086.2060505@FreeBSD.org> Date: Sat, 21 Jul 2007 02:17:10 +0200 From: Stefan Esser User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Julian Elischer References: <20070720185101.F20123@mp2.macomnet.net> <46A0D313.8010904@delphij.net> <20070720192830.C20123@mp2.macomnet.net> <46A13A10.8070108@FreeBSD.org> <46A1410F.3080703@elischer.org> In-Reply-To: <46A1410F.3080703@elischer.org> X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX19ib/9W28zJNFmk+X3QOvDdCCWX8l5qlDgFp06 14sOb9em7AGcN0HQvwVdamKXpQsLUod7LuYELRy/xxvlxlgfKv jGWSUTJd1tdfW0bYtO6sw== Cc: Xin LI , hackers@freebsd.org, Stefan Esser Subject: Re: tunefs.8 oddity 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, 21 Jul 2007 00:31:04 -0000 Julian Elischer wrote: > Stefan Esser wrote: >> Maxim Konovalov wrote: >>> On Fri, 20 Jul 2007, 23:21+0800, Xin LI wrote: >>>> Any chance that we resolve the bug instead of documenting it? :-) >>>> >>> Personally, I have no energy/time for that. It was documented for >>> ages, it is still documented in other BSDs. >> >> It has long ago been converted to a mount option instead of a >> tunefs command in NetBSD. My FreeBSD systems are patched that >> way since shortly after soft-updates was committed (long before >> it became available in NetBSD, IIRC); I have not checked whether >> they used the (very simple) patches I had posted at that time. >> >> Controlling soft-updates during mount has many advantages (not >> only if you decide to enable it on a root file-system that had >> been created without it) and no disadvantages. >> > > As the person who added this originally on behalf of Kirk, > I think the time for this has probably come. > I think even Kirk has said this might now make sense but I'd check > with him first. I had asked him and he replied that the mount option was better. But when I discussed this in a FreeBSD list, there was strong opposition and it was claimed, that sysinstall took care of it in such a way, that the users would not miss the mount option. I had strong arguments in favour of the mount option, but since there were different opinions that were strongly voiced, I just gave up and maintained the changes locally to this day. The arguments (of both sides) can be found in the mail archives. I think this change should have been made long before 7.0 (it could have been in 5.0 without problems). But I guess that ZFS will attract many previous UFS2/soft-updates users (I have converted most of my systems to ZFS with quite satisfactory results and could now live without soft-updates) and that the relevance of soft-updates will shrink for that reason. So if it is not changed in 7.0, I won't keep my local patches, since there will be no UFS file system on my systems (I'm using a ZFS root partition and have only a UFS boot partition). Regards, STefan From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 21 02:23:59 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2422416A419 for ; Sat, 21 Jul 2007 02:23:59 +0000 (UTC) (envelope-from ioplex@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.229]) by mx1.freebsd.org (Postfix) with ESMTP id DC69013C428 for ; Sat, 21 Jul 2007 02:23:58 +0000 (UTC) (envelope-from ioplex@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so875592wxd for ; Fri, 20 Jul 2007 19:23: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=LJcKXSLGM3om5/lMx0/FJ2EeqlJdNBuG3ztWeO1axEWhFgwghNedBzhU3HA5ld37TmG6Qi4mT+4JhlX1OGjPFVWX45Gd5hHAZGRYrZ/9Ov5FQFwwSaaLqjZGMAS5n2JZ0K9Q2FzN+JaNeJAmvEc1fOTHXtDfqXZXFfXc5Y+C69s= 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=LKNqNBCeIb9ZvIG7Z8hZy72VX9c8Sijhh8Cvg5GsEhF3aS35C34O/0KJmhA50EEH/rgU6Fki9tU6m8+KBujj+7aqu3TpDKkj2DjYEgeQPurSgQFQ389g9fMUoumHEBOZdH6mmeDLh+noQ3cvD+ZC3FfH8c7Ukalb2fhZFPMRJR4= Received: by 10.70.87.5 with SMTP id k5mr1850098wxb.1184984638139; Fri, 20 Jul 2007 19:23:58 -0700 (PDT) Received: by 10.70.38.11 with HTTP; Fri, 20 Jul 2007 19:23:58 -0700 (PDT) Message-ID: <78c6bd860707201923x5d94d609s8715ce58282d865@mail.gmail.com> Date: Fri, 20 Jul 2007 22:23:58 -0400 From: "Michael B Allen" 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: Get pid of child that has exited? 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, 21 Jul 2007 02:23:59 -0000 Hello, How does one get the pid if a child process that has exited? On other systems this is available in siginfo_t but si_pid seems to be 0. Is that normal? Mike From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 21 03:16:43 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CFE516A419 for ; Sat, 21 Jul 2007 03:16:43 +0000 (UTC) (envelope-from ioplex@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.224]) by mx1.freebsd.org (Postfix) with ESMTP id 1A7D113C474 for ; Sat, 21 Jul 2007 03:16:42 +0000 (UTC) (envelope-from ioplex@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so881429wxd for ; Fri, 20 Jul 2007 20:16:42 -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=bk0Rt8ZB3ZIQQfXz26yB2hVmzSBmLisRIo+GYAX++nFBxK48vtG5Vo2tJOPI5oC0zAZdXTNqm0xS7XuGVQzYgpsb21vjuks/+LG9kNnZZVkRYauRI3t0BQ9P55Nk7jTpE6HBHmxUXkn9kED6cIfwnuxH23TuFiPLdyRzoTIDXTk= 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=qDIzMDO0G87LlUjoXUs5hZvXWwhNH1ZK35ALP4SFCFQcRSHZcHFCDsYim47qwX4q690lcgDWDrGl5rj0FE/uA4SqtegK5/FUKNGs1a5tmeV8z9O3i7TmsqubE6Ack7xinxXzxHoxvggw7cCIYVlNpSowNuiLo301YuiSXT1Pmn8= Received: by 10.70.18.11 with SMTP id 11mr1857815wxr.1184987802376; Fri, 20 Jul 2007 20:16:42 -0700 (PDT) Received: by 10.70.38.11 with HTTP; Fri, 20 Jul 2007 20:16:41 -0700 (PDT) Message-ID: <78c6bd860707202016h2e9bf369oee7d14792fb1cf4c@mail.gmail.com> Date: Fri, 20 Jul 2007 23:16:42 -0400 From: "Michael B Allen" To: freebsd-hackers In-Reply-To: <78c6bd860707201923x5d94d609s8715ce58282d865@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <78c6bd860707201923x5d94d609s8715ce58282d865@mail.gmail.com> Subject: Re: Get pid of child that has exited? 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, 21 Jul 2007 03:16:43 -0000 On 7/20/07, Michael B Allen wrote: > Hello, > > How does one get the pid if a child process that has exited? On other > systems this is available in siginfo_t but si_pid seems to be 0. Is > that normal? Nevermind. I see siginfo_t isn't portable. I'm using waitpid now. Mike From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 21 04:04:24 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87AF216A418 for ; Sat, 21 Jul 2007 04:04:24 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 4BF2213C494 for ; Sat, 21 Jul 2007 04:04:23 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.8/8.13.4) with ESMTP id l6L41imq010264; Fri, 20 Jul 2007 22:01:44 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 20 Jul 2007 22:01:44 -0600 (MDT) Message-Id: <20070720.220144.74739925.imp@bsdimp.com> To: ioplex@gmail.com From: Warner Losh In-Reply-To: <78c6bd860707201923x5d94d609s8715ce58282d865@mail.gmail.com> References: <78c6bd860707201923x5d94d609s8715ce58282d865@mail.gmail.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Fri, 20 Jul 2007 22:01:44 -0600 (MDT) Cc: freebsd-hackers@freebsd.org Subject: Re: Get pid of child that has exited? 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, 21 Jul 2007 04:04:24 -0000 > How does one get the pid if a child process that has exited? On other > systems this is available in siginfo_t but si_pid seems to be 0. Is > that normal? wait4, wait3 and waitpid will all return it: If wait4(), wait3(), or waitpid() returns due to a stopped, continued, or terminated child process, the process ID of the child is returned to the calling process. If there are no children not previously awaited, -1 is returned with errno set to ECHILD. Otherwise, if WNOHANG is specified and there are no stopped, continued or exited children, 0 is returned. If an error is detected or a caught signal aborts the call, a value of -1 is returned and errno is set to indicate the error. I don't know if si_pid == 0 is normal. I rarely use SIGCHILD to get the status of a child process. Warner From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 21 12:11:14 2007 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C71B516A41F for ; Sat, 21 Jul 2007 12:11:14 +0000 (UTC) (envelope-from danger@rulez.sk) Received: from virtual.micronet.sk (smtp.micronet.sk [84.16.32.237]) by mx1.freebsd.org (Postfix) with ESMTP id 7631113C45E for ; Sat, 21 Jul 2007 12:11:14 +0000 (UTC) (envelope-from danger@rulez.sk) Received: from localhost (localhost [127.0.0.1]) by virtual.micronet.sk (Postfix) with ESMTP id B286410E629 for ; Sat, 21 Jul 2007 13:50:04 +0200 (CEST) X-Virus-Scanned: by amavisd-new at virtual.micronet.sk Received: from virtual.micronet.sk ([127.0.0.1]) by localhost (virtual.micronet.sk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kMNfcJL33bvI for ; Sat, 21 Jul 2007 13:50:03 +0200 (CEST) Received: from [10.50.0.2] (danger.mcrn.sk [84.16.37.254]) by virtual.micronet.sk (Postfix) with ESMTP id E324010E5EA for ; Sat, 21 Jul 2007 13:50:02 +0200 (CEST) Date: Sat, 21 Jul 2007 13:51:31 +0200 From: Daniel Gerzo X-Priority: 3 (Normal) Message-ID: <941152776.20070721135131@rulez.sk> To: hackers@freebsd.org In-Reply-To: <204397895.20070705123728@rulez.sk> References: <204397895.20070705123728@rulez.sk> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------1718A10517F41DB2" X-Mailman-Approved-At: Sat, 21 Jul 2007 12:20:30 +0000 Cc: Subject: Fwd: ng_fec man page (docs/114259) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Gerzo List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2007 12:11:14 -0000 ------------1718A10517F41DB2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, I am sending this email to hackers@ because I haven't heard from wpaul back and I suppose that there might be someone who has some knowledge about this part of system. I have checked the source code by myself, but C source is not really my area and somebody from here could have idea if I am right. Thanks in advance! This is a forwarded message From: Daniel Gerzo To: wpaul@FreeBSD.org Date: Thursday, July 5, 2007, 12:37:28 PM Subject: ng_fec man page (docs/114259) ===8<==============Original message text=============== Hello wpaul, I was looking throguh docs/114259 and it looks to me like submitter is correct, and I also found the other problem in the man page - NGM_FEC_MODE_MAC and NGM_FEC_MODE_INET should be repleaced by NGM_FEC_SET_MODE_MAC NGM_FEC_SET_MODE_INET. Could you please confirm this, so that I can work it out? -- Best regards, Daniel mailto:danger@FreeBSD.org ===8<===========End of original message text=========== -- Best regards, Daniel mailto:danger@rulez.sk ------------1718A10517F41DB2 Content-Type: message/rfc822; name="1.eml" Content-Disposition: attachment; filename="1.eml" Date: Thu, 5 Jul 2007 12:37:28 +0200 From: Daniel Gerzo Reply-To: Daniel Gerzo Organization: The FreeBSD Project X-Priority: 3 (Normal) Message-ID: <204397895.20070705123728@rulez.sk> To: wpaul@FreeBSD.org Subject: ng_fec man page (docs/114259) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello wpaul, I was looking throguh docs/114259 and it looks to me like submitter is correct, and I also found the other problem in the man page - NGM_FEC_MODE_MAC and NGM_FEC_MODE_INET should be repleaced by NGM_FEC_SET_MODE_MAC NGM_FEC_SET_MODE_INET. Could you please confirm this, so that I can work it out? -- Best regards, Daniel mailto:danger@FreeBSD.org ------------1718A10517F41DB2--