From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 31 00:48:52 2010 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 6228E106566C for ; Sun, 31 Oct 2010 00:48:52 +0000 (UTC) (envelope-from redcrash@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 24CDE8FC13 for ; Sun, 31 Oct 2010 00:48:51 +0000 (UTC) Received: by iwn39 with SMTP id 39so5351534iwn.13 for ; Sat, 30 Oct 2010 17:48:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=ObuMUgXw1kQN3WOK12DQ6zbzKWlnYvpXrFBK4Lnvito=; b=T9oeZsfRqP95H4dZV2FdWZpCmPlbtWThOg0WaQ5I7KcEbyRIVFrMYF6ruLLY5+9Orm 3jy0zLIE0XyZC6i7PzePB1wmhcuuBKtq/DScvz+97Kkr3D/LPjG9tI7q7ZFeIRyWX4is kfCNlWu93FS7F9cOit0w3dLaH6TugCpg70u5E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=JLglUtwso5HslPXQmW5jKnawBJhJt8b+1I6rPtNoRnbsQb7/vmHDR4UlzUSmOFPZUt OoUnthy6mXkwz7GRRtABsPu5sOZ+iFmFUvcvDYX3o5h/p/p+vvqGgid7IX3yz2dnQEau z61bY8k6M5IU86dufg28hDfaflw9KENV5vBfw= MIME-Version: 1.0 Received: by 10.231.85.206 with SMTP id p14mr10443462ibl.89.1288486129383; Sat, 30 Oct 2010 17:48:49 -0700 (PDT) Received: by 10.231.38.7 with HTTP; Sat, 30 Oct 2010 17:48:49 -0700 (PDT) In-Reply-To: <20101030224001.GA10529@mark-laptop-bsd.mark-home> References: <4CCC7C07.8080903@FreeBSD.org> <20101030220828.GA24395@stack.nl> <20101030224001.GA10529@mark-laptop-bsd.mark-home> Date: Sun, 31 Oct 2010 02:48:49 +0200 Message-ID: From: Harald Servat To: Mark Johnston Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org, Jilles Tjoelker Subject: Re: Space character in rc.conf variable 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, 31 Oct 2010 00:48:52 -0000 Wow! It looks like the subject arised some issues which are out of my knowledge. Right now, I can follow Doug's suggestion to change my SSID. Thank you for all your comments. 2010/10/31 Mark Johnston > On Sun, Oct 31, 2010 at 12:08:28AM +0200, Jilles Tjoelker wrote: > > Array support in the shell could make this easier, but not much unless > > the rc.conf syntax would be changed as well, like > > ifconfig_wlan0=(ssid "SSID WITH SPACE" dhcp) > > but then changed some more such that "DHCP" can be used as SSID. > > > > Array support would add a fair bit of code to sh, and even then it will > > remain fairly limited and clumsy. For example, an array can only be > > returned from a function by passing the name of an existing array to > > place the result in and using eval, extending setvar in some strange way > > or implementing another ksh93 extension, namerefs. > > > > -- > > Jilles Tjoelker > > Incidentally, I've actually been working on this, though it was more for > fun than anything else - my impression is that new features for sh(1) > are generally unwelcome because of the testing required and the > possibility of regressions. I have some of the syntax working, e.g. > > $ foo[1]=one > $ foo[2]=two > $ foo[3]=three > $ echo ${foo[1]} ${foo[2]} ${foo[3]} > one two three > $ unset foo[2] > $ echo ${foo[1]} ${foo[2]} ${foo[3]} > one three > > It was while working on the ${#arr[@]} syntax that I ran into > bin/151720. > > If people are actually interested in this, I can discuss my changes in > more detail. The actually array implementation is quite simple, around > 200 LOC... a number of changes to var.c, parser.c and eval.c are > necessary however. > > -Mark > _______________________________________________ > 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" > -- _________________________________________________________________ Fry: You can see how I lived before I met you. Bender: You lived before you met me?! Fry: Yeah, lots of people did. Bender: Really?! From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 31 04:12:57 2010 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 75E81106564A for ; Sun, 31 Oct 2010 04:12:57 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id 536F68FC12 for ; Sun, 31 Oct 2010 04:12:57 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id o9V4CuN8097434 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 30 Oct 2010 21:12:56 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id o9V4CuZY097433; Sat, 30 Oct 2010 21:12:56 -0700 (PDT) Received: from fbsd61 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA24856; Sat, 30 Oct 10 21:06:00 PDT Date: Sat, 30 Oct 2010 21:05:36 -0700 From: perryh@pluto.rain.com To: cronfy@gmail.com Message-Id: <4ccceb10.4n2iAQ/sY/YrDSI2%perryh@pluto.rain.com> References: In-Reply-To: User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Slow disk access while rsync - what should I tune? 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, 31 Oct 2010 04:12:57 -0000 cronfy wrote: > And also, maybe there are other ways to create incremental backups > instead of using rsync/hardlinks? Yes. Use dump(8) -- that's what it's for. It reads the inodes, directories, and files directly from the disk device, thereby eliminating stat() overhead entirely. Any replication mechanism -- rsync, tar, even dd -- can be used as a backup mechanism, but dump was specifically designed for the purpose. From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 31 16:35:36 2010 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 4A95F106566C for ; Sun, 31 Oct 2010 16:35:36 +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 860098FC17 for ; Sun, 31 Oct 2010 16:35:35 +0000 (UTC) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.14.4/8.14.1) with ESMTP id o9VGZGPY046167; Sun, 31 Oct 2010 09:35:16 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.14.4/8.13.4/Submit) id o9VGZG1O046164; Sun, 31 Oct 2010 09:35:16 -0700 (PDT) Date: Sun, 31 Oct 2010 09:35:16 -0700 (PDT) From: Matthew Dillon Message-Id: <201010311635.o9VGZG1O046164@apollo.backplane.com> To: perryh@pluto.rain.com References: <4ccceb10.4n2iAQ/sY/YrDSI2%perryh@pluto.rain.com> Cc: cronfy@gmail.com, freebsd-hackers@freebsd.org Subject: Re: Slow disk access while rsync - what should I tune? 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, 31 Oct 2010 16:35:36 -0000 :cronfy wrote: : :> And also, maybe there are other ways to create incremental backups :> instead of using rsync/hardlinks? : :Yes. Use dump(8) -- that's what it's for. It reads the inodes, :directories, and files directly from the disk device, thereby :eliminating stat() overhead entirely. : :Any replication mechanism -- rsync, tar, even dd -- can be used :as a backup mechanism, but dump was specifically designed for the :purpose. Well, dump is 25+ years old and has some serious issues when it comes to reliably backing data up. On a modern (large) filesystem you are virtually guaranteed to get corruption due to the asynchronous nature of the dump. This can be partially mitigated by using a block level snapshot on the UFS source filesystem and then dumping the snapshot instead of the live filesystem, but that opens up a pandora's box of other issues (such as whether issuing the snapshot itself will destabilize the machine), plus the live system will stall while it is making the snapshot, assuming you want a consistent snapshot, plus the snapshot itself may not be entirely consistent, depending on how it is made. Plus dump uses mtime to detect changes, which is unreliable, and the output produced by dump is not live-accessible whereas a snapshot / live filesystem copy is. That makes the dump fairly worthless for anything other than catastrophic recovery. From experience, most people need to access backups to pull out small bits of information rather than whole filesystems, such as to restore a user's home directory or web pages, and dump/restore is really unsuitable for that sort of thing. Live backups are far, far, far superior to dump/restore. -Matt From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 31 17:15:38 2010 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 DAB381065679 for ; Sun, 31 Oct 2010 17:15:38 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 848148FC15 for ; Sun, 31 Oct 2010 17:15:38 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.4/8.14.4) with ESMTP id o9VGc6ns009514 for ; Sun, 31 Oct 2010 10:38:06 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.4/8.14.4/Submit) with ESMTP id o9VGc6R4009511 for ; Sun, 31 Oct 2010 10:38:06 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Sun, 31 Oct 2010 10:38:06 -0600 (MDT) From: Warren Block To: hackers@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (wonkity.com [127.0.0.1]); Sun, 31 Oct 2010 10:38:06 -0600 (MDT) Cc: Subject: ccache pausing in buildworld 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, 31 Oct 2010 17:15:38 -0000 About a month ago, ccache began to pause in buildworld. The build doesn't halt or quit, it stays running but not doing anything: /usr/local/libexec/ccache/world-cc -fpic -DPIC -O2 -pipe -march=prescott -I/usr/src/lib/libc/include -I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/i386-DNLS -D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa -DINET6 -I/usr/obj/usr/src/lib/libc -I/usr/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c crypt_xdr.c -o crypt_xdr.So And there it stays: load: 0.02 cmd: make 83143 [select] 401.32r 0.05u 0.05s 0% 852k load: 0.01 cmd: make 83143 [select] 409.08r 0.05u 0.05s 0% 852k load: 0.01 cmd: make 83143 [select] 422.00r 0.05u 0.05s 0% 852k The file where it pauses varies depending on the number of jobs (-j) option. The example above is with -j6; -j1 doesn't fix it, although it pauses on nslexer.c instead. This is on 8-stable as of today, i386. The -march=prescott option comes from CPUTYPE?=core2 in make.conf, and removing that setting doesn't fix the problem. buildworld without ccache works fine, just takes more than twice as long. The kernel target works fine with or without ccache. Any ideas? From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 31 20:14:31 2010 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 0EAB2106566B for ; Sun, 31 Oct 2010 20:14:31 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id C4EEE8FC16 for ; Sun, 31 Oct 2010 20:14:30 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id o9VKERS1008392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 31 Oct 2010 13:14:27 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id o9VKERkx008391; Sun, 31 Oct 2010 13:14:27 -0700 (PDT) Received: from fbsd61 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA27545; Sun, 31 Oct 10 12:12:52 PST Date: Sun, 31 Oct 2010 13:12:26 -0700 From: perryh@pluto.rain.com To: dillon@apollo.backplane.com Message-Id: <4ccdcdaa.XSDkZZUUYXDXpkXV%perryh@pluto.rain.com> References: <4ccceb10.4n2iAQ/sY/YrDSI2%perryh@pluto.rain.com> <201010311635.o9VGZG1O046164@apollo.backplane.com> In-Reply-To: <201010311635.o9VGZG1O046164@apollo.backplane.com> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: cronfy@gmail.com, freebsd-hackers@freebsd.org Subject: Re: Slow disk access while rsync - what should I tune? 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, 31 Oct 2010 20:14:31 -0000 [missing attribution restored] Matthew Dillon wrote: > perryh@pluto.rain.com wrote: > :cronfy wrote: > : > :> And also, maybe there are other ways to create incremental backups > :> instead of using rsync/hardlinks? > : > :Yes. Use dump(8) -- that's what it's for. It reads the inodes, > :directories, and files directly from the disk device, thereby > :eliminating stat() overhead entirely. > : > :Any replication mechanism -- rsync, tar, even dd -- can be used > :as a backup mechanism, but dump was specifically designed for the > :purpose. > Well, dump is 25+ years old ... Why are you running BSD if you prefer newer (=> less mature) stuff? Switch to Linux! > ... On a modern (large) filesystem you are virtually guaranteed > to get corruption due to the asynchronous nature of the dump. > > This can be partially mitigated by using a block level snapshot on > the UFS source filesystem and then dumping the snapshot instead of > the live filesystem ... IOW by using "dump -L" > Plus dump uses mtime to detect changes, which is unreliable, ... Are you sure about that? Last I knew it used ctime. > and the output produced by dump is not live-accessible whereas a > snapshot / live filesystem copy is. That makes the dump fairly > worthless for anything other than catastrophic recovery. Ever heard of "restore -i"? From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 31 20:44:40 2010 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 9A033106564A for ; Sun, 31 Oct 2010 20:44:40 +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 5A4B68FC13 for ; Sun, 31 Oct 2010 20:44:40 +0000 (UTC) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.14.4/8.14.1) with ESMTP id o9VKiPh8049616; Sun, 31 Oct 2010 13:44:25 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.14.4/8.13.4/Submit) id o9VKiPwG049615; Sun, 31 Oct 2010 13:44:25 -0700 (PDT) Date: Sun, 31 Oct 2010 13:44:25 -0700 (PDT) From: Matthew Dillon Message-Id: <201010312044.o9VKiPwG049615@apollo.backplane.com> To: perryh@pluto.rain.com References: <4ccceb10.4n2iAQ/sY/YrDSI2%perryh@pluto.rain.com> <201010311635.o9VGZG1O046164@apollo.backplane.com> <4ccdcdaa.XSDkZZUUYXDXpkXV%perryh@pluto.rain.com> Cc: cronfy@gmail.com, freebsd-hackers@freebsd.org Subject: Re: Slow disk access while rsync - what should I tune? 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, 31 Oct 2010 20:44:40 -0000 :> and the output produced by dump is not live-accessible whereas a :> snapshot / live filesystem copy is. That makes the dump fairly :> worthless for anything other than catastrophic recovery. : :Ever heard of "restore -i"? Have you ever tried to restore a single file from a 2 Terrabyte dump file ? Or even better, if you are using incremental dumps, try restoring a single file from 6 dump files. I'm not saying that dump/restore is completely unusable, I'm saying that it MOSTLY unusable for the use cases people have today for backups. There is a certain convenience to being able to restore a file from a live backup in a few seconds verses having to struggle with large multi-layered incremental dump/restore files that were designed to be spooled off to tape units. -Matt Matthew Dillon From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 31 23:05:02 2010 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 0D6641065672 for ; Sun, 31 Oct 2010 23:05:02 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 9027D8FC13 for ; Sun, 31 Oct 2010 23:05:01 +0000 (UTC) Received: by wwi17 with SMTP id 17so3719495wwi.31 for ; Sun, 31 Oct 2010 16:05:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=ZF+fLhaAZbspjPB0pg0OHcL6NORCw67UOOdiObIJFVs=; b=AH2Rw47vLCi0eUAA9BsDPTXw6ltGLyydSQ+O0+vJfE5FvaZTN9b9JKJx1dpTTGVHn9 OlswTMXI3VHNn6gRRcQ7Km2TZXehr176vQQTks79jo8k2GMz0ZSuNPEhgX1CXk9J6350 1fFhb4jRIqWw+Nm2bQMfgEpPSJTAM6AQLZUCc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=oRP5jnYGkc/KILnsjeHXFVhe2pMtBcIPYqYfNj5uuObP1bDQcFZla0TKlKRRUQNNbh tB2dKQY20qs6UKkJ7Cq5nozDfMEI1DrBVDP6zW0QqdetO93cBjeaTReADgpgyjL/SBPd wltrN7W1EhnzcVUwITfLKBdYP3D1pmpEdMV64= MIME-Version: 1.0 Received: by 10.216.46.200 with SMTP id r50mr1994327web.45.1288566300043; Sun, 31 Oct 2010 16:05:00 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.216.198.27 with HTTP; Sun, 31 Oct 2010 16:05:00 -0700 (PDT) In-Reply-To: References: Date: Sun, 31 Oct 2010 16:05:00 -0700 X-Google-Sender-Auth: 6qlj3Y8IPucWEquaMn5IEZA_BCo Message-ID: From: Garrett Cooper To: Warren Block Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: hackers@freebsd.org Subject: Re: ccache pausing in buildworld 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, 31 Oct 2010 23:05:02 -0000 On Sun, Oct 31, 2010 at 9:38 AM, Warren Block wrote: > About a month ago, ccache began to pause in buildworld. =A0The build does= n't > halt or quit, it stays running but not doing anything: > > /usr/local/libexec/ccache/world-cc -fpic -DPIC -O2 -pipe -march=3Dprescot= t > -I/usr/src/lib/libc/include -I/usr/src/lib/libc/../../include > -I/usr/src/lib/libc/i386-DNLS -D__DBINTERFACE_PRIVATE > -I/usr/src/lib/libc/../../contrib/gdtoa -DINET6 -I/usr/obj/usr/src/lib/li= bc > -I/usr/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE > -I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN > -I/usr/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu9= 9 > -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k > -Wno-uninitialized -Wno-pointer-sign -c crypt_xdr.c -o crypt_xdr.So > > And there it stays: > > =A0load: 0.02 =A0cmd: make 83143 [select] 401.32r 0.05u 0.05s 0% 852k > =A0load: 0.01 =A0cmd: make 83143 [select] 409.08r 0.05u 0.05s 0% 852k > =A0load: 0.01 =A0cmd: make 83143 [select] 422.00r 0.05u 0.05s 0% 852k > > The file where it pauses varies depending on the number of jobs (-j) opti= on. > =A0The example above is with -j6; -j1 doesn't fix it, although it pauses = on > nslexer.c instead. > > This is on 8-stable as of today, i386. =A0The -march=3Dprescott option co= mes > from CPUTYPE?=3Dcore2 in make.conf, and removing that setting doesn't fix= the > problem. > > buildworld without ccache works fine, just takes more than twice as long. > > The kernel target works fine with or without ccache. > > Any ideas? Have you tried trussing or ktrace'ing the processes to determine where they get stuck? Thanks, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 1 00:21:02 2010 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 E7F40106564A for ; Mon, 1 Nov 2010 00:21:02 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id A46378FC16 for ; Mon, 1 Nov 2010 00:21:02 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.4/8.14.4) with ESMTP id oA10L14M011056; Sun, 31 Oct 2010 18:21:01 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.4/8.14.4/Submit) with ESMTP id oA10L17F011053; Sun, 31 Oct 2010 18:21:01 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Sun, 31 Oct 2010 18:21:01 -0600 (MDT) From: Warren Block To: Garrett Cooper In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-902635197-645990358-1288570243=:10943" Content-ID: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (wonkity.com [127.0.0.1]); Sun, 31 Oct 2010 18:21:01 -0600 (MDT) Cc: hackers@FreeBSD.org Subject: Re: ccache pausing in buildworld 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, 01 Nov 2010 00:21:03 -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. ---902635197-645990358-1288570243=:10943 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-15; FORMAT=flowed Content-Transfer-Encoding: 8BIT Content-ID: On Sun, 31 Oct 2010, Garrett Cooper wrote: > On Sun, Oct 31, 2010 at 9:38 AM, Warren Block wrote: >> About a month ago, ccache began to pause in buildworld.  The build doesn't >> halt or quit, it stays running but not doing anything: >> >> /usr/local/libexec/ccache/world-cc -fpic -DPIC -O2 -pipe -march=prescott >> -I/usr/src/lib/libc/include -I/usr/src/lib/libc/../../include >> -I/usr/src/lib/libc/i386-DNLS -D__DBINTERFACE_PRIVATE >> -I/usr/src/lib/libc/../../contrib/gdtoa -DINET6 -I/usr/obj/usr/src/lib/libc >> -I/usr/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE >> -I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN >> -I/usr/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 >> -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k >> -Wno-uninitialized -Wno-pointer-sign -c crypt_xdr.c -o crypt_xdr.So >> >> And there it stays: >> >>  load: 0.02  cmd: make 83143 [select] 401.32r 0.05u 0.05s 0% 852k >>  load: 0.01  cmd: make 83143 [select] 409.08r 0.05u 0.05s 0% 852k >>  load: 0.01  cmd: make 83143 [select] 422.00r 0.05u 0.05s 0% 852k > > Have you tried trussing or ktrace'ing the processes to determine > where they get stuck? Not until now: # truss -p 89904 wait4(0xffffffff,0xbfbfdda8,0x3,0x0,0x0,0x0) = 0 (0x0) select(1024,{4},0x0,0x0,{2.000000 }) = 0 (0x0) wait4(0xffffffff,0xbfbfdda8,0x3,0x0,0x0,0x0) = 0 (0x0) select(1024,{4},0x0,0x0,{2.000000 }) = 0 (0x0) Like it's waiting for input. Yet do it alone, and it works fine: # cd /usr/obj/usr/src/lib/libc # /usr/local/libexec/ccache/world-cc -O2 -pipe -march=prescott -I/usr/src/lib/libc/include -I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/i386 -DNLS -D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa -DINET6 -I/usr/obj/usr/src/lib/libc -I/usr/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c nslexer.c # Emanuel Haupt points out ports/151287, which is the same thing. ---902635197-645990358-1288570243=:10943-- From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 1 01:02:28 2010 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 DCDD8106564A for ; Mon, 1 Nov 2010 01:02:27 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 680A58FC14 for ; Mon, 1 Nov 2010 01:02:27 +0000 (UTC) Received: by wwi17 with SMTP id 17so3773687wwi.31 for ; Sun, 31 Oct 2010 18:02:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=IlCvdZpsPo1fU5KC/kcfkZNzM0TQS+qqu5UcEhEllpE=; b=lB0eiYY06sP1iyNbM8vecLRH46AYNQzTp9siJ4rpfSLPS35R8uB4WI3x+SOrpkbl7O gzpN/+65CQ/TySEI5z4lbANMsVQnjM5TLneUJwi0QaP6C48fS8Z+TBwoOktw6xbhsRjJ QwXUS20WeQbuW7mzo2epVUtDzK1AR5lMtb3OM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=pxUblYNP8ibJb4Qb7TBhkN2VtJqXMTTOUTxHdsDFaAteISjoFbNlKp6s2GaN2wE+eq MO/qlQIAW2XO5mQgmE9GN6imcpgV83l6If4k38ipWKvARxS1/aLtfOlz/j39Xsefyk/i 8CAvJXTYSR7v5Agu1UgisKpgJ1uFb/Gg0LTLE= MIME-Version: 1.0 Received: by 10.216.175.83 with SMTP id y61mr14900357wel.30.1288573346208; Sun, 31 Oct 2010 18:02:26 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.216.198.27 with HTTP; Sun, 31 Oct 2010 18:02:26 -0700 (PDT) In-Reply-To: References: Date: Sun, 31 Oct 2010 18:02:26 -0700 X-Google-Sender-Auth: FxUPFm3VNrwyznu6ticGNEULRm4 Message-ID: From: Garrett Cooper To: Warren Block Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: hackers@freebsd.org Subject: Re: ccache pausing in buildworld 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, 01 Nov 2010 01:02:28 -0000 On Sun, Oct 31, 2010 at 5:21 PM, Warren Block wrote: > On Sun, 31 Oct 2010, Garrett Cooper wrote: > >> On Sun, Oct 31, 2010 at 9:38 AM, Warren Block wrote= : >>> >>> About a month ago, ccache began to pause in buildworld. =A0The build >>> doesn't >>> halt or quit, it stays running but not doing anything: >>> >>> /usr/local/libexec/ccache/world-cc -fpic -DPIC -O2 -pipe -march=3Dpresc= ott >>> -I/usr/src/lib/libc/include -I/usr/src/lib/libc/../../include >>> -I/usr/src/lib/libc/i386-DNLS -D__DBINTERFACE_PRIVATE >>> -I/usr/src/lib/libc/../../contrib/gdtoa -DINET6 >>> -I/usr/obj/usr/src/lib/libc >>> -I/usr/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE >>> -I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN >>> -I/usr/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgn= u99 >>> -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k >>> -Wno-uninitialized -Wno-pointer-sign -c crypt_xdr.c -o crypt_xdr.So >>> >>> And there it stays: >>> >>> =A0load: 0.02 =A0cmd: make 83143 [select] 401.32r 0.05u 0.05s 0% 852k >>> =A0load: 0.01 =A0cmd: make 83143 [select] 409.08r 0.05u 0.05s 0% 852k >>> =A0load: 0.01 =A0cmd: make 83143 [select] 422.00r 0.05u 0.05s 0% 852k >> >> =A0 Have you tried trussing or ktrace'ing the processes to determine >> where they get stuck? > > Not until now: > > # truss -p 89904 > wait4(0xffffffff,0xbfbfdda8,0x3,0x0,0x0,0x0) =A0 =A0 =3D 0 (0x0) > select(1024,{4},0x0,0x0,{2.000000 }) =A0 =A0 =A0 =A0 =A0 =A0 =3D 0 (0x0) > wait4(0xffffffff,0xbfbfdda8,0x3,0x0,0x0,0x0) =A0 =A0 =3D 0 (0x0) > select(1024,{4},0x0,0x0,{2.000000 }) =A0 =A0 =A0 =A0 =A0 =A0 =3D 0 (0x0) > > Like it's waiting for input. =A0Yet do it alone, and it works fine: > > =A0# cd /usr/obj/usr/src/lib/libc > =A0# /usr/local/libexec/ccache/world-cc -O2 -pipe -march=3Dprescott > -I/usr/src/lib/libc/include -I/usr/src/lib/libc/../../include > -I/usr/src/lib/libc/i386 -DNLS -D__DBINTERFACE_PRIVATE > -I/usr/src/lib/libc/../../contrib/gdtoa -DINET6 -I/usr/obj/usr/src/lib/li= bc > -I/usr/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE > -I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN > -I/usr/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu9= 9 > -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k > -Wno-uninitialized -Wno-pointer-sign -c nslexer.c > =A0# > > Emanuel Haupt points out ports/151287, which is the same thing. Question is, is it ccache's fault, or something else's? FWIW, it would be really nice to see what the 4th file descriptor actually maps to, and what command is being run at the time, as well as what other commands are being run. Thanks, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 1 02:53:53 2010 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 A6945106566B; Mon, 1 Nov 2010 02:53:53 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 05CC48FC1B; Mon, 1 Nov 2010 02:53:52 +0000 (UTC) Received: by fxm17 with SMTP id 17so4768295fxm.13 for ; Sun, 31 Oct 2010 19:53:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=YnYjWIv9JCDuZueisYpnB4j8s2fUDRXN0WZBbwrrMeU=; b=QCHspP5PgCAnz4T7z1xs2/1KFNOw0niQg97p05+ZfweNHq7hvX9Paq1jXZxQLesBs8 uZ9lCCmgdG5dc0rBzX/2B9/JEj2f4AnjNxnCg+rMUSXC2ql3upMk3LBxxSljsoWqPo1/ fbzuX6z9owHA5xg2iMT/fjcgbVoEx3aA+eryo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=qCqe7prHC/kSEsTPD/IuiLxyXOv4eXgPXg90UuMiG0P7iDnya1SbYHmiEM8/ncmGyp a1fUH4EDrECwlaeKnTaD3SKtHN0takcqGpzFC29QTnrNP/kuhS/WDA05NQxYI4ePSiv9 J4iKVYuflpCqk/1EyY0y/7ylUGfjgSXb39mFs= MIME-Version: 1.0 Received: by 10.223.86.4 with SMTP id q4mr6725111fal.20.1288578665114; Sun, 31 Oct 2010 19:31:05 -0700 (PDT) Received: by 10.223.108.194 with HTTP; Sun, 31 Oct 2010 19:31:05 -0700 (PDT) In-Reply-To: References: Date: Sun, 31 Oct 2010 21:31:05 -0500 Message-ID: From: Adam Vande More To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: hackers@freebsd.org Subject: Re: ccache pausing in buildworld 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, 01 Nov 2010 02:53:53 -0000 On Sun, Oct 31, 2010 at 8:02 PM, Garrett Cooper wrote: > Question is, is it ccache's fault, or something else's? > FWIW, it would be really nice to see what the 4th file descriptor > actually maps to, and what command is being run at the time, as well > as what other commands are being run. > The error doesn't seem to appear when ccache is disabled. Another data point is that the is an error spit out when ccache is run with a clean cache. w/ -j8: /usr/local/libexec/ccache/world-cc -O2 -fno-strict-aliasing -pipe -I/usr/src/lib/libc/include -I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/i386 -DNLS -D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa -DINET6 -I/usr/obj/lib32/usr/src/lib/libc -I/usr/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c fork.S /usr/local/libexec/ccache/world-cc -DPROF -O2 -fno-strict-aliasing -pipe -I/usr/src/lib/libc/include -I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/i386 -DNLS -D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa -DINET6 -I/usr/obj/lib32/usr/src/lib/libc -I/usr/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c fork.S -o fork.po /usr/local/libexec/ccache/world-cc -fpic -DPIC -O2 -fno-strict-aliasing -pipe -I/usr/src/lib/libc/include -I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/i386 -DNLS -D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa -DINET6 -I/usr/obj/lib32/usr/src/lib/libc -I/usr/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c fork.S -o fork.So /usr/local/libexec/ccache/world-cc -O2 -fno-strict-aliasing -pipe -I/usr/src/lib/libc/include -I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/i386 -DNLS -D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa -DINET6 -I/usr/obj/lib32/usr/src/lib/libc -I/usr/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c read.S /usr/local/libexec/ccache/world-cc -DPROF -O2 -fno-strict-aliasing -pipe -I/usr/src/lib/libc/include -I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/i386 -DNLS -D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa -DINET6 -I/usr/obj/lib32/usr/src/lib/libc -I/usr/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c read.S -o read.po /usr/local/libexec/ccache/world-cc -fpic -DPIC -O2 -fno-strict-aliasing -pipe -I/usr/src/lib/libc/include -I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/i386 -DNLS -D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa -DINET6 -I/usr/obj/lib32/usr/src/lib/libc -I/usr/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c read.S -o read.So /usr/local/libexec/ccache/world-cc -O2 -fno-strict-aliasing -pipe -I/usr/src/lib/libc/include -I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/i386 -DNLS -D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa -DINET6 -I/usr/obj/lib32/usr/src/lib/libc -I/usr/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c write.S /usr/local/libexec/ccache/world-cc -DPROF -O2 -fno-strict-aliasing -pipe -I/usr/src/lib/libc/include -I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/i386 -DNLS -D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa -DINET6 -I/usr/obj/lib32/usr/src/lib/libc -I/usr/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c write.S -o write.po fork.S: Assembler messages: fork.S:3: Error: invalid character '_' in mnemonic fork.S: Assembler messages: fork.S:3: Error: invalid character '_' in mnemonic fork.S: Assembler messages: fork.S:3: Error: invalid character '_' in mnemonic *** Error code 1 *** Error code 1 read.S: Assembler messages: read.S:3: Error: invalid character '_' in mnemonic *** Error code 1 *** Error code 1 read.S: Assembler messages: read.S:3: Error: invalid character '_' in mnemonic *** Error code 1 write.S: Assembler messages: write.S:3: Error: invalid character '_' in mnemonic *** Error code 1 read.S: Assembler messages: read.S:3: Error: invalid character '_' in mnemonic *** Error code 1 write.S: Assembler messages: write.S:3: Error: invalid character '_' in mnemonic *** Error code 1 8 errors *** Error code 2 2 errors *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error -- Adam Vande More From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 1 07:17:03 2010 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 32521106564A for ; Mon, 1 Nov 2010 07:17:03 +0000 (UTC) (envelope-from j.mckeown@ru.ac.za) Received: from f.mail.ru.ac.za (f.mail.ru.ac.za [IPv6:2001:4200:1010::25:6]) by mx1.freebsd.org (Postfix) with ESMTP id 34C548FC12 for ; Mon, 1 Nov 2010 07:17:02 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ru-msa; d=ru.ac.za; h=Received:From:Organization:To:Subject:Date:User-Agent:References:In-Reply-To:X-Face:MIME-Version:Content-Type:Content-Transfer-Encoding:Content-Disposition:Message-Id:X-Virus-Scanned:X-Authenticated-User; b=RiPLgHdCP8Y0BoBWj1kHurBtEC9U/EsAk9+UAe0/afz/EfHizLSA1lLUUP9yttcfLwUiYQPKEwD5fu+Q0dXG/KQ4IJQTjAgTXNpTHnss4YoB2T427fCMFSSNdXm5/2xA; Received: from vorkosigan.ru.ac.za ([2001:4200:1010:1058:219:d1ff:fe9f:a932]:57368) by f.mail.ru.ac.za with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1PCodX-000A4i-Ey for freebsd-hackers@freebsd.org; Mon, 01 Nov 2010 09:16:59 +0200 From: Jonathan McKeown Organization: Rhodes University To: freebsd-hackers@freebsd.org Date: Mon, 1 Nov 2010 09:16:58 +0200 User-Agent: KMail/1.9.10 References: <4ccdcdaa.XSDkZZUUYXDXpkXV%perryh@pluto.rain.com> <201010312044.o9VKiPwG049615@apollo.backplane.com> In-Reply-To: <201010312044.o9VKiPwG049615@apollo.backplane.com> X-Face: $@VrUx^RHy/}yu]jKf/<4T%/d|F+$j-Ol2"2J$q+%OK1]&/G_S9(=?utf-8?q?HkaQ*=60!=3FYOK=3FY!=27M=60C=0A=09aP=5C9nVPF8Q=7DCilHH8l=3B=7E!4?= =?utf-8?q?2HK6=273lg4J=7Daz?=@1Dqqh:J]M^"YPn*2IWrZON$1+G?oX3@ =?utf-8?q?k=230=0A=0954XDRg=3DYn=5FF-etwot4U=24b?=dTS{i X-Virus-Scanned: f.mail.ru.ac.za (2001:4200:1010::25:6) X-Authenticated-User: s0900137 from vorkosigan.ru.ac.za (2001:4200:1010:1058:219:d1ff:fe9f:a932) using auth_plaintext Subject: Re: Slow disk access while rsync - what should I tune? 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, 01 Nov 2010 07:17:03 -0000 On Sunday 31 October 2010 22:44:25 Matthew Dillon wrote: > :> and the output produced by dump is not live-accessible whereas a > :> snapshot / live filesystem copy is. That makes the dump fairly > :> worthless for anything other than catastrophic recovery. > : > :Ever heard of "restore -i"? > > Have you ever tried to restore a single file from a 2 Terrabyte dump > file ? Or even better, if you are using incremental dumps, try > restoring a single file from 6 dump files. > > I'm not saying that dump/restore is completely unusable, I'm saying > that it MOSTLY unusable for the use cases people have today for > backups. I'd argue that if you're routinely restoring single files, you aren't managing your time or your users' expectations properly. Backups are /for/ catastrophic recovery, imo, and users shouldn't expect systems staff to be routinely restoring single files they've inadvertently deleted. Users need to realise that when you delete something it goes away: that's what delete does, which is why you're usually asked to confirm it. Restoring single files for individual users should be very much a special case and not a routine service; otherwise you risk being snowed under with file recovery requests. Jonathan From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 1 07:18:40 2010 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 DDF801065670 for ; Mon, 1 Nov 2010 07:18:40 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6F8878FC0C for ; Mon, 1 Nov 2010 07:18:40 +0000 (UTC) Received: by wyb42 with SMTP id 42so5167354wyb.13 for ; Mon, 01 Nov 2010 00:18:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=LtLGUbhGJnp2m8m+yCSYkYCDAvU7Xhx4BFdj59Jyt9o=; b=B2QVnvdSq6KQF8jkUs7buQ5B594dUQbcR1h935fkwpt1i03/cOrbIIsnw8szskMW6R r9MhxDYDlQL8qB0Dsl9pcmjiVjxkjl6S5t9AdyxvqcuEfFMKdFUqFng1WuBcdE1jP/7M u8RjrM5pf54dsFxwEJLhWsNJdC+rwgR5ro2sk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=TWRw4Y3BCqTRAHjkAxS8dz+Jtxcj00lZu+XwrdWxHKmu7Mnk1r9FayuLjIWow7+dB/ ybdt4Wwr9eRbdlRIVvaQgXMlcrfKETgFnRlh0P3w9dgCd4Y0Bab2LTQ5eZQraWpOczCM 8wrgc+QFRAcImm6+lzNMR+dzXieOey6QC7SYo= MIME-Version: 1.0 Received: by 10.216.7.210 with SMTP id 60mr2341408wep.30.1288595919336; Mon, 01 Nov 2010 00:18:39 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.216.198.27 with HTTP; Mon, 1 Nov 2010 00:18:39 -0700 (PDT) In-Reply-To: <201011010916.59108.j.mckeown@ru.ac.za> References: <4ccdcdaa.XSDkZZUUYXDXpkXV%perryh@pluto.rain.com> <201010312044.o9VKiPwG049615@apollo.backplane.com> <201011010916.59108.j.mckeown@ru.ac.za> Date: Mon, 1 Nov 2010 00:18:39 -0700 X-Google-Sender-Auth: uRql-DN4CM5iS4Vabi_yPM_FCbk Message-ID: From: Garrett Cooper To: Jonathan McKeown Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: Slow disk access while rsync - what should I tune? 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, 01 Nov 2010 07:18:40 -0000 On Mon, Nov 1, 2010 at 12:16 AM, Jonathan McKeown wrot= e: > On Sunday 31 October 2010 22:44:25 Matthew Dillon wrote: >> :> and the output produced by dump is not live-accessible whereas a >> :> snapshot / live filesystem copy is. =A0That makes the dump fairly >> :> worthless for anything other than catastrophic recovery. >> : >> :Ever heard of "restore -i"? >> >> =A0 =A0 Have you ever tried to restore a single file from a 2 Terrabyte = dump >> =A0 =A0 file ? =A0Or even better, if you are using incremental dumps, tr= y >> =A0 =A0 restoring a single file from 6 dump files. >> >> =A0 =A0 I'm not saying that dump/restore is completely unusable, I'm say= ing >> =A0 =A0 that it MOSTLY unusable for the use cases people have today for >> backups. > > I'd argue that if you're routinely restoring single files, you aren't man= aging > your time or your users' expectations properly. > > Backups are /for/ catastrophic recovery, imo, and users shouldn't expect > systems staff to be routinely restoring single files they've inadvertentl= y > deleted. Users need to realise that when you delete something it goes awa= y: > that's what delete does, which is why you're usually asked to confirm it. > > Restoring single files for individual users should be very much a special= case > and not a routine service; otherwise you risk being snowed under with fil= e > recovery requests. Isn't that the purpose of periodic snapshots anyhow (restoring a minimal number of files)? Thanks, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 1 13:47:55 2010 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 BD7BC1065670 for ; Mon, 1 Nov 2010 13:47:55 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4E35B8FC08 for ; Mon, 1 Nov 2010 13:47:55 +0000 (UTC) Received: by eyb7 with SMTP id 7so2781312eyb.13 for ; Mon, 01 Nov 2010 06:47:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:mime-version:content-type:content-disposition:user-agent; bh=C8fDZ79MYE6gQfwhrvpVWFXg6fMBlCqacL/s3CyEhKM=; b=o6bL86QJLwpkHpk1EIynpuUTAYNdBPqYrfjus7E8N/RzjxtQ9GVSTHtvIL04PfEmS1 6bF4vIDX6Yom5U74n0iDjJslfovOTyFdlQC/oyhPY9jikcdRJp1gDo+/dXLgYTR8+ayg 72BnIeWiMIcarRhBKb2Nmbl35YhKGCO+t5O64= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent; b=H8ghWWvoWxPZbPKMMDB2Mspm+yf0NYFzmMYQZL+ULowLcIN1pm3S06wtERRA+sbHa2 SYPoSQt6kMhpmUrjMLuojhmY+sr3OR9aAIrwqFcedakyIzCqQi9TWgk4LWvLpL/wZUFf i595OfXFtHZNQhvsjzVyAgtfKmmAHhYeEhjq4= Received: by 10.213.29.145 with SMTP id q17mr13153190ebc.27.1288617607757; Mon, 01 Nov 2010 06:20:07 -0700 (PDT) Received: from localhost (lan-78-157-92-5.vln.skynet.lt [78.157.92.5]) by mx.google.com with ESMTPS id x54sm4191930eeh.17.2010.11.01.06.20.05 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 01 Nov 2010 06:20:06 -0700 (PDT) Date: Mon, 1 Nov 2010 15:20:00 +0200 From: Gleb Kurtsou To: freebsd-hackers@freebsd.org Message-ID: <20101101132000.GA4016@tops> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: ABI compatibility checker for shared libraries 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, 01 Nov 2010 13:47:55 -0000 Hi, I'd like to introduce shlib-compat -- an ABI compatibility checker for shared libraries with symbol versioning. The idea of such tool was discussed on mail lists before. shlib-compat uses debugging info (dwarf) from compiled library to compare definitions of exported symbols, i.e. no sources is necessary. Code quality is pre-alpha, loops in struct/union definitions are not handled properly, values for enums and const/volatile are ignored. Reporting is not yet implemented, it has knob to dump complete symbol definitions in json which is rather useless. It just prints if symbol definitions match. shlib-compat parses libc.so.7 on my system (amd64), but there is a lot warnings about symbols it can't find in dwarf dump (looks like these are implemented in asm). Sources contain several trivial test cases. devel/dwarfdump port is required (as well as objdump which is in base). Source code available on github: http://github.com/glk/shlib-compat Or as tarball: http://github.com/downloads/glk/shlib-compat/shlib-compat-0.1.tar.gz I don't have much free time to continue developing it right now, but feel free to add a ticket on github, submit a patch or fork it. Thanks, Gleb. From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 1 14:49:25 2010 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 AD770106564A for ; Mon, 1 Nov 2010 14:49:25 +0000 (UTC) (envelope-from buganini@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6618C8FC1A for ; Mon, 1 Nov 2010 14:49:25 +0000 (UTC) Received: by gxk9 with SMTP id 9so3477420gxk.13 for ; Mon, 01 Nov 2010 07:49:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=Kb2/Tf7taok6iztD0YMYEiPQBatLC03Jaz6Mr6hZfkw=; b=x5PDukrm/rOxj4wp7CaQnmtdUUe7GDkUjzQ+ApGeOiLjJeq66xr4dFheTwDNu/clPR BWJZIYVgYhktC+Rhg3QIkPC/SCgoZlrvT4GLGMwHMt/pN0MBVXyQEHP1SIfGA1sEaXTL I/ci9eh0jXSNicoS7zU/C/8qBcJj2jIK2y08M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=V1lkkkB9gC2OnO6hwwCwH9Oh0H04T7wygm7UAsttvuWM0Qh9Tl/MfOMyTKcCd6fbBE wwxknMg5WLDrc5wcGkvLS6yXTNt6IZnmDrBFzX7c7N2LhX86KUxnghJpGotdBGu+0gUR e1YVdhpowKsMzTr3JHfSbB28CMaTRL54nHyLE= MIME-Version: 1.0 Received: by 10.42.145.134 with SMTP id f6mr5635845icv.153.1288621179792; Mon, 01 Nov 2010 07:19:39 -0700 (PDT) Received: by 10.220.100.71 with HTTP; Mon, 1 Nov 2010 07:19:39 -0700 (PDT) In-Reply-To: References: <4ccdcdaa.XSDkZZUUYXDXpkXV%perryh@pluto.rain.com> <201010312044.o9VKiPwG049615@apollo.backplane.com> <201011010916.59108.j.mckeown@ru.ac.za> Date: Mon, 1 Nov 2010 22:19:39 +0800 Message-ID: From: Buganini To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: Re: Slow disk access while rsync - what should I tune? 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, 01 Nov 2010 14:49:25 -0000 Might gsched(8) help ? From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 1 14:12:55 2010 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 BDCCD1065693 for ; Mon, 1 Nov 2010 14:12:55 +0000 (UTC) (envelope-from Daan@vehosting.nl) Received: from VM01.VEHosting.nl (vm01.vehosting.nl [85.17.51.140]) by mx1.freebsd.org (Postfix) with ESMTP id 5C7BD8FC12 for ; Mon, 1 Nov 2010 14:12:55 +0000 (UTC) Received: from [192.168.72.11] (124-54.bbned.dsl.internl.net [92.254.54.124]) (authenticated bits=0) by VM01.VEHosting.nl (8.14.3/8.13.8) with ESMTP id oA1EBfZJ092605; Mon, 1 Nov 2010 15:11:41 +0100 (CET) (envelope-from Daan@vehosting.nl) From: Daan Vreeken Organization: http://VEHosting.nl/ To: cronfy Date: Mon, 1 Nov 2010 15:11:38 +0100 User-Agent: KMail/1.9.10 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201011011511.38244.Daan@vehosting.nl> x-ve-auth-version: mi-1.0.3 2008-05-30 - Copyright (c) 2008 - Daan Vreeken - VEHosting x-ve-auth: authenticated as 'pa4dan' on VM01.VEHosting.nl X-Mailman-Approved-At: Mon, 01 Nov 2010 15:16:05 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: Slow disk access while rsync - what should I tune? 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, 01 Nov 2010 14:12:55 -0000 Hi Cronfy, On Saturday 30 October 2010 23:48:45 cronfy wrote: > Hello. > > > Every time backup starts server slows down significantly, disk > > operations become very slow. It may take up to 10 seconds to stat() a > > file that is not in filesystem cache. At the same time, rsync on > > remote server does not affect disk load much, server works without > > slowdown. > > Thank you all for the answers. ... > Also, is it possible to limit disk operations for rm -rf somehow? The > only idea I have at the moment is to replace rm -rf with 'find | > slow_down_script | xargs rm' (or use similar patch as for rsync)... Yes there is. You could use the same 'trick' I've added to rsync and limit the amount of I/O-creating system calls an application creates. You could even create a small wrapper library that does this for a specific application, without having to recompile or change the application. You can find a working proof of concept in "slowdown.c" here : http://vehosting.nl/pub_diffs/ The library can be compiled with : gcc -Wall -fPIC -shared -o slowdown.so slowdown.c Then start the application you want to I/O-limit with something like : ( export LD_PRELOAD=slowdown.so export LD_LIBRARY_PATH=.:${LD_LIBRARY_PATH} ls -R /a/random/huge/directory/ ) (Assuming you start the application from withing the directory where "slowdown.so" resides.) This should work with rsync, ls and rm "out of the box", without changing the source of the applications. Regards, -- Daan Vreeken VEHosting http://VEHosting.nl tel: +31-(0)40-7113050 / +31-(0)6-46210825 KvK nr: 17174380 From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 1 15:20:03 2010 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 1646C1065672 for ; Mon, 1 Nov 2010 15:20:03 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id D10E78FC1F for ; Mon, 1 Nov 2010 15:20:02 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 53F6246B82; Mon, 1 Nov 2010 11:20:02 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 6B7CE8A009; Mon, 1 Nov 2010 11:20:01 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Mon, 1 Nov 2010 09:28:12 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <4CCB62D6.1050808@bluezbox.com> In-Reply-To: <4CCB62D6.1050808@bluezbox.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011010928.12562.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 01 Nov 2010 11:20:01 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Oleksandr Tymoshenko Subject: Re: [PATCH] hwpmc(4) syscall arguments fix 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, 01 Nov 2010 15:20:03 -0000 On Friday, October 29, 2010 8:12:06 pm Oleksandr Tymoshenko wrote: > I ran into problems trying to get hwpmc to work on 64-bit MIPS > system with big endian byte order. Turned out hwpmc syscall handler > is byte-order and register_t size agnostic unlike the rest of syscalls. > The best solution I have so far is a copy sys/sysproto.h approach: > http://people.freebsd.org/~gonzo/patches/hwpmc-syscall.diff > > Any other ideas how to get it fixed in more clean way? Yes, a better way would be to add pmc_syscall() to sys/kern/syscalls.master as a NOSTD system call. Then it's arguments would be included in sysproto.h directly. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 3 14:54:57 2010 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 6EEE1106566B for ; Wed, 3 Nov 2010 14:54:57 +0000 (UTC) (envelope-from squeaky1204@yahoo.com) Received: from nm14-vm0.bullet.mail.sp2.yahoo.com (nm14-vm0.bullet.mail.sp2.yahoo.com [98.139.91.246]) by mx1.freebsd.org (Postfix) with SMTP id 4DFE38FC18 for ; Wed, 3 Nov 2010 14:54:57 +0000 (UTC) Received: from [98.139.91.68] by nm14.bullet.mail.sp2.yahoo.com with NNFMP; 03 Nov 2010 14:41:38 -0000 Received: from [98.139.91.52] by tm8.bullet.mail.sp2.yahoo.com with NNFMP; 03 Nov 2010 14:41:38 -0000 Received: from [127.0.0.1] by omp1052.mail.sp2.yahoo.com with NNFMP; 03 Nov 2010 14:41:38 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 254701.92472.bm@omp1052.mail.sp2.yahoo.com Received: (qmail 32775 invoked by uid 60001); 3 Nov 2010 14:41:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1288795297; bh=x7WJQiZ8UN+jf7WBf+I82iOy4Hi5a0F5/32RrXd5FB0=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=MX7nXg7MQlygAtoH1tr8mHweMvAFZOBDHMJrOgMAO68iapVoM2BRAg5yB8ltX8zLgBEtkFhs5KpDwfQBTrtt3be92p0opIcSYNWiO8Mi+JTn6dvgYmvLB3Y2MSB9jc7Nbk1dhb41K4DpV+pA8p+IF18SCAQlfq/CFQnGsty4eVw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=0nahFrUbP0OXPy3rSGGiIFfqU6iwalt8xF4tKPdehPvFG6XVmBcyngr7nDMcepj9ml1m3A+JIrOdeyXMRriCu5nMnDHe6fU5JYoisr6UjnvzkmHxGeJgrkFdENRwjDyFSLydxdvXiBz7rDvSTg26OFCTZR9WW/Q16cCgBo8JvBQ=; Message-ID: <766664.32120.qm@web111701.mail.gq1.yahoo.com> X-YMail-OSG: N8RNNdQVM1ml7GXOPKiRkD2KhGsBpY0bBfWfYXf59PB5ilD 2yYk- Received: from [65.223.155.30] by web111701.mail.gq1.yahoo.com via HTTP; Wed, 03 Nov 2010 07:41:37 PDT X-Mailer: YahooMailRC/504.5 YahooMailWebService/0.8.107.284920 Date: Wed, 3 Nov 2010 07:41:37 -0700 (PDT) From: Bob Brower To: freebsd-hackers@freebsd.org MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 03 Nov 2010 15:20:57 +0000 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Searching for supported Hardware listing 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, 03 Nov 2010 14:54:57 -0000 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 While searching the Archives I saw a referenc= e to a txt =0Afilecontaining a listing of driver supported hardware. Is thi= s listing available =0Avia forums? =0A=0A=0A=A0=A0=A0 thnx=0A=0A=0A From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 3 16:07:51 2010 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 40855106566C for ; Wed, 3 Nov 2010 16:07:51 +0000 (UTC) (envelope-from redcrash@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id E3AD28FC0C for ; Wed, 3 Nov 2010 16:07:50 +0000 (UTC) Received: by vws12 with SMTP id 12so1119206vws.13 for ; Wed, 03 Nov 2010 09:07:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=gz4B2zvd42qXOo+Z93dOgszGMgbUXjnQOwRdUEYAhWE=; b=MYcsauEzajhFBM87yX/n0AbYMB2w6msabae6WtyPPdAIMPiu4Z87PbELOhrYAx+OmK on9IMpw6hTsToInLGqJYrmr8lddzDYKgKVNyP4RsicCAo7L+2R8RcfMtkl3yM9KBCizc QF1B3zT2FgoT/TK6RLphcYeKStrY9YI7yuZ8M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=J8leJ8yxnivvGRrjJfNZDRe7Ms4kJO1U3xFsWQVc20PkiDdJu3MNemamX9752mpCMd LfNtFTO8GOt6EqxWafYPrp91cdpLKHGRGbApFQrgTmSipxouSXeRSKrtpOgLuWpTgq3Q a0WC/GCMeNaFX1ppcvij1Pk9rATbete9B11t4= MIME-Version: 1.0 Received: by 10.42.153.4 with SMTP id k4mr1459309icw.195.1288800469447; Wed, 03 Nov 2010 09:07:49 -0700 (PDT) Received: by 10.231.38.7 with HTTP; Wed, 3 Nov 2010 09:07:49 -0700 (PDT) In-Reply-To: <766664.32120.qm@web111701.mail.gq1.yahoo.com> References: <766664.32120.qm@web111701.mail.gq1.yahoo.com> Date: Wed, 3 Nov 2010 17:07:49 +0100 Message-ID: From: Harald Servat To: Bob Brower Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: Searching for supported Hardware listing 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, 03 Nov 2010 16:07:51 -0000 You mean something like this? http://www.freebsd.org/releases/8.1R/hardware.html Regards. 2010/11/3 Bob Brower > While searching the Archives I saw a reference to a txt > filecontaining a listing of driver supported hardware. Is this listing > available > via forums? > > > thnx > > > > _______________________________________________ > 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" > -- _________________________________________________________________ Fry: You can see how I lived before I met you. Bender: You lived before you met me?! Fry: Yeah, lots of people did. Bender: Really?! From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 4 14:47:10 2010 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 A5F0F1065675 for ; Thu, 4 Nov 2010 14:47:10 +0000 (UTC) (envelope-from kraduk@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 30E078FC21 for ; Thu, 4 Nov 2010 14:47:09 +0000 (UTC) Received: by wyb34 with SMTP id 34so54938wyb.13 for ; Thu, 04 Nov 2010 07:47:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=4SkO1OMiom2t2lFDIxyUl9EJyGsyuwJaPxVWBaStl3k=; b=XZ5Oh3MFbTqxa9w79KjVrCRRTy8pZiGu+fnWOLal+Ga5KBQOkxCpvEXw7toHI6d7oQ gHysVHi+tJixtOnX87vdkIKuEuWEJZC2W2Z0/xEMT/n+8gwyIWR6lBpt7y8nPVlnFMuK dyCds2LM7km+AVO5iLTrBEzImiruX1H9aRnGk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=hlCCK20kQZwbCTJcFADXjtoheLLq5H+9KIoquM67isKHQVPpk5sfXbUE9y78uztUvf UPWE1w4ngOv0lm/VSyt1C/ukeZbeRQcGrosKvHTeD6KOcvGkGCPZaOVmEOuRjqxEQCaj mGReIFXLWZUvFx/pPCa4ghHBOyRy81bwmPRho= MIME-Version: 1.0 Received: by 10.216.5.21 with SMTP id 21mr1990658wek.20.1288880705550; Thu, 04 Nov 2010 07:25:05 -0700 (PDT) Received: by 10.216.25.85 with HTTP; Thu, 4 Nov 2010 07:25:05 -0700 (PDT) In-Reply-To: <201011011511.38244.Daan@vehosting.nl> References: <201011011511.38244.Daan@vehosting.nl> Date: Thu, 4 Nov 2010 14:25:05 +0000 Message-ID: From: krad To: Daan Vreeken X-Mailman-Approved-At: Thu, 04 Nov 2010 16:40:03 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: cronfy , freebsd-hackers@freebsd.org Subject: Re: Slow disk access while rsync - what should I tune? 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, 04 Nov 2010 14:47:10 -0000 On 1 November 2010 14:11, Daan Vreeken wrote: > Hi Cronfy, > > On Saturday 30 October 2010 23:48:45 cronfy wrote: > > Hello. > > > > > Every time backup starts server slows down significantly, disk > > > operations become very slow. It may take up to 10 seconds to stat() a > > > file that is not in filesystem cache. At the same time, rsync on > > > remote server does not affect disk load much, server works without > > > slowdown. > > > > Thank you all for the answers. > ... > > Also, is it possible to limit disk operations for rm -rf somehow? The > > only idea I have at the moment is to replace rm -rf with 'find | > > slow_down_script | xargs rm' (or use similar patch as for rsync)... > > Yes there is. You could use the same 'trick' I've added to rsync and limit > the > amount of I/O-creating system calls an application creates. > You could even create a small wrapper library that does this for a specific > application, without having to recompile or change the application. > > You can find a working proof of concept in "slowdown.c" here : > http://vehosting.nl/pub_diffs/ > > The library can be compiled with : > gcc -Wall -fPIC -shared -o slowdown.so slowdown.c > > Then start the application you want to I/O-limit with something like : > ( > export LD_PRELOAD=slowdown.so > export LD_LIBRARY_PATH=.:${LD_LIBRARY_PATH} > ls -R /a/random/huge/directory/ > ) > > (Assuming you start the application from withing the directory > where "slowdown.so" resides.) > This should work with rsync, ls and rm "out of the box", without changing > the > source of the applications. > > > Regards, > -- > Daan Vreeken > VEHosting > http://VEHosting.nl > tel: +31-(0)40-7113050 / +31-(0)6-46210825 > KvK nr: 17174380 > _______________________________________________ > 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" > Just a wild punt here, but are you using zfs on both systems? If you are look at doing incremental zfs sends as an alternative. From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 5 16:01:33 2010 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 CFAEF106566B for ; Fri, 5 Nov 2010 16:01:33 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 975C88FC13 for ; Fri, 5 Nov 2010 16:01:33 +0000 (UTC) Received: by iwn39 with SMTP id 39so2939607iwn.13 for ; Fri, 05 Nov 2010 09:01:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=jWVXAiuxP2ZiPP8zCX1Rt1Vg4MMWWKmY49j5LloYhJ8=; b=a8zNKXSFNubumRp7efjh0IPTLPayeBtqLA83h5TznOGGhKuYFNMQHPn2XepPyAsdop rMfovIzhEJu5xFhZDMjydVUfzSIkmB3aGgypY8a63OMWv8XwdzNj2dgdIMzhGyNQa9IJ OV3S3wXZ2YvGS8VmugFdXgeT0y5wtcF8TAMFs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=IZL/VoL7xd4hOoJkKmAEuUchS5TaU+0HOuVZTqJu1OXwUCTpN6aHPZcn2Ee0W+1m5M 6coj0fLNEAqTVP26/hgqKE35Ga5C2W5Ygra0rOVoiCIbgn8025Suq93/QHle0tLjgApW 9bc4xpjya8lyxX2AbK/IWX2FIWIarVKm0V4r8= MIME-Version: 1.0 Received: by 10.231.36.11 with SMTP id r11mr1801488ibd.58.1288971176652; Fri, 05 Nov 2010 08:32:56 -0700 (PDT) Sender: baptiste.daroussin@gmail.com Received: by 10.231.192.76 with HTTP; Fri, 5 Nov 2010 08:32:56 -0700 (PDT) Date: Fri, 5 Nov 2010 16:32:56 +0100 X-Google-Sender-Auth: hVIRPVwCvorTK0QBX3-WM7Y6m8A Message-ID: From: Baptiste Daroussin To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [PATCH] update to the latest libedit version and remove libreadline deps 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, 05 Nov 2010 16:01:33 -0000 Hi all, I've updated libedit to the latest version available in the netbsd cvs. UTF8 support is disabled for now has it seems to be experimental and segfault. I also patch and tested all the sources that used to be linked against libreadline so that it now uses libedit making libreadline unused (I guess, perhaps I have missed some) beware that there are collision between libreadline and libedit (/usr/include/readline/readline.h) is provided by both of them. You can find the patch against current here: http://people.freebsd.org/~bapt/update-libedit.patch regards, Bapt From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 5 19:15:03 2010 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 920B81065679 for ; Fri, 5 Nov 2010 19:15:03 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 44DB58FC14 for ; Fri, 5 Nov 2010 19:15:02 +0000 (UTC) Received: by yxl31 with SMTP id 31so2504549yxl.13 for ; Fri, 05 Nov 2010 12:15:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:mime-version:content-type:content-disposition:user-agent; bh=W/8gJP2KFebQpJ9CKkumzoMLHypuiI+6EWW8ZTm7nv0=; b=I6THbEaC9sqTA74hF3H3le72Uk7UKsOHNai1sHyy8BssjSU4P0WRdFbiQmdAU5u50J KcHBzj/fI7yL51Kxq7whtMXHy9LQNEdfWDnCHC/5y2Kf3BMZAfk6zNpjI3OYzu8BfleU 6FVmD+m0tNnSfBfq9PNF7wZlW4JKDiHI3YyWw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent; b=g1fjNJpsy2lEnvrR/uEcFOJxo5oSsAgT78CG44JLzccJyhkaVYyA3rPwNxlRNRd79Q S0Dq7oKUMIBnn928sD8U/bAyZGwFPiHX9hMnVlXq3yLcPLF4eJmcoibbSR/F6PGN5o+f +EmMtnhCVZr2UObp4NkVH3FWErDcQ2sg/BN8w= Received: by 10.100.229.16 with SMTP id b16mr63114anh.109.1288984502024; Fri, 05 Nov 2010 12:15:02 -0700 (PDT) Received: from mark-laptop-bsd.mark-home (Mail1.sandvine.com [64.7.137.162]) by mx.google.com with ESMTPS id 6sm1787700anx.32.2010.11.05.12.15.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 05 Nov 2010 12:15:01 -0700 (PDT) Date: Fri, 5 Nov 2010 15:14:43 -0400 From: Mark Johnston To: freebsd-hackers@freebsd.org Message-ID: <20101105191443.GD1437@mark-laptop-bsd.mark-home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Userland debug symbols directory 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, 05 Nov 2010 19:15:03 -0000 Hi all, I have some tentative patches which add support for creating a separate directory containing all of the userland debugging symbols. I posted about this a week or so ago: http://lists.freebsd.org/pipermail/freebsd-hackers/2010-October/033437.html Some future work will involve finding out if any changes are necessary to support Clang/LLVM, and seeing whether there's any interest in adding support to the FreeBSD installer to install the debug symbols to a user-defined directory. Note that DEBUG_FLAGS must be set somewhere when building world - adding WITH_DEBUG_SYMBOLS_DIR=yes to src.conf beforehand is sufficient, as it causes DEBUG_FLAGS+=-g to be set; building world with DEBUG_FLAGS=-g alone is also sufficient. If the binaries are built without debug symbols and one tries to use my new option, nothing happens, i.e., no new files/directories are created, unless specific programs explicitly build with -g somehow (see below). My changes are below. There's a new file (stripbin.sh) which invokes objcopy(1) and strip(1). At the moment it's in usr/src, but it should probably go elsewhere... perhaps usr/src/tools? The other changes are to bsd.prog.mk, bsd.own.mk and the src.conf man page. I've also noticed a few Makefiles that explicitly set DEBUG_FLAGS=-g or CFLAGS+=-g for some reason. They are in usr.bin/tar/ cddl/usr.bin/ctfconvert/ cddl/usr.sbin/usr.sbin/lockstat/ usr.sbin/wpa/wpa_supplicant/ usr.sbin/wpa/hostapd/ usr.sbin/bluetooth/bthidd/ I'm not sure if this is intentional. Feedback and suggestions are extremely welcome. =) Thanks, -Mark diff --git a/stripbin.sh b/stripbin.sh new file mode 100755 index 0000000..be2e9ad --- /dev/null +++ b/stripbin.sh @@ -0,0 +1,29 @@ +#!/bin/sh + +# This script is invoked by install(1) on all binaries when installing world. +# It determines whether any debug info is present in the binary; if so, it +# will extract the debug symbols to $SYMBOLS_FULLPATH, strip the binary and +# add a link to the binary which points to the file containing the debugging +# symbols. + +: ${READELFEXEC:=/usr/obj/usr/src/gnu/usr.bin/binutils/readelf/readelf} +: ${STRIPEXEC:=/usr/obj/usr/src/gnu/usr.bin/binutils/strip/strip} +: ${OBJCEXEC:=/usr/obj/usr/src/gnu/usr.bin/binutils/objcopy/objcopy} +: ${DIRNAMEEXEC:=/usr/obj/usr/src/usr.bin/dirname/dirname} + +SYMBOLS_FULLPATH="${SYMBOLS_DIR}`${DIRNAMEEXEC} ${1}`" + +case $1 in +/*INS@*) + exit 0 + ;; +esac + +# Make sure that some debug info is actually present. +[ -z `$READELFEXEC -wi $1` ] && exit 0 + +mkdir -p $SYMBOLS_FULLPATH + +$STRIPEXEC --only-keep-debug -o ${SYMBOLS_DIR}${1}.symbols $1 +$STRIPEXEC --strip-debug $1 +$OBJCEXEC --add-gnu-debuglink=${SYMBOLS_DIR}${1}.symbols $1 diff --git a/share/mk/bsd.prog.mk b/share/mk/bsd.prog.mk index 47b43ab..9809db0 100644 --- a/share/mk/bsd.prog.mk +++ b/share/mk/bsd.prog.mk @@ -29,6 +29,12 @@ CFLAGS+=${CRUNCH_CFLAGS} .if !defined(DEBUG_FLAGS) STRIP?= -s +.else + +.if defined(STRIPSCRIPT) +STRIP?= -s +INSTALL:= /usr/bin/env SYMBOLS_DIR=${SYMBOLS_DIR} STRIPBIN=${STRIPSCRIPT} ${INSTALL} +.endif .endif .if defined(NO_SHARED) && (${NO_SHARED} != "no" && ${NO_SHARED} != "NO") diff --git a/share/mk/bsd.own.mk b/share/mk/bsd.own.mk index 3aa832c..80b42ad 100644 --- a/share/mk/bsd.own.mk +++ b/share/mk/bsd.own.mk @@ -541,6 +541,12 @@ MK_${vv:H}:= ${MK_${vv:T}} .endif .endfor +.if defined(WITH_DEBUG_SYMBOLS_DIR) +DEBUG_FLAGS+= -g +STRIPSCRIPT= /usr/src/stripbin.sh +SYMBOLS_DIR?= /usr/local/lib/debug +.endif + .endif # !_WITHOUT_SRCCONF .endif # !target(____) diff --git a/share/man/man5/src.conf.5 b/share/man/man5/src.conf.5 index 4f8f9a1..d787746 100644 --- a/share/man/man5/src.conf.5 +++ b/share/man/man5/src.conf.5 @@ -283,6 +283,15 @@ Set to not build CVS. Set to not build .Xr g++ 1 and related libraries. +.It Va WITH_DEBUG_SYMBOLS_DIR +Set this to have userland debugging symbols placed in a separate directory. +By default, they will be placed in +.Pa /usr/local/lib/debug/ . +A different location can be specified by defining +.Va SYMBOLS_DIR +when running make installworld. +Define this variable before running make buildworld to ensure that +the userland binaries will be built with debug symbols in the first place. .It Va WITHOUT_DICT .\" from FreeBSD: stable/8/tools/build/options/WITHOUT_DICT 156932 2006-03-21 07:50:50Z ru Set to not build the Webster dictionary files. From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 5 20:01:09 2010 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 2E54C106567A; Fri, 5 Nov 2010 20:01:09 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) by mx1.freebsd.org (Postfix) with ESMTP id BFAAA8FC1C; Fri, 5 Nov 2010 20:01:08 +0000 (UTC) Received: from turtle.stack.nl (turtle.stack.nl [IPv6:2001:610:1108:5010::132]) by mx1.stack.nl (Postfix) with ESMTP id D0C781DD753; Fri, 5 Nov 2010 21:01:07 +0100 (CET) Received: by turtle.stack.nl (Postfix, from userid 1677) id C65FD17315; Fri, 5 Nov 2010 21:01:07 +0100 (CET) Date: Fri, 5 Nov 2010 21:01:07 +0100 From: Jilles Tjoelker To: Baptiste Daroussin Message-ID: <20101105200107.GB84851@stack.nl> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org Subject: Re: [PATCH] update to the latest libedit version and remove libreadline deps 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, 05 Nov 2010 20:01:09 -0000 On Fri, Nov 05, 2010 at 04:32:56PM +0100, Baptiste Daroussin wrote: > I've updated libedit to the latest version available in the netbsd cvs. > UTF8 support is disabled for now has it seems to be experimental and segfault. > I also patch and tested all the sources that used to be linked against > libreadline so that it now uses libedit making libreadline unused (I > guess, perhaps I have missed some) > beware that there are collision between libreadline and libedit > (/usr/include/readline/readline.h) is provided by both of them. > You can find the patch against current here: > http://people.freebsd.org/~bapt/update-libedit.patch This patch reverts various local enhancements to libedit, such as: * r212191 more expected behaviour of ed-delete-next-char * r212235 key support * r209217,r209219,r209224 completion improvements for sh(1) * built-in "\033[1~" and "\033[4~" support (not sure how useful this is) * .An macros in man pages If the csh-style history expansion gets in, a "set -o histexpand" for sh could be useful. I think this is not important enough to add all the code for, but if we have the code anyway why not allow using it. On the other hand, if we can replace it with stubs and is very simplistic, perhaps it is better to stub it out and not change sh. -- Jilles Tjoelker From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 5 20:45:23 2010 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 ED0ED106566B for ; Fri, 5 Nov 2010 20:45:23 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 761DA8FC16 for ; Fri, 5 Nov 2010 20:45:23 +0000 (UTC) Received: by eyb7 with SMTP id 7so1998709eyb.13 for ; Fri, 05 Nov 2010 13:45:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=4/IeiDXDJjJA3dj9rqbnLPKf5lqJ+2XoRDXDIwiTJis=; b=UTEJ1Mu69t3fRhHdNl8fxNQvOoAvbhN5yAsKQYaWEotUGG6j1CVXDEBltbQHB1CU1E AXpBEmo0MR6HiUM7sdHY72u2+VmW50Rrcf0BwXqipNq5uqasNmgj+BcC1L6kc6BTmM9C 2HyT2BCPHhWbgcvlLrhEWkd1SB3Eq01xTmEbE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=dlAzKz5Fi8DXbsXmErSDnFF/zFMiiJzQ7EyJAPSnKnKKgO7GgyLVup3oZMy8hljtlU yGvATeRZF22GdT6P+LVeLX5dyD7C/edtdvnUxekXrnnf1zqFSqVYMWX4nvLWAa1K8F9E KybjWuL0T/M3Z4AbZRzDVwYn//vK0ZeoHrzZc= Received: by 10.213.6.201 with SMTP id a9mr1920953eba.18.1288989922301; Fri, 05 Nov 2010 13:45:22 -0700 (PDT) Received: from localhost ([212.98.186.134]) by mx.google.com with ESMTPS id v56sm1414667eeh.14.2010.11.05.13.45.20 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 05 Nov 2010 13:45:21 -0700 (PDT) Date: Fri, 5 Nov 2010 22:45:19 +0200 From: Gleb Kurtsou To: Mark Johnston Message-ID: <20101105204519.GA2843@tops> References: <20101105191443.GD1437@mark-laptop-bsd.mark-home> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20101105191443.GD1437@mark-laptop-bsd.mark-home> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org Subject: Re: Userland debug symbols directory 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, 05 Nov 2010 20:45:24 -0000 On (05/11/2010 15:14), Mark Johnston wrote: > Hi all, > > I have some tentative patches which add support for creating a separate > directory containing all of the userland debugging symbols. > > I posted about this a week or so ago: > http://lists.freebsd.org/pipermail/freebsd-hackers/2010-October/033437.html > > Some future work will involve finding out if any changes are necessary to > support Clang/LLVM, and seeing whether there's any interest in adding > support to the FreeBSD installer to install the debug symbols to a > user-defined directory. > > Note that DEBUG_FLAGS must be set somewhere when building world - > adding WITH_DEBUG_SYMBOLS_DIR=yes to src.conf beforehand is sufficient, > as it causes DEBUG_FLAGS+=-g to be set; building world with DEBUG_FLAGS=-g > alone is also sufficient. If the binaries are built without debug symbols > and one tries to use my new option, nothing happens, i.e., no new > files/directories are created, unless specific programs explicitly > build with -g somehow (see below). Hi, I like the idea a lot, but why not to leave symbol files in /usr/obj, otherwise it creates a problem of mismatch between installed binaries and stale symbol files. Kernel case is very different, it preserves previous version during 'make installkernel' besides one would hardly need symbols for all installed binaries. It's for developers only after all. If there is a problem to be debugged one can always find binary and corresponding symbols file under /usr/obj. I find this feature to be particularly useful for shlib-compat ABI compatibility checker: http://marc.info/?l=freebsd-hackers&m=128861933016176&w=2 > My changes are below. There's a new file (stripbin.sh) which invokes > objcopy(1) and strip(1). At the moment it's in usr/src, but it should > probably go elsewhere... perhaps usr/src/tools? The other changes are to > bsd.prog.mk, bsd.own.mk and the src.conf man page. > > I've also noticed a few Makefiles that explicitly set DEBUG_FLAGS=-g > or CFLAGS+=-g for some reason. They are in > > usr.bin/tar/ > cddl/usr.bin/ctfconvert/ > cddl/usr.sbin/usr.sbin/lockstat/ > usr.sbin/wpa/wpa_supplicant/ > usr.sbin/wpa/hostapd/ > usr.sbin/bluetooth/bthidd/ > > I'm not sure if this is intentional. > > Feedback and suggestions are extremely welcome. =) > > Thanks, > -Mark > > diff --git a/stripbin.sh b/stripbin.sh > new file mode 100755 > index 0000000..be2e9ad > --- /dev/null > +++ b/stripbin.sh > @@ -0,0 +1,29 @@ > +#!/bin/sh > + > +# This script is invoked by install(1) on all binaries when installing world. > +# It determines whether any debug info is present in the binary; if so, it > +# will extract the debug symbols to $SYMBOLS_FULLPATH, strip the binary and > +# add a link to the binary which points to the file containing the debugging > +# symbols. > + > +: ${READELFEXEC:=/usr/obj/usr/src/gnu/usr.bin/binutils/readelf/readelf} > +: ${STRIPEXEC:=/usr/obj/usr/src/gnu/usr.bin/binutils/strip/strip} > +: ${OBJCEXEC:=/usr/obj/usr/src/gnu/usr.bin/binutils/objcopy/objcopy} > +: ${DIRNAMEEXEC:=/usr/obj/usr/src/usr.bin/dirname/dirname} Did it survive make universe? Looks incorrect for me. At least you should depend on binaries which are part of the build toolchain, and not hard code paths. I'd propose not to add any scripts and handle it within makefiles. > + > +SYMBOLS_FULLPATH="${SYMBOLS_DIR}`${DIRNAMEEXEC} ${1}`" > + > +case $1 in > +/*INS@*) > + exit 0 > + ;; > +esac > + > +# Make sure that some debug info is actually present. > +[ -z `$READELFEXEC -wi $1` ] && exit 0 > + > +mkdir -p $SYMBOLS_FULLPATH > + > +$STRIPEXEC --only-keep-debug -o ${SYMBOLS_DIR}${1}.symbols $1 > +$STRIPEXEC --strip-debug $1 > +$OBJCEXEC --add-gnu-debuglink=${SYMBOLS_DIR}${1}.symbols $1 > diff --git a/share/mk/bsd.prog.mk b/share/mk/bsd.prog.mk > index 47b43ab..9809db0 100644 > --- a/share/mk/bsd.prog.mk > +++ b/share/mk/bsd.prog.mk > @@ -29,6 +29,12 @@ CFLAGS+=${CRUNCH_CFLAGS} > > .if !defined(DEBUG_FLAGS) > STRIP?= -s > +.else > + > +.if defined(STRIPSCRIPT) > +STRIP?= -s > +INSTALL:= /usr/bin/env SYMBOLS_DIR=${SYMBOLS_DIR} STRIPBIN=${STRIPSCRIPT} ${INSTALL} > +.endif > .endif > > .if defined(NO_SHARED) && (${NO_SHARED} != "no" && ${NO_SHARED} != "NO") > diff --git a/share/mk/bsd.own.mk b/share/mk/bsd.own.mk > index 3aa832c..80b42ad 100644 > --- a/share/mk/bsd.own.mk > +++ b/share/mk/bsd.own.mk > @@ -541,6 +541,12 @@ MK_${vv:H}:= ${MK_${vv:T}} > .endif > .endfor > > +.if defined(WITH_DEBUG_SYMBOLS_DIR) > +DEBUG_FLAGS+= -g > +STRIPSCRIPT= /usr/src/stripbin.sh > +SYMBOLS_DIR?= /usr/local/lib/debug > +.endif > + > .endif # !_WITHOUT_SRCCONF > > .endif # !target(____) > diff --git a/share/man/man5/src.conf.5 b/share/man/man5/src.conf.5 > index 4f8f9a1..d787746 100644 > --- a/share/man/man5/src.conf.5 > +++ b/share/man/man5/src.conf.5 > @@ -283,6 +283,15 @@ Set to not build CVS. > Set to not build > .Xr g++ 1 > and related libraries. > +.It Va WITH_DEBUG_SYMBOLS_DIR > +Set this to have userland debugging symbols placed in a separate directory. > +By default, they will be placed in > +.Pa /usr/local/lib/debug/ . > +A different location can be specified by defining > +.Va SYMBOLS_DIR > +when running make installworld. > +Define this variable before running make buildworld to ensure that > +the userland binaries will be built with debug symbols in the first place. > .It Va WITHOUT_DICT > .\" from FreeBSD: stable/8/tools/build/options/WITHOUT_DICT 156932 2006-03-21 07:50:50Z ru > Set to not build the Webster dictionary files. > _______________________________________________ > 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 Fri Nov 5 21:06:00 2010 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 021D71065696 for ; Fri, 5 Nov 2010 21:06:00 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id ABC378FC22 for ; Fri, 5 Nov 2010 21:05:59 +0000 (UTC) Received: by gwj16 with SMTP id 16so2571156gwj.13 for ; Fri, 05 Nov 2010 14:05:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=S1F2/fIxkF/wBZG3/2Bh0S0HGLR+u+h3koUZ3Gk3vdE=; b=OWgq2F8A9H0ipbjSxD7JErUW2gvaKrYudHVKGFEesCxknb8/M5gJFSraLa123D86Fm i2kt8GHas9EjBBoeS+tuMdTiVt6SidAbGjk4fk6J31dIRjLyCmWK39SjxaxHGdd5EWRo joH5u8Rw/zRIzrMe6f/IiKmES3UKOm+g52rA4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=ta3lTP+8BIBf7RcY46dbc85mF9YN91BSR47raoLq6grp9OnVfsCof5LXmYtjJFTfDv T/YwSgqDxzOjCMUvHMS09mPrfzEbqgiQ1P3xYZi0w1Dw2hdXJHUHF0JwRVXm3RzYXetj PTjzaeqHpDYzr+hkfWJzlo0JO6sxFkrmqRKnI= Received: by 10.150.191.13 with SMTP id o13mr4222759ybf.235.1288991157027; Fri, 05 Nov 2010 14:05:57 -0700 (PDT) Received: from mark-laptop-bsd.mark-home (mail1.sandvine.com [64.7.137.162]) by mx.google.com with ESMTPS id q5sm2834207ybe.6.2010.11.05.14.05.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 05 Nov 2010 14:05:56 -0700 (PDT) Date: Fri, 5 Nov 2010 17:05:38 -0400 From: Mark Johnston To: Gleb Kurtsou Message-ID: <20101105210538.GE1437@mark-laptop-bsd.mark-home> References: <20101105191443.GD1437@mark-laptop-bsd.mark-home> <20101105204519.GA2843@tops> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101105204519.GA2843@tops> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hackers@freebsd.org Subject: Re: Userland debug symbols directory 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, 05 Nov 2010 21:06:00 -0000 On Fri, Nov 05, 2010 at 10:45:19PM +0200, Gleb Kurtsou wrote: > On (05/11/2010 15:14), Mark Johnston wrote: > > Hi all, > > > > I have some tentative patches which add support for creating a separate > > directory containing all of the userland debugging symbols. > > > > I posted about this a week or so ago: > > http://lists.freebsd.org/pipermail/freebsd-hackers/2010-October/033437.html > > > > Some future work will involve finding out if any changes are necessary to > > support Clang/LLVM, and seeing whether there's any interest in adding > > support to the FreeBSD installer to install the debug symbols to a > > user-defined directory. > > > > Note that DEBUG_FLAGS must be set somewhere when building world - > > adding WITH_DEBUG_SYMBOLS_DIR=yes to src.conf beforehand is sufficient, > > as it causes DEBUG_FLAGS+=-g to be set; building world with DEBUG_FLAGS=-g > > alone is also sufficient. If the binaries are built without debug symbols > > and one tries to use my new option, nothing happens, i.e., no new > > files/directories are created, unless specific programs explicitly > > build with -g somehow (see below). > Hi, > > I like the idea a lot, but why not to leave symbol files in /usr/obj, > otherwise it creates a problem of mismatch between installed binaries > and stale symbol files. Kernel case is very different, it preserves > previous version during 'make installkernel' besides one would hardly > need symbols for all installed binaries. It's for developers only after > all. If there is a problem to be debugged one can always find binary > and corresponding symbols file under /usr/obj. When the .gnu_debuglink segment is added to a binary, it doesn't contain a full path to the .symbols file - it just contains the name. It's gdb that looks for debug symbols files: http://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html In particular, gdb looks in /usr/local/lib/debug by default: mark: ~/docs$ gdb (gdb) show debug-file-directory The directory where separate debug symbols are searched for is "/usr/local/lib/debug". I have no problem using a different directory, but users would have to remember to configure it to use a different path. > > My changes are below. There's a new file (stripbin.sh) which invokes > > objcopy(1) and strip(1). At the moment it's in usr/src, but it should > > probably go elsewhere... perhaps usr/src/tools? The other changes are to > > bsd.prog.mk, bsd.own.mk and the src.conf man page. > > > > I've also noticed a few Makefiles that explicitly set DEBUG_FLAGS=-g > > or CFLAGS+=-g for some reason. They are in > > > > usr.bin/tar/ > > cddl/usr.bin/ctfconvert/ > > cddl/usr.sbin/usr.sbin/lockstat/ > > usr.sbin/wpa/wpa_supplicant/ > > usr.sbin/wpa/hostapd/ > > usr.sbin/bluetooth/bthidd/ > > > > I'm not sure if this is intentional. > > > > Feedback and suggestions are extremely welcome. =) > > > > Thanks, > > -Mark > > > > diff --git a/stripbin.sh b/stripbin.sh > > new file mode 100755 > > index 0000000..be2e9ad > > --- /dev/null > > +++ b/stripbin.sh > > @@ -0,0 +1,29 @@ > > +#!/bin/sh > > + > > +# This script is invoked by install(1) on all binaries when installing world. > > +# It determines whether any debug info is present in the binary; if so, it > > +# will extract the debug symbols to $SYMBOLS_FULLPATH, strip the binary and > > +# add a link to the binary which points to the file containing the debugging > > +# symbols. > > + > > +: ${READELFEXEC:=/usr/obj/usr/src/gnu/usr.bin/binutils/readelf/readelf} > > +: ${STRIPEXEC:=/usr/obj/usr/src/gnu/usr.bin/binutils/strip/strip} > > +: ${OBJCEXEC:=/usr/obj/usr/src/gnu/usr.bin/binutils/objcopy/objcopy} > > +: ${DIRNAMEEXEC:=/usr/obj/usr/src/usr.bin/dirname/dirname} > Did it survive make universe? Looks incorrect for me. At least you > should depend on binaries which are part of the build toolchain, and not > hard code paths. > Ah, I forgot about that target; I'll give it a try tonight. As for the hard-coded paths, that's really an artifact of what's done in the tree at my work. We do FreeBSD builds by copying over a pre-defined set of binaries and libraries to the build server, copying the sources, and building in a chroot. Hard-coding the paths just ensures that the programs are actually there. I suppose this is not necessary in general though; does it make sense to assume that the above tools will always be available in PATH? > I'd propose not to add any scripts and handle it within makefiles. That was my original goal, but it's much more difficult to accomplish. As described in the install(1) man page, install(1) invokes the value of STRIPBIN (if set) on its input if -s is passed in. AFAIK, there's no way to accomplish what I want - extract symbols, strip the binary, and add debuglink - with a single command. I tried adding some extra options to strip(1) to do it, and it turned into something of a mess - it was discussed a bit in the original thread. Thanks, -Mark From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 5 21:39:16 2010 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 296CA106564A; Fri, 5 Nov 2010 21:39:16 +0000 (UTC) (envelope-from jeremie@le-hen.org) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by mx1.freebsd.org (Postfix) with ESMTP id 1999C8FC0C; Fri, 5 Nov 2010 21:39:13 +0000 (UTC) Received: from endor.tataz.chchile.org (unknown [82.233.239.98]) by smtp5-g21.free.fr (Postfix) with ESMTP id 7339DD480A9; Fri, 5 Nov 2010 22:39:07 +0100 (CET) Received: from felucia.tataz.chchile.org (felucia.tataz.chchile.org [192.168.1.9]) by endor.tataz.chchile.org (Postfix) with ESMTP id 52EDE33CF9; Fri, 5 Nov 2010 21:39:06 +0000 (UTC) Received: by felucia.tataz.chchile.org (Postfix, from userid 1000) id 41ED3A1200; Fri, 5 Nov 2010 21:39:06 +0000 (UTC) Date: Fri, 5 Nov 2010 22:39:06 +0100 From: Jeremie Le Hen To: Kostik Belousov Message-ID: <20101105213905.GT30284@felucia.tataz.chchile.org> References: <20100803150545.GH14016@felucia.tataz.chchile.org> <20100803114651.651e0ea4@kan.dnsalias.net> <20100805191446.GJ14016@felucia.tataz.chchile.org> <20100919081406.GH6864@felucia.tataz.chchile.org> <20100919184146.GE2389@deviant.kiev.zoral.com.ua> <20100920162925.GL6864@felucia.tataz.chchile.org> <20100920192708.GK2389@deviant.kiev.zoral.com.ua> <20100927094651.GB57265@felucia.tataz.chchile.org> <20100927154457.GJ43070@deviant.kiev.zoral.com.ua> <20101005181804.GJ7536@felucia.tataz.chchile.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101005181804.GJ7536@felucia.tataz.chchile.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: kan@freebsd.org, freebsd-hackers@freebsd.org, Jeremie Le Hen Subject: Re: [PATCH] Add -lssp_nonshared to GCC's LIB_SPEC unconditionally 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, 05 Nov 2010 21:39:16 -0000 Hi Kib, On Tue, Oct 05, 2010 at 08:18:04PM +0200, Jeremie Le Hen wrote: > > On Mon, Sep 27, 2010 at 06:44:57PM +0300, Kostik Belousov wrote: > > Hardcoding /usr/lib as the path to the library in the script looks > > problematic. For the buidlworld, you are linking resulting binaries > > with the host library, instead of the buildworld-produced one. For > > lib32, it makes non-working combination of 32/64 bit. > > Sorry for the late reply, but I had to collect various evidences for my > sayings and my development machine is reaaaaaaaaaaally slow. > > In fact it seems the toolchain built for buildworld contains a ld(1) > binary which invariably bases lookups for libraries in ${WORLDTMP}, even > in case of an absolute path. I have two evidences of this: > - Putting /usr/obj/usr/src/tmp/usr/lib/libssp_nonshared.a in > /usr/obj/usr/src/tmp/usr/lib/libc.ld leads toolchain's ld(1) to use > /usr/obj/usr/src/tmp/usr/obj/usr/src/tmp/usr/lib/libssp_nonshared.a; > - I also verified this with a hand-wrought opensnoop-like DTrace script. I dare to remind you about my patch. Do you have any other concerns? Thanks. Regards, -- Jeremie Le Hen Humans are born free and equal. But some are more equal than others. Coluche From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 5 23:28:41 2010 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 35F98106564A for ; Fri, 5 Nov 2010 23:28:40 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id D499C8FC12 for ; Fri, 5 Nov 2010 23:28:39 +0000 (UTC) Received: by qwg8 with SMTP id 8so2949537qwg.13 for ; Fri, 05 Nov 2010 16:28:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type; bh=IB1eizm5hWB2Sm6J/dBpsu5sNiyGI6IuRqxV/IsQVa0=; b=OShABctybFk6eQgW1JlwQtF2gm47A/N+DcA+i6SJpur6heAl6bj/zaX3DcYhmGMDru XNxGqGw3TPsqrIyNMLi+oGYutFBV5FyDmbzAtekfVVdVS7XLDYazveexx7Ow1j0vwLiN 2VGsC9+MyfGbbopMPmzZk2Y3FKmhYEMDF7F7s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=JAILaRbqj4sO5NSOoln4w49VwPprvJ6H+g9Q6MlAwHKBs0g2+hkWFrnK5G72WdoD/k HHJIN6Bwo4xL9uPcI0krf2P0725MYCByk7TqGVa5zJlfB2Iuci3iaoPN5NSYn00+7khs B3Aq5JIcc6eEe+dM9FOmRbupv+ZYhpNaOPVy4= Received: by 10.229.213.146 with SMTP id gw18mr2458412qcb.243.1288998031140; Fri, 05 Nov 2010 16:00:31 -0700 (PDT) Received: from kan.dnsalias.net (c-24-63-226-98.hsd1.ma.comcast.net [24.63.226.98]) by mx.google.com with ESMTPS id l14sm1867151qck.29.2010.11.05.16.00.29 (version=SSLv3 cipher=RC4-MD5); Fri, 05 Nov 2010 16:00:29 -0700 (PDT) Date: Fri, 5 Nov 2010 19:00:23 -0400 From: Alexander Kabaev To: Jeremie Le Hen Message-ID: <20101105190023.29e5d39d@kan.dnsalias.net> In-Reply-To: <20101105213905.GT30284@felucia.tataz.chchile.org> References: <20100803150545.GH14016@felucia.tataz.chchile.org> <20100803114651.651e0ea4@kan.dnsalias.net> <20100805191446.GJ14016@felucia.tataz.chchile.org> <20100919081406.GH6864@felucia.tataz.chchile.org> <20100919184146.GE2389@deviant.kiev.zoral.com.ua> <20100920162925.GL6864@felucia.tataz.chchile.org> <20100920192708.GK2389@deviant.kiev.zoral.com.ua> <20100927094651.GB57265@felucia.tataz.chchile.org> <20100927154457.GJ43070@deviant.kiev.zoral.com.ua> <20101005181804.GJ7536@felucia.tataz.chchile.org> <20101105213905.GT30284@felucia.tataz.chchile.org> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/B0AAXSDb_wmecMDrS8ZGrMP"; protocol="application/pgp-signature" Cc: Kostik Belousov , kan@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: [PATCH] Add -lssp_nonshared to GCC's LIB_SPEC unconditionally 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, 05 Nov 2010 23:28:41 -0000 --Sig_/B0AAXSDb_wmecMDrS8ZGrMP Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Fri, 5 Nov 2010 22:39:06 +0100 Jeremie Le Hen wrote: > Hi Kib, >=20 > On Tue, Oct 05, 2010 at 08:18:04PM +0200, Jeremie Le Hen wrote: > >=20 > > On Mon, Sep 27, 2010 at 06:44:57PM +0300, Kostik Belousov wrote: > > > Hardcoding /usr/lib as the path to the library in the script looks > > > problematic. For the buidlworld, you are linking resulting > > > binaries with the host library, instead of the > > > buildworld-produced one. For lib32, it makes non-working > > > combination of 32/64 bit. > >=20 > > Sorry for the late reply, but I had to collect various evidences > > for my sayings and my development machine is reaaaaaaaaaaally slow. > >=20 > > In fact it seems the toolchain built for buildworld contains a ld(1) > > binary which invariably bases lookups for libraries in ${WORLDTMP}, > > even in case of an absolute path. I have two evidences of this: > > - Putting /usr/obj/usr/src/tmp/usr/lib/libssp_nonshared.a in > > /usr/obj/usr/src/tmp/usr/lib/libc.ld leads toolchain's ld(1) to > > use /usr/obj/usr/src/tmp/usr/obj/usr/src/tmp/usr/lib/libssp_nonshared.a; > > - I also verified this with a hand-wrought opensnoop-like DTrace > > script. >=20 > I dare to remind you about my patch. Do you have any other concerns? >=20 > Thanks. > Regards, > --=20 > Jeremie Le Hen >=20 > Humans are born free and equal. But some are more equal than others. > Coluche Hmm, I thought I did approve this patch already a long time agi, but since you asked: +.if defined(SHLIB_LDSCRIPT) && exists(${.CURDIR}/${SHLIB_LDSCRIPT}) this should be: +.if defined(SHLIB_LDSCRIPT) ditto for all other similar places. Otherwise I do not think we should hold the patch in queue ans should unleash it on unsuspecting public. --=20 Alexander Kabaev --Sig_/B0AAXSDb_wmecMDrS8ZGrMP Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iD8DBQFM1IyMQ6z1jMm+XZYRApYIAJ9UsbwPnV0dEub002Nk4OWVok7JQQCgvU9B L+lsEZA4M0qV4JCu5pOgqBM= =5elm -----END PGP SIGNATURE----- --Sig_/B0AAXSDb_wmecMDrS8ZGrMP-- From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 6 04:34:57 2010 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 8AD831065675 for ; Sat, 6 Nov 2010 04:34:57 +0000 (UTC) (envelope-from jpaetzel@freebsd.org) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by mx1.freebsd.org (Postfix) with ESMTP id 4F6E68FC13 for ; Sat, 6 Nov 2010 04:34:57 +0000 (UTC) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.messagingengine.com (Postfix) with ESMTP id E6B4C47A for ; Sat, 6 Nov 2010 00:16:31 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute3.internal (MEProxy); Sat, 06 Nov 2010 00:16:31 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=from:to:subject:date:mime-version:content-type:content-transfer-encoding:message-id; s=smtpout; bh=JjjADzhrl2VPq+2+CAVSxgB2Ysg=; b=OR7UUUyq6z3KHl2eoSOAWXsuVahLJ0V2wm52rGG0HpVZJJGFfYW+X715ZZZB3Xzq2WeKLi/ixa73oeSNDJfr8JmjEJsLlrt+w2VRpDg/+gO5qvZ2SepJRyeq7y7UdGm1Pd2JnkTRbJvY9yyFwjqIyBMCM91h7FZimSa3lVvOd1w= X-Sasl-enc: Qlj6kIxcp/F/5wGsXdhHbw8JfsDFd3H3UkWz8SrInfvv 1289016991 Received: from tcbug.ixsystems.com (174-145-138-211.pools.spcsdns.net [174.145.138.211]) by mail.messagingengine.com (Postfix) with ESMTPSA id 094BF400F8E for ; Sat, 6 Nov 2010 00:16:31 -0400 (EDT) From: Josh Paetzel To: freebsd-hackers@freebsd.org Date: Fri, 5 Nov 2010 23:16:20 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.1-RELEASE; KDE/4.4.5; amd64; ; ) Organization: FreeBSD MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1757189.nHTtOFvdDe"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201011052316.27839.jpaetzel@freebsd.org> Subject: txt-sysinstall scrapped 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, 06 Nov 2010 04:34:57 -0000 --nextPart1757189.nHTtOFvdDe Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It's been incredibly busy for us in iXsystems land, with a lot of irons in = the=20 fire. One of the many things we've been working on is a new installer. Several=20 months ago pc-sysinstall was imported into HEAD from the PC-BSD project. =20 pc-sysinstall is a fine tool, and very useful as the backend for doing=20 scripted installs. If you're using scripted sysinstall I recommend you che= ck=20 it out, it's a lot easier to use and configure than sysinstall, the=20 documentation is much better, and reasonable requests for functionality can= =20 and will be brought in. This is all fine and good, but without a front end to generate the config=20 files pc-sysinstall needs it's not much use to an end user for doing instal= ls. =20 We (and by we I mean the forces at iXsystems) have been working on txt- sysinstall, which is a front end for pc-sysinstall using curses and dialog = to=20 generate a pc-sysinstall config file from user input. What we've encounter= ed=20 is that doing disk configuration in dialog isn't possible, and we started d= own=20 the road of using curses....but we already have a curses and dialog based=20 installer, and wouldn't it be neat if we could use the disk configuration t= ool=20 we are writing for FreeNAS, too bad it's a web app..... But if the installer just launched a web server..... Ok, wait a minute, that couldn't work...how would you configure networking?= =20 Oh wait, that's already solved in FreeNAS, before you access the system you= =20 use a console/CLI app to configure the network. Ok, but people do installs= =20 over serial ports....oh wait, you could run lynx from the console too... We quickly realized that the objections we could come up with were easily=20 overcome, and the more we talked to people here at MeetBSD the more we=20 realized it was a viable (and good) idea. People quickly came up with=20 improvements. This gets us the best of both worlds. Want a super fancy GUI installer, ju= st=20 hit the box with firefox or whatever from a full desktop, want a text=20 interface that's simple, need low bandwidth, running over a serial port, us= e=20 the embedded lynx browser. Installing in a remote vm/cloud, just configure= =20 the ip and hit it with a browser (yes, we're dreaming up ways to do it over= =20 ssl and such) I'll do a better write-up very soon, I'm pretty tired now and have a long=20 weekend looming, but just wanted to get the word out. Just to give credit where credit is due, this all started with Warner Losh= =20 saying, "Can you listen to a crazy idea I had?" It didn't take long to=20 realize that it wasn't crazy, it was a stroke of genius. Secondary props go to Philip Paeps and Kris Moore for implementation detail= s,=20 Matt Olander for recognizing the benefits and approving the change in focus= ,=20 John Hixson for the priceless look on his face when he realized we were=20 serious about changing (He's done the bulk of the work on txt-sysinstall) t= he=20 random NetBSD user here at MeetBSD (sorry I don't know his name) who said i= t=20 was a horrible idea because it would "bloat the installer way too much" (I'= m=20 still laughing at that, he was saying something about floppies too, I guess= =20 we're locking out people using 386's or something.) and quite a few other=20 people who are too countless to mention but offered random advice or=20 encouragement. =20 =2D-=20 Thanks, Josh Paetzel =46reeBSD -- The power to serve --nextPart1757189.nHTtOFvdDe Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iQEcBAABAgAGBQJM1NabAAoJEKFq1/n1feG2h/8IAI0kw8IGHlXTfedqkykpWzhp 28RLWzjebeq72cEVGoIT4ptdBfu5GXeqgZJeCHyyskUNSeRbxQmtWdV2Ue4AITeX GiV0lS4ev3ZV3c9EvC8LYQzSnr8lkxB/Le0gJXtJRU4XYT3sAdcqsAyM3vIilYYk 1C5iIapikEjpEiFDGon8dGPaaNo0uhHWCn7/hrnoUA25KFWH7JeBTCb518TYlJ1u 1yqf/W5XroAvkoTUdOOkdsL1WlDSmun7e7IXAOk1J4dAWA+IyffK4Pzav5939ynK cDJioVCGhlKsV81JUJV7xDBqxQ7L6A+9CsPyvQyk0hWONeB63annF458YVg9RwU= =RxS+ -----END PGP SIGNATURE----- --nextPart1757189.nHTtOFvdDe-- From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 6 04:47:05 2010 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 57CA3106566B for ; Sat, 6 Nov 2010 04:47:05 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id B69ED8FC14 for ; Sat, 6 Nov 2010 04:47:04 +0000 (UTC) Received: by wwb28 with SMTP id 28so186834wwb.31 for ; Fri, 05 Nov 2010 21:47:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=1/d6kCZ9Q6TEZkPjtAbPMUOBRwtVGMRcFIKos39tn3M=; b=B8LIc40as6DCvFVI1gidmavG2CbJI9cyn6ZQKdaiK2ieqZEPlh9haKLSI3QW+/DX8k XgCE7jFiZkKsu+j2k0alstMY15GaJObEvXPsrAX6x/H01MsjBHvKX957/4zNR3d6qymq OQ4U1YKhEzRBaHg1PlB6JA2Va6/ftj3dH0fKE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=UEHMgXKpSJny5HuhWSmyi9jVNh7oEvJwlo74djnXNgPcdPO2r0K1oIrWBL5o2h1EnZ vtLkpsjEtWUL/YGfzQU2LGBw/jR39IZc9Oc1fp/dAm8FkerwJB7ApP1eWwfJiKcBMJf8 1AP9DNGbDJTluKIWZZ0W7pGYCHA8OuibcPexM= MIME-Version: 1.0 Received: by 10.216.175.18 with SMTP id y18mr2970421wel.30.1289018823699; Fri, 05 Nov 2010 21:47:03 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.216.198.27 with HTTP; Fri, 5 Nov 2010 21:47:03 -0700 (PDT) In-Reply-To: <201011052316.27839.jpaetzel@freebsd.org> References: <201011052316.27839.jpaetzel@freebsd.org> Date: Fri, 5 Nov 2010 21:47:03 -0700 X-Google-Sender-Auth: oSRfPalA5E6pG5USfur6CR57vZk Message-ID: From: Garrett Cooper To: Josh Paetzel Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: txt-sysinstall scrapped 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, 06 Nov 2010 04:47:05 -0000 On Fri, Nov 5, 2010 at 9:16 PM, Josh Paetzel wrote: > It's been incredibly busy for us in iXsystems land, with a lot of irons i= n the > fire. > > One of the many things we've been working on is a new installer. =A0Sever= al > months ago pc-sysinstall was imported into HEAD from the PC-BSD project. > > pc-sysinstall is a fine tool, and very useful as the backend for doing > scripted installs. =A0If you're using scripted sysinstall I recommend you= check > it out, it's a lot easier to use and configure than sysinstall, the > documentation is much better, and reasonable requests for functionality c= an > and will be brought in. > > This is all fine and good, but without a front end to generate the config > files pc-sysinstall needs it's not much use to an end user for doing inst= alls. > We (and by we I mean the forces at iXsystems) have been working on txt- > sysinstall, which is a front end for pc-sysinstall using curses and dialo= g to > generate a pc-sysinstall config file from user input. =A0What we've encou= ntered > is that doing disk configuration in dialog isn't possible, and we started= down > the road of using curses....but we already have a curses and dialog based > installer, and wouldn't it be neat if we could use the disk configuration= tool > we are writing for FreeNAS, too bad it's a web app..... > > But if the installer just launched a web server..... > > Ok, wait a minute, that couldn't work...how would you configure networkin= g? > Oh wait, that's already solved in FreeNAS, before you access the system y= ou > use a console/CLI app to configure the network. =A0Ok, but people do inst= alls > over serial ports....oh wait, you could run lynx from the console too... > > We quickly realized that the objections we could come up with were easily > overcome, and the more we talked to people here at MeetBSD the more we > realized it was a viable (and good) idea. =A0People quickly came up with > improvements. > > This gets us the best of both worlds. =A0Want a super fancy GUI installer= , just > hit the box with firefox or whatever from a full desktop, want a text > interface that's simple, need low bandwidth, running over a serial port, = use > the embedded lynx browser. =A0Installing in a remote vm/cloud, just confi= gure > the ip and hit it with a browser (yes, we're dreaming up ways to do it ov= er > ssl and such) > > I'll do a better write-up very soon, I'm pretty tired now and have a long > weekend looming, but just wanted to get the word out. > > Just to give credit where credit is due, this all started with Warner Los= h > saying, "Can you listen to a crazy idea I had?" =A0 It didn't take long t= o > realize that it wasn't crazy, it was a stroke of genius. > > Secondary props go to Philip Paeps and Kris Moore for implementation deta= ils, > Matt Olander for recognizing the benefits and approving the change in foc= us, > John Hixson for the priceless look on his face when he realized we were > serious about changing (He's done the bulk of the work on txt-sysinstall)= the > random NetBSD user here at MeetBSD (sorry I don't know his name) who said= it > was a horrible idea because it would "bloat the installer way too much" (= I'm > still laughing at that, he was saying something about floppies too, I gue= ss > we're locking out people using 386's or something.) and quite a few other > people who are too countless to mention but offered random advice or > encouragement. Just to add to that (because I do find it a novel idea), 1) how are you going to properly prevent man in the middle attacks (SSL, TLS, etc?), and 2) what webserver would you use? I bring up the former item because I wouldn't want my data going unencrypted across any wire, and what BSD compatible web servers did you guys have in store and who would maintain the server, and what kinds of vulnerabilities would you be introducing by adding a service which would be enabled by default at runtime? Thanks! -Garrett From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 6 04:48:29 2010 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 B13ED10656AC for ; Sat, 6 Nov 2010 04:48:29 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1D5D48FC13 for ; Sat, 6 Nov 2010 04:48:28 +0000 (UTC) Received: by wyb34 with SMTP id 34so1756650wyb.13 for ; Fri, 05 Nov 2010 21:48:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=6Eu/65+zmssLCNVyJ7swMsZzxitFakMItcYizzb3j1o=; b=uz0Qt0nGNOELAmgTv3CEdAAPrLFBfCL2qMRvkbEgcz9UWnCOieVD26NrE8sl5sw6hl w8zU5jq65OJCmi5bkL+n5sRqX4itoPnWylCJs/JJ5OG6DjsaQMFsZYK8RyS3BrQrux9Y 6st+bWNRoNBOq8lzi7J1ytMgU78LwatP2FtZU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=pMa9+MhhBtr3b2b3+sdbdWcKHgR1B+pDcEurpGnE5qrETDFiD79SB598h94pVOrWhe tGv1Yz4G5QL4GRirLXMr0ZPl0Kf8ITWP8Op3XkCL8FPSw6U/9+rfj+6PvfwiLV4VGpUy 8XFqOSI1m0FzJKZfkCKLWbZl/yx+SzovimM+M= MIME-Version: 1.0 Received: by 10.216.82.197 with SMTP id o47mr2944863wee.45.1289018907792; Fri, 05 Nov 2010 21:48:27 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.216.198.27 with HTTP; Fri, 5 Nov 2010 21:48:27 -0700 (PDT) In-Reply-To: References: <201011052316.27839.jpaetzel@freebsd.org> Date: Fri, 5 Nov 2010 21:48:27 -0700 X-Google-Sender-Auth: ULlVDJavEqMEOHkWssOVXvJFDaI Message-ID: From: Garrett Cooper To: Josh Paetzel Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: txt-sysinstall scrapped 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, 06 Nov 2010 04:48:29 -0000 On Fri, Nov 5, 2010 at 9:47 PM, Garrett Cooper wrote: > On Fri, Nov 5, 2010 at 9:16 PM, Josh Paetzel wrote= : >> It's been incredibly busy for us in iXsystems land, with a lot of irons = in the >> fire. >> >> One of the many things we've been working on is a new installer. =A0Seve= ral >> months ago pc-sysinstall was imported into HEAD from the PC-BSD project. >> >> pc-sysinstall is a fine tool, and very useful as the backend for doing >> scripted installs. =A0If you're using scripted sysinstall I recommend yo= u check >> it out, it's a lot easier to use and configure than sysinstall, the >> documentation is much better, and reasonable requests for functionality = can >> and will be brought in. >> >> This is all fine and good, but without a front end to generate the confi= g >> files pc-sysinstall needs it's not much use to an end user for doing ins= talls. >> We (and by we I mean the forces at iXsystems) have been working on txt- >> sysinstall, which is a front end for pc-sysinstall using curses and dial= og to >> generate a pc-sysinstall config file from user input. =A0What we've enco= untered >> is that doing disk configuration in dialog isn't possible, and we starte= d down >> the road of using curses....but we already have a curses and dialog base= d >> installer, and wouldn't it be neat if we could use the disk configuratio= n tool >> we are writing for FreeNAS, too bad it's a web app..... >> >> But if the installer just launched a web server..... >> >> Ok, wait a minute, that couldn't work...how would you configure networki= ng? >> Oh wait, that's already solved in FreeNAS, before you access the system = you >> use a console/CLI app to configure the network. =A0Ok, but people do ins= talls >> over serial ports....oh wait, you could run lynx from the console too... >> >> We quickly realized that the objections we could come up with were easil= y >> overcome, and the more we talked to people here at MeetBSD the more we >> realized it was a viable (and good) idea. =A0People quickly came up with >> improvements. >> >> This gets us the best of both worlds. =A0Want a super fancy GUI installe= r, just >> hit the box with firefox or whatever from a full desktop, want a text >> interface that's simple, need low bandwidth, running over a serial port,= use >> the embedded lynx browser. =A0Installing in a remote vm/cloud, just conf= igure >> the ip and hit it with a browser (yes, we're dreaming up ways to do it o= ver >> ssl and such) >> >> I'll do a better write-up very soon, I'm pretty tired now and have a lon= g >> weekend looming, but just wanted to get the word out. >> >> Just to give credit where credit is due, this all started with Warner Lo= sh >> saying, "Can you listen to a crazy idea I had?" =A0 It didn't take long = to >> realize that it wasn't crazy, it was a stroke of genius. >> >> Secondary props go to Philip Paeps and Kris Moore for implementation det= ails, >> Matt Olander for recognizing the benefits and approving the change in fo= cus, >> John Hixson for the priceless look on his face when he realized we were >> serious about changing (He's done the bulk of the work on txt-sysinstall= ) the >> random NetBSD user here at MeetBSD (sorry I don't know his name) who sai= d it >> was a horrible idea because it would "bloat the installer way too much" = (I'm >> still laughing at that, he was saying something about floppies too, I gu= ess >> we're locking out people using 386's or something.) and quite a few othe= r >> people who are too countless to mention but offered random advice or >> encouragement. > > =A0 =A0Just to add to that (because I do find it a novel idea), 1) how > are you going to properly prevent man in the middle attacks (SSL, TLS, > etc?), and 2) what webserver would you use? > =A0 =A0I bring up the former item because I wouldn't want my data going > unencrypted across any wire, and what BSD compatible web servers did > you guys have in store and who would maintain the server, and what > kinds of vulnerabilities would you be introducing by adding a service > which would be enabled by default at runtime? Sorry -- missed the SSL note. Other questions still outstanding :). Thanks! -Garrett From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 6 05:07:32 2010 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 0ADF61065673; Sat, 6 Nov 2010 05:07:32 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id C0EB58FC13; Sat, 6 Nov 2010 05:07:31 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id oA656Hoo080790; Fri, 5 Nov 2010 23:06:18 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 05 Nov 2010 23:06:17 -0600 (MDT) Message-Id: <20101105.230617.74669306.imp@bsdimp.com> To: gcooper@FreeBSD.org From: Warner Losh In-Reply-To: References: <201011052316.27839.jpaetzel@freebsd.org> 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 Cc: jpaetzel@FreeBSD.org, freebsd-hackers@FreeBSD.org Subject: Re: txt-sysinstall scrapped 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, 06 Nov 2010 05:07:32 -0000 > Just to add to that (because I do find it a novel idea), 1) how > are you going to properly prevent man in the middle attacks (SSL, TLS, > etc?), and 2) what webserver would you use? https or ssh. We're also toying with the idea of having a partition that you could 'dd' your certs and keys to (so any system can customize the image with keys to make sure you were talking to who you think you are). We'd just reserve 1MB of space on partition s3. We'd then check to see if there was a tar ball. If so, we'd extract it and do the intelligent thing with the keys we find there. > I bring up the former item because I wouldn't want my data going > unencrypted across any wire, and what BSD compatible web servers did > you guys have in store and who would maintain the server, and what > kinds of vulnerabilities would you be introducing by adding a service > which would be enabled by default at runtime? The web server would just be there at installation time. You'd run it out of the ram disk and it would evaporate when the system reboots after it being installed. Also, I'm not sure we even need to have to have a set of prompts. If we do the web page right, we likely can just go directly to lynx... Warner From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 6 05:17:13 2010 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 F3743106566B for ; Sat, 6 Nov 2010 05:17:13 +0000 (UTC) (envelope-from jpaetzel@freebsd.org) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by mx1.freebsd.org (Postfix) with ESMTP id B67F48FC12 for ; Sat, 6 Nov 2010 05:17:13 +0000 (UTC) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.messagingengine.com (Postfix) with ESMTP id 2F6A052F; Sat, 6 Nov 2010 01:17:13 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Sat, 06 Nov 2010 01:17:13 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=from:to:subject:date:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:message-id; s=smtpout; bh=WofKdE0zlNV8aKi9CmOwKWWp6q8=; b=MdR3rxx28bDsHP+8J1CRrMidzb3WlgO3W6WKOCdnRl8gTG1oOMEmPuxHTOpA0zxgXDSFQ6aSLmyoHrZLSHDS72314uRAIpPKNJkQxYAC30KnIuj2eZsi5OPBcLX8bqIxDBLWZzMz5Kz2z/8ctrfuQsmhki3WGaBgNDCdooqozaQ= X-Sasl-enc: XClK0kYGTAtYTX7sS4UvMRh9mnl2d2q5hQVjfRAt4Hc3 1289020632 Received: from tcbug.ixsystems.com (174-145-138-211.pools.spcsdns.net [174.145.138.211]) by mail.messagingengine.com (Postfix) with ESMTPSA id A431C402234; Sat, 6 Nov 2010 01:17:12 -0400 (EDT) From: Josh Paetzel Organization: FreeBSD To: freebsd-hackers@freebsd.org Date: Sat, 6 Nov 2010 00:17:02 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.1-RELEASE; KDE/4.4.5; amd64; ; ) References: <201011052316.27839.jpaetzel@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2887140.J7R9Bl7mQN"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201011060017.10067.jpaetzel@freebsd.org> Cc: Garrett Cooper Subject: Re: txt-sysinstall scrapped 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, 06 Nov 2010 05:17:14 -0000 --nextPart2887140.J7R9Bl7mQN Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Friday, November 05, 2010 11:48:27 pm Garrett Cooper wrote: =20 > > Just to add to that (because I do find it a novel idea), 1) how > > are you going to properly prevent man in the middle attacks (SSL, TLS, > > etc?), and 2) what webserver would you use? > > I bring up the former item because I wouldn't want my data going > > unencrypted across any wire, and what BSD compatible web servers did > > you guys have in store and who would maintain the server, and what > > kinds of vulnerabilities would you be introducing by adding a service > > which would be enabled by default at runtime? >=20 > Sorry -- missed the SSL note. Other questions still outstanding :). >=20 > Thanks! > -Garrett Without putting much analysis into it, we talked about using lighttpd, whic= h=20 is BSDL. As far as another service, it would be running for the install on= ly=20 which is in most circumstances something that happens locally. =2D-=20 Thanks, Josh Paetzel =46reeBSD -- The power to serve --nextPart2887140.J7R9Bl7mQN Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iQEcBAABAgAGBQJM1OTVAAoJEKFq1/n1feG2iPQH/iLfpABNKo5GlSqouksEYFY4 e6C9GnrB/s3kRkKBHsvVsEoBnHD+uOTGbaptJt79xBoGjQGWytWMW8wh8GQ2E1Y1 68WNM5DrxsWrFedfr52QqIxmENHgRDmSjqQAZjAfPXCAZlD0hYsWPTSC8BzM3GWk lQ2c4YmlhcDrKwPoy3FITcQSMQaetZWQS/N+lgIw4EJ2b9libdeduMxtc4rQzdnQ y8cu0LDbgLiEATpL/4dXIa8+sQ2r0/6hG62ErftriMn3eTeY7NFDmYGXCL7cHVTh Rx/3w/cWl0RuFhVtBu3zxWqhEEzLKyJtijZv83EqRQflPsN08ImPXwQE+ylaf3w= =2D89 -----END PGP SIGNATURE----- --nextPart2887140.J7R9Bl7mQN-- From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 6 06:00:57 2010 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 D3E411065670; Sat, 6 Nov 2010 06:00:57 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 769A48FC0C; Sat, 6 Nov 2010 06:00:57 +0000 (UTC) Received: by ywh2 with SMTP id 2so2742739ywh.13 for ; Fri, 05 Nov 2010 23:00:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=T2s2DpV9KQRuZ/bR6BC6V0zKhS7aTGeMCxZG9vk/DoM=; b=HQxPFAavry5QYyAZ59QCHnwHQxX6wZLJjsL+PllDXUC3/T5zTjRUs15rmcaHVSskss pBkzwsCTbZ6xf8RAa8Jt34QonmI+4GJpjqRxITwC2UJBnBxwRPqoMtDzJoaWTjw4xWP1 cKj+w0NTD6GKz1/74b1/NA+XaRRkrb9tV7Lwc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=vtKFTh567N4ekFSacbju59qLJZVUMOlz/NRHHAVxXeCBMHiUJ3bcpZf/OzkPcOQa0O xtb8857fg87IGzSDla0R2tSsvAqZ5CYg9tYeV2meps/g25n/aN4olb0hoVJYG5IFU1aB pbFXnG3ZPbuFpGWeNyM/k876MRy14KQXUC8js= MIME-Version: 1.0 Received: by 10.91.18.33 with SMTP id v33mr2393206agi.153.1289023256715; Fri, 05 Nov 2010 23:00:56 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.90.70.19 with HTTP; Fri, 5 Nov 2010 23:00:56 -0700 (PDT) In-Reply-To: <201011060017.10067.jpaetzel@freebsd.org> References: <201011052316.27839.jpaetzel@freebsd.org> <201011060017.10067.jpaetzel@freebsd.org> Date: Fri, 5 Nov 2010 23:00:56 -0700 X-Google-Sender-Auth: B997w5uifsLgSZ-ugxmdVnv9vrU Message-ID: From: Garrett Cooper To: Josh Paetzel Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: txt-sysinstall scrapped 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, 06 Nov 2010 06:00:57 -0000 On Fri, Nov 5, 2010 at 10:17 PM, Josh Paetzel wrote: > On Friday, November 05, 2010 11:48:27 pm Garrett Cooper wrote: > >> > =A0 =A0Just to add to that (because I do find it a novel idea), 1) how >> > are you going to properly prevent man in the middle attacks (SSL, TLS, >> > etc?), and 2) what webserver would you use? >> > =A0 =A0I bring up the former item because I wouldn't want my data goin= g >> > unencrypted across any wire, and what BSD compatible web servers did >> > you guys have in store and who would maintain the server, and what >> > kinds of vulnerabilities would you be introducing by adding a service >> > which would be enabled by default at runtime? >> >> Sorry -- missed the SSL note. Other questions still outstanding :). >> >> Thanks! >> -Garrett > > Without putting much analysis into it, we talked about using lighttpd, wh= ich > is BSDL. =A0As far as another service, it would be running for the instal= l only > which is in most circumstances something that happens locally. Right. Lighttpd was relatively light and small (but back in the day at my other job at Cisco when I was testing it I remember it ran under 10MB, and the another thing such as Lynx ran about 5MB -- this was on ppc 32 though... MIPS 64-bit was a bit more heavyweight IIRC). Is Lynx a good idea though? It is a GPL tool (and whilst I agree that we shouldn't be really investing any time in modifying the app, FreeBSD tends to shy away from GPL nowadays)... someone else suggested curl, but then you miss out on the visual representation of the installation process :(... Coming up with a short and sweet http client shouldn't be too hard, but it probably would be more error prone than investing in a preexisting client. Thanks, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 6 06:04:22 2010 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 D2AF2106566B; Sat, 6 Nov 2010 06:04:22 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7662D8FC12; Sat, 6 Nov 2010 06:04:22 +0000 (UTC) Received: by gwj16 with SMTP id 16so2703526gwj.13 for ; Fri, 05 Nov 2010 23:04:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=5sF20wumfVfi/FYWjRHTNRp/EmobUAXcaKnGX/nNZVY=; b=vCob5dyV5X3dUwAn6i2zK5zrWa7uSzgHHiweGLa5Ay+ZM/8BMKAsiVoOvTgDyOxEA3 I3EDI51CqaXAQ8YbdOsYSYb7CKGUPc0iNIXBhoQurNszrSDhe2jhQP3JCstZK5EDMTXv DAdg+hg94CBnPoL+tddOx4R7uFRJXFE6/zJmo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=STkwZvsSthj6U0HrOheVnZlPb/mrpyrjBgN0scL/qF4K8CLu95vLAYupl+dynxp7QW +m1pV5FkxVDHHaNbiabb1G4gyQnjtLyEEcBr7EOTEY+mUyCRL3tUpbn7LOBcO0jxytfV lquiN9LdH0Ivbm5ycNRuD1Im+6wgvlwdeONPg= MIME-Version: 1.0 Received: by 10.91.51.38 with SMTP id d38mr2364381agk.108.1289023459875; Fri, 05 Nov 2010 23:04:19 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.90.70.19 with HTTP; Fri, 5 Nov 2010 23:04:19 -0700 (PDT) In-Reply-To: <20101105.230617.74669306.imp@bsdimp.com> References: <201011052316.27839.jpaetzel@freebsd.org> <20101105.230617.74669306.imp@bsdimp.com> Date: Fri, 5 Nov 2010 23:04:19 -0700 X-Google-Sender-Auth: pieNafsI0RNLawFldJXUiP0bhok Message-ID: From: Garrett Cooper To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: jpaetzel@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: txt-sysinstall scrapped 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, 06 Nov 2010 06:04:22 -0000 On Fri, Nov 5, 2010 at 10:06 PM, Warner Losh wrote: >> =A0 =A0 Just to add to that (because I do find it a novel idea), 1) how >> are you going to properly prevent man in the middle attacks (SSL, TLS, >> etc?), and 2) what webserver would you use? > > https or ssh. > > We're also toying with the idea of having a partition that you could > 'dd' your certs and keys to (so any system can customize the image > with keys to make sure you were talking to who you think you are). > We'd just reserve 1MB of space on partition s3. =A0We'd then check to > see if there was a tar ball. =A0If so, we'd extract it and do the > intelligent thing with the keys we find there. Wouldn't it be better just to go with a read-write media solution (USB) like Matt Dillon was suggesting at today then? Then again, determining the root device to date is still a bit kludgy isn't it? >> =A0 =A0 I bring up the former item because I wouldn't want my data going >> unencrypted across any wire, and what BSD compatible web servers did >> you guys have in store and who would maintain the server, and what >> kinds of vulnerabilities would you be introducing by adding a service >> which would be enabled by default at runtime? > > The web server would just be there at installation time. =A0You'd run it > out of the ram disk and it would evaporate when the system reboots > after it being installed. Sure. > Also, I'm not sure we even need to have to have a set of prompts. =A0If > we do the web page right, we likely can just go directly to lynx... Well... I like the curl idea a lot more for this approach (esp because it supports more protocols than just http and ftp, whereas lynx is constrained to ftp and http for the most part), but having both solutions is more heavyweight for the task than it probably should be. Cheers, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 6 06:05:49 2010 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 0373F106564A; Sat, 6 Nov 2010 06:05:49 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 99EC78FC1C; Sat, 6 Nov 2010 06:05:48 +0000 (UTC) Received: by gya6 with SMTP id 6so2685928gya.13 for ; Fri, 05 Nov 2010 23:05:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=7O0PVSyT594563oKYEKWWdie7ZB4QmiAHB1WKWJXWXc=; b=EGdjbo7kCDMRaipQd/J66Xuoq2YMvLJJeNew3OfmRETGjwcdUBOKB9Wqljl5cezK0Y czilwxX6D87NN2ZuICCkSkxXoHwLbY1prVNymAu91Gf2AA8Y2LnU34UHMEpBBuqhXbNR RUgO37tyyyrctxQ3TvzT7HdYUBR8eWZl+FJrM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=hKQxF1UJpd1OwjDN5xkCfLAn/ck/1Na1HlprGp5y6V2WT4tsuZSS8r3VPr7e5yJ12o 14lLYu9+iab6u7WdMy7seeheVO0We9P975pkeYFIRs9P0cMAmUkShEfKnihn5giDS2cZ mFumnlk5KS2o2H8GxZ212T6SkFDA0VZLvxm7E= MIME-Version: 1.0 Received: by 10.91.16.27 with SMTP id t27mr2369418agi.126.1289023547659; Fri, 05 Nov 2010 23:05:47 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.90.70.19 with HTTP; Fri, 5 Nov 2010 23:05:47 -0700 (PDT) In-Reply-To: References: <201011052316.27839.jpaetzel@freebsd.org> <20101105.230617.74669306.imp@bsdimp.com> Date: Fri, 5 Nov 2010 23:05:47 -0700 X-Google-Sender-Auth: AEIsEpk9AieZrZX1ANipTyfqg_8 Message-ID: From: Garrett Cooper To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: jpaetzel@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: txt-sysinstall scrapped 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, 06 Nov 2010 06:05:49 -0000 On Fri, Nov 5, 2010 at 11:04 PM, Garrett Cooper wrote= : > On Fri, Nov 5, 2010 at 10:06 PM, Warner Losh wrote: >>> =A0 =A0 Just to add to that (because I do find it a novel idea), 1) how >>> are you going to properly prevent man in the middle attacks (SSL, TLS, >>> etc?), and 2) what webserver would you use? >> >> https or ssh. >> >> We're also toying with the idea of having a partition that you could >> 'dd' your certs and keys to (so any system can customize the image >> with keys to make sure you were talking to who you think you are). >> We'd just reserve 1MB of space on partition s3. =A0We'd then check to >> see if there was a tar ball. =A0If so, we'd extract it and do the >> intelligent thing with the keys we find there. > > Wouldn't it be better just to go with a read-write media solution > (USB) like Matt Dillon was suggesting at today then? Then again, > determining the root device to date is still a bit kludgy isn't it? > >>> =A0 =A0 I bring up the former item because I wouldn't want my data goin= g >>> unencrypted across any wire, and what BSD compatible web servers did >>> you guys have in store and who would maintain the server, and what >>> kinds of vulnerabilities would you be introducing by adding a service >>> which would be enabled by default at runtime? >> >> The web server would just be there at installation time. =A0You'd run it >> out of the ram disk and it would evaporate when the system reboots >> after it being installed. > > Sure. > >> Also, I'm not sure we even need to have to have a set of prompts. =A0If >> we do the web page right, we likely can just go directly to lynx... > > Well... I like the curl idea a lot more for this approach (esp because > it supports more protocols than just http and ftp, whereas lynx is > constrained to ftp and http for the most part), but having both > solutions is more heavyweight for the task than it probably should be. One other thing to add. If prompts aren't necessary, the process should be completely scripted, so I personally would probably just take the webserver, et all out of the equation. Just seems like unnecessary and problematic overhead requirements... Thanks! -Garrett From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 6 06:51:30 2010 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 7D5D01065675; Sat, 6 Nov 2010 06:51:30 +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 1D9698FC13; Sat, 6 Nov 2010 06:51:30 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id oA66pGrh081470; Sat, 6 Nov 2010 00:51:17 -0600 (MDT) (envelope-from imp@bsdimp.com) Message-ID: <4CD4FAE4.6050304@bsdimp.com> Date: Sat, 06 Nov 2010 00:51:16 -0600 From: Warner Losh User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100918 Thunderbird/3.1.4 MIME-Version: 1.0 To: Garrett Cooper References: <201011052316.27839.jpaetzel@freebsd.org> <20101105.230617.74669306.imp@bsdimp.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: jpaetzel@FreeBSD.org, freebsd-hackers@FreeBSD.org Subject: Re: txt-sysinstall scrapped 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, 06 Nov 2010 06:51:30 -0000 On 11/06/2010 00:05, Garrett Cooper wrote: > On Fri, Nov 5, 2010 at 11:04 PM, Garrett Cooper wrote: >> On Fri, Nov 5, 2010 at 10:06 PM, Warner Losh wrote: >>>> Just to add to that (because I do find it a novel idea), 1) how >>>> are you going to properly prevent man in the middle attacks (SSL, TLS, >>>> etc?), and 2) what webserver would you use? >>> https or ssh. >>> >>> We're also toying with the idea of having a partition that you could >>> 'dd' your certs and keys to (so any system can customize the image >>> with keys to make sure you were talking to who you think you are). >>> We'd just reserve 1MB of space on partition s3. We'd then check to >>> see if there was a tar ball. If so, we'd extract it and do the >>> intelligent thing with the keys we find there. >> Wouldn't it be better just to go with a read-write media solution >> (USB) like Matt Dillon was suggesting at today then? Then again, >> determining the root device to date is still a bit kludgy isn't it? >> >>>> I bring up the former item because I wouldn't want my data going >>>> unencrypted across any wire, and what BSD compatible web servers did >>>> you guys have in store and who would maintain the server, and what >>>> kinds of vulnerabilities would you be introducing by adding a service >>>> which would be enabled by default at runtime? >>> The web server would just be there at installation time. You'd run it >>> out of the ram disk and it would evaporate when the system reboots >>> after it being installed. >> Sure. >> >>> Also, I'm not sure we even need to have to have a set of prompts. If >>> we do the web page right, we likely can just go directly to lynx... >> Well... I like the curl idea a lot more for this approach (esp because >> it supports more protocols than just http and ftp, whereas lynx is >> constrained to ftp and http for the most part), but having both >> solutions is more heavyweight for the task than it probably should be. > One other thing to add. If prompts aren't necessary, the process > should be completely scripted, so I personally would probably just > take the webserver, et all out of the equation. Just seems like > unnecessary and problematic overhead requirements... Prompts are required. Of course, we could have an image that would automatically overwrite whatever disk it found when booting, but that's kinda dangerous to have be the default. We really need the web server to run the web app that is the installer front end. I don't see any way around that. Warner > Thanks! > -Garrett > > > From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 6 06:51:31 2010 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 22D1C106564A; Sat, 6 Nov 2010 06:51:31 +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 B71198FC14; Sat, 6 Nov 2010 06:51:30 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id oA66nYgY081465; Sat, 6 Nov 2010 00:49:35 -0600 (MDT) (envelope-from imp@bsdimp.com) Message-ID: <4CD4FA7E.4030602@bsdimp.com> Date: Sat, 06 Nov 2010 00:49:34 -0600 From: Warner Losh User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100918 Thunderbird/3.1.4 MIME-Version: 1.0 To: Garrett Cooper References: <201011052316.27839.jpaetzel@freebsd.org> <20101105.230617.74669306.imp@bsdimp.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: jpaetzel@FreeBSD.org, freebsd-hackers@FreeBSD.org Subject: Re: txt-sysinstall scrapped 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, 06 Nov 2010 06:51:31 -0000 On 11/06/2010 00:04, Garrett Cooper wrote: > On Fri, Nov 5, 2010 at 10:06 PM, Warner Losh wrote: >>> Just to add to that (because I do find it a novel idea), 1) how >>> are you going to properly prevent man in the middle attacks (SSL, TLS, >>> etc?), and 2) what webserver would you use? >> https or ssh. >> >> We're also toying with the idea of having a partition that you could >> 'dd' your certs and keys to (so any system can customize the image >> with keys to make sure you were talking to who you think you are). >> We'd just reserve 1MB of space on partition s3. We'd then check to >> see if there was a tar ball. If so, we'd extract it and do the >> intelligent thing with the keys we find there. > Wouldn't it be better just to go with a read-write media solution > (USB) like Matt Dillon was suggesting at today then? That's exactly what I'm doing, i think. I didn't hear matt's suggestion at all, so I have no idea what you are talking about. my idea was that you could do this with an image you'd DD to a usb stick. For the cdrom, you'd need to do more complicated things, which I hadn't though about earlier... While I thought of this for vm creation mostly, I can see cdrom booting might be desirable too... > Then again, > determining the root device to date is still a bit kludgy isn't it? > Not anymore. ufs labels and glabel make it almost bulletproof. >>> I bring up the former item because I wouldn't want my data going >>> unencrypted across any wire, and what BSD compatible web servers did >>> you guys have in store and who would maintain the server, and what >>> kinds of vulnerabilities would you be introducing by adding a service >>> which would be enabled by default at runtime? >> The web server would just be there at installation time. You'd run it >> out of the ram disk and it would evaporate when the system reboots >> after it being installed. > Sure. > >> Also, I'm not sure we even need to have to have a set of prompts. If >> we do the web page right, we likely can just go directly to lynx... > Well... I like the curl idea a lot more for this approach (esp because > it supports more protocols than just http and ftp, whereas lynx is > constrained to ftp and http for the most part), but having both > solutions is more heavyweight for the task than it probably should be. I must be explaining badly. lynx isn't for downloading anything from the web, but connecting to the web-server that's running on your box to configure the box before the install happens. You don't need https for that, and while I suppose we could offer the uber-geek ftp install via command line extensions to ftpd, I hadn't planned on that :) I have no idea what the curl idea is. Maybe you could explain to me what you are suggesting here. Warner > Cheers, > -Garrett > > > From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 6 07:28:29 2010 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 56353106566C; Sat, 6 Nov 2010 07:28:29 +0000 (UTC) (envelope-from swell.k@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id AA6B38FC0A; Sat, 6 Nov 2010 07:28:28 +0000 (UTC) Received: by yxl31 with SMTP id 31so2721864yxl.13 for ; Sat, 06 Nov 2010 00:28:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:references :date:message-id:user-agent:mime-version:content-type; bh=PBhQHHL1T+Dclbi4ncnw+4IupmKyItwT1vdRawMq3ic=; b=MEJOTRj4F+gnQ4tPYEhZZnKOCKUwwh4wJSyHeJbM3mxqoaDGo8tLdpRvr/gYmQDSkQ SbTwx4L4LXFPEM0VFl5/f3nNWv6il8SLkEkBQ94POyuk+fbJg8+4bAFTN+1+87Dr7xsa WI9zBfkC1qr1EnzqjP2NkTnCGN4vdWcVSg+og= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:date:message-id:user-agent :mime-version:content-type; b=SHB3lPz2efg8zqH3ZNAL5JN8Su/UJAWcSO6ooNFaq3Gll9enFN3yex7Mw0/EKren9v JWWiGlE7RfEcYvoW6bMfGhnHi8NQgzS/vDWXYqqixKjeHjQMzpeb+X5xpQPZNw/HA1Uy V57MLyW0q3DyOr6O/tXhUMmhShObBwDd7L6mg= Received: by 10.100.209.5 with SMTP id h5mr551232ang.39.1289028507939; Sat, 06 Nov 2010 00:28:27 -0700 (PDT) Received: from localhost (tor-proxy.31173.se [193.138.216.157]) by mx.google.com with ESMTPS id b22sm2600908anb.15.2010.11.06.00.28.25 (version=SSLv3 cipher=RC4-MD5); Sat, 06 Nov 2010 00:28:27 -0700 (PDT) From: Anonymous To: Baptiste Daroussin References: <861v6zwo9j.fsf@gmail.com> <868w17v3b6.fsf@gmail.com> Date: Sat, 06 Nov 2010 10:28:13 +0300 Message-ID: <86y696q5bm.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain Cc: freebsd-hackers@freebsd.org Subject: Re: [PATCH] update to the latest libedit version and remove libreadline deps 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, 06 Nov 2010 07:28:29 -0000 Anonymous writes: > Anonymous writes: > >> Baptiste Daroussin writes: > [...] >>> You can find the patch against current here: >>> http://people.freebsd.org/~bapt/update-libedit.patch >> >> $ make depend >> /usr/src/lib/libedit/makelist -h /usr/src/lib/libedit/vi.c > vi.h.tmp && mv vi.h.tmp vi.h >> /usr/src/lib/libedit/makelist: Permission denied >> *** Error code 126 >> >> I guess HOST_SH is defined by build.sh on NetBSD. > > libgdb doesn't build, too Aww, a few more changes were needed to make buildworld happy. %% Index: ObsoleteFiles.inc =================================================================== --- ObsoleteFiles.inc (revision 214854) +++ ObsoleteFiles.inc (working copy) @@ -14,6 +14,36 @@ # The file is partitioned: OLD_FILES first, then OLD_LIBS and OLD_DIRS last. # +# XXXXXXXX: readline removed, ports should use devel/readline ;) +OLD_FILES+=usr/include/readline/chardefs.h +OLD_FILES+=usr/include/readline/keymaps.h +OLD_FILES+=usr/include/readline/rlconf.h +OLD_FILES+=usr/include/readline/rlstdc.h +OLD_FILES+=usr/include/readline/rltypedefs.h +OLD_FILES+=usr/include/readline/tilde.h +OLD_FILES+=usr/lib/libhistory.a +OLD_FILES+=usr/lib/libhistory_p.a +OLD_FILES+=usr/lib/libreadline.a +OLD_FILES+=usr/lib/libreadline_p.a +OLD_FILES+=usr/share/info/history.info.gz +OLD_FILES+=usr/share/info/readline.info.gz +OLD_FILES+=usr/share/info/rluserman.info.gz +OLD_FILES+=usr/share/man/man3/readline.3.gz +OLD_FILES+=usr/share/man/man3/rlhistory.3.gz +OLD_LIBS+=lib/libreadline.so.8 +OLD_LIBS+=usr/lib/libhistory.so +OLD_LIBS+=usr/lib/libhistory.so.8 +OLD_LIBS+=usr/lib/libreadline.so +.if ${TARGET_ARCH} == "amd64" +OLD_FILES+=usr/lib32/libhistory.a +OLD_FILES+=usr/lib32/libhistory_p.a +OLD_FILES+=usr/lib32/libreadline.a +OLD_FILES+=usr/lib32/libreadline_p.a +OLD_LIBS+=usr/lib32/libhistory.so +OLD_LIBS+=usr/lib32/libhistory.so.8 +OLD_LIBS+=usr/lib32/libreadline.so +OLD_LIBS+=usr/lib32/libreadline.so.8 +.endif # 20101101: headers moved to machine/ to x86/ .if ${TARGET_ARCH} == "amd64" || ${TARGET_ARCH} == "i386" OLD_FILES+=usr/include/machine/apicreg.h Index: contrib/gdb/gdb/cli/cli-cmds.c =================================================================== --- contrib/gdb/gdb/cli/cli-cmds.c (revision 214854) +++ contrib/gdb/gdb/cli/cli-cmds.c (working copy) @@ -21,7 +21,6 @@ #include "defs.h" #include "readline/readline.h" -#include "readline/tilde.h" #include "completer.h" #include "target.h" /* For baud_rate, remote_debug and remote_timeout */ #include "gdb_wait.h" /* For shell escape implementation */ Index: contrib/gdb/gdb/cli/cli-setshow.c =================================================================== --- contrib/gdb/gdb/cli/cli-setshow.c (revision 214854) +++ contrib/gdb/gdb/cli/cli-setshow.c (working copy) @@ -18,7 +18,6 @@ Boston, MA 02111-1307, USA. */ #include "defs.h" -#include "readline/tilde.h" #include "value.h" #include #include "gdb_string.h" Index: contrib/gdb/gdb/event-top.c =================================================================== --- contrib/gdb/gdb/event-top.c (revision 214854) +++ contrib/gdb/gdb/event-top.c (working copy) @@ -34,7 +34,6 @@ /* readline include files */ #include "readline/readline.h" -#include "readline/history.h" /* readline defines this. */ #undef savestring Index: contrib/gdb/gdb/top.c =================================================================== --- contrib/gdb/gdb/top.c (revision 214854) +++ contrib/gdb/gdb/top.c (working copy) @@ -48,7 +48,6 @@ /* readline include files */ #include "readline/readline.h" -#include "readline/history.h" /* readline defines this. */ #undef savestring Index: contrib/gdb/gdb/tracepoint.c =================================================================== --- contrib/gdb/gdb/tracepoint.c (revision 214854) +++ contrib/gdb/gdb/tracepoint.c (working copy) @@ -45,7 +45,6 @@ /* readline include files */ #include "readline/readline.h" -#include "readline/history.h" /* readline defines this. */ #undef savestring Index: contrib/gdb/gdb/tui/tui-io.c =================================================================== --- contrib/gdb/gdb/tui/tui-io.c (revision 214854) +++ contrib/gdb/gdb/tui/tui-io.c (working copy) @@ -397,8 +397,6 @@ static void tui_rl_display_match_list (char **matches, int len, int max) { typedef int QSFUNC (const void *, const void *); - extern int _rl_qsort_string_compare (const void*, const void*); - extern int _rl_print_completions_horizontally; int count, limit, printed_len; int i, j, k, l; Index: gnu/lib/Makefile =================================================================== --- gnu/lib/Makefile (revision 214854) +++ gnu/lib/Makefile (working copy) @@ -2,7 +2,7 @@ .include -SUBDIR= csu libgcc libgcov libdialog libgomp libregex libreadline libssp +SUBDIR= csu libgcc libgcov libdialog libgomp libregex libssp # libsupc++ uses libstdc++ headers, although 'make includes' should # have taken care of that already. Index: include/Makefile =================================================================== --- include/Makefile (revision 214854) +++ include/Makefile (working copy) @@ -11,7 +11,7 @@ INCS= a.out.h ar.h assert.h bitstring.h complex.h db.h \ dirent.h dlfcn.h elf.h elf-hints.h err.h fmtmsg.h fnmatch.h fstab.h \ fts.h ftw.h getopt.h glob.h grp.h gssapi.h \ - histedit.h ieeefp.h ifaddrs.h \ + ieeefp.h ifaddrs.h \ inttypes.h iso646.h kenv.h langinfo.h libgen.h limits.h link.h \ locale.h malloc.h malloc_np.h memory.h monetary.h mpool.h mqueue.h \ ndbm.h netconfig.h \ Index: lib/libedit/Makefile =================================================================== --- lib/libedit/Makefile (revision 214856) +++ lib/libedit/Makefile (working copy) @@ -1,9 +1,8 @@ -# $NetBSD: Makefile,v 1.34 2005/05/28 12:02:53 lukem Exp $ # $NetBSD: Makefile,v 1.41 2010/02/03 15:34:43 roy Exp $ # @(#)Makefile 8.1 (Berkeley) 6/4/93 # $FreeBSD$ -WIDECHAR ?= yes +WIDECHAR ?= no WARNS?= 3 LIB= edit SHLIB_MAJOR= 7 @@ -40,6 +40,7 @@ CFLAGS+=-DWIDECHAR .endif LIBEDITDIR?=${.CURDIR} +HOST_SH?=sh INCS= histedit.h INCSDIR=/usr/include Index: lib/libedit/readline/Makefile =================================================================== --- lib/libedit/readline/Makefile (revision 0) +++ lib/libedit/readline/Makefile (revision 0) @@ -5,10 +5,8 @@ .include -.PATH: ${NETBSDSRCDIR}/lib/libedit - INCS= readline.h INCSDIR= /usr/include/readline -INCSYMLINKS= readline.h ${INCSDIR}/history.h +INCSLINKS= readline.h ${INCSDIR}/history.h .include Index: rescue/rescue/Makefile =================================================================== --- rescue/rescue/Makefile (revision 214854) +++ rescue/rescue/Makefile (working copy) @@ -143,7 +143,7 @@ CRUNCH_LIBS+= -lipx .if ${MK_ZFS} != "no" CRUNCH_LIBS+= -lzfs -lnvpair -luutil -lavl .endif -CRUNCH_LIBS+= -lgeom -lbsdxml -ljail -lkiconv -lmd -lreadline -lsbuf -lufs -lz +CRUNCH_LIBS+= -lgeom -lbsdxml -ljail -lkiconv -lmd -lsbuf -lufs -lz .if ${MACHINE_CPUARCH} == "i386" CRUNCH_PROGS_sbin+= bsdlabel sconfig fdisk Index: sbin/gvinum/Makefile =================================================================== --- sbin/gvinum/Makefile (revision 214854) +++ sbin/gvinum/Makefile (working copy) @@ -7,8 +7,8 @@ MAN= gvinum.8 WARNS?= 2 CFLAGS+= -I${.CURDIR}/../../sys -DPADD= ${LIBREADLINE} ${LIBTERMCAP} ${LIBDEVSTAT} ${LIBKVM} ${LIBGEOM} -LDADD= -lreadline -ltermcap -ldevstat -lkvm -lgeom +DPADD= ${LIBEDIT} ${LIBTERMCAP} ${LIBDEVSTAT} ${LIBKVM} ${LIBGEOM} +LDADD= -ledit -ltermcap -ldevstat -lkvm -lgeom .PATH: ${.CURDIR}/../../sys/geom/vinum Index: sbin/gvinum/gvinum.c =================================================================== --- sbin/gvinum/gvinum.c (revision 214854) +++ sbin/gvinum/gvinum.c (working copy) @@ -52,7 +52,6 @@ #include #include #include -#include #include #include "gvinum.h" %% From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 6 07:38:14 2010 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 36A12106564A; Sat, 6 Nov 2010 07:38:14 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id CC6278FC0A; Sat, 6 Nov 2010 07:38:13 +0000 (UTC) Received: by iwn39 with SMTP id 39so3757044iwn.13 for ; Sat, 06 Nov 2010 00:38:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=IqnISn3fXgj6nzAGDSUiIUzRcZYGZ0U7YJmOmIeji+U=; b=qGkiFoJRBiZlWRxgKSKNWdVMAjW2zlAWoe54yQjjrvFzWmv3AFHx67KXkVGxbscbMH s2+ChUC5UDztOt9CVutLV1nfH3eJ8Ptq7NSdFP6bidTo1k/xGaIFd9s33r0l7RhqGFHQ jwelsd/7JI1p/TK9jBvf/t7pIFfWMOdhoDWLM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=B5AmhrktWoUfDcjZja2Stw2EWPp1VHamdq8o0+/bVVHzHPi24G7g2UijGaTwVyNnZR HVfi1IVL/dbzI5E8DeEDapFLc21hAgXN5HoZca/PrZQndI8iB4LFTxecX7XxWz5T9Kzi 8AK3co7drwNbCqYUrrn74fcTozuUEgyvaVAWA= Received: by 10.231.157.9 with SMTP id z9mr2483120ibw.48.1289029093366; Sat, 06 Nov 2010 00:38:13 -0700 (PDT) Received: from littlepig.local (c-67-161-8-62.hsd1.ca.comcast.net [67.161.8.62]) by mx.google.com with ESMTPS id d21sm2480645ibg.9.2010.11.06.00.38.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 06 Nov 2010 00:38:12 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Garrett Cooper In-Reply-To: <4CD4FA7E.4030602@bsdimp.com> Date: Sat, 6 Nov 2010 00:38:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201011052316.27839.jpaetzel@freebsd.org> <20101105.230617.74669306.imp@bsdimp.com> <4CD4FA7E.4030602@bsdimp.com> To: Warner Losh X-Mailer: Apple Mail (2.1081) Cc: jpaetzel@FreeBSD.org, freebsd-hackers@FreeBSD.org, Garrett Cooper Subject: Re: txt-sysinstall scrapped 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, 06 Nov 2010 07:38:14 -0000 On Nov 5, 2010, at 11:49 PM, Warner Losh wrote: > On 11/06/2010 00:04, Garrett Cooper wrote: >> On Fri, Nov 5, 2010 at 10:06 PM, Warner Losh wrote: >>>> Just to add to that (because I do find it a novel idea), 1) how >>>> are you going to properly prevent man in the middle attacks (SSL, = TLS, >>>> etc?), and 2) what webserver would you use? >>> https or ssh. >>>=20 >>> We're also toying with the idea of having a partition that you could >>> 'dd' your certs and keys to (so any system can customize the image >>> with keys to make sure you were talking to who you think you are). >>> We'd just reserve 1MB of space on partition s3. We'd then check to >>> see if there was a tar ball. If so, we'd extract it and do the >>> intelligent thing with the keys we find there. >> Wouldn't it be better just to go with a read-write media solution >> (USB) like Matt Dillon was suggesting at today then? > That's exactly what I'm doing, i think. I didn't hear matt's = suggestion at all, so I have no idea what you are talking about. Summary: DVD load times are ridiculous; just go straight for a fat (4GB = uncompressed, 1.7GB compressed) USB image. I think it's a bit big, but = with all of the binary packages in ports, it might be around that size. > my idea was that you could do this with an image you'd DD to a usb = stick. For the cdrom, you'd need to do more complicated things, which I = hadn't though about earlier... While I thought of this for vm creation = mostly, I can see cdrom booting might be desirable too... Yeah... I boot from CD by default and so do a number of other users of = course (despite the fact that it's an archaic 1980s technology :)...). >> Then again, >> determining the root device to date is still a bit kludgy isn't it? >>=20 > Not anymore. ufs labels and glabel make it almost bulletproof. Good point -- forgot about that. Which reminds me that I need to test = some geom things related to this. >>>> I bring up the former item because I wouldn't want my data = going >>>> unencrypted across any wire, and what BSD compatible web servers = did >>>> you guys have in store and who would maintain the server, and what >>>> kinds of vulnerabilities would you be introducing by adding a = service >>>> which would be enabled by default at runtime? >>> The web server would just be there at installation time. You'd run = it >>> out of the ram disk and it would evaporate when the system reboots >>> after it being installed. >> Sure. >>=20 >>> Also, I'm not sure we even need to have to have a set of prompts. = If >>> we do the web page right, we likely can just go directly to lynx... >> Well... I like the curl idea a lot more for this approach (esp = because >> it supports more protocols than just http and ftp, whereas lynx is >> constrained to ftp and http for the most part), but having both >> solutions is more heavyweight for the task than it probably should = be. > I must be explaining badly. lynx isn't for downloading anything from = the web, but connecting to the web-server that's running on your box to = configure the box before the install happens. You don't need https for = that, and while I suppose we could offer the uber-geek ftp install via = command line extensions to ftpd, I hadn't planned on that :) Well... what do you mean by "before the install happens"? What kind of = information would one specify in that state to get the machine from an = effectively halted state to a singing and dancing I'm installing FreeBSD = state? > I have no idea what the curl idea is. Maybe you could explain to me = what you are suggesting here. Summary: push and pull data to and from the backend via curl. There = wasn't much else to it other than that... Thanks, -Garrett= From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 6 07:58:15 2010 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 C3F0A1065675; Sat, 6 Nov 2010 07:58:15 +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 71CDB8FC17; Sat, 6 Nov 2010 07:58:15 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id oA67vLoL081891; Sat, 6 Nov 2010 01:57:26 -0600 (MDT) (envelope-from imp@bsdimp.com) Message-ID: <4CD50A61.6050208@bsdimp.com> Date: Sat, 06 Nov 2010 01:57:21 -0600 From: Warner Losh User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100918 Thunderbird/3.1.4 MIME-Version: 1.0 To: Garrett Cooper References: <201011052316.27839.jpaetzel@freebsd.org> <20101105.230617.74669306.imp@bsdimp.com> <4CD4FA7E.4030602@bsdimp.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: jpaetzel@FreeBSD.org, freebsd-hackers@FreeBSD.org, Garrett Cooper Subject: Re: txt-sysinstall scrapped 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, 06 Nov 2010 07:58:15 -0000 On 11/06/2010 01:38, Garrett Cooper wrote: > On Nov 5, 2010, at 11:49 PM, Warner Losh wrote: > >> On 11/06/2010 00:04, Garrett Cooper wrote: >>> On Fri, Nov 5, 2010 at 10:06 PM, Warner Losh wrote: >>>>> Just to add to that (because I do find it a novel idea), 1) how >>>>> are you going to properly prevent man in the middle attacks (SSL, TLS, >>>>> etc?), and 2) what webserver would you use? >>>> https or ssh. >>>> >>>> We're also toying with the idea of having a partition that you could >>>> 'dd' your certs and keys to (so any system can customize the image >>>> with keys to make sure you were talking to who you think you are). >>>> We'd just reserve 1MB of space on partition s3. We'd then check to >>>> see if there was a tar ball. If so, we'd extract it and do the >>>> intelligent thing with the keys we find there. >>> Wouldn't it be better just to go with a read-write media solution >>> (USB) like Matt Dillon was suggesting at today then? >> That's exactly what I'm doing, i think. I didn't hear matt's suggestion at all, so I have no idea what you are talking about. > Summary: DVD load times are ridiculous; just go straight for a fat (4GB uncompressed, 1.7GB compressed) USB image. I think it's a bit big, but with all of the binary packages in ports, it might be around that size. ah, ok... >> my idea was that you could do this with an image you'd DD to a usb stick. For the cdrom, you'd need to do more complicated things, which I hadn't though about earlier... While I thought of this for vm creation mostly, I can see cdrom booting might be desirable too... > Yeah... I boot from CD by default and so do a number of other users of course (despite the fact that it's an archaic 1980s technology :)...). CD's are desirable, if possible, but DVDs as a last resort... >>> Then again, >>> determining the root device to date is still a bit kludgy isn't it? >>> >> Not anymore. ufs labels and glabel make it almost bulletproof. > Good point -- forgot about that. Which reminds me that I need to test some geom things related to this. > >>>>> I bring up the former item because I wouldn't want my data going >>>>> unencrypted across any wire, and what BSD compatible web servers did >>>>> you guys have in store and who would maintain the server, and what >>>>> kinds of vulnerabilities would you be introducing by adding a service >>>>> which would be enabled by default at runtime? >>>> The web server would just be there at installation time. You'd run it >>>> out of the ram disk and it would evaporate when the system reboots >>>> after it being installed. >>> Sure. >>> >>>> Also, I'm not sure we even need to have to have a set of prompts. If >>>> we do the web page right, we likely can just go directly to lynx... >>> Well... I like the curl idea a lot more for this approach (esp because >>> it supports more protocols than just http and ftp, whereas lynx is >>> constrained to ftp and http for the most part), but having both >>> solutions is more heavyweight for the task than it probably should be. >> I must be explaining badly. lynx isn't for downloading anything from the web, but connecting to the web-server that's running on your box to configure the box before the install happens. You don't need https for that, and while I suppose we could offer the uber-geek ftp install via command line extensions to ftpd, I hadn't planned on that :) > Well... what do you mean by "before the install happens"? What kind of information would one specify in that state to get the machine from an effectively halted state to a singing and dancing I'm installing FreeBSD state? Before the install happens means before the install happens... The paradigm is that you gather all the info, then write a config file, then go. 'before install happens' is before the 'go'. >> I have no idea what the curl idea is. Maybe you could explain to me what you are suggesting here. > Summary: push and pull data to and from the backend via curl. There wasn't much else to it other than that... ah, ok. so not really relevant to what we have in mind... the web app for the install runs on this box being installed... Warner > Thanks, > -Garrett > > From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 6 08:13:25 2010 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 6976C10656A5; Sat, 6 Nov 2010 08:13:25 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 7AF1A8FC18; Sat, 6 Nov 2010 08:13:24 +0000 (UTC) Received: by wwb28 with SMTP id 28so255158wwb.31 for ; Sat, 06 Nov 2010 01:13:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type; bh=jAoTMEpLDUZuS4WToi2rQNNUzpmCnhRSEKPkflmMQJ4=; b=JdiSIDEH5gfWL/XHyblOW0U1DTKY9qX2H8SFxMRMxiKof5Ug/PIRLsQ33J1zjhRgS4 YvX3qsv7cGOoagz0mJQ2P+FRf9Hqm+FMibfN2aaJ4TvAfDbD9AcZcC0kMHU/TAylfaqo IlRq1vx9cUaFgI7i+vDlMSs6dPSpppvpR7Ipk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=VLP4YIOUzbs+D1LzELIs4EBcxzoqx14Nfs1P4NunP2uGDknWtK/lU1AG0KBXpVsV8v VBO5ZxDG3ZQAwHc4A+bwWBVlPvR0oKDCgiQ38pCS6IvI67FX5RW0aKFN0yp/8fk9IefJ zQRWjbZLFTX2yCroIEynlotbzIRxaY+sDE+X8= MIME-Version: 1.0 Received: by 10.216.175.18 with SMTP id y18mr3106361wel.30.1289031203545; Sat, 06 Nov 2010 01:13:23 -0700 (PDT) Received: by 10.216.198.27 with HTTP; Sat, 6 Nov 2010 01:13:23 -0700 (PDT) Date: Sat, 6 Nov 2010 01:13:23 -0700 Message-ID: From: Garrett Cooper To: freebsd-hackers@freebsd.org Content-Type: multipart/mixed; boundary=0016e6567d28fde28604945df687 Cc: Subject: [PATCH] mptutil(8) - capture errors and percolate up to caller 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, 06 Nov 2010 08:13:25 -0000 --0016e6567d28fde28604945df687 Content-Type: text/plain; charset=ISO-8859-1 Similar to r214396, this patch deals with properly capturing error and passing it up to the caller in mptutil just in case the errno value gets stomped on by warn*(3); this patch deals with an improper use of warn(3), and also some malloc(3) errors, as well as shrink down some static buffers to fit the data being output. If someone could review and help me commit this patch it would be much appreciated; all I could do is run negative tests on my local box and minor positive tests on my vmware fusion instance because it doesn't fully emulate a fully working mpt(4) device (the vmware instance consistently crashed with a warning about the mpt controller's unimplemented features after I poked at it enough). I'll submit another patch to fix up style(9) in this app if requested. Thanks! -Garrett --0016e6567d28fde28604945df687 Content-Type: text/x-patch; charset=US-ASCII; name="mptutil-capture-errno-values.patch" Content-Disposition: attachment; filename="mptutil-capture-errno-values.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gg67siny1 SW5kZXg6IHVzci5zYmluL21wdHV0aWwvbXB0X2V2dC5jCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHVzci5zYmlu L21wdHV0aWwvbXB0X2V2dC5jCShyZXZpc2lvbiAyMTQ1NjgpCisrKyB1c3Iuc2Jpbi9tcHR1dGls L21wdF9ldnQuYwkod29ya2luZyBjb3B5KQpAQCAtOTQsMTggKzk0LDIwIEBACiB7CiAJQ09ORklH X1BBR0VfTE9HXzAgKmxvZzsKIAlNUElfTE9HXzBfRU5UUlkgKiplbnRyaWVzOwotCWludCBjaCwg ZmQsIGksIG51bV9ldmVudHMsIHZlcmJvc2U7CisJaW50IGNoLCBlcnJvciwgZmQsIGksIG51bV9l dmVudHMsIHZlcmJvc2U7CiAKIAlmZCA9IG1wdF9vcGVuKG1wdF91bml0KTsKIAlpZiAoZmQgPCAw KSB7CisJCWVycm9yID0gZXJybm87CiAJCXdhcm4oIm1wdF9vcGVuIik7Ci0JCXJldHVybiAoZXJy bm8pOworCQlyZXR1cm4gKGVycm9yKTsKIAl9CiAKIAlsb2cgPSBtcHRfZ2V0X2V2ZW50cyhmZCwg TlVMTCk7CiAJaWYgKGxvZyA9PSBOVUxMKSB7CisJCWVycm9yID0gZXJybm87CiAJCXdhcm4oIkZh aWxlZCB0byBnZXQgZXZlbnQgbG9nIGluZm8iKTsKLQkJcmV0dXJuIChlcnJubyk7CisJCXJldHVy biAoZXJyb3IpOwogCX0KIAogCS8qIERlZmF1bHQgc2V0dGluZ3MuICovCkBAIC0xMjgsNiArMTMw LDggQEAKIAogCS8qIEJ1aWxkIGEgbGlzdCBvZiB2YWxpZCBlbnRyaWVzIGFuZCBzb3J0IHRoZW0g Ynkgc2VxdWVuY2UuICovCiAJZW50cmllcyA9IG1hbGxvYyhzaXplb2YoTVBJX0xPR18wX0VOVFJZ ICopICogbG9nLT5OdW1Mb2dFbnRyaWVzKTsKKwlpZiAoZW50cmllcyA9PSBOVUxMKQorCQlyZXR1 cm4gKGVycm5vKTsKIAludW1fZXZlbnRzID0gMDsKIAlmb3IgKGkgPSAwOyBpIDwgbG9nLT5OdW1M b2dFbnRyaWVzOyBpKyspIHsKIAkJaWYgKGxvZy0+TG9nRW50cnlbaV0uTG9nRW50cnlRdWFsaWZp ZXIgPT0KSW5kZXg6IHVzci5zYmluL21wdHV0aWwvbXB0X2NhbS5jCj09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHVz ci5zYmluL21wdHV0aWwvbXB0X2NhbS5jCShyZXZpc2lvbiAyMTQ1NjgpCisrKyB1c3Iuc2Jpbi9t cHR1dGlsL21wdF9jYW0uYwkod29ya2luZyBjb3B5KQpAQCAtNjMsNiArNjMsNyBAQAogCXN0cnVj dCBidXNfbWF0Y2hfcGF0dGVybiAqYjsKIAl1bmlvbiBjY2IgY2NiOwogCXNpemVfdCBidWZzaXpl OworCWludCBlcnJvcjsKIAogCWlmICh4cHRfb3BlbigpIDwgMCkKIAkJcmV0dXJuIChFTlhJTyk7 CkBAIC05MSw5ICs5MiwxMCBAQAogCWItPmZsYWdzID0gQlVTX01BVENIX05BTUUgfCBCVVNfTUFU Q0hfVU5JVCB8IEJVU19NQVRDSF9CVVNfSUQ7CiAKIAlpZiAoaW9jdGwoeHB0ZmQsIENBTUlPQ09N TUFORCwgJmNjYikgPCAwKSB7CisJCWVycm9yID0gZXJybm87CiAJCWZyZWUoY2NiLmNkbS5tYXRj aGVzKTsKIAkJZnJlZShjY2IuY2RtLnBhdHRlcm5zKTsKLQkJcmV0dXJuIChlcnJubyk7CisJCXJl dHVybiAoZXJyb3IpOwogCX0KIAlmcmVlKGNjYi5jZG0ucGF0dGVybnMpOwogCkBAIC0xMjQsNyAr MTI2LDcgQEAKIAl1bmlvbiBjY2IgY2NiOwogCXBhdGhfaWRfdCBwYXRoX2lkOwogCXNpemVfdCBi dWZzaXplOwotCWludCBlcnJvciwgaTsKKwlpbnQgZXJyb3I7CiAKIAkvKiBtcHQoNCkgb25seSBo YW5kbGVzIGRldmljZXMgb24gYnVzIDAuICovCiAJaWYgKFZvbHVtZUJ1cyAhPSAwKQpAQCAtMTY0 LDEwICsxNjYsMTAgQEAKIAlwLT5mbGFncyA9IFBFUklQSF9NQVRDSF9QQVRIIHwgUEVSSVBIX01B VENIX05BTUUgfCBQRVJJUEhfTUFUQ0hfVEFSR0VUOwogCiAJaWYgKGlvY3RsKHhwdGZkLCBDQU1J T0NPTU1BTkQsICZjY2IpIDwgMCkgewotCQlpID0gZXJybm87CisJCWVycm9yID0gZXJybm87CiAJ CWZyZWUoY2NiLmNkbS5tYXRjaGVzKTsKIAkJZnJlZShjY2IuY2RtLnBhdHRlcm5zKTsKLQkJcmV0 dXJuIChpKTsKKwkJcmV0dXJuIChlcnJvcik7CiAJfQogCWZyZWUoY2NiLmNkbS5wYXR0ZXJucyk7 CiAKQEAgLTIzNiw3ICsyMzgsNyBAQAogCiAJY2NiID0gY2FtX2dldGNjYihkZXYpOwogCWlmIChj Y2IgPT0gTlVMTCkKLQkJcmV0dXJuIChFTk9NRU0pOworCQlyZXR1cm4gKGVycm5vKTsKIAogCS8q IFplcm8gdGhlIHJlc3Qgb2YgdGhlIGNjYi4gKi8KIAliemVybygmKCZjY2ItPmNjYl9oKVsxXSwg c2l6ZW9mKHN0cnVjdCBjY2Jfc2NzaWlvKSAtCkBAIC0zNTAsNyArMzUyLDcgQEAKIAogCWNjYiA9 IGNhbV9nZXRjY2IoZGV2KTsKIAlpZiAoY2NiID09IE5VTEwpCi0JCXJldHVybiAoRU5PTUVNKTsK KwkJcmV0dXJuIChlcnJubyk7CiAKIAkvKiBaZXJvIHRoZSByZXN0IG9mIHRoZSBjY2IuICovCiAJ Ynplcm8oJigmY2NiLT5jY2JfaClbMV0sIHNpemVvZihzdHJ1Y3QgY2NiX3Njc2lpbykgLQpAQCAt MzU4LDggKzM2MCw5IEBACiAKIAlpbnFfYnVmID0gY2FsbG9jKDEsIHNpemVvZigqaW5xX2J1Zikp OwogCWlmIChpbnFfYnVmID09IE5VTEwpIHsKKwkJZXJyb3IgPSBlcnJubzsKIAkJY2FtX2ZyZWVj Y2IoY2NiKTsKLQkJcmV0dXJuIChFTk9NRU0pOworCQlyZXR1cm4gKGVycm5vKTsKIAl9CiAJc2Nz aV9pbnF1aXJ5KCZjY2ItPmNzaW8sIDEsIE5VTEwsIE1TR19TSU1QTEVfUV9UQUcsICh2b2lkICop aW5xX2J1ZiwKIAkgICAgU0hPUlRfSU5RVUlSWV9MRU5HVEgsIDAsIDAsIFNTRF9GVUxMX1NJWkUs IDUwMDApOwpAQCAtMzk3LDggKzQwMCw4IEBACiAJdW5pb24gY2NiIGNjYjsKIAlwYXRoX2lkX3Qg cGF0aF9pZDsKIAlzaXplX3QgYnVmc2l6ZTsKLQl1X2ludCBpOwogCWludCBjb3VudCwgZXJyb3I7 CisJdWludDMyX3QgaTsKIAogCWlmICh4cHRfb3BlbigpIDwgMCkKIAkJcmV0dXJuIChFTlhJTyk7 CkBAIC00MzEsMTAgKzQzNCwxMCBAQAogCQlwLT5mbGFncyA9IFBFUklQSF9NQVRDSF9QQVRIIHwg UEVSSVBIX01BVENIX05BTUU7CiAKIAkJaWYgKGlvY3RsKHhwdGZkLCBDQU1JT0NPTU1BTkQsICZj Y2IpIDwgMCkgewotCQkJaSA9IGVycm5vOworCQkJZXJyb3IgPSBlcnJubzsKIAkJCWZyZWUoY2Ni LmNkbS5tYXRjaGVzKTsKIAkJCWZyZWUoY2NiLmNkbS5wYXR0ZXJucyk7Ci0JCQlyZXR1cm4gKGkp OworCQkJcmV0dXJuIChlcnJvcik7CiAJCX0KIAkJZnJlZShjY2IuY2RtLnBhdHRlcm5zKTsKIApA QCAtNDgxLDYgKzQ4NCw4IEBACiAJICogZXhjbHVkZSB0aGVtIGZyb20gdGhlIGxpc3QuCiAJICov CiAJaW9jMiA9IG1wdF9yZWFkX2lvY19wYWdlKGZkLCAyLCBOVUxMKTsKKwlpZiAoaW9jMiA9PSBO VUxMKQorCQlyZXR1cm4gKGVycm5vKTsKIAlkaXNrcyA9IGNhbGxvYyhjY2IuY2RtLm51bV9tYXRj aGVzLCBzaXplb2YoKmRpc2tzKSk7CiAJY291bnQgPSAwOwogCWZvciAoaSA9IDA7IGkgPCBjY2Iu Y2RtLm51bV9tYXRjaGVzOyBpKyspIHsKSW5kZXg6IHVzci5zYmluL21wdHV0aWwvbXB0X3Nob3cu Ywo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09Ci0tLSB1c3Iuc2Jpbi9tcHR1dGlsL21wdF9zaG93LmMJKHJldmlzaW9uIDIx NDU2OCkKKysrIHVzci5zYmluL21wdHV0aWwvbXB0X3Nob3cuYwkod29ya2luZyBjb3B5KQpAQCAt NzksNyArNzksNyBAQAogCUNPTkZJR19QQUdFX0lPQ18yICppb2MyOwogCUNPTkZJR19QQUdFX0lP Q182ICppb2M2OwogCVUxNiBJT0NTdGF0dXM7Ci0JaW50IGZkLCBjb21tYTsKKwlpbnQgY29tbWEs IGVycm9yLCBmZDsKIAogCWlmIChhYyAhPSAxKSB7CiAJCXdhcm54KCJzaG93IGFkYXB0ZXI6IGV4 dHJhIGFyZ3VtZW50cyIpOwpAQCAtODgsMTcgKzg4LDE5IEBACiAKIAlmZCA9IG1wdF9vcGVuKG1w dF91bml0KTsKIAlpZiAoZmQgPCAwKSB7CisJCWVycm9yID0gZXJybm87CiAJCXdhcm4oIm1wdF9v cGVuIik7Ci0JCXJldHVybiAoZXJybm8pOworCQlyZXR1cm4gKGVycm9yKTsKIAl9CiAKIAltYW4w ID0gbXB0X3JlYWRfbWFuX3BhZ2UoZmQsIDAsIE5VTEwpOwogCWlmIChtYW4wID09IE5VTEwpIHsK KwkJZXJyb3IgPSBlcnJubzsKIAkJd2FybigiRmFpbGVkIHRvIGdldCBjb250cm9sbGVyIGluZm8i KTsKLQkJcmV0dXJuIChlcnJubyk7CisJCXJldHVybiAoZXJyb3IpOwogCX0KIAlpZiAobWFuMC0+ SGVhZGVyLlBhZ2VMZW5ndGggPCBzaXplb2YoKm1hbjApIC8gNCkgewotCQl3YXJuKCJJbnZhbGlk IGNvbnRyb2xsZXIgaW5mbyIpOworCQl3YXJueCgiSW52YWxpZCBjb250cm9sbGVyIGluZm8iKTsK IAkJcmV0dXJuIChFSU5WQUwpOwogCX0KIAlwcmludGYoIm1wdCVkIEFkYXB0ZXI6XG4iLCBtcHRf dW5pdCk7CkBAIC0yODMsNyArMjg1LDcgQEAKIAlDT05GSUdfUEFHRV9SQUlEX1ZPTF8xICp2bmFt ZXM7CiAJQ09ORklHX1BBR0VfUkFJRF9QSFlTX0RJU0tfMCAqcGluZm87CiAJc3RydWN0IG1wdF9z dGFuZGFsb25lX2Rpc2sgKnNkaXNrczsKLQlpbnQgZmQsIGksIGosIG5zZGlza3M7CisJaW50IGVy cm9yLCBmZCwgaSwgaiwgbnNkaXNrczsKIAogCWlmIChhYyAhPSAxKSB7CiAJCXdhcm54KCJzaG93 IGNvbmZpZzogZXh0cmEgYXJndW1lbnRzIik7CkBAIC0yOTIsMjAgKzI5NCwyMyBAQAogCiAJZmQg PSBtcHRfb3BlbihtcHRfdW5pdCk7CiAJaWYgKGZkIDwgMCkgeworCQllcnJvciA9IGVycm5vOwog CQl3YXJuKCJtcHRfb3BlbiIpOwotCQlyZXR1cm4gKGVycm5vKTsKKwkJcmV0dXJuIChlcnJvcik7 CiAJfQogCiAJLyogR2V0IHRoZSBjb25maWcgZnJvbSB0aGUgY29udHJvbGxlci4gKi8KIAlpb2My ID0gbXB0X3JlYWRfaW9jX3BhZ2UoZmQsIDIsIE5VTEwpOwogCWlvYzUgPSBtcHRfcmVhZF9pb2Nf cGFnZShmZCwgNSwgTlVMTCk7CiAJaWYgKGlvYzIgPT0gTlVMTCB8fCBpb2M1ID09IE5VTEwpIHsK KwkJZXJyb3IgPSBlcnJubzsKIAkJd2FybigiRmFpbGVkIHRvIGdldCBjb25maWciKTsKLQkJcmV0 dXJuIChlcnJubyk7CisJCXJldHVybiAoZXJyb3IpOwogCX0KIAlpZiAobXB0X2ZldGNoX2Rpc2tz KGZkLCAmbnNkaXNrcywgJnNkaXNrcykgPCAwKSB7CisJCWVycm9yID0gZXJybm87CiAJCXdhcm4o IkZhaWxlZCB0byBnZXQgc3RhbmRhbG9uZSBkcml2ZSBsaXN0Iik7Ci0JCXJldHVybiAoZXJybm8p OworCQlyZXR1cm4gKGVycm9yKTsKIAl9CiAKIAkvKiBEdW1wIG91dCB0aGUgY29uZmlndXJhdGlv bi4gKi8KQEAgLTM4MSw3ICszODYsNyBAQAogCUNPTkZJR19QQUdFX0lPQ18yX1JBSURfVk9MICp2 b2w7CiAJQ09ORklHX1BBR0VfUkFJRF9WT0xfMCAqKnZvbHVtZXM7CiAJQ09ORklHX1BBR0VfUkFJ RF9WT0xfMSAqdm5hbWVzOwotCWludCBmZCwgaSwgbGVuLCBzdGF0ZV9sZW47CisJaW50IGVycm9y LCBmZCwgaSwgbGVuLCBzdGF0ZV9sZW47CiAKIAlpZiAoYWMgIT0gMSkgewogCQl3YXJueCgic2hv dyB2b2x1bWVzOiBleHRyYSBhcmd1bWVudHMiKTsKQEAgLTM5MCwxNSArMzk1LDE3IEBACiAKIAlm ZCA9IG1wdF9vcGVuKG1wdF91bml0KTsKIAlpZiAoZmQgPCAwKSB7CisJCWVycm9yID0gZXJybm87 CiAJCXdhcm4oIm1wdF9vcGVuIik7Ci0JCXJldHVybiAoZXJybm8pOworCQlyZXR1cm4gKGVycm9y KTsKIAl9CiAKIAkvKiBHZXQgdGhlIHZvbHVtZSBsaXN0IGZyb20gdGhlIGNvbnRyb2xsZXIuICov CiAJaW9jMiA9IG1wdF9yZWFkX2lvY19wYWdlKGZkLCAyLCBOVUxMKTsKIAlpZiAoaW9jMiA9PSBO VUxMKSB7CisJCWVycm9yID0gZXJybm87CiAJCXdhcm4oIkZhaWxlZCB0byBnZXQgdm9sdW1lIGxp c3QiKTsKLQkJcmV0dXJuIChlcnJubyk7CisJCXJldHVybiAoZXJyb3IpOwogCX0KIAogCS8qCkBA IC00NjYsNyArNDczLDcgQEAKIHsKIAlzdHJ1Y3QgbXB0X2RyaXZlX2xpc3QgKmxpc3Q7CiAJc3Ry dWN0IG1wdF9zdGFuZGFsb25lX2Rpc2sgKnNkaXNrczsKLQlpbnQgZmQsIGksIGxlbiwgbnNkaXNr cywgc3RhdGVfbGVuOworCWludCBlcnJvciwgZmQsIGksIGxlbiwgbnNkaXNrcywgc3RhdGVfbGVu OwogCiAJaWYgKGFjICE9IDEpIHsKIAkJd2FybngoInNob3cgZHJpdmVzOiBleHRyYSBhcmd1bWVu dHMiKTsKQEAgLTQ3NSwxNSArNDgyLDE3IEBACiAKIAlmZCA9IG1wdF9vcGVuKG1wdF91bml0KTsK IAlpZiAoZmQgPCAwKSB7CisJCWVycm9yID0gZXJybm87CiAJCXdhcm4oIm1wdF9vcGVuIik7Ci0J CXJldHVybiAoZXJybm8pOworCQlyZXR1cm4gKGVycm9yKTsKIAl9CiAKIAkvKiBHZXQgdGhlIGRy aXZlIGxpc3QuICovCiAJbGlzdCA9IG1wdF9wZF9saXN0KGZkKTsKIAlpZiAobGlzdCA9PSBOVUxM KSB7CisJCWVycm9yID0gZXJybm87CiAJCXdhcm4oIkZhaWxlZCB0byBnZXQgZHJpdmUgbGlzdCIp OwotCQlyZXR1cm4gKGVycm5vKTsKKwkJcmV0dXJuIChlcnJvcik7CiAJfQogCiAJLyogRmV0Y2gg dGhlIGxpc3Qgb2Ygc3RhbmRhbG9uZSBkaXNrcyBmb3IgdGhpcyBjb250cm9sbGVyLiAqLwpAQCAt NTM4LDggKzU0Nyw5IEBACiAKIAlmZCA9IG1wdF9vcGVuKG1wdF91bml0KTsKIAlpZiAoZmQgPCAw KSB7CisJCWVycm9yID0gZXJybm87CiAJCXdhcm4oIm1wdF9vcGVuIik7Ci0JCXJldHVybiAoZXJy bm8pOworCQlyZXR1cm4gKGVycm9yKTsKIAl9CiAKIAkvKiBUcnkgdG8gZmluZCBlYWNoIHBvc3Np YmxlIHBoeXMgZGlzayBwYWdlLiAqLwpJbmRleDogdXNyLnNiaW4vbXB0dXRpbC9tcHRfY21kLmMK PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PQotLS0gdXNyLnNiaW4vbXB0dXRpbC9tcHRfY21kLmMJKHJldmlzaW9uIDIxNDU2 OCkKKysrIHVzci5zYmluL21wdHV0aWwvbXB0X2NtZC5jCSh3b3JraW5nIGNvcHkpCkBAIC0yMjEs NyArMjIxLDcgQEAKIGNvbnN0IGNoYXIgKgogbXB0X2lvY19zdGF0dXMoVTE2IElPQ1N0YXR1cykK IHsKLQlzdGF0aWMgY2hhciBidWZmZXJbMTZdOworCXN0YXRpYyBjaGFyIGJ1ZmZlclsxNV07CiAK IAlJT0NTdGF0dXMgJj0gTVBJX0lPQ1NUQVRVU19NQVNLOwogCWlmIChJT0NTdGF0dXMgPCBzaXpl b2YobXB0X2lvY19zdGF0dXNfY29kZXMpIC8gc2l6ZW9mKGNoYXIgKikgJiYKQEAgLTIzNCw3ICsy MzQsNyBAQAogY29uc3QgY2hhciAqCiBtcHRfcmFpZF9zdGF0dXMoVTE2IEFjdGlvblN0YXR1cykK IHsKLQlzdGF0aWMgY2hhciBidWZmZXJbMTZdOworCXN0YXRpYyBjaGFyIGJ1ZmZlclsxNV07CiAK IAlpZiAoQWN0aW9uU3RhdHVzIDwgc2l6ZW9mKG1wdF9yYWlkX2FjdGlvbl9zdGF0dXNfY29kZXMp IC8KIAkgICAgc2l6ZW9mKGNoYXIgKikpCkBAIC0yNDYsNyArMjQ2LDYgQEAKIGNvbnN0IGNoYXIg KgogbXB0X3JhaWRfbGV2ZWwoVTggVm9sdW1lVHlwZSkKIHsKLQlzdGF0aWMgY2hhciBidWZbMTZd OwogCiAJc3dpdGNoIChWb2x1bWVUeXBlKSB7CiAJY2FzZSBNUElfUkFJRF9WT0xfVFlQRV9JUzoK QEAgLTI2MywxMCArMjYyLDEyIEBACiAJCXJldHVybiAoIlJBSUQtMTAiKTsKIAljYXNlIE1QSV9S QUlEX1ZPTF9UWVBFX1JBSURfNTA6CiAJCXJldHVybiAoIlJBSUQtNTAiKTsKLQlkZWZhdWx0Ogor CWRlZmF1bHQ6IHsKKwkJc3RhdGljIGNoYXIgYnVmWzldOwogCQlzcHJpbnRmKGJ1ZiwgIkxWTCAw eCUwMngiLCBWb2x1bWVUeXBlKTsKIAkJcmV0dXJuIChidWYpOwogCX0KKwl9CiB9CiAKIGNvbnN0 IGNoYXIgKgpAQCAtMzEwLDE4ICszMTEsMTUgQEAKIAkJaWQgPSBzdHJ0b2woY3AgKyAxLCAmY3As IDApOwogCQlpZiAoKmNwID09ICdcMCcpIHsKIAkJCWlmIChidXMgPCAwIHx8IGJ1cyA+IDB4ZmYg fHwgaWQgPCAwIHx8IGlkID4gMHhmZikgewotCQkJCWVycm5vID0gRUlOVkFMOwotCQkJCXJldHVy biAoLTEpOworCQkJCXJldHVybiAoRUlOVkFMKTsKIAkJCX0KIAkJCSpWb2x1bWVCdXMgPSBidXM7 CiAJCQkqVm9sdW1lSUQgPSBpZDsKIAkJCXJldHVybiAoMCk7CiAJCX0KIAl9IGVsc2UgaWYgKCpj cCA9PSAnXDAnKSB7Ci0JCWlmIChidXMgPCAwIHx8IGJ1cyA+IDB4ZmYpIHsKLQkJCWVycm5vID0g RUlOVkFMOwotCQkJcmV0dXJuICgtMSk7Ci0JCX0KKwkJaWYgKGJ1cyA8IDAgfHwgYnVzID4gMHhm ZikKKwkJCXJldHVybiAoRUlOVkFMKTsKIAkJKlZvbHVtZUJ1cyA9IDA7CiAJCSpWb2x1bWVJRCA9 IGJ1czsKIAkJcmV0dXJuICgwKTsKQEAgLTMyOSw3ICszMjcsNyBAQAogCiAJaW9jMiA9IG1wdF9y ZWFkX2lvY19wYWdlKGZkLCAyLCBOVUxMKTsKIAlpZiAoaW9jMiA9PSBOVUxMKQotCQlyZXR1cm4g KC0xKTsKKwkJcmV0dXJuIChlcnJubyk7CiAKIAl2b2wgPSBpb2MyLT5SYWlkVm9sdW1lOwogCWZv ciAoaSA9IDA7IGkgPCBpb2MyLT5OdW1BY3RpdmVWb2x1bWVzOyB2b2wrKywgaSsrKSB7CkBAIC0z NDMsOCArMzQxLDcgQEAKIAkJfQogCX0KIAlmcmVlKGlvYzIpOwotCWVycm5vID0gRUlOVkFMOwot CXJldHVybiAoLTEpOworCXJldHVybiAoRUlOVkFMKTsKIH0KIAogaW50CkBAIC0zNjAsMTUgKzM1 NywxNCBAQAogCXJlcS5oZWFkZXIuUGFnZU51bWJlciA9IFBhZ2VOdW1iZXI7CiAJcmVxLnBhZ2Vf YWRkcmVzcyA9IFBhZ2VBZGRyZXNzOwogCWlmIChpb2N0bChmZCwgTVBUSU9fUkVBRF9DRkdfSEVB REVSLCAmcmVxKSA8IDApCi0JCXJldHVybiAoLTEpOwotCWlmICghSU9DX1NUQVRVU19TVUNDRVNT KHJlcS5pb2Nfc3RhdHVzKSkgeworCQlyZXR1cm4gKGVycm5vKTsKKwlpZiAoSU9DX1NUQVRVU19T VUNDRVNTKHJlcS5pb2Nfc3RhdHVzKSA9PSAwKSB7CiAJCWlmIChJT0NTdGF0dXMgIT0gTlVMTCkK IAkJCSpJT0NTdGF0dXMgPSByZXEuaW9jX3N0YXR1czsKIAkJZWxzZQogCQkJd2FybngoIlJlYWRp bmcgY29uZmlnIHBhZ2UgaGVhZGVyIGZhaWxlZDogJXMiLAogCQkJICAgIG1wdF9pb2Nfc3RhdHVz KHJlcS5pb2Nfc3RhdHVzKSk7Ci0JCWVycm5vID0gRUlPOwotCQlyZXR1cm4gKC0xKTsKKwkJcmV0 dXJuIChFSU8pOwogCX0KIAkqaGVhZGVyID0gcmVxLmhlYWRlcjsKIAlyZXR1cm4gKDApOwpAQCAt MzgwLDcgKzM3Niw3IEBACiB7CiAJc3RydWN0IG1wdF9jZmdfcGFnZV9yZXEgcmVxOwogCXZvaWQg KmJ1ZjsKLQlpbnQgc2F2ZV9lcnJubzsKKwlpbnQgZXJyb3I7CiAKIAlpZiAoSU9DU3RhdHVzICE9 IE5VTEwpCiAJCSpJT0NTdGF0dXMgPSBNUElfSU9DU1RBVFVTX1NVQ0NFU1M7CkBAIC0zOTAsNyAr Mzg2LDcgQEAKIAlyZXEucGFnZV9hZGRyZXNzID0gUGFnZUFkZHJlc3M7CiAJaWYgKGlvY3RsKGZk LCBNUFRJT19SRUFEX0NGR19IRUFERVIsICZyZXEpIDwgMCkKIAkJcmV0dXJuIChOVUxMKTsKLQlp ZiAoIUlPQ19TVEFUVVNfU1VDQ0VTUyhyZXEuaW9jX3N0YXR1cykpIHsKKwlpZiAoSU9DX1NUQVRV U19TVUNDRVNTKHJlcS5pb2Nfc3RhdHVzKSA9PSAwKSB7CiAJCWlmIChJT0NTdGF0dXMgIT0gTlVM TCkKIAkJCSpJT0NTdGF0dXMgPSByZXEuaW9jX3N0YXR1czsKIAkJZWxzZQpAQCAtNDA0LDkgKzQw MCw5IEBACiAJcmVxLmJ1ZiA9IGJ1ZjsKIAliY29weSgmcmVxLmhlYWRlciwgYnVmLCBzaXplb2Yo cmVxLmhlYWRlcikpOwogCWlmIChpb2N0bChmZCwgTVBUSU9fUkVBRF9DRkdfUEFHRSwgJnJlcSkg PCAwKSB7Ci0JCXNhdmVfZXJybm8gPSBlcnJubzsKKwkJZXJyb3IgPSBlcnJubzsKIAkJZnJlZShi dWYpOwotCQllcnJubyA9IHNhdmVfZXJybm87CisJCWVycm5vID0gZXJyb3I7CiAJCXJldHVybiAo TlVMTCk7CiAJfQogCWlmICghSU9DX1NUQVRVU19TVUNDRVNTKHJlcS5pb2Nfc3RhdHVzKSkgewpA QCAtNDI4LDcgKzQyNCw3IEBACiB7CiAJc3RydWN0IG1wdF9leHRfY2ZnX3BhZ2VfcmVxIHJlcTsK IAl2b2lkICpidWY7Ci0JaW50IHNhdmVfZXJybm87CisJaW50IGVycm9yOwogCiAJaWYgKElPQ1N0 YXR1cyAhPSBOVUxMKQogCQkqSU9DU3RhdHVzID0gTVBJX0lPQ1NUQVRVU19TVUNDRVNTOwpAQCAt NDM5LDcgKzQzNSw3IEBACiAJcmVxLnBhZ2VfYWRkcmVzcyA9IFBhZ2VBZGRyZXNzOwogCWlmIChp b2N0bChmZCwgTVBUSU9fUkVBRF9FWFRfQ0ZHX0hFQURFUiwgJnJlcSkgPCAwKQogCQlyZXR1cm4g KE5VTEwpOwotCWlmICghSU9DX1NUQVRVU19TVUNDRVNTKHJlcS5pb2Nfc3RhdHVzKSkgeworCWlm IChJT0NfU1RBVFVTX1NVQ0NFU1MocmVxLmlvY19zdGF0dXMpID09IDApIHsKIAkJaWYgKElPQ1N0 YXR1cyAhPSBOVUxMKQogCQkJKklPQ1N0YXR1cyA9IHJlcS5pb2Nfc3RhdHVzOwogCQllbHNlCkBA IC00NTMsMTIgKzQ0OSwxMiBAQAogCXJlcS5idWYgPSBidWY7CiAJYmNvcHkoJnJlcS5oZWFkZXIs IGJ1Ziwgc2l6ZW9mKHJlcS5oZWFkZXIpKTsKIAlpZiAoaW9jdGwoZmQsIE1QVElPX1JFQURfRVhU X0NGR19QQUdFLCAmcmVxKSA8IDApIHsKLQkJc2F2ZV9lcnJubyA9IGVycm5vOworCQllcnJvciA9 IGVycm5vOwogCQlmcmVlKGJ1Zik7Ci0JCWVycm5vID0gc2F2ZV9lcnJubzsKKwkJZXJybm8gPSBl cnJvcjsKIAkJcmV0dXJuIChOVUxMKTsKIAl9Ci0JaWYgKCFJT0NfU1RBVFVTX1NVQ0NFU1MocmVx LmlvY19zdGF0dXMpKSB7CisJaWYgKElPQ19TVEFUVVNfU1VDQ0VTUyhyZXEuaW9jX3N0YXR1cykg PT0gMCkgewogCQlpZiAoSU9DU3RhdHVzICE9IE5VTEwpCiAJCQkqSU9DU3RhdHVzID0gcmVxLmlv Y19zdGF0dXM7CiAJCWVsc2UKQEAgLTQ4NCwxNiArNDgwLDE1IEBACiAJaGRyID0gYnVmOwogCXJl cS5sZW4gPSBoZHItPlBhZ2VMZW5ndGggKiA0OwogCWlmIChpb2N0bChmZCwgTVBUSU9fV1JJVEVf Q0ZHX1BBR0UsICZyZXEpIDwgMCkKLQkJcmV0dXJuICgtMSk7Ci0JaWYgKCFJT0NfU1RBVFVTX1NV Q0NFU1MocmVxLmlvY19zdGF0dXMpKSB7CisJCXJldHVybiAoZXJybm8pOworCWlmIChJT0NfU1RB VFVTX1NVQ0NFU1MocmVxLmlvY19zdGF0dXMpID09IDApIHsKIAkJaWYgKElPQ1N0YXR1cyAhPSBO VUxMKSB7CiAJCQkqSU9DU3RhdHVzID0gcmVxLmlvY19zdGF0dXM7CiAJCQlyZXR1cm4gKDApOwog CQl9CiAJCXdhcm54KCJXcml0aW5nIGNvbmZpZyBwYWdlIGZhaWxlZDogJXMiLAogCQkgICAgbXB0 X2lvY19zdGF0dXMocmVxLmlvY19zdGF0dXMpKTsKLQkJZXJybm8gPSBFSU87Ci0JCXJldHVybiAo LTEpOworCQlyZXR1cm4gKEVJTyk7CiAJfQogCXJldHVybiAoMCk7CiB9CkBAIC01MDcsMTAgKzUw Miw4IEBACiAKIAlpZiAoSU9DU3RhdHVzICE9IE5VTEwpCiAJCSpJT0NTdGF0dXMgPSBNUElfSU9D U1RBVFVTX1NVQ0NFU1M7Ci0JaWYgKGRhdGFsZW4gPCAwIHx8ICh1bnNpZ25lZClkYXRhbGVuID4g c2l6ZW9mKHJhaWRfYWN0LmFjdGlvbl9kYXRhKSkgewotCQllcnJubyA9IEVJTlZBTDsKLQkJcmV0 dXJuICgtMSk7Ci0JfQorCWlmIChkYXRhbGVuIDwgMCB8fCAodW5zaWduZWQpZGF0YWxlbiA+IHNp emVvZihyYWlkX2FjdC5hY3Rpb25fZGF0YSkpCisJCXJldHVybiAoRUlOVkFMKTsKIAliemVybygm cmFpZF9hY3QsIHNpemVvZihyYWlkX2FjdCkpOwogCXJhaWRfYWN0LmFjdGlvbiA9IEFjdGlvbjsK IAlyYWlkX2FjdC52b2x1bWVfYnVzID0gVm9sdW1lQnVzOwpAQCAtNTI0LDE3ICs1MTcsMTYgQEAK IAl9CiAKIAlpZiAoaW9jdGwoZmQsIE1QVElPX1JBSURfQUNUSU9OLCAmcmFpZF9hY3QpIDwgMCkK LQkJcmV0dXJuICgtMSk7CisJCXJldHVybiAoZXJybm8pOwogCi0JaWYgKCFJT0NfU1RBVFVTX1NV Q0NFU1MocmFpZF9hY3QuaW9jX3N0YXR1cykpIHsKKwlpZiAoSU9DX1NUQVRVU19TVUNDRVNTKHJh aWRfYWN0LmlvY19zdGF0dXMpID09IDApIHsKIAkJaWYgKElPQ1N0YXR1cyAhPSBOVUxMKSB7CiAJ CQkqSU9DU3RhdHVzID0gcmFpZF9hY3QuaW9jX3N0YXR1czsKIAkJCXJldHVybiAoMCk7CiAJCX0K IAkJd2FybngoIlJBSUQgYWN0aW9uIGZhaWxlZDogJXMiLAogCQkgICAgbXB0X2lvY19zdGF0dXMo cmFpZF9hY3QuaW9jX3N0YXR1cykpOwotCQllcnJubyA9IEVJTzsKLQkJcmV0dXJuICgtMSk7CisJ CXJldHVybiAoRUlPKTsKIAl9CiAKIAlpZiAoQWN0aW9uU3RhdHVzICE9IE5VTEwpCkBAIC01NDQs OCArNTM2LDcgQEAKIAkJCXJldHVybiAoMCk7CiAJCXdhcm54KCJSQUlEIGFjdGlvbiBmYWlsZWQ6 ICVzIiwKIAkJICAgIG1wdF9yYWlkX3N0YXR1cyhyYWlkX2FjdC5hY3Rpb25fc3RhdHVzKSk7Ci0J CWVycm5vID0gRUlPOwotCQlyZXR1cm4gKC0xKTsKKwkJcmV0dXJuIChFSU8pOwogCX0KIAogCWlm IChWb2x1bWVTdGF0dXMgIT0gTlVMTCkKSW5kZXg6IHVzci5zYmluL21wdHV0aWwvbXB0X2NvbmZp Zy5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT0KLS0tIHVzci5zYmluL21wdHV0aWwvbXB0X2NvbmZpZy5jCShyZXZpc2lv biAyMTQ1NjgpCisrKyB1c3Iuc2Jpbi9tcHR1dGlsL21wdF9jb25maWcuYwkod29ya2luZyBjb3B5 KQpAQCAtMTA0LDEzICsxMDQsMTQgQEAKIAlpZiAoZXJyb3IpIHsKIAkJZXJybm8gPSBlcnJvcjsK IAkJd2FybigiVW5hYmxlIHRvIGxvb2t1cCB2b2x1bWUgZGV2aWNlIG5hbWUiKTsKLQkJcmV0dXJu ICgtMSk7CisJCXJldHVybiAoZXJyb3IpOwogCX0KIAlzbnByaW50ZihwYXRoLCBzaXplb2YocGF0 aCksICIlcyVzIiwgX1BBVEhfREVWLCBxZC5kZXZuYW1lKTsKIAl2ZmQgPSBvcGVuKHBhdGgsIE9f UkRXUik7CiAJaWYgKHZmZCA8IDApIHsKKwkJZXJyb3IgPSBlcnJubzsKIAkJd2FybigiVW5hYmxl IHRvIGxvY2sgdm9sdW1lICVzIiwgcWQuZGV2bmFtZSk7Ci0JCXJldHVybiAoLTEpOworCQlyZXR1 cm4gKGVycm9yKTsKIAl9CiAJcmV0dXJuICgwKTsKIH0KQEAgLTExOSwxMyArMTIwLDE0IEBACiBt cHRfbG9ja19waHlzZGlzayhzdHJ1Y3QgbXB0X3N0YW5kYWxvbmVfZGlzayAqZGlzaykKIHsKIAlj aGFyIHBhdGhbTUFYUEFUSExFTl07Ci0JaW50IGRmZDsKKwlpbnQgZGZkLCBlcnJvcjsKIAogCXNu cHJpbnRmKHBhdGgsIHNpemVvZihwYXRoKSwgIiVzJXMiLCBfUEFUSF9ERVYsIGRpc2stPmRldm5h bWUpOwogCWRmZCA9IG9wZW4ocGF0aCwgT19SRFdSKTsKIAlpZiAoZGZkIDwgMCkgeworCQllcnJv ciA9IGVycm5vOwogCQl3YXJuKCJVbmFibGUgdG8gbG9jayBkaXNrICVzIiwgZGlzay0+ZGV2bmFt ZSk7Ci0JCXJldHVybiAoLTEpOworCQlyZXR1cm4gKGVycm9yKTsKIAl9CiAJcmV0dXJuICgwKTsK IH0KQEAgLTE0NCw4ICsxNDYsNyBAQAogCQlpZCA9IHN0cnRvbChjcCArIDEsICZjcCwgMCk7CiAJ CWlmICgqY3AgPT0gJ1wwJykgewogCQkJaWYgKGJ1cyA8IDAgfHwgYnVzID4gMHhmZiB8fCBpZCA8 IDAgfHwgaWQgPiAweGZmKSB7Ci0JCQkJZXJybm8gPSBFSU5WQUw7Ci0JCQkJcmV0dXJuICgtMSk7 CisJCQkJcmV0dXJuIChFSU5WQUwpOwogCQkJfQogCQkJZm9yIChpID0gMDsgaSA8IG5kaXNrczsg aSsrKSB7CiAJCQkJaWYgKGRpc2tzW2ldLmJ1cyA9PSAoVTgpYnVzICYmCkBAIC0xNTQsOCArMTU1 LDcgQEAKIAkJCQkJcmV0dXJuICgwKTsKIAkJCQl9CiAJCQl9Ci0JCQllcnJubyA9IEVOT0VOVDsK LQkJCXJldHVybiAoLTEpOworCQkJcmV0dXJuIChFTk9FTlQpOwogCQl9CiAJfQogCkBAIC0xNjYs MTIgKzE2NiwxMCBAQAogCQkJCXJldHVybiAoMCk7CiAJCQl9CiAJCX0KLQkJZXJybm8gPSBFTk9F TlQ7Ci0JCXJldHVybiAoLTEpOworCQlyZXR1cm4gKEVOT0VOVCk7CiAJfQogCi0JZXJybm8gPSBF SU5WQUw7Ci0JcmV0dXJuICgtMSk7CisJcmV0dXJuIChFSU5WQUwpOwogfQogCiAvKgpAQCAtMTgy LDE2ICsxODAsMTcgQEAKIHsKIAlDT05GSUdfUEFHRV9IRUFERVIgaGVhZGVyOwogCUNPTkZJR19Q QUdFX1JBSURfUEhZU19ESVNLXzAgKmNvbmZpZ19wYWdlOworCWludCBlcnJvcjsKIAlVMzIgQWN0 aW9uRGF0YTsKIAotCWlmIChtcHRfcmVhZF9jb25maWdfcGFnZV9oZWFkZXIoZmQsIE1QSV9DT05G SUdfUEFHRVRZUEVfUkFJRF9QSFlTRElTSywKLQkgICAgMCwgMCwgJmhlYWRlciwgTlVMTCkgPCAw KQotCQlyZXR1cm4gKC0xKTsKKwllcnJvciA9IG1wdF9yZWFkX2NvbmZpZ19wYWdlX2hlYWRlcihm ZCwgTVBJX0NPTkZJR19QQUdFVFlQRV9SQUlEX1BIWVNESVNLLAorCSAgICAwLCAwLCAmaGVhZGVy LCBOVUxMKTsKKwlpZiAoZXJyb3IpCisJCXJldHVybiAoZXJyb3IpOwogCWlmIChoZWFkZXIuUGFn ZVZlcnNpb24gPiBNUElfUkFJRFBIWVNESVNLUEFHRTBfUEFHRVZFUlNJT04pIHsKIAkJd2Fybngo IlVuc3VwcG9ydGVkIFJBSUQgcGh5c2Rpc2sgcGFnZSAwIHZlcnNpb24gJWQiLAogCQkgICAgaGVh ZGVyLlBhZ2VWZXJzaW9uKTsKLQkJZXJybm8gPSBFT1BOT1RTVVBQOwotCQlyZXR1cm4gKC0xKTsK KwkJcmV0dXJuIChFT1BOT1RTVVBQKTsKIAl9CQkKIAljb25maWdfcGFnZSA9IGNhbGxvYygxLCBz aXplb2YoQ09ORklHX1BBR0VfUkFJRF9QSFlTX0RJU0tfMCkpOwogCWNvbmZpZ19wYWdlLT5IZWFk ZXIuUGFnZVR5cGUgPSBNUElfQ09ORklHX1BBR0VUWVBFX1JBSURfUEhZU0RJU0s7CkBAIC0yMDMs MTAgKzIwMiwxMSBAQAogCWNvbmZpZ19wYWdlLT5QaHlzRGlza0lEID0gZGlzay0+dGFyZ2V0Owog CiAJLyogWFhYOiBFbmNsb3N1cmUgaW5mbyBmb3IgUGh5c0Rpc2tTZXR0aW5ncz8gKi8KLQlpZiAo bXB0X3JhaWRfYWN0aW9uKGZkLCBNUElfUkFJRF9BQ1RJT05fQ1JFQVRFX1BIWVNESVNLLCAwLCAw LCAwLCAwLAorCWVycm9yID0gbXB0X3JhaWRfYWN0aW9uKGZkLCBNUElfUkFJRF9BQ1RJT05fQ1JF QVRFX1BIWVNESVNLLCAwLCAwLCAwLCAwLAogCSAgICBjb25maWdfcGFnZSwgc2l6ZW9mKENPTkZJ R19QQUdFX1JBSURfUEhZU19ESVNLXzApLCBOVUxMLAotCSAgICAmQWN0aW9uRGF0YSwgc2l6ZW9m KEFjdGlvbkRhdGEpLCBOVUxMLCBOVUxMLCAxKSA8IDApCi0JCXJldHVybiAoLTEpOworCSAgICAm QWN0aW9uRGF0YSwgc2l6ZW9mKEFjdGlvbkRhdGEpLCBOVUxMLCBOVUxMLCAxKTsKKwlpZiAoZXJy b3IpCisJCXJldHVybiAoZXJyb3IpOwogCSpQaHlzRGlza051bSA9IEFjdGlvbkRhdGEgJiAweGZm OwogCXJldHVybiAoMCk7CiB9CkBAIC0yMzIsMTggKzIzMiwyMCBAQAogCUlPQ18zX1BIWVNfRElT SyAqZGlzazsKIAlDT05GSUdfUEFHRV9JT0NfNSAqaW9jNTsKIAlJT0NfNV9IT1RfU1BBUkUgKnNw YXJlOwotCWludCBjaCwgZmQsIGk7CisJaW50IGNoLCBlcnJvciwgZmQsIGk7CiAKIAlmZCA9IG1w dF9vcGVuKG1wdF91bml0KTsKIAlpZiAoZmQgPCAwKSB7CisJCWVycm9yID0gZXJybm87CiAJCXdh cm4oIm1wdF9vcGVuIik7Ci0JCXJldHVybiAoZXJybm8pOworCQlyZXR1cm4gKGVycm9yKTsKIAl9 CiAKIAlpb2MyID0gbXB0X3JlYWRfaW9jX3BhZ2UoZmQsIDIsIE5VTEwpOwogCWlmIChpb2MyID09 IE5VTEwpIHsKKwkJZXJyb3IgPSBlcnJubzsKIAkJd2FybigiRmFpbGVkIHRvIGZldGNoIHZvbHVt ZSBsaXN0Iik7Ci0JCXJldHVybiAoZXJybm8pOworCQlyZXR1cm4gKGVycm9yKTsKIAl9CiAKIAkv KiBMb2NrIGFsbCB0aGUgdm9sdW1lcyBmaXJzdC4gKi8KQEAgLTI2NywxNCArMjY5LDE4IEBACiAK IAkvKiBEZWxldGUgYWxsIHRoZSB2b2x1bWVzLiAqLwogCXZvbCA9IGlvYzItPlJhaWRWb2x1bWU7 Ci0JZm9yIChpID0gMDsgaSA8IGlvYzItPk51bUFjdGl2ZVZvbHVtZXM7IHZvbCsrLCBpKyspCi0J CWlmIChtcHRfcmFpZF9hY3Rpb24oZmQsIE1QSV9SQUlEX0FDVElPTl9ERUxFVEVfVk9MVU1FLAor CWZvciAoaSA9IDA7IGkgPCBpb2MyLT5OdW1BY3RpdmVWb2x1bWVzOyB2b2wrKywgaSsrKSB7CisJ CWVycm9yID0gbXB0X3JhaWRfYWN0aW9uKGZkLCBNUElfUkFJRF9BQ1RJT05fREVMRVRFX1ZPTFVN RSwKIAkJICAgIHZvbC0+Vm9sdW1lQnVzLCB2b2wtPlZvbHVtZUlELCAwLAogCQkgICAgTVBJX1JB SURfQUNUSU9OX0FEQVRBX0RFTF9QSFlTX0RJU0tTIHwKIAkJICAgIE1QSV9SQUlEX0FDVElPTl9B REFUQV9aRVJPX0xCQTAsIE5VTEwsIDAsIE5VTEwsIE5VTEwsIDAsCi0JCSAgICBOVUxMLCBOVUxM LCAwKSA8IDApCisJCSAgICBOVUxMLCBOVUxMLCAwKTsKKwkJaWYgKGVycm9yKSB7CisJCQllcnJu byA9IGVycm9yOwogCQkJd2FybigiRmFpbGVkIHRvIGRlbGV0ZSB2b2x1bWUgJXMiLAogCQkJICAg IG1wdF92b2x1bWVfbmFtZSh2b2wtPlZvbHVtZUJ1cywgdm9sLT5Wb2x1bWVJRCkpOworCQl9CisJ fQogCWZyZWUoaW9jMik7CiAKIAkvKiBEZWxldGUgYWxsIHRoZSBzcGFyZXMuICovCkBAIC00MTEs OCArNDE3LDkgQEAKIAkJLyogU2VlIGlmIGl0IGlzIGEgc3RhbmRhbG9uZSBkaXNrLiAqLwogCQlp ZiAobXB0X2xvb2t1cF9zdGFuZGFsb25lX2Rpc2soY3AsIHN0YXRlLT5zZGlza3MsCiAJCSAgICBz dGF0ZS0+bnNkaXNrcywgJmkpIDwgMCkgeworCQkJZXJyb3IgPSBlcnJubzsKIAkJCXdhcm4oIlVu YWJsZSB0byBsb29rdXAgZHJpdmUgJXMiLCBjcCk7Ci0JCQlyZXR1cm4gKGVycm5vKTsKKwkJCXJl dHVybiAoZXJyb3IpOwogCQl9CiAJCWRpbmZvLT5zZGlzayA9ICZzdGF0ZS0+c2Rpc2tzW2ldOwog CkBAIC00MzMsMTcgKzQ0MCwxOCBAQAogewogCXN0cnVjdCBkcml2ZV9pbmZvICpkaW5mbzsKIAlV OCBQaHlzRGlza051bTsKLQlpbnQgaTsKKwlpbnQgZXJyb3IsIGk7CiAKIAlmb3IgKGkgPSAwLCBk aW5mbyA9IGluZm8tPmRyaXZlczsgaSA8IGluZm8tPmRyaXZlX2NvdW50OwogCSAgICAgaSsrLCBk aW5mbysrKSB7CiAJCWlmIChkaW5mby0+aW5mbyA9PSBOVUxMKSB7CiAJCQlpZiAobXB0X2NyZWF0 ZV9waHlzZGlzayhmZCwgZGluZm8tPnNkaXNrLAogCQkJICAgICZQaHlzRGlza051bSkgPCAwKSB7 CisJCQkJZXJyb3IgPSBlcnJubzsKIAkJCQl3YXJuKAogCQkJICAgICJGYWlsZWQgdG8gY3JlYXRl IHBoeXNpY2FsIGRpc2sgcGFnZSBmb3IgJXMiLAogCQkJCSAgICBkaW5mby0+c2Rpc2stPmRldm5h bWUpOwotCQkJCXJldHVybiAoZXJybm8pOworCQkJCXJldHVybiAoZXJyb3IpOwogCQkJfQogCQkJ aWYgKHZlcmJvc2UpCiAJCQkJcHJpbnRmKCJBZGRlZCBkcml2ZSAlcyB3aXRoIFBoeXNEaXNrTnVt ICV1XG4iLApAQCAtNTAwLDExICs1MDgsMTQgQEAKICAgICAgICAgVTMyIE1pbkxCQTsKIAl1aW50 NjRfdCBNYXhMQkE7CiAJc2l6ZV90IHBhZ2Vfc2l6ZTsKLQlpbnQgaTsKKwlpbnQgZXJyb3IsIGk7 CiAKLQlpZiAobXB0X3JlYWRfY29uZmlnX3BhZ2VfaGVhZGVyKGZkLCBNUElfQ09ORklHX1BBR0VU WVBFX1JBSURfVk9MVU1FLAotCSAgICAwLCAwLCAmaGVhZGVyLCBOVUxMKSA8IDApCisJZXJyb3Ig PSBtcHRfcmVhZF9jb25maWdfcGFnZV9oZWFkZXIoZmQsIE1QSV9DT05GSUdfUEFHRVRZUEVfUkFJ RF9WT0xVTUUsCisJICAgIDAsIDAsICZoZWFkZXIsIE5VTEwpOworCWlmIChlcnJvcikgeworCQll cnJubyA9IGVycm9yOwogCQlyZXR1cm4gKE5VTEwpOworCX0KIAlpZiAoaGVhZGVyLlBhZ2VWZXJz aW9uID4gTVBJX1JBSURWT0xQQUdFMF9QQUdFVkVSU0lPTikgewogCQl3YXJueCgiVW5zdXBwb3J0 ZWQgUkFJRCB2b2x1bWUgcGFnZSAwIHZlcnNpb24gJWQiLAogCQkgICAgaGVhZGVyLlBhZ2VWZXJz aW9uKTsKQEAgLTUxNCw2ICs1MjUsOCBAQAogCXBhZ2Vfc2l6ZSA9IHNpemVvZihDT05GSUdfUEFH RV9SQUlEX1ZPTF8wKSArCiAJICAgIHNpemVvZihSQUlEX1ZPTDBfUEhZU19ESVNLKSAqIChpbmZv LT5kcml2ZV9jb3VudCAtIDEpOwogCXZvbCA9IGNhbGxvYygxLCBwYWdlX3NpemUpOworCWlmICh2 b2wgPT0gTlVMTCkKKwkJcmV0dXJuIChOVUxMKTsKIAogCS8qIEhlYWRlciAqLwogCXZvbC0+SGVh ZGVyLlBhZ2VUeXBlID0gTVBJX0NPTkZJR19QQUdFVFlQRV9SQUlEX1ZPTFVNRTsKQEAgLTYwNyw4 ICs2MjAsOCBAQAogCUNPTkZJR19QQUdFX1JBSURfVk9MXzAgKnZvbDsKIAlzdHJ1Y3QgY29uZmln X2lkX3N0YXRlIHN0YXRlOwogCXN0cnVjdCB2b2x1bWVfaW5mbyAqaW5mbzsKLQlpbnQgY2gsIGVy cm9yLCBmZCwgaSwgcmFpZF90eXBlLCB2ZXJib3NlLCBxdWljazsKIAlsb25nIHN0cmlwZV9zaXpl OworCWludCBjaCwgZXJyb3IsIGZkLCBpLCBxdWljaywgcmFpZF90eXBlLCB2ZXJib3NlOwogI2lm ZGVmIERFQlVHCiAJaW50IGR1bXA7CiAjZW5kaWYKQEAgLTYyMCw4ICs2MzMsOSBAQAogCQogCWZk ID0gbXB0X29wZW4obXB0X3VuaXQpOwogCWlmIChmZCA8IDApIHsKKwkJZXJyb3IgPSBlcnJubzsK IAkJd2FybigibXB0X29wZW4iKTsKLQkJcmV0dXJuIChlcnJubyk7CisJCXJldHVybiAoZXJyb3Ip OwogCX0KIAogCS8qIExvb2t1cCB0aGUgUkFJRCB0eXBlIGZpcnN0LiAqLwpAQCAtNjc3LDggKzY5 MSw5IEBACiAJLyogRmV0Y2ggZXhpc3RpbmcgY29uZmlnIGRhdGEuICovCiAJc3RhdGUuaW9jMiA9 IG1wdF9yZWFkX2lvY19wYWdlKGZkLCAyLCBOVUxMKTsKIAlpZiAoc3RhdGUuaW9jMiA9PSBOVUxM KSB7CisJCWVycm9yID0gZXJybm87CiAJCXdhcm4oIkZhaWxlZCB0byByZWFkIHZvbHVtZSBsaXN0 Iik7Ci0JCXJldHVybiAoZXJybm8pOworCQlyZXR1cm4gKGVycm9yKTsKIAl9CiAJc3RhdGUubGlz dCA9IG1wdF9wZF9saXN0KGZkKTsKIAlpZiAoc3RhdGUubGlzdCA9PSBOVUxMKQpAQCAtNjk2LDYg KzcxMSw4IEBACiAJCXJldHVybiAoRUlOVkFMKTsKIAl9CiAJaW5mbyA9IGNhbGxvYygxLCBzaXpl b2YoKmluZm8pKTsKKwlpZiAoaW5mbyA9PSBOVUxMKQorCQlyZXR1cm4gKEVOT01FTSk7CiAJZXJy b3IgPSBwYXJzZV92b2x1bWUoZmQsIHJhaWRfdHlwZSwgJnN0YXRlLCBhdlswXSwgaW5mbyk7CiAJ aWYgKGVycm9yKQogCQlyZXR1cm4gKGVycm9yKTsKQEAgLTcwNyw2ICs3MjQsOCBAQAogCiAJLyog QnVpbGQgdGhlIHZvbHVtZS4gKi8KIAl2b2wgPSBidWlsZF92b2x1bWUoZmQsIGluZm8sIHJhaWRf dHlwZSwgc3RyaXBlX3NpemUsICZzdGF0ZSwgdmVyYm9zZSk7CisJaWYgKHZvbCA9PSBOVUxMKQor CQlyZXR1cm4gKGVycm5vKTsKIAogI2lmZGVmIERFQlVHCiAJaWYgKGR1bXApIHsKQEAgLTcxNiwx MiArNzM1LDEzIEBACiAjZW5kaWYKIAogCS8qIFNlbmQgdGhlIG5ldyB2b2x1bWUgdG8gdGhlIGNv bnRyb2xsZXIuICovCi0JaWYgKG1wdF9yYWlkX2FjdGlvbihmZCwgTVBJX1JBSURfQUNUSU9OX0NS RUFURV9WT0xVTUUsIHZvbC0+Vm9sdW1lQnVzLAorCWVycm9yID0gbXB0X3JhaWRfYWN0aW9uKGZk LCBNUElfUkFJRF9BQ1RJT05fQ1JFQVRFX1ZPTFVNRSwgdm9sLT5Wb2x1bWVCdXMsCiAJICAgIHZv bC0+Vm9sdW1lSUQsIDAsIHF1aWNrID8gTVBJX1JBSURfQUNUSU9OX0FEQVRBX0RPX05PVF9TWU5D IDogMCwKLQkgICAgdm9sLCB2b2wtPkhlYWRlci5QYWdlTGVuZ3RoICogNCwgTlVMTCwgTlVMTCwg MCwgTlVMTCwgTlVMTCwgMSkgPAotCSAgICAwKSB7CisJICAgIHZvbCwgdm9sLT5IZWFkZXIuUGFn ZUxlbmd0aCAqIDQsIE5VTEwsIE5VTEwsIDAsIE5VTEwsIE5VTEwsIDEpOworCWlmIChlcnJvcikg eworCQllcnJubyA9IGVycm9yOwogCQl3YXJuKCJGYWlsZWQgdG8gYWRkIHZvbHVtZSIpOwotCQly ZXR1cm4gKGVycm5vKTsKKwkJcmV0dXJuIChlcnJvcik7CiAJfQogCiAjaWZkZWYgREVCVUcKQEAg LTc0NSw3ICs3NjUsNyBAQAogZGVsZXRlX3ZvbHVtZShpbnQgYWMsIGNoYXIgKiphdikKIHsKIAlV OCBWb2x1bWVCdXMsIFZvbHVtZUlEOwotCWludCBmZDsKKwlpbnQgZXJyb3IsIGZkOwogCiAJaWYg KGFjICE9IDIpIHsKIAkJd2FybngoImRlbGV0ZTogdm9sdW1lIHJlcXVpcmVkIik7CkBAIC03NTQs MjQgKzc3NCwyOSBAQAogCiAJZmQgPSBtcHRfb3BlbihtcHRfdW5pdCk7CiAJaWYgKGZkIDwgMCkg eworCQllcnJvciA9IGVycm5vOwogCQl3YXJuKCJtcHRfb3BlbiIpOwotCQlyZXR1cm4gKGVycm5v KTsKKwkJcmV0dXJuIChlcnJvcik7CiAJfQogCi0JaWYgKG1wdF9sb29rdXBfdm9sdW1lKGZkLCBh dlsxXSwgJlZvbHVtZUJ1cywgJlZvbHVtZUlEKSA8IDApIHsKKwllcnJvciA9IG1wdF9sb29rdXBf dm9sdW1lKGZkLCBhdlsxXSwgJlZvbHVtZUJ1cywgJlZvbHVtZUlEKTsKKwlpZiAoZXJyb3IpIHsK KwkJZXJybm8gPSBlcnJvcjsKIAkJd2FybigiSW52YWxpZCB2b2x1bWUgJXMiLCBhdlsxXSk7Ci0J CXJldHVybiAoZXJybm8pOworCQlyZXR1cm4gKGVycm9yKTsKIAl9CiAKIAlpZiAobXB0X2xvY2tf dm9sdW1lKFZvbHVtZUJ1cywgVm9sdW1lSUQpIDwgMCkKIAkJcmV0dXJuIChlcnJubyk7CiAKLQlp ZiAobXB0X3JhaWRfYWN0aW9uKGZkLCBNUElfUkFJRF9BQ1RJT05fREVMRVRFX1ZPTFVNRSwgVm9s dW1lQnVzLAorCWVycm9yID0gbXB0X3JhaWRfYWN0aW9uKGZkLCBNUElfUkFJRF9BQ1RJT05fREVM RVRFX1ZPTFVNRSwgVm9sdW1lQnVzLAogCSAgICBWb2x1bWVJRCwgMCwgTVBJX1JBSURfQUNUSU9O X0FEQVRBX0RFTF9QSFlTX0RJU0tTIHwKIAkgICAgTVBJX1JBSURfQUNUSU9OX0FEQVRBX1pFUk9f TEJBMCwgTlVMTCwgMCwgTlVMTCwgTlVMTCwgMCwgTlVMTCwKLQkgICAgTlVMTCwgMCkgPCAwKSB7 CisJICAgIE5VTEwsIDApOworCWlmIChlcnJvcikgeworCQllcnJubyA9IGVycm9yOwogCQl3YXJu KCJGYWlsZWQgdG8gZGVsZXRlIHZvbHVtZSIpOwotCQlyZXR1cm4gKGVycm5vKTsKKwkJcmV0dXJu IChlcnJvcik7CiAJfQogCiAJbXB0X3Jlc2Nhbl9idXMoLTEsIC0xKTsKQEAgLTc4OCwxNiArODEz LDE4IEBACiAJQ09ORklHX1BBR0VfSU9DXzIgKmlvYzI7CiAJQ09ORklHX1BBR0VfSU9DXzJfUkFJ RF9WT0wgKnZvbDsKIAlVOCBWb2x1bWVCdXMsIFZvbHVtZUlEOwotCWludCBpLCBqLCBuZXdfcG9v bCwgcG9vbF9jb3VudFs3XTsKKwlpbnQgZXJyb3IsIGksIGosIG5ld19wb29sLCBwb29sX2NvdW50 WzddOwogCi0JaWYgKG1wdF9sb29rdXBfdm9sdW1lKGZkLCBuYW1lLCAmVm9sdW1lQnVzLCAmVm9s dW1lSUQpIDwgMCkgeworCWVycm9yID0gbXB0X2xvb2t1cF92b2x1bWUoZmQsIG5hbWUsICZWb2x1 bWVCdXMsICZWb2x1bWVJRCk7CisJaWYgKGVycm9yKSB7CisJCWVycm5vID0gZXJyb3I7CiAJCXdh cm4oIkludmFsaWQgdm9sdW1lICVzIiwgbmFtZSk7Ci0JCXJldHVybiAoLTEpOworCQlyZXR1cm4g KGVycm9yKTsKIAl9CiAKIAlpbmZvID0gbXB0X3ZvbF9pbmZvKGZkLCBWb2x1bWVCdXMsIFZvbHVt ZUlELCBOVUxMKTsKIAlpZiAoaW5mbyA9PSBOVUxMKQotCQlyZXR1cm4gKC0xKTsKKwkJcmV0dXJu IChlcnJubyk7CiAKIAkvKgogCSAqIENoZWNrIGZvciBhbiBleGlzdGluZyBwb29sIG90aGVyIHRo YW4gcG9vbCAwICh1c2VkIGZvcgpAQCAtODE3LDE1ICs4NDQsMTYgQEAKIAkgKi8KIAlpb2MyID0g bXB0X3JlYWRfaW9jX3BhZ2UoZmQsIDIsIE5VTEwpOwogCWlmIChpb2MyID09IE5VTEwpIHsKKwkJ ZXJyb3IgPSBlcnJubzsKIAkJd2FybigiRmFpbGVkIHRvIGZldGNoIHZvbHVtZSBsaXN0Iik7Ci0J CXJldHVybiAoLTEpOworCQlyZXR1cm4gKGVycm9yKTsKIAl9CiAJYnplcm8ocG9vbF9jb3VudCwg c2l6ZW9mKHBvb2xfY291bnQpKTsJCiAJdm9sID0gaW9jMi0+UmFpZFZvbHVtZTsKIAlmb3IgKGkg PSAwOyBpIDwgaW9jMi0+TnVtQWN0aXZlVm9sdW1lczsgdm9sKyssIGkrKykgewogCQlpbmZvID0g bXB0X3ZvbF9pbmZvKGZkLCB2b2wtPlZvbHVtZUJ1cywgdm9sLT5Wb2x1bWVJRCwgTlVMTCk7CiAJ CWlmIChpbmZvID09IE5VTEwpCi0JCQlyZXR1cm4gKC0xKTsKKwkJCXJldHVybiAoZXJybm8pOwog CQlmb3IgKGogPSAwOyBqIDwgNzsgaisrKQogCQkJaWYgKGluZm8tPlZvbHVtZVNldHRpbmdzLkhv dFNwYXJlUG9vbCAmICgxIDw8IChqICsgMSkpKQogCQkJCXBvb2xfY291bnRbal0rKzsKQEAgLTg0 MywxNCArODcxLDE1IEBACiAJLyogQWRkIHRoaXMgcG9vbCB0byB0aGUgdm9sdW1lLiAqLwogCWlu Zm8gPSBtcHRfdm9sX2luZm8oZmQsIFZvbHVtZUJ1cywgVm9sdW1lSUQsIE5VTEwpOwogCWlmIChp bmZvID09IE5VTEwpCi0JCXJldHVybiAoLTEpOworCQlyZXR1cm4gKGVycm9yKTsKIAlpbmZvLT5W b2x1bWVTZXR0aW5ncy5Ib3RTcGFyZVBvb2wgfD0gKDEgPDwgbmV3X3Bvb2wpOwotCWlmIChtcHRf cmFpZF9hY3Rpb24oZmQsIE1QSV9SQUlEX0FDVElPTl9DSEFOR0VfVk9MVU1FX1NFVFRJTkdTLAor CWVycm9yID0gbXB0X3JhaWRfYWN0aW9uKGZkLCBNUElfUkFJRF9BQ1RJT05fQ0hBTkdFX1ZPTFVN RV9TRVRUSU5HUywKIAkgICAgVm9sdW1lQnVzLCBWb2x1bWVJRCwgMCwgKihVMzIgKikmaW5mby0+ Vm9sdW1lU2V0dGluZ3MsIE5VTEwsIDAsCi0JICAgIE5VTEwsIE5VTEwsIDAsIE5VTEwsIE5VTEws IDApIDwgMCkgeworCSAgICBOVUxMLCBOVUxMLCAwLCBOVUxMLCBOVUxMLCAwKTsKKwlpZiAoZXJy b3IpIHsKIAkJd2FybngoIkZhaWxlZCB0byBhZGQgc3BhcmUgcG9vbCAlZCB0byAlcyIsIG5ld19w b29sLAogCQkgICAgbXB0X3ZvbHVtZV9uYW1lKFZvbHVtZUJ1cywgVm9sdW1lSUQpKTsKLQkJcmV0 dXJuICgtMSk7CisJCXJldHVybiAoZXJyb3IpOwogCX0KIAlmcmVlKGluZm8pOwogCkBAIC04Nzgs MTMgKzkwNywxNSBAQAogCiAJZmQgPSBtcHRfb3BlbihtcHRfdW5pdCk7CiAJaWYgKGZkIDwgMCkg eworCQllcnJvciA9IGVycm5vOwogCQl3YXJuKCJtcHRfb3BlbiIpOwotCQlyZXR1cm4gKGVycm5v KTsKKwkJcmV0dXJuIChlcnJvcik7CiAJfQogCiAJaWYgKGFjID09IDMpIHsKLQkJaWYgKGZpbmRf dm9sdW1lX3NwYXJlX3Bvb2woZmQsIGF2WzJdLCAmcG9vbCkgPCAwKQotCQkJcmV0dXJuIChlcnJu byk7CisJCWVycm9yID0gZmluZF92b2x1bWVfc3BhcmVfcG9vbChmZCwgYXZbMl0sICZwb29sKTsK KwkJaWYgKGVycm9yKQorCQkJcmV0dXJuIChlcnJvcik7CiAJfSBlbHNlCiAJCXBvb2wgPSBNUElf UkFJRF9IT1RfU1BBUkVfUE9PTF8wOwogCkBAIC05MDIsMTYgKzkzMywxOCBAQAogCiAJCWlmICht cHRfbG9va3VwX3N0YW5kYWxvbmVfZGlzayhhdlsxXSwgc2Rpc2tzLCBuc2Rpc2tzLCAmaSkgPAog CQkgICAgMCkgeworCQkJZXJyb3IgPSBlcnJubzsKIAkJCXdhcm4oIlVuYWJsZSB0byBsb29rdXAg ZHJpdmUgJXMiLCBhdlsxXSk7Ci0JCQlyZXR1cm4gKGVycm5vKTsKKwkJCXJldHVybiAoZXJyb3Ip OwogCQl9CiAKIAkJaWYgKG1wdF9sb2NrX3BoeXNkaXNrKCZzZGlza3NbaV0pIDwgMCkKIAkJCXJl dHVybiAoZXJybm8pOwogCiAJCWlmIChtcHRfY3JlYXRlX3BoeXNkaXNrKGZkLCAmc2Rpc2tzW2ld LCAmUGh5c0Rpc2tOdW0pIDwgMCkgeworCQkJZXJyb3IgPSBlcnJubzsKIAkJCXdhcm4oIkZhaWxl ZCB0byBjcmVhdGUgcGh5c2ljYWwgZGlzayBwYWdlIik7Ci0JCQlyZXR1cm4gKGVycm5vKTsKKwkJ CXJldHVybiAoZXJyb3IpOwogCQl9CiAJCWZyZWUoc2Rpc2tzKTsKIAl9CkBAIC05MTksOCArOTUy LDkgQEAKIAogCWluZm8gPSBtcHRfcGRfaW5mbyhmZCwgUGh5c0Rpc2tOdW0sIE5VTEwpOwogCWlm IChpbmZvID09IE5VTEwpIHsKKwkJZXJyb3IgPSBlcnJubzsKIAkJd2FybigiRmFpbGVkIHRvIGZl dGNoIGRyaXZlIGluZm8iKTsKLQkJcmV0dXJuIChlcnJubyk7CisJCXJldHVybiAoZXJyb3IpOwog CX0KIAogCWluZm8tPlBoeXNEaXNrU2V0dGluZ3MuSG90U3BhcmVQb29sID0gcG9vbDsKQEAgLTky OCw4ICs5NjIsOSBAQAogCSAgICAwLCBQaHlzRGlza051bSwgKihVMzIgKikmaW5mby0+UGh5c0Rp c2tTZXR0aW5ncywgTlVMTCwgMCwgTlVMTCwKIAkgICAgTlVMTCwgMCwgTlVMTCwgTlVMTCwgMCk7 CiAJaWYgKGVycm9yKSB7CisJCWVycm5vID0gZXJyb3I7CiAJCXdhcm4oIkZhaWxlZCB0byBhc3Np Z24gc3BhcmUiKTsKLQkJcmV0dXJuIChlcnJubyk7CisJCXJldHVybiAoZXJyb3IpOwogCX0KIAog CWZyZWUoaW5mbyk7CkBAIC05NTQsOCArOTg5LDkgQEAKIAogCWZkID0gbXB0X29wZW4obXB0X3Vu aXQpOwogCWlmIChmZCA8IDApIHsKKwkJZXJyb3IgPSBlcnJubzsKIAkJd2FybigibXB0X29wZW4i KTsKLQkJcmV0dXJuIChlcnJubyk7CisJCXJldHVybiAoZXJyb3IpOwogCX0KIAogCWxpc3QgPSBt cHRfcGRfbGlzdChmZCk7CkBAIC05NzIsOCArMTAwOCw5IEBACiAJCiAJaW5mbyA9IG1wdF9wZF9p bmZvKGZkLCBQaHlzRGlza051bSwgTlVMTCk7CiAJaWYgKGluZm8gPT0gTlVMTCkgeworCQllcnJv ciA9IGVycm5vOwogCQl3YXJuKCJGYWlsZWQgdG8gZmV0Y2ggZHJpdmUgaW5mbyIpOwotCQlyZXR1 cm4gKGVycm5vKTsKKwkJcmV0dXJuIChlcnJvcik7CiAJfQogCiAJaWYgKGluZm8tPlBoeXNEaXNr U2V0dGluZ3MuSG90U3BhcmVQb29sID09IDApIHsKQEAgLTk4MiwxMSArMTAxOSwxNCBAQAogCX0K IAogCWlmIChtcHRfZGVsZXRlX3BoeXNkaXNrKGZkLCBQaHlzRGlza051bSkgPCAwKSB7CisJCWVy cm9yID0gZXJybm87CiAJCXdhcm4oIkZhaWxlZCB0byBkZWxldGUgcGh5c2ljYWwgZGlzayBwYWdl Iik7Ci0JCXJldHVybiAoZXJybm8pOworCQlyZXR1cm4gKGVycm9yKTsKIAl9CiAKLQltcHRfcmVz Y2FuX2J1cyhpbmZvLT5QaHlzRGlza0J1cywgaW5mby0+UGh5c0Rpc2tJRCk7CisJZXJyb3IgPSBt cHRfcmVzY2FuX2J1cyhpbmZvLT5QaHlzRGlza0J1cywgaW5mby0+UGh5c0Rpc2tJRCk7CisJaWYg KGVycm9yKQorCQlyZXR1cm4gKGVycm9yKTsKIAlmcmVlKGluZm8pOwogCWNsb3NlKGZkKTsKIApA QCAtMTAxMSw4ICsxMDUxLDkgQEAKIAogCWZkID0gbXB0X29wZW4obXB0X3VuaXQpOwogCWlmIChm ZCA8IDApIHsKKwkJZXJyb3IgPSBlcnJubzsKIAkJd2FybigibXB0X29wZW4iKTsKLQkJcmV0dXJu IChlcnJubyk7CisJCXJldHVybiAoZXJyb3IpOwogCX0KIAogCWVycm9yID0gbXB0X2ZldGNoX2Rp c2tzKGZkLCAmbmRpc2tzLCAmZGlza3MpOwpAQCAtMTAyMiwxNiArMTA2MywxOCBAQAogCX0KIAog CWlmIChtcHRfbG9va3VwX3N0YW5kYWxvbmVfZGlzayhhdlsxXSwgZGlza3MsIG5kaXNrcywgJmkp IDwgMCkgeworCQllcnJvciA9IGVycm5vOwogCQl3YXJuKCJVbmFibGUgdG8gbG9va3VwIGRyaXZl Iik7Ci0JCXJldHVybiAoZXJybm8pOworCQlyZXR1cm4gKGVycm9yKTsKIAl9CiAKIAlpZiAobXB0 X2xvY2tfcGh5c2Rpc2soJmRpc2tzW2ldKSA8IDApCiAJCXJldHVybiAoZXJybm8pOwogCiAJaWYg KG1wdF9jcmVhdGVfcGh5c2Rpc2soZmQsICZkaXNrc1tpXSwgJlBoeXNEaXNrTnVtKSA8IDApIHsK KwkJZXJyb3IgPSBlcnJubzsKIAkJd2FybigiRmFpbGVkIHRvIGNyZWF0ZSBwaHlzaWNhbCBkaXNr IHBhZ2UiKTsKLQkJcmV0dXJuIChlcnJubyk7CisJCXJldHVybiAoZXJyb3IpOwogCX0KIAlmcmVl KGRpc2tzKTsKIApAQCAtMTA0OCw3ICsxMDkxLDcgQEAKIHsKIAlDT05GSUdfUEFHRV9SQUlEX1BI WVNfRElTS18wICppbmZvOwogCXN0cnVjdCBtcHRfZHJpdmVfbGlzdCAqbGlzdDsKLQlpbnQgZmQ7 CisJaW50IGVycm9yLCBmZDsKIAlVOCBQaHlzRGlza051bTsKIAogCWlmIChhYyAhPSAyKSB7CkBA IC0xMDU4LDggKzExMDEsOSBAQAogCiAJZmQgPSBtcHRfb3BlbihtcHRfdW5pdCk7CiAJaWYgKGZk IDwgMCkgeworCQllcnJvciA9IGVycm5vOwogCQl3YXJuKCJtcHRfb3BlbiIpOwotCQlyZXR1cm4g KGVycm5vKTsKKwkJcmV0dXJuIChlcnJvcik7CiAJfQogCiAJbGlzdCA9IG1wdF9wZF9saXN0KGZk KTsKQEAgLTEwNjcsMjMgKzExMTEsMjggQEAKIAkJcmV0dXJuIChlcnJubyk7CiAKIAlpZiAobXB0 X2xvb2t1cF9kcml2ZShsaXN0LCBhdlsxXSwgJlBoeXNEaXNrTnVtKSA8IDApIHsKKwkJZXJyb3Ig PSBlcnJubzsKIAkJd2FybigiRmFpbGVkIHRvIGZpbmQgZHJpdmUgJXMiLCBhdlsxXSk7Ci0JCXJl dHVybiAoZXJybm8pOworCQlyZXR1cm4gKGVycm9yKTsKIAl9CiAJbXB0X2ZyZWVfcGRfbGlzdChs aXN0KTsKIAogCWluZm8gPSBtcHRfcGRfaW5mbyhmZCwgUGh5c0Rpc2tOdW0sIE5VTEwpOwogCWlm IChpbmZvID09IE5VTEwpIHsKKwkJZXJyb3IgPSBlcnJubzsKIAkJd2FybigiRmFpbGVkIHRvIGZl dGNoIGRyaXZlIGluZm8iKTsKLQkJcmV0dXJuIChlcnJubyk7CisJCXJldHVybiAoZXJyb3IpOwog CX0KIAogCWlmIChtcHRfZGVsZXRlX3BoeXNkaXNrKGZkLCBQaHlzRGlza051bSkgPCAwKSB7CisJ CWVycm9yID0gZXJybm87CiAJCXdhcm4oIkZhaWxlZCB0byBkZWxldGUgcGh5c2ljYWwgZGlzayBw YWdlIik7Ci0JCXJldHVybiAoZXJybm8pOworCQlyZXR1cm4gKGVycm9yKTsKIAl9CiAKLQltcHRf cmVzY2FuX2J1cyhpbmZvLT5QaHlzRGlza0J1cywgaW5mby0+UGh5c0Rpc2tJRCk7CisJZXJyb3Ig PSBtcHRfcmVzY2FuX2J1cyhpbmZvLT5QaHlzRGlza0J1cywgaW5mby0+UGh5c0Rpc2tJRCk7CisJ aWYgKGVycm9yKQorCQlyZXR1cm4gKGVycm9yKTsKIAlmcmVlKGluZm8pOwogCWNsb3NlKGZkKTsK IApAQCAtMTEyNiw3ICsxMTc1LDcgQEAKIHsKIAlDT05GSUdfUEFHRV9SQUlEX1ZPTF8wICp2b2w7 CiAJVTggVm9sdW1lQnVzLCBWb2x1bWVJRDsKLQlpbnQgZmQ7CisJaW50IGVycm9yLCBmZDsKIAog CWlmIChhYyAhPSAyKSB7CiAJCXdhcm54KCJkZWJ1Zzogdm9sdW1lIHJlcXVpcmVkIik7CkBAIC0x MTM1LDE5ICsxMTg0LDIzIEBACiAKIAlmZCA9IG1wdF9vcGVuKG1wdF91bml0KTsKIAlpZiAoZmQg PCAwKSB7CisJCWVycm9yID0gZXJybm87CiAJCXdhcm4oIm1wdF9vcGVuIik7Ci0JCXJldHVybiAo ZXJybm8pOworCQlyZXR1cm4gKGVycm9yKTsKIAl9CiAKLQlpZiAobXB0X2xvb2t1cF92b2x1bWUo ZmQsIGF2WzFdLCAmVm9sdW1lQnVzLCAmVm9sdW1lSUQpIDwgMCkgeworCWVycm9yID0gbXB0X2xv b2t1cF92b2x1bWUoZmQsIGF2WzFdLCAmVm9sdW1lQnVzLCAmVm9sdW1lSUQpOworCWlmIChlcnJv cikgeworCQllcnJubyA9IGVycm9yOwogCQl3YXJuKCJJbnZhbGlkIHZvbHVtZTogJXMiLCBhdlsx XSk7Ci0JCXJldHVybiAoZXJybm8pOworCQlyZXR1cm4gKGVycm9yKTsKIAl9CiAKIAl2b2wgPSBt cHRfdm9sX2luZm8oZmQsIFZvbHVtZUJ1cywgVm9sdW1lSUQsIE5VTEwpOwogCWlmICh2b2wgPT0g TlVMTCkgeworCQllcnJvciA9IGVycm5vOwogCQl3YXJuKCJGYWlsZWQgdG8gZ2V0IHZvbHVtZSBp bmZvIik7Ci0JCXJldHVybiAoZXJybm8pOworCQlyZXR1cm4gKGVycm9yKTsKIAl9CiAKIAlkdW1w X2NvbmZpZyh2b2wpOwpJbmRleDogdXNyLnNiaW4vbXB0dXRpbC9tcHRfdm9sdW1lLmMKPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQotLS0gdXNyLnNiaW4vbXB0dXRpbC9tcHRfdm9sdW1lLmMJKHJldmlzaW9uIDIxNDU2OCkK KysrIHVzci5zYmluL21wdHV0aWwvbXB0X3ZvbHVtZS5jCSh3b3JraW5nIGNvcHkpCkBAIC00Nyw3 ICs0Nyw2IEBACiBjb25zdCBjaGFyICoKIG1wdF92b2xzdGF0ZShVOCBTdGF0ZSkKIHsKLQlzdGF0 aWMgY2hhciBidWZbMTZdOwogCiAJc3dpdGNoIChTdGF0ZSkgewogCWNhc2UgTVBJX1JBSURWT0ww X1NUQVRVU19TVEFURV9PUFRJTUFMOgpAQCAtNTgsMTAgKzU3LDEyIEBACiAJCXJldHVybiAoIkZB SUxFRCIpOwogCWNhc2UgTVBJX1JBSURWT0wwX1NUQVRVU19TVEFURV9NSVNTSU5HOgogCQlyZXR1 cm4gKCJNSVNTSU5HIik7Ci0JZGVmYXVsdDoKKwlkZWZhdWx0OiB7CisJCXN0YXRpYyBjaGFyIGJ1 ZiBbMTJdOwogCQlzcHJpbnRmKGJ1ZiwgIlZTVEFURSAweCUwMngiLCBTdGF0ZSk7CiAJCXJldHVy biAoYnVmKTsKIAl9CisJfQogfQogCiBzdGF0aWMgaW50CkBAIC02OSw3ICs3MCw3IEBACiB7CiAJ Q09ORklHX1BBR0VfUkFJRF9WT0xfMSAqdm5hbWVzOwogCVU4IFZvbHVtZUJ1cywgVm9sdW1lSUQ7 Ci0JaW50IGZkOworCWludCBlcnJvciwgZmQ7CiAKIAlpZiAoYWMgIT0gMykgewogCQl3YXJueCgi bmFtZTogdm9sdW1lIGFuZCBuYW1lIHJlcXVpcmVkIik7CkBAIC04MywxOSArODQsMjMgQEAKIAog CWZkID0gbXB0X29wZW4obXB0X3VuaXQpOwogCWlmIChmZCA8IDApIHsKKwkJZXJyb3IgPSBlcnJu bzsKIAkJd2FybigibXB0X29wZW4iKTsKLQkJcmV0dXJuIChlcnJubyk7CisJCXJldHVybiAoZXJy b3IpOwogCX0KIAotCWlmIChtcHRfbG9va3VwX3ZvbHVtZShmZCwgYXZbMV0sICZWb2x1bWVCdXMs ICZWb2x1bWVJRCkgPCAwKSB7CisJZXJyb3IgPSBtcHRfbG9va3VwX3ZvbHVtZShmZCwgYXZbMV0s ICZWb2x1bWVCdXMsICZWb2x1bWVJRCk7CisJaWYgKGVycm9yKSB7CisJCWVycm5vID0gZXJyb3I7 CiAJCXdhcm4oIkludmFsaWQgdm9sdW1lOiAlcyIsIGF2WzFdKTsKLQkJcmV0dXJuIChlcnJubyk7 CisJCXJldHVybiAoZXJyb3IpOwogCX0KIAogCXZuYW1lcyA9IG1wdF92b2xfbmFtZXMoZmQsIFZv bHVtZUJ1cywgVm9sdW1lSUQsIE5VTEwpOwogCWlmICh2bmFtZXMgPT0gTlVMTCkgeworCQllcnJv ciA9IGVycm5vOwogCQl3YXJuKCJGYWlsZWQgdG8gZmV0Y2ggdm9sdW1lIG5hbWVzIik7Ci0JCXJl dHVybiAoZXJybm8pOworCQlyZXR1cm4gKGVycm9yKTsKIAl9CiAKIAlpZiAodm5hbWVzLT5IZWFk ZXIuUGFnZVR5cGUgIT0gTVBJX0NPTkZJR19QQUdFQVRUUl9DSEFOR0VBQkxFKSB7CkBAIC0xMDks OCArMTE0LDkgQEAKIAlzdHJjcHkodm5hbWVzLT5OYW1lLCBhdlsyXSk7CiAKIAlpZiAobXB0X3dy aXRlX2NvbmZpZ19wYWdlKGZkLCB2bmFtZXMsIE5VTEwpIDwgMCkgeworCQllcnJvciA9IGVycm5v OwogCQl3YXJuKCJGYWlsZWQgdG8gc2V0IHZvbHVtZSBuYW1lIik7Ci0JCXJldHVybiAoZXJybm8p OworCQlyZXR1cm4gKGVycm9yKTsKIAl9CiAKIAlmcmVlKHZuYW1lcyk7CkBAIC0xMjgsNyArMTM0 LDcgQEAKIAl1aW50NjRfdCB0b3RhbCwgcmVtYWluaW5nOwogCWZsb2F0IHBjdDsKIAlVOCBWb2x1 bWVCdXMsIFZvbHVtZUlEOwotCWludCBmZDsKKwlpbnQgZXJyb3IsIGZkOwogCiAJaWYgKGFjICE9 IDIpIHsKIAkJd2FybngoInZvbHVtZSBzdGF0dXM6ICVzIiwgYWMgPiAyID8gImV4dHJhIGFyZ3Vt ZW50cyIgOgpAQCAtMTM4LDIwICsxNDQsMjUgQEAKIAogCWZkID0gbXB0X29wZW4obXB0X3VuaXQp OwogCWlmIChmZCA8IDApIHsKKwkJZXJyb3IgPSBlcnJubzsKIAkJd2FybigibXB0X29wZW4iKTsK LQkJcmV0dXJuIChlcnJubyk7CisJCXJldHVybiAoZXJyb3IpOwogCX0KIAotCWlmIChtcHRfbG9v a3VwX3ZvbHVtZShmZCwgYXZbMV0sICZWb2x1bWVCdXMsICZWb2x1bWVJRCkgPCAwKSB7CisJZXJy b3IgPSBtcHRfbG9va3VwX3ZvbHVtZShmZCwgYXZbMV0sICZWb2x1bWVCdXMsICZWb2x1bWVJRCk7 CisJaWYgKGVycm9yKSB7CisJCWVycm5vID0gZXJyb3I7CiAJCXdhcm4oIkludmFsaWQgdm9sdW1l OiAlcyIsIGF2WzFdKTsKLQkJcmV0dXJuIChlcnJubyk7CisJCXJldHVybiAoZXJyb3IpOwogCX0K IAotCWlmIChtcHRfcmFpZF9hY3Rpb24oZmQsIE1QSV9SQUlEX0FDVElPTl9JTkRJQ0FUT1JfU1RS VUNULCBWb2x1bWVCdXMsCisJZXJyb3IgPSBtcHRfcmFpZF9hY3Rpb24oZmQsIE1QSV9SQUlEX0FD VElPTl9JTkRJQ0FUT1JfU1RSVUNULCBWb2x1bWVCdXMsCiAJICAgIFZvbHVtZUlELCAwLCAwLCBO VUxMLCAwLCAmVm9sdW1lU3RhdHVzLCAoVTMyICopJnByb2csIHNpemVvZihwcm9nKSwKLQkgICAg TlVMTCwgTlVMTCwgMCkgPCAwKSB7CisJICAgIE5VTEwsIE5VTEwsIDApOworCWlmIChlcnJvcikg eworCQllcnJubyA9IGVycm9yOwogCQl3YXJuKCJGZXRjaGluZyB2b2x1bWUgc3RhdHVzIGZhaWxl ZCIpOwotCQlyZXR1cm4gKGVycm5vKTsKKwkJcmV0dXJuIChlcnJvcik7CiAJfQogCiAJcHJpbnRm KCJWb2x1bWUgJXMgc3RhdHVzOlxuIiwgbXB0X3ZvbHVtZV9uYW1lKFZvbHVtZUJ1cywgVm9sdW1l SUQpKTsKQEAgLTE5MSwxMSArMjAyLDExIEBACiAJVTMyIFNldHRpbmdzLCBOZXdTZXR0aW5nczsK IAlVOCBWb2x1bWVCdXMsIFZvbHVtZUlEOwogCWNoYXIgKnMxOwotCWludCBmZDsKKwlpbnQgZXJy b3IsIGZkOwogCiAJaWYgKGFjICE9IDMpIHsKIAkJd2FybngoInZvbHVtZSBjYWNoZTogJXMiLCBh YyA+IDMgPyAiZXh0cmEgYXJndW1lbnRzIiA6Ci0JCSAgICAidm9sdW1lIHJlcXVpcmVkIik7CisJ CSAgICAibWlzc2luZyBhcmd1bWVudHMiKTsKIAkJcmV0dXJuIChFSU5WQUwpOwogCX0KIApAQCAt MjA5LDE4ICsyMjAsMjEgQEAKIAogCWZkID0gbXB0X29wZW4obXB0X3VuaXQpOwogCWlmIChmZCA8 IDApIHsKKwkJZXJyb3IgPSBlcnJubzsKIAkJd2FybigibXB0X29wZW4iKTsKLQkJcmV0dXJuIChl cnJubyk7CisJCXJldHVybiAoZXJyb3IpOwogCX0KIAotCWlmIChtcHRfbG9va3VwX3ZvbHVtZShm ZCwgYXZbMV0sICZWb2x1bWVCdXMsICZWb2x1bWVJRCkgPCAwKSB7CisJZXJyb3IgPSBtcHRfbG9v a3VwX3ZvbHVtZShmZCwgYXZbMV0sICZWb2x1bWVCdXMsICZWb2x1bWVJRCk7CisJaWYgKGVycm9y KSB7CisJCWVycm5vID0gZXJyb3I7CiAJCXdhcm4oIkludmFsaWQgdm9sdW1lOiAlcyIsIGF2WzFd KTsKLQkJcmV0dXJuIChlcnJubyk7CisJCXJldHVybiAoZXJyb3IpOwogCX0KIAogCXZvbHVtZSA9 IG1wdF92b2xfaW5mbyhmZCwgVm9sdW1lQnVzLCBWb2x1bWVJRCwgTlVMTCk7CiAJaWYgKHZvbHVt ZSA9PSBOVUxMKQotCQlyZXR1cm4gKC0xKTsKKwkJcmV0dXJuIChlcnJubyk7CiAKIAlTZXR0aW5n cyA9IHZvbHVtZS0+Vm9sdW1lU2V0dGluZ3MuU2V0dGluZ3M7CiAKQEAgLTIzMSwxOCArMjQ1LDE5 IEBACiAJCU5ld1NldHRpbmdzICY9IH4weDAxOwogCiAJaWYgKE5ld1NldHRpbmdzID09IFNldHRp bmdzKSB7Ci0JCXdhcm54KCJ2b2x1bWUgY2FjaGUgdW5jaGFuZ2VkXG4iKTsKKwkJd2FybngoInZv bHVtZSBjYWNoZSB1bmNoYW5nZWQiKTsKIAkJY2xvc2UoZmQpOwogCQlyZXR1cm4gKDApOwogCX0K IAogCXZvbHVtZS0+Vm9sdW1lU2V0dGluZ3MuU2V0dGluZ3MgPSBOZXdTZXR0aW5nczsKLQlpZiAo bXB0X3JhaWRfYWN0aW9uKGZkLCBNUElfUkFJRF9BQ1RJT05fQ0hBTkdFX1ZPTFVNRV9TRVRUSU5H UywKKwllcnJvciA9IG1wdF9yYWlkX2FjdGlvbihmZCwgTVBJX1JBSURfQUNUSU9OX0NIQU5HRV9W T0xVTUVfU0VUVElOR1MsCiAJICAgIFZvbHVtZUJ1cywgVm9sdW1lSUQsIDAsICooVTMyICopJnZv bHVtZS0+Vm9sdW1lU2V0dGluZ3MsIE5VTEwsIDAsCi0JICAgIE5VTEwsIE5VTEwsIDAsIE5VTEws IE5VTEwsIDApIDwgMCkKLQkJd2FybngoInZvbHVtZSBjYWNoZSBjaGFuZ2UgZmFpbGVkLCBlcnJu bz0gJWRcbiIsIGVycm5vKTsKKwkgICAgTlVMTCwgTlVMTCwgMCwgTlVMTCwgTlVMTCwgMCk7CisJ aWYgKGVycm9yKQorCQl3YXJuKCJ2b2x1bWUgY2FjaGUgY2hhbmdlIGZhaWxlZCIpOwogCiAJY2xv c2UoZmQpOwotCXJldHVybiAoMCk7CisJcmV0dXJuIChlcnJvcik7CiB9CiBNUFRfQ09NTUFORCh2 b2x1bWUsIGNhY2hlLCB2b2x1bWVfY2FjaGUpOwpJbmRleDogdXNyLnNiaW4vbXB0dXRpbC9tcHRf ZHJpdmUuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09Ci0tLSB1c3Iuc2Jpbi9tcHR1dGlsL21wdF9kcml2ZS5jCShyZXZp c2lvbiAyMTQ1NjgpCisrKyB1c3Iuc2Jpbi9tcHR1dGlsL21wdF9kcml2ZS5jCSh3b3JraW5nIGNv cHkpCkBAIC01MSw3ICs1MSw2IEBACiBjb25zdCBjaGFyICoKIG1wdF9wZHN0YXRlKENPTkZJR19Q QUdFX1JBSURfUEhZU19ESVNLXzAgKmluZm8pCiB7Ci0Jc3RhdGljIGNoYXIgYnVmWzE2XTsKIAog CXN3aXRjaCAoaW5mby0+UGh5c0Rpc2tTdGF0dXMuU3RhdGUpIHsKIAljYXNlIE1QSV9QSFlTRElT SzBfU1RBVFVTX09OTElORToKQEAgLTc2LDkgKzc1LDEyIEBACiAJY2FzZSBNUElfUEhZU0RJU0sw X1NUQVRVU19PVEhFUl9PRkZMSU5FOgogCQlyZXR1cm4gKCJPVEhFUiBPRkZMSU5FIik7CiAJZGVm YXVsdDoKKwl7CisJCXN0YXRpYyBjaGFyIGJ1ZlsxMl07CiAJCXNwcmludGYoYnVmLCAiUFNUQVRF IDB4JTAyeCIsIGluZm8tPlBoeXNEaXNrU3RhdHVzLlN0YXRlKTsKIAkJcmV0dXJuIChidWYpOwog CX0KKwl9CiB9CiAKIC8qCkBAIC0xMjksNyArMTMxLDcgQEAKIAkJbGlzdC0+ZHJpdmVzW2ogKyAx XSA9IGxpc3QtPmRyaXZlc1tqXTsKIAlsaXN0LT5kcml2ZXNbaV0gPSBtcHRfcGRfaW5mbyhmZCwg UGh5c0Rpc2tOdW0sIE5VTEwpOwogCWlmIChsaXN0LT5kcml2ZXNbaV0gPT0gTlVMTCkKLQkJcmV0 dXJuICgtMSk7CisJCXJldHVybiAoZXJybm8pOwogCWxpc3QtPm5kcml2ZXMrKzsKIAlyZXR1cm4g KDApOwogfQpAQCAtMTQ2LDI2ICsxNDgsMzIgQEAKIAlDT05GSUdfUEFHRV9JT0NfNSAqaW9jNTsK IAlJT0NfNV9IT1RfU1BBUkUgKnNwYXJlOwogCXN0cnVjdCBtcHRfZHJpdmVfbGlzdCAqbGlzdDsK LQlpbnQgY291bnQsIGksIGo7CisJaW50IGNvdW50LCBlcnJvciwgaSwgajsKIAogCWlvYzIgPSBt cHRfcmVhZF9pb2NfcGFnZShmZCwgMiwgTlVMTCk7CiAJaWYgKGlvYzIgPT0gTlVMTCkgeworCQll cnJvciA9IGVycm5vOwogCQl3YXJuKCJGYWlsZWQgdG8gZmV0Y2ggdm9sdW1lIGxpc3QiKTsKKwkJ ZXJybm8gPSBlcnJvcjsKIAkJcmV0dXJuIChOVUxMKTsKIAl9CiAKIAlpb2MzID0gbXB0X3JlYWRf aW9jX3BhZ2UoZmQsIDMsIE5VTEwpOwogCWlmIChpb2MzID09IE5VTEwpIHsKKwkJZXJyb3IgPSBl cnJubzsKIAkJd2FybigiRmFpbGVkIHRvIGZldGNoIGRyaXZlIGxpc3QiKTsKIAkJZnJlZShpb2My KTsKKwkJZXJybm8gPSBlcnJvcjsKIAkJcmV0dXJuIChOVUxMKTsKIAl9CiAKIAlpb2M1ID0gbXB0 X3JlYWRfaW9jX3BhZ2UoZmQsIDUsIE5VTEwpOwogCWlmIChpb2M1ID09IE5VTEwpIHsKKwkJZXJy b3IgPSBlcnJubzsKIAkJd2FybigiRmFpbGVkIHRvIGZldGNoIHNwYXJlIGxpc3QiKTsKIAkJZnJl ZShpb2MzKTsKIAkJZnJlZShpb2MyKTsKKwkJZXJybm8gPSBlcnJvcjsKIAkJcmV0dXJuIChOVUxM KTsKIAl9CiAKQEAgLTE4MCw3ICsxODgsOSBAQAogCQl2b2x1bWVzW2ldID0gbXB0X3ZvbF9pbmZv KGZkLCB2b2wtPlZvbHVtZUJ1cywgdm9sLT5Wb2x1bWVJRCwKIAkJICAgIE5VTEwpOwogCQlpZiAo dm9sdW1lc1tpXSA9PSBOVUxMKSB7CisJCQllcnJvciA9IGVycm5vOwogCQkJd2FybigiRmFpbGVk IHRvIHJlYWQgdm9sdW1lIGluZm8iKTsKKwkJCWVycm5vID0gZXJyb3I7CiAJCQlyZXR1cm4gKE5V TEwpOwogCQl9CiAJCWNvdW50ICs9IHZvbHVtZXNbaV0tPk51bVBoeXNEaXNrczsKQEAgLTI2NCwx MyArMjc0LDExIEBACiAJCQkJcmV0dXJuICgwKTsKIAkJCX0KIAkJfQotCQllcnJubyA9IEVOT0VO VDsKLQkJcmV0dXJuICgtMSk7CisJCXJldHVybiAoRU5PRU5UKTsKIAl9CiAKIGJhZDoKLQllcnJu byA9IEVJTlZBTDsKLQlyZXR1cm4gKC0xKTsKKwlyZXR1cm4gKEVJTlZBTCk7CiB9CiAKIC8qIEJv cnJvd2VkIGhlYXZpbHkgZnJvbSBzY3NpX2FsbC5jOnNjc2lfcHJpbnRfaW5xdWlyeSgpLiAqLwpA QCAtMzA2LDEyICszMTQsMTMgQEAKIAlDT05GSUdfUEFHRV9SQUlEX1BIWVNfRElTS18wICppbmZv OwogCXN0cnVjdCBtcHRfZHJpdmVfbGlzdCAqbGlzdDsKIAlVOCBQaHlzRGlza051bTsKLQlpbnQg ZmQ7CisJaW50IGVycm9yLCBmZDsKIAogCWZkID0gbXB0X29wZW4obXB0X3VuaXQpOwogCWlmIChm ZCA8IDApIHsKKwkJZXJyb3IgPSBlcnJubzsKIAkJd2FybigibXB0X29wZW4iKTsKLQkJcmV0dXJu IChlcnJubyk7CisJCXJldHVybiAoZXJyb3IpOwogCX0KIAogCWxpc3QgPSBtcHRfcGRfbGlzdChm ZCk7CkBAIC0zMTksMTYgKzMyOCwxOCBAQAogCQlyZXR1cm4gKGVycm5vKTsKIAogCWlmIChtcHRf bG9va3VwX2RyaXZlKGxpc3QsIGRyaXZlLCAmUGh5c0Rpc2tOdW0pIDwgMCkgeworCQllcnJvciA9 IGVycm5vOwogCQl3YXJuKCJGYWlsZWQgdG8gZmluZCBkcml2ZSAlcyIsIGRyaXZlKTsKLQkJcmV0 dXJuIChlcnJubyk7CisJCXJldHVybiAoZXJyb3IpOwogCX0KIAltcHRfZnJlZV9wZF9saXN0KGxp c3QpOwogCiAJLyogR2V0IHRoZSBpbmZvIGZvciB0aGlzIGRyaXZlLiAqLwogCWluZm8gPSBtcHRf cGRfaW5mbyhmZCwgUGh5c0Rpc2tOdW0sIE5VTEwpOwogCWlmIChpbmZvID09IE5VTEwpIHsKKwkJ ZXJyb3IgPSBlcnJubzsKIAkJd2FybigiRmFpbGVkIHRvIGZldGNoIGluZm8gZm9yIGRyaXZlICV1 IiwgUGh5c0Rpc2tOdW0pOwotCQlyZXR1cm4gKGVycm5vKTsKKwkJcmV0dXJuIChlcnJvcik7CiAJ fQogCiAJLyogVHJ5IHRvIGNoYW5nZSB0aGUgc3RhdGUuICovCkBAIC0zMzcsMTAgKzM0OCwxMiBA QAogCQlyZXR1cm4gKEVJTlZBTCk7CiAJfQogCi0JaWYgKG1wdF9yYWlkX2FjdGlvbihmZCwgQWN0 aW9uLCAwLCAwLCBQaHlzRGlza051bSwgMCwgTlVMTCwgMCwgTlVMTCwKLQkgICAgTlVMTCwgMCwg TlVMTCwgTlVMTCwgMCkgPCAwKSB7CisJZXJyb3IgPSBtcHRfcmFpZF9hY3Rpb24oZmQsIEFjdGlv biwgMCwgMCwgUGh5c0Rpc2tOdW0sIDAsIE5VTEwsIDAsIE5VTEwsCisJICAgIE5VTEwsIDAsIE5V TEwsIE5VTEwsIDApOworCWlmIChlcnJvcikgeworCQllcnJubyA9IGVycm9yOwogCQl3YXJuKCJG YWlsZWQgdG8gc2V0IGRyaXZlICV1IHRvICVzIiwgUGh5c0Rpc2tOdW0sIG5hbWUpOwotCQlyZXR1 cm4gKGVycm5vKTsKKwkJcmV0dXJuIChlcnJvcik7CiAJfQogCiAJZnJlZShpbmZvKTsK --0016e6567d28fde28604945df687-- From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 6 10:33:00 2010 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 81C17106566B for ; Sat, 6 Nov 2010 10:33:00 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3BBE98FC18 for ; Sat, 6 Nov 2010 10:32:59 +0000 (UTC) Received: by iwn39 with SMTP id 39so3863928iwn.13 for ; Sat, 06 Nov 2010 03:32:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=kjF8V3dEieGz4w6415WTZ/14184CgIuyB38kgmxHFz8=; b=Cr+o4ytltlbLI8rsS1mdec9GgJ2phoks2G9uJs5i0RssHV5BqMFV6bx9BctOfXt7Oq a64lRgi8gKZhiqJ/EEylQQebMOcQ+JFVLEjSNRgVFAqc9o8KhKDHoUheCLsW0tX9fr5X Q10uzQeOhp9APG4XNO9bOzcKhttexF8ITHAbw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=ZR4xwLuX4oCcnLhRjjuUC/H8WejYr3H6I4zBHGcoirNaYTUo3F50c2hLc8p5SZpuY+ t7cxFZOwWrQA91jOlyMjnhUL0IWClmod0V47t+/oTWT//Z5e6Q1dF96bfywzvGSmwCnu 2Uli4F62trEOfmMy3ZB2xanfo/6emLmnTm5p8= MIME-Version: 1.0 Received: by 10.42.21.17 with SMTP id i17mr2255312icb.263.1289039579641; Sat, 06 Nov 2010 03:32:59 -0700 (PDT) Sender: baptiste.daroussin@gmail.com Received: by 10.231.69.212 with HTTP; Sat, 6 Nov 2010 03:32:59 -0700 (PDT) In-Reply-To: <86y696q5bm.fsf@gmail.com> References: <861v6zwo9j.fsf@gmail.com> <868w17v3b6.fsf@gmail.com> <86y696q5bm.fsf@gmail.com> Date: Sat, 6 Nov 2010 10:32:59 +0000 X-Google-Sender-Auth: QHYHiddNH2SsfwowoI9Lzb7zs5s Message-ID: From: Baptiste Daroussin To: Anonymous Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: [PATCH] update to the latest libedit version and remove libreadline deps 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, 06 Nov 2010 10:33:00 -0000 Thanks all for your returns, I'll update my patch during the next week. Concerning the reverts I'll try to reintegrate them and then send them to upstream, Because I think it is better to keep in sync to easier futures updates. regards, Bapt From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 6 16:24:25 2010 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 71EA8106566B for ; Sat, 6 Nov 2010 16:24:25 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from mail.icecube.wisc.edu (trout.icecube.wisc.edu [128.104.255.119]) by mx1.freebsd.org (Postfix) with ESMTP id 16F978FC0A for ; Sat, 6 Nov 2010 16:24:24 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 0435458E31; Sat, 6 Nov 2010 11:24:24 -0500 (CDT) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from mail.icecube.wisc.edu ([127.0.0.1]) by localhost (trout.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id qUIC+MqzJ30H; Sat, 6 Nov 2010 11:24:23 -0500 (CDT) Received: from wanderer.tachypleus.net (unknown [76.210.66.181]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 806AD58E2E; Sat, 6 Nov 2010 11:24:23 -0500 (CDT) Message-ID: <4CD58136.6070509@freebsd.org> Date: Sat, 06 Nov 2010 11:24:22 -0500 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.12) Gecko/20100925 Thunderbird/3.0.8 MIME-Version: 1.0 To: Garrett Cooper References: <201011052316.27839.jpaetzel@freebsd.org> <20101105.230617.74669306.imp@bsdimp.com> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: jpaetzel@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: txt-sysinstall scrapped 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, 06 Nov 2010 16:24:25 -0000 On 11/06/10 01:04, Garrett Cooper wrote: > On Fri, Nov 5, 2010 at 10:06 PM, Warner Losh wrote: >>> Just to add to that (because I do find it a novel idea), 1) how >>> are you going to properly prevent man in the middle attacks (SSL, TLS, >>> etc?), and 2) what webserver would you use? >> >> https or ssh. >> >> We're also toying with the idea of having a partition that you could >> 'dd' your certs and keys to (so any system can customize the image >> with keys to make sure you were talking to who you think you are). >> We'd just reserve 1MB of space on partition s3. We'd then check to >> see if there was a tar ball. If so, we'd extract it and do the >> intelligent thing with the keys we find there. > > Wouldn't it be better just to go with a read-write media solution > (USB) like Matt Dillon was suggesting at today then? Then again, > determining the root device to date is still a bit kludgy isn't it? But this breaks badly for people who don't own USB sticks of sufficient size, are installing on machines without USB ports, can't boot from USB, want to install from a shared medium like PXE, are installing on blades with convenient shared CD drives but not USB etc. etc. Everything in the world can boot from CD, and we have to ensure that continues working. I also have mixed feelings about needing to use a web browser to instruct a web app inside a bundled web server to write a config file to be interpreted by shell scripts just in order to run gpart, newfs, and tar. But if you get it working, it's better than sysinstall no matter how baroque. -Nathan From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 6 17:36:22 2010 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 1A2A91065693 for ; Sat, 6 Nov 2010 17:36:22 +0000 (UTC) (envelope-from emaste@freebsd.org) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by mx1.freebsd.org (Postfix) with ESMTP id C9E1B8FC14 for ; Sat, 6 Nov 2010 17:36:21 +0000 (UTC) Received: from labgw2.phaedrus.sandvine.com (192.168.222.22) by WTL-EXCH-1.sandvine.com (192.168.196.31) with Microsoft SMTP Server id 14.0.694.0; Sat, 6 Nov 2010 13:36:20 -0400 Received: by labgw2.phaedrus.sandvine.com (Postfix, from userid 10332) id AF98633C00; Sat, 6 Nov 2010 13:36:20 -0400 (EDT) Date: Sat, 6 Nov 2010 13:36:20 -0400 From: Ed Maste To: Gleb Kurtsou Message-ID: <20101106173620.GA45793@sandvine.com> References: <20101105191443.GD1437@mark-laptop-bsd.mark-home> <20101105204519.GA2843@tops> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20101105204519.GA2843@tops> User-Agent: Mutt/1.4.2.1i Cc: freebsd-hackers@freebsd.org, Mark Johnston Subject: Re: Userland debug symbols directory 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, 06 Nov 2010 17:36:22 -0000 On Fri, Nov 05, 2010 at 10:45:19PM +0200, Gleb Kurtsou wrote: > I like the idea a lot, but why not to leave symbol files in /usr/obj, The application where this is most useful (and why we implemented it originally) is the case where /usr/obj isn't available - for instance, a binary installation other than where the source tree was built. If you're going to keep /usr/obj around anyway then you can get most of the benefit by just keeping the unstripped binaries / libs in there, no? -Ed From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 6 17:56:09 2010 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 B6015106566B for ; Sat, 6 Nov 2010 17:56:09 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 2D7588FC14 for ; Sat, 6 Nov 2010 17:56:08 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id oA6Hu4Q8018564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Nov 2010 19:56:04 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id oA6Hu3FR073497; Sat, 6 Nov 2010 19:56:03 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id oA6Hu3EG073496; Sat, 6 Nov 2010 19:56:03 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 6 Nov 2010 19:56:03 +0200 From: Kostik Belousov To: Ed Maste Message-ID: <20101106175603.GL2392@deviant.kiev.zoral.com.ua> References: <20101105191443.GD1437@mark-laptop-bsd.mark-home> <20101105204519.GA2843@tops> <20101106173620.GA45793@sandvine.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VD/LOZLa8Ox1/mf9" Content-Disposition: inline In-Reply-To: <20101106173620.GA45793@sandvine.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-hackers@freebsd.org, Gleb Kurtsou , Mark Johnston Subject: Re: Userland debug symbols directory 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, 06 Nov 2010 17:56:09 -0000 --VD/LOZLa8Ox1/mf9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Nov 06, 2010 at 01:36:20PM -0400, Ed Maste wrote: > On Fri, Nov 05, 2010 at 10:45:19PM +0200, Gleb Kurtsou wrote: >=20 > > I like the idea a lot, but why not to leave symbol files in /usr/obj, >=20 > The application where this is most useful (and why we implemented it > originally) is the case where /usr/obj isn't available - for instance, > a binary installation other than where the source tree was built. If > you're going to keep /usr/obj around anyway then you can get most of > the benefit by just keeping the unstripped binaries / libs in there, > no? Not that easy, since you have to arrange to use libraries from obj/, by LD_LIBRARY_PATH etc. I fully support the work to install symbol files, and it should go into /usr, might be /usr/lib/debug. Possibly, some change to gdb (config) is required. --VD/LOZLa8Ox1/mf9 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAkzVlrMACgkQC3+MBN1Mb4gG/gCgtmLvVgGVDvNMt17kjb0tjQYZ m28AoJWQALYTXLMDO/6cjyam052H4tlO =XmB5 -----END PGP SIGNATURE----- --VD/LOZLa8Ox1/mf9-- From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 6 18:04:22 2010 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 4A3EB106566B for ; Sat, 6 Nov 2010 18:04:22 +0000 (UTC) (envelope-from emaste@freebsd.org) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by mx1.freebsd.org (Postfix) with ESMTP id 0348A8FC08 for ; Sat, 6 Nov 2010 18:04:21 +0000 (UTC) Received: from labgw2.phaedrus.sandvine.com (192.168.222.22) by WTL-EXCH-1.sandvine.com (192.168.196.31) with Microsoft SMTP Server id 14.0.694.0; Sat, 6 Nov 2010 14:04:21 -0400 Received: by labgw2.phaedrus.sandvine.com (Postfix, from userid 10332) id D3F3133C00; Sat, 6 Nov 2010 14:04:20 -0400 (EDT) Date: Sat, 6 Nov 2010 14:04:20 -0400 From: Ed Maste To: Kostik Belousov Message-ID: <20101106180420.GA50159@sandvine.com> References: <20101105191443.GD1437@mark-laptop-bsd.mark-home> <20101105204519.GA2843@tops> <20101106173620.GA45793@sandvine.com> <20101106175603.GL2392@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20101106175603.GL2392@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.1i Cc: freebsd-hackers@freebsd.org, Gleb Kurtsou , Johnston , Mark Subject: Re: Userland debug symbols directory 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, 06 Nov 2010 18:04:22 -0000 On Sat, Nov 06, 2010 at 07:56:03PM +0200, Kostik Belousov wrote: > On Sat, Nov 06, 2010 at 01:36:20PM -0400, Ed Maste wrote: > > On Fri, Nov 05, 2010 at 10:45:19PM +0200, Gleb Kurtsou wrote: > > > > > I like the idea a lot, but why not to leave symbol files in /usr/obj, > > > > The application where this is most useful (and why we implemented it > > originally) is the case where /usr/obj isn't available - for instance, > > a binary installation other than where the source tree was built. If > > you're going to keep /usr/obj around anyway then you can get most of > > the benefit by just keeping the unstripped binaries / libs in there, > > no? > Not that easy, since you have to arrange to use libraries from obj/, > by LD_LIBRARY_PATH etc. > > I fully support the work to install symbol files, and it should go > into /usr, might be /usr/lib/debug. Possibly, some change to gdb (config) > is required. Yeah, I just mean that using LD_LIBRARY_PATH or whatever is still a lot easier than realizing you don't have the debug info at all, and trying to rebuild an identical binary or library with debug. I definitely want the changes to build and install the symbol files in the FreeBSD tree. I don't have a huge concern over the exact path we pick. -Ed From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 6 18:22:55 2010 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 7B2281065670 for ; Sat, 6 Nov 2010 18:22:55 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0FD978FC19 for ; Sat, 6 Nov 2010 18:22:54 +0000 (UTC) Received: by wyb34 with SMTP id 34so2118060wyb.13 for ; Sat, 06 Nov 2010 11:22:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=r6fCTfoEPwOS/rcztMzL3NKIHUbcBrlWu3hgr+hM7Lw=; b=fl9ug253Y8Tugy+ihSemWDFMBxLdKqSZ6VW4BDYYKMggFaQULIgd+DDdxo4yvwRl4p N5+WHpRiKqVGLczh42vYl8/dp9InXCRD1CHMrN4XE1xBo9MH4Xk6k5Uo+5wrLJiXSzWT 98xZMQFEQ+twf2gl0jgdnHx0wX/SJ52yVAuug= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=NrtfWk7Q9tBAxza+Pm6tllufLnsulfhStVMXh4Dp1z7roi8vv8xL5w6wJnoEh+ezCy X6qFemVSBLXOiT4iN3SObDSgkUamRvHaa7buzVeIuRn2jt69hk2TzdIDgg7ZoHkMugFI yIpgdy+Vl4ONH/0qWiDthk+o/J8MyGyeZc0UY= MIME-Version: 1.0 Received: by 10.216.7.210 with SMTP id 60mr2551760wep.30.1289067773562; Sat, 06 Nov 2010 11:22:53 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.216.198.27 with HTTP; Sat, 6 Nov 2010 11:22:53 -0700 (PDT) Date: Sat, 6 Nov 2010 11:22:53 -0700 X-Google-Sender-Auth: wolnXNXqWnQI59fkYUsWgEdAS5I Message-ID: From: Garrett Cooper To: hackers@freebsd.org Content-Type: multipart/mixed; boundary=0016364c7576bc10170494667abf Cc: Subject: [PATCH] Simplify uart_bus_pci_probe 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, 06 Nov 2010 18:22:55 -0000 --0016364c7576bc10170494667abf Content-Type: text/plain; charset=ISO-8859-1 Some of the logic could have been simplified in the probe. The proposed patch makes the detection process a tad bit more straightforward. Comments, review (and maybe a commit :P) are more than welcome :). Thanks! -Garrett --0016364c7576bc10170494667abf Content-Type: application/octet-stream; name="uart-bus-probe-minor-cleanup.patch" Content-Disposition: attachment; filename="uart-bus-probe-minor-cleanup.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gg6tkewo0 SW5kZXg6IHN5cy9kZXYvdWFydC91YXJ0X2J1c19wY2kuYwo9PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvZGV2 L3VhcnQvdWFydF9idXNfcGNpLmMJKHJldmlzaW9uIDIxNDg1NykKKysrIHN5cy9kZXYvdWFydC91 YXJ0X2J1c19wY2kuYwkod29ya2luZyBjb3B5KQpAQCAtMTUwLDE0ICsxNTAsMTMgQEAKIAlzYyA9 IGRldmljZV9nZXRfc29mdGMoZGV2KTsKIAogCWlkID0gdWFydF9wY2lfbWF0Y2goZGV2LCBwY2lf bnM4MjUwX2lkcyk7Ci0JaWYgKGlkICE9IE5VTEwpIHsKLQkJc2MtPnNjX2NsYXNzID0gJnVhcnRf bnM4MjUwX2NsYXNzOwotCQlnb3RvIG1hdGNoOworCWlmIChpZCA9PSBOVUxMKSB7CisJCS8qIEFk ZCBjaGVja3MgZm9yIG5vbi1uczgyNTAgSURzIGhlcmUuICovCisJCXJldHVybiAoRU5YSU8pOwog CX0KLQkvKiBBZGQgY2hlY2tzIGZvciBub24tbnM4MjUwIElEcyBoZXJlLiAqLwotCXJldHVybiAo RU5YSU8pOwogCi0gbWF0Y2g6CisJc2MtPnNjX2NsYXNzID0gJnVhcnRfbnM4MjUwX2NsYXNzOwor CiAJaWYgKGlkLT5kZXNjKQogCQlkZXZpY2Vfc2V0X2Rlc2MoZGV2LCBpZC0+ZGVzYyk7CiAJcmV0 dXJuICh1YXJ0X2J1c19wcm9iZShkZXYsIDAsIGlkLT5yY2xrLCBpZC0+cmlkLCAwKSk7Cg== --0016364c7576bc10170494667abf-- From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 6 19:17:03 2010 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 322B0106566B; Sat, 6 Nov 2010 19:17:03 +0000 (UTC) (envelope-from gljennjohn@googlemail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 81EE28FC12; Sat, 6 Nov 2010 19:17:02 +0000 (UTC) Received: by bwz3 with SMTP id 3so3677899bwz.13 for ; Sat, 06 Nov 2010 12:17:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:reply-to:x-mailer:mime-version :content-type:content-transfer-encoding; bh=2KWlA0RJav0X5DNL0VvgGj9sP/Pkov1p0AxaNvgZPug=; b=OcOROr4zekxwZXFb3YLq26+3sQw7ocuisAbOdFc3kifhRiB2qDp2d+r+FSUiOnGw8p cB/zN9weUVnx4MxW2YWqw3V5RXHXoEYEXcsv2WOW0zmQV5uY/YZhE1PFpssRxgdvl8pq vYifals20aKRdrlnTtreQuqMOEbvbnziakABg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :x-mailer:mime-version:content-type:content-transfer-encoding; b=kg0o8o/psFbEpSlPbmWS5GlupcIjl7ripfM3t4xra0vwGbPRdJXR0UbcfR8/0x1Oju xFeZ1lOAbF/ioJuYk+pOz8mUjtkWGTi6Mlg2sphJmr5h0tDmqai49gCwpSJtAneksjN3 bOcvqriY6E6bVBpl9UbI8rCNNkpmc+U3jIR5I= Received: by 10.204.117.204 with SMTP id s12mr778546bkq.60.1289069623801; Sat, 06 Nov 2010 11:53:43 -0700 (PDT) Received: from ernst.jennejohn.org (p578E3053.dip.t-dialin.net [87.142.48.83]) by mx.google.com with ESMTPS id 4sm2176086bki.1.2010.11.06.11.53.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 06 Nov 2010 11:53:42 -0700 (PDT) Date: Sat, 6 Nov 2010 19:53:40 +0100 From: Gary Jennejohn To: freebsd-hackers@freebsd.org Message-ID: <20101106195340.23caa136@ernst.jennejohn.org> In-Reply-To: References: X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.7; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Garrett Cooper Subject: Re: [PATCH] Simplify uart_bus_pci_probe X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gljennjohn@googlemail.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 19:17:03 -0000 On Sat, 6 Nov 2010 11:22:53 -0700 Garrett Cooper wrote: > Some of the logic could have been simplified in the probe. The > proposed patch makes the detection process a tad bit more > straightforward. > Comments, review (and maybe a commit :P) are more than welcome :). > Thanks! > -Garrett This is definitely much less convoluted and easier to understand than the old code! I'd commit it, if I still had my src commit bit :) -- Gary Jennejohn From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 6 19:47:12 2010 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 09914106566C; Sat, 6 Nov 2010 19:47:12 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 7C9F68FC13; Sat, 6 Nov 2010 19:47:10 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id oA6Jl6e2024826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Nov 2010 21:47:06 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id oA6Jl6PN074187; Sat, 6 Nov 2010 21:47:06 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id oA6Jl2jJ074184; Sat, 6 Nov 2010 21:47:02 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 6 Nov 2010 21:47:02 +0200 From: Kostik Belousov To: Alexander Kabaev Message-ID: <20101106194702.GN2392@deviant.kiev.zoral.com.ua> References: <20100805191446.GJ14016@felucia.tataz.chchile.org> <20100919081406.GH6864@felucia.tataz.chchile.org> <20100919184146.GE2389@deviant.kiev.zoral.com.ua> <20100920162925.GL6864@felucia.tataz.chchile.org> <20100920192708.GK2389@deviant.kiev.zoral.com.ua> <20100927094651.GB57265@felucia.tataz.chchile.org> <20100927154457.GJ43070@deviant.kiev.zoral.com.ua> <20101005181804.GJ7536@felucia.tataz.chchile.org> <20101105213905.GT30284@felucia.tataz.chchile.org> <20101105190023.29e5d39d@kan.dnsalias.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="f054HvE3bsu5oaav" Content-Disposition: inline In-Reply-To: <20101105190023.29e5d39d@kan.dnsalias.net> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: kan@freebsd.org, freebsd-hackers@freebsd.org, Jeremie Le Hen Subject: Re: [PATCH] Add -lssp_nonshared to GCC's LIB_SPEC unconditionally 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, 06 Nov 2010 19:47:12 -0000 --f054HvE3bsu5oaav Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 05, 2010 at 07:00:23PM -0400, Alexander Kabaev wrote: > On Fri, 5 Nov 2010 22:39:06 +0100 > Jeremie Le Hen wrote: >=20 > > Hi Kib, > >=20 > > On Tue, Oct 05, 2010 at 08:18:04PM +0200, Jeremie Le Hen wrote: > > >=20 > > > On Mon, Sep 27, 2010 at 06:44:57PM +0300, Kostik Belousov wrote: > > > > Hardcoding /usr/lib as the path to the library in the script looks > > > > problematic. For the buidlworld, you are linking resulting > > > > binaries with the host library, instead of the > > > > buildworld-produced one. For lib32, it makes non-working > > > > combination of 32/64 bit. > > >=20 > > > Sorry for the late reply, but I had to collect various evidences > > > for my sayings and my development machine is reaaaaaaaaaaally slow. > > >=20 > > > In fact it seems the toolchain built for buildworld contains a ld(1) > > > binary which invariably bases lookups for libraries in ${WORLDTMP}, > > > even in case of an absolute path. I have two evidences of this: > > > - Putting /usr/obj/usr/src/tmp/usr/lib/libssp_nonshared.a in > > > /usr/obj/usr/src/tmp/usr/lib/libc.ld leads toolchain's ld(1) to > > > use /usr/obj/usr/src/tmp/usr/obj/usr/src/tmp/usr/lib/libssp_nonshared= .a; > > > - I also verified this with a hand-wrought opensnoop-like DTrace > > > script. > >=20 > > I dare to remind you about my patch. Do you have any other concerns? > >=20 > > Thanks. > > Regards, > > --=20 > > Jeremie Le Hen > >=20 > > Humans are born free and equal. But some are more equal than others. > > Coluche >=20 > Hmm, I thought I did approve this patch already a long time agi, but > since you asked: >=20 > +.if defined(SHLIB_LDSCRIPT) && exists(${.CURDIR}/${SHLIB_LDSCRIPT}) >=20 > this should be: >=20 > +.if defined(SHLIB_LDSCRIPT) >=20 > ditto for all other similar places. Otherwise I do not think we should > hold the patch in queue ans should unleash it on unsuspecting public. Also, I think the "DEBUG" lines should be removed. You install the libxxx.ld and then symlink libxxx.so to libxxx.ld. Why ? Would it be enough to install just the libxxx.so ? Otherwise, I think you need the similar =2Eif ${SHLIBDIR} =3D=3D ${LIBDIR} magic, that is better to be avoided. --f054HvE3bsu5oaav Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAkzVsLYACgkQC3+MBN1Mb4jT/wCgxi4WlXr4+/xaU8A9E8Ke/Oul J4EAnRcsvYhEOI5bQrr9+ibq8hB8H3V8 =s1yG -----END PGP SIGNATURE----- --f054HvE3bsu5oaav-- From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 6 20:33:11 2010 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 F04CE106566B; Sat, 6 Nov 2010 20:33:11 +0000 (UTC) (envelope-from dteske@vicor.com) Received: from postoffice.vicor.com (postoffice.vicor.com [69.26.56.53]) by mx1.freebsd.org (Postfix) with ESMTP id CF3238FC08; Sat, 6 Nov 2010 20:33:11 +0000 (UTC) Received: from [71.202.142.31] (port=63242 helo=[192.168.1.93]) by postoffice.vicor.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71) (envelope-from ) id 1PEpRh-00043G-Ej; Sat, 06 Nov 2010 13:33:11 -0700 Mime-Version: 1.0 (Apple Message framework v1081) From: Devin Teske In-Reply-To: <4CD58136.6070509@freebsd.org> Date: Sat, 6 Nov 2010 13:33:04 -0700 Message-Id: <7D12F133-FBFD-4664-A5B2-D8DC6D189F9B@vicor.com> References: <201011052316.27839.jpaetzel@freebsd.org> <20101105.230617.74669306.imp@bsdimp.com> <4CD58136.6070509@freebsd.org> To: Nathan Whitehorn X-Mailer: Apple Mail (2.1081) X-Scan-Signature: efbd7d49882a16e52164b7dd8ceb816c X-Scan-Host: postoffice.vicor.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: jpaetzel@freebsd.org, freebsd-hackers@freebsd.org, Devin Teske , Garrett Cooper Subject: Re: txt-sysinstall scrapped 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, 06 Nov 2010 20:33:12 -0000 On Nov 6, 2010, at 9:24 AM, Nathan Whitehorn wrote: > On 11/06/10 01:04, Garrett Cooper wrote: >> On Fri, Nov 5, 2010 at 10:06 PM, Warner Losh wrote: >>>> Just to add to that (because I do find it a novel idea), 1) how >>>> are you going to properly prevent man in the middle attacks (SSL, = TLS, >>>> etc?), and 2) what webserver would you use? >>>=20 >>> https or ssh. >>>=20 >>> We're also toying with the idea of having a partition that you could >>> 'dd' your certs and keys to (so any system can customize the image >>> with keys to make sure you were talking to who you think you are). >>> We'd just reserve 1MB of space on partition s3. We'd then check to >>> see if there was a tar ball. If so, we'd extract it and do the >>> intelligent thing with the keys we find there. >>=20 >> Wouldn't it be better just to go with a read-write media solution >> (USB) like Matt Dillon was suggesting at today then? Then again, >> determining the root device to date is still a bit kludgy isn't it? >=20 > But this breaks badly for people who don't own USB sticks of = sufficient > size, are installing on machines without USB ports, can't boot from = USB, > want to install from a shared medium like PXE, are installing on = blades > with convenient shared CD drives but not USB etc. etc. Everything in = the > world can boot from CD, and we have to ensure that continues working. >=20 > I also have mixed feelings about needing to use a web browser to > instruct a web app inside a bundled web server to write a config file = to > be interpreted by shell scripts just in order to run gpart, newfs, and > tar. But if you get it working, it's better than sysinstall no matter > how baroque. > -Nathan I find myself identifying a lot with this sentiment. We have FreeBSD = running on 1,000+ systems (modestly) within our organization. We've = found that some older BIOSes don't boot from USB sticks so-well. It's = also hit-or-miss in varied combinations of old-BIOS and off-brand sticks = -- had great luck with those super-tiny PNY's that rotate-out, though = again, old BIOSes say pre-2003 P4 or AMD K6, have issues). And since we're shipping at a rate of at least 100+ servers a year that = are now coming without any optical drives... our solution has been to = purchase one of these for each/every field engineer: = http://www.lg.com/us/computer-products/optical-media/LG-external-dvd-burne= r-GP08LU30.jsp This great little device has worked wonders for over 30 field engineers = (modestly). Out of thousands upon thousands of installs with the thing, = we've really only had a problem with about a half-dozen individual PCs = -- but after a BIOS upgrade, they tended to work else we slapped = internal ATAPI CD-ROM's in there and they worked). Though, to-date what we've really found great-success in, is employing = the latest-and-greatest ISOLINUX boot-loader w/ their `isohybrid' ISO = post-processing program which encapsulates the disk-image contents = within a hardware-emulation structure (you can make your ISO -- when = written to USB stick -- appear to the BIOS as a ZIP disk, Hard Disk, = etc.). We currently tell all of our field engineers to download a single ISO = that is built with our custom build-process (which employs ISOLINUX and = `isohybrid' from http://syslinux.zytor.com/). This ISO can then = optionally -- at the field engineer's discretion -- either burn that ISO = to optical media and use the LG AC-Adapterless USB optical drive (linked = to above), OR ... they can use dd(1) to write the ISO directly to a USB = stick (though again... some older BIOSes prefer the optical over flash = media). This was, of course, quite a challenge to achieve. Here's a brief (lol -- it started that way, you got to believe me) list = of what we did to accomplish installs with one ISO on two mediums: 1. Entire swaths of sysinstall(8) were patched Out of the 48 source files that make up sysinstall (that I count = currently within RELENG_8), we've thus far patched 28 of them and added = 1 new file. We even added a new feature ... ability to install from a directory = rather than a device. In install.cfg, we have something akin to: nullfs=3D/path/to/freebsd/release mediaSetNullFS As implied by the name, a nullfs is done from the directory specified to = /dist -- where sysinstall(8) expects to find the mounted distribution, = regardless of what media you select. 2. One tiny kernel patch There's a feature in the kernel for forcing the boot-medium into = read-write mode (which is not the default... the default is to mount = read-only and switch it during boot-up). When we're mounting an mfsroot, = especially one that's been customized to run scripts which build the = `install.cfg' script to hand-off to sysinstall(8), you _want_ to mount = read-write out of the gate. This feature is enabled by setting the environment variable = vfs.root.mountfrom.options to "rw" in the loader's Forth name-space (in = loader.rc for example). Well, this was broken. : ( So we patched it : ) 3. One tiny patch to the release(7) Makefile Since we rely on the release(7) process to compile both our customized = sysinstall(8) and also our custom mfsroot (explained below), it became a = real problem that WORLD_FLAGS was not being passed to installworld from = within `/usr/obj'. For example, when passing in WORLD_FLAGS=3D"-DWITHOUT_OPENSSL" (see = src.conf(5)) we kept bombing out on the installworld phase which = installs your newly compiled object-files from /usr/obj to an = installbase of /usr/release (we pass CHROOTDIR=3D/usr/release to `make = release'). This was because installworld was descending into a directory like = gssapi which it shouldn't, had WORLD_FLAGS been properly replicated down = the chain to installworld. We fixed this with a one-liner patch to /usr/src/release/Makefile 4. A custom dialog(3) based menu system for selecting pre-scripted = installs of many different flavors 5. A custom highly customized mfsroot We start by patching /usr/src/release/i386/boot_crunch.conf (heavily). = We add the following utilities: cat(1), chflags(1), chmod(1), cp(1), kill(1), ln(1), mkdir(1), mv(1), = rmdir(1), sleep(1), bsdlabel(8) (aka disklabel), init(8), ldconfig(8), = mount(8), mount_cd9660(8), reboot(8) (aka halt), at(1) (aka atq, atrm, = batch), awk(1), bzip2(1) (aka bunzip2, bzcat), ee(1), passwd(1), = printf(1), tar(1), tail(1), uniq(1), chown(8) (aka chgrp), moused(8), = mtree(8), pw(8), pwd_mkdb(8), sendmail(8) (aka newaliases, mailq), = tzsetup(8), vidcontrol(1), dialog(1), grep(1), sort(1), and crontab(1) NOTE: Yes, all those fit into the same amount of disk-space currently = allocated for the mfsroot, so no patching was necessary to give us a = larger mfsroot. First, you might be asking yourself... OMG, why so many utilities added? With the exception of dialog(1), mount_cd9660(8), and sleep(1), ALL of = these utilities were added because they are called directly by = sysinstall(8). We wanted to do something absolutely crazy... we wanted to install = FreeBSD-8.1 amd64 while booted under FreeBSD-8.1 i386. This proved to be = a challenge because once sysinstall(8) is done laying-down the = distribution-sets chose, it then does a chroot(2) into the = newly-installed OS and starts calling all these lovely binaries (most = listed above are called when performing optional setup routines, like = configuring sendmail, setting up the mouse, etc. etc.). Well, by adding all these utilities to the mfsroot and patching = sysinstall(8) to keep /stand around, we can have sysinstall(8) -- when = told to do so -- only call executables out of /stand after the chroot. = This way, all the normal optional setup routines can be performed, but = now with the 32-bit binaries that we trust, rather than the 64-bit = binaries which cause the system to panic and reboot when invoked after = the chroot normally. This heavy patching affords the user to -- once in our custom dialog(3) = based menu system -- choose to install either 64-bit or 32-bit despite = having booted from 32-bit kernel whereas currently sysinstall(8) must be = run in an environment that can execute 64-bit binaries if you want to = install the 64-bit distributions. It also affords us the ability to put legacy OSes on the disk as = optional installs. Because our patched sysinstall will never call a = single binary within the installed base, we're safe from problems = involving incompatible binaries. Still talking about the customized mfsroot... once the `make release' = process is finished and we have our highly customized mfsroot, we then = patch it some more! We add the binary nullfs.ko kernel module -- to support our custom = sysinstall(8) feature of mediaSetNullFS -- which will load the nullfs = kernel module if this VFS type is not already compiled into the kernel = (more on that later -- see description of our custom boot loader below). Then we throw a very tiny binary custom init(8) that chain-loads to = sysinstall(8), but not before simply putting some dots up on the screen = for 4 seconds -- allowing the user to quickly hit Scroll-Lock and peruse = the kernel messages if necessary before sysinstall launches (this was a = real problem in 4.x where the scrollback history was not preserved so = well). We add `/install.cfg' (searched-for and read automatically by = sysinstall(8) on startup) which invokes a script which uses mount_cd9660 = to re-mount the device we booted off of to `/cdrom' That last part is important. Remember that I mentioned that we're using = ISOLINUX's `isohybrid' to post-process the ISO. A very nice effect is = that our post-processed ISO is probed by the cd9660 geom provider and = /dev/iso9660/VOLID appears in devfs when probed, despite the fact that = we booted using zip-disk or hard-disk emulation from the BIOS. This makes the process of re-mounting the media we booted from (from = within the mfsroot) a piece of cake, regardless of whether the field = engineer wrote the ISO to optical media or USB stick. Lastly, before our custom mfsroot stops interrupting sysinstall(8)'s = progress (remember, we invoked this custom shell script via = `/install.cfg' which used mount_cd9660(8) to mount `/dev/iso9660/VOLID' = to `/cdrom'), we invoke `/cdrom/freebsd/menu/menu' which is an ELF = executable based on dialog(3) which presents our custom menu to the user = for them to choose "Which OS?" to install (among which we have both = 32-bit variants AND 64-bit variants of FreeBSD). 6. Because there's always that ONE package you'd like to have = pre-installed along with your OS, we have an elaborate post-install = configuration system. However, we later realized that (as randi once so eloquently voiced) = installing Packages from sysinstall(8) is a bad bad idea. We patched sysinstall(8) to no longer call system executables for = configuration setups, allowing safe install/configuration of a foreign = binary system, though we couldn't patch the package installation process = for one very good reason... We can't predict what +INSTALL, +POST-INSTALL, +DEINSTALL, = +POST-DEINSTALL, and in-truth, even +CONTENTS (via @exec/@unexec) were = going to do. Some developers have even been caught writing these scripts = in perl (which is no longer part of the base distribution). So, for that ONE package that we just _had to have_ pre-installed before = first-boot (for us it's perl), we make use of DIST_LOCAL. sysinstall has = a feature allowing you to create your own custom distribution-set = (local). We ended up throwing a few packages in there. Though to be honest, we felt that perl and kernels deserved special = attention. Our patched sysinstall(8) also has a selector for our own = custom kernel (we have in our release, /usr/release/R/stage/kernels/FIS = which ends up in the ISO at = /freebsd/repos/8.1-RELEASE{,-amd64}/kernels/fis.?? w/ accompanying = files). It also has a selector for installing perl -- our release has = /usr/release/R/stage/trees/perl which is actually an unpacked = perl-5.10.1_1 package, which ends up on the iso at = /freebsd/repos/8.1-RELEASE{,-amd64}/perl/perl.?? w/ accompanying dist = files). I have to say, it's nice being able to install FreeBSD-8.1 = _with_ perl (and if I later decide to uninstall it, I can, because we = retained the /var/db/pkg records). Oh, and before anyone asks, yes, I hand-recoded the +INSTALL, etc. files = from the packages we converted to distribution-sets into post-install = routines that are performed automatically. 7. And if that all wasn't enough (phew -- yeah, even that was abridged) = ... now we get to the custom boot loader. This part isn't as important to the whole "boot from both optical _and_ = USB stick" schtick, as it is important to our own internal operations. We have found a common problem to be that we _don't_ currently upgrade = our Operating System often enough to keep up with hardware demands. We = quite often find that we can't order a part anymore because it went = End-of-Life (EOL). Then we're forced to get some new hardware that = performs the same functionality. This can continue for some time until = the operating system you're working with too becomes End-of-Life. If you're good, you'll still be OK... you'll just hire someone to = backport drivers (HINT: that was my job for several years), from later = revisions of the OS which _aren't_ EOL'd. However, that gravy-train comes to an end eventually when the gap = between your current OS and the next-non-EOL OS is ... oh... say, 4 = major revisions (compare FreeBSD-4.11 to FreeBSD-8.1). Well, as an enterprise model, we can't just say "well, sorry, the = community has stopped supporting our OS, can't help you" as our = customers (the ones running the 1000+ FreeBSD = workstations/pedestals/servers) look to us for = solutions/upgrades/everything FreeBSD. The proper solution is to get the customers to upgrade more often -- but = our customers are the type that don't like to upgrade more than once = every few years (and as my co-workers point-out, the FreeBSD community = has worked with us on that in the past -- delaying the EOL of certain = releases for example). However, we found a permanent solution. By building a custom boot-loader that allows us to select from a list of = custom kernels and custom mfsroots and change boot parameters visually, = we were able to solve the problem of not being able to install a = particular OS because the GENERIC kernel used by the Walnut = Creek/FreeBSD Mall CD/DVD's couldn't effectively probe the newer = hardware. Of course, the boot-loader alone was only half the solution. Because = naturally, just slapping a custom kernel and boot-loader onto the disc = to get around your boot problems won't change the fact that the = installer will still lay-down the GENERIC kernel. Your very first boot = off the internal system disk will fail if the hardware is something that = the GENERIC kernel can't utilize. The other half of the solution was to have our scripted installs lay = down a custom kernel and configure that kernel to boot. FYI: The boot-loader I developed for this is no slouch... it's = 1930-lines of ANS FICL Forth -- the reverse polish stack-based language = for which there is an embedded interpreter inside FreeBSD's = boot-loader). I did not customize the boot-loader itself, so much as I = wrote extensible Forth modules capable of managing a hierarchical and/or = deep menu structure (something far more advanced than what is displayed = by today's boot-loader). In the full-picture, this has allowed us to do crazy things... like = install FreeBSD-4.11 to hardware that is not currently supported by = RELENG_4 even in it's current state (we've done crazy things like = regress drivers from FreeBSD-6.x back to 4.x, mainly mpt, isp, mfi, em, = fxp, and others as we use a lot of varied RAID controllers and NICs). But none of this could have been possible without the build process that = we developed to develop the install platform itself. The build-platform consists of: autoconf-based configure.in and GNUMakefile.in configure script config.guess, config.sub, install-sh Though don't be fooled. The GNUMakefile.in (sorry BSD makefiles -- you = don't support `override' in the target deps which means length of = makefile would have tripled if not quadrupled) is a heavy-hitter. I got deathly tired of ripping open mfsroot's to modify the boot-loader = Forth modules, only to be forced to close them, deconfigure the md = device, run my tests, then repeat. I ended up developing the makefile to = generate an ISO that contains the boot-loader, kernel(s), forth modules, = etc. and have the menu-ing system load the mfsroot. This opened up the = door for a whole new set up possibilities. We are now using vesamenu.c32 from ISOLINUX to throw up an advanced menu = of options, allowing the user to select from booting memtest86, windiag, = dban, spinrite, tufftest pro, hdt.c32, seatools, firmware updaters, or = ... our freebsd installer. ISOLINUX these days has support for chain-loading (via memdisk module) = to ISO files. So our makefile makes the ISO containing all the FreeBSD = boot stuffs, and that chain-loads to mfsroot, and that re-mounts the = CD-ROM where all the releases are. Sounds convoluted, but it dramatically increased development time. It = also allowed the core of development to move off of FreeBSD as the = development platform. The building of the ISO(s) can be done on any OS, = including the Forth modules, which kernels to load into the menu, which = kernels period, and everything about the boot process with the exception = of the mfsroot itself, can be worked-on on some other OS like Linux, Mac = OS X, Windows, or whatever as long as it supports CVS, has gmake, and = has mkisofs (and perl for isohybrid ability -- though that can be = disabled via ./configure). Not to mention that the disc can also install other OSes. We have in the = works right now, a multi-distro Linux installer being developed on the = same platform, and an N-Lite based slipstreamed Windows install too. The = build process is actively allowing development of all three in parallel = (FreeBSD developers say "make freebsd", linux guys say "make linux", = windows guys say "make windows", and when we all coalesce to a = release-point, we'll say "make all" and it will make the all-in-one = super-disc capable of installing multiple versions of FreeBSD, multiple = versions of Linux, and multiple versions of Windows -- all scripted = installs with minimal user-interaction). Now... for the best part (which I've been saving the best for last): I've already started generalizing this stuff and releasing it to the = outside world: http://druidbsd.sf.net/ Right now, if you were to pull down the code using anonymous pserver CVS = access, here's what you would get today: 1. A development platform already capable of producing an ISO that boots = FreeBSD either from optical media or USB stick 2. The underpinnings of our very own installer that we use to perform = cross-platform 64-bit while booted under 32-bit 3. Many (if not all) of the FreeBSD patches mentioned above 4. The excellent build process that solves all the difficult problems of = how to get FreeBSD booted under ISOLINUX and also the abstraction layer = that allows you to develop the boot process on platforms other than = FreeBSD (achieved by building the chain-loaded ISO at compile-time) 5. A graphical boot menu system And I do think I left all the tools in there, so it should come complete = with memtest86, memtest86+, dban, windiag, seatools, etc. etc. though = you can compile the ISO without them if size is a concern. The resulting ISO right now is only 32MB with all the tools enabled, or = 24MB w/o. You can get it even smaller (sub 16MB) if you rip out all the = rescue tools that I have added too. .... I am so sad that I could not be at the MeetBSD unConference this year. = Me and a co-worker were going to come down and meet up with you all. We = already know many of you and many of you know us, but we've been down = for the count for a few years. We really wanted to show you what we have been developing for the past = 3-5 years, because we feel it's reached a really stable level where it's = worth showing. I guess we'll have to work at making an appearance for = next year. It's just with all the mergers, we've not been able to get away from the = grind-stone (especially with down-sizing). But don't worry, we'll be = back in the community soon. Many may know us by the name VICOR. Our = signatures have changed in our e-mail footers, but we are still the same = core set of developers. Though I do miss the annual release parties we = used to throw for FreeBSD (gosh, that seems like so long ago now). -- Cheers, Devin Teske -> CONTACT INFORMATION <- Business Solutions Consultant II FIS - fisglobal.com 510-735-5650 Mobile 510-621-2038 Office 510-621-2020 Office Fax 909-477-4578 Home/Fax devin.teske@fisglobal.com -> LEGAL DISCLAIMER <- This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy. -> FUN STUFF <- -----BEGIN GEEK CODE BLOCK----- Version 3.1 GAT/CS d(+) s: a- C++(++++) UB++++$ P++(++++) L++(++++) !E--- W++ N? o? = K- w O M+ V- PS+ PE Y+ PGP- t(+) 5? X+(++) R>++ tv(+) b+(++) DI+(++) D(+) G+>++ = e>+ h r>++ y+=20 ------END GEEK CODE BLOCK------ http://www.geekcode.com/ -> END TRANSMISSION <- P.S. Sorry if I rambled a bit... this stuff has been bottled up in my = head for a long time. For a time I was the sole developer on this = project.= From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 6 23:21:18 2010 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 77C47106566B for ; Sat, 6 Nov 2010 23:21:18 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 29F0E8FC17 for ; Sat, 6 Nov 2010 23:21:17 +0000 (UTC) Received: by gxk9 with SMTP id 9so2913200gxk.13 for ; Sat, 06 Nov 2010 16:21:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=DTFOWmaZNWLtqou+ZIrjLtkPs4SSfGTCzsv0jOxwCkg=; b=Kaic1zTcgy8wAkRZfLDaeRBD+PiImBsJsiQWVvADeSTJwl1Xi9Pya1iGNotl3ioUfL RmSxhhw9AHtiP1+pXcVyE7CLvkkEPty2XhJoaanhe046gWW12M+drHt4KW4jHllWfCd7 RCOuMKL5FqEx6haqe0hy3H7oFju/ChgyUfz04= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=Q9Mm0EaTxsqfrOK5iA4tx0uRoVBElfSwFxJiQykOMaeybJAwDFAYvw7GY+OARwVMxZ /eZZ3sluDc03kvy4xhzmogV+4Sb1pFfrPFe6g8rz/jGb1wY325PY03cqS8WhAFMFh6UI ZIJoeOpS6S+2cxymw0vyVgo8vP4vAjqGjufAE= Received: by 10.101.167.20 with SMTP id u20mr1134295ano.108.1289085676275; Sat, 06 Nov 2010 16:21:16 -0700 (PDT) Received: from mark-laptop-bsd.mark-home (CPE00222d75bcd8-CM00222d75bcd5.cpe.net.cable.rogers.com [99.233.53.36]) by mx.google.com with ESMTPS id g18sm3615734anh.38.2010.11.06.16.21.14 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 06 Nov 2010 16:21:15 -0700 (PDT) Date: Sat, 6 Nov 2010 19:20:58 -0400 From: Mark Johnston To: Ed Maste Message-ID: <20101106232058.GB1420@mark-laptop-bsd.mark-home> References: <20101105191443.GD1437@mark-laptop-bsd.mark-home> <20101105204519.GA2843@tops> <20101106173620.GA45793@sandvine.com> <20101106175603.GL2392@deviant.kiev.zoral.com.ua> <20101106180420.GA50159@sandvine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101106180420.GA50159@sandvine.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Kostik Belousov , freebsd-hackers@freebsd.org, Gleb Kurtsou Subject: Re: Userland debug symbols directory 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, 06 Nov 2010 23:21:18 -0000 On Sat, Nov 06, 2010 at 02:04:20PM -0400, Ed Maste wrote: > On Sat, Nov 06, 2010 at 07:56:03PM +0200, Kostik Belousov wrote: > > > On Sat, Nov 06, 2010 at 01:36:20PM -0400, Ed Maste wrote: > > > On Fri, Nov 05, 2010 at 10:45:19PM +0200, Gleb Kurtsou wrote: > > > > > > > I like the idea a lot, but why not to leave symbol files in /usr/obj, > > > > > > The application where this is most useful (and why we implemented it > > > originally) is the case where /usr/obj isn't available - for instance, > > > a binary installation other than where the source tree was built. If > > > you're going to keep /usr/obj around anyway then you can get most of > > > the benefit by just keeping the unstripped binaries / libs in there, > > > no? > > Not that easy, since you have to arrange to use libraries from obj/, > > by LD_LIBRARY_PATH etc. > > > > I fully support the work to install symbol files, and it should go > > into /usr, might be /usr/lib/debug. Possibly, some change to gdb (config) > > is required. > > > Yeah, I just mean that using LD_LIBRARY_PATH or whatever is still a lot > easier than realizing you don't have the debug info at all, and trying > to rebuild an identical binary or library with debug. > > I definitely want the changes to build and install the symbol files in > the FreeBSD tree. I don't have a huge concern over the exact path we > pick. > > -Ed FWIW, the default path is #defined in gnu/usr.bin/gdb/arch/*/config.h as DEBUGDIR. I suppose that could be changed on a system-by-system basis using a global configuration file, but apparently such a file needs to be defined at compile time: http://sourceware.org/gdb/onlinedocs/gdb/System_002dwide-configuration.html#System_002dwide-configuration I don't have a strong opinion on the location, /usr/lib/debug seems fine to me. -Mark From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 6 23:37:28 2010 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 4EB20106564A; Sat, 6 Nov 2010 23:37:28 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id F25E98FC0A; Sat, 6 Nov 2010 23:37:27 +0000 (UTC) Received: by pvc22 with SMTP id 22so1113255pvc.13 for ; Sat, 06 Nov 2010 16:37:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:in-reply-to :mime-version:content-transfer-encoding:content-type:message-id:cc :x-mailer:from:subject:date:to; bh=2eJXclCn7H1ctcuuLjMoKLOuLmn9iw7goS+WklCf37U=; b=RtYK8TlslXC9ZFq4ZBAIXZE+ZRB6hTroimj+xxcdpoOA6+LBIlqXgToLQ1MoaOHKVY Kzc8lKXNsQyEp6mo+D4zGJrV7YyrVbijTnwwP5e+hg00FbKwmJFgYgcG2VvUh/jynTpN H697SNBxz4Oj/uDLz/xGbhRfawthtOAgVOBcE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=NWyURsVwgK84aHYO1XVVBjnZWswnFsFmipWaiotDofEwQRryJVauPBWejuHOqI7OPj +tH7XIOTRJX0/H4xM2HOc7Vl6nocVCEPSUof7NWMarcQ72GRP2R0oZfMoHaugm+EDbKh oGH6JnLVMTC8egBh1qxExFCT9t+CUiVr+64OU= Received: by 10.142.215.16 with SMTP id n16mr2747194wfg.288.1289086646302; Sat, 06 Nov 2010 16:37:26 -0700 (PDT) Received: from [10.0.28.248] ([166.205.139.182]) by mx.google.com with ESMTPS id y42sm4769712wfd.22.2010.11.06.16.37.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 06 Nov 2010 16:37:23 -0700 (PDT) References: <201011052316.27839.jpaetzel@freebsd.org> <20101105.230617.74669306.imp@bsdimp.com> <4CD58136.6070509@freebsd.org> <7D12F133-FBFD-4664-A5B2-D8DC6D189F9B@vicor.com> In-Reply-To: <7D12F133-FBFD-4664-A5B2-D8DC6D189F9B@vicor.com> Mime-Version: 1.0 (iPhone Mail 8B117) Message-Id: <150A8520-3DC3-4978-916F-F51667482A50@gmail.com> X-Mailer: iPhone Mail (8B117) From: Garrett Cooper Date: Sat, 6 Nov 2010 16:37:25 -0700 To: Devin Teske Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "jpaetzel@freebsd.org" , "freebsd-hackers@freebsd.org" , Devin Teske , Nathan Whitehorn , Garrett Cooper Subject: Re: txt-sysinstall scrapped 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, 06 Nov 2010 23:37:28 -0000 On Nov 6, 2010, at 1:33 PM, Devin Teske wrote: >=20 > On Nov 6, 2010, at 9:24 AM, Nathan Whitehorn wrote: >=20 >> On 11/06/10 01:04, Garrett Cooper wrote: >>> On Fri, Nov 5, 2010 at 10:06 PM, Warner Losh wrote: >>>>> Just to add to that (because I do find it a novel idea), 1) how >>>>> are you going to properly prevent man in the middle attacks (SSL, TLS,= >>>>> etc?), and 2) what webserver would you use? >>>>=20 >>>> https or ssh. >>>>=20 >>>> We're also toying with the idea of having a partition that you could >>>> 'dd' your certs and keys to (so any system can customize the image >>>> with keys to make sure you were talking to who you think you are). >>>> We'd just reserve 1MB of space on partition s3. We'd then check to >>>> see if there was a tar ball. If so, we'd extract it and do the >>>> intelligent thing with the keys we find there. >>>=20 >>> Wouldn't it be better just to go with a read-write media solution >>> (USB) like Matt Dillon was suggesting at today then? Then again, >>> determining the root device to date is still a bit kludgy isn't it? >>=20 >> But this breaks badly for people who don't own USB sticks of sufficient >> size, are installing on machines without USB ports, can't boot from USB, >> want to install from a shared medium like PXE, are installing on blades >> with convenient shared CD drives but not USB etc. etc. Everything in the >> world can boot from CD, and we have to ensure that continues working. >>=20 >> I also have mixed feelings about needing to use a web browser to >> instruct a web app inside a bundled web server to write a config file to >> be interpreted by shell scripts just in order to run gpart, newfs, and >> tar. But if you get it working, it's better than sysinstall no matter >> how baroque. >> -Nathan >=20 >=20 > I find myself identifying a lot with this sentiment. We have FreeBSD runni= ng on 1,000+ systems (modestly) within our organization. We've found that so= me older BIOSes don't boot from USB sticks so-well. It's also hit-or-miss in= varied combinations of old-BIOS and off-brand sticks -- had great luck with= those super-tiny PNY's that rotate-out, though again, old BIOSes say pre-20= 03 P4 or AMD K6, have issues). >=20 > And since we're shipping at a rate of at least 100+ servers a year that ar= e now coming without any optical drives... our solution has been to purchase= one of these for each/every field engineer: >=20 > http://www.lg.com/us/computer-products/optical-media/LG-external-dvd-burne= r-GP08LU30.jsp >=20 > This great little device has worked wonders for over 30 field engineers (m= odestly). Out of thousands upon thousands of installs with the thing, we've r= eally only had a problem with about a half-dozen individual PCs -- but after= a BIOS upgrade, they tended to work else we slapped internal ATAPI CD-ROM's= in there and they worked). >=20 > Though, to-date what we've really found great-success in, is employing the= latest-and-greatest ISOLINUX boot-loader w/ their `isohybrid' ISO post-proc= essing program which encapsulates the disk-image contents within a hardware-= emulation structure (you can make your ISO -- when written to USB stick -- a= ppear to the BIOS as a ZIP disk, Hard Disk, etc.). >=20 > We currently tell all of our field engineers to download a single ISO that= is built with our custom build-process (which employs ISOLINUX and `isohybr= id' from http://syslinux.zytor.com/). This ISO can then optionally -- at the= field engineer's discretion -- either burn that ISO to optical media and us= e the LG AC-Adapterless USB optical drive (linked to above), OR ... they can= use dd(1) to write the ISO directly to a USB stick (though again... some ol= der BIOSes prefer the optical over flash media). >=20 > This was, of course, quite a challenge to achieve. >=20 > Here's a brief (lol -- it started that way, you got to believe me) list of= what we did to accomplish installs with one ISO on two mediums: >=20 > 1. Entire swaths of sysinstall(8) were patched >=20 > Out of the 48 source files that make up sysinstall (that I count currently= within RELENG_8), we've thus far patched 28 of them and added 1 new file. >=20 > We even added a new feature ... ability to install from a directory rather= than a device. In install.cfg, we have something akin to: >=20 > nullfs=3D/path/to/freebsd/release > mediaSetNullFS >=20 > As implied by the name, a nullfs is done from the directory specified to /= dist -- where sysinstall(8) expects to find the mounted distribution, regard= less of what media you select. >=20 >=20 >=20 > 2. One tiny kernel patch >=20 > There's a feature in the kernel for forcing the boot-medium into read-writ= e mode (which is not the default... the default is to mount read-only and sw= itch it during boot-up). When we're mounting an mfsroot, especially one that= 's been customized to run scripts which build the `install.cfg' script to ha= nd-off to sysinstall(8), you _want_ to mount read-write out of the gate. >=20 > This feature is enabled by setting the environment variable vfs.root.mount= from.options to "rw" in the loader's Forth name-space (in loader.rc for exam= ple). >=20 > Well, this was broken. : ( >=20 > So we patched it : ) >=20 >=20 >=20 > 3. One tiny patch to the release(7) Makefile >=20 > Since we rely on the release(7) process to compile both our customized sys= install(8) and also our custom mfsroot (explained below), it became a real p= roblem that WORLD_FLAGS was not being passed to installworld from within `/u= sr/obj'. >=20 > For example, when passing in WORLD_FLAGS=3D"-DWITHOUT_OPENSSL" (see src.co= nf(5)) we kept bombing out on the installworld phase which installs your new= ly compiled object-files from /usr/obj to an installbase of /usr/release (we= pass CHROOTDIR=3D/usr/release to `make release'). >=20 > This was because installworld was descending into a directory like gssapi w= hich it shouldn't, had WORLD_FLAGS been properly replicated down the chain t= o installworld. >=20 > We fixed this with a one-liner patch to /usr/src/release/Makefile >=20 >=20 >=20 > 4. A custom dialog(3) based menu system for selecting pre-scripted install= s of many different flavors >=20 >=20 >=20 > 5. A custom highly customized mfsroot >=20 > We start by patching /usr/src/release/i386/boot_crunch.conf (heavily). We a= dd the following utilities: >=20 > cat(1), chflags(1), chmod(1), cp(1), kill(1), ln(1), mkdir(1), mv(1), rmdi= r(1), sleep(1), bsdlabel(8) (aka disklabel), init(8), ldconfig(8), mount(8),= mount_cd9660(8), reboot(8) (aka halt), at(1) (aka atq, atrm, batch), awk(1)= , bzip2(1) (aka bunzip2, bzcat), ee(1), passwd(1), printf(1), tar(1), tail(1= ), uniq(1), chown(8) (aka chgrp), moused(8), mtree(8), pw(8), pwd_mkdb(8), s= endmail(8) (aka newaliases, mailq), tzsetup(8), vidcontrol(1), dialog(1), gr= ep(1), sort(1), and crontab(1) >=20 > NOTE: Yes, all those fit into the same amount of disk-space currently allo= cated for the mfsroot, so no patching was necessary to give us a larger mfsr= oot. >=20 > First, you might be asking yourself... OMG, why so many utilities added? >=20 > With the exception of dialog(1), mount_cd9660(8), and sleep(1), ALL of the= se utilities were added because they are called directly by sysinstall(8). >=20 > We wanted to do something absolutely crazy... we wanted to install FreeBSD= -8.1 amd64 while booted under FreeBSD-8.1 i386. This proved to be a challeng= e because once sysinstall(8) is done laying-down the distribution-sets chose= , it then does a chroot(2) into the newly-installed OS and starts calling al= l these lovely binaries (most listed above are called when performing option= al setup routines, like configuring sendmail, setting up the mouse, etc. etc= .). >=20 > Well, by adding all these utilities to the mfsroot and patching sysinstall= (8) to keep /stand around, we can have sysinstall(8) -- when told to do so -= - only call executables out of /stand after the chroot. This way, all the no= rmal optional setup routines can be performed, but now with the 32-bit binar= ies that we trust, rather than the 64-bit binaries which cause the system to= panic and reboot when invoked after the chroot normally. >=20 > This heavy patching affords the user to -- once in our custom dialog(3) ba= sed menu system -- choose to install either 64-bit or 32-bit despite having b= ooted from 32-bit kernel whereas currently sysinstall(8) must be run in an e= nvironment that can execute 64-bit binaries if you want to install the 64-bi= t distributions. >=20 > It also affords us the ability to put legacy OSes on the disk as optional i= nstalls. Because our patched sysinstall will never call a single binary with= in the installed base, we're safe from problems involving incompatible binar= ies. >=20 > Still talking about the customized mfsroot... once the `make release' proc= ess is finished and we have our highly customized mfsroot, we then patch it s= ome more! >=20 > We add the binary nullfs.ko kernel module -- to support our custom sysinst= all(8) feature of mediaSetNullFS -- which will load the nullfs kernel module= if this VFS type is not already compiled into the kernel (more on that late= r -- see description of our custom boot loader below). >=20 > Then we throw a very tiny binary custom init(8) that chain-loads to sysins= tall(8), but not before simply putting some dots up on the screen for 4 seco= nds -- allowing the user to quickly hit Scroll-Lock and peruse the kernel me= ssages if necessary before sysinstall launches (this was a real problem in 4= .x where the scrollback history was not preserved so well). >=20 > We add `/install.cfg' (searched-for and read automatically by sysinstall(8= ) on startup) which invokes a script which uses mount_cd9660 to re-mount the= device we booted off of to `/cdrom' >=20 > That last part is important. Remember that I mentioned that we're using IS= OLINUX's `isohybrid' to post-process the ISO. A very nice effect is that our= post-processed ISO is probed by the cd9660 geom provider and /dev/iso9660/V= OLID appears in devfs when probed, despite the fact that we booted using zip= -disk or hard-disk emulation from the BIOS. >=20 > This makes the process of re-mounting the media we booted from (from withi= n the mfsroot) a piece of cake, regardless of whether the field engineer wro= te the ISO to optical media or USB stick. >=20 > Lastly, before our custom mfsroot stops interrupting sysinstall(8)'s progr= ess (remember, we invoked this custom shell script via `/install.cfg' which u= sed mount_cd9660(8) to mount `/dev/iso9660/VOLID' to `/cdrom'), we invoke `/= cdrom/freebsd/menu/menu' which is an ELF executable based on dialog(3) which= presents our custom menu to the user for them to choose "Which OS?" to inst= all (among which we have both 32-bit variants AND 64-bit variants of FreeBSD= ). >=20 >=20 >=20 > 6. Because there's always that ONE package you'd like to have pre-installe= d along with your OS, we have an elaborate post-install configuration system= . >=20 > However, we later realized that (as randi once so eloquently voiced) insta= lling Packages from sysinstall(8) is a bad bad idea. >=20 > We patched sysinstall(8) to no longer call system executables for configur= ation setups, allowing safe install/configuration of a foreign binary system= , though we couldn't patch the package installation process for one very goo= d reason... >=20 > We can't predict what +INSTALL, +POST-INSTALL, +DEINSTALL, +POST-DEINSTALL= , and in-truth, even +CONTENTS (via @exec/@unexec) were going to do. Some de= velopers have even been caught writing these scripts in perl (which is no lo= nger part of the base distribution). >=20 > So, for that ONE package that we just _had to have_ pre-installed before f= irst-boot (for us it's perl), we make use of DIST_LOCAL. sysinstall has a fe= ature allowing you to create your own custom distribution-set (local). We en= ded up throwing a few packages in there. >=20 > Though to be honest, we felt that perl and kernels deserved special attent= ion. Our patched sysinstall(8) also has a selector for our own custom kernel= (we have in our release, /usr/release/R/stage/kernels/FIS which ends up in t= he ISO at /freebsd/repos/8.1-RELEASE{,-amd64}/kernels/fis.?? w/ accompanying= files). It also has a selector for installing perl -- our release has /usr/= release/R/stage/trees/perl which is actually an unpacked perl-5.10.1_1 packa= ge, which ends up on the iso at /freebsd/repos/8.1-RELEASE{,-amd64}/perl/per= l.?? w/ accompanying dist files). I have to say, it's nice being able to ins= tall FreeBSD-8.1 _with_ perl (and if I later decide to uninstall it, I can, b= ecause we retained the /var/db/pkg records). >=20 > Oh, and before anyone asks, yes, I hand-recoded the +INSTALL, etc. files f= rom the packages we converted to distribution-sets into post-install routine= s that are performed automatically. >=20 >=20 >=20 > 7. And if that all wasn't enough (phew -- yeah, even that was abridged) ..= . now we get to the custom boot loader. >=20 > This part isn't as important to the whole "boot from both optical _and_ US= B stick" schtick, as it is important to our own internal operations. >=20 > We have found a common problem to be that we _don't_ currently upgrade our= Operating System often enough to keep up with hardware demands. We quite of= ten find that we can't order a part anymore because it went End-of-Life (EOL= ). Then we're forced to get some new hardware that performs the same functio= nality. This can continue for some time until the operating system you're wo= rking with too becomes End-of-Life. >=20 > If you're good, you'll still be OK... you'll just hire someone to backport= drivers (HINT: that was my job for several years), from later revisions of t= he OS which _aren't_ EOL'd. >=20 > However, that gravy-train comes to an end eventually when the gap between y= our current OS and the next-non-EOL OS is ... oh... say, 4 major revisions (= compare FreeBSD-4.11 to FreeBSD-8.1). >=20 > Well, as an enterprise model, we can't just say "well, sorry, the communit= y has stopped supporting our OS, can't help you" as our customers (the ones r= unning the 1000+ FreeBSD workstations/pedestals/servers) look to us for solu= tions/upgrades/everything FreeBSD. >=20 > The proper solution is to get the customers to upgrade more often -- but o= ur customers are the type that don't like to upgrade more than once every fe= w years (and as my co-workers point-out, the FreeBSD community has worked wi= th us on that in the past -- delaying the EOL of certain releases for exampl= e). >=20 > However, we found a permanent solution. >=20 > By building a custom boot-loader that allows us to select from a list of c= ustom kernels and custom mfsroots and change boot parameters visually, we we= re able to solve the problem of not being able to install a particular OS be= cause the GENERIC kernel used by the Walnut Creek/FreeBSD Mall CD/DVD's coul= dn't effectively probe the newer hardware. >=20 > Of course, the boot-loader alone was only half the solution. Because natur= ally, just slapping a custom kernel and boot-loader onto the disc to get aro= und your boot problems won't change the fact that the installer will still l= ay-down the GENERIC kernel. Your very first boot off the internal system dis= k will fail if the hardware is something that the GENERIC kernel can't utili= ze. >=20 > The other half of the solution was to have our scripted installs lay down a= custom kernel and configure that kernel to boot. >=20 > FYI: The boot-loader I developed for this is no slouch... it's 1930-lines o= f ANS FICL Forth -- the reverse polish stack-based language for which there i= s an embedded interpreter inside FreeBSD's boot-loader). I did not customize= the boot-loader itself, so much as I wrote extensible Forth modules capable= of managing a hierarchical and/or deep menu structure (something far more a= dvanced than what is displayed by today's boot-loader). >=20 > In the full-picture, this has allowed us to do crazy things... like instal= l FreeBSD-4.11 to hardware that is not currently supported by RELENG_4 even i= n it's current state (we've done crazy things like regress drivers from Free= BSD-6.x back to 4.x, mainly mpt, isp, mfi, em, fxp, and others as we use a l= ot of varied RAID controllers and NICs). >=20 > But none of this could have been possible without the build process that w= e developed to develop the install platform itself. >=20 > The build-platform consists of: >=20 > autoconf-based configure.in and GNUMakefile.in > configure script > config.guess, config.sub, install-sh >=20 > Though don't be fooled. The GNUMakefile.in (sorry BSD makefiles -- you don= 't support `override' in the target deps which means length of makefile woul= d have tripled if not quadrupled) is a heavy-hitter. >=20 > I got deathly tired of ripping open mfsroot's to modify the boot-loader Fo= rth modules, only to be forced to close them, deconfigure the md device, run= my tests, then repeat. I ended up developing the makefile to generate an IS= O that contains the boot-loader, kernel(s), forth modules, etc. and have the= menu-ing system load the mfsroot. This opened up the door for a whole new s= et up possibilities. >=20 > We are now using vesamenu.c32 from ISOLINUX to throw up an advanced menu o= f options, allowing the user to select from booting memtest86, windiag, dban= , spinrite, tufftest pro, hdt.c32, seatools, firmware updaters, or ... our f= reebsd installer. >=20 > ISOLINUX these days has support for chain-loading (via memdisk module) to I= SO files. So our makefile makes the ISO containing all the FreeBSD boot stuf= fs, and that chain-loads to mfsroot, and that re-mounts the CD-ROM where all= the releases are. >=20 > Sounds convoluted, but it dramatically increased development time. It also= allowed the core of development to move off of FreeBSD as the development p= latform. The building of the ISO(s) can be done on any OS, including the For= th modules, which kernels to load into the menu, which kernels period, and e= verything about the boot process with the exception of the mfsroot itself, c= an be worked-on on some other OS like Linux, Mac OS X, Windows, or whatever a= s long as it supports CVS, has gmake, and has mkisofs (and perl for isohybri= d ability -- though that can be disabled via ./configure). >=20 > Not to mention that the disc can also install other OSes. We have in the w= orks right now, a multi-distro Linux installer being developed on the same p= latform, and an N-Lite based slipstreamed Windows install too. The build pro= cess is actively allowing development of all three in parallel (FreeBSD deve= lopers say "make freebsd", linux guys say "make linux", windows guys say "ma= ke windows", and when we all coalesce to a release-point, we'll say "make al= l" and it will make the all-in-one super-disc capable of installing multiple= versions of FreeBSD, multiple versions of Linux, and multiple versions of W= indows -- all scripted installs with minimal user-interaction). >=20 > Now... for the best part (which I've been saving the best for last): >=20 > I've already started generalizing this stuff and releasing it to the outsi= de world: >=20 > http://druidbsd.sf.net/ >=20 > Right now, if you were to pull down the code using anonymous pserver CVS a= ccess, here's what you would get today: >=20 > 1. A development platform already capable of producing an ISO that boots Fre= eBSD either from optical media or USB stick > 2. The underpinnings of our very own installer that we use to perform cros= s-platform 64-bit while booted under 32-bit > 3. Many (if not all) of the FreeBSD patches mentioned above > 4. The excellent build process that solves all the difficult problems of h= ow to get FreeBSD booted under ISOLINUX and also the abstraction layer that a= llows you to develop the boot process on platforms other than FreeBSD (achie= ved by building the chain-loaded ISO at compile-time) > 5. A graphical boot menu system >=20 > And I do think I left all the tools in there, so it should come complete w= ith memtest86, memtest86+, dban, windiag, seatools, etc. etc. though you can= compile the ISO without them if size is a concern. >=20 > The resulting ISO right now is only 32MB with all the tools enabled, or 24= MB w/o. You can get it even smaller (sub 16MB) if you rip out all the rescue= tools that I have added too. >=20 > .... >=20 > I am so sad that I could not be at the MeetBSD unConference this year. Me a= nd a co-worker were going to come down and meet up with you all. We already k= now many of you and many of you know us, but we've been down for the count f= or a few years. >=20 > We really wanted to show you what we have been developing for the past 3-5= years, because we feel it's reached a really stable level where it's worth s= howing. I guess we'll have to work at making an appearance for next year. >=20 > It's just with all the mergers, we've not been able to get away from the g= rind-stone (especially with down-sizing). But don't worry, we'll be back in t= he community soon. Many may know us by the name VICOR. Our signatures have c= hanged in our e-mail footers, but we are still the same core set of develope= rs. Though I do miss the annual release parties we used to throw for FreeBSD= (gosh, that seems like so long ago now). Being brief (sadly it would take a millennia to abbreviate the above tex= t with my phone :/) -- the suggestion was to replace the DVD with a fat USB i= mage. That was all :). Thanks! -Garrett=