From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 24 00:22:48 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id F17481065670; Sun, 24 Oct 2010 00:22:48 +0000 (UTC) Date: Sun, 24 Oct 2010 00:22:48 +0000 From: Alexander Best To: freebsd-hackers@freebsd.org Message-ID: <20101024002248.GA73346@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="G4iJoqBmSsgzjUCe" Content-Disposition: inline Subject: fix pnpinfo on arch=amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 24 Oct 2010 00:22:49 -0000 --G4iJoqBmSsgzjUCe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline this tiny patch will fix pnpinfo so it doesn't core dump (bus error) any longer on arch=amd64. cheers. alex -- a13x --G4iJoqBmSsgzjUCe Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="pnpinfo.c.diff" diff --git a/contrib/pnpinfo/pnpinfo.c b/contrib/pnpinfo/pnpinfo.c index 790cfd8..c09f4ef 100644 --- a/contrib/pnpinfo/pnpinfo.c +++ b/contrib/pnpinfo/pnpinfo.c @@ -588,7 +588,7 @@ main(int argc, char **argv) { int num_pnp_devs; -#ifdef __i386__ +#if defined(__i386__) || defined(__amd64__) /* Hey what about a i386_iopl() call :) */ if (open("/dev/io", O_RDONLY) < 0) errx(1, "can't get I/O privilege"); --G4iJoqBmSsgzjUCe-- From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 24 00:54:08 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 89352106566B; Sun, 24 Oct 2010 00:54:08 +0000 (UTC) Date: Sun, 24 Oct 2010 00:54:08 +0000 From: Alexander Best To: Robert Watson Message-ID: <20101024005408.GA76451@freebsd.org> References: <20101019233656.GA84316@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: freebsd-hackers@freebsd.org Subject: Re: addition of sysctl nodes after compile time X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Oct 2010 00:54:08 -0000 On Thu Oct 21 10, Robert Watson wrote: > > On Tue, 19 Oct 2010, Alexander Best wrote: > > >does this limitation still exist? > > Sysctls can be added dynamically using the sysctl_add_oid(9) KPI, which has > existed (as far as I'm aware) at least since FreeBSD 4.x. It could be that > this KPI provides the functionality required to do what the comment > describes. thanks a lot for the hint. maybe i'll hack into the cd driver and see if i can make the minimum and maximum timeout values apply to specific devices. cheers. alex > > Robert -- a13x From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 24 01:18:54 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 407B61065670; Sun, 24 Oct 2010 01:18:54 +0000 (UTC) Date: Sun, 24 Oct 2010 01:18:54 +0000 From: Alexander Best To: Dag-Erling =?iso-8859-15?Q?Sm=F8rgrav?= Message-ID: <20101024011854.GB78293@freebsd.org> References: <201009161742.24228.tijl@coosemans.org> <201009161619.o8GGJAmv035378@lurza.secnetix.de> <20101018155944.GA12425@freebsd.org> <868w1r92rf.fsf@ds4.des.no> <20101021122110.GA65490@freebsd.org> <86zku77mj6.fsf@ds4.des.no> <20101021130730.GA72290@freebsd.org> <86r5fj7gin.fsf@ds4.des.no> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <86r5fj7gin.fsf@ds4.des.no> Cc: freebsd-hackers@freebsd.org, mav@freebsd.org, Tijl Coosemans , Oliver Fromme Subject: Re: Summary: Re: Spin down HDD after disk sync or before power off X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 24 Oct 2010 01:18:54 -0000 On Thu Oct 21 10, Dag-Erling Smørgrav wrote: > Alexander Best writes: > > no need to get upset. you asked where i found the information regarding the > > wear impact of spinning down disks and i gave you the answer. > > I am upset by your claim that "doing spin downs upon reboot might be > even worse than not doing spindowns upon shutdown", because you should > know better, and following your advice could damage people's hardware. well...since currently hdds don't spindown during shutdown the current behavior is in fact damaging hardware. i don't quite understand why this hasn't been fixed yet. the patch is available and known to work. it won't cause any problems with SCSI devices like mav's current implementation, since the spindown code is limited to ATA devices. instead of talking and talking somebody should drop the changes into HEAD! cheers. alex > > DES > -- > Dag-Erling Smørgrav - des@des.no -- a13x From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 24 02:56:07 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 BABC11065672; Sun, 24 Oct 2010 02:56:07 +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 2032A8FC08; Sun, 24 Oct 2010 02:56:06 +0000 (UTC) Received: by wyb42 with SMTP id 42so2224330wyb.13 for ; Sat, 23 Oct 2010 19:56:06 -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=G3Xs5qzA+ZWQ81R2YdYV7eUlj7cro1PxlQfheq8XuD8=; b=EhO3IW9cm5Zf4zn0oOaX25aMwH4UkGT/xOck6ZSjigzFZ1GbBct0RmteFSdtpGWQ5q P2/kfNRrTy96A5+Rd6z5YAlPMaMtuqmPdL1ICbdIhMjq+rAmAH4AkHtPxP1bwBOsl4Jv j+lBC0PS6tL2j6LxQetAF5YO3Iqgu2q33ymrs= 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=oMvbrievGvcyS1s+4z8UZdzeCACveVCBHFpXFIULoYFROtoP5sn/MMysQRgNfgLJ60 BGBc3NSG9qO0Uy4npoCS1+H0oN9ppAwtLy1Jzt446/YzIp6XlhhMW/bF9IVU1w9wmQ4a etm9BFX0RsOM/dwRTTHW7lGnVPf1kyH29OfHY= MIME-Version: 1.0 Received: by 10.216.11.205 with SMTP id 55mr4549122wex.51.1287888966024; Sat, 23 Oct 2010 19:56:06 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.216.10.198 with HTTP; Sat, 23 Oct 2010 19:56:05 -0700 (PDT) In-Reply-To: <20101024002248.GA73346@freebsd.org> References: <20101024002248.GA73346@freebsd.org> Date: Sat, 23 Oct 2010 19:56:05 -0700 X-Google-Sender-Auth: UR207EQFSRmaeOnIoXGXItHwZ7U Message-ID: From: Garrett Cooper To: Alexander Best Content-Type: multipart/mixed; boundary=0016364d2cbd547e8804935404dc Cc: freebsd-hackers@freebsd.org Subject: Re: fix pnpinfo on arch=amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 24 Oct 2010 02:56:07 -0000 --0016364d2cbd547e8804935404dc Content-Type: text/plain; charset=ISO-8859-1 On Sat, Oct 23, 2010 at 5:22 PM, Alexander Best wrote: > this tiny patch will fix pnpinfo so it doesn't core dump (bus error) any > longer on arch=amd64. 1. I had to modify the Makefile to get it to work. 2. FWIW, I don't there's really much point in adding a check for only x86 architectures, if the tool is capable of more than that. 3. Might as well close the file descriptor after opening it. SIGBUS occurs because it doesn't have permission to write via outb. It's a shame that there isn't a more proper way to catch this SIGBUS fault minus adding a SIGBUS handler (but that might have other undesired side effects). Thanks, -Garrett --0016364d2cbd547e8804935404dc Content-Type: text/x-patch; charset=US-ASCII; name="pnpinfo-improvements.patch" Content-Disposition: attachment; filename="pnpinfo-improvements.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gfnbm9bi1 SW5kZXg6IGNvbnRyaWIvcG5waW5mby9wbnBpbmZvLmMKPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gY29udHJpYi9w bnBpbmZvL3BucGluZm8uYwkocmV2aXNpb24gMjE0MTY5KQorKysgY29udHJpYi9wbnBpbmZvL3Bu cGluZm8uYwkod29ya2luZyBjb3B5KQpAQCAtNTA2LDcgKzUwNiw3IEBACiAJfSBlbHNlIHsKIAkg ICAgLyogSGFuZGxlIGxhcmdlIHJlc291Y2UgZGF0YSB0eXBlcyAqLwogCSAgICB1X2NoYXIgYnVm WzJdOwotCSAgICBpZiAoIWdldF9yZXNvdXJjZV9pbmZvKChjaGFyICopYnVmLCAyKSkKKwkgICAg aWYgKCFnZXRfcmVzb3VyY2VfaW5mbyhidWYsIDIpKQogCQlicmVhazsKIAkgICAgbGFyZ2VfbGVu ID0gKGJ1ZlsxXSA8PCA4KSArIGJ1ZlswXTsKIApAQCAtNTg2LDEzICs1ODYsMTMgQEAKIGludAog bWFpbihpbnQgYXJnYywgY2hhciAqKmFyZ3YpCiB7CisgICAgaW50IGZkOwogICAgIGludCBudW1f cG5wX2RldnM7CiAKLSNpZmRlZiBfX2kzODZfXwogICAgIC8qIEhleSB3aGF0IGFib3V0IGEgaTM4 Nl9pb3BsKCkgY2FsbCA6KSAqLwotICAgIGlmIChvcGVuKCIvZGV2L2lvIiwgT19SRE9OTFkpIDwg MCkKLQllcnJ4KDEsICJjYW4ndCBnZXQgSS9PIHByaXZpbGVnZSIpOwotI2VuZGlmCisgICAgaWYg KChmZCA9IG9wZW4oIi9kZXYvaW8iLCBPX1JET05MWSkpIDwgMCkKKwllcnIoMSwgImNhbid0IGdl dCBJL08gcHJpdmlsZWdlcyIpOworICAgICh2b2lkKSBjbG9zZShmZCk7CiAKICAgICBwcmludGYo IkNoZWNraW5nIGZvciBQbHVnLW4tUGxheSBkZXZpY2VzLi4uXG4iKTsKIApJbmRleDogY29udHJp Yi9wbnBpbmZvL01ha2VmaWxlCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGNvbnRyaWIvcG5waW5mby9NYWtlZmls ZQkocmV2aXNpb24gMjE0MTY5KQorKysgY29udHJpYi9wbnBpbmZvL01ha2VmaWxlCSh3b3JraW5n IGNvcHkpCkBAIC0yLDYgKzIsNiBAQAogCiBQUk9HPQlwbnBpbmZvCiBNQU44PQlwbnBpbmZvLjgK LUNGTEFHUz0gLVdhbGwKK0NGTEFHUz0gLVdhbGwgLUkkey5DVVJESVJ9Ly4uLy4uL3N5cwogCiAu aW5jbHVkZSA8YnNkLnByb2cubWs+Cg== --0016364d2cbd547e8804935404dc-- From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 24 04:05:45 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 61627106566C; Sun, 24 Oct 2010 04:05:45 +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 6C4CC8FC12; Sun, 24 Oct 2010 04:05:44 +0000 (UTC) Received: by wyb42 with SMTP id 42so2245959wyb.13 for ; Sat, 23 Oct 2010 21:05:43 -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=7W/Ipmu6d1TJtXMhH3cRIaV+0pHPK9gp/Y0Z/MDhSDA=; b=CaxDEy4+scNGgOsDLRynz1fUROm3wPglH8wXcRkgjUXfmltlD8X1S9hReftL1nEZS2 HzKPOTmxBOOfSO5Rzm6zyz3SEGRBy7qu2JewWfnRnsad5f5ReMgtTuJEDFCaVZh7WC6B luZbMDqWbIU9gLZkkWvQiKt3H7yMnAgceeudo= 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=L7aB+tTeUC/O+Nl0d+bKfs7jlna/Kp49OlCvC+aHPmF25nkljBDD1q5JairMtcb3+t txokvWUAkfY1dUfVKI61m7rFXvj40t5/zV7z87M9ICN3nO03Djwgh9H+IMG1P53+Ng4m 0DyRhY2ukWGIl6ICSp4C2Mvdb4wQRlfD4deJY= MIME-Version: 1.0 Received: by 10.216.65.196 with SMTP id f46mr4536257wed.113.1287893143272; Sat, 23 Oct 2010 21:05:43 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.216.10.198 with HTTP; Sat, 23 Oct 2010 21:05:43 -0700 (PDT) In-Reply-To: <8662wz4twb.fsf@ds4.des.no> References: <86fwyq8rsc.fsf@ds4.des.no> <86d3tujh72.fsf@ds4.des.no> <864of680wv.fsf@ds4.des.no> <8662zkurx9.fsf@ds4.des.no> <8662zg586z.fsf@ds4.des.no> <8662wz4twb.fsf@ds4.des.no> Date: Sat, 23 Oct 2010 21:05:43 -0700 X-Google-Sender-Auth: i2SK-Cz-cy8RZcyMTPrAKgYC-ms Message-ID: From: Garrett Cooper To: =?ISO-8859-1?Q?Dag=2DErling_Sm=F8rgrav?= Content-Type: multipart/mixed; boundary=000e0cdfc900503d80049354fd59 Cc: freebsd-hackers@freebsd.org, Ivan Voras Subject: Re: Why is TUNABLE_INT discouraged? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 24 Oct 2010 04:05:45 -0000 --000e0cdfc900503d80049354fd59 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2010/10/18 Dag-Erling Sm=F8rgrav : > Garrett Cooper writes: >> PS I added uquad_t for consistency in the APIs, even though quad_t was >> deprecated, but I didn't bump __FreeBSD_version__ -- wasn't sure if I >> should have done that). > > You should bump __FreeBSD_version__ anyway so third-party or shared code > can use the new API if it is available and the old one if it isn't. > >> Let's try with the patch attached... > > Mailman strips binary attachments. =A0The correct MIME type is > text/x-patch. Ok. Let's retry with a .patch extension and by bumping __FreeBSD_versio= n__. Thanks! -Garrett --000e0cdfc900503d80049354fd59 Content-Type: text/x-patch; charset=US-ASCII; name="tunables-enhancement.patch" Content-Disposition: attachment; filename="tunables-enhancement.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gfne3kym1 SW5kZXg6IHN5cy9rZXJuL2tlcm5fZW52aXJvbm1lbnQuYwo9PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMva2Vy bi9rZXJuX2Vudmlyb25tZW50LmMJKHJldmlzaW9uIDIxNDI1OCkKKysrIHN5cy9rZXJuL2tlcm5f ZW52aXJvbm1lbnQuYwkod29ya2luZyBjb3B5KQpAQCAtNTAsNiArNTAsNyBAQAogI2luY2x1ZGUg PHN5cy9zeXNlbnQuaD4KICNpbmNsdWRlIDxzeXMvc3lzcHJvdG8uaD4KICNpbmNsdWRlIDxzeXMv bGlia2Vybi5oPgorI2luY2x1ZGUgPHN5cy9saW1pdHMuaD4KICNpbmNsdWRlIDxzeXMva2Vudi5o PgogCiAjaW5jbHVkZSA8c2VjdXJpdHkvbWFjL21hY19mcmFtZXdvcmsuaD4KQEAgLTQ0MiwzMiAr NDQzLDExNSBAQAogfQogCiAvKgotICogUmV0dXJuIGEgc3RyaW5nIHZhbHVlIGZyb20gYW4gZW52 aXJvbm1lbnQgdmFyaWFibGUuCisgKiBSZXR1cm4gdGhlIG11bHRpcGxpZXIgZm9yIGEgdXNlciBz cGVjaWZpZWQgc3VmZml4IGZyb20gYSBnZXRlbnYgY2FsbC4KICAqLwordWludG1heF90CitnZXRl bnZfcGFyc2Vfc3VmZml4KGNvbnN0IGNoYXIgc3VmZml4KQoreworCXVpbnRtYXhfdCBtdWx0aXBs aWVyID0gMTsKKworCXN3aXRjaCAoc3VmZml4KSB7CisJY2FzZSAndCc6IGNhc2UgJ1QnOgorCQlt dWx0aXBsaWVyICo9IDEwMjQ7CisJY2FzZSAnZyc6IGNhc2UgJ0cnOgorCQltdWx0aXBsaWVyICo9 IDEwMjQ7CisJY2FzZSAnbSc6IGNhc2UgJ00nOgorCQltdWx0aXBsaWVyICo9IDEwMjQ7CisJY2Fz ZSAnayc6IGNhc2UgJ0snOgorCQltdWx0aXBsaWVyICo9IDEwMjQ7CisJY2FzZSAnXDAnOgorCQli cmVhazsKKwlkZWZhdWx0OgorCQltdWx0aXBsaWVyID0gMDsKKwl9CisKKwlyZXR1cm4gKG11bHRp cGxpZXIpOworfQorCisvKgorICogUmV0dXJuIGEgc2lnbmVkIHF1YW50aXR5IGZyb20gYW4gZW52 aXJvbm1lbnQgdmFyaWFibGUuCisgKi8KIGludAotZ2V0ZW52X3N0cmluZyhjb25zdCBjaGFyICpu YW1lLCBjaGFyICpkYXRhLCBpbnQgc2l6ZSkKK2dldGVudl9zaWduZWQoY29uc3QgY2hhciAqbmFt ZSwgaW50bWF4X3QgKmRhdGEsIGNvbnN0IGludG1heF90IG1pbiwKKyAgICBjb25zdCBpbnRtYXhf dCBtYXgpCiB7Ci0JY2hhciAqdG1wOworCXVpbnRtYXhfdAltdWx0aXBsaWVyOworCWludG1heF90 CWl2OworCWludAkJcmV0X2NvZGU7CisJY2hhcgkJKnZhbHVlOworCWNoYXIJCSp2dHA7CiAKLQl0 bXAgPSBnZXRlbnYobmFtZSk7Ci0JaWYgKHRtcCAhPSBOVUxMKSB7Ci0JCXN0cmxjcHkoZGF0YSwg dG1wLCBzaXplKTsKLQkJZnJlZWVudih0bXApOwotCQlyZXR1cm4gKDEpOwotCX0gZWxzZQotCQly ZXR1cm4gKDApOworCXJldF9jb2RlID0gMDsKKworCXZhbHVlID0gZ2V0ZW52KG5hbWUpOworCWlm ICh2YWx1ZSA9PSBOVUxMKQorCQlyZXR1cm4gKHJldF9jb2RlKTsKKwlpdiA9IHN0cnRvcSh2YWx1 ZSwgJnZ0cCwgMCk7CisJaWYgKHZ0cCA9PSB2YWx1ZSB8fCAodnRwWzBdICE9ICdcMCcgJiYgdnRw WzFdICE9ICdcMCcpIHx8CisJICAgIChtdWx0aXBsaWVyID0gZ2V0ZW52X3BhcnNlX3N1ZmZpeCh2 dHBbMF0pKSA9PSAwKSB7CisJCS8qIAorCQkgKiBDYXRjaCBlcnJvcnMgaW4gcGFyc2luZyB0aGUg bnVtYmVyLCBiYWQgaW5wdXQsIG9yIHRoZQorCQkgKiBzdWZmaXggaWYgb25lIHdhcyBzcGVjaWZp ZWQuCisJCSAqLworCQk7CisJfSBlbHNlIHsKKwkJaXYgKj0gbXVsdGlwbGllcjsKKwkJaWYgKG1p biA8PSBpdiAmJiBpdiA8PSBtYXgpIHsKKwkJCSpkYXRhID0gaXY7CisJCQlyZXRfY29kZSA9IDE7 CisJCX0KKwl9CisJZnJlZWVudih2YWx1ZSk7CisJcmV0dXJuIChyZXRfY29kZSk7CiB9CiAKIC8q CisgKiBSZXR1cm4gYW4gdW5zaWduZWQgcXVhbnRpdHkgZnJvbSBhbiBlbnZpcm9ubWVudCB2YXJp YWJsZS4KKyAqLworaW50CitnZXRlbnZfdW5zaWduZWQoY29uc3QgY2hhciAqbmFtZSwgdWludG1h eF90ICpkYXRhLCBjb25zdCB1aW50bWF4X3QgbWluLAorICAgIGNvbnN0IHVpbnRtYXhfdCBtYXgp Cit7CisJdWludG1heF90CW11bHRpcGxpZXI7CisJdWludG1heF90CXVpdjsKKwlpbnQJCXJldF9j b2RlOworCWNoYXIJCSp2YWx1ZTsKKwljaGFyCQkqdnRwOworCisJcmV0X2NvZGUgPSAwOworCisJ dmFsdWUgPSBnZXRlbnYobmFtZSk7CisJaWYgKHZhbHVlID09IE5VTEwpCisJCXJldHVybiAocmV0 X2NvZGUpOworCXVpdiA9IHN0cnRvdXEodmFsdWUsICZ2dHAsIDApOworCWlmICh2dHAgPT0gdmFs dWUgfHwgKHZ0cFswXSAhPSAnXDAnICYmIHZ0cFsxXSAhPSAnXDAnKSB8fAorCSAgICAobXVsdGlw bGllciA9IGdldGVudl9wYXJzZV9zdWZmaXgodnRwWzBdKSkgPT0gMCkgeworCQkvKiAKKwkJICog Q2F0Y2ggZXJyb3JzIGluIHBhcnNpbmcgdGhlIG51bWJlciwgYmFkIGlucHV0LCBvciB0aGUKKwkJ ICogc3VmZml4IGlmIG9uZSB3YXMgc3BlY2lmaWVkLgorCQkgKi8KKwkJOworCX0gZWxzZSB7CisJ CXVpdiAqPSBtdWx0aXBsaWVyOworCQlpZiAobWluIDw9IHVpdiAmJiB1aXYgPD0gbWF4KSB7CisJ CQkqZGF0YSA9IHVpdjsKKwkJCXJldF9jb2RlID0gMTsKKwkJfQorCX0KKwlmcmVlZW52KHZhbHVl KTsKKwlyZXR1cm4gKHJldF9jb2RlKTsKK30KKworLyoKICAqIFJldHVybiBhbiBpbnRlZ2VyIHZh bHVlIGZyb20gYW4gZW52aXJvbm1lbnQgdmFyaWFibGUuCiAgKi8KIGludAogZ2V0ZW52X2ludChj b25zdCBjaGFyICpuYW1lLCBpbnQgKmRhdGEpCiB7Ci0JcXVhZF90IHRtcDsKKwlpbnRtYXhfdCB0 bXA7CiAJaW50IHJ2YWw7CiAKLQlydmFsID0gZ2V0ZW52X3F1YWQobmFtZSwgJnRtcCk7CisJcnZh bCA9IGdldGVudl9zaWduZWQobmFtZSwgJnRtcCwgSU5UX01JTiwgSU5UX01BWCk7CiAJaWYgKHJ2 YWwpCiAJCSpkYXRhID0gKGludCkgdG1wOwogCXJldHVybiAocnZhbCk7CkBAIC00NzksMTAgKzU2 MywxMCBAQAogaW50CiBnZXRlbnZfdWludChjb25zdCBjaGFyICpuYW1lLCB1bnNpZ25lZCBpbnQg KmRhdGEpCiB7Ci0JcXVhZF90IHRtcDsKKwlpbnRtYXhfdCB0bXA7CiAJaW50IHJ2YWw7CiAKLQly dmFsID0gZ2V0ZW52X3F1YWQobmFtZSwgJnRtcCk7CisJcnZhbCA9IGdldGVudl91bnNpZ25lZChu YW1lLCAmdG1wLCAwLCBVSU5UX01BWCk7CiAJaWYgKHJ2YWwpCiAJCSpkYXRhID0gKHVuc2lnbmVk IGludCkgdG1wOwogCXJldHVybiAocnZhbCk7CkBAIC00OTQsMTAgKzU3OCwxMCBAQAogaW50CiBn ZXRlbnZfbG9uZyhjb25zdCBjaGFyICpuYW1lLCBsb25nICpkYXRhKQogewotCXF1YWRfdCB0bXA7 CisJaW50bWF4X3QgdG1wOwogCWludCBydmFsOwogCi0JcnZhbCA9IGdldGVudl9xdWFkKG5hbWUs ICZ0bXApOworCXJ2YWwgPSBnZXRlbnZfc2lnbmVkKG5hbWUsICZ0bXAsIExPTkdfTUlOLCBMT05H X01BWCk7CiAJaWYgKHJ2YWwpCiAJCSpkYXRhID0gKGxvbmcpIHRtcDsKIAlyZXR1cm4gKHJ2YWwp OwpAQCAtNTA5LDUxICs1OTMsOTAgQEAKIGludAogZ2V0ZW52X3Vsb25nKGNvbnN0IGNoYXIgKm5h bWUsIHVuc2lnbmVkIGxvbmcgKmRhdGEpCiB7Ci0JcXVhZF90IHRtcDsKKwlpbnRtYXhfdCB0bXA7 CiAJaW50IHJ2YWw7CiAKLQlydmFsID0gZ2V0ZW52X3F1YWQobmFtZSwgJnRtcCk7CisJcnZhbCA9 IGdldGVudl91bnNpZ25lZChuYW1lLCAmdG1wLCAwLCBVTE9OR19NQVgpOwogCWlmIChydmFsKQog CQkqZGF0YSA9ICh1bnNpZ25lZCBsb25nKSB0bXA7CiAJcmV0dXJuIChydmFsKTsKIH0KIAogLyoK KyAqIFJldHVybiBhIHBvaW50ZXIgZnJvbSBhbiBlbnZpcm9ubWVudCB2YXJpYWJsZS4KKyAqLwor aW50CitnZXRlbnZfcG9pbnRlcihjb25zdCBjaGFyICpuYW1lLCB1aW50cHRyX3QgKmRhdGEpCit7 CisJaW50bWF4X3QgdG1wOworCWludCBydmFsOworCisJcnZhbCA9IGdldGVudl91bnNpZ25lZChu YW1lLCAmdG1wLCAwLCBVSU5UUFRSX01BWCk7CisJaWYgKHJ2YWwpCisJCSpkYXRhID0gKHVpbnRw dHJfdCkgdG1wOworCXJldHVybiAocnZhbCk7Cit9CisKKy8qCiAgKiBSZXR1cm4gYSBxdWFkX3Qg dmFsdWUgZnJvbSBhbiBlbnZpcm9ubWVudCB2YXJpYWJsZS4KICAqLwogaW50CiBnZXRlbnZfcXVh ZChjb25zdCBjaGFyICpuYW1lLCBxdWFkX3QgKmRhdGEpCiB7Ci0JY2hhcgkqdmFsdWU7Ci0JY2hh cgkqdnRwOwotCXF1YWRfdAlpdjsKKwlpbnRtYXhfdCB0bXA7CisJaW50IHJ2YWw7CiAKLQl2YWx1 ZSA9IGdldGVudihuYW1lKTsKLQlpZiAodmFsdWUgPT0gTlVMTCkKKwlydmFsID0gZ2V0ZW52X3Np Z25lZChuYW1lLCAmdG1wLCBRVUFEX01JTiwgUVVBRF9NQVgpOworCWlmIChydmFsKQorCQkqZGF0 YSA9IChxdWFkX3QpIHRtcDsKKwlyZXR1cm4gKHJ2YWwpOworfQorCisvKgorICogUmV0dXJuIGEg dXF1YWRfdCB2YWx1ZSBmcm9tIGFuIGVudmlyb25tZW50IHZhcmlhYmxlLgorICovCitpbnQKK2dl dGVudl91cXVhZChjb25zdCBjaGFyICpuYW1lLCB1cXVhZF90ICpkYXRhKQoreworCWludG1heF90 IHRtcDsKKwlpbnQgcnZhbDsKKworCXJ2YWwgPSBnZXRlbnZfdW5zaWduZWQobmFtZSwgJnRtcCwg MCwgVVFVQURfTUFYKTsKKwlpZiAocnZhbCkKKwkJKmRhdGEgPSAodXF1YWRfdCkgdG1wOworCXJl dHVybiAocnZhbCk7Cit9CisKKy8qCisgKiBSZXR1cm4gYSBzaXplX3QgdmFsdWUgZnJvbSBhbiBl bnZpcm9ubWVudCB2YXJpYWJsZS4KKyAqLworaW50CitnZXRlbnZfc2l6ZShjb25zdCBjaGFyICpu YW1lLCBzaXplX3QgKmRhdGEpCit7CisJaW50bWF4X3QgdG1wOworCWludCBydmFsOworCisJcnZh bCA9IGdldGVudl91bnNpZ25lZChuYW1lLCAmdG1wLCAwLCBTSVpFX01BWCk7CisJaWYgKHJ2YWwp CisJCSpkYXRhID0gKHNpemVfdCkgdG1wOworCXJldHVybiAocnZhbCk7Cit9CisKKy8qCisgKiBS ZXR1cm4gYSBzdHJpbmcgdmFsdWUgZnJvbSBhbiBlbnZpcm9ubWVudCB2YXJpYWJsZS4KKyAqLwor aW50CitnZXRlbnZfc3RyaW5nKGNvbnN0IGNoYXIgKm5hbWUsIGNoYXIgKmRhdGEsIHNpemVfdCBz aXplKQoreworCWNoYXIgKnRtcDsKKworCXRtcCA9IGdldGVudihuYW1lKTsKKwlpZiAodG1wICE9 IE5VTEwpIHsKKwkJc3RybGNweShkYXRhLCB0bXAsIHNpemUpOworCQlmcmVlZW52KHRtcCk7CisJ CXJldHVybiAoMSk7CisJfSBlbHNlCiAJCXJldHVybiAoMCk7Ci0JaXYgPSBzdHJ0b3EodmFsdWUs ICZ2dHAsIDApOwotCWlmICh2dHAgPT0gdmFsdWUgfHwgKHZ0cFswXSAhPSAnXDAnICYmIHZ0cFsx XSAhPSAnXDAnKSkgewotCQlmcmVlZW52KHZhbHVlKTsKLQkJcmV0dXJuICgwKTsKLQl9Ci0Jc3dp dGNoICh2dHBbMF0pIHsKLQljYXNlICd0JzogY2FzZSAnVCc6Ci0JCWl2ICo9IDEwMjQ7Ci0JY2Fz ZSAnZyc6IGNhc2UgJ0cnOgotCQlpdiAqPSAxMDI0OwotCWNhc2UgJ20nOiBjYXNlICdNJzoKLQkJ aXYgKj0gMTAyNDsKLQljYXNlICdrJzogY2FzZSAnSyc6Ci0JCWl2ICo9IDEwMjQ7Ci0JY2FzZSAn XDAnOgotCQlicmVhazsKLQlkZWZhdWx0OgotCQlmcmVlZW52KHZhbHVlKTsKLQkJcmV0dXJuICgw KTsKLQl9Ci0JKmRhdGEgPSBpdjsKLQlmcmVlZW52KHZhbHVlKTsKLQlyZXR1cm4gKDEpOwogfQog CiAvKgpAQCAtNTgzLDYgKzcwNiwxNCBAQAogfQogCiB2b2lkCit0dW5hYmxlX3VpbnRfaW5pdCh2 b2lkICpkYXRhKQoreworCXN0cnVjdCB0dW5hYmxlX3VpbnQgKmQgPSAoc3RydWN0IHR1bmFibGVf dWludCAqKWRhdGE7CisKKwlUVU5BQkxFX1VJTlRfRkVUQ0goZC0+cGF0aCwgZC0+dmFyKTsKK30K Kwordm9pZAogdHVuYWJsZV9sb25nX2luaXQodm9pZCAqZGF0YSkKIHsKIAlzdHJ1Y3QgdHVuYWJs ZV9sb25nICpkID0gKHN0cnVjdCB0dW5hYmxlX2xvbmcgKilkYXRhOwpAQCAtNTk5LDYgKzczMCwx NCBAQAogfQogCiB2b2lkCit0dW5hYmxlX3BvaW50ZXJfaW5pdCh2b2lkICpkYXRhKQoreworCXN0 cnVjdCB0dW5hYmxlX3BvaW50ZXIgKmQgPSAoc3RydWN0IHR1bmFibGVfcG9pbnRlciAqKWRhdGE7 CisKKwlUVU5BQkxFX1BPSU5URVJfRkVUQ0goZC0+cGF0aCwgZC0+dmFyKTsKK30KKwordm9pZAog dHVuYWJsZV9xdWFkX2luaXQodm9pZCAqZGF0YSkKIHsKIAlzdHJ1Y3QgdHVuYWJsZV9xdWFkICpk ID0gKHN0cnVjdCB0dW5hYmxlX3F1YWQgKilkYXRhOwpAQCAtNjA3LDYgKzc0NiwyMiBAQAogfQog CiB2b2lkCit0dW5hYmxlX3VxdWFkX2luaXQodm9pZCAqZGF0YSkKK3sKKwlzdHJ1Y3QgdHVuYWJs ZV91cXVhZCAqZCA9IChzdHJ1Y3QgdHVuYWJsZV91cXVhZCAqKWRhdGE7CisKKwlUVU5BQkxFX1VR VUFEX0ZFVENIKGQtPnBhdGgsIGQtPnZhcik7Cit9CisKK3ZvaWQKK3R1bmFibGVfc2l6ZV9pbml0 KHZvaWQgKmRhdGEpCit7CisJc3RydWN0IHR1bmFibGVfc2l6ZSAqZCA9IChzdHJ1Y3QgdHVuYWJs ZV9zaXplICopZGF0YTsKKworCVRVTkFCTEVfU0laRV9GRVRDSChkLT5wYXRoLCBkLT52YXIpOwor fQorCit2b2lkCiB0dW5hYmxlX3N0cl9pbml0KHZvaWQgKmRhdGEpCiB7CiAJc3RydWN0IHR1bmFi bGVfc3RyICpkID0gKHN0cnVjdCB0dW5hYmxlX3N0ciAqKWRhdGE7CkluZGV4OiBzeXMvc3lzL2tl cm5lbC5oCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9zeXMva2VybmVsLmgJKHJldmlzaW9uIDIxNDI1OCkK KysrIHN5cy9zeXMva2VybmVsLmgJKHdvcmtpbmcgY29weSkKQEAgLTI3NSw3ICsyNzUsOSBAQAog CiAvKgogICogaW50Ci0gKiBwbGVhc2UgYXZvaWQgdXNpbmcgZm9yIG5ldyB0dW5hYmxlcyEKKyAq CisgKiBQbGVhc2UgZG8gbm90IHVzZSBmb3IgYWRkcmVzc2VzIG9yIHBvaW50ZXJzICh1c2UgdGhl IHBvaW50ZXIgdHVuYWJsZQorICogaW5zdGVhZCksIG9yIHNpemVzICh1c2UgdGhlIHNpemUgdHVu YWJsZSBpbnN0ZWFkKS4KICAqLwogZXh0ZXJuIHZvaWQgdHVuYWJsZV9pbnRfaW5pdCh2b2lkICop Owogc3RydWN0IHR1bmFibGVfaW50IHsKQEAgLTI5NCw2ICsyOTYsMjggQEAKICNkZWZpbmUJVFVO QUJMRV9JTlRfRkVUQ0gocGF0aCwgdmFyKQlnZXRlbnZfaW50KChwYXRoKSwgKHZhcikpCiAKIC8q CisgKiB1bnNpZ25lZCBpbnQKKyAqCisgKiBQbGVhc2UgZG8gbm90IHVzZSBmb3IgYWRkcmVzc2Vz IG9yIHBvaW50ZXJzICh1c2UgdGhlIHBvaW50ZXIgdHVuYWJsZQorICogaW5zdGVhZCksIG9yIHNp emVzICh1c2UgdGhlIHNpemUgdHVuYWJsZSBpbnN0ZWFkKS4KKyAqLworZXh0ZXJuIHZvaWQgdHVu YWJsZV91aW50X2luaXQodm9pZCAqKTsKK3N0cnVjdCB0dW5hYmxlX3VpbnQgeworCWNvbnN0IGNo YXIgKnBhdGg7CisJdW5zaWduZWQgaW50ICp2YXI7Cit9OworI2RlZmluZQlUVU5BQkxFX1VJTlQo cGF0aCwgdmFyKQkJCQkJXAorCXN0YXRpYyBzdHJ1Y3QgdHVuYWJsZV91aW50IF9fQ09OQ0FUKF9f dHVuYWJsZV91aW50XywgX19MSU5FX18pID0geyBcCisJCShwYXRoKSwJCQkJCQlcCisJCSh2YXIp LAkJCQkJCVwKKwl9OwkJCQkJCQlcCisJU1lTSU5JVChfX0NPTkNBVChfX1R1bmFibGVfaW5pdF8s IF9fTElORV9fKSwJCVwKKwkgICAgU0lfU1VCX1RVTkFCTEVTLCBTSV9PUkRFUl9NSURETEUsIHR1 bmFibGVfdWludF9pbml0LCBcCisJICAgICZfX0NPTkNBVChfX3R1bmFibGVfdWludF8sIF9fTElO RV9fKSkKKworI2RlZmluZQlUVU5BQkxFX1VJTlRfRkVUQ0gocGF0aCwgdmFyKQlnZXRlbnZfdWlu dCgocGF0aCksICh2YXIpKQorCisvKgogICogbG9uZwogICovCiBleHRlcm4gdm9pZCB0dW5hYmxl X2xvbmdfaW5pdCh2b2lkICopOwpAQCAtMzMyLDggKzM1NiwyOCBAQAogI2RlZmluZQlUVU5BQkxF X1VMT05HX0ZFVENIKHBhdGgsIHZhcikJZ2V0ZW52X3Vsb25nKChwYXRoKSwgKHZhcikpCiAKIC8q Ci0gKiBxdWFkCisgKiBwb2ludGVyCiAgKi8KK2V4dGVybiB2b2lkIHR1bmFibGVfcG9pbnRlcl9p bml0KHZvaWQgKik7CitzdHJ1Y3QgdHVuYWJsZV9wb2ludGVyIHsKKwljb25zdCBjaGFyICpwYXRo OworCXVpbnRwdHJfdCAqdmFyOworfTsKKyNkZWZpbmUJVFVOQUJMRV9QT0lOVEVSKHBhdGgsIHZh cikJCQkJXAorCXN0YXRpYyBzdHJ1Y3QgdHVuYWJsZV9wb2ludGVyIF9fQ09OQ0FUKF9fdHVuYWJs ZV9wb2ludGVyXywgX19MSU5FX18pID0geyBcCisJCShwYXRoKSwJCQkJCQlcCisJCSh2YXIpLAkJ CQkJCVwKKwl9OwkJCQkJCQlcCisJU1lTSU5JVChfX0NPTkNBVChfX1R1bmFibGVfaW5pdF8sIF9f TElORV9fKSwJCVwKKwkgICAgU0lfU1VCX1RVTkFCTEVTLCBTSV9PUkRFUl9NSURETEUsIHR1bmFi bGVfcG9pbnRlcl9pbml0LCBcCisJICAgICZfX0NPTkNBVChfX3R1bmFibGVfcG9pbnRlcl8sIF9f TElORV9fKSkKKworI2RlZmluZQlUVU5BQkxFX1BPSU5URVJfRkVUQ0gocGF0aCwgdmFyKQkJCVwK KwlnZXRlbnZfcG9pbnRlcigocGF0aCksICh2YXIpKQorCisvKgorICogcXVhZF90CisgKi8KIGV4 dGVybiB2b2lkIHR1bmFibGVfcXVhZF9pbml0KHZvaWQgKik7CiBzdHJ1Y3QgdHVuYWJsZV9xdWFk IHsKIAljb25zdCBjaGFyICpwYXRoOwpAQCAtMzUwLDYgKzM5NCwyOCBAQAogCiAjZGVmaW5lCVRV TkFCTEVfUVVBRF9GRVRDSChwYXRoLCB2YXIpCWdldGVudl9xdWFkKChwYXRoKSwgKHZhcikpCiAK Ky8qCisgKiBzaXplX3QKKyAqLworZXh0ZXJuIHZvaWQgdHVuYWJsZV9zaXplX2luaXQodm9pZCAq KTsKK3N0cnVjdCB0dW5hYmxlX3NpemUgeworCWNvbnN0IGNoYXIgKnBhdGg7CisJc2l6ZV90ICp2 YXI7Cit9OworI2RlZmluZQlUVU5BQkxFX1NJWkUocGF0aCwgdmFyKQkJCQkJXAorCXN0YXRpYyBz dHJ1Y3QgdHVuYWJsZV9zaXplIF9fQ09OQ0FUKF9fdHVuYWJsZV9zaXplXywgX19MSU5FX18pID0g eyBcCisJCShwYXRoKSwJCQkJCQlcCisJCSh2YXIpLAkJCQkJCVwKKwl9OwkJCQkJCQlcCisJU1lT SU5JVChfX0NPTkNBVChfX1R1bmFibGVfaW5pdF8sIF9fTElORV9fKSwJCVwKKwkgICAgU0lfU1VC X1RVTkFCTEVTLCBTSV9PUkRFUl9NSURETEUsIHR1bmFibGVfc2l6ZV9pbml0LCBcCisJICAgICZf X0NPTkNBVChfX3R1bmFibGVfc2l6ZV8sIF9fTElORV9fKSkKKworI2RlZmluZQlUVU5BQkxFX1NJ WkVfRkVUQ0gocGF0aCwgdmFyKQlnZXRlbnZfc2l6ZSgocGF0aCksICh2YXIpKQorCisvKgorICog c3RyaW5ncworICovCiBleHRlcm4gdm9pZCB0dW5hYmxlX3N0cl9pbml0KHZvaWQgKik7CiBzdHJ1 Y3QgdHVuYWJsZV9zdHIgewogCWNvbnN0IGNoYXIgKnBhdGg7CkBAIC0zNjksNiArNDM1LDI1IEBA CiAjZGVmaW5lCVRVTkFCTEVfU1RSX0ZFVENIKHBhdGgsIHZhciwgc2l6ZSkJCQlcCiAJZ2V0ZW52 X3N0cmluZygocGF0aCksICh2YXIpLCAoc2l6ZSkpCiAKKy8qCisgKiB1cXVhZF90CisgKi8KK2V4 dGVybiB2b2lkIHR1bmFibGVfdXF1YWRfaW5pdCh2b2lkICopOworc3RydWN0IHR1bmFibGVfdXF1 YWQgeworCWNvbnN0IGNoYXIgKnBhdGg7CisJdXF1YWRfdCAqdmFyOworfTsKKyNkZWZpbmUJVFVO QUJMRV9VUVVBRChwYXRoLCB2YXIpCQkJCQlcCisJc3RhdGljIHN0cnVjdCB0dW5hYmxlX3VxdWFk IF9fQ09OQ0FUKF9fdHVuYWJsZV91cXVhZF8sIF9fTElORV9fKSA9IHsgXAorCQkocGF0aCksCQkJ CQkJXAorCQkodmFyKSwJCQkJCQlcCisJfTsJCQkJCQkJXAorCVNZU0lOSVQoX19DT05DQVQoX19U dW5hYmxlX2luaXRfLCBfX0xJTkVfXyksCQlcCisJICAgIFNJX1NVQl9UVU5BQkxFUywgU0lfT1JE RVJfTUlERExFLCB0dW5hYmxlX3VxdWFkX2luaXQsIFwKKwkgICAgJl9fQ09OQ0FUKF9fdHVuYWJs ZV91cXVhZF8sIF9fTElORV9fKSkKKworI2RlZmluZQlUVU5BQkxFX1VRVUFEX0ZFVENIKHBhdGgs IHZhcikJZ2V0ZW52X3VxdWFkKChwYXRoKSwgKHZhcikpCisKIHN0cnVjdCBpbnRyX2NvbmZpZ19o b29rIHsKIAlUQUlMUV9FTlRSWShpbnRyX2NvbmZpZ19ob29rKSBpY2hfbGlua3M7CiAJdm9pZAko KmljaF9mdW5jKSh2b2lkICphcmcpOwpJbmRleDogc3lzL3N5cy9wYXJhbS5oCj09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0K LS0tIHN5cy9zeXMvcGFyYW0uaAkocmV2aXNpb24gMjE0MjU4KQorKysgc3lzL3N5cy9wYXJhbS5o CSh3b3JraW5nIGNvcHkpCkBAIC01OCw3ICs1OCw3IEBACiAgKgkJaW4gdGhlIHJhbmdlIDUgdG8g OS4KICAqLwogI3VuZGVmIF9fRnJlZUJTRF92ZXJzaW9uCi0jZGVmaW5lIF9fRnJlZUJTRF92ZXJz aW9uIDkwMDAyMwkvKiBNYXN0ZXIsIHByb3BhZ2F0ZWQgdG8gbmV3dmVycyAqLworI2RlZmluZSBf X0ZyZWVCU0RfdmVyc2lvbiA5MDAwMjQJLyogTWFzdGVyLCBwcm9wYWdhdGVkIHRvIG5ld3ZlcnMg Ki8KIAogI2lmbmRlZiBMT0NPUkUKICNpbmNsdWRlIDxzeXMvdHlwZXMuaD4KSW5kZXg6IHN5cy9z eXMvc3lzdG0uaAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvc3lzL3N5c3RtLmgJKHJldmlzaW9uIDIxNDI1 OCkKKysrIHN5cy9zeXMvc3lzdG0uaAkod29ya2luZyBjb3B5KQpAQCAtMjYwLDEyICsyNjAsMjAg QEAKIAogY2hhcgkqZ2V0ZW52KGNvbnN0IGNoYXIgKm5hbWUpOwogdm9pZAlmcmVlZW52KGNoYXIg KmVudik7Cit1aW50bWF4X3QgZ2V0ZW52X3BhcnNlX3N1ZmZpeChjb25zdCBjaGFyIHN1ZmZpeCk7 CitpbnQJZ2V0ZW52X3NpZ25lZChjb25zdCBjaGFyICpuYW1lLCBpbnRtYXhfdCAqZGF0YSwgY29u c3QgaW50bWF4X3QgbWluLAorCSAgICBjb25zdCBpbnRtYXhfdCBtYXgpOworaW50CWdldGVudl91 bnNpZ25lZChjb25zdCBjaGFyICpuYW1lLCB1aW50bWF4X3QgKmRhdGEsCisJICAgIGNvbnN0IHVp bnRtYXhfdCBtaW4sIGNvbnN0IHVpbnRtYXhfdCBtYXgpOwogaW50CWdldGVudl9pbnQoY29uc3Qg Y2hhciAqbmFtZSwgaW50ICpkYXRhKTsKIGludAlnZXRlbnZfdWludChjb25zdCBjaGFyICpuYW1l LCB1bnNpZ25lZCBpbnQgKmRhdGEpOwogaW50CWdldGVudl9sb25nKGNvbnN0IGNoYXIgKm5hbWUs IGxvbmcgKmRhdGEpOwogaW50CWdldGVudl91bG9uZyhjb25zdCBjaGFyICpuYW1lLCB1bnNpZ25l ZCBsb25nICpkYXRhKTsKLWludAlnZXRlbnZfc3RyaW5nKGNvbnN0IGNoYXIgKm5hbWUsIGNoYXIg KmRhdGEsIGludCBzaXplKTsKK2ludAlnZXRlbnZfcG9pbnRlcihjb25zdCBjaGFyICpuYW1lLCB1 aW50cHRyX3QgKmRhdGEpOwogaW50CWdldGVudl9xdWFkKGNvbnN0IGNoYXIgKm5hbWUsIHF1YWRf dCAqZGF0YSk7CitpbnQJZ2V0ZW52X3VxdWFkKGNvbnN0IGNoYXIgKm5hbWUsIHVxdWFkX3QgKmRh dGEpOworaW50CWdldGVudl9zaXplKGNvbnN0IGNoYXIgKm5hbWUsIHNpemVfdCAqZGF0YSk7Citp bnQJZ2V0ZW52X3N0cmluZyhjb25zdCBjaGFyICpuYW1lLCBjaGFyICpkYXRhLCBzaXplX3Qgc2l6 ZSk7CiBpbnQJc2V0ZW52KGNvbnN0IGNoYXIgKm5hbWUsIGNvbnN0IGNoYXIgKnZhbHVlKTsKIGlu dAl1bnNldGVudihjb25zdCBjaGFyICpuYW1lKTsKIGludAl0ZXN0ZW52KGNvbnN0IGNoYXIgKm5h bWUpOwpJbmRleDogdG9vbHMvcmVncmVzc2lvbi90dW5hYmxlcy91cXVhZC90ZXN0X3VxdWFkX3R1 bmFibGUuc2gKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PQotLS0gdG9vbHMvcmVncmVzc2lvbi90dW5hYmxlcy91cXVhZC90 ZXN0X3VxdWFkX3R1bmFibGUuc2gJKHJldmlzaW9uIDApCisrKyB0b29scy9yZWdyZXNzaW9uL3R1 bmFibGVzL3VxdWFkL3Rlc3RfdXF1YWRfdHVuYWJsZS5zaAkocmV2aXNpb24gMCkKQEAgLTAsMCAr MSwzOCBAQAorIyEvYmluL3NoCisjCisjIEV4cGVjdGVkIHZhbHVlczoKKyMgKHVuc2V0KSAgICA6 ICAgICAgICAgICAwCisjICAgICAgLTEgICAgOiAgIFVMT05HX01BWAorIyAgICAgICAwICAgIDog ICAgICAgICAgIDAKKyMgICAgICA0MiAgICA6ICAgICAgICAgIDQyCisjIGFzZGYxMjM0ICAgOiAg ICAgICAgICAgMCAocmVqZWN0KQorIyBMT05HX01BWCsxIDogIExPTkdfTUFYKzEKKyMgVUxPTkdf TUFYLTE6IFVMT05HX01BWC0xCisjIFVMT05HX01BWCsxOiAgIFVMT05HX01BWAorIworCitNT0RO QU1FPSIkKGJhc2VuYW1lICIkMCIgLnNoKSIKKwordGVzdF9tb2R1bGUoKSB7CisJa2xkbG9hZCAu LyRNT0ROQU1FLmtvCisJa2xkdW5sb2FkIC4vJE1PRE5BTUUua28KK30KKworY2FzZSAiJCgkKGRp cm5hbWUgIiQwIikvLi4vdG9vbHMvZ2V0d29yZHNpemUpIiBpbgorMzIpCisJTE9OR19NQVhfUExV U18xPTIxNDc0ODM2NDkKKwlVTE9OR19NQVhfTUlOVVNfMT00Mjk0OTY3Mjk1CisJVUxPTkdfTUFY X1BMVVNfMT00Mjk0OTY3Mjk3CisJOzsKKzY0KQorCUxPTkdfTUFYX1BMVVNfMT05MjIzMzcyMDM2 ODU0Nzc1ODA4CisJVUxPTkdfTUFYX01JTlVTXzE9MTg0NDY3NDQwNzM3MDk1NTE2MTQKKwlVTE9O R19NQVhfUExVU18xPTE4NDQ2NzQ0MDczNzA5NTUxNjE2CisJOzsKK2VzYWMKK2tlbnYgLXUgJE1P RE5BTUUudHVuYWJsZSAyPi9kZXYvbnVsbAordGVzdF9tb2R1bGUKK2ZvciBpIGluIC0xIDAgNDIg YXNkZjEyMzQgJExPTkdfTUFYX1BMVVNfMSAkVUxPTkdfTUFYX01JTlVTXzEgJFVMT05HX01BWF9Q TFVTXzE7IGRvCisJa2VudiAkTU9ETkFNRS50dW5hYmxlPSIkaSIKKwl0ZXN0X21vZHVsZQorZG9u ZQpJbmRleDogdG9vbHMvcmVncmVzc2lvbi90dW5hYmxlcy91cXVhZC90ZXN0X3VxdWFkX3R1bmFi bGUuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09Ci0tLSB0b29scy9yZWdyZXNzaW9uL3R1bmFibGVzL3VxdWFkL3Rlc3Rf dXF1YWRfdHVuYWJsZS5jCShyZXZpc2lvbiAwKQorKysgdG9vbHMvcmVncmVzc2lvbi90dW5hYmxl cy91cXVhZC90ZXN0X3VxdWFkX3R1bmFibGUuYwkocmV2aXNpb24gMCkKQEAgLTAsMCArMSwzMSBA QAorI2luY2x1ZGUgPHN5cy9wYXJhbS5oPgorI2luY2x1ZGUgPHN5cy90eXBlcy5oPgorI2luY2x1 ZGUgPHN5cy9wcm9jLmg+CisjaW5jbHVkZSA8c3lzL21vZHVsZS5oPgorI2luY2x1ZGUgPHN5cy9r ZXJuZWwuaD4KKyNpbmNsdWRlIDxzeXMvc3lzdG0uaD4KKworI2RlZmluZSBNT0RVTEVfTkFNRQki dGVzdF91cXVhZF90dW5hYmxlIgorCitzdGF0aWMgdXF1YWRfdCB0dW5hYmxlID0gMDsKKworVFVO QUJMRV9VUVVBRCgidGVzdF91cXVhZF90dW5hYmxlLnR1bmFibGUiLCAmdHVuYWJsZSk7CisKK3N0 YXRpYyBpbnQKK2xvYWQgKG1vZHVsZV90IG0sIGludCB3aGF0LCB2b2lkICphcmcpCit7CisJc3dp dGNoICh3aGF0KSB7CisJY2FzZSBNT0RfTE9BRDoKKwkJcHJpbnRmKCIlczogJWx1XG4iLCBNT0RV TEVfTkFNRSwgdHVuYWJsZSk7CisJCWJyZWFrOworCX0KKwlyZXR1cm4gKDApOworfQorCitzdGF0 aWMgbW9kdWxlZGF0YV90IHRlc3RfdXF1YWRfdHVuYWJsZV9tb2QgPSB7CisJTU9EVUxFX05BTUUs CisJbG9hZCwKK307CitERUNMQVJFX01PRFVMRSh0ZXN0X3VxdWFkX3R1bmFibGUsIHRlc3RfdXF1 YWRfdHVuYWJsZV9tb2QsIFNJX1NVQl9LTEQsCisgICAgU0lfT1JERVJfQU5ZKTsKK01PRFVMRV9W RVJTSU9OKHRlc3RfdXF1YWRfdHVuYWJsZSwgMSk7CkluZGV4OiB0b29scy9yZWdyZXNzaW9uL3R1 bmFibGVzL3VxdWFkL01ha2VmaWxlCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHRvb2xzL3JlZ3Jlc3Npb24vdHVu YWJsZXMvdXF1YWQvTWFrZWZpbGUJKHJldmlzaW9uIDApCisrKyB0b29scy9yZWdyZXNzaW9uL3R1 bmFibGVzL3VxdWFkL01ha2VmaWxlCShyZXZpc2lvbiAwKQpAQCAtMCwwICsxLDQgQEAKK0tNT0Q9 CXRlc3RfdXF1YWRfdHVuYWJsZQorU1JDUz0JdGVzdF91cXVhZF90dW5hYmxlLmMKKworLmluY2x1 ZGUgPGJzZC5rbW9kLm1rPgpJbmRleDogdG9vbHMvcmVncmVzc2lvbi90dW5hYmxlcy91aW50L3Rl c3RfdWludF90dW5hYmxlLnNoCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHRvb2xzL3JlZ3Jlc3Npb24vdHVuYWJs ZXMvdWludC90ZXN0X3VpbnRfdHVuYWJsZS5zaAkocmV2aXNpb24gMCkKKysrIHRvb2xzL3JlZ3Jl c3Npb24vdHVuYWJsZXMvdWludC90ZXN0X3VpbnRfdHVuYWJsZS5zaAkocmV2aXNpb24gMCkKQEAg LTAsMCArMSwyOSBAQAorIyEvYmluL3NoCisjCisjIEV4cGVjdGVkIHZhbHVlczoKKyMgKHVuc2V0 KSAgIDogICAgICAgICAgMAorIyAgICAgIC0xICAgOiAgICAgICAgICAwIChyZWplY3QpIAorIyAg ICAgICAwICAgOiAgICAgICAgICAwCisjICAgICAgNDIgICA6ICAgICAgICAgNDIKKyMgYXNkZjEy MzQgIDogICAgICAgICAgMCAocmVqZWN0KQorIyBJTlRfTUFYKzEgOiAgSU5UX01BWCsxCisjIFVJ TlRfTUFYLTE6IFVJTlRfTUFYLTEKKyMgVUlOVF9NQVgrMTogICAgICAgICAgMCAocmVqZWN0KQor IworCitNT0ROQU1FPSIkKGJhc2VuYW1lICIkMCIgLnNoKSIKKwordGVzdF9tb2R1bGUoKSB7CisJ a2xkbG9hZCAuLyRNT0ROQU1FLmtvCisJa2xkdW5sb2FkIC4vJE1PRE5BTUUua28KK30KKworSU5U X01BWF9QTFVTX09ORT0yMTQ3NDgzNjQ4CitVSU5UX01BWF9NSU5VU19PTkU9NDI5NDk2NzI5NAor VUlOVF9NQVhfUExVU19PTkU9NDI5NDk2NzI5Ngora2VudiAtdSAkTU9ETkFNRS50dW5hYmxlIDI+ L2Rldi9udWxsCit0ZXN0X21vZHVsZQorZm9yIGkgaW4gLTEgMCA0MiBhc2RmMTIzNCAkSU5UX01B WF9QTFVTX09ORSAkVUlOVF9NQVhfTUlOVVNfT05FICRVSU5UX01BWF9QTFVTX09ORTsgZG8KKwlr ZW52ICRNT0ROQU1FLnR1bmFibGU9IiRpIgorCXRlc3RfbW9kdWxlCitkb25lCkluZGV4OiB0b29s cy9yZWdyZXNzaW9uL3R1bmFibGVzL3VpbnQvdGVzdF91aW50X3R1bmFibGUuYwo9PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 Ci0tLSB0b29scy9yZWdyZXNzaW9uL3R1bmFibGVzL3VpbnQvdGVzdF91aW50X3R1bmFibGUuYwko cmV2aXNpb24gMCkKKysrIHRvb2xzL3JlZ3Jlc3Npb24vdHVuYWJsZXMvdWludC90ZXN0X3VpbnRf dHVuYWJsZS5jCShyZXZpc2lvbiAwKQpAQCAtMCwwICsxLDMxIEBACisjaW5jbHVkZSA8c3lzL3Bh cmFtLmg+CisjaW5jbHVkZSA8c3lzL3R5cGVzLmg+CisjaW5jbHVkZSA8c3lzL3Byb2MuaD4KKyNp bmNsdWRlIDxzeXMvbW9kdWxlLmg+CisjaW5jbHVkZSA8c3lzL2tlcm5lbC5oPgorI2luY2x1ZGUg PHN5cy9zeXN0bS5oPgorCisjZGVmaW5lIE1PRFVMRV9OQU1FCSJ0ZXN0X3VpbnRfdHVuYWJsZSIK Kworc3RhdGljIHVuc2lnbmVkIGludCB0dW5hYmxlID0gMDsKKworVFVOQUJMRV9VSU5UKCJ0ZXN0 X3VpbnRfdHVuYWJsZS50dW5hYmxlIiwgJnR1bmFibGUpOworCitzdGF0aWMgaW50Citsb2FkICht b2R1bGVfdCBtLCBpbnQgd2hhdCwgdm9pZCAqYXJnKQoreworCXN3aXRjaCAod2hhdCkgeworCWNh c2UgTU9EX0xPQUQ6CisJCXByaW50ZigiJXM6ICV1XG4iLCBNT0RVTEVfTkFNRSwgdHVuYWJsZSk7 CisJCWJyZWFrOworCX0KKwlyZXR1cm4gKDApOworfQorCitzdGF0aWMgbW9kdWxlZGF0YV90IHRl c3RfdWludF90dW5hYmxlX21vZCA9IHsKKwlNT0RVTEVfTkFNRSwKKwlsb2FkLAorfTsKK0RFQ0xB UkVfTU9EVUxFKHRlc3RfdWludF90dW5hYmxlLCB0ZXN0X3VpbnRfdHVuYWJsZV9tb2QsIFNJX1NV Ql9LTEQsCisgICAgU0lfT1JERVJfQU5ZKTsKK01PRFVMRV9WRVJTSU9OKHRlc3RfdWludF90dW5h YmxlLCAxKTsKSW5kZXg6IHRvb2xzL3JlZ3Jlc3Npb24vdHVuYWJsZXMvdWludC9NYWtlZmlsZQo9 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09Ci0tLSB0b29scy9yZWdyZXNzaW9uL3R1bmFibGVzL3VpbnQvTWFrZWZpbGUJKHJl dmlzaW9uIDApCisrKyB0b29scy9yZWdyZXNzaW9uL3R1bmFibGVzL3VpbnQvTWFrZWZpbGUJKHJl dmlzaW9uIDApCkBAIC0wLDAgKzEsNCBAQAorS01PRD0JdGVzdF91aW50X3R1bmFibGUKK1NSQ1M9 CXRlc3RfdWludF90dW5hYmxlLmMKKworLmluY2x1ZGUgPGJzZC5rbW9kLm1rPgpJbmRleDogdG9v bHMvcmVncmVzc2lvbi90dW5hYmxlcy90b29scy9nZXR3b3Jkc2l6ZS5jCj09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0t IHRvb2xzL3JlZ3Jlc3Npb24vdHVuYWJsZXMvdG9vbHMvZ2V0d29yZHNpemUuYwkocmV2aXNpb24g MCkKKysrIHRvb2xzL3JlZ3Jlc3Npb24vdHVuYWJsZXMvdG9vbHMvZ2V0d29yZHNpemUuYwkocmV2 aXNpb24gMCkKQEAgLTAsMCArMSw5IEBACisjaW5jbHVkZSA8c3lzL2VsZi5oPgorI2luY2x1ZGUg PHN0ZGlvLmg+CisKK2ludAorbWFpbih2b2lkKQoreworCXByaW50ZigiJWRcbiIsIF9fRUxGX1dP UkRfU0laRSk7CisJcmV0dXJuICgwKTsKK30KSW5kZXg6IHRvb2xzL3JlZ3Jlc3Npb24vdHVuYWJs ZXMvdG9vbHMvTWFrZWZpbGUKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gdG9vbHMvcmVncmVzc2lvbi90dW5hYmxl cy90b29scy9NYWtlZmlsZQkocmV2aXNpb24gMCkKKysrIHRvb2xzL3JlZ3Jlc3Npb24vdHVuYWJs ZXMvdG9vbHMvTWFrZWZpbGUJKHJldmlzaW9uIDApCkBAIC0wLDAgKzEsNyBAQAorUFJPRz0JCWdl dHdvcmRzaXplCisKK1NSQ1M9CQlnZXR3b3Jkc2l6ZS5jCisKK05PX01BTj0JCTEKKworLmluY2x1 ZGUgPGJzZC5wcm9nLm1rPgpJbmRleDogdG9vbHMvcmVncmVzc2lvbi90dW5hYmxlcy91bG9uZy90 ZXN0X3Vsb25nX3R1bmFibGUuc2gKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gdG9vbHMvcmVncmVzc2lvbi90dW5h Ymxlcy91bG9uZy90ZXN0X3Vsb25nX3R1bmFibGUuc2gJKHJldmlzaW9uIDApCisrKyB0b29scy9y ZWdyZXNzaW9uL3R1bmFibGVzL3Vsb25nL3Rlc3RfdWxvbmdfdHVuYWJsZS5zaAkocmV2aXNpb24g MCkKQEAgLTAsMCArMSwzOCBAQAorIyEvYmluL3NoCisjCisjIEV4cGVjdGVkIHZhbHVlczoKKyMg KHVuc2V0KSAgICA6ICAgICAgICAgICAwCisjICAgICAgLTEgICAgOiAgIFVMT05HX01BWAorIyAg ICAgICAwICAgIDogICAgICAgICAgIDAKKyMgICAgICA0MiAgICA6ICAgICAgICAgIDQyCisjIGFz ZGYxMjM0ICAgOiAgICAgICAgICAgMCAocmVqZWN0KQorIyBMT05HX01BWCsxIDogIExPTkdfTUFY KzEKKyMgVUxPTkdfTUFYLTE6IFVMT05HX01BWC0xCisjIFVMT05HX01BWCsxOiAgIFVMT05HX01B WAorIworCitNT0ROQU1FPSIkKGJhc2VuYW1lICIkMCIgLnNoKSIKKwordGVzdF9tb2R1bGUoKSB7 CisJa2xkbG9hZCAuLyRNT0ROQU1FLmtvCisJa2xkdW5sb2FkIC4vJE1PRE5BTUUua28KK30KKwor Y2FzZSAiJCgkKGRpcm5hbWUgIiQwIikvLi4vdG9vbHMvZ2V0d29yZHNpemUpIiBpbgorMzIpCisJ TE9OR19NQVhfUExVU18xPTIxNDc0ODM2NDkKKwlVTE9OR19NQVhfTUlOVVNfMT00Mjk0OTY3Mjk1 CisJVUxPTkdfTUFYX1BMVVNfMT00Mjk0OTY3Mjk3CisJOzsKKzY0KQorCUxPTkdfTUFYX1BMVVNf MT05MjIzMzcyMDM2ODU0Nzc1ODA4CisJVUxPTkdfTUFYX01JTlVTXzE9MTg0NDY3NDQwNzM3MDk1 NTE2MTQKKwlVTE9OR19NQVhfUExVU18xPTE4NDQ2NzQ0MDczNzA5NTUxNjE2CisJOzsKK2VzYWMK K2tlbnYgLXUgJE1PRE5BTUUudHVuYWJsZSAyPi9kZXYvbnVsbAordGVzdF9tb2R1bGUKK2ZvciBp IGluIC0xIDAgNDIgYXNkZjEyMzQgJExPTkdfTUFYX1BMVVNfMSAkVUxPTkdfTUFYX01JTlVTXzEg JFVMT05HX01BWF9QTFVTXzE7IGRvCisJa2VudiAkTU9ETkFNRS50dW5hYmxlPSIkaSIKKwl0ZXN0 X21vZHVsZQorZG9uZQpJbmRleDogdG9vbHMvcmVncmVzc2lvbi90dW5hYmxlcy91bG9uZy9NYWtl ZmlsZQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09Ci0tLSB0b29scy9yZWdyZXNzaW9uL3R1bmFibGVzL3Vsb25nL01ha2Vm aWxlCShyZXZpc2lvbiAwKQorKysgdG9vbHMvcmVncmVzc2lvbi90dW5hYmxlcy91bG9uZy9NYWtl ZmlsZQkocmV2aXNpb24gMCkKQEAgLTAsMCArMSw0IEBACitLTU9EPQl0ZXN0X3Vsb25nX3R1bmFi bGUKK1NSQ1M9CXRlc3RfdWxvbmdfdHVuYWJsZS5jCisKKy5pbmNsdWRlIDxic2Qua21vZC5taz4K SW5kZXg6IHRvb2xzL3JlZ3Jlc3Npb24vdHVuYWJsZXMvdWxvbmcvdGVzdF91bG9uZ190dW5hYmxl LmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PQotLS0gdG9vbHMvcmVncmVzc2lvbi90dW5hYmxlcy91bG9uZy90ZXN0X3Vs b25nX3R1bmFibGUuYwkocmV2aXNpb24gMCkKKysrIHRvb2xzL3JlZ3Jlc3Npb24vdHVuYWJsZXMv dWxvbmcvdGVzdF91bG9uZ190dW5hYmxlLmMJKHJldmlzaW9uIDApCkBAIC0wLDAgKzEsMzEgQEAK KyNpbmNsdWRlIDxzeXMvcGFyYW0uaD4KKyNpbmNsdWRlIDxzeXMvdHlwZXMuaD4KKyNpbmNsdWRl IDxzeXMvcHJvYy5oPgorI2luY2x1ZGUgPHN5cy9tb2R1bGUuaD4KKyNpbmNsdWRlIDxzeXMva2Vy bmVsLmg+CisjaW5jbHVkZSA8c3lzL3N5c3RtLmg+CisKKyNkZWZpbmUgTU9EVUxFX05BTUUJInRl c3RfdWxvbmdfdHVuYWJsZSIKKworc3RhdGljIHVuc2lnbmVkIGxvbmcgdHVuYWJsZSA9IDA7CisK K1RVTkFCTEVfVUxPTkcoInRlc3RfdWxvbmdfdHVuYWJsZS50dW5hYmxlIiwgJnR1bmFibGUpOwor CitzdGF0aWMgaW50Citsb2FkIChtb2R1bGVfdCBtLCBpbnQgd2hhdCwgdm9pZCAqYXJnKQorewor CXN3aXRjaCAod2hhdCkgeworCWNhc2UgTU9EX0xPQUQ6CisJCXByaW50ZigiJXM6ICVsdVxuIiwg TU9EVUxFX05BTUUsIHR1bmFibGUpOworCQlicmVhazsKKwl9CisJcmV0dXJuICgwKTsKK30KKwor c3RhdGljIG1vZHVsZWRhdGFfdCB0ZXN0X3Vsb25nX3R1bmFibGVfbW9kID0geworCU1PRFVMRV9O QU1FLAorCWxvYWQsCit9OworREVDTEFSRV9NT0RVTEUodGVzdF91bG9uZ190dW5hYmxlLCB0ZXN0 X3Vsb25nX3R1bmFibGVfbW9kLCBTSV9TVUJfS0xELAorICAgIFNJX09SREVSX0FOWSk7CitNT0RV TEVfVkVSU0lPTih0ZXN0X3Vsb25nX3R1bmFibGUsIDEpOwpJbmRleDogdG9vbHMvcmVncmVzc2lv bi90dW5hYmxlcy9zdWZmaXgvdGVzdF90dW5hYmxlX3N1ZmZpeGVzLmMKPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0g dG9vbHMvcmVncmVzc2lvbi90dW5hYmxlcy9zdWZmaXgvdGVzdF90dW5hYmxlX3N1ZmZpeGVzLmMJ KHJldmlzaW9uIDApCisrKyB0b29scy9yZWdyZXNzaW9uL3R1bmFibGVzL3N1ZmZpeC90ZXN0X3R1 bmFibGVfc3VmZml4ZXMuYwkocmV2aXNpb24gMCkKQEAgLTAsMCArMSwzMSBAQAorI2luY2x1ZGUg PHN5cy9wYXJhbS5oPgorI2luY2x1ZGUgPHN5cy90eXBlcy5oPgorI2luY2x1ZGUgPHN5cy9wcm9j Lmg+CisjaW5jbHVkZSA8c3lzL21vZHVsZS5oPgorI2luY2x1ZGUgPHN5cy9rZXJuZWwuaD4KKyNp bmNsdWRlIDxzeXMvc3lzdG0uaD4KKworI2RlZmluZSBNT0RVTEVfTkFNRQkidGVzdF90dW5hYmxl X3N1ZmZpeGVzIgorCitzdGF0aWMgbG9uZyB0dW5hYmxlID0gMDsKKworVFVOQUJMRV9MT05HKCJ0 ZXN0X3R1bmFibGVfc3VmZml4ZXMudHVuYWJsZSIsICZ0dW5hYmxlKTsKKworc3RhdGljIGludAor bG9hZCAoc3RydWN0IG1vZHVsZSAqbSwgaW50IHdoYXQsIHZvaWQgKmFyZykKK3sKKwlzd2l0Y2gg KHdoYXQpIHsKKwljYXNlIE1PRF9MT0FEOgorCQlwcmludGYoIiVzOiAlbGRcbiIsIE1PRFVMRV9O QU1FLCB0dW5hYmxlKTsKKwkJYnJlYWs7CisJfQorCXJldHVybiAoMCk7Cit9CisKK3N0YXRpYyBt b2R1bGVkYXRhX3QgdGVzdF90dW5hYmxlX3N1ZmZpeGVzX21vZCA9IHsKKwlNT0RVTEVfTkFNRSwK Kwlsb2FkLAorfTsKK0RFQ0xBUkVfTU9EVUxFKHRlc3RfdHVuYWJsZV9zdWZmaXhlcywgdGVzdF90 dW5hYmxlX3N1ZmZpeGVzX21vZCwgU0lfU1VCX0tMRCwKKyAgICBTSV9PUkRFUl9BTlkpOworTU9E VUxFX1ZFUlNJT04odGVzdF90dW5hYmxlX3N1ZmZpeGVzLCAxKTsKSW5kZXg6IHRvb2xzL3JlZ3Jl c3Npb24vdHVuYWJsZXMvc3VmZml4L01ha2VmaWxlCj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHRvb2xzL3JlZ3Jl c3Npb24vdHVuYWJsZXMvc3VmZml4L01ha2VmaWxlCShyZXZpc2lvbiAwKQorKysgdG9vbHMvcmVn cmVzc2lvbi90dW5hYmxlcy9zdWZmaXgvTWFrZWZpbGUJKHJldmlzaW9uIDApCkBAIC0wLDAgKzEs NCBAQAorS01PRD0JdGVzdF90dW5hYmxlX3N1ZmZpeGVzCitTUkNTPQl0ZXN0X3R1bmFibGVfc3Vm Zml4ZXMuYworCisuaW5jbHVkZSA8YnNkLmttb2QubWs+CkluZGV4OiB0b29scy9yZWdyZXNzaW9u L3R1bmFibGVzL3N1ZmZpeC90ZXN0X3R1bmFibGVfc3VmZml4ZXMuc2gKPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0g dG9vbHMvcmVncmVzc2lvbi90dW5hYmxlcy9zdWZmaXgvdGVzdF90dW5hYmxlX3N1ZmZpeGVzLnNo CShyZXZpc2lvbiAwKQorKysgdG9vbHMvcmVncmVzc2lvbi90dW5hYmxlcy9zdWZmaXgvdGVzdF90 dW5hYmxlX3N1ZmZpeGVzLnNoCShyZXZpc2lvbiAwKQpAQCAtMCwwICsxLDQxIEBACisjIS9iaW4v c2gKKyMKKyMgRXhwZWN0ZWQgdmFsdWVzOgorIyAodW5zZXQpICAgOiAgICAgICAgICAgMAorIyAg ICAgICAgIC0xOiAgICAgICAgICAtMQorIyAgICAgICAgLTFnOiAgICAgLTEwMjReMworIyAgICAg ICAgLTFHOiAgICAgLTEwMjReMyAoc2FtZSBhcyAxZykgCisjICAgICAgICAtMWs6ICAgICAgIC0x MDI0CisjICAgICAgICAtMUs6ICAgICAgIC0xMDI0IChzYW1lIGFzIDFLKQorIyAgICAgICAgLTFt OiAgICAgLTEwMjReMgorIyAgICAgICAgLTFNOiAgICAgLTEwMjReMiAoc2FtZSBhcyAxbSkKKyMg ICAgICAgIC0xdDogICAgIC0xMDI0XjQKKyMgICAgICAgIC0xVDogICAgIC0xMDI0XjQgKHNhbWUg YXMgMXQpCisjICAgICAgICAtMXo6ICAgICAgICAgICAwIChyZWplY3QpCisjICAgICAgICAgIDE6 ICAgICAgICAgICAxCisjICAgICAgICAgMWc6ICAgICAgMTAyNF4zCisjICAgICAgICAgMUc6ICAg ICAgMTAyNF4zIChzYW1lIGFzIDFnKSAKKyMgICAgICAgICAxazogICAgICAgIDEwMjQKKyMgICAg ICAgICAxSzogICAgICAgIDEwMjQgKHNhbWUgYXMgMUspCisjICAgICAgICAgMW06ICAgICAgMTAy NF4yCisjICAgICAgICAgMU06ICAgICAgMTAyNF4yIChzYW1lIGFzIDFtKQorIyAgICAgICAgIDF0 OiAgICAgIDEwMjReNAorIyAgICAgICAgIDFUOiAgICAgIDEwMjReNCAoc2FtZSBhcyAxdCkKKyMg ICAgICAgICAxejogICAgICAgICAgIDAgKHJlamVjdCkKKyMgICAgICAgICAxVDogICAgICAgICAg IDAgKHJlamVjdCkKKworTU9ETkFNRT0iJChiYXNlbmFtZSAiJDAiIC5zaCkiCisKK3Rlc3RfbW9k dWxlKCkgeworCWtsZGxvYWQgLi8kTU9ETkFNRS5rbworCWtsZHVubG9hZCAuLyRNT0ROQU1FLmtv Cit9CisKK2tlbnYgLXUgJE1PRE5BTUUudHVuYWJsZSAyPi9kZXYvbnVsbAordGVzdF9tb2R1bGUK K2ZvciBpIGluIC0xIDAgMTsgZG8KKwlmb3IgaiBpbiAnJyBnIEcgayBLIG0gTSB0IFQgeiBaOyBk bworCQlrZW52ICRNT0ROQU1FLnR1bmFibGU9IiRpJGoiCisJCXRlc3RfbW9kdWxlCisJZG9uZQor ZG9uZQpJbmRleDogdG9vbHMvcmVncmVzc2lvbi90dW5hYmxlcy9zdHJpbmcvdGVzdF9zdHJpbmdf dHVuYWJsZS5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT0KLS0tIHRvb2xzL3JlZ3Jlc3Npb24vdHVuYWJsZXMvc3RyaW5n L3Rlc3Rfc3RyaW5nX3R1bmFibGUuYwkocmV2aXNpb24gMCkKKysrIHRvb2xzL3JlZ3Jlc3Npb24v dHVuYWJsZXMvc3RyaW5nL3Rlc3Rfc3RyaW5nX3R1bmFibGUuYwkocmV2aXNpb24gMCkKQEAgLTAs MCArMSwzMSBAQAorI2luY2x1ZGUgPHN5cy9wYXJhbS5oPgorI2luY2x1ZGUgPHN5cy90eXBlcy5o PgorI2luY2x1ZGUgPHN5cy9wcm9jLmg+CisjaW5jbHVkZSA8c3lzL21vZHVsZS5oPgorI2luY2x1 ZGUgPHN5cy9rZXJuZWwuaD4KKyNpbmNsdWRlIDxzeXMvc3lzdG0uaD4KKworI2RlZmluZSBNT0RV TEVfTkFNRQkidGVzdF9zdHJpbmdfdHVuYWJsZSIKKworc3RhdGljIGNoYXIgdHVuYWJsZVsxMF07 CisKK1RVTkFCTEVfU1RSKCJ0ZXN0X3N0cmluZ190dW5hYmxlLnR1bmFibGUiLCB0dW5hYmxlLCBz aXplb2YodHVuYWJsZSkpOworCitzdGF0aWMgaW50Citsb2FkIChtb2R1bGVfdCBtLCBpbnQgd2hh dCwgdm9pZCAqYXJnKQoreworCXN3aXRjaCAod2hhdCkgeworCWNhc2UgTU9EX0xPQUQ6CisJCXBy aW50ZigiJXM6ICVzXG4iLCBNT0RVTEVfTkFNRSwgdHVuYWJsZSk7CisJCWJyZWFrOworCX0KKwly ZXR1cm4gKDApOworfQorCitzdGF0aWMgbW9kdWxlZGF0YV90IHRlc3Rfc3RyaW5nX3R1bmFibGVf bW9kID0geworCU1PRFVMRV9OQU1FLAorCWxvYWQsCit9OworREVDTEFSRV9NT0RVTEUodGVzdF9z dHJpbmdfdHVuYWJsZSwgdGVzdF9zdHJpbmdfdHVuYWJsZV9tb2QsIFNJX1NVQl9LTEQsCisgICAg U0lfT1JERVJfQU5ZKTsKK01PRFVMRV9WRVJTSU9OKHRlc3Rfc3RyaW5nX3R1bmFibGUsIDEpOwpJ bmRleDogdG9vbHMvcmVncmVzc2lvbi90dW5hYmxlcy9zdHJpbmcvdGVzdF9zdHJpbmdfdHVuYWJs ZS5zaAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09Ci0tLSB0b29scy9yZWdyZXNzaW9uL3R1bmFibGVzL3N0cmluZy90ZXN0 X3N0cmluZ190dW5hYmxlLnNoCShyZXZpc2lvbiAwKQorKysgdG9vbHMvcmVncmVzc2lvbi90dW5h Ymxlcy9zdHJpbmcvdGVzdF9zdHJpbmdfdHVuYWJsZS5zaAkocmV2aXNpb24gMCkKQEAgLTAsMCAr MSwyMiBAQAorIyEvYmluL3NoCisjCisjIEV4cGVjdGVkIHZhbHVlczoKKyMgKHVuc2V0KSAgICAg ICAgICAgICAgOiAgICAgICAgICAiIgorIyAiIiAgICAgICAgICAgICAgICAgICA6ICAgICAgICAg ICIiCisjIGFzZGYxMjM0ICAgICAgICAgICAgIDogICAgYXNkZjEyMzQKKyMgY2hhcmFjdGVyICAg ICAgICAgICAgOiAgIGNoYXJhY3RlcgorIyBhc29ydG9mbG9uZ2lzaHN0cmluZyA6ICAgYXNvcnRv ZmxvCisjCisKK01PRE5BTUU9IiQoYmFzZW5hbWUgIiQwIiAuc2gpIgorCit0ZXN0X21vZHVsZSgp IHsKKwlrbGRsb2FkIC4vJE1PRE5BTUUua28KKwlrbGR1bmxvYWQgLi8kTU9ETkFNRS5rbworfQor Cit0ZXN0X21vZHVsZQorZm9yIGkgaW4gIiIgYXNkZjEyMzQgY2hhcmFjdGVyIGFzb3J0b2Zsb25n aXNoc3RyaW5nOyBkbworCWtlbnYgJE1PRE5BTUUudHVuYWJsZT0iJGkiCisJdGVzdF9tb2R1bGUK K2RvbmUKSW5kZXg6IHRvb2xzL3JlZ3Jlc3Npb24vdHVuYWJsZXMvc3RyaW5nL01ha2VmaWxlCj09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT0KLS0tIHRvb2xzL3JlZ3Jlc3Npb24vdHVuYWJsZXMvc3RyaW5nL01ha2VmaWxlCShy ZXZpc2lvbiAwKQorKysgdG9vbHMvcmVncmVzc2lvbi90dW5hYmxlcy9zdHJpbmcvTWFrZWZpbGUJ KHJldmlzaW9uIDApCkBAIC0wLDAgKzEsNCBAQAorS01PRD0JdGVzdF9zdHJpbmdfdHVuYWJsZQor U1JDUz0JdGVzdF9zdHJpbmdfdHVuYWJsZS5jCisKKy5pbmNsdWRlIDxic2Qua21vZC5taz4KSW5k ZXg6IHRvb2xzL3JlZ3Jlc3Npb24vdHVuYWJsZXMvc2l6ZS90ZXN0X3NpemVfdHVuYWJsZS5jCj09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT0KLS0tIHRvb2xzL3JlZ3Jlc3Npb24vdHVuYWJsZXMvc2l6ZS90ZXN0X3NpemVfdHVu YWJsZS5jCShyZXZpc2lvbiAwKQorKysgdG9vbHMvcmVncmVzc2lvbi90dW5hYmxlcy9zaXplL3Rl c3Rfc2l6ZV90dW5hYmxlLmMJKHJldmlzaW9uIDApCkBAIC0wLDAgKzEsMzEgQEAKKyNpbmNsdWRl IDxzeXMvcGFyYW0uaD4KKyNpbmNsdWRlIDxzeXMvdHlwZXMuaD4KKyNpbmNsdWRlIDxzeXMvcHJv Yy5oPgorI2luY2x1ZGUgPHN5cy9tb2R1bGUuaD4KKyNpbmNsdWRlIDxzeXMva2VybmVsLmg+Cisj aW5jbHVkZSA8c3lzL3N5c3RtLmg+CisKKyNkZWZpbmUgTU9EVUxFX05BTUUJInRlc3Rfc2l6ZV90 dW5hYmxlIgorCitzdGF0aWMgc2l6ZV90IHR1bmFibGUgPSAwOworCitUVU5BQkxFX1NJWkUoInRl c3Rfc2l6ZV90dW5hYmxlLnR1bmFibGUiLCAmdHVuYWJsZSk7CisKK3N0YXRpYyBpbnQKK2xvYWQg KG1vZHVsZV90IG0sIGludCB3aGF0LCB2b2lkICphcmcpCit7CisJc3dpdGNoICh3aGF0KSB7CisJ Y2FzZSBNT0RfTE9BRDoKKwkJcHJpbnRmKCIlczogJXp1XG4iLCBNT0RVTEVfTkFNRSwgdHVuYWJs ZSk7CisJCWJyZWFrOworCX0KKwlyZXR1cm4gKDApOworfQorCitzdGF0aWMgbW9kdWxlZGF0YV90 IHRlc3Rfc2l6ZV90dW5hYmxlX21vZCA9IHsKKwlNT0RVTEVfTkFNRSwKKwlsb2FkLAorfTsKK0RF Q0xBUkVfTU9EVUxFKHRlc3Rfc2l6ZV90dW5hYmxlLCB0ZXN0X3NpemVfdHVuYWJsZV9tb2QsIFNJ X1NVQl9LTEQsCisgICAgU0lfT1JERVJfQU5ZKTsKK01PRFVMRV9WRVJTSU9OKHRlc3Rfc2l6ZV90 dW5hYmxlLCAxKTsKSW5kZXg6IHRvb2xzL3JlZ3Jlc3Npb24vdHVuYWJsZXMvc2l6ZS90ZXN0X3Np emVfdHVuYWJsZS5zaAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSB0b29scy9yZWdyZXNzaW9uL3R1bmFibGVzL3Np emUvdGVzdF9zaXplX3R1bmFibGUuc2gJKHJldmlzaW9uIDApCisrKyB0b29scy9yZWdyZXNzaW9u L3R1bmFibGVzL3NpemUvdGVzdF9zaXplX3R1bmFibGUuc2gJKHJldmlzaW9uIDApCkBAIC0wLDAg KzEsMzggQEAKKyMhL2Jpbi9zaAorIworIyBFeHBlY3RlZCB2YWx1ZXM6CisjICh1bnNldCkgICAg OiAgICAgICAgICAgMAorIyAgICAgIC0xICAgIDogICBVTE9OR19NQVgKKyMgICAgICAgMCAgICA6 ICAgICAgICAgICAwCisjICAgICAgNDIgICAgOiAgICAgICAgICA0MgorIyBhc2RmMTIzNCAgIDog ICAgICAgICAgIDAgKHJlamVjdCkKKyMgTE9OR19NQVgrMSA6ICBMT05HX01BWCsxCisjIFVMT05H X01BWC0xOiBVTE9OR19NQVgtMQorIyBVTE9OR19NQVgrMTogICBVTE9OR19NQVgKKyMKKworTU9E TkFNRT0iJChiYXNlbmFtZSAiJDAiIC5zaCkiCisKK3Rlc3RfbW9kdWxlKCkgeworCWtsZGxvYWQg Li8kTU9ETkFNRS5rbworCWtsZHVubG9hZCAuLyRNT0ROQU1FLmtvCit9CisKK2Nhc2UgIiQoJChk aXJuYW1lICIkMCIpLy4uL3Rvb2xzL2dldHdvcmRzaXplKSIgaW4KKzMyKQorCUxPTkdfTUFYX1BM VVNfMT0yMTQ3NDgzNjQ5CisJVUxPTkdfTUFYX01JTlVTXzE9NDI5NDk2NzI5NQorCVVMT05HX01B WF9QTFVTXzE9NDI5NDk2NzI5NworCTs7Cis2NCkKKwlMT05HX01BWF9QTFVTXzE9OTIyMzM3MjAz Njg1NDc3NTgwOAorCVVMT05HX01BWF9NSU5VU18xPTE4NDQ2NzQ0MDczNzA5NTUxNjE0CisJVUxP TkdfTUFYX1BMVVNfMT0xODQ0Njc0NDA3MzcwOTU1MTYxNgorCTs7Citlc2FjCitrZW52IC11ICRN T0ROQU1FLnR1bmFibGUgMj4vZGV2L251bGwKK3Rlc3RfbW9kdWxlCitmb3IgaSBpbiAtMSAwIDQy IGFzZGYxMjM0ICRMT05HX01BWF9QTFVTXzEgJFVMT05HX01BWF9NSU5VU18xICRVTE9OR19NQVhf UExVU18xOyBkbworCWtlbnYgJE1PRE5BTUUudHVuYWJsZT0iJGkiCisJdGVzdF9tb2R1bGUKK2Rv bmUKSW5kZXg6IHRvb2xzL3JlZ3Jlc3Npb24vdHVuYWJsZXMvc2l6ZS9NYWtlZmlsZQo9PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09Ci0tLSB0b29scy9yZWdyZXNzaW9uL3R1bmFibGVzL3NpemUvTWFrZWZpbGUJKHJldmlzaW9u IDApCisrKyB0b29scy9yZWdyZXNzaW9uL3R1bmFibGVzL3NpemUvTWFrZWZpbGUJKHJldmlzaW9u IDApCkBAIC0wLDAgKzEsNCBAQAorS01PRD0JdGVzdF9zaXplX3R1bmFibGUKK1NSQ1M9CXRlc3Rf c2l6ZV90dW5hYmxlLmMKKworLmluY2x1ZGUgPGJzZC5rbW9kLm1rPgpJbmRleDogdG9vbHMvcmVn cmVzc2lvbi90dW5hYmxlcy9xdWFkL3Rlc3RfcXVhZF90dW5hYmxlLmMKPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0g dG9vbHMvcmVncmVzc2lvbi90dW5hYmxlcy9xdWFkL3Rlc3RfcXVhZF90dW5hYmxlLmMJKHJldmlz aW9uIDApCisrKyB0b29scy9yZWdyZXNzaW9uL3R1bmFibGVzL3F1YWQvdGVzdF9xdWFkX3R1bmFi bGUuYwkocmV2aXNpb24gMCkKQEAgLTAsMCArMSwzMSBAQAorI2luY2x1ZGUgPHN5cy9wYXJhbS5o PgorI2luY2x1ZGUgPHN5cy90eXBlcy5oPgorI2luY2x1ZGUgPHN5cy9wcm9jLmg+CisjaW5jbHVk ZSA8c3lzL21vZHVsZS5oPgorI2luY2x1ZGUgPHN5cy9rZXJuZWwuaD4KKyNpbmNsdWRlIDxzeXMv c3lzdG0uaD4KKworI2RlZmluZSBNT0RVTEVfTkFNRQkidGVzdF9xdWFkX3R1bmFibGUiCisKK3N0 YXRpYyBxdWFkX3QgdHVuYWJsZSA9IDA7CisKK1RVTkFCTEVfUVVBRCgidGVzdF9xdWFkX3R1bmFi bGUudHVuYWJsZSIsICZ0dW5hYmxlKTsKKworc3RhdGljIGludAorbG9hZCAobW9kdWxlX3QgbSwg aW50IHdoYXQsIHZvaWQgKmFyZykKK3sKKwlzd2l0Y2ggKHdoYXQpIHsKKwljYXNlIE1PRF9MT0FE OgorCQlwcmludGYoIiVzOiAlbGRcbiIsIE1PRFVMRV9OQU1FLCB0dW5hYmxlKTsKKwkJYnJlYWs7 CisJfQorCXJldHVybiAoMCk7Cit9CisKK3N0YXRpYyBtb2R1bGVkYXRhX3QgdGVzdF9xdWFkX3R1 bmFibGVfbW9kID0geworCU1PRFVMRV9OQU1FLAorCWxvYWQsCit9OworREVDTEFSRV9NT0RVTEUo dGVzdF9xdWFkX3R1bmFibGUsIHRlc3RfcXVhZF90dW5hYmxlX21vZCwgU0lfU1VCX0tMRCwKKyAg ICBTSV9PUkRFUl9BTlkpOworTU9EVUxFX1ZFUlNJT04odGVzdF9xdWFkX3R1bmFibGUsIDEpOwpJ bmRleDogdG9vbHMvcmVncmVzc2lvbi90dW5hYmxlcy9xdWFkL3Rlc3RfcXVhZF90dW5hYmxlLnNo Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT0KLS0tIHRvb2xzL3JlZ3Jlc3Npb24vdHVuYWJsZXMvcXVhZC90ZXN0X3F1YWRf dHVuYWJsZS5zaAkocmV2aXNpb24gMCkKKysrIHRvb2xzL3JlZ3Jlc3Npb24vdHVuYWJsZXMvcXVh ZC90ZXN0X3F1YWRfdHVuYWJsZS5zaAkocmV2aXNpb24gMCkKQEAgLTAsMCArMSw0MCBAQAorIyEv YmluL3NoCisjCisjIEV4cGVjdGVkIHZhbHVlczoKKyMgKHVuc2V0KSAgICA6ICAgICAgICAgICAw CisjICAgICAgIDAgICAgOiAgICAgICAgICAgMAorIyAgICAgIDQyICAgIDogICAgICAgICAgNDIK KyMgYXNkZjEyMzQgICA6ICAgICAgICAgICAwIChyZWplY3QpCisjIExPTkdfTUlOLTEgOiAgTE9O R19NSU4KKyMgTE9OR19NSU4rMSA6ICBMT05HX01JTisxCisjIExPTkdfTUFYLTEgOiAgTE9OR19N QVgtMQorIyBMT05HX01BWCsxIDogIExPTkdfTUFYCisjCisKK01PRE5BTUU9IiQoYmFzZW5hbWUg IiQwIiAuc2gpIgorCit0ZXN0X21vZHVsZSgpIHsKKwlrbGRsb2FkIC4vJE1PRE5BTUUua28KKwlr bGR1bmxvYWQgLi8kTU9ETkFNRS5rbworfQorCitjYXNlICIkKCQoZGlybmFtZSAiJDAiKS8uLi90 b29scy9nZXR3b3Jkc2l6ZSkiIGluCiszMikKKwlMT05HX01JTl9NSU5VU18xPSItMjE0NzQ4MzY0 OSIKKwlMT05HX01JTl9QTFVTXzE9Ii0yMTQ3NDgzNjQ3IgorCUxPTkdfTUFYX01JTlVTXzE9MjE0 NzQ4MzY0NworCUxPTkdfTUFYX1BMVVNfMT0yMTQ3NDgzNjQ5CisJOzsKKzY0KQorCUxPTkdfTUlO X01JTlVTXzE9Ii05MjIzMzcyMDM2ODU0Nzc1ODA5IgorCUxPTkdfTUlOX1BMVVNfMT0iLTkyMjMz NzIwMzY4NTQ3NzU4MDciCisJTE9OR19NQVhfTUlOVVNfMT05MjIzMzcyMDM2ODU0Nzc1ODA2CisJ TE9OR19NQVhfUExVU18xPTkyMjMzNzIwMzY4NTQ3NzU4MDgKKwk7OworZXNhYwora2VudiAtdSAk TU9ETkFNRS50dW5hYmxlIDI+L2Rldi9udWxsCit0ZXN0X21vZHVsZQorZm9yIGkgaW4gMCA0MiBh c2RmMTIzNCAkTE9OR19NSU5fTUlOVVNfMSAkTE9OR19NSU5fUExVU18xICRMT05HX01BWF9NSU5V U18xICRMT05HX01BWF9QTFVTXzEgOyBkbworCWtlbnYgJE1PRE5BTUUudHVuYWJsZT0iJGkiCisJ dGVzdF9tb2R1bGUKK2RvbmUKSW5kZXg6IHRvb2xzL3JlZ3Jlc3Npb24vdHVuYWJsZXMvcXVhZC9N YWtlZmlsZQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09Ci0tLSB0b29scy9yZWdyZXNzaW9uL3R1bmFibGVzL3F1YWQvTWFr ZWZpbGUJKHJldmlzaW9uIDApCisrKyB0b29scy9yZWdyZXNzaW9uL3R1bmFibGVzL3F1YWQvTWFr ZWZpbGUJKHJldmlzaW9uIDApCkBAIC0wLDAgKzEsNCBAQAorS01PRD0JdGVzdF9xdWFkX3R1bmFi bGUKK1NSQ1M9CXRlc3RfcXVhZF90dW5hYmxlLmMKKworLmluY2x1ZGUgPGJzZC5rbW9kLm1rPgpJ bmRleDogdG9vbHMvcmVncmVzc2lvbi90dW5hYmxlcy9pbnQvdGVzdF9pbnRfdHVuYWJsZS5jCj09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT0KLS0tIHRvb2xzL3JlZ3Jlc3Npb24vdHVuYWJsZXMvaW50L3Rlc3RfaW50X3R1bmFi bGUuYwkocmV2aXNpb24gMCkKKysrIHRvb2xzL3JlZ3Jlc3Npb24vdHVuYWJsZXMvaW50L3Rlc3Rf aW50X3R1bmFibGUuYwkocmV2aXNpb24gMCkKQEAgLTAsMCArMSwzMSBAQAorI2luY2x1ZGUgPHN5 cy9wYXJhbS5oPgorI2luY2x1ZGUgPHN5cy90eXBlcy5oPgorI2luY2x1ZGUgPHN5cy9wcm9jLmg+ CisjaW5jbHVkZSA8c3lzL2tlcm5lbC5oPgorI2luY2x1ZGUgPHN5cy9zeXN0bS5oPgorI2luY2x1 ZGUgPHN5cy9tb2R1bGUuaD4KKworI2RlZmluZSBNT0RVTEVfTkFNRQkidGVzdF9pbnRfdHVuYWJs ZSIKKworc3RhdGljIGludCB0dW5hYmxlID0gMDsKKworVFVOQUJMRV9JTlQoInRlc3RfaW50X3R1 bmFibGUudHVuYWJsZSIsICZ0dW5hYmxlKTsKKworc3RhdGljIGludAorbG9hZCAobW9kdWxlX3Qg bSwgaW50IHdoYXQsIHZvaWQgKmFyZykKK3sKKwlzd2l0Y2ggKHdoYXQpIHsKKwljYXNlIE1PRF9M T0FEOgorCQlwcmludGYoIiVzOiAlZFxuIiwgTU9EVUxFX05BTUUsIHR1bmFibGUpOworCQlicmVh azsKKwl9CisJcmV0dXJuICgwKTsKK30KKworc3RhdGljIG1vZHVsZWRhdGFfdCB0ZXN0X2ludF90 dW5hYmxlX21vZCA9IHsKKwlNT0RVTEVfTkFNRSwKKwlsb2FkLAorfTsKK0RFQ0xBUkVfTU9EVUxF KHRlc3RfaW50X3R1bmFibGUsIHRlc3RfaW50X3R1bmFibGVfbW9kLCBTSV9TVUJfS0xELAorICAg IFNJX09SREVSX0FOWSk7CitNT0RVTEVfVkVSU0lPTih0ZXN0X2ludF90dW5hYmxlLCAxKTsKSW5k ZXg6IHRvb2xzL3JlZ3Jlc3Npb24vdHVuYWJsZXMvaW50L3Rlc3RfaW50X3R1bmFibGUuc2gKPT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQotLS0gdG9vbHMvcmVncmVzc2lvbi90dW5hYmxlcy9pbnQvdGVzdF9pbnRfdHVuYWJs ZS5zaAkocmV2aXNpb24gMCkKKysrIHRvb2xzL3JlZ3Jlc3Npb24vdHVuYWJsZXMvaW50L3Rlc3Rf aW50X3R1bmFibGUuc2gJKHJldmlzaW9uIDApCkBAIC0wLDAgKzEsMzEgQEAKKyMhL2Jpbi9zaAor IworIyBFeHBlY3RlZCB2YWx1ZXM6CisjICh1bnNldCkgICA6ICAgICAgICAgICAwCisjICAgICAg LTEgICA6ICAgICAgICAgIC0xCisjICAgICAgIDAgICA6ICAgICAgICAgICAwCisjICAgICAgNDIg ICA6ICAgICAgICAgIDQyCisjIGFzZGYxMjM0ICA6ICAgICAgICAgICAwIChyZWplY3QpCisjIElO VF9NSU4rMSA6ICAgSU5UX01JTisxCisjIElOVF9NSU4tMSA6ICAgICAgICAgICAwIChyZWplY3Qp CisjIElOVF9NQVgtMSA6ICAgSU5UX01BWC0xCisjIElOVF9NQVgrMSA6ICAgICAgICAgICAwIChy ZWplY3QpCisjCisKK01PRE5BTUU9IiQoYmFzZW5hbWUgIiQwIiAuc2gpIgorCit0ZXN0X21vZHVs ZSgpIHsKKwlrbGRsb2FkIC4vJE1PRE5BTUUua28KKwlrbGR1bmxvYWQgLi8kTU9ETkFNRS5rbwor fQorCitJTlRfTUlOX1BMVVNfT05FPS0yMTQ3NDgzNjQ3CitJTlRfTUlOX01JTlVTX09ORT0tMjE0 NzQ4MzY0OQorSU5UX01BWF9NSU5VU19PTkU9MjE0NzQ4MzY0NgorSU5UX01BWF9QTFVTX09ORT0y MTQ3NDgzNjQ4CitrZW52IC11ICRNT0ROQU1FLnR1bmFibGUgMj4vZGV2L251bGwKK3Rlc3RfbW9k dWxlCitmb3IgaSBpbiAtMSAwIDQyIGFzZGYxMjM0ICRJTlRfTUlOX1BMVVNfT05FICRJTlRfTUlO X01JTlVTX09ORSAkSU5UX01BWF9NSU5VU19PTkUgJElOVF9NQVhfUExVU19PTkU7IGRvCisJa2Vu diAkTU9ETkFNRS50dW5hYmxlPSIkaSIKKwl0ZXN0X21vZHVsZQorZG9uZQpJbmRleDogdG9vbHMv cmVncmVzc2lvbi90dW5hYmxlcy9pbnQvTWFrZWZpbGUKPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gdG9vbHMvcmVn cmVzc2lvbi90dW5hYmxlcy9pbnQvTWFrZWZpbGUJKHJldmlzaW9uIDApCisrKyB0b29scy9yZWdy ZXNzaW9uL3R1bmFibGVzL2ludC9NYWtlZmlsZQkocmV2aXNpb24gMCkKQEAgLTAsMCArMSw0IEBA CitLTU9EPQl0ZXN0X2ludF90dW5hYmxlCitTUkNTPQl0ZXN0X2ludF90dW5hYmxlLmMKKworLmlu Y2x1ZGUgPGJzZC5rbW9kLm1rPgpJbmRleDogdG9vbHMvcmVncmVzc2lvbi90dW5hYmxlcy9NYWtl ZmlsZQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09Ci0tLSB0b29scy9yZWdyZXNzaW9uL3R1bmFibGVzL01ha2VmaWxlCShy ZXZpc2lvbiAwKQorKysgdG9vbHMvcmVncmVzc2lvbi90dW5hYmxlcy9NYWtlZmlsZQkocmV2aXNp b24gMCkKQEAgLTAsMCArMSwxMCBAQAorU1VCRElSPQkJdG9vbHMJCVwKKwkJaW50IHVpbnQJXAor CQlsb25nIHVsb25nCVwKKwkJcG9pbnRlcgkJXAorCQlxdWFkIHVxdWFkCVwKKwkJc2l6ZQkJXAor CQlzdHJpbmcJCVwKKwkJc3VmZml4CQlcCisKKy5pbmNsdWRlIDxic2Quc3ViZGlyLm1rPgo= --000e0cdfc900503d80049354fd59-- From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 24 04:20: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 975A3106566B; Sun, 24 Oct 2010 04:20:57 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id AAD168FC14; Sun, 24 Oct 2010 04:20:56 +0000 (UTC) Received: by wwe15 with SMTP id 15so209104wwe.1 for ; Sat, 23 Oct 2010 21:20:55 -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=UR0dprrCjDJk8aE/6A1XA/RM9ssdBJRMtXE+TMVPvfU=; b=AofPXgeWirqJctAN0Fm9vhyhfzUo2YbdnwkBaCG0DBw3cU7pDqri2HX2Au0xH7T6o5 bA++od7b+1GoWmGRHJ1hbzJUQDOPHKmIfAg1y2Mn2Y5k1BV/3LLdq6R3gPCsZSDVdHP5 JWUnGqCHbrHWwBzwJh6xHfjLpuYXQP8jmEOyw= 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=CY/EzsKNpWQq2awUCYMbWjSThf8wCqLsFb3okK7+XbDeHbUj0Wctgy9cf4G5TwkRxm yUJPF46NRp8wW5uhU/ozTgnquD8/zpAugNAhJBWc52Y9gbphISk+ajYzBgrXcWZqYXVl ct3gwv4pB3+bC8G9bIpMlfZWuSw9sxNzNs5dk= MIME-Version: 1.0 Received: by 10.216.38.71 with SMTP id z49mr1380741wea.76.1287894055608; Sat, 23 Oct 2010 21:20:55 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.216.10.198 with HTTP; Sat, 23 Oct 2010 21:20:55 -0700 (PDT) In-Reply-To: References: <86fwyq8rsc.fsf@ds4.des.no> <86d3tujh72.fsf@ds4.des.no> <864of680wv.fsf@ds4.des.no> <8662zkurx9.fsf@ds4.des.no> <8662zg586z.fsf@ds4.des.no> <8662wz4twb.fsf@ds4.des.no> Date: Sat, 23 Oct 2010 21:20:55 -0700 X-Google-Sender-Auth: 1IJJdjnN4bYkbVbvrhNIbZIjzQY Message-ID: From: Garrett Cooper To: =?ISO-8859-1?Q?Dag=2DErling_Sm=F8rgrav?= Content-Type: multipart/mixed; boundary=0016364c7f13b16b8304935533e3 Cc: freebsd-hackers@freebsd.org, Ivan Voras Subject: Re: Why is TUNABLE_INT discouraged? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 24 Oct 2010 04:20:57 -0000 --0016364c7f13b16b8304935533e3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2010/10/23 Garrett Cooper : > 2010/10/18 Dag-Erling Sm=F8rgrav : >> Garrett Cooper writes: >>> PS I added uquad_t for consistency in the APIs, even though quad_t was >>> deprecated, but I didn't bump __FreeBSD_version__ -- wasn't sure if I >>> should have done that). >> >> You should bump __FreeBSD_version__ anyway so third-party or shared code >> can use the new API if it is available and the old one if it isn't. >> >>> Let's try with the patch attached... >> >> Mailman strips binary attachments. =A0The correct MIME type is >> text/x-patch. > > =A0 =A0Ok. Let's retry with a .patch extension and by bumping __FreeBSD_v= ersion__. Sorry.. forgot the uquad_t addition to sys/types.h :(... --0016364c7f13b16b8304935533e3 Content-Type: text/x-patch; charset=US-ASCII; name="tunables-enhancement.patch" Content-Disposition: attachment; filename="tunables-enhancement.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gfnesoqj1 SW5kZXg6IHN5cy9rZXJuL2tlcm5fZW52aXJvbm1lbnQuYwo9PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMva2Vy bi9rZXJuX2Vudmlyb25tZW50LmMJKHJldmlzaW9uIDIxNDI1OCkKKysrIHN5cy9rZXJuL2tlcm5f ZW52aXJvbm1lbnQuYwkod29ya2luZyBjb3B5KQpAQCAtNTAsNiArNTAsNyBAQAogI2luY2x1ZGUg PHN5cy9zeXNlbnQuaD4KICNpbmNsdWRlIDxzeXMvc3lzcHJvdG8uaD4KICNpbmNsdWRlIDxzeXMv bGlia2Vybi5oPgorI2luY2x1ZGUgPHN5cy9saW1pdHMuaD4KICNpbmNsdWRlIDxzeXMva2Vudi5o PgogCiAjaW5jbHVkZSA8c2VjdXJpdHkvbWFjL21hY19mcmFtZXdvcmsuaD4KQEAgLTQ0MiwzMiAr NDQzLDExNSBAQAogfQogCiAvKgotICogUmV0dXJuIGEgc3RyaW5nIHZhbHVlIGZyb20gYW4gZW52 aXJvbm1lbnQgdmFyaWFibGUuCisgKiBSZXR1cm4gdGhlIG11bHRpcGxpZXIgZm9yIGEgdXNlciBz cGVjaWZpZWQgc3VmZml4IGZyb20gYSBnZXRlbnYgY2FsbC4KICAqLwordWludG1heF90CitnZXRl bnZfcGFyc2Vfc3VmZml4KGNvbnN0IGNoYXIgc3VmZml4KQoreworCXVpbnRtYXhfdCBtdWx0aXBs aWVyID0gMTsKKworCXN3aXRjaCAoc3VmZml4KSB7CisJY2FzZSAndCc6IGNhc2UgJ1QnOgorCQlt dWx0aXBsaWVyICo9IDEwMjQ7CisJY2FzZSAnZyc6IGNhc2UgJ0cnOgorCQltdWx0aXBsaWVyICo9 IDEwMjQ7CisJY2FzZSAnbSc6IGNhc2UgJ00nOgorCQltdWx0aXBsaWVyICo9IDEwMjQ7CisJY2Fz ZSAnayc6IGNhc2UgJ0snOgorCQltdWx0aXBsaWVyICo9IDEwMjQ7CisJY2FzZSAnXDAnOgorCQli cmVhazsKKwlkZWZhdWx0OgorCQltdWx0aXBsaWVyID0gMDsKKwl9CisKKwlyZXR1cm4gKG11bHRp cGxpZXIpOworfQorCisvKgorICogUmV0dXJuIGEgc2lnbmVkIHF1YW50aXR5IGZyb20gYW4gZW52 aXJvbm1lbnQgdmFyaWFibGUuCisgKi8KIGludAotZ2V0ZW52X3N0cmluZyhjb25zdCBjaGFyICpu YW1lLCBjaGFyICpkYXRhLCBpbnQgc2l6ZSkKK2dldGVudl9zaWduZWQoY29uc3QgY2hhciAqbmFt ZSwgaW50bWF4X3QgKmRhdGEsIGNvbnN0IGludG1heF90IG1pbiwKKyAgICBjb25zdCBpbnRtYXhf dCBtYXgpCiB7Ci0JY2hhciAqdG1wOworCXVpbnRtYXhfdAltdWx0aXBsaWVyOworCWludG1heF90 CWl2OworCWludAkJcmV0X2NvZGU7CisJY2hhcgkJKnZhbHVlOworCWNoYXIJCSp2dHA7CiAKLQl0 bXAgPSBnZXRlbnYobmFtZSk7Ci0JaWYgKHRtcCAhPSBOVUxMKSB7Ci0JCXN0cmxjcHkoZGF0YSwg dG1wLCBzaXplKTsKLQkJZnJlZWVudih0bXApOwotCQlyZXR1cm4gKDEpOwotCX0gZWxzZQotCQly ZXR1cm4gKDApOworCXJldF9jb2RlID0gMDsKKworCXZhbHVlID0gZ2V0ZW52KG5hbWUpOworCWlm ICh2YWx1ZSA9PSBOVUxMKQorCQlyZXR1cm4gKHJldF9jb2RlKTsKKwlpdiA9IHN0cnRvcSh2YWx1 ZSwgJnZ0cCwgMCk7CisJaWYgKHZ0cCA9PSB2YWx1ZSB8fCAodnRwWzBdICE9ICdcMCcgJiYgdnRw WzFdICE9ICdcMCcpIHx8CisJICAgIChtdWx0aXBsaWVyID0gZ2V0ZW52X3BhcnNlX3N1ZmZpeCh2 dHBbMF0pKSA9PSAwKSB7CisJCS8qIAorCQkgKiBDYXRjaCBlcnJvcnMgaW4gcGFyc2luZyB0aGUg bnVtYmVyLCBiYWQgaW5wdXQsIG9yIHRoZQorCQkgKiBzdWZmaXggaWYgb25lIHdhcyBzcGVjaWZp ZWQuCisJCSAqLworCQk7CisJfSBlbHNlIHsKKwkJaXYgKj0gbXVsdGlwbGllcjsKKwkJaWYgKG1p biA8PSBpdiAmJiBpdiA8PSBtYXgpIHsKKwkJCSpkYXRhID0gaXY7CisJCQlyZXRfY29kZSA9IDE7 CisJCX0KKwl9CisJZnJlZWVudih2YWx1ZSk7CisJcmV0dXJuIChyZXRfY29kZSk7CiB9CiAKIC8q CisgKiBSZXR1cm4gYW4gdW5zaWduZWQgcXVhbnRpdHkgZnJvbSBhbiBlbnZpcm9ubWVudCB2YXJp YWJsZS4KKyAqLworaW50CitnZXRlbnZfdW5zaWduZWQoY29uc3QgY2hhciAqbmFtZSwgdWludG1h eF90ICpkYXRhLCBjb25zdCB1aW50bWF4X3QgbWluLAorICAgIGNvbnN0IHVpbnRtYXhfdCBtYXgp Cit7CisJdWludG1heF90CW11bHRpcGxpZXI7CisJdWludG1heF90CXVpdjsKKwlpbnQJCXJldF9j b2RlOworCWNoYXIJCSp2YWx1ZTsKKwljaGFyCQkqdnRwOworCisJcmV0X2NvZGUgPSAwOworCisJ dmFsdWUgPSBnZXRlbnYobmFtZSk7CisJaWYgKHZhbHVlID09IE5VTEwpCisJCXJldHVybiAocmV0 X2NvZGUpOworCXVpdiA9IHN0cnRvdXEodmFsdWUsICZ2dHAsIDApOworCWlmICh2dHAgPT0gdmFs dWUgfHwgKHZ0cFswXSAhPSAnXDAnICYmIHZ0cFsxXSAhPSAnXDAnKSB8fAorCSAgICAobXVsdGlw bGllciA9IGdldGVudl9wYXJzZV9zdWZmaXgodnRwWzBdKSkgPT0gMCkgeworCQkvKiAKKwkJICog Q2F0Y2ggZXJyb3JzIGluIHBhcnNpbmcgdGhlIG51bWJlciwgYmFkIGlucHV0LCBvciB0aGUKKwkJ ICogc3VmZml4IGlmIG9uZSB3YXMgc3BlY2lmaWVkLgorCQkgKi8KKwkJOworCX0gZWxzZSB7CisJ CXVpdiAqPSBtdWx0aXBsaWVyOworCQlpZiAobWluIDw9IHVpdiAmJiB1aXYgPD0gbWF4KSB7CisJ CQkqZGF0YSA9IHVpdjsKKwkJCXJldF9jb2RlID0gMTsKKwkJfQorCX0KKwlmcmVlZW52KHZhbHVl KTsKKwlyZXR1cm4gKHJldF9jb2RlKTsKK30KKworLyoKICAqIFJldHVybiBhbiBpbnRlZ2VyIHZh bHVlIGZyb20gYW4gZW52aXJvbm1lbnQgdmFyaWFibGUuCiAgKi8KIGludAogZ2V0ZW52X2ludChj b25zdCBjaGFyICpuYW1lLCBpbnQgKmRhdGEpCiB7Ci0JcXVhZF90IHRtcDsKKwlpbnRtYXhfdCB0 bXA7CiAJaW50IHJ2YWw7CiAKLQlydmFsID0gZ2V0ZW52X3F1YWQobmFtZSwgJnRtcCk7CisJcnZh bCA9IGdldGVudl9zaWduZWQobmFtZSwgJnRtcCwgSU5UX01JTiwgSU5UX01BWCk7CiAJaWYgKHJ2 YWwpCiAJCSpkYXRhID0gKGludCkgdG1wOwogCXJldHVybiAocnZhbCk7CkBAIC00NzksMTAgKzU2 MywxMCBAQAogaW50CiBnZXRlbnZfdWludChjb25zdCBjaGFyICpuYW1lLCB1bnNpZ25lZCBpbnQg KmRhdGEpCiB7Ci0JcXVhZF90IHRtcDsKKwlpbnRtYXhfdCB0bXA7CiAJaW50IHJ2YWw7CiAKLQly dmFsID0gZ2V0ZW52X3F1YWQobmFtZSwgJnRtcCk7CisJcnZhbCA9IGdldGVudl91bnNpZ25lZChu YW1lLCAmdG1wLCAwLCBVSU5UX01BWCk7CiAJaWYgKHJ2YWwpCiAJCSpkYXRhID0gKHVuc2lnbmVk IGludCkgdG1wOwogCXJldHVybiAocnZhbCk7CkBAIC00OTQsMTAgKzU3OCwxMCBAQAogaW50CiBn ZXRlbnZfbG9uZyhjb25zdCBjaGFyICpuYW1lLCBsb25nICpkYXRhKQogewotCXF1YWRfdCB0bXA7 CisJaW50bWF4X3QgdG1wOwogCWludCBydmFsOwogCi0JcnZhbCA9IGdldGVudl9xdWFkKG5hbWUs ICZ0bXApOworCXJ2YWwgPSBnZXRlbnZfc2lnbmVkKG5hbWUsICZ0bXAsIExPTkdfTUlOLCBMT05H X01BWCk7CiAJaWYgKHJ2YWwpCiAJCSpkYXRhID0gKGxvbmcpIHRtcDsKIAlyZXR1cm4gKHJ2YWwp OwpAQCAtNTA5LDUxICs1OTMsOTAgQEAKIGludAogZ2V0ZW52X3Vsb25nKGNvbnN0IGNoYXIgKm5h bWUsIHVuc2lnbmVkIGxvbmcgKmRhdGEpCiB7Ci0JcXVhZF90IHRtcDsKKwlpbnRtYXhfdCB0bXA7 CiAJaW50IHJ2YWw7CiAKLQlydmFsID0gZ2V0ZW52X3F1YWQobmFtZSwgJnRtcCk7CisJcnZhbCA9 IGdldGVudl91bnNpZ25lZChuYW1lLCAmdG1wLCAwLCBVTE9OR19NQVgpOwogCWlmIChydmFsKQog CQkqZGF0YSA9ICh1bnNpZ25lZCBsb25nKSB0bXA7CiAJcmV0dXJuIChydmFsKTsKIH0KIAogLyoK KyAqIFJldHVybiBhIHBvaW50ZXIgZnJvbSBhbiBlbnZpcm9ubWVudCB2YXJpYWJsZS4KKyAqLwor aW50CitnZXRlbnZfcG9pbnRlcihjb25zdCBjaGFyICpuYW1lLCB1aW50cHRyX3QgKmRhdGEpCit7 CisJaW50bWF4X3QgdG1wOworCWludCBydmFsOworCisJcnZhbCA9IGdldGVudl91bnNpZ25lZChu YW1lLCAmdG1wLCAwLCBVSU5UUFRSX01BWCk7CisJaWYgKHJ2YWwpCisJCSpkYXRhID0gKHVpbnRw dHJfdCkgdG1wOworCXJldHVybiAocnZhbCk7Cit9CisKKy8qCiAgKiBSZXR1cm4gYSBxdWFkX3Qg dmFsdWUgZnJvbSBhbiBlbnZpcm9ubWVudCB2YXJpYWJsZS4KICAqLwogaW50CiBnZXRlbnZfcXVh ZChjb25zdCBjaGFyICpuYW1lLCBxdWFkX3QgKmRhdGEpCiB7Ci0JY2hhcgkqdmFsdWU7Ci0JY2hh cgkqdnRwOwotCXF1YWRfdAlpdjsKKwlpbnRtYXhfdCB0bXA7CisJaW50IHJ2YWw7CiAKLQl2YWx1 ZSA9IGdldGVudihuYW1lKTsKLQlpZiAodmFsdWUgPT0gTlVMTCkKKwlydmFsID0gZ2V0ZW52X3Np Z25lZChuYW1lLCAmdG1wLCBRVUFEX01JTiwgUVVBRF9NQVgpOworCWlmIChydmFsKQorCQkqZGF0 YSA9IChxdWFkX3QpIHRtcDsKKwlyZXR1cm4gKHJ2YWwpOworfQorCisvKgorICogUmV0dXJuIGEg dXF1YWRfdCB2YWx1ZSBmcm9tIGFuIGVudmlyb25tZW50IHZhcmlhYmxlLgorICovCitpbnQKK2dl dGVudl91cXVhZChjb25zdCBjaGFyICpuYW1lLCB1cXVhZF90ICpkYXRhKQoreworCWludG1heF90 IHRtcDsKKwlpbnQgcnZhbDsKKworCXJ2YWwgPSBnZXRlbnZfdW5zaWduZWQobmFtZSwgJnRtcCwg MCwgVVFVQURfTUFYKTsKKwlpZiAocnZhbCkKKwkJKmRhdGEgPSAodXF1YWRfdCkgdG1wOworCXJl dHVybiAocnZhbCk7Cit9CisKKy8qCisgKiBSZXR1cm4gYSBzaXplX3QgdmFsdWUgZnJvbSBhbiBl bnZpcm9ubWVudCB2YXJpYWJsZS4KKyAqLworaW50CitnZXRlbnZfc2l6ZShjb25zdCBjaGFyICpu YW1lLCBzaXplX3QgKmRhdGEpCit7CisJaW50bWF4X3QgdG1wOworCWludCBydmFsOworCisJcnZh bCA9IGdldGVudl91bnNpZ25lZChuYW1lLCAmdG1wLCAwLCBTSVpFX01BWCk7CisJaWYgKHJ2YWwp CisJCSpkYXRhID0gKHNpemVfdCkgdG1wOworCXJldHVybiAocnZhbCk7Cit9CisKKy8qCisgKiBS ZXR1cm4gYSBzdHJpbmcgdmFsdWUgZnJvbSBhbiBlbnZpcm9ubWVudCB2YXJpYWJsZS4KKyAqLwor aW50CitnZXRlbnZfc3RyaW5nKGNvbnN0IGNoYXIgKm5hbWUsIGNoYXIgKmRhdGEsIHNpemVfdCBz aXplKQoreworCWNoYXIgKnRtcDsKKworCXRtcCA9IGdldGVudihuYW1lKTsKKwlpZiAodG1wICE9 IE5VTEwpIHsKKwkJc3RybGNweShkYXRhLCB0bXAsIHNpemUpOworCQlmcmVlZW52KHRtcCk7CisJ CXJldHVybiAoMSk7CisJfSBlbHNlCiAJCXJldHVybiAoMCk7Ci0JaXYgPSBzdHJ0b3EodmFsdWUs ICZ2dHAsIDApOwotCWlmICh2dHAgPT0gdmFsdWUgfHwgKHZ0cFswXSAhPSAnXDAnICYmIHZ0cFsx XSAhPSAnXDAnKSkgewotCQlmcmVlZW52KHZhbHVlKTsKLQkJcmV0dXJuICgwKTsKLQl9Ci0Jc3dp dGNoICh2dHBbMF0pIHsKLQljYXNlICd0JzogY2FzZSAnVCc6Ci0JCWl2ICo9IDEwMjQ7Ci0JY2Fz ZSAnZyc6IGNhc2UgJ0cnOgotCQlpdiAqPSAxMDI0OwotCWNhc2UgJ20nOiBjYXNlICdNJzoKLQkJ aXYgKj0gMTAyNDsKLQljYXNlICdrJzogY2FzZSAnSyc6Ci0JCWl2ICo9IDEwMjQ7Ci0JY2FzZSAn XDAnOgotCQlicmVhazsKLQlkZWZhdWx0OgotCQlmcmVlZW52KHZhbHVlKTsKLQkJcmV0dXJuICgw KTsKLQl9Ci0JKmRhdGEgPSBpdjsKLQlmcmVlZW52KHZhbHVlKTsKLQlyZXR1cm4gKDEpOwogfQog CiAvKgpAQCAtNTgzLDYgKzcwNiwxNCBAQAogfQogCiB2b2lkCit0dW5hYmxlX3VpbnRfaW5pdCh2 b2lkICpkYXRhKQoreworCXN0cnVjdCB0dW5hYmxlX3VpbnQgKmQgPSAoc3RydWN0IHR1bmFibGVf dWludCAqKWRhdGE7CisKKwlUVU5BQkxFX1VJTlRfRkVUQ0goZC0+cGF0aCwgZC0+dmFyKTsKK30K Kwordm9pZAogdHVuYWJsZV9sb25nX2luaXQodm9pZCAqZGF0YSkKIHsKIAlzdHJ1Y3QgdHVuYWJs ZV9sb25nICpkID0gKHN0cnVjdCB0dW5hYmxlX2xvbmcgKilkYXRhOwpAQCAtNTk5LDYgKzczMCwx NCBAQAogfQogCiB2b2lkCit0dW5hYmxlX3BvaW50ZXJfaW5pdCh2b2lkICpkYXRhKQoreworCXN0 cnVjdCB0dW5hYmxlX3BvaW50ZXIgKmQgPSAoc3RydWN0IHR1bmFibGVfcG9pbnRlciAqKWRhdGE7 CisKKwlUVU5BQkxFX1BPSU5URVJfRkVUQ0goZC0+cGF0aCwgZC0+dmFyKTsKK30KKwordm9pZAog dHVuYWJsZV9xdWFkX2luaXQodm9pZCAqZGF0YSkKIHsKIAlzdHJ1Y3QgdHVuYWJsZV9xdWFkICpk ID0gKHN0cnVjdCB0dW5hYmxlX3F1YWQgKilkYXRhOwpAQCAtNjA3LDYgKzc0NiwyMiBAQAogfQog CiB2b2lkCit0dW5hYmxlX3VxdWFkX2luaXQodm9pZCAqZGF0YSkKK3sKKwlzdHJ1Y3QgdHVuYWJs ZV91cXVhZCAqZCA9IChzdHJ1Y3QgdHVuYWJsZV91cXVhZCAqKWRhdGE7CisKKwlUVU5BQkxFX1VR VUFEX0ZFVENIKGQtPnBhdGgsIGQtPnZhcik7Cit9CisKK3ZvaWQKK3R1bmFibGVfc2l6ZV9pbml0 KHZvaWQgKmRhdGEpCit7CisJc3RydWN0IHR1bmFibGVfc2l6ZSAqZCA9IChzdHJ1Y3QgdHVuYWJs ZV9zaXplICopZGF0YTsKKworCVRVTkFCTEVfU0laRV9GRVRDSChkLT5wYXRoLCBkLT52YXIpOwor fQorCit2b2lkCiB0dW5hYmxlX3N0cl9pbml0KHZvaWQgKmRhdGEpCiB7CiAJc3RydWN0IHR1bmFi bGVfc3RyICpkID0gKHN0cnVjdCB0dW5hYmxlX3N0ciAqKWRhdGE7CkluZGV4OiBzeXMvc3lzL2tl cm5lbC5oCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9zeXMva2VybmVsLmgJKHJldmlzaW9uIDIxNDI1OCkK KysrIHN5cy9zeXMva2VybmVsLmgJKHdvcmtpbmcgY29weSkKQEAgLTI3NSw3ICsyNzUsOSBAQAog CiAvKgogICogaW50Ci0gKiBwbGVhc2UgYXZvaWQgdXNpbmcgZm9yIG5ldyB0dW5hYmxlcyEKKyAq CisgKiBQbGVhc2UgZG8gbm90IHVzZSBmb3IgYWRkcmVzc2VzIG9yIHBvaW50ZXJzICh1c2UgdGhl IHBvaW50ZXIgdHVuYWJsZQorICogaW5zdGVhZCksIG9yIHNpemVzICh1c2UgdGhlIHNpemUgdHVu YWJsZSBpbnN0ZWFkKS4KICAqLwogZXh0ZXJuIHZvaWQgdHVuYWJsZV9pbnRfaW5pdCh2b2lkICop Owogc3RydWN0IHR1bmFibGVfaW50IHsKQEAgLTI5NCw2ICsyOTYsMjggQEAKICNkZWZpbmUJVFVO QUJMRV9JTlRfRkVUQ0gocGF0aCwgdmFyKQlnZXRlbnZfaW50KChwYXRoKSwgKHZhcikpCiAKIC8q CisgKiB1bnNpZ25lZCBpbnQKKyAqCisgKiBQbGVhc2UgZG8gbm90IHVzZSBmb3IgYWRkcmVzc2Vz IG9yIHBvaW50ZXJzICh1c2UgdGhlIHBvaW50ZXIgdHVuYWJsZQorICogaW5zdGVhZCksIG9yIHNp emVzICh1c2UgdGhlIHNpemUgdHVuYWJsZSBpbnN0ZWFkKS4KKyAqLworZXh0ZXJuIHZvaWQgdHVu YWJsZV91aW50X2luaXQodm9pZCAqKTsKK3N0cnVjdCB0dW5hYmxlX3VpbnQgeworCWNvbnN0IGNo YXIgKnBhdGg7CisJdW5zaWduZWQgaW50ICp2YXI7Cit9OworI2RlZmluZQlUVU5BQkxFX1VJTlQo cGF0aCwgdmFyKQkJCQkJXAorCXN0YXRpYyBzdHJ1Y3QgdHVuYWJsZV91aW50IF9fQ09OQ0FUKF9f dHVuYWJsZV91aW50XywgX19MSU5FX18pID0geyBcCisJCShwYXRoKSwJCQkJCQlcCisJCSh2YXIp LAkJCQkJCVwKKwl9OwkJCQkJCQlcCisJU1lTSU5JVChfX0NPTkNBVChfX1R1bmFibGVfaW5pdF8s IF9fTElORV9fKSwJCVwKKwkgICAgU0lfU1VCX1RVTkFCTEVTLCBTSV9PUkRFUl9NSURETEUsIHR1 bmFibGVfdWludF9pbml0LCBcCisJICAgICZfX0NPTkNBVChfX3R1bmFibGVfdWludF8sIF9fTElO RV9fKSkKKworI2RlZmluZQlUVU5BQkxFX1VJTlRfRkVUQ0gocGF0aCwgdmFyKQlnZXRlbnZfdWlu dCgocGF0aCksICh2YXIpKQorCisvKgogICogbG9uZwogICovCiBleHRlcm4gdm9pZCB0dW5hYmxl X2xvbmdfaW5pdCh2b2lkICopOwpAQCAtMzMyLDggKzM1NiwyOCBAQAogI2RlZmluZQlUVU5BQkxF X1VMT05HX0ZFVENIKHBhdGgsIHZhcikJZ2V0ZW52X3Vsb25nKChwYXRoKSwgKHZhcikpCiAKIC8q Ci0gKiBxdWFkCisgKiBwb2ludGVyCiAgKi8KK2V4dGVybiB2b2lkIHR1bmFibGVfcG9pbnRlcl9p bml0KHZvaWQgKik7CitzdHJ1Y3QgdHVuYWJsZV9wb2ludGVyIHsKKwljb25zdCBjaGFyICpwYXRo OworCXVpbnRwdHJfdCAqdmFyOworfTsKKyNkZWZpbmUJVFVOQUJMRV9QT0lOVEVSKHBhdGgsIHZh cikJCQkJXAorCXN0YXRpYyBzdHJ1Y3QgdHVuYWJsZV9wb2ludGVyIF9fQ09OQ0FUKF9fdHVuYWJs ZV9wb2ludGVyXywgX19MSU5FX18pID0geyBcCisJCShwYXRoKSwJCQkJCQlcCisJCSh2YXIpLAkJ CQkJCVwKKwl9OwkJCQkJCQlcCisJU1lTSU5JVChfX0NPTkNBVChfX1R1bmFibGVfaW5pdF8sIF9f TElORV9fKSwJCVwKKwkgICAgU0lfU1VCX1RVTkFCTEVTLCBTSV9PUkRFUl9NSURETEUsIHR1bmFi bGVfcG9pbnRlcl9pbml0LCBcCisJICAgICZfX0NPTkNBVChfX3R1bmFibGVfcG9pbnRlcl8sIF9f TElORV9fKSkKKworI2RlZmluZQlUVU5BQkxFX1BPSU5URVJfRkVUQ0gocGF0aCwgdmFyKQkJCVwK KwlnZXRlbnZfcG9pbnRlcigocGF0aCksICh2YXIpKQorCisvKgorICogcXVhZF90CisgKi8KIGV4 dGVybiB2b2lkIHR1bmFibGVfcXVhZF9pbml0KHZvaWQgKik7CiBzdHJ1Y3QgdHVuYWJsZV9xdWFk IHsKIAljb25zdCBjaGFyICpwYXRoOwpAQCAtMzUwLDYgKzM5NCwyOCBAQAogCiAjZGVmaW5lCVRV TkFCTEVfUVVBRF9GRVRDSChwYXRoLCB2YXIpCWdldGVudl9xdWFkKChwYXRoKSwgKHZhcikpCiAK Ky8qCisgKiBzaXplX3QKKyAqLworZXh0ZXJuIHZvaWQgdHVuYWJsZV9zaXplX2luaXQodm9pZCAq KTsKK3N0cnVjdCB0dW5hYmxlX3NpemUgeworCWNvbnN0IGNoYXIgKnBhdGg7CisJc2l6ZV90ICp2 YXI7Cit9OworI2RlZmluZQlUVU5BQkxFX1NJWkUocGF0aCwgdmFyKQkJCQkJXAorCXN0YXRpYyBz dHJ1Y3QgdHVuYWJsZV9zaXplIF9fQ09OQ0FUKF9fdHVuYWJsZV9zaXplXywgX19MSU5FX18pID0g eyBcCisJCShwYXRoKSwJCQkJCQlcCisJCSh2YXIpLAkJCQkJCVwKKwl9OwkJCQkJCQlcCisJU1lT SU5JVChfX0NPTkNBVChfX1R1bmFibGVfaW5pdF8sIF9fTElORV9fKSwJCVwKKwkgICAgU0lfU1VC X1RVTkFCTEVTLCBTSV9PUkRFUl9NSURETEUsIHR1bmFibGVfc2l6ZV9pbml0LCBcCisJICAgICZf X0NPTkNBVChfX3R1bmFibGVfc2l6ZV8sIF9fTElORV9fKSkKKworI2RlZmluZQlUVU5BQkxFX1NJ WkVfRkVUQ0gocGF0aCwgdmFyKQlnZXRlbnZfc2l6ZSgocGF0aCksICh2YXIpKQorCisvKgorICog c3RyaW5ncworICovCiBleHRlcm4gdm9pZCB0dW5hYmxlX3N0cl9pbml0KHZvaWQgKik7CiBzdHJ1 Y3QgdHVuYWJsZV9zdHIgewogCWNvbnN0IGNoYXIgKnBhdGg7CkBAIC0zNjksNiArNDM1LDI1IEBA CiAjZGVmaW5lCVRVTkFCTEVfU1RSX0ZFVENIKHBhdGgsIHZhciwgc2l6ZSkJCQlcCiAJZ2V0ZW52 X3N0cmluZygocGF0aCksICh2YXIpLCAoc2l6ZSkpCiAKKy8qCisgKiB1cXVhZF90CisgKi8KK2V4 dGVybiB2b2lkIHR1bmFibGVfdXF1YWRfaW5pdCh2b2lkICopOworc3RydWN0IHR1bmFibGVfdXF1 YWQgeworCWNvbnN0IGNoYXIgKnBhdGg7CisJdXF1YWRfdCAqdmFyOworfTsKKyNkZWZpbmUJVFVO QUJMRV9VUVVBRChwYXRoLCB2YXIpCQkJCQlcCisJc3RhdGljIHN0cnVjdCB0dW5hYmxlX3VxdWFk IF9fQ09OQ0FUKF9fdHVuYWJsZV91cXVhZF8sIF9fTElORV9fKSA9IHsgXAorCQkocGF0aCksCQkJ CQkJXAorCQkodmFyKSwJCQkJCQlcCisJfTsJCQkJCQkJXAorCVNZU0lOSVQoX19DT05DQVQoX19U dW5hYmxlX2luaXRfLCBfX0xJTkVfXyksCQlcCisJICAgIFNJX1NVQl9UVU5BQkxFUywgU0lfT1JE RVJfTUlERExFLCB0dW5hYmxlX3VxdWFkX2luaXQsIFwKKwkgICAgJl9fQ09OQ0FUKF9fdHVuYWJs ZV91cXVhZF8sIF9fTElORV9fKSkKKworI2RlZmluZQlUVU5BQkxFX1VRVUFEX0ZFVENIKHBhdGgs IHZhcikJZ2V0ZW52X3VxdWFkKChwYXRoKSwgKHZhcikpCisKIHN0cnVjdCBpbnRyX2NvbmZpZ19o b29rIHsKIAlUQUlMUV9FTlRSWShpbnRyX2NvbmZpZ19ob29rKSBpY2hfbGlua3M7CiAJdm9pZAko KmljaF9mdW5jKSh2b2lkICphcmcpOwpJbmRleDogc3lzL3N5cy9wYXJhbS5oCj09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0K LS0tIHN5cy9zeXMvcGFyYW0uaAkocmV2aXNpb24gMjE0MjU4KQorKysgc3lzL3N5cy9wYXJhbS5o CSh3b3JraW5nIGNvcHkpCkBAIC01OCw3ICs1OCw3IEBACiAgKgkJaW4gdGhlIHJhbmdlIDUgdG8g OS4KICAqLwogI3VuZGVmIF9fRnJlZUJTRF92ZXJzaW9uCi0jZGVmaW5lIF9fRnJlZUJTRF92ZXJz aW9uIDkwMDAyMwkvKiBNYXN0ZXIsIHByb3BhZ2F0ZWQgdG8gbmV3dmVycyAqLworI2RlZmluZSBf X0ZyZWVCU0RfdmVyc2lvbiA5MDAwMjQJLyogTWFzdGVyLCBwcm9wYWdhdGVkIHRvIG5ld3ZlcnMg Ki8KIAogI2lmbmRlZiBMT0NPUkUKICNpbmNsdWRlIDxzeXMvdHlwZXMuaD4KSW5kZXg6IHN5cy9z eXMvc3lzdG0uaAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvc3lzL3N5c3RtLmgJKHJldmlzaW9uIDIxNDI1 OCkKKysrIHN5cy9zeXMvc3lzdG0uaAkod29ya2luZyBjb3B5KQpAQCAtMjYwLDEyICsyNjAsMjAg QEAKIAogY2hhcgkqZ2V0ZW52KGNvbnN0IGNoYXIgKm5hbWUpOwogdm9pZAlmcmVlZW52KGNoYXIg KmVudik7Cit1aW50bWF4X3QgZ2V0ZW52X3BhcnNlX3N1ZmZpeChjb25zdCBjaGFyIHN1ZmZpeCk7 CitpbnQJZ2V0ZW52X3NpZ25lZChjb25zdCBjaGFyICpuYW1lLCBpbnRtYXhfdCAqZGF0YSwgY29u c3QgaW50bWF4X3QgbWluLAorCSAgICBjb25zdCBpbnRtYXhfdCBtYXgpOworaW50CWdldGVudl91 bnNpZ25lZChjb25zdCBjaGFyICpuYW1lLCB1aW50bWF4X3QgKmRhdGEsCisJICAgIGNvbnN0IHVp bnRtYXhfdCBtaW4sIGNvbnN0IHVpbnRtYXhfdCBtYXgpOwogaW50CWdldGVudl9pbnQoY29uc3Qg Y2hhciAqbmFtZSwgaW50ICpkYXRhKTsKIGludAlnZXRlbnZfdWludChjb25zdCBjaGFyICpuYW1l LCB1bnNpZ25lZCBpbnQgKmRhdGEpOwogaW50CWdldGVudl9sb25nKGNvbnN0IGNoYXIgKm5hbWUs IGxvbmcgKmRhdGEpOwogaW50CWdldGVudl91bG9uZyhjb25zdCBjaGFyICpuYW1lLCB1bnNpZ25l ZCBsb25nICpkYXRhKTsKLWludAlnZXRlbnZfc3RyaW5nKGNvbnN0IGNoYXIgKm5hbWUsIGNoYXIg KmRhdGEsIGludCBzaXplKTsKK2ludAlnZXRlbnZfcG9pbnRlcihjb25zdCBjaGFyICpuYW1lLCB1 aW50cHRyX3QgKmRhdGEpOwogaW50CWdldGVudl9xdWFkKGNvbnN0IGNoYXIgKm5hbWUsIHF1YWRf dCAqZGF0YSk7CitpbnQJZ2V0ZW52X3VxdWFkKGNvbnN0IGNoYXIgKm5hbWUsIHVxdWFkX3QgKmRh dGEpOworaW50CWdldGVudl9zaXplKGNvbnN0IGNoYXIgKm5hbWUsIHNpemVfdCAqZGF0YSk7Citp bnQJZ2V0ZW52X3N0cmluZyhjb25zdCBjaGFyICpuYW1lLCBjaGFyICpkYXRhLCBzaXplX3Qgc2l6 ZSk7CiBpbnQJc2V0ZW52KGNvbnN0IGNoYXIgKm5hbWUsIGNvbnN0IGNoYXIgKnZhbHVlKTsKIGlu dAl1bnNldGVudihjb25zdCBjaGFyICpuYW1lKTsKIGludAl0ZXN0ZW52KGNvbnN0IGNoYXIgKm5h bWUpOwpJbmRleDogc3lzL3N5cy90eXBlcy5oCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9zeXMvdHlwZXMu aAkocmV2aXNpb24gMjE0MjU4KQorKysgc3lzL3N5cy90eXBlcy5oCSh3b3JraW5nIGNvcHkpCkBA IC0xMTIsNiArMTEyLDcgQEAKIHR5cGVkZWYgX191aW50NjRfdAl1X2ludDY0X3Q7CiAKIHR5cGVk ZWYJX191aW50NjRfdAl1X3F1YWRfdDsJLyogcXVhZHMgKGRlcHJlY2F0ZWQpICovCit0eXBlZGVm CV9fdWludDY0X3QJdXF1YWRfdDsKIHR5cGVkZWYJX19pbnQ2NF90CXF1YWRfdDsKIHR5cGVkZWYJ cXVhZF90ICoJcWFkZHJfdDsKIApJbmRleDogdG9vbHMvcmVncmVzc2lvbi90dW5hYmxlcy91cXVh ZC90ZXN0X3VxdWFkX3R1bmFibGUuc2gKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gdG9vbHMvcmVncmVzc2lvbi90 dW5hYmxlcy91cXVhZC90ZXN0X3VxdWFkX3R1bmFibGUuc2gJKHJldmlzaW9uIDApCisrKyB0b29s cy9yZWdyZXNzaW9uL3R1bmFibGVzL3VxdWFkL3Rlc3RfdXF1YWRfdHVuYWJsZS5zaAkocmV2aXNp b24gMCkKQEAgLTAsMCArMSwzOCBAQAorIyEvYmluL3NoCisjCisjIEV4cGVjdGVkIHZhbHVlczoK KyMgKHVuc2V0KSAgICA6ICAgICAgICAgICAwCisjICAgICAgLTEgICAgOiAgIFVMT05HX01BWAor IyAgICAgICAwICAgIDogICAgICAgICAgIDAKKyMgICAgICA0MiAgICA6ICAgICAgICAgIDQyCisj IGFzZGYxMjM0ICAgOiAgICAgICAgICAgMCAocmVqZWN0KQorIyBMT05HX01BWCsxIDogIExPTkdf TUFYKzEKKyMgVUxPTkdfTUFYLTE6IFVMT05HX01BWC0xCisjIFVMT05HX01BWCsxOiAgIFVMT05H X01BWAorIworCitNT0ROQU1FPSIkKGJhc2VuYW1lICIkMCIgLnNoKSIKKwordGVzdF9tb2R1bGUo KSB7CisJa2xkbG9hZCAuLyRNT0ROQU1FLmtvCisJa2xkdW5sb2FkIC4vJE1PRE5BTUUua28KK30K KworY2FzZSAiJCgkKGRpcm5hbWUgIiQwIikvLi4vdG9vbHMvZ2V0d29yZHNpemUpIiBpbgorMzIp CisJTE9OR19NQVhfUExVU18xPTIxNDc0ODM2NDkKKwlVTE9OR19NQVhfTUlOVVNfMT00Mjk0OTY3 Mjk1CisJVUxPTkdfTUFYX1BMVVNfMT00Mjk0OTY3Mjk3CisJOzsKKzY0KQorCUxPTkdfTUFYX1BM VVNfMT05MjIzMzcyMDM2ODU0Nzc1ODA4CisJVUxPTkdfTUFYX01JTlVTXzE9MTg0NDY3NDQwNzM3 MDk1NTE2MTQKKwlVTE9OR19NQVhfUExVU18xPTE4NDQ2NzQ0MDczNzA5NTUxNjE2CisJOzsKK2Vz YWMKK2tlbnYgLXUgJE1PRE5BTUUudHVuYWJsZSAyPi9kZXYvbnVsbAordGVzdF9tb2R1bGUKK2Zv ciBpIGluIC0xIDAgNDIgYXNkZjEyMzQgJExPTkdfTUFYX1BMVVNfMSAkVUxPTkdfTUFYX01JTlVT XzEgJFVMT05HX01BWF9QTFVTXzE7IGRvCisJa2VudiAkTU9ETkFNRS50dW5hYmxlPSIkaSIKKwl0 ZXN0X21vZHVsZQorZG9uZQpJbmRleDogdG9vbHMvcmVncmVzc2lvbi90dW5hYmxlcy91cXVhZC90 ZXN0X3VxdWFkX3R1bmFibGUuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSB0b29scy9yZWdyZXNzaW9uL3R1bmFi bGVzL3VxdWFkL3Rlc3RfdXF1YWRfdHVuYWJsZS5jCShyZXZpc2lvbiAwKQorKysgdG9vbHMvcmVn cmVzc2lvbi90dW5hYmxlcy91cXVhZC90ZXN0X3VxdWFkX3R1bmFibGUuYwkocmV2aXNpb24gMCkK QEAgLTAsMCArMSwzMSBAQAorI2luY2x1ZGUgPHN5cy9wYXJhbS5oPgorI2luY2x1ZGUgPHN5cy90 eXBlcy5oPgorI2luY2x1ZGUgPHN5cy9wcm9jLmg+CisjaW5jbHVkZSA8c3lzL21vZHVsZS5oPgor I2luY2x1ZGUgPHN5cy9rZXJuZWwuaD4KKyNpbmNsdWRlIDxzeXMvc3lzdG0uaD4KKworI2RlZmlu ZSBNT0RVTEVfTkFNRQkidGVzdF91cXVhZF90dW5hYmxlIgorCitzdGF0aWMgdXF1YWRfdCB0dW5h YmxlID0gMDsKKworVFVOQUJMRV9VUVVBRCgidGVzdF91cXVhZF90dW5hYmxlLnR1bmFibGUiLCAm dHVuYWJsZSk7CisKK3N0YXRpYyBpbnQKK2xvYWQgKG1vZHVsZV90IG0sIGludCB3aGF0LCB2b2lk ICphcmcpCit7CisJc3dpdGNoICh3aGF0KSB7CisJY2FzZSBNT0RfTE9BRDoKKwkJcHJpbnRmKCIl czogJWx1XG4iLCBNT0RVTEVfTkFNRSwgdHVuYWJsZSk7CisJCWJyZWFrOworCX0KKwlyZXR1cm4g KDApOworfQorCitzdGF0aWMgbW9kdWxlZGF0YV90IHRlc3RfdXF1YWRfdHVuYWJsZV9tb2QgPSB7 CisJTU9EVUxFX05BTUUsCisJbG9hZCwKK307CitERUNMQVJFX01PRFVMRSh0ZXN0X3VxdWFkX3R1 bmFibGUsIHRlc3RfdXF1YWRfdHVuYWJsZV9tb2QsIFNJX1NVQl9LTEQsCisgICAgU0lfT1JERVJf QU5ZKTsKK01PRFVMRV9WRVJTSU9OKHRlc3RfdXF1YWRfdHVuYWJsZSwgMSk7CkluZGV4OiB0b29s cy9yZWdyZXNzaW9uL3R1bmFibGVzL3VxdWFkL01ha2VmaWxlCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHRvb2xz L3JlZ3Jlc3Npb24vdHVuYWJsZXMvdXF1YWQvTWFrZWZpbGUJKHJldmlzaW9uIDApCisrKyB0b29s cy9yZWdyZXNzaW9uL3R1bmFibGVzL3VxdWFkL01ha2VmaWxlCShyZXZpc2lvbiAwKQpAQCAtMCww ICsxLDQgQEAKK0tNT0Q9CXRlc3RfdXF1YWRfdHVuYWJsZQorU1JDUz0JdGVzdF91cXVhZF90dW5h YmxlLmMKKworLmluY2x1ZGUgPGJzZC5rbW9kLm1rPgpJbmRleDogdG9vbHMvcmVncmVzc2lvbi90 dW5hYmxlcy91aW50L3Rlc3RfdWludF90dW5hYmxlLnNoCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHRvb2xzL3Jl Z3Jlc3Npb24vdHVuYWJsZXMvdWludC90ZXN0X3VpbnRfdHVuYWJsZS5zaAkocmV2aXNpb24gMCkK KysrIHRvb2xzL3JlZ3Jlc3Npb24vdHVuYWJsZXMvdWludC90ZXN0X3VpbnRfdHVuYWJsZS5zaAko cmV2aXNpb24gMCkKQEAgLTAsMCArMSwyOSBAQAorIyEvYmluL3NoCisjCisjIEV4cGVjdGVkIHZh bHVlczoKKyMgKHVuc2V0KSAgIDogICAgICAgICAgMAorIyAgICAgIC0xICAgOiAgICAgICAgICAw IChyZWplY3QpIAorIyAgICAgICAwICAgOiAgICAgICAgICAwCisjICAgICAgNDIgICA6ICAgICAg ICAgNDIKKyMgYXNkZjEyMzQgIDogICAgICAgICAgMCAocmVqZWN0KQorIyBJTlRfTUFYKzEgOiAg SU5UX01BWCsxCisjIFVJTlRfTUFYLTE6IFVJTlRfTUFYLTEKKyMgVUlOVF9NQVgrMTogICAgICAg ICAgMCAocmVqZWN0KQorIworCitNT0ROQU1FPSIkKGJhc2VuYW1lICIkMCIgLnNoKSIKKwordGVz dF9tb2R1bGUoKSB7CisJa2xkbG9hZCAuLyRNT0ROQU1FLmtvCisJa2xkdW5sb2FkIC4vJE1PRE5B TUUua28KK30KKworSU5UX01BWF9QTFVTX09ORT0yMTQ3NDgzNjQ4CitVSU5UX01BWF9NSU5VU19P TkU9NDI5NDk2NzI5NAorVUlOVF9NQVhfUExVU19PTkU9NDI5NDk2NzI5Ngora2VudiAtdSAkTU9E TkFNRS50dW5hYmxlIDI+L2Rldi9udWxsCit0ZXN0X21vZHVsZQorZm9yIGkgaW4gLTEgMCA0MiBh c2RmMTIzNCAkSU5UX01BWF9QTFVTX09ORSAkVUlOVF9NQVhfTUlOVVNfT05FICRVSU5UX01BWF9Q TFVTX09ORTsgZG8KKwlrZW52ICRNT0ROQU1FLnR1bmFibGU9IiRpIgorCXRlc3RfbW9kdWxlCitk b25lCkluZGV4OiB0b29scy9yZWdyZXNzaW9uL3R1bmFibGVzL3VpbnQvdGVzdF91aW50X3R1bmFi bGUuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09Ci0tLSB0b29scy9yZWdyZXNzaW9uL3R1bmFibGVzL3VpbnQvdGVzdF91 aW50X3R1bmFibGUuYwkocmV2aXNpb24gMCkKKysrIHRvb2xzL3JlZ3Jlc3Npb24vdHVuYWJsZXMv dWludC90ZXN0X3VpbnRfdHVuYWJsZS5jCShyZXZpc2lvbiAwKQpAQCAtMCwwICsxLDMxIEBACisj aW5jbHVkZSA8c3lzL3BhcmFtLmg+CisjaW5jbHVkZSA8c3lzL3R5cGVzLmg+CisjaW5jbHVkZSA8 c3lzL3Byb2MuaD4KKyNpbmNsdWRlIDxzeXMvbW9kdWxlLmg+CisjaW5jbHVkZSA8c3lzL2tlcm5l bC5oPgorI2luY2x1ZGUgPHN5cy9zeXN0bS5oPgorCisjZGVmaW5lIE1PRFVMRV9OQU1FCSJ0ZXN0 X3VpbnRfdHVuYWJsZSIKKworc3RhdGljIHVuc2lnbmVkIGludCB0dW5hYmxlID0gMDsKKworVFVO QUJMRV9VSU5UKCJ0ZXN0X3VpbnRfdHVuYWJsZS50dW5hYmxlIiwgJnR1bmFibGUpOworCitzdGF0 aWMgaW50Citsb2FkIChtb2R1bGVfdCBtLCBpbnQgd2hhdCwgdm9pZCAqYXJnKQoreworCXN3aXRj aCAod2hhdCkgeworCWNhc2UgTU9EX0xPQUQ6CisJCXByaW50ZigiJXM6ICV1XG4iLCBNT0RVTEVf TkFNRSwgdHVuYWJsZSk7CisJCWJyZWFrOworCX0KKwlyZXR1cm4gKDApOworfQorCitzdGF0aWMg bW9kdWxlZGF0YV90IHRlc3RfdWludF90dW5hYmxlX21vZCA9IHsKKwlNT0RVTEVfTkFNRSwKKwls b2FkLAorfTsKK0RFQ0xBUkVfTU9EVUxFKHRlc3RfdWludF90dW5hYmxlLCB0ZXN0X3VpbnRfdHVu YWJsZV9tb2QsIFNJX1NVQl9LTEQsCisgICAgU0lfT1JERVJfQU5ZKTsKK01PRFVMRV9WRVJTSU9O KHRlc3RfdWludF90dW5hYmxlLCAxKTsKSW5kZXg6IHRvb2xzL3JlZ3Jlc3Npb24vdHVuYWJsZXMv dWludC9NYWtlZmlsZQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSB0b29scy9yZWdyZXNzaW9uL3R1bmFibGVzL3Vp bnQvTWFrZWZpbGUJKHJldmlzaW9uIDApCisrKyB0b29scy9yZWdyZXNzaW9uL3R1bmFibGVzL3Vp bnQvTWFrZWZpbGUJKHJldmlzaW9uIDApCkBAIC0wLDAgKzEsNCBAQAorS01PRD0JdGVzdF91aW50 X3R1bmFibGUKK1NSQ1M9CXRlc3RfdWludF90dW5hYmxlLmMKKworLmluY2x1ZGUgPGJzZC5rbW9k Lm1rPgpJbmRleDogdG9vbHMvcmVncmVzc2lvbi90dW5hYmxlcy90b29scy9nZXR3b3Jkc2l6ZS5j Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT0KLS0tIHRvb2xzL3JlZ3Jlc3Npb24vdHVuYWJsZXMvdG9vbHMvZ2V0d29yZHNp emUuYwkocmV2aXNpb24gMCkKKysrIHRvb2xzL3JlZ3Jlc3Npb24vdHVuYWJsZXMvdG9vbHMvZ2V0 d29yZHNpemUuYwkocmV2aXNpb24gMCkKQEAgLTAsMCArMSw5IEBACisjaW5jbHVkZSA8c3lzL2Vs Zi5oPgorI2luY2x1ZGUgPHN0ZGlvLmg+CisKK2ludAorbWFpbih2b2lkKQoreworCXByaW50Zigi JWRcbiIsIF9fRUxGX1dPUkRfU0laRSk7CisJcmV0dXJuICgwKTsKK30KSW5kZXg6IHRvb2xzL3Jl Z3Jlc3Npb24vdHVuYWJsZXMvdG9vbHMvTWFrZWZpbGUKPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gdG9vbHMvcmVn cmVzc2lvbi90dW5hYmxlcy90b29scy9NYWtlZmlsZQkocmV2aXNpb24gMCkKKysrIHRvb2xzL3Jl Z3Jlc3Npb24vdHVuYWJsZXMvdG9vbHMvTWFrZWZpbGUJKHJldmlzaW9uIDApCkBAIC0wLDAgKzEs NyBAQAorUFJPRz0JCWdldHdvcmRzaXplCisKK1NSQ1M9CQlnZXR3b3Jkc2l6ZS5jCisKK05PX01B Tj0JCTEKKworLmluY2x1ZGUgPGJzZC5wcm9nLm1rPgpJbmRleDogdG9vbHMvcmVncmVzc2lvbi90 dW5hYmxlcy91bG9uZy90ZXN0X3Vsb25nX3R1bmFibGUuc2gKPT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gdG9vbHMv cmVncmVzc2lvbi90dW5hYmxlcy91bG9uZy90ZXN0X3Vsb25nX3R1bmFibGUuc2gJKHJldmlzaW9u IDApCisrKyB0b29scy9yZWdyZXNzaW9uL3R1bmFibGVzL3Vsb25nL3Rlc3RfdWxvbmdfdHVuYWJs ZS5zaAkocmV2aXNpb24gMCkKQEAgLTAsMCArMSwzOCBAQAorIyEvYmluL3NoCisjCisjIEV4cGVj dGVkIHZhbHVlczoKKyMgKHVuc2V0KSAgICA6ICAgICAgICAgICAwCisjICAgICAgLTEgICAgOiAg IFVMT05HX01BWAorIyAgICAgICAwICAgIDogICAgICAgICAgIDAKKyMgICAgICA0MiAgICA6ICAg ICAgICAgIDQyCisjIGFzZGYxMjM0ICAgOiAgICAgICAgICAgMCAocmVqZWN0KQorIyBMT05HX01B WCsxIDogIExPTkdfTUFYKzEKKyMgVUxPTkdfTUFYLTE6IFVMT05HX01BWC0xCisjIFVMT05HX01B WCsxOiAgIFVMT05HX01BWAorIworCitNT0ROQU1FPSIkKGJhc2VuYW1lICIkMCIgLnNoKSIKKwor dGVzdF9tb2R1bGUoKSB7CisJa2xkbG9hZCAuLyRNT0ROQU1FLmtvCisJa2xkdW5sb2FkIC4vJE1P RE5BTUUua28KK30KKworY2FzZSAiJCgkKGRpcm5hbWUgIiQwIikvLi4vdG9vbHMvZ2V0d29yZHNp emUpIiBpbgorMzIpCisJTE9OR19NQVhfUExVU18xPTIxNDc0ODM2NDkKKwlVTE9OR19NQVhfTUlO VVNfMT00Mjk0OTY3Mjk1CisJVUxPTkdfTUFYX1BMVVNfMT00Mjk0OTY3Mjk3CisJOzsKKzY0KQor CUxPTkdfTUFYX1BMVVNfMT05MjIzMzcyMDM2ODU0Nzc1ODA4CisJVUxPTkdfTUFYX01JTlVTXzE9 MTg0NDY3NDQwNzM3MDk1NTE2MTQKKwlVTE9OR19NQVhfUExVU18xPTE4NDQ2NzQ0MDczNzA5NTUx NjE2CisJOzsKK2VzYWMKK2tlbnYgLXUgJE1PRE5BTUUudHVuYWJsZSAyPi9kZXYvbnVsbAordGVz dF9tb2R1bGUKK2ZvciBpIGluIC0xIDAgNDIgYXNkZjEyMzQgJExPTkdfTUFYX1BMVVNfMSAkVUxP TkdfTUFYX01JTlVTXzEgJFVMT05HX01BWF9QTFVTXzE7IGRvCisJa2VudiAkTU9ETkFNRS50dW5h YmxlPSIkaSIKKwl0ZXN0X21vZHVsZQorZG9uZQpJbmRleDogdG9vbHMvcmVncmVzc2lvbi90dW5h Ymxlcy91bG9uZy9NYWtlZmlsZQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSB0b29scy9yZWdyZXNzaW9uL3R1bmFi bGVzL3Vsb25nL01ha2VmaWxlCShyZXZpc2lvbiAwKQorKysgdG9vbHMvcmVncmVzc2lvbi90dW5h Ymxlcy91bG9uZy9NYWtlZmlsZQkocmV2aXNpb24gMCkKQEAgLTAsMCArMSw0IEBACitLTU9EPQl0 ZXN0X3Vsb25nX3R1bmFibGUKK1NSQ1M9CXRlc3RfdWxvbmdfdHVuYWJsZS5jCisKKy5pbmNsdWRl IDxic2Qua21vZC5taz4KSW5kZXg6IHRvb2xzL3JlZ3Jlc3Npb24vdHVuYWJsZXMvdWxvbmcvdGVz dF91bG9uZ190dW5hYmxlLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gdG9vbHMvcmVncmVzc2lvbi90dW5hYmxl cy91bG9uZy90ZXN0X3Vsb25nX3R1bmFibGUuYwkocmV2aXNpb24gMCkKKysrIHRvb2xzL3JlZ3Jl c3Npb24vdHVuYWJsZXMvdWxvbmcvdGVzdF91bG9uZ190dW5hYmxlLmMJKHJldmlzaW9uIDApCkBA IC0wLDAgKzEsMzEgQEAKKyNpbmNsdWRlIDxzeXMvcGFyYW0uaD4KKyNpbmNsdWRlIDxzeXMvdHlw ZXMuaD4KKyNpbmNsdWRlIDxzeXMvcHJvYy5oPgorI2luY2x1ZGUgPHN5cy9tb2R1bGUuaD4KKyNp bmNsdWRlIDxzeXMva2VybmVsLmg+CisjaW5jbHVkZSA8c3lzL3N5c3RtLmg+CisKKyNkZWZpbmUg TU9EVUxFX05BTUUJInRlc3RfdWxvbmdfdHVuYWJsZSIKKworc3RhdGljIHVuc2lnbmVkIGxvbmcg dHVuYWJsZSA9IDA7CisKK1RVTkFCTEVfVUxPTkcoInRlc3RfdWxvbmdfdHVuYWJsZS50dW5hYmxl IiwgJnR1bmFibGUpOworCitzdGF0aWMgaW50Citsb2FkIChtb2R1bGVfdCBtLCBpbnQgd2hhdCwg dm9pZCAqYXJnKQoreworCXN3aXRjaCAod2hhdCkgeworCWNhc2UgTU9EX0xPQUQ6CisJCXByaW50 ZigiJXM6ICVsdVxuIiwgTU9EVUxFX05BTUUsIHR1bmFibGUpOworCQlicmVhazsKKwl9CisJcmV0 dXJuICgwKTsKK30KKworc3RhdGljIG1vZHVsZWRhdGFfdCB0ZXN0X3Vsb25nX3R1bmFibGVfbW9k ID0geworCU1PRFVMRV9OQU1FLAorCWxvYWQsCit9OworREVDTEFSRV9NT0RVTEUodGVzdF91bG9u Z190dW5hYmxlLCB0ZXN0X3Vsb25nX3R1bmFibGVfbW9kLCBTSV9TVUJfS0xELAorICAgIFNJX09S REVSX0FOWSk7CitNT0RVTEVfVkVSU0lPTih0ZXN0X3Vsb25nX3R1bmFibGUsIDEpOwpJbmRleDog dG9vbHMvcmVncmVzc2lvbi90dW5hYmxlcy9zdWZmaXgvdGVzdF90dW5hYmxlX3N1ZmZpeGVzLmMK PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PQotLS0gdG9vbHMvcmVncmVzc2lvbi90dW5hYmxlcy9zdWZmaXgvdGVzdF90dW5h YmxlX3N1ZmZpeGVzLmMJKHJldmlzaW9uIDApCisrKyB0b29scy9yZWdyZXNzaW9uL3R1bmFibGVz L3N1ZmZpeC90ZXN0X3R1bmFibGVfc3VmZml4ZXMuYwkocmV2aXNpb24gMCkKQEAgLTAsMCArMSwz MSBAQAorI2luY2x1ZGUgPHN5cy9wYXJhbS5oPgorI2luY2x1ZGUgPHN5cy90eXBlcy5oPgorI2lu Y2x1ZGUgPHN5cy9wcm9jLmg+CisjaW5jbHVkZSA8c3lzL21vZHVsZS5oPgorI2luY2x1ZGUgPHN5 cy9rZXJuZWwuaD4KKyNpbmNsdWRlIDxzeXMvc3lzdG0uaD4KKworI2RlZmluZSBNT0RVTEVfTkFN RQkidGVzdF90dW5hYmxlX3N1ZmZpeGVzIgorCitzdGF0aWMgbG9uZyB0dW5hYmxlID0gMDsKKwor VFVOQUJMRV9MT05HKCJ0ZXN0X3R1bmFibGVfc3VmZml4ZXMudHVuYWJsZSIsICZ0dW5hYmxlKTsK Kworc3RhdGljIGludAorbG9hZCAoc3RydWN0IG1vZHVsZSAqbSwgaW50IHdoYXQsIHZvaWQgKmFy ZykKK3sKKwlzd2l0Y2ggKHdoYXQpIHsKKwljYXNlIE1PRF9MT0FEOgorCQlwcmludGYoIiVzOiAl bGRcbiIsIE1PRFVMRV9OQU1FLCB0dW5hYmxlKTsKKwkJYnJlYWs7CisJfQorCXJldHVybiAoMCk7 Cit9CisKK3N0YXRpYyBtb2R1bGVkYXRhX3QgdGVzdF90dW5hYmxlX3N1ZmZpeGVzX21vZCA9IHsK KwlNT0RVTEVfTkFNRSwKKwlsb2FkLAorfTsKK0RFQ0xBUkVfTU9EVUxFKHRlc3RfdHVuYWJsZV9z dWZmaXhlcywgdGVzdF90dW5hYmxlX3N1ZmZpeGVzX21vZCwgU0lfU1VCX0tMRCwKKyAgICBTSV9P UkRFUl9BTlkpOworTU9EVUxFX1ZFUlNJT04odGVzdF90dW5hYmxlX3N1ZmZpeGVzLCAxKTsKSW5k ZXg6IHRvb2xzL3JlZ3Jlc3Npb24vdHVuYWJsZXMvc3VmZml4L01ha2VmaWxlCj09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0K LS0tIHRvb2xzL3JlZ3Jlc3Npb24vdHVuYWJsZXMvc3VmZml4L01ha2VmaWxlCShyZXZpc2lvbiAw KQorKysgdG9vbHMvcmVncmVzc2lvbi90dW5hYmxlcy9zdWZmaXgvTWFrZWZpbGUJKHJldmlzaW9u IDApCkBAIC0wLDAgKzEsNCBAQAorS01PRD0JdGVzdF90dW5hYmxlX3N1ZmZpeGVzCitTUkNTPQl0 ZXN0X3R1bmFibGVfc3VmZml4ZXMuYworCisuaW5jbHVkZSA8YnNkLmttb2QubWs+CkluZGV4OiB0 b29scy9yZWdyZXNzaW9uL3R1bmFibGVzL3N1ZmZpeC90ZXN0X3R1bmFibGVfc3VmZml4ZXMuc2gK PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PQotLS0gdG9vbHMvcmVncmVzc2lvbi90dW5hYmxlcy9zdWZmaXgvdGVzdF90dW5h YmxlX3N1ZmZpeGVzLnNoCShyZXZpc2lvbiAwKQorKysgdG9vbHMvcmVncmVzc2lvbi90dW5hYmxl cy9zdWZmaXgvdGVzdF90dW5hYmxlX3N1ZmZpeGVzLnNoCShyZXZpc2lvbiAwKQpAQCAtMCwwICsx LDQxIEBACisjIS9iaW4vc2gKKyMKKyMgRXhwZWN0ZWQgdmFsdWVzOgorIyAodW5zZXQpICAgOiAg ICAgICAgICAgMAorIyAgICAgICAgIC0xOiAgICAgICAgICAtMQorIyAgICAgICAgLTFnOiAgICAg LTEwMjReMworIyAgICAgICAgLTFHOiAgICAgLTEwMjReMyAoc2FtZSBhcyAxZykgCisjICAgICAg ICAtMWs6ICAgICAgIC0xMDI0CisjICAgICAgICAtMUs6ICAgICAgIC0xMDI0IChzYW1lIGFzIDFL KQorIyAgICAgICAgLTFtOiAgICAgLTEwMjReMgorIyAgICAgICAgLTFNOiAgICAgLTEwMjReMiAo c2FtZSBhcyAxbSkKKyMgICAgICAgIC0xdDogICAgIC0xMDI0XjQKKyMgICAgICAgIC0xVDogICAg IC0xMDI0XjQgKHNhbWUgYXMgMXQpCisjICAgICAgICAtMXo6ICAgICAgICAgICAwIChyZWplY3Qp CisjICAgICAgICAgIDE6ICAgICAgICAgICAxCisjICAgICAgICAgMWc6ICAgICAgMTAyNF4zCisj ICAgICAgICAgMUc6ICAgICAgMTAyNF4zIChzYW1lIGFzIDFnKSAKKyMgICAgICAgICAxazogICAg ICAgIDEwMjQKKyMgICAgICAgICAxSzogICAgICAgIDEwMjQgKHNhbWUgYXMgMUspCisjICAgICAg ICAgMW06ICAgICAgMTAyNF4yCisjICAgICAgICAgMU06ICAgICAgMTAyNF4yIChzYW1lIGFzIDFt KQorIyAgICAgICAgIDF0OiAgICAgIDEwMjReNAorIyAgICAgICAgIDFUOiAgICAgIDEwMjReNCAo c2FtZSBhcyAxdCkKKyMgICAgICAgICAxejogICAgICAgICAgIDAgKHJlamVjdCkKKyMgICAgICAg ICAxVDogICAgICAgICAgIDAgKHJlamVjdCkKKworTU9ETkFNRT0iJChiYXNlbmFtZSAiJDAiIC5z aCkiCisKK3Rlc3RfbW9kdWxlKCkgeworCWtsZGxvYWQgLi8kTU9ETkFNRS5rbworCWtsZHVubG9h ZCAuLyRNT0ROQU1FLmtvCit9CisKK2tlbnYgLXUgJE1PRE5BTUUudHVuYWJsZSAyPi9kZXYvbnVs bAordGVzdF9tb2R1bGUKK2ZvciBpIGluIC0xIDAgMTsgZG8KKwlmb3IgaiBpbiAnJyBnIEcgayBL IG0gTSB0IFQgeiBaOyBkbworCQlrZW52ICRNT0ROQU1FLnR1bmFibGU9IiRpJGoiCisJCXRlc3Rf bW9kdWxlCisJZG9uZQorZG9uZQpJbmRleDogdG9vbHMvcmVncmVzc2lvbi90dW5hYmxlcy9zdHJp bmcvdGVzdF9zdHJpbmdfdHVuYWJsZS5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHRvb2xzL3JlZ3Jlc3Npb24v dHVuYWJsZXMvc3RyaW5nL3Rlc3Rfc3RyaW5nX3R1bmFibGUuYwkocmV2aXNpb24gMCkKKysrIHRv b2xzL3JlZ3Jlc3Npb24vdHVuYWJsZXMvc3RyaW5nL3Rlc3Rfc3RyaW5nX3R1bmFibGUuYwkocmV2 aXNpb24gMCkKQEAgLTAsMCArMSwzMSBAQAorI2luY2x1ZGUgPHN5cy9wYXJhbS5oPgorI2luY2x1 ZGUgPHN5cy90eXBlcy5oPgorI2luY2x1ZGUgPHN5cy9wcm9jLmg+CisjaW5jbHVkZSA8c3lzL21v ZHVsZS5oPgorI2luY2x1ZGUgPHN5cy9rZXJuZWwuaD4KKyNpbmNsdWRlIDxzeXMvc3lzdG0uaD4K KworI2RlZmluZSBNT0RVTEVfTkFNRQkidGVzdF9zdHJpbmdfdHVuYWJsZSIKKworc3RhdGljIGNo YXIgdHVuYWJsZVsxMF07CisKK1RVTkFCTEVfU1RSKCJ0ZXN0X3N0cmluZ190dW5hYmxlLnR1bmFi bGUiLCB0dW5hYmxlLCBzaXplb2YodHVuYWJsZSkpOworCitzdGF0aWMgaW50Citsb2FkIChtb2R1 bGVfdCBtLCBpbnQgd2hhdCwgdm9pZCAqYXJnKQoreworCXN3aXRjaCAod2hhdCkgeworCWNhc2Ug TU9EX0xPQUQ6CisJCXByaW50ZigiJXM6ICVzXG4iLCBNT0RVTEVfTkFNRSwgdHVuYWJsZSk7CisJ CWJyZWFrOworCX0KKwlyZXR1cm4gKDApOworfQorCitzdGF0aWMgbW9kdWxlZGF0YV90IHRlc3Rf c3RyaW5nX3R1bmFibGVfbW9kID0geworCU1PRFVMRV9OQU1FLAorCWxvYWQsCit9OworREVDTEFS RV9NT0RVTEUodGVzdF9zdHJpbmdfdHVuYWJsZSwgdGVzdF9zdHJpbmdfdHVuYWJsZV9tb2QsIFNJ X1NVQl9LTEQsCisgICAgU0lfT1JERVJfQU5ZKTsKK01PRFVMRV9WRVJTSU9OKHRlc3Rfc3RyaW5n X3R1bmFibGUsIDEpOwpJbmRleDogdG9vbHMvcmVncmVzc2lvbi90dW5hYmxlcy9zdHJpbmcvdGVz dF9zdHJpbmdfdHVuYWJsZS5zaAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSB0b29scy9yZWdyZXNzaW9uL3R1bmFi bGVzL3N0cmluZy90ZXN0X3N0cmluZ190dW5hYmxlLnNoCShyZXZpc2lvbiAwKQorKysgdG9vbHMv cmVncmVzc2lvbi90dW5hYmxlcy9zdHJpbmcvdGVzdF9zdHJpbmdfdHVuYWJsZS5zaAkocmV2aXNp b24gMCkKQEAgLTAsMCArMSwyMiBAQAorIyEvYmluL3NoCisjCisjIEV4cGVjdGVkIHZhbHVlczoK KyMgKHVuc2V0KSAgICAgICAgICAgICAgOiAgICAgICAgICAiIgorIyAiIiAgICAgICAgICAgICAg ICAgICA6ICAgICAgICAgICIiCisjIGFzZGYxMjM0ICAgICAgICAgICAgIDogICAgYXNkZjEyMzQK KyMgY2hhcmFjdGVyICAgICAgICAgICAgOiAgIGNoYXJhY3RlcgorIyBhc29ydG9mbG9uZ2lzaHN0 cmluZyA6ICAgYXNvcnRvZmxvCisjCisKK01PRE5BTUU9IiQoYmFzZW5hbWUgIiQwIiAuc2gpIgor Cit0ZXN0X21vZHVsZSgpIHsKKwlrbGRsb2FkIC4vJE1PRE5BTUUua28KKwlrbGR1bmxvYWQgLi8k TU9ETkFNRS5rbworfQorCit0ZXN0X21vZHVsZQorZm9yIGkgaW4gIiIgYXNkZjEyMzQgY2hhcmFj dGVyIGFzb3J0b2Zsb25naXNoc3RyaW5nOyBkbworCWtlbnYgJE1PRE5BTUUudHVuYWJsZT0iJGki CisJdGVzdF9tb2R1bGUKK2RvbmUKSW5kZXg6IHRvb2xzL3JlZ3Jlc3Npb24vdHVuYWJsZXMvc3Ry aW5nL01ha2VmaWxlCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHRvb2xzL3JlZ3Jlc3Npb24vdHVuYWJsZXMvc3Ry aW5nL01ha2VmaWxlCShyZXZpc2lvbiAwKQorKysgdG9vbHMvcmVncmVzc2lvbi90dW5hYmxlcy9z dHJpbmcvTWFrZWZpbGUJKHJldmlzaW9uIDApCkBAIC0wLDAgKzEsNCBAQAorS01PRD0JdGVzdF9z dHJpbmdfdHVuYWJsZQorU1JDUz0JdGVzdF9zdHJpbmdfdHVuYWJsZS5jCisKKy5pbmNsdWRlIDxi c2Qua21vZC5taz4KSW5kZXg6IHRvb2xzL3JlZ3Jlc3Npb24vdHVuYWJsZXMvc2l6ZS90ZXN0X3Np emVfdHVuYWJsZS5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHRvb2xzL3JlZ3Jlc3Npb24vdHVuYWJsZXMvc2l6 ZS90ZXN0X3NpemVfdHVuYWJsZS5jCShyZXZpc2lvbiAwKQorKysgdG9vbHMvcmVncmVzc2lvbi90 dW5hYmxlcy9zaXplL3Rlc3Rfc2l6ZV90dW5hYmxlLmMJKHJldmlzaW9uIDApCkBAIC0wLDAgKzEs MzEgQEAKKyNpbmNsdWRlIDxzeXMvcGFyYW0uaD4KKyNpbmNsdWRlIDxzeXMvdHlwZXMuaD4KKyNp bmNsdWRlIDxzeXMvcHJvYy5oPgorI2luY2x1ZGUgPHN5cy9tb2R1bGUuaD4KKyNpbmNsdWRlIDxz eXMva2VybmVsLmg+CisjaW5jbHVkZSA8c3lzL3N5c3RtLmg+CisKKyNkZWZpbmUgTU9EVUxFX05B TUUJInRlc3Rfc2l6ZV90dW5hYmxlIgorCitzdGF0aWMgc2l6ZV90IHR1bmFibGUgPSAwOworCitU VU5BQkxFX1NJWkUoInRlc3Rfc2l6ZV90dW5hYmxlLnR1bmFibGUiLCAmdHVuYWJsZSk7CisKK3N0 YXRpYyBpbnQKK2xvYWQgKG1vZHVsZV90IG0sIGludCB3aGF0LCB2b2lkICphcmcpCit7CisJc3dp dGNoICh3aGF0KSB7CisJY2FzZSBNT0RfTE9BRDoKKwkJcHJpbnRmKCIlczogJXp1XG4iLCBNT0RV TEVfTkFNRSwgdHVuYWJsZSk7CisJCWJyZWFrOworCX0KKwlyZXR1cm4gKDApOworfQorCitzdGF0 aWMgbW9kdWxlZGF0YV90IHRlc3Rfc2l6ZV90dW5hYmxlX21vZCA9IHsKKwlNT0RVTEVfTkFNRSwK Kwlsb2FkLAorfTsKK0RFQ0xBUkVfTU9EVUxFKHRlc3Rfc2l6ZV90dW5hYmxlLCB0ZXN0X3NpemVf dHVuYWJsZV9tb2QsIFNJX1NVQl9LTEQsCisgICAgU0lfT1JERVJfQU5ZKTsKK01PRFVMRV9WRVJT SU9OKHRlc3Rfc2l6ZV90dW5hYmxlLCAxKTsKSW5kZXg6IHRvb2xzL3JlZ3Jlc3Npb24vdHVuYWJs ZXMvc2l6ZS90ZXN0X3NpemVfdHVuYWJsZS5zaAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSB0b29scy9yZWdyZXNz aW9uL3R1bmFibGVzL3NpemUvdGVzdF9zaXplX3R1bmFibGUuc2gJKHJldmlzaW9uIDApCisrKyB0 b29scy9yZWdyZXNzaW9uL3R1bmFibGVzL3NpemUvdGVzdF9zaXplX3R1bmFibGUuc2gJKHJldmlz aW9uIDApCkBAIC0wLDAgKzEsMzggQEAKKyMhL2Jpbi9zaAorIworIyBFeHBlY3RlZCB2YWx1ZXM6 CisjICh1bnNldCkgICAgOiAgICAgICAgICAgMAorIyAgICAgIC0xICAgIDogICBVTE9OR19NQVgK KyMgICAgICAgMCAgICA6ICAgICAgICAgICAwCisjICAgICAgNDIgICAgOiAgICAgICAgICA0Mgor IyBhc2RmMTIzNCAgIDogICAgICAgICAgIDAgKHJlamVjdCkKKyMgTE9OR19NQVgrMSA6ICBMT05H X01BWCsxCisjIFVMT05HX01BWC0xOiBVTE9OR19NQVgtMQorIyBVTE9OR19NQVgrMTogICBVTE9O R19NQVgKKyMKKworTU9ETkFNRT0iJChiYXNlbmFtZSAiJDAiIC5zaCkiCisKK3Rlc3RfbW9kdWxl KCkgeworCWtsZGxvYWQgLi8kTU9ETkFNRS5rbworCWtsZHVubG9hZCAuLyRNT0ROQU1FLmtvCit9 CisKK2Nhc2UgIiQoJChkaXJuYW1lICIkMCIpLy4uL3Rvb2xzL2dldHdvcmRzaXplKSIgaW4KKzMy KQorCUxPTkdfTUFYX1BMVVNfMT0yMTQ3NDgzNjQ5CisJVUxPTkdfTUFYX01JTlVTXzE9NDI5NDk2 NzI5NQorCVVMT05HX01BWF9QTFVTXzE9NDI5NDk2NzI5NworCTs7Cis2NCkKKwlMT05HX01BWF9Q TFVTXzE9OTIyMzM3MjAzNjg1NDc3NTgwOAorCVVMT05HX01BWF9NSU5VU18xPTE4NDQ2NzQ0MDcz NzA5NTUxNjE0CisJVUxPTkdfTUFYX1BMVVNfMT0xODQ0Njc0NDA3MzcwOTU1MTYxNgorCTs7Citl c2FjCitrZW52IC11ICRNT0ROQU1FLnR1bmFibGUgMj4vZGV2L251bGwKK3Rlc3RfbW9kdWxlCitm b3IgaSBpbiAtMSAwIDQyIGFzZGYxMjM0ICRMT05HX01BWF9QTFVTXzEgJFVMT05HX01BWF9NSU5V U18xICRVTE9OR19NQVhfUExVU18xOyBkbworCWtlbnYgJE1PRE5BTUUudHVuYWJsZT0iJGkiCisJ dGVzdF9tb2R1bGUKK2RvbmUKSW5kZXg6IHRvb2xzL3JlZ3Jlc3Npb24vdHVuYWJsZXMvc2l6ZS9N YWtlZmlsZQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09Ci0tLSB0b29scy9yZWdyZXNzaW9uL3R1bmFibGVzL3NpemUvTWFr ZWZpbGUJKHJldmlzaW9uIDApCisrKyB0b29scy9yZWdyZXNzaW9uL3R1bmFibGVzL3NpemUvTWFr ZWZpbGUJKHJldmlzaW9uIDApCkBAIC0wLDAgKzEsNCBAQAorS01PRD0JdGVzdF9zaXplX3R1bmFi bGUKK1NSQ1M9CXRlc3Rfc2l6ZV90dW5hYmxlLmMKKworLmluY2x1ZGUgPGJzZC5rbW9kLm1rPgpJ bmRleDogdG9vbHMvcmVncmVzc2lvbi90dW5hYmxlcy9xdWFkL3Rlc3RfcXVhZF90dW5hYmxlLmMK PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PQotLS0gdG9vbHMvcmVncmVzc2lvbi90dW5hYmxlcy9xdWFkL3Rlc3RfcXVhZF90 dW5hYmxlLmMJKHJldmlzaW9uIDApCisrKyB0b29scy9yZWdyZXNzaW9uL3R1bmFibGVzL3F1YWQv dGVzdF9xdWFkX3R1bmFibGUuYwkocmV2aXNpb24gMCkKQEAgLTAsMCArMSwzMSBAQAorI2luY2x1 ZGUgPHN5cy9wYXJhbS5oPgorI2luY2x1ZGUgPHN5cy90eXBlcy5oPgorI2luY2x1ZGUgPHN5cy9w cm9jLmg+CisjaW5jbHVkZSA8c3lzL21vZHVsZS5oPgorI2luY2x1ZGUgPHN5cy9rZXJuZWwuaD4K KyNpbmNsdWRlIDxzeXMvc3lzdG0uaD4KKworI2RlZmluZSBNT0RVTEVfTkFNRQkidGVzdF9xdWFk X3R1bmFibGUiCisKK3N0YXRpYyBxdWFkX3QgdHVuYWJsZSA9IDA7CisKK1RVTkFCTEVfUVVBRCgi dGVzdF9xdWFkX3R1bmFibGUudHVuYWJsZSIsICZ0dW5hYmxlKTsKKworc3RhdGljIGludAorbG9h ZCAobW9kdWxlX3QgbSwgaW50IHdoYXQsIHZvaWQgKmFyZykKK3sKKwlzd2l0Y2ggKHdoYXQpIHsK KwljYXNlIE1PRF9MT0FEOgorCQlwcmludGYoIiVzOiAlbGRcbiIsIE1PRFVMRV9OQU1FLCB0dW5h YmxlKTsKKwkJYnJlYWs7CisJfQorCXJldHVybiAoMCk7Cit9CisKK3N0YXRpYyBtb2R1bGVkYXRh X3QgdGVzdF9xdWFkX3R1bmFibGVfbW9kID0geworCU1PRFVMRV9OQU1FLAorCWxvYWQsCit9Owor REVDTEFSRV9NT0RVTEUodGVzdF9xdWFkX3R1bmFibGUsIHRlc3RfcXVhZF90dW5hYmxlX21vZCwg U0lfU1VCX0tMRCwKKyAgICBTSV9PUkRFUl9BTlkpOworTU9EVUxFX1ZFUlNJT04odGVzdF9xdWFk X3R1bmFibGUsIDEpOwpJbmRleDogdG9vbHMvcmVncmVzc2lvbi90dW5hYmxlcy9xdWFkL3Rlc3Rf cXVhZF90dW5hYmxlLnNoCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHRvb2xzL3JlZ3Jlc3Npb24vdHVuYWJsZXMv cXVhZC90ZXN0X3F1YWRfdHVuYWJsZS5zaAkocmV2aXNpb24gMCkKKysrIHRvb2xzL3JlZ3Jlc3Np b24vdHVuYWJsZXMvcXVhZC90ZXN0X3F1YWRfdHVuYWJsZS5zaAkocmV2aXNpb24gMCkKQEAgLTAs MCArMSw0MCBAQAorIyEvYmluL3NoCisjCisjIEV4cGVjdGVkIHZhbHVlczoKKyMgKHVuc2V0KSAg ICA6ICAgICAgICAgICAwCisjICAgICAgIDAgICAgOiAgICAgICAgICAgMAorIyAgICAgIDQyICAg IDogICAgICAgICAgNDIKKyMgYXNkZjEyMzQgICA6ICAgICAgICAgICAwIChyZWplY3QpCisjIExP TkdfTUlOLTEgOiAgTE9OR19NSU4KKyMgTE9OR19NSU4rMSA6ICBMT05HX01JTisxCisjIExPTkdf TUFYLTEgOiAgTE9OR19NQVgtMQorIyBMT05HX01BWCsxIDogIExPTkdfTUFYCisjCisKK01PRE5B TUU9IiQoYmFzZW5hbWUgIiQwIiAuc2gpIgorCit0ZXN0X21vZHVsZSgpIHsKKwlrbGRsb2FkIC4v JE1PRE5BTUUua28KKwlrbGR1bmxvYWQgLi8kTU9ETkFNRS5rbworfQorCitjYXNlICIkKCQoZGly bmFtZSAiJDAiKS8uLi90b29scy9nZXR3b3Jkc2l6ZSkiIGluCiszMikKKwlMT05HX01JTl9NSU5V U18xPSItMjE0NzQ4MzY0OSIKKwlMT05HX01JTl9QTFVTXzE9Ii0yMTQ3NDgzNjQ3IgorCUxPTkdf TUFYX01JTlVTXzE9MjE0NzQ4MzY0NworCUxPTkdfTUFYX1BMVVNfMT0yMTQ3NDgzNjQ5CisJOzsK KzY0KQorCUxPTkdfTUlOX01JTlVTXzE9Ii05MjIzMzcyMDM2ODU0Nzc1ODA5IgorCUxPTkdfTUlO X1BMVVNfMT0iLTkyMjMzNzIwMzY4NTQ3NzU4MDciCisJTE9OR19NQVhfTUlOVVNfMT05MjIzMzcy MDM2ODU0Nzc1ODA2CisJTE9OR19NQVhfUExVU18xPTkyMjMzNzIwMzY4NTQ3NzU4MDgKKwk7Owor ZXNhYwora2VudiAtdSAkTU9ETkFNRS50dW5hYmxlIDI+L2Rldi9udWxsCit0ZXN0X21vZHVsZQor Zm9yIGkgaW4gMCA0MiBhc2RmMTIzNCAkTE9OR19NSU5fTUlOVVNfMSAkTE9OR19NSU5fUExVU18x ICRMT05HX01BWF9NSU5VU18xICRMT05HX01BWF9QTFVTXzEgOyBkbworCWtlbnYgJE1PRE5BTUUu dHVuYWJsZT0iJGkiCisJdGVzdF9tb2R1bGUKK2RvbmUKSW5kZXg6IHRvb2xzL3JlZ3Jlc3Npb24v dHVuYWJsZXMvcXVhZC9NYWtlZmlsZQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSB0b29scy9yZWdyZXNzaW9uL3R1 bmFibGVzL3F1YWQvTWFrZWZpbGUJKHJldmlzaW9uIDApCisrKyB0b29scy9yZWdyZXNzaW9uL3R1 bmFibGVzL3F1YWQvTWFrZWZpbGUJKHJldmlzaW9uIDApCkBAIC0wLDAgKzEsNCBAQAorS01PRD0J dGVzdF9xdWFkX3R1bmFibGUKK1NSQ1M9CXRlc3RfcXVhZF90dW5hYmxlLmMKKworLmluY2x1ZGUg PGJzZC5rbW9kLm1rPgpJbmRleDogdG9vbHMvcmVncmVzc2lvbi90dW5hYmxlcy9pbnQvdGVzdF9p bnRfdHVuYWJsZS5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHRvb2xzL3JlZ3Jlc3Npb24vdHVuYWJsZXMvaW50 L3Rlc3RfaW50X3R1bmFibGUuYwkocmV2aXNpb24gMCkKKysrIHRvb2xzL3JlZ3Jlc3Npb24vdHVu YWJsZXMvaW50L3Rlc3RfaW50X3R1bmFibGUuYwkocmV2aXNpb24gMCkKQEAgLTAsMCArMSwzMSBA QAorI2luY2x1ZGUgPHN5cy9wYXJhbS5oPgorI2luY2x1ZGUgPHN5cy90eXBlcy5oPgorI2luY2x1 ZGUgPHN5cy9wcm9jLmg+CisjaW5jbHVkZSA8c3lzL2tlcm5lbC5oPgorI2luY2x1ZGUgPHN5cy9z eXN0bS5oPgorI2luY2x1ZGUgPHN5cy9tb2R1bGUuaD4KKworI2RlZmluZSBNT0RVTEVfTkFNRQki dGVzdF9pbnRfdHVuYWJsZSIKKworc3RhdGljIGludCB0dW5hYmxlID0gMDsKKworVFVOQUJMRV9J TlQoInRlc3RfaW50X3R1bmFibGUudHVuYWJsZSIsICZ0dW5hYmxlKTsKKworc3RhdGljIGludAor bG9hZCAobW9kdWxlX3QgbSwgaW50IHdoYXQsIHZvaWQgKmFyZykKK3sKKwlzd2l0Y2ggKHdoYXQp IHsKKwljYXNlIE1PRF9MT0FEOgorCQlwcmludGYoIiVzOiAlZFxuIiwgTU9EVUxFX05BTUUsIHR1 bmFibGUpOworCQlicmVhazsKKwl9CisJcmV0dXJuICgwKTsKK30KKworc3RhdGljIG1vZHVsZWRh dGFfdCB0ZXN0X2ludF90dW5hYmxlX21vZCA9IHsKKwlNT0RVTEVfTkFNRSwKKwlsb2FkLAorfTsK K0RFQ0xBUkVfTU9EVUxFKHRlc3RfaW50X3R1bmFibGUsIHRlc3RfaW50X3R1bmFibGVfbW9kLCBT SV9TVUJfS0xELAorICAgIFNJX09SREVSX0FOWSk7CitNT0RVTEVfVkVSU0lPTih0ZXN0X2ludF90 dW5hYmxlLCAxKTsKSW5kZXg6IHRvb2xzL3JlZ3Jlc3Npb24vdHVuYWJsZXMvaW50L3Rlc3RfaW50 X3R1bmFibGUuc2gKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PQotLS0gdG9vbHMvcmVncmVzc2lvbi90dW5hYmxlcy9pbnQv dGVzdF9pbnRfdHVuYWJsZS5zaAkocmV2aXNpb24gMCkKKysrIHRvb2xzL3JlZ3Jlc3Npb24vdHVu YWJsZXMvaW50L3Rlc3RfaW50X3R1bmFibGUuc2gJKHJldmlzaW9uIDApCkBAIC0wLDAgKzEsMzEg QEAKKyMhL2Jpbi9zaAorIworIyBFeHBlY3RlZCB2YWx1ZXM6CisjICh1bnNldCkgICA6ICAgICAg ICAgICAwCisjICAgICAgLTEgICA6ICAgICAgICAgIC0xCisjICAgICAgIDAgICA6ICAgICAgICAg ICAwCisjICAgICAgNDIgICA6ICAgICAgICAgIDQyCisjIGFzZGYxMjM0ICA6ICAgICAgICAgICAw IChyZWplY3QpCisjIElOVF9NSU4rMSA6ICAgSU5UX01JTisxCisjIElOVF9NSU4tMSA6ICAgICAg ICAgICAwIChyZWplY3QpCisjIElOVF9NQVgtMSA6ICAgSU5UX01BWC0xCisjIElOVF9NQVgrMSA6 ICAgICAgICAgICAwIChyZWplY3QpCisjCisKK01PRE5BTUU9IiQoYmFzZW5hbWUgIiQwIiAuc2gp IgorCit0ZXN0X21vZHVsZSgpIHsKKwlrbGRsb2FkIC4vJE1PRE5BTUUua28KKwlrbGR1bmxvYWQg Li8kTU9ETkFNRS5rbworfQorCitJTlRfTUlOX1BMVVNfT05FPS0yMTQ3NDgzNjQ3CitJTlRfTUlO X01JTlVTX09ORT0tMjE0NzQ4MzY0OQorSU5UX01BWF9NSU5VU19PTkU9MjE0NzQ4MzY0NgorSU5U X01BWF9QTFVTX09ORT0yMTQ3NDgzNjQ4CitrZW52IC11ICRNT0ROQU1FLnR1bmFibGUgMj4vZGV2 L251bGwKK3Rlc3RfbW9kdWxlCitmb3IgaSBpbiAtMSAwIDQyIGFzZGYxMjM0ICRJTlRfTUlOX1BM VVNfT05FICRJTlRfTUlOX01JTlVTX09ORSAkSU5UX01BWF9NSU5VU19PTkUgJElOVF9NQVhfUExV U19PTkU7IGRvCisJa2VudiAkTU9ETkFNRS50dW5hYmxlPSIkaSIKKwl0ZXN0X21vZHVsZQorZG9u ZQpJbmRleDogdG9vbHMvcmVncmVzc2lvbi90dW5hYmxlcy9pbnQvTWFrZWZpbGUKPT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PQotLS0gdG9vbHMvcmVncmVzc2lvbi90dW5hYmxlcy9pbnQvTWFrZWZpbGUJKHJldmlzaW9uIDAp CisrKyB0b29scy9yZWdyZXNzaW9uL3R1bmFibGVzL2ludC9NYWtlZmlsZQkocmV2aXNpb24gMCkK QEAgLTAsMCArMSw0IEBACitLTU9EPQl0ZXN0X2ludF90dW5hYmxlCitTUkNTPQl0ZXN0X2ludF90 dW5hYmxlLmMKKworLmluY2x1ZGUgPGJzZC5rbW9kLm1rPgpJbmRleDogdG9vbHMvcmVncmVzc2lv bi90dW5hYmxlcy9NYWtlZmlsZQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSB0b29scy9yZWdyZXNzaW9uL3R1bmFi bGVzL01ha2VmaWxlCShyZXZpc2lvbiAwKQorKysgdG9vbHMvcmVncmVzc2lvbi90dW5hYmxlcy9N YWtlZmlsZQkocmV2aXNpb24gMCkKQEAgLTAsMCArMSwxMCBAQAorU1VCRElSPQkJdG9vbHMJCVwK KwkJaW50IHVpbnQJXAorCQlsb25nIHVsb25nCVwKKwkJcG9pbnRlcgkJXAorCQlxdWFkIHVxdWFk CVwKKwkJc2l6ZQkJXAorCQlzdHJpbmcJCVwKKwkJc3VmZml4CQlcCisKKy5pbmNsdWRlIDxic2Qu c3ViZGlyLm1rPgo= --0016364c7f13b16b8304935533e3-- From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 24 04:25: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 C925D1065674 for ; Sun, 24 Oct 2010 04:25:30 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5DF778FC0C for ; Sun, 24 Oct 2010 04:25:29 +0000 (UTC) Received: by wwe15 with SMTP id 15so210628wwe.1 for ; Sat, 23 Oct 2010 21:25:29 -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:content-type; bh=Jhn1CnaKoNJng9r6mKBr1nglpY6qKvWB6j+KMuBoXDo=; b=xaI3k7yq57JowG30iXWa8Q2LI29OckxaUD52q6nS+AdJAbUJAZmlZU4tJSzbzM6CN3 STqBBygnn3f+InBPhmUXBXsKZ1fScQqgUjlnfNUiUZ/1d9g/Oehhl8zsthJY8dy1GJPB N9XGNz2ZCGy8ZDvqgRAhNChOPsBFGXuoXUOjw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=B7bjkjEoVqZ2sZufwGkIK5RdYW9qzeNgPf714Ld1h0eMpxherDqMNegbrAfZl9HrPP XccSoqyQuJuDtUqtbvVWGqBmk+e6sNaJ2Nv60BRvz1MS5ttosqYNBoOewnue4aeqiODY bVK+botTIDNpnzC32BG/le+2amKJ03xEroU7s= MIME-Version: 1.0 Received: by 10.216.132.131 with SMTP id o3mr4621128wei.19.1287894329319; Sat, 23 Oct 2010 21:25:29 -0700 (PDT) Received: by 10.216.10.198 with HTTP; Sat, 23 Oct 2010 21:25:29 -0700 (PDT) Date: Sat, 23 Oct 2010 21:25:29 -0700 Message-ID: From: Garrett Cooper To: freebsd-hackers@freebsd.org Content-Type: multipart/mixed; boundary=0016e6de002301e0ed04935544e7 Subject: [PATCH] Add SF_ARCHIVED to EPERM in chflags(2) ERROR section X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 24 Oct 2010 04:25:31 -0000 --0016e6de002301e0ed04935544e7 Content-Type: text/plain; charset=ISO-8859-1 The SF_ARCHIVED flag isn't noted in the chflags(2) ERROR section. The attached patch adds the entry. If no one has any objections, could someone help me commit this? Thanks! -Garrett --0016e6de002301e0ed04935544e7 Content-Type: text/x-patch; charset=US-ASCII; name="note-EPERM-SF_ARCHIVED-requirement.patch" Content-Disposition: attachment; filename="note-EPERM-SF_ARCHIVED-requirement.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gfney0ra0 SW5kZXg6IGxpYi9saWJjL3N5cy9jaGZsYWdzLjIKPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gbGliL2xpYmMvc3lz L2NoZmxhZ3MuMgkocmV2aXNpb24gMjEzMzc3KQorKysgbGliL2xpYmMvc3lzL2NoZmxhZ3MuMgko d29ya2luZyBjb3B5KQpAQCAtMTQ4LDE0ICsxNDgsMTQgQEAKIHRoZSBlZmZlY3RpdmUgdXNlciBJ RCBpcyBub3QgdGhlIHN1cGVyLXVzZXIuCiAuSXQgQnEgRXIgRVBFUk0KIE9uZSBvZgotLkR2IFNG X0lNTVVUQUJMRSAsIFNGX0FQUEVORCAsCisuRHYgU0ZfQVJDSElWRUQgLCBTRl9JTU1VVEFCTEUg LCBTRl9BUFBFTkQgLAogb3IKIC5EdiBTRl9OT1VOTElOSwogaXMgc2V0IGFuZCB0aGUgdXNlciBp cyBlaXRoZXIgbm90IHRoZSBzdXBlci11c2VyIG9yCiBzZWN1cmVsZXZlbCBpcyBncmVhdGVyIHRo YW4gMC4KIC5JdCBCcSBFciBFUEVSTQogQSBub24tc3VwZXItdXNlciB0cmllcyB0byBzZXQgb25l IG9mCi0uRHYgU0ZfSU1NVVRBQkxFICwgU0ZfQVBQRU5EICwKKy5EdiBTRl9BUkNISVZFRCAsIFNG X0lNTVVUQUJMRSAsIFNGX0FQUEVORCAsCiBvcgogLkR2IFNGX05PVU5MSU5LIC4KIC5JdCBCcSBF ciBFUEVSTQo= --0016e6de002301e0ed04935544e7-- From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 24 05:13:59 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 B05C6106566B; Sun, 24 Oct 2010 05:13:59 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id 6B4708FC14; Sun, 24 Oct 2010 05:13:59 +0000 (UTC) Received: from [93.104.125.203] (helo=current.Sisis.de) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1P9su5-0001on-Mg; Sun, 24 Oct 2010 07:13:57 +0200 Received: from current.Sisis.de (current [127.0.0.1]) by current.Sisis.de (8.14.3/8.14.3) with ESMTP id o9O5E4KT001968; Sun, 24 Oct 2010 07:14:04 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by current.Sisis.de (8.14.3/8.14.3/Submit) id o9O5E43E001967; Sun, 24 Oct 2010 07:14:04 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: current.Sisis.de: guru set sender to guru@unixarea.de using -f Date: Sun, 24 Oct 2010 07:13:59 +0200 From: Matthias Apitz To: freebsd-hackers@freebsd.org, freebsd-usb@freebsd.org Message-ID: <20101024051358.GA1935@current.Sisis.de> References: <20100905081917.GA2212@current.Sisis.de> <20100909063514.GA2333@current.Sisis.de> <20100910061629.GA2461@current.Sisis.de> <20101023084956.GA1362@tiny.Sisis.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20101023084956.GA1362@tiny.Sisis.de> X-Operating-System: FreeBSD 8.0-CURRENT (i386) User-Agent: Mutt/1.5.19 (2009-01-05) X-Con-Id: 51246 X-Originating-IP: 93.104.125.203 Cc: Subject: Re: USB key && can't mount /root during boot X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Oct 2010 05:13:59 -0000 El día Saturday, October 23, 2010 a las 10:49:56AM +0200, Matthias Apitz escribió: > I have now again the same problem (see Subject) again with a new laptop > Acer Aspire One D250 and neither of the two values in loader.conf: > > > kern.cam.boot_delay="10000" > > kern.cam.scsi_delay="10000" > > seems to help. The 10 sec delay is not even visible during the boot, the > message to enter manually the root device just pops up without any > delay. What does this mean? After a lot of testing I got it to woork with: kern.cam.boot_delay="10000" kern.cam.scsi_delay="3000" i.e. it works with 3000, but not with 10000 Thanks matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 24 05:25:59 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 2F36F1065673 for ; Sun, 24 Oct 2010 05:25:59 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id BB0748FC08 for ; Sun, 24 Oct 2010 05:25:58 +0000 (UTC) Received: from [93.104.125.203] (helo=current.Sisis.de) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1P9t5h-0006F5-KG; Sun, 24 Oct 2010 07:25:57 +0200 Received: from current.Sisis.de (current [127.0.0.1]) by current.Sisis.de (8.14.3/8.14.3) with ESMTP id o9O5Q557002026; Sun, 24 Oct 2010 07:26:05 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by current.Sisis.de (8.14.3/8.14.3/Submit) id o9O5Q4II002025; Sun, 24 Oct 2010 07:26:04 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: current.Sisis.de: guru set sender to guru@unixarea.de using -f Date: Sun, 24 Oct 2010 07:25:59 +0200 From: Matthias Apitz To: freebsd-net@freebsd.org Message-ID: <20101024052559.GA1971@current.Sisis.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD 8.0-CURRENT (i386) User-Agent: Mutt/1.5.19 (2009-01-05) X-Con-Id: 51246 X-Originating-IP: 93.104.125.203 Cc: freebsd-hackers@freebsd.org Subject: Broadcom BCM4310 / bwi(4) and interface bwi0 is not showing up X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Oct 2010 05:25:59 -0000 Hello, I have a new laptop Acer Aspire One D250 and I want to install a 8-CURRENT as of CVS from May 2009 (as I use this on all my laptops). The laptop comes with as Wifi chip: none2@pci0:1:0:0: class=0x028000 card=0xe01b105b chip=0x431514e4 rev=0x01 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM4310 USB Controller' class = network I learned after searching around that it should be supported by bwi(4) and one should install the firmware kmod from the ports. I have in loader.conf: if_bwi_load="YES" bwi_v3_ucode_load="YES" and a kldstat shows that both are loaded. But the bwi0 interface is not showing up. If I do a kldunload/kldload it says: pci0: driver added found-> vendor=0x8086, dev=0x27d8, revid=0x02 domain=0, bus=0, slot=27, func=0 class=04-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=16 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit pci0:0:27:0: reprobing on driver added found-> vendor=0x8086, dev=0x27da, revid=0x02 domain=0, bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0001, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=17 pci0:0:31:3: reprobing on driver added pci1: driver added found-> vendor=0x14e4, dev=0x4315, revid=0x01 domain=0, bus=1, slot=0, func=0 class=02-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=16 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit pci0:1:0:0: reprobing on driver added pci2: driver added pci3: driver added found-> vendor=0x1969, dev=0x1062, revid=0xc0 domain=0, bus=3, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=18 powerspec 3 supports D0 D3 current D0 MSI supports 1 message, 64 bit pci0:3:0:0: reprobing on driver added pci4: driver added pci5: driver added and a 'dmesg | fgrep bwi' shows: Preloaded elf module "/boot/kernel/if_bwi.ko" at 0xc10ed228. Preloaded elf module "/boot/modules/bwi_v3_ucode.ko" at 0xc10ed2d4. firmware: 'bwi_v3_ucode' version 0: 0 bytes loaded at 0xc10d33d4 firmware: 'bwi_v3_ucode11' version 0: 21680 bytes loaded at 0xc10d33d4 firmware: 'bwi_v3_ucode2' version 0: 16360 bytes loaded at 0xc10d8884 firmware: 'bwi_v3_ucode4' version 0: 20096 bytes loaded at 0xc10dc86c firmware: 'bwi_v3_ucode5' version 0: 22280 bytes loaded at 0xc10e16ec firmware: 'bwi_v3_a0g0bsinitvals2' version 0: 18 bytes loaded at 0xc10e6df4 firmware: 'bwi_v3_a0g0bsinitvals5' version 0: 158 bytes loaded at 0xc10e6e06 firmware: 'bwi_v3_a0g0initvals2' version 0: 2520 bytes loaded at 0xc10e6ea4 firmware: 'bwi_v3_a0g0initvals5' version 0: 1818 bytes loaded at 0xc10e787c firmware: 'bwi_v3_a0g1bsinitvals5' version 0: 158 bytes loaded at 0xc10e7f96 firmware: 'bwi_v3_a0g1initvals5' version 0: 1818 bytes loaded at 0xc10e8034 firmware: 'bwi_v3_b0g0bsinitvals2' version 0: 18 bytes loaded at 0xc10e874e firmware: 'bwi_v3_b0g0bsinitvals5' version 0: 158 bytes loaded at 0xc10e8760 firmware: 'bwi_v3_b0g0initvals2' version 0: 2520 bytes loaded at 0xc10e87fe firmware: 'bwi_v3_b0g0initvals5' version 0: 1818 bytes loaded at 0xc10e91d6 firmware: 'bwi_v3_pcm4' version 0: 1320 bytes loaded at 0xc10e98f0 firmware: 'bwi_v3_pcm5' version 0: 1320 bytes loaded at 0xc10e9e18 What I am missing here? Thanks matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 24 11:57:12 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 8F7601065670; Sun, 24 Oct 2010 11:57:12 +0000 (UTC) Date: Sun, 24 Oct 2010 11:57:12 +0000 From: Alexander Best To: Garrett Cooper Message-ID: <20101024115712.GA61342@freebsd.org> References: <20101024002248.GA73346@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: freebsd-hackers@freebsd.org Subject: Re: fix pnpinfo on arch=amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 24 Oct 2010 11:57:12 -0000 On Sat Oct 23 10, Garrett Cooper wrote: > On Sat, Oct 23, 2010 at 5:22 PM, Alexander Best wrote: > > this tiny patch will fix pnpinfo so it doesn't core dump (bus error) any > > longer on arch=amd64. > > 1. I had to modify the Makefile to get it to work. probably because you built pnpinfo from contrib/pnpinfo and not from usr.sbin/pnpinfo. i'm not sure your changes to contrib/pnpinfo/Makefile are according to current practice. maybe the vendor Makefile shouldn't be modified and every additional stuff should rather go into usr.sbin/pnpinfo/Makefile. but i don't really know. also in the in usr.sbin/pnpinfo/makefile there's a check for PC98 that i'm not sure is really needed. > 2. FWIW, I don't there's really much point in adding a check for only > x86 architectures, if the tool is capable of more than that. yeah you're probably right. to be honest i know nothing about "archs != i386|amd64". ;) so i just added the amd64 option, because i didn't want to break pnpinfo on other platforms. > 3. Might as well close the file descriptor after opening it. right. expecially, because opening /dev/io (even in ro mode) is a huge security issue. so better close it asap. of course on i386/amd64 (maybe pc98 too?) i386_set_ioperm(2) could be used to work around the security issue. but since pnpinfo's job is to access hardware directly i think opening /dev/io directly can be consideren ok. > > SIGBUS occurs because it doesn't have permission to write via outb. > It's a shame that there isn't a more proper way to catch this SIGBUS > fault minus adding a SIGBUS handler (but that might have other > undesired side effects). well on i386/amd (pc98?) you could use i386_get_ioperm(2) to check for proper io permissions. > Thanks, > -Garrett -- a13x From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 24 13:47:50 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 A5B4D1065672 for ; Sun, 24 Oct 2010 13:47:50 +0000 (UTC) (envelope-from cronfy@gmail.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 376588FC08 for ; Sun, 24 Oct 2010 13:47:49 +0000 (UTC) Received: by bwz3 with SMTP id 3so2340615bwz.13 for ; Sun, 24 Oct 2010 06:47:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:from:date :message-id:subject:to:content-type; bh=H5ixNfCrVKwTykwO2RRVp31/8blbuWJvq1GLRj98IE8=; b=g/PvhRFDA7JrX5CPX+LnDNEwEhYWiFM0jivAYGK7dY/Sznj8ACWD+lL2NCp39yRUhG qDzEcQ4MMAz6UGD+bXlQT7hh4ikW/SP6GMa0jhVh0vv/ILo432l/Iib93sTcgZJXaxWe 5x2WbsOlWvKweKfnAO0DM8lG8QZdFQIbhUp/c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=qmsNfu4Ux+NemRk5p3rWG27qysqau1yGvUm0xj9nc5Ee3PjcyJNrmTEOCu5VTi/Kq0 thWDH4th4P3n9zo3cm6tYix9/q8diKyAnU+9ZXMYLXBKPnjFg8tVQ3JkVoS0PRoQKRz4 lr+r/3Qyn7xlxqJITKoFFA1qgU6E81pRPx230= Received: by 10.204.122.8 with SMTP id j8mr3995037bkr.135.1287926184104; Sun, 24 Oct 2010 06:16:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.73.135 with HTTP; Sun, 24 Oct 2010 06:15:53 -0700 (PDT) From: cronfy Date: Sun, 24 Oct 2010 17:15:53 +0400 Message-ID: To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: 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, 24 Oct 2010 13:47:50 -0000 Hello, I have a web-server (nginx + apache + mysql, FreeBSD 7.3) with many sites. Every night it creates a backup of /home on a separate disk. /home is a RAID1 mirror on Adaptec 3405 (128M write cache) with SAS drives; /backup is a single SATA drive on the same controller. Rsync creates backups using hardlinks, it stores 7 daily and 4 weekly copies. Total amount of data is ~300G and 11M of files. The server is under heavy web load every time (appox 100 queries/sec). 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. I think that problem can be caused by two reasons: * either bulk of reads on SATA /backup drive, that fills OS filesystem cache and many file access operations require real disk read. * or bulk of writes on /backup fills controller write cache and geom disk operations queue grown, causing all disk operations to wait. This is only my assumption of course, I may be wrong. How can I find a real reason of these slowdowns, to either conclude that it is not possible to solve this because of hardware/software limits, or tune my software/hardware system to make this all work at an acceptable speed? Here is my current sysctl setup (what should I tune?): kern.maxvnodes=500000 vfs.ufs.dirhash_maxmem=67108864 vfs.lookup_shared=1 kern.dirdelay=6 kern.metadelay=5 kern.filedelay=7 sysctl's counters (which others should I monitor?): vfs.numvnodes: 407690 vfs.ufs.dirhash_mem: 27158118 I tried to enable async (in hope it will make rsync faster) or even disable softupdates on /backup partition (in hope it will make rsync slower and OS filesytem cache will not be flushed by backups), it did not help. I also want to try to upgrate to Adaptec 5405 (it has 256M of write cache) or move mysql databases on a separate SAS disk, but I just not quite sure what will help better. What would I start from to diagnose the issue? Thanks in advance! -- // cronfy From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 24 15:19: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 8EA82106564A for ; Sun, 24 Oct 2010 15:19:05 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3fd3:cd67:fafa:3d78]) by mx1.freebsd.org (Postfix) with ESMTP id 76E438FC19 for ; Sun, 24 Oct 2010 15:19:04 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [81.187.76.163]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.4/8.14.4) with ESMTP id o9OFIxmY033434 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 24 Oct 2010 16:18:59 +0100 (BST) (envelope-from m.seaman@infracaninophile.co.uk) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp.infracaninophile.co.uk o9OFIxmY033434 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=infracaninophile.co.uk; s=201001-infracaninophile; t=1287933539; bh=fA95/ksXbMhpZvoPTv797ZupRiMBo1BZNGTNZm08cjQ=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Cc:Content-Type:Date:From:In-Reply-To: Message-ID:Mime-Version:References:To; z=Message-ID:=20<4CC44E5B.9040902@infracaninophile.co.uk>|Date:=20S un,=2024=20Oct=202010=2016:18:51=20+0100|From:=20Matthew=20Seaman= 20|Organization:=20Infracaninophi le|User-Agent:=20Mozilla/5.0=20(Macintosh=3B=20U=3B=20Intel=20Mac= 20OS=20X=2010.6=3B=20en-GB=3B=20rv:1.9.2.11)=20Gecko/20101013=20Th underbird/3.1.5|MIME-Version:=201.0|To:=20cronfy=20|CC:=20freebsd-hackers@freebsd.org|Subject:=20Re:=20Slow=20disk =20access=20while=20rsync=20-=20what=20should=20I=20tune?|Referenc es:=20|In-Reply-To:=20|X-Enigmail-Version:=201.1.1|OpenPGP:=20id=3D60A E908C|Content-Type:=20multipart/signed=3B=20micalg=3Dpgp-sha1=3B=0 D=0A=20protocol=3D"application/pgp-signature"=3B=0D=0A=20boundary= 3D"------------enigA9CEBDD7A4FDFC2DAD3E6A7B"; b=l9/oCnepfVpMdSUeMqgSbU135xXCyxuLDTLfSeCaB3rTdj6yo2tm6FCCNGK/uikHC XP/HXvQzftCNWpIeMxqwEoUXfHMnvsXSzMupyug2Y0eQRpUEpis2bLAQOK9n6ETIpH kaZXXCvzH1CqIjCj8FlZy3xqXa+3gerOkRn0VFn4= Message-ID: <4CC44E5B.9040902@infracaninophile.co.uk> Date: Sun, 24 Oct 2010 16:18:51 +0100 From: Matthew Seaman Organization: Infracaninophile User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: cronfy References: In-Reply-To: X-Enigmail-Version: 1.1.1 OpenPGP: id=60AE908C Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA9CEBDD7A4FDFC2DAD3E6A7B" X-Virus-Scanned: clamav-milter 0.96.3 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-0.1 required=5.0 tests=BAYES_40,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,SPF_FAIL autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on lucid-nonsense.infracaninophile.co.uk 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, 24 Oct 2010 15:19:05 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA9CEBDD7A4FDFC2DAD3E6A7B Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 24/10/2010 14:15, cronfy wrote: > I tried to enable async (in hope it will make rsync faster) or even > disable softupdates on /backup partition (in hope it will make rsync > slower and OS filesytem cache will not be flushed by backups), it did > not help. I also want to try to upgrate to Adaptec 5405 (it has 256M > of write cache) or move mysql databases on a separate SAS disk, but I > just not quite sure what will help better. rsync has standard options to limit the bandwidth it will consume. Making it write through a narrow pipe will also slow down the rate of disk accesses, so should help control the impact on other services on the machine. However, taking backups slowly makes it harder to ensure you have a consistent backup, so I recommend you investigate snapshotting the filesystem (well supported for UFS, trivially easy for ZFS) and then backup the snapshot as slowly as you like. Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matthew@infracaninophile.co.uk Kent, CT11 9PW --------------enigA9CEBDD7A4FDFC2DAD3E6A7B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzETmIACgkQ8Mjk52CukIxXLwCdFNhbjn8AE59ablYpmbF/pwET nqIAn1q3+QHg0psXmBDlllt3K/uusjj+ =f+KB -----END PGP SIGNATURE----- --------------enigA9CEBDD7A4FDFC2DAD3E6A7B-- From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 24 15:28:37 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 37055106564A for ; Sun, 24 Oct 2010 15:28:37 +0000 (UTC) (envelope-from brucec@muon.cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id C71988FC16 for ; Sun, 24 Oct 2010 15:28:36 +0000 (UTC) Received: by muon.cran.org.uk (Postfix, from userid 1001) id 20B09E7F9F; Sun, 24 Oct 2010 16:28:36 +0100 (BST) Date: Sun, 24 Oct 2010 16:28:36 +0100 From: Bruce Cran To: Matthew Seaman Message-ID: <20101024152835.GA62748@muon.cran.org.uk> References: <4CC44E5B.9040902@infracaninophile.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CC44E5B.9040902@infracaninophile.co.uk> User-Agent: Mutt/1.5.21 (2010-09-15) 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: Sun, 24 Oct 2010 15:28:37 -0000 On Sun, Oct 24, 2010 at 04:18:51PM +0100, Matthew Seaman wrote: > > However, taking backups slowly makes it harder to ensure you have a > consistent backup, so I recommend you investigate snapshotting the > filesystem (well supported for UFS, trivially easy for ZFS) and then > backup the snapshot as slowly as you like. I'm not sure snapshots are so well supported for UFS. >From sys/ufs/ffs/README.snapshot: "As is detailed in the operational information below, snapshots are definitely alpha-test code and are NOT yet ready for production use." -- Bruce Cran From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 24 16:15:01 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 53D73106566B; Sun, 24 Oct 2010 16:15:01 +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 B4E038FC08; Sun, 24 Oct 2010 16:15:00 +0000 (UTC) Received: by wwb24 with SMTP id 24so2477571wwb.31 for ; Sun, 24 Oct 2010 09:14: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=znk7eK3A6G+0DdahY7o5qSduEQsCSgkSPl3sMdtaXkw=; b=v8xpkSlxE+09ZgFXBTHhWtcDIlvG1a1XKyPVmoO7Tl3+062WFEsO2OSW/hxmFHSiBF Rb3pkgtcAj6nDUEvZZRaAzjiymziqxijbtgjlGPvbfbIQ6E8qjvQCHedVdTn/y5oz/bd Bjh5OVefaEF6KrlG7pv5xpAlUjEcWT0cYgEAs= 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=OSsbOz01uyqZwTsC9pzYq8dYrYiVOAuaBRMK9ab/519RL09r9/ufGo4yYbG+/Vfq2+ p29qWDUdJBMdTDlmnXaK6eqPWSt3EDC15uLB7pJz6+UsNAZ/EYPg5i/x/4fkP/kkuJ2Q 1WIzLzgMzbeMF0tX1JOWSMwH9ZiX+JnDacL+o= MIME-Version: 1.0 Received: by 10.216.143.163 with SMTP id l35mr4602397wej.68.1287936899535; Sun, 24 Oct 2010 09:14:59 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.216.10.198 with HTTP; Sun, 24 Oct 2010 09:14:59 -0700 (PDT) In-Reply-To: <20101024115712.GA61342@freebsd.org> References: <20101024002248.GA73346@freebsd.org> <20101024115712.GA61342@freebsd.org> Date: Sun, 24 Oct 2010 09:14:59 -0700 X-Google-Sender-Auth: 4Q4azdlz_wubQ-7dhWWAcTL7Tu4 Message-ID: From: Garrett Cooper To: Alexander Best Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: fix pnpinfo on arch=amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 24 Oct 2010 16:15:01 -0000 On Sun, Oct 24, 2010 at 4:57 AM, Alexander Best wrote: > On Sat Oct 23 10, Garrett Cooper wrote: >> On Sat, Oct 23, 2010 at 5:22 PM, Alexander Best wrote: >> > this tiny patch will fix pnpinfo so it doesn't core dump (bus error) any >> > longer on arch=amd64. >> >> 1. I had to modify the Makefile to get it to work. > > probably because you built pnpinfo from contrib/pnpinfo and not from > usr.sbin/pnpinfo. i'm not sure your changes to contrib/pnpinfo/Makefile are > according to current practice. maybe the vendor Makefile shouldn't be modified > and every additional stuff should rather go into usr.sbin/pnpinfo/Makefile. but > i don't really know. Ah... I was a bit confused as to why there was a copy hanging out in contrib, because it seems like it was imported primarily to FreeBSD in 2.2 (which contradicts the manpage as it states that it was imported in 7.2). I see it's over in DragonFly, but not in the other BSDs; it has a BSD license; doesn't denote any kind of proprietary info (leverages some of the FreeBSD isa(4) driver structures); doesn't have an external website for development; etc. I was also a bit confused why this directory wasn't iterated over in usr.sbin, but it appears to be missing from SUBDIR in usr.sbin/Makefile (wonder how many others are missing and whether or not the tools / apps really have any value, but that's another top for another thread). > also in the in usr.sbin/pnpinfo/makefile there's a check for PC98 that i'm not > sure is really needed. No, it's not used anymore (I looked over pnpinfo and the isa/machine headers). >> 2. FWIW, I don't there's really much point in adding a check for only >> x86 architectures, if the tool is capable of more than that. > > yeah you're probably right. to be honest i know nothing about > "archs != i386|amd64". ;) so i just added the amd64 option, because i didn't > want to break pnpinfo on other platforms. Well, but there are other platforms, other than x86 that could benefit from using this tool (arm, mips, etc). There might be some bugs lurking in the code dealing with endianness, but that should be resolved first by enabling the tool for all platforms and fixing the cases one by one (unfortunately I don't have either architecture at my disposal, otherwise I'd test this out). I do have a Sparc64 pizza box that I could test this out on though later on this week... hmmm. >> 3. Might as well close the file descriptor after opening it. > > right. expecially, because opening /dev/io (even in ro mode) is a huge security > issue. so better close it asap. > > of course on i386/amd64 (maybe pc98 too?) i386_set_ioperm(2) could be used to > work around the security issue. but since pnpinfo's job is to access hardware > directly i think opening /dev/io directly can be consideren ok. Well, right... but there's no reason to leak a filehandle until the program is finished :). >> SIGBUS occurs because it doesn't have permission to write via outb. >> It's a shame that there isn't a more proper way to catch this SIGBUS >> fault minus adding a SIGBUS handler (but that might have other >> undesired side effects). > > well on i386/amd (pc98?) you could use i386_get_ioperm(2) to check for proper > io permissions. Yeah, and it's x86 specific. Kind of curious why there isn't a more generalized name for this API, but it appeared to be geared towards x86 (today, not so much according to LEGACY in io(4)). FWIW, it also looks like the manpages are missing for those syscalls, even though they're referenced in io(4)... $ man i386_get_ioperm No manual entry for i386_get_ioperm $ man i386_set_ioperm No manual entry for i386_set_ioperm ... and I couldn't find anything in the syscall entry table for this syscall. I did a bit more poking and it looks like the Linux ioperm syscall is the only really publicly available means of accessing this functionality. I could be wrong though. Thanks, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 24 16:22: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 F2E461065670 for ; Sun, 24 Oct 2010 16:22:21 +0000 (UTC) (envelope-from dockes@wanadoo.fr) Received: from smtpfb2-g21.free.fr (smtpfb2-g21.free.fr [212.27.42.10]) by mx1.freebsd.org (Postfix) with ESMTP id 30AE38FC13 for ; Sun, 24 Oct 2010 16:22:19 +0000 (UTC) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [212.27.42.4]) by smtpfb2-g21.free.fr (Postfix) with ESMTP id 6D275D1ABAF for ; Sun, 24 Oct 2010 18:05:17 +0200 (CEST) Received: from y.dockes.com (unknown [82.227.105.245]) by smtp4-g21.free.fr (Postfix) with ESMTP id 833DC4C8090 for ; Sun, 24 Oct 2010 18:05:09 +0200 (CEST) Received: from y.dockes.com (localhost [127.0.0.1]) by y.dockes.com (8.14.4/8.14.1) with ESMTP id o9OG55WT038005 for ; Sun, 24 Oct 2010 18:05:05 +0200 (CEST) (envelope-from dockes@y.dockes.com) Received: (from dockes@localhost) by y.dockes.com (8.14.4/8.14.4/Submit) id o9OG55Ll038004; Sun, 24 Oct 2010 18:05:05 +0200 (CEST) (envelope-from dockes) From: Jean-Francois Dockes MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="7h54wWBw8j" Content-Transfer-Encoding: 7bit Message-ID: <19652.22833.731361.647776@y.dockes.com> Date: Sun, 24 Oct 2010 18:05:05 +0200 To: freebsd-hackers@freebsd.org In-Reply-To: <20101024152835.GA62748@muon.cran.org.uk> References: <4CC44E5B.9040902@infracaninophile.co.uk> <20101024152835.GA62748@muon.cran.org.uk> X-Mailer: VM 8.1.1 under 23.2.1 (amd64-portbld-freebsd7.3) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on y.dockes.com Subject: dump cache performance X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Oct 2010 16:22:22 -0000 --7h54wWBw8j Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit Hello, I took a look at the "cache management for the dump command" project on the freebsd.org project ideas page. http://www.freebsd.org/projects/ideas/ideas.html#p-extenddump It appears that modifying dump to use a shared cache in a very simple way (move the control structures to the shared segment and perform simple locking) yields substantial speed increases. A patch implementing this is attached. Some numbers follow. The test system is an intel core i5 750, with recent SATA disks. The tests all record an improvement with the shared cache, but the values vary widely from 7% to 236%. It would be interesting to have more tests on different configurations. Would someone be interested in reviewing the patch and/or perform more tests ? Regards, J.F. Dockes Some tests results =================== The command used in all cases is "dump -0aC XX -f /dev/null filesystem" The current dump actually uses 5 times the value of the -C option for cache. The patched version uses a single shared memory segment. So "olddump -C 10" and "newdump -C 50" are equivalent in terms of cache memory usage. --------------- Tests performed on a small slice (3.7GB/4GB). The filesystem is quite full, and has been pushed beyond full then partially pruned a few times to simulate one which would actually had a life. It contains a mix of /home/ user files (avg size 68 kB). Tests were run both in single disk and mirror mode. Mirrored slice Split cache -C 10: 18 MB/s Shared cache -C 10 : 42 MB/s (+133%) Same slice, without the mirroring Split cache -C 10: 11 MB/s Shared cache -C 50: 37 MB/s (+236%) -------- Tests on /var (500 MB / 5 GB). Mirrored slice Split cache -C 10: 15 MB/s Shared cache -C 50: 28 MB/s (+86%) ----------- Tests on a bigger slice (24 GB / 43 GB) with mostly big files. Single disk Split cache -C 10: 15 MB/s Shared cache -C 50: 35 MB/s (+133%) ----------- Tests on /usr (464 GB / 595 GB), mirrored Split cache, -C 50: 57 MB/s Shared cache, -C 250: 63 MB/s (+10%) Level 1 tests (5GB dump) Split cache, -C 50: 38 MB/s Shared cache, -C 250: 41 MB/s (+7%) --7h54wWBw8j Content-Type: text/x-patch; name="dump-shared-cache.diff" Content-Disposition: inline; filename="dump-shared-cache.diff" Content-Transfer-Encoding: 7bit diff -r 01d7ce8f41d5 cache.c --- a/cache.c Wed Oct 20 08:39:03 2010 +0200 +++ b/cache.c Sun Oct 24 11:27:36 2010 +0200 @@ -9,6 +9,8 @@ #include #include #include +#include +#include #ifdef sunos #include @@ -43,6 +45,8 @@ #define HFACTOR 4 #define BLKFACTOR 4 +static int lockfd; + static char *DataBase; static Block **BlockHash; static int BlockSize; @@ -55,6 +59,15 @@ int i; int hi; Block *base; + int data_offs; + char tempname[20]; + + /* If mkstemp fails, we're back to using flock(), no need for special + action here */ + strcpy(tempname, "/tmp/dump.XXXXXX"); + if ((lockfd = mkstemp(tempname)) >= 0) { + unlink(tempname); + } if ((BlockSize = sblock->fs_bsize * BLKFACTOR) > MAXBSIZE) BlockSize = MAXBSIZE; @@ -64,10 +77,19 @@ msg("Cache %d MB, blocksize = %d\n", NBlocks * BlockSize / (1024 * 1024), BlockSize); - base = calloc(sizeof(Block), NBlocks); - BlockHash = calloc(sizeof(Block *), HSize); - DataBase = mmap(NULL, NBlocks * BlockSize, - PROT_READ|PROT_WRITE, MAP_ANON, -1, 0); + data_offs = howmany(sizeof(Block) * NBlocks + sizeof(Block *) * HSize, + getpagesize()) * getpagesize(); + DataBase = mmap(NULL, NBlocks * BlockSize + data_offs, + PROT_READ|PROT_WRITE, MAP_ANON|MAP_SHARED|MAP_NOSYNC, + -1, 0); + if (DataBase == MAP_FAILED) { + msg("mmap failed: %s\n", strerror(errno)); + DataBase = NULL; + return; + } + BlockHash = (Block **)DataBase; + base = (Block *)(DataBase + HSize * sizeof(Block *)); + DataBase += data_offs; for (i = 0; i < NBlocks; ++i) { base[i].b_Data = DataBase + i * BlockSize; base[i].b_Offset = (off_t)-1; @@ -86,14 +108,18 @@ int hi; int n; off_t mask; + struct flock lock; /* * If the cache is disabled, or we do not yet know the filesystem * block size, then revert to pread. Otherwise initialize the * cache as necessary and continue. + * This will happen in the top process while mapping and needs no + * locking. */ - if (cachesize <= 0 || sblock->fs_bsize == 0) + if (cachesize <= 0 || sblock->fs_bsize == 0) { return(pread(fd, buf, nbytes, offset)); + } if (DataBase == NULL) cinit(); @@ -115,6 +141,20 @@ * occur near the end of the media). */ hi = (offset / BlockSize) % HSize; + + /* Lock hash bucket */ + lock.l_start = hi; + lock.l_len = 1; + lock.l_type = F_WRLCK; + lock.l_whence = SEEK_SET; + + if (lockfd >= 0 ? fcntl(lockfd, F_SETLKW, &lock) : + flock(fd, LOCK_EX)) { + msg("shared cache lock failed: %s\n", strerror(errno)); + return(pread(fd, buf, nbytes, offset)); + } + lock.l_type = F_UNLCK; + pblk = &BlockHash[hi]; ppblk = NULL; while ((blk = *pblk) != NULL) { @@ -138,8 +178,19 @@ *pblk = blk->b_HNext; blk->b_HNext = BlockHash[hi]; BlockHash[hi] = blk; + + if (lockfd >= 0 ? fcntl(lockfd, F_SETLKW, &lock) : + flock(diskfd, LOCK_UN)) { + msg("unlock shared cache: %s\n", strerror(errno)); + } + return(nbytes); } else { + if (lockfd >= 0 ? fcntl(lockfd, F_SETLKW, &lock) : + flock(diskfd, LOCK_UN)) { + msg("unlock shared cache: %s\n", strerror(errno)); + } + return(pread(fd, buf, nbytes, offset)); } } --7h54wWBw8j Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit diff --7h54wWBw8j Content-Type: text/x-patch; name="dump-shared-cache.diff" Content-Disposition: inline; filename="dump-shared-cache.diff" Content-Transfer-Encoding: 7bit diff -r 01d7ce8f41d5 cache.c --- a/cache.c Wed Oct 20 08:39:03 2010 +0200 +++ b/cache.c Sun Oct 24 11:27:36 2010 +0200 @@ -9,6 +9,8 @@ #include #include #include +#include +#include #ifdef sunos #include @@ -43,6 +45,8 @@ #define HFACTOR 4 #define BLKFACTOR 4 +static int lockfd; + static char *DataBase; static Block **BlockHash; static int BlockSize; @@ -55,6 +59,15 @@ int i; int hi; Block *base; + int data_offs; + char tempname[20]; + + /* If mkstemp fails, we're back to using flock(), no need for special + action here */ + strcpy(tempname, "/tmp/dump.XXXXXX"); + if ((lockfd = mkstemp(tempname)) >= 0) { + unlink(tempname); + } if ((BlockSize = sblock->fs_bsize * BLKFACTOR) > MAXBSIZE) BlockSize = MAXBSIZE; @@ -64,10 +77,19 @@ msg("Cache %d MB, blocksize = %d\n", NBlocks * BlockSize / (1024 * 1024), BlockSize); - base = calloc(sizeof(Block), NBlocks); - BlockHash = calloc(sizeof(Block *), HSize); - DataBase = mmap(NULL, NBlocks * BlockSize, - PROT_READ|PROT_WRITE, MAP_ANON, -1, 0); + data_offs = howmany(sizeof(Block) * NBlocks + sizeof(Block *) * HSize, + getpagesize()) * getpagesize(); + DataBase = mmap(NULL, NBlocks * BlockSize + data_offs, + PROT_READ|PROT_WRITE, MAP_ANON|MAP_SHARED|MAP_NOSYNC, + -1, 0); + if (DataBase == MAP_FAILED) { + msg("mmap failed: %s\n", strerror(errno)); + DataBase = NULL; + return; + } + BlockHash = (Block **)DataBase; + base = (Block *)(DataBase + HSize * sizeof(Block *)); + DataBase += data_offs; for (i = 0; i < NBlocks; ++i) { base[i].b_Data = DataBase + i * BlockSize; base[i].b_Offset = (off_t)-1; @@ -86,14 +108,18 @@ int hi; int n; off_t mask; + struct flock lock; /* * If the cache is disabled, or we do not yet know the filesystem * block size, then revert to pread. Otherwise initialize the * cache as necessary and continue. + * This will happen in the top process while mapping and needs no + * locking. */ - if (cachesize <= 0 || sblock->fs_bsize == 0) + if (cachesize <= 0 || sblock->fs_bsize == 0) { return(pread(fd, buf, nbytes, offset)); + } if (DataBase == NULL) cinit(); @@ -115,6 +141,20 @@ * occur near the end of the media). */ hi = (offset / BlockSize) % HSize; + + /* Lock hash bucket */ + lock.l_start = hi; + lock.l_len = 1; + lock.l_type = F_WRLCK; + lock.l_whence = SEEK_SET; + + if (lockfd >= 0 ? fcntl(lockfd, F_SETLKW, &lock) : + flock(fd, LOCK_EX)) { + msg("shared cache lock failed: %s\n", strerror(errno)); + return(pread(fd, buf, nbytes, offset)); + } + lock.l_type = F_UNLCK; + pblk = &BlockHash[hi]; ppblk = NULL; while ((blk = *pblk) != NULL) { @@ -138,8 +178,19 @@ *pblk = blk->b_HNext; blk->b_HNext = BlockHash[hi]; BlockHash[hi] = blk; + + if (lockfd >= 0 ? fcntl(lockfd, F_SETLKW, &lock) : + flock(diskfd, LOCK_UN)) { + msg("unlock shared cache: %s\n", strerror(errno)); + } + return(nbytes); } else { + if (lockfd >= 0 ? fcntl(lockfd, F_SETLKW, &lock) : + flock(diskfd, LOCK_UN)) { + msg("unlock shared cache: %s\n", strerror(errno)); + } + return(pread(fd, buf, nbytes, offset)); } } --7h54wWBw8j-- From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 24 16:48:04 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 3D119106564A; Sun, 24 Oct 2010 16:48:04 +0000 (UTC) (envelope-from mavbsd@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 67A4D8FC0A; Sun, 24 Oct 2010 16:48:02 +0000 (UTC) Received: by fxm17 with SMTP id 17so2171864fxm.13 for ; Sun, 24 Oct 2010 09:48:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type; bh=8HbT/8wjLYDKQ4gbAw/dwjwKz7rZmFdieUsSTG73IpE=; b=w6lXSgoQzN8RkQhyRDVAjJ2QTpb3b+yLgScLUjwONxXXBakfK13UY+6fD3uG32xbg9 JNu9yCCRoq1omFD6n4qEiTqzF3bV1/amQSS+QBQRBbFUdpPkcqMYs4Ue9eplP43IVkrr 8/SzMnrLHcOgyyAmM9SvLt9Gwbc2qnXHc+4TI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type; b=nEFAECasUY1fCNa00NmndSuV8QiOCZvCIvovvbJ2hOp2uAFQ5smF1BPZ/lcFbj0/oW YX43BZNSRHBm3G9Ean2fJ+/qrDtE7Za27A6A9mkCbtUo1qM70Ns2EUNnyzxeUiHo12h7 sYcET1xYb6qiGY8PkGQ20iSzNVLFW+bW6DbTw= Received: by 10.102.247.20 with SMTP id u20mr3526997muh.34.1287938881818; Sun, 24 Oct 2010 09:48:01 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id a25sm2437595fab.13.2010.10.24.09.47.59 (version=SSLv3 cipher=RC4-MD5); Sun, 24 Oct 2010 09:48:00 -0700 (PDT) Sender: Alexander Motin Message-ID: <4CC4633D.4070605@FreeBSD.org> Date: Sun, 24 Oct 2010 19:47:57 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Alexander Best References: <201009161742.24228.tijl@coosemans.org> <201009161619.o8GGJAmv035378@lurza.secnetix.de> <20101018155944.GA12425@freebsd.org> <868w1r92rf.fsf@ds4.des.no> <20101021122110.GA65490@freebsd.org> <86zku77mj6.fsf@ds4.des.no> <20101021130730.GA72290@freebsd.org> <86r5fj7gin.fsf@ds4.des.no> <20101024011854.GB78293@freebsd.org> In-Reply-To: <20101024011854.GB78293@freebsd.org> X-Enigmail-Version: 0.96.0 Content-Type: multipart/mixed; boundary="------------030609010706040704060309" Cc: freebsd-hackers@freebsd.org, Oliver Fromme , freebsd-scsi@freebsd.org Subject: Re: Summary: Re: Spin down HDD after disk sync or before power off X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 24 Oct 2010 16:48:04 -0000 This is a multi-part message in MIME format. --------------030609010706040704060309 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit Alexander Best wrote: > On Thu Oct 21 10, Dag-Erling Smørgrav wrote: >> Alexander Best writes: >>> no need to get upset. you asked where i found the information regarding the >>> wear impact of spinning down disks and i gave you the answer. >> I am upset by your claim that "doing spin downs upon reboot might be >> even worse than not doing spindowns upon shutdown", because you should >> know better, and following your advice could damage people's hardware. > > well...since currently hdds don't spindown during shutdown the current behavior > is in fact damaging hardware. i don't quite understand why this hasn't been > fixed yet. the patch is available and known to work. it won't cause any > problems with SCSI devices like mav's current implementation, since the > spindown code is limited to ATA devices. > > instead of talking and talking somebody should drop the changes into HEAD! Comparing two ways implementing spindown, I've recalled that both of them using xpt_polled_action() method, which depends on working controller polling operation. So they could be almost equaly not good. But the method present in HEAD now is more universal. Looking on fact that need of spindown is not so obvious for SCSI devices (in SAN environments), we can just make kern.cam.power_down tunable a bitmask of supported protocols for now. Patch is attached. But there is still question that stops me from going one way or another now. Where all this this things should be done properly: in peripheral driver, as proposed (then it have to be duplicated in da and ada drivers and possibly some others), or at the transport level, as present, independent from drivers? I am not sure, but have feeling that tape drives (for example) may also benefit from head parking before powering down. -- Alexander Motin --------------030609010706040704060309 Content-Type: text/plain; name="spindown3.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="spindown3.patch" --- cam_xpt.c.prev 2010-09-22 07:52:38.000000000 +0300 +++ cam_xpt.c 2010-10-24 18:50:13.000000000 +0300 @@ -153,7 +153,7 @@ static struct xpt_softc xsoftc; TUNABLE_INT("kern.cam.boot_delay", &xsoftc.boot_delay); SYSCTL_INT(_kern_cam, OID_AUTO, boot_delay, CTLFLAG_RDTUN, &xsoftc.boot_delay, 0, "Bus registration wait time"); -static int xpt_power_down = 0; +static int xpt_power_down = 1; TUNABLE_INT("kern.cam.power_down", &xpt_power_down); SYSCTL_INT(_kern_cam, OID_AUTO, power_down, CTLFLAG_RW, &xpt_power_down, 0, "Power down devices on shutdown"); @@ -4646,11 +4646,16 @@ xpt_shutdown_dev(struct cam_ed *device, return (1); if (device->protocol == PROTO_ATA) { + if ((xpt_power_down & 1) == 0) + return (1); /* Only power down device if it supports power management. */ if ((device->ident_data.support.command1 & ATA_SUPPORT_POWERMGT) == 0) return (1); - } else if (device->protocol != PROTO_SCSI) + } else if (device->protocol == PROTO_SCSI) { + if ((xpt_power_down & 2) == 0) + return (1); + } else return (1); xpt_compile_path(&path, --------------030609010706040704060309-- From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 24 16:53: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 1686D106566C; Sun, 24 Oct 2010 16:53:10 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id C8D938FC19; Sun, 24 Oct 2010 16:53:09 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 328F5E7F6E; Sun, 24 Oct 2010 17:53:09 +0100 (BST) Received: from unknown (client-81-107-142-135.midd.adsl.virginmedia.com [81.107.142.135]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA; Sun, 24 Oct 2010 17:53:08 +0100 (BST) Date: Sun, 24 Oct 2010 17:53:06 +0100 From: Bruce Cran To: Alexander Motin Message-ID: <20101024175306.00003c66@unknown> In-Reply-To: <4CC4633D.4070605@FreeBSD.org> References: <201009161742.24228.tijl@coosemans.org> <201009161619.o8GGJAmv035378@lurza.secnetix.de> <20101018155944.GA12425@freebsd.org> <868w1r92rf.fsf@ds4.des.no> <20101021122110.GA65490@freebsd.org> <86zku77mj6.fsf@ds4.des.no> <20101021130730.GA72290@freebsd.org> <86r5fj7gin.fsf@ds4.des.no> <20101024011854.GB78293@freebsd.org> <4CC4633D.4070605@FreeBSD.org> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Alexander Best , freebsd-scsi@freebsd.org, Oliver Fromme , freebsd-hackers@freebsd.org Subject: Re: Summary: Re: Spin down HDD after disk sync or before power off X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 24 Oct 2010 16:53:10 -0000 On Sun, 24 Oct 2010 19:47:57 +0300 Alexander Motin wrote: > Comparing two ways implementing spindown, I've recalled that both of > them using xpt_polled_action() method, which depends on working > controller polling operation. So they could be almost equaly not good. > But the method present in HEAD now is more universal. Looking on fact > that need of spindown is not so obvious for SCSI devices (in SAN > environments), we can just make kern.cam.power_down tunable a bitmask > of supported protocols for now. Patch is attached. I've just committed the patch to move the functionality into ada(4). Should it be reverted? -- Bruce Cran From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 24 17:05: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 91099106566B; Sun, 24 Oct 2010 17:05:10 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0DF6E8FC13; Sun, 24 Oct 2010 17:05:05 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id o9OH4jKI052928; Sun, 24 Oct 2010 19:05:01 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id o9OH4jDM052926; Sun, 24 Oct 2010 19:04:45 +0200 (CEST) (envelope-from olli) From: Oliver Fromme Message-Id: <201010241704.o9OH4jDM052926@lurza.secnetix.de> To: bruce@cran.org.uk (Bruce Cran) Date: Sun, 24 Oct 2010 19:04:45 +0200 (CEST) In-Reply-To: <20101024175306.00003c66@unknown> X-Mailer: ELM [version 2.5 PL8] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.5 (lurza.secnetix.de [127.0.0.1]); Sun, 24 Oct 2010 19:05:02 +0200 (CEST) Cc: Alexander Best , Alexander Motin , freebsd-scsi@FreeBSD.org, freebsd-hackers@FreeBSD.org Subject: Re: Summary: Re: Spin down HDD after disk sync or before power off X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 24 Oct 2010 17:05:10 -0000 Bruce Cran wrote: > I've just committed the patch to move the functionality into ada(4). > Should it be reverted? It seems to me that ATA and SCSI devices are sufficiently different (from the code's point of view) that it makes sense to separate the functionality in the ada and da drivers. In other words, I think the commit is good. I'm biased, though. By the way, I also think it's better to issue a "standby immediate" command, not a "sleep" command. The former is reversible, i.e. the drive can spin up if required (for whatever reason), while the latter may require a hardware reset, according to the documentation. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Python tricks" is a tough one, cuz the language is so clean. E.g., C makes an art of confusing pointers with arrays and strings, which leads to lotsa neat pointer tricks; APL mistakes everything for an array, leading to neat one-liners; and Perl confuses everything period, making each line a joyous adventure . -- Tim Peters From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 24 17:09: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 325E91065670; Sun, 24 Oct 2010 17:09:00 +0000 (UTC) (envelope-from mavbsd@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 5E3988FC0A; Sun, 24 Oct 2010 17:08:58 +0000 (UTC) Received: by fxm17 with SMTP id 17so2182883fxm.13 for ; Sun, 24 Oct 2010 10:08:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=xQ0esLMS5G0mYb3KgJQC7SoYqeHS/WVkxsu2grHnuy4=; b=Ti7fl5BkhbNX9LWAll+wSSFSnPghmt/F851VlimUx3A71zQO9Nm+aIap60rHHpkwNz NeVXI+R12Z0M6W0xF75SunUTIKE/e2oJBUAbTobFTmX670X4WzngM9sCEDa5IrLjCQUU l4XfLi0HjMyYfuEYa5IRy3kMK0KCaM3zcf0sQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=k54UzljuhG6v0d4Owruem8LEAuhv0djAGaRnOP6CGUOAu2A7VO2GfHJXDoAAXIG9c4 0Q2Xz3/AhVzakpflEGgHYZLSPLtbjwuIJwQJQlpLkKEIIDPxzecmRr5ri+e+dhlWBGJG OvYWVWS+PRmfLaGf8Bi4iROM79di2oKHpiNvQ= Received: by 10.103.191.17 with SMTP id t17mr6952567mup.54.1287940138250; Sun, 24 Oct 2010 10:08:58 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id n8sm2443031faa.31.2010.10.24.10.08.56 (version=SSLv3 cipher=RC4-MD5); Sun, 24 Oct 2010 10:08:57 -0700 (PDT) Sender: Alexander Motin Message-ID: <4CC46826.9030700@FreeBSD.org> Date: Sun, 24 Oct 2010 20:08:54 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Bruce Cran References: <201009161742.24228.tijl@coosemans.org> <201009161619.o8GGJAmv035378@lurza.secnetix.de> <20101018155944.GA12425@freebsd.org> <868w1r92rf.fsf@ds4.des.no> <20101021122110.GA65490@freebsd.org> <86zku77mj6.fsf@ds4.des.no> <20101021130730.GA72290@freebsd.org> <86r5fj7gin.fsf@ds4.des.no> <20101024011854.GB78293@freebsd.org> <4CC4633D.4070605@FreeBSD.org> <20101024175306.00003c66@unknown> In-Reply-To: <20101024175306.00003c66@unknown> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alexander Best , freebsd-scsi@freebsd.org, Oliver Fromme , freebsd-hackers@freebsd.org Subject: Re: Summary: Re: Spin down HDD after disk sync or before power off X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 24 Oct 2010 17:09:00 -0000 Bruce Cran wrote: > On Sun, 24 Oct 2010 19:47:57 +0300 > Alexander Motin wrote: > >> Comparing two ways implementing spindown, I've recalled that both of >> them using xpt_polled_action() method, which depends on working >> controller polling operation. So they could be almost equaly not good. >> But the method present in HEAD now is more universal. Looking on fact >> that need of spindown is not so obvious for SCSI devices (in SAN >> environments), we can just make kern.cam.power_down tunable a bitmask >> of supported protocols for now. Patch is attached. > > I've just committed the patch to move the functionality into ada(4). > Should it be reverted? Both solutions are possible. I don't have strong enough position to hurry now, when it is already done. It would be nice to hear opinion of SCSI people whether this functionality needed/safe there. -- Alexander Motin From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 24 17:18:59 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 6BA66106566C for ; Sun, 24 Oct 2010 17:18:59 +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 3E29D8FC19 for ; Sun, 24 Oct 2010 17:18:58 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 68DC3582C5 for ; Sun, 24 Oct 2010 11:53:51 -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 wy1ICHK-HoT5 for ; Sun, 24 Oct 2010 11:53:51 -0500 (CDT) Received: from comporellon.tachypleus.net (unknown [76.210.66.181]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 29E63582A6 for ; Sun, 24 Oct 2010 11:53:51 -0500 (CDT) Message-ID: <4CC4649E.3060805@freebsd.org> Date: Sun, 24 Oct 2010 11:53:50 -0500 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.14) Gecko/20101021 Thunderbird/3.0.9 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <20101024002248.GA73346@freebsd.org> <20101024115712.GA61342@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: fix pnpinfo on arch=amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 24 Oct 2010 17:18:59 -0000 On 10/24/10 11:14, Garrett Cooper wrote: > >> well on i386/amd (pc98?) you could use i386_get_ioperm(2) to check for proper >> io permissions. >> > Yeah, and it's x86 specific. Kind of curious why there isn't a > more generalized name for this API, but it appeared to be geared > towards x86 (today, not so much according to LEGACY in io(4)). > > That's because the whole concept is very x86-specific. For example, at least PowerPC and ARM don't even have a concept of IO space as distinct from memory, and /dev/io is something that only exists on i386, amd64, pc98, and ia64 (i.e. Intel products). -Nathan From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 24 18:31: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 39B131065679; Sun, 24 Oct 2010 18:31:15 +0000 (UTC) (envelope-from tijl@coosemans.org) Received: from mailrelay010.isp.belgacom.be (mailrelay010.isp.belgacom.be [195.238.6.177]) by mx1.freebsd.org (Postfix) with ESMTP id 9CC908FC14; Sun, 24 Oct 2010 18:31:13 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAFMXxExbsew3/2dsb2JhbACTc41zcroWhUgE Received: from 55.236-177-91.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([91.177.236.55]) by relay.skynet.be with ESMTP; 24 Oct 2010 20:31:12 +0200 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.14.4/8.14.4) with ESMTP id o9OIVBu1081192; Sun, 24 Oct 2010 20:31:12 +0200 (CEST) (envelope-from tijl@coosemans.org) From: Tijl Coosemans To: freebsd-hackers@freebsd.org Date: Sun, 24 Oct 2010 20:30:53 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.5.2; i386; ; ) References: <201009161742.24228.tijl@coosemans.org> <20101024011854.GB78293@freebsd.org> <4CC4633D.4070605@FreeBSD.org> In-Reply-To: <4CC4633D.4070605@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2379086.db1uFEK4fO"; protocol="application/pgp-signature"; micalg=pgp-sha256 Content-Transfer-Encoding: 7bit Message-Id: <201010242031.09656.tijl@coosemans.org> Cc: Alexander Best , Alexander Motin , Oliver Fromme , freebsd-scsi@freebsd.org Subject: Re: Summary: Re: Spin down HDD after disk sync or before power off X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 24 Oct 2010 18:31:15 -0000 --nextPart2379086.db1uFEK4fO Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Sunday 24 October 2010 18:47:57 Alexander Motin wrote: > I am not sure, but have feeling that tape drives (for example) may > also benefit from head parking before powering down. USB hard disks would benefit as well I think. Although, ideally it should happen after unmounting the last file system. --nextPart2379086.db1uFEK4fO Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iF4EABEIAAYFAkzEe2kACgkQfoCS2CCgtiup8QD+PLTzr0ZWOYJrkFU59OENpgu9 iXHRmX9kNlUFCz31agoA/2891eINMM2WO+D7n8g6sohhJjCZvcS9j+tS3y8n1OxY =HQF6 -----END PGP SIGNATURE----- --nextPart2379086.db1uFEK4fO-- From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 24 19:02: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 5F03C1065672; Sun, 24 Oct 2010 19:02:25 +0000 (UTC) (envelope-from mavbsd@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 8C06D8FC37; Sun, 24 Oct 2010 19:02:24 +0000 (UTC) Received: by fxm17 with SMTP id 17so2245610fxm.13 for ; Sun, 24 Oct 2010 12:02:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=t2XK6mZXDm5Wwtz6phu/TV6xl7YIMHCshDJozq0yOWY=; b=npk/1j1cINlkdinZ4sPcaVYz5olBh/Y7jPDIL+z08fAgN8/Axnf3RDztyVAigTxSp5 nOhywIMp0lf051MPeegIRwkpr4vySZV6P7uNsAmuDwvMdIN+lVqJNazwYpkrSrpK0xO/ PVBuSn+0XZUq6BFzdd0CAKzcH0hj64y8MHOEQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=uxPtMfZtdv0CvTS1vkPhu9xfF8/lj7L32Xh//bcuBErsplLVFElxw4YUpFboSqDSzA 4rdu45f8uCvUY1CFN/oytqtSpXuw4e7iZHQFl4QlSt5ToVPQWEhsVNdiIDIAXzLAoRca icHmwxVC7vcvSKwiBdj+PcmQ7iNLi2WcWIkcQ= Received: by 10.103.224.5 with SMTP id b5mr5250307mur.58.1287946943213; Sun, 24 Oct 2010 12:02:23 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id d20sm1330058fav.14.2010.10.24.12.02.21 (version=SSLv3 cipher=RC4-MD5); Sun, 24 Oct 2010 12:02:22 -0700 (PDT) Sender: Alexander Motin Message-ID: <4CC482BB.90102@FreeBSD.org> Date: Sun, 24 Oct 2010 22:02:19 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Tijl Coosemans References: <201009161742.24228.tijl@coosemans.org> <20101024011854.GB78293@freebsd.org> <4CC4633D.4070605@FreeBSD.org> <201010242031.09656.tijl@coosemans.org> In-Reply-To: <201010242031.09656.tijl@coosemans.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, freebsd-scsi@freebsd.org, Oliver Fromme , Alexander Best Subject: Re: Summary: Re: Spin down HDD after disk sync or before power off X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 24 Oct 2010 19:02:25 -0000 Tijl Coosemans wrote: > On Sunday 24 October 2010 18:47:57 Alexander Motin wrote: >> I am not sure, but have feeling that tape drives (for example) may >> also benefit from head parking before powering down. > > USB hard disks would benefit as well I think. Although, ideally it > should happen after unmounting the last file system. Depending on unmount would be excessively aggressive. Far from every device close will be followed by unplugging. Same time nobody denies to run `camcontrol stop daX` before unplugging. USB disks are still "da". It would be more interesting to know if this practice applicable to other kinds of SCSI devices. -- Alexander Motin From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 25 00:11: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 3D6BD1065673 for ; Mon, 25 Oct 2010 00:11:15 +0000 (UTC) (envelope-from markjdb@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 0195A8FC0C for ; Mon, 25 Oct 2010 00:11:14 +0000 (UTC) Received: by iwn39 with SMTP id 39so3611344iwn.13 for ; Sun, 24 Oct 2010 17:11:14 -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=MQRzDPmOu9ZCysBZshm9SZV751nzOHeGsEyAiNq8PgQ=; b=ZcaXKts/LcZI6BwfDD3B+Iq9uvcfBBCQAqfHL9Yxx0g3U8xw3SCfy1sV/Xmi963lLY gmSut/JxSVjyoHHSb461H3kI6ME7lDTG2CXNg/QjKREXE5yCk/O/9sCsKR/XLm42eB7q u4BjhsE1E4BqryaC9MuSdLzPzk9EAJ7PRzgkE= 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=eKjzNmjJ/qGktKX/3RCduU/t78mUzZJevdi3KpP/5GeAGR+kxbg4g7QK4lkaTSHzpm dbyTgk2bWefGtOTVTNf15zZqVCa/VGfL3L8pL1/AJr20GevjHvS95RFoOQo+8yQOqiwc WOkV+3TeFXBh0Sk6dgXUEjqRM7efZivtTwRJA= Received: by 10.42.175.193 with SMTP id bb1mr840607icb.103.1287964110129; Sun, 24 Oct 2010 16:48:30 -0700 (PDT) Received: from mark-laptop-bsd.mark-home (mail1.sandvine.com [64.7.137.162]) by mx.google.com with ESMTPS id u6sm7121505ibd.6.2010.10.24.16.48.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 24 Oct 2010 16:48:28 -0700 (PDT) Date: Sun, 24 Oct 2010 19:48:15 -0400 From: Mark Johnston To: freebsd-hackers@freebsd.org Message-ID: <20101024234814.GA2304@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: Re: Broadcom BCM4310 / bwi(4) and interface bwi0 is not showing up X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 25 Oct 2010 00:11:15 -0000 > I have a new laptop Acer Aspire One D250 and I want to install a > 8-CURRENT as of CVS from May 2009 (as I use this on all my laptops). > The laptop comes with as Wifi chip: > > none2 at pci0:1:0:0: class=0x028000 card=0xe01b105b chip=0x431514e4 > rev=0x01 hdr=0x00 > vendor = 'Broadcom Corporation' > device = 'BCM4310 USB Controller' > class = network > > I learned after searching around that it should be supported by bwi(4) > and one should install the firmware kmod from the ports. > ... > > What I am missing here? Thanks > > matthias > -- > Matthias Apitz > t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 > e - w http://www.unixarea.de/ Looking at bwi/if_bwi_pci.c, it doesn't seem as though your particular chip is supported: static const struct bwi_dev { uint16_t vid; uint16_t did; const char *desc; } bwi_devices[] = { { PCI_VENDOR_BROADCOM, 0x4301,"Broadcom BCM4301 802.11b Wireless Lan" }, { PCI_VENDOR_BROADCOM, 0x4307,"Broadcom BCM4307 802.11b Wireless Lan" }, { PCI_VENDOR_BROADCOM, 0x4311,"Broadcom BCM4311 802.11b/g Wireless Lan" }, { PCI_VENDOR_BROADCOM, 0x4312,"Broadcom BCM4312 802.11a/b/g Wireless Lan" }, { PCI_VENDOR_BROADCOM, 0x4313,"Broadcom BCM4312 802.11a Wireless Lan" }, { PCI_VENDOR_BROADCOM, 0x4320,"Broadcom BCM4306 802.11b/g Wireless Lan"}, { PCI_VENDOR_BROADCOM, 0x4321,"Broadcom BCM4306 802.11a Wireless Lan"}, { PCI_VENDOR_BROADCOM, 0x4325,"Broadcom BCM4306 802.11b/g Wireless Lan"}, { PCI_VENDOR_BROADCOM, 0x4324,"Broadcom BCM4309 802.11a/b/g Wireless Lan" }, { PCI_VENDOR_BROADCOM, 0x4318,"Broadcom BCM4318 802.11b/g Wireless Lan" }, { PCI_VENDOR_BROADCOM, 0x4319,"Broadcom BCM4318 802.11a/b/g Wireless Lan" }, { PCI_VENDOR_BROADCOM, 0x431a,"Broadcom BCM4318 802.11a Wireless Lan" }, { 0, 0, NULL } }; -Mark From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 25 05:43: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 C537D1065694 for ; Mon, 25 Oct 2010 05:43:41 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id 81A928FC1B for ; Mon, 25 Oct 2010 05:43:41 +0000 (UTC) Received: from [93.104.106.118] (helo=current.Sisis.de) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1PAFqM-0003Qc-Ov; Mon, 25 Oct 2010 07:43:38 +0200 Received: from current.Sisis.de (current [127.0.0.1]) by current.Sisis.de (8.14.3/8.14.3) with ESMTP id o9P5hcvi012421; Mon, 25 Oct 2010 07:43:38 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by current.Sisis.de (8.14.3/8.14.3/Submit) id o9P5hbFj012420; Mon, 25 Oct 2010 07:43:37 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: current.Sisis.de: guru set sender to guru@unixarea.de using -f Date: Mon, 25 Oct 2010 07:43:32 +0200 From: Matthias Apitz To: Mark Johnston Message-ID: <20101025054332.GA2835@current.Sisis.de> References: <20101024234814.GA2304@mark-laptop-bsd.mark-home> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20101024234814.GA2304@mark-laptop-bsd.mark-home> X-Operating-System: FreeBSD 8.0-CURRENT (i386) User-Agent: Mutt/1.5.19 (2009-01-05) X-Con-Id: 51246 X-Originating-IP: 93.104.106.118 Cc: freebsd-hackers@freebsd.org Subject: Re: Broadcom BCM4310 / bwi(4) and interface bwi0 is not showing up X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 05:43:41 -0000 El día Sunday, October 24, 2010 a las 07:48:15PM -0400, Mark Johnston escribió: > > none2 at pci0:1:0:0: class=0x028000 card=0xe01b105b chip=0x431514e4 > > rev=0x01 hdr=0x00 > > vendor = 'Broadcom Corporation' > > device = 'BCM4310 USB Controller' > > class = network > > > > I learned after searching around that it should be supported by bwi(4) > > and one should install the firmware kmod from the ports. > > ... > > > > What I am missing here? Thanks > > > > matthias > > -- > > Matthias Apitz > > t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 > > e - w http://www.unixarea.de/ > > Looking at bwi/if_bwi_pci.c, it doesn't seem as though your particular > chip is supported: > ... Yes, I saw this later too. And sys/dev/bwn does not compile in my old kernel env. I've pulled out now HEAD from SVN and will build an USB key based on this to see if it will have support for this chip. Thanks matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 25 09:42: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 5A5851065674 for ; Mon, 25 Oct 2010 09:42:03 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from fallbackmx06.syd.optusnet.com.au (fallbackmx06.syd.optusnet.com.au [211.29.132.8]) by mx1.freebsd.org (Postfix) with ESMTP id BF0C68FC16 for ; Mon, 25 Oct 2010 09:42:02 +0000 (UTC) Received: from mail36.syd.optusnet.com.au (mail36.syd.optusnet.com.au [211.29.133.76]) by fallbackmx06.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o9P9W0tH029726 for ; Mon, 25 Oct 2010 20:32:00 +1100 Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail36.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o9P9Vneu030078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Oct 2010 20:31:51 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.4/8.14.4) with ESMTP id o9P9VnsS067946; Mon, 25 Oct 2010 20:31:49 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.4/8.14.4/Submit) id o9P9Vn24067945; Mon, 25 Oct 2010 20:31:49 +1100 (EST) (envelope-from peter) Date: Mon, 25 Oct 2010 20:31:49 +1100 From: Peter Jeremy To: Jean-Francois Dockes Message-ID: <20101025093149.GA67314@server.vk2pj.dyndns.org> References: <4CC44E5B.9040902@infracaninophile.co.uk> <20101024152835.GA62748@muon.cran.org.uk> <19652.22833.731361.647776@y.dockes.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2oS5YaxWCcQjTEyO" Content-Disposition: inline In-Reply-To: <19652.22833.731361.647776@y.dockes.com> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hackers@freebsd.org Subject: Re: dump cache performance X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 09:42:03 -0000 --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2010-Oct-24 18:05:05 +0200, Jean-Francois Dockes wrote: >It appears that modifying dump to use a shared cache in a very simple way >(move the control structures to the shared segment and perform simple lock= ing) >yields substantial speed increases. Indeed. That's better than I expected. >Would someone be interested in reviewing the patch and/or perform >more tests ? I've mostly convered to ZFS but still have UFS root (which is basically a full base install without /var but including /usr/src - 94k inodes and 1.7GB). I've run both the 8-stable ("stable") and patched ("jfd") dump= =20 alternately 4 times with 50/250MB cache with the following results: x stable + jfd +------------------------------------------------------------+ | +| | +| | x +| |x xx +| ||AM A| +------------------------------------------------------------+ N Min Max Median Avg Stddev x 4 9413 9673 9568 9555.5 107.12143 + 4 15359 15359 15359 15359 0 Difference at 95.0% confidence 5803.5 +/- 131.063 60.7347% +/- 1.3716% (Student's t, pooled s =3D 75.7463) --=20 Peter Jeremy --2oS5YaxWCcQjTEyO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iEYEARECAAYFAkzFToUACgkQ/opHv/APuIdK3QCeJ/Wpki/DqQwnn1mfmtCWgedO gBUAnR0CYT9O4VUSsyW0/89WGEVTFmcf =mLvt -----END PGP SIGNATURE----- --2oS5YaxWCcQjTEyO-- From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 25 09:56:24 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 DBD57106564A; Mon, 25 Oct 2010 09:56:24 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4B69B8FC19; Mon, 25 Oct 2010 09:56:23 +0000 (UTC) Received: by fxm17 with SMTP id 17so2727429fxm.13 for ; Mon, 25 Oct 2010 02:56:23 -0700 (PDT) Received: by 10.103.212.2 with SMTP id o2mr7917222muq.136.1287998988948; Mon, 25 Oct 2010 02:29:48 -0700 (PDT) Received: from jessie.localnet (p5B0E216B.dip0.t-ipconnect.de [91.14.33.107]) by mx.google.com with ESMTPS id r22sm2744372fax.45.2010.10.25.02.29.46 (version=SSLv3 cipher=RC4-MD5); Mon, 25 Oct 2010 02:29:46 -0700 (PDT) Sender: Bernhard Schmidt From: Bernhard Schmidt To: Matthias Apitz Date: Mon, 25 Oct 2010 11:29:43 +0200 User-Agent: KMail/1.13.2 (Linux/2.6.32-25-generic; KDE/4.4.2; i686; ; ) References: <20101024052559.GA1971@current.Sisis.de> In-Reply-To: <20101024052559.GA1971@current.Sisis.de> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_I4UxMQlRq0osoBA" Message-Id: <201010251129.44262.bschmidt@freebsd.org> Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Broadcom BCM4310 / bwi(4) and interface bwi0 is not showing up X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bschmidt@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 09:56:25 -0000 --Boundary-00=_I4UxMQlRq0osoBA Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit On Sunday, October 24, 2010 07:25:59 Matthias Apitz wrote: > Hello, > > I have a new laptop Acer Aspire One D250 and I want to install a > 8-CURRENT as of CVS from May 2009 (as I use this on all my laptops). > The laptop comes with as Wifi chip: > > none2@pci0:1:0:0: class=0x028000 card=0xe01b105b chip=0x431514e4 > rev=0x01 hdr=0x00 > vendor = 'Broadcom Corporation' > device = 'BCM4310 USB Controller' > class = network > > I learned after searching around that it should be supported by bwi(4) > and one should install the firmware kmod from the ports. I have in > loader.conf: > [..] Please try attached patch, I'm not sure if it is that simple.. worth a try though. -- Bernhard --Boundary-00=_I4UxMQlRq0osoBA Content-Type: text/x-patch; charset="UTF-8"; name="bwi_4315.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="bwi_4315.diff" --- a/sys/dev/bwi/if_bwi_pci.c +++ b/sys/dev/bwi/if_bwi_pci.c @@ -85,6 +85,7 @@ static const struct bwi_dev { { PCI_VENDOR_BROADCOM, 0x4311,"Broadcom BCM4311 802.11b/g Wireless Lan" }, { PCI_VENDOR_BROADCOM, 0x4312,"Broadcom BCM4312 802.11a/b/g Wireless Lan" }, { PCI_VENDOR_BROADCOM, 0x4313,"Broadcom BCM4312 802.11a Wireless Lan" }, + { PCI_VENDOR_BROADCOM, 0x4315,"Broadcom BCM4312 802.11b/g Wireless Lan"}, { PCI_VENDOR_BROADCOM, 0x4320,"Broadcom BCM4306 802.11b/g Wireless Lan"}, { PCI_VENDOR_BROADCOM, 0x4321,"Broadcom BCM4306 802.11a Wireless Lan"}, { PCI_VENDOR_BROADCOM, 0x4325,"Broadcom BCM4306 802.11b/g Wireless Lan"}, --Boundary-00=_I4UxMQlRq0osoBA-- From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 25 12:54: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 82CC21065670; Mon, 25 Oct 2010 12:54:41 +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 525E08FC1D; Mon, 25 Oct 2010 12:54:41 +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 EE87646B5B; Mon, 25 Oct 2010 08:54:40 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id EB7008A01D; Mon, 25 Oct 2010 08:54:39 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Mon, 25 Oct 2010 08:45:47 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <20101024002248.GA73346@freebsd.org> In-Reply-To: <20101024002248.GA73346@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201010250845.47794.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 25 Oct 2010 08:54:40 -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: Alexander Best Subject: Re: fix pnpinfo on arch=amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 25 Oct 2010 12:54:41 -0000 On Saturday, October 23, 2010 8:22:48 pm Alexander Best wrote: > this tiny patch will fix pnpinfo so it doesn't core dump (bus error) any > longer on arch=amd64. This utility isn't really useful on amd64 though. No amd64 machines have ISA slots in which to place an ISA PnP adapter. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 25 13:34:48 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 1BF78106566B for ; Mon, 25 Oct 2010 13:34:48 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id C76408FC20 for ; Mon, 25 Oct 2010 13:34:47 +0000 (UTC) Received: from c83-255-61-120.bredband.comhem.se ([83.255.61.120]:45919 helo=falcon.midgard.homeip.net) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.71) (envelope-from ) id 1PANCA-0007hv-3s for freebsd-hackers@freebsd.org; Mon, 25 Oct 2010 15:34:40 +0200 Received: (qmail 48347 invoked from network); 25 Oct 2010 15:34:37 +0200 Received: from owl.midgard.homeip.net (10.1.5.7) by falcon.midgard.homeip.net with ESMTP; 25 Oct 2010 15:34:37 +0200 Received: (qmail 72699 invoked by uid 1001); 25 Oct 2010 15:34:37 +0200 Date: Mon, 25 Oct 2010 15:34:37 +0200 From: Erik Trulsson To: John Baldwin Message-ID: <20101025133437.GA72669@owl.midgard.homeip.net> References: <20101024002248.GA73346@freebsd.org> <201010250845.47794.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201010250845.47794.jhb@freebsd.org> User-Agent: Mutt/1.5.20 (2009-06-14) X-Originating-IP: 83.255.61.120 X-Scan-Result: No virus found in message 1PANCA-0007hv-3s. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1PANCA-0007hv-3s b37a75f9798fbb38bb23dbd66d2ca874 Cc: freebsd-hackers@freebsd.org, Alexander Best Subject: Re: fix pnpinfo on arch=amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 25 Oct 2010 13:34:48 -0000 On Mon, Oct 25, 2010 at 08:45:47AM -0400, John Baldwin wrote: > On Saturday, October 23, 2010 8:22:48 pm Alexander Best wrote: > > this tiny patch will fix pnpinfo so it doesn't core dump (bus error) any > > longer on arch=amd64. > > This utility isn't really useful on amd64 though. No amd64 machines have ISA > slots in which to place an ISA PnP adapter. Are you really sure about that? See http://www.ibase.com.tw/2009/mb945.htmL or http://www.adek.com/ATX-motherboards.html for what certainly looks like counter-examples. -- Erik Trulsson ertr1013@student.uu.se From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 25 14:27:21 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 27A5E106566C; Mon, 25 Oct 2010 14:27:21 +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 EBF618FC08; Mon, 25 Oct 2010 14:27:20 +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 7692E46B0C; Mon, 25 Oct 2010 10:27:20 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 5F44B8A009; Mon, 25 Oct 2010 10:27:19 -0400 (EDT) From: John Baldwin To: Erik Trulsson Date: Mon, 25 Oct 2010 10:27:05 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <20101024002248.GA73346@freebsd.org> <201010250845.47794.jhb@freebsd.org> <20101025133437.GA72669@owl.midgard.homeip.net> In-Reply-To: <20101025133437.GA72669@owl.midgard.homeip.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201010251027.06059.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 25 Oct 2010 10:27:19 -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: freebsd-hackers@freebsd.org, Alexander Best Subject: Re: fix pnpinfo on arch=amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 25 Oct 2010 14:27:21 -0000 On Monday, October 25, 2010 9:34:37 am Erik Trulsson wrote: > On Mon, Oct 25, 2010 at 08:45:47AM -0400, John Baldwin wrote: > > On Saturday, October 23, 2010 8:22:48 pm Alexander Best wrote: > > > this tiny patch will fix pnpinfo so it doesn't core dump (bus error) any > > > longer on arch=amd64. > > > > This utility isn't really useful on amd64 though. No amd64 machines have ISA > > slots in which to place an ISA PnP adapter. > > Are you really sure about that? > > See http://www.ibase.com.tw/2009/mb945.htmL or > http://www.adek.com/ATX-motherboards.html for what certainly looks like > counter-examples. Hmm, well, I suspect in this case these boards exist to support really ancient custom hardware. If you are stuck with one of these, then manually needing to fix up pnpinfo.c is probably the least of your problems. However, I strongly doubt that FreeBSD users are lining up to buy these motherboards so they can use an ISA SB16 adapter with FreeBSD/amd64. I was not aware of these boards previously, but I still doubt that pnpinfo is relevant to any FreeBSD/amd64 users. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 25 18:02: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 9ECF81065674; Mon, 25 Oct 2010 18:02:14 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mailoutltc.fnis.com (mailoutltc.fnis.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 66E7C8FC15; Mon, 25 Oct 2010 18:02:13 +0000 (UTC) Received: from SBHFISLREXT03 ([10.132.254.62]) by SCSFISLTC01 (8.14.3/8.14.3) with ESMTP id o9PI1qjs030455; Mon, 25 Oct 2010 13:01:52 -0500 Received: from sbhfisltcgw01.FNFIS.COM (Not Verified[10.132.248.121]) by SBHFISLREXT03 with MailMarshal (v6, 5, 4, 7535) id ; Mon, 25 Oct 2010 13:02:07 -0500 Received: from SBHFISLTCGW04.FNFIS.COM ([10.132.248.123]) by sbhfisltcgw01.FNFIS.COM with Microsoft SMTPSVC(6.0.3790.4675); Mon, 25 Oct 2010 13:01:51 -0500 Received: from dt.vicor.com ([10.14.152.6]) by SBHFISLTCGW04.FNFIS.COM over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Oct 2010 13:01:51 -0500 From: Devin Teske To: Anthony Pankov In-Reply-To: <168417535437.20101023152013@mail.ru> References: <1286397912.27308.40.camel@localhost.localdomain> <4CB34BF9.4050504@FreeBSD.org> <1286824968.30494.46.camel@localhost.localdomain> <4CB4B293.1050505@FreeBSD.org> <1286924785.32724.17.camel@localhost.localdomain> <168417535437.20101023152013@mail.ru> Content-Type: text/plain Date: Mon, 25 Oct 2010 11:01:49 -0700 Message-Id: <1288029709.29028.68.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-41.el4) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Oct 2010 18:01:51.0508 (UTC) FILETIME=[B363D540:01CB746E] Cc: freebsd-hackers@freebsd.org, Doug Barton Subject: Re: sysrc -- a sysctl(8)-like utility for managing /etc/rc.conf et. al. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 25 Oct 2010 18:02:14 -0000 On Sat, 2010-10-23 at 15:20 +0400, Anthony Pankov wrote: > Greetings. > > Just for note. > > Some time ago i thought about the same problem. > I started something then had delayed it forever in favour of fast wrong > way. > > So, the aim was: > > --- > NAME > modcfg - modify configuration > > SYNOPSIS > modcfg -f config_file -t config_type {-s param=val | -u param} > modcfg -l > modcfg -i plugin > > DESCRIPTION > The modcfg utility modifies configuration file in > accordance to parameters. > > The following options are available: > -f config_file - the file itself which to be modified > -t config_type - type of config_file. Type specifies the internal > structure of config_file, or, more roughly, > program which this file belongs to. To > list available types see -l option. > -s param=val - set configuration parameter 'param' to value > 'val'. > -u param - unset configuration parameter 'param' (or set it to default). > > -l - list all supported types of config files. > > -i plugin - install plugin 'plugin' for modcfg utility. > Plugin is used to support additional configuration file type. > > EXAMPLES > The command > modcfg -f /etc/rc.conf -t rc -s keymap=ru.cp1251 > sets parameter 'keymap' to value 'ru.cp1251'in file rc.conf. > > The command > modcfg -f /etc/rc.conf -t rc -u keymap > resets parameter 'keymap' to default value. I think it's great that you've taken on the task of finding a solution that works best for you, but this doesn't really work that well for the case of rc.conf(5) files because it neither sources `/etc/defaults/rc.conf' nor calls source_rc_confs() from said-file. So yes, one could modify a variable in a given file with your utility, but it doesn't take into account that rc.conf(5) is not a single file, it's a collection of files. Least of which contains: /etc/defaults/rc.conf /etc/rc.conf /etc/rc.conf.local /etc/rc.conf.d/* NOTE: The last one is not sourced by source_rc_confs() but is sourced by /etc/rc.d/* (the local-service boot-scripts), most [if not all] of which call load_rc_config(). In example, /etc/rc.d/foo would first source /etc/rc.subr then call `load_rc_config foo' which will both call source_rc_confs() from /etc/defaults/rc.conf AND source /etc/rc.conf.d/foo [if it exists]. This heirarchical structure forces a level of complexity onto the user which _can_ be confusing at times to less experienced users, and therefore providing a utility that ignores said-heirarchy forces the user to either navigate the complexity themselves or to write a wrapper script around your utility to manage it for them. Whereas, I started my utility (sysrc) from the ground-up with the express purpose of wrangling this complexity. I wanted a tool that would -- overall -- help me in my daily routines of managing thousands of FreeBSD workstations/pedestals/servers (fyi: a pedestal is server-class hardware in workstation-tower-like chassis). > To install obtained plugin 'samba.mcfg' use > modcfg -i samba.mcfg > After that configuration type 'samba' will be supported. Out of curiosity, why must the user be forced to "install the plugin" manually? Why not have the code automatically probe for the plugin on first-use? For example, when 'samba'-type is used for the first time, take that as a queue to load the module and if the module can't be loaded, die with an error. I think this streamlines the process (but wouldn't go as far as to remove the `-i' parameter -- keep it, it could be useful to some). > > --- > > INTERNALLY > > modcfg itself is very simple. It parse command line options, then load > plugin (module) for specified 'config_type', then call _set(file,param, > value) or _unset(file,param) function from this module. > So, plugin (module) should have functions such as: > _set(file, param, value) or, better name, {$type}_set. rc_set, for > example. > _unset(file, param) > _description - for display in module list. Your utility I think loosely resembles Apple's Core Data Programming API. I recently have been making my way through this Mac/iOS API known as "Core Data Programming" which uses relationship mapping (similar to your `config_type') to teach the Core Data API how modify different underlying data containers (but extends far beyond BSD-style configuration files). For example, Core Data -- in an object-oriented fashion -- provides a set of high-level access routines for accessing your data meanwhile the specifics of how that data was obtained or how said data is persistently stored back to the container are hidden from your application (much in the way that your utility masks from the user how the data is stored in the specific configuration-file type). Much like your utility, Core Data already supports some well-known data containers -- SQLite, Boulder/IO (simple key=value pairs), etc. -- and can easily be extended through OOP's multiple-inheritance, class-method overrides, and abstract sub-classing. However, Core Data is not limited to working on just files (or databases). Core Data is useful for literally anything where there is data in one format that needs to be parsed into another format and then optionally modified and then stored back in the original format. For example, you could write a set of Core Data classes that can read information from the Internet via a socket, present the objects (after first being transparently fetched and parsed) to the calling-code, allow the calling-code to modify the data, and then have the same underlying classes transparently submit the modified data back to the Internet. The end-result is that the code interfacing to the Core Data API has no idea whether the objects presented to it via the ``Core Data Object Model'' came from the local disk, the Internet, a database, an Apache-style config, a BSD-style config, NFS, or anything else. This leaves your application free to change the underlying data structure of how you store/distribute/retrieve the data without having to modify the code that ultimately presents that data to the user (for either viewing or modifying). Your utility loosely reminds me of this in that your utility leaves the end-user blissfully unaware of the underlying configuration-file structure (nice). > FUTURE > Of course, better way is to run modcfg as: > modcfg rc {-s ... | -u ...} > i.e. reduce "-f /etc/rc.conf -t rc" to the key "rc", > i.e. add another call scheme > modcfg subsystem {-s ... | -u ...} > > For rc it is trivial. But in general, for all installed programs and > they instances, it is not possible now. Does your program take into consideration that the rc.conf(5) files are actually shell scripts? They are not Boulder/IO (key=value pairs -- one per-line), or any other similar format. Rather, they are sourced (executed within the same contextual namespace as the parent) shell scripts. When I rewrite my sysrc(8) utility in C, I'll likely be using a parser that I wrote which utilizes the same parsing logic as the POSIX bourne- shell itself. That way, I'm guaranteed to treat these files like what they really are -- shell scripts without an invocation-line -- so that I can catch things like this: hostname=foo; sshd_enable=YES; nfs_client_enable=YES (and that's only the beginning) The logical parser will need to know things like: a. When the state-machine is in the "bare-word space" b. How to treat leading bare-words containing an assignment differently than trailing bare-words containing an assignment c. How to differentiate between different read-states when: 1. within single-quotes 2. within double-quotes 3. within a sub-shell block ($(...), `...`, (...), etc) d. How to interpret nested blocks A suitably-advanced parser capable of doing the right things in all circumstances invariably will need to make use of a LIFO queue (a "stack") to accurately handle nested elements. Thankfully however, we don't need to implement 100% of the POSIX bourne- shell interpreter because in the case of modifying rc.conf(5) files, we really only need to modify assignment operations happening within the bare-word namespace (the top-level namespace opposed to assignments taking place within sub-shells; assignments within sub-shells cannot filter back-up the chain to the calling parent, so we won't care about most all nesting cases). In example, we care about this assignment: hostname=foo but not this one: ( hostname=foo ) nor this one: ignored=$( hostname=foo ) nor this one: : ${hostname:=foo} NOTE: OK, yes that one is in the proper namespace that we care about, but I'm deeming this one as inconsequential because if someone so- desires such a line in their rc.conf(5) file, I'm willing to bet that they also don't want some program blowing away such a line -- considering that it's not really a proper assignment since the assignment only occurs in the event that hostname is null or unset (which depends on the state of /etc/defaults/rc.conf). nor would we care about further obscure assignments, such as: ( ignored="`/bin/sh -c \"hostname=foobar\"`" ) NOTE: That's a sub-shell within a sub-shell within a sub-shell (3 namespaces away from parent/bare-word namespace). Although, maybe we should care about some of the few odd-ball cases where assignments don't look like normal assignments... such as: env hostname=foo However... this is easy because the state-machine will be able to track these, both via our LIFO/stack and by way of checking for when: a. the leading bare-word expands to `env' NOTE: Here, `expands' means not that I intend to perform all the same expansions that the bourne-shell performs, such as parameter expansion, but at least quote expansion b. while being in the top-level namespace And even with all that, we won't catch ALL the possible cases... For example, we'll still fail to catch the following assignment: FOO=env $FOO hostname=bar Which is perfectly valid, since when source_rc_confs() is called at boot-time (by way of /etc/rc called by /sbin/init invoked by the kernel) out of /etc/defaults/rc.conf, the /etc/rc.conf file is essentially executed by /bin/sh, and the above two lines will produce the environment variable: hostname=bar in-turn causing the later stages to read said environment variable and set the ensuing hostname. My sysrc(8) script -- as you can see -- has quite the goal... handle all but the most esoteric cases (such as bare-word abstraction demostrated above ala "FOO=env"). > > > > Wednesday, October 13, 2010, 3:06:25 AM, you wrote: > > DT> On Tue, 2010-10-12 at 12:10 -0700, Doug Barton wrote: > >> On 2010-10-11 at 10:40 -0700, Doug Barton wrote: > >> | So to summarize, the general idea is a good one and needed, and an area > >> | that I'd like to see more work in. Perhaps it might be a good idea to > >> | move the discussion about that to freebsd-rc@? > >> | > >> |On 2010-10-11 at 12:22 -0700, Devin Teske wrote: > >> |> I'll look into signing up for the rc mailing list (didn't see that when > >> |> I checked last -- I'll have to look again). Maybe I'll post v2.0 to > >> |> there (but will cc back hackers cause I know folks may not be part of > >> |> both). > >> > >> The canonical way to deal with that is to post the message to the proper > >> list (-rc@), then post a brief note to the other list (-hackers@) saying > >> where the discussion is being continued. We discourage people from > >> cc'ing multiple FreeBSD lists. > > > DT> This thread is moving over to the -rc@ list. > DT> New thread: sysrc(8) -- a sysctl(8)-like utility for managing rc.conf(5) > > DT> The first post to the -rc@ list will be version 2.0 of the script which > DT> attempts to address the following (which were discussed in this thread > DT> here on -hackers@): > > DT> 1. Style -- remove some personal styles in favor of standardized styles. > DT> (the FreeBSD environment doesn't need all the extra things that are > DT> required to run in an embedded environment -- which the first version > DT> was coded for) > > DT> 2. Remove a disgusting-amount of comments (the first release of the > DT> script had a hurdle to climb in that it had to establish rapport with > DT> the targeted audience -- y'all). > > DT> 3. Remove shell inheritance of SUCCESS/FAILURE (this was silly for a > DT> finished product). > > DT> 4. Remove unnecessary code-sense (some things just don't need to be > DT> tested for in a known environment -- such as FreeBSD vs. embedded). > > DT> 5. Remove dependency checks (have(), depend(), and show_deps() are > DT> gone). > > DT> 6. Remove fake "function" keywords (public objections win) > > DT> 7. Rename sysrc() function to sysrc_get() to: > DT> a. prevent confusion between the script and the internal function > DT> b. to coincide with the remainder of related functions (sysrc_get, > DT> sysrc_set, sysrc_find, and sysrc_desc). > > DT> 8. Fix sysrc_get() function to mask positional parameters (don't expand > DT> "1", "2", etc.) > > DT> 9. Fix sysrc_get() function to clean the environment prior to sourcing > DT> rc.conf(5) files (preventing expansion of normals such as PS1, TERM, > DT> etc.) > > DT> 10. New function: `sysrc_find $varname' > DT> Find which file holds the effective last-assignment to a given variable > DT> within the rc.conf(5) file(s). If the variable is found in any of the > DT> rc.conf(5) files, the function prints the filename it was found in and > DT> then returns success. Otherwise output is NULL and the function returns > DT> with error status. > > DT> 11. Fix sysrc_set() function to use mktemp(1) (prevent race-conditions > DT> where sysrc(8) could be executing in concurrence, possibly whacking the > DT> output-file in an unexpected manner). > > DT> 12. New function: `sysrc_desc $varname' > DT> Attempts to return the comments associated with varname from the rc.conf > DT> (5) defaults file `/etc/defaults/rc.conf' (or whatever RC_DEFAULTS > DT> points to). Multi-line comments are joined together. Results are NULL if > DT> no description could be found. > > DT> 13. Use getopts(1) to parse command-line options rather than manually > DT> parsing (now we can support grouping of flags -- i.e. "-avN"). > > DT> 14. Remove `--help' option (using getopts(1) now ... that was the only > DT> long-option we had, and we don't need it). > > DT> 15. Remove `-d' as we know it. No longer dump internal dependency list, > DT> but mimick `-d' from sysctl(8) -- Print a description of the given > DT> variable. > > DT> 16. Remove `SYSRC_SHOW_DEPS' environment variable. > > DT> 17. Add `SYSRC_VERBOSE' environment variable (inheritable from the > DT> shell, so that folks whom don't want to always pass `-v' can plop > DT> `SYSRC_VERBOSE=1' into their shell startup scripts, `~/.bash_profile' > DT> and `~/.profile' for example). > > DT> 18. Add `-f file' option. > DT> Operate on the specified file(s) instead of rc_conf_files. > > DT> 19. Add `-a' option. > DT> Dump a list of non-default configuration variables. > > DT> 20. Add `-A' option. > DT> Dump a list of all configuration variables (incl. defaults). > > DT> 21. Add `-v' option. > DT> Verbose. Print the pathname of the specific rc.conf(5) file where the > DT> directive was found. > > DT> 22. Add `-i' option. > DT> Ignore unknown variables. > > DT> 23. Add `-N' option. > DT> Show only variable names, not their values. > > > > DT> And, here's the new usage: > > DT> Usage: sysrc [OPTIONS] name[=value] ... > DT> OPTIONS: > DT> -h Print this message to stderr and exit. > DT> -f file Operate on the specified file(s) instead of rc_conf_files. > DT> -a Dump a list of non-default configuration variables. > DT> -A Dump a list of all configuration variables (incl. defaults). > DT> -d Print a description of the given variable. > DT> -e Print query results as `var=value' (useful for producing > DT> output to be fed back in). Ignored if -n is specified. > DT> -v Verbose. Print the pathname of the specific rc.conf(5) > DT> file where the directive was found. > DT> -i Ignore unknown variables. > DT> -n Show only variable values, not their names. > DT> -N Show only variable names, not their values. > > DT> ENVIRONMENT: > DT> RC_DEFAULTS Location of `/etc/defaults/rc.conf' file. > DT> SYSRC_VERBOSE Default verbosity. Set to non-NULL to enable. > > > DT> See you all on the -rc@ list. > > > > -- > Best regards, > Anthony mailto:ap00@mail.ru > > > _______________________________________________ > 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" _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. _____________ From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 25 21:22:12 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 0940E1065672; Mon, 25 Oct 2010 21:22:12 +0000 (UTC) Date: Mon, 25 Oct 2010 21:22:12 +0000 From: Alexander Best To: Garrett Cooper Message-ID: <20101025212212.GB18193@freebsd.org> References: <20101024002248.GA73346@freebsd.org> <20101024115712.GA61342@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: freebsd-hackers@freebsd.org Subject: Re: fix pnpinfo on arch=amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 25 Oct 2010 21:22:12 -0000 On Sun Oct 24 10, Garrett Cooper wrote: > On Sun, Oct 24, 2010 at 4:57 AM, Alexander Best wrote: > > On Sat Oct 23 10, Garrett Cooper wrote: > >> On Sat, Oct 23, 2010 at 5:22 PM, Alexander Best wrote: > >> > this tiny patch will fix pnpinfo so it doesn't core dump (bus error) any > >> > longer on arch=amd64. > >> > >> 1. I had to modify the Makefile to get it to work. > > > > probably because you built pnpinfo from contrib/pnpinfo and not from > > usr.sbin/pnpinfo. i'm not sure your changes to contrib/pnpinfo/Makefile are > > according to current practice. maybe the vendor Makefile shouldn't be modified > > and every additional stuff should rather go into usr.sbin/pnpinfo/Makefile. but > > i don't really know. > > Ah... I was a bit confused as to why there was a copy hanging out > in contrib, because it seems like it was imported primarily to FreeBSD > in 2.2 (which contradicts the manpage as it states that it was > imported in 7.2). I see it's over in DragonFly, but not in the other > BSDs; it has a BSD license; doesn't denote any kind of proprietary > info (leverages some of the FreeBSD isa(4) driver structures); doesn't > have an external website for development; etc. > I was also a bit confused why this directory wasn't iterated over > in usr.sbin, but it appears to be missing from SUBDIR in > usr.sbin/Makefile (wonder how many others are missing and whether or > not the tools / apps really have any value, but that's another top for > another thread). > > > also in the in usr.sbin/pnpinfo/makefile there's a check for PC98 that i'm not > > sure is really needed. > > No, it's not used anymore (I looked over pnpinfo and the > isa/machine headers). > > >> 2. FWIW, I don't there's really much point in adding a check for only > >> x86 architectures, if the tool is capable of more than that. > > > > yeah you're probably right. to be honest i know nothing about > > "archs != i386|amd64". ;) so i just added the amd64 option, because i didn't > > want to break pnpinfo on other platforms. > > Well, but there are other platforms, other than x86 that could > benefit from using this tool (arm, mips, etc). There might be some > bugs lurking in the code dealing with endianness, but that should be > resolved first by enabling the tool for all platforms and fixing the > cases one by one (unfortunately I don't have either architecture at my > disposal, otherwise I'd test this out). I do have a Sparc64 pizza box > that I could test this out on though later on this week... hmmm. > > >> 3. Might as well close the file descriptor after opening it. > > > > right. expecially, because opening /dev/io (even in ro mode) is a huge security > > issue. so better close it asap. > > > > of course on i386/amd64 (maybe pc98 too?) i386_set_ioperm(2) could be used to > > work around the security issue. but since pnpinfo's job is to access hardware > > directly i think opening /dev/io directly can be consideren ok. > > Well, right... but there's no reason to leak a filehandle until > the program is finished :). > > >> SIGBUS occurs because it doesn't have permission to write via outb. > >> It's a shame that there isn't a more proper way to catch this SIGBUS > >> fault minus adding a SIGBUS handler (but that might have other > >> undesired side effects). > > > > well on i386/amd (pc98?) you could use i386_get_ioperm(2) to check for proper > > io permissions. > > Yeah, and it's x86 specific. Kind of curious why there isn't a > more generalized name for this API, but it appeared to be geared > towards x86 (today, not so much according to LEGACY in io(4)). > FWIW, it also looks like the manpages are missing for those > syscalls, even though they're referenced in io(4)... > > $ man i386_get_ioperm > No manual entry for i386_get_ioperm > $ man i386_set_ioperm > No manual entry for i386_set_ioperm are you running amd64? me too. it appears these manual pages are only being installed under i386. that's a bug imo. they should also be installed under amd64. the manuals are in /usr/src/lib/libc/i386/sys/ > > ... and I couldn't find anything in the syscall entry table for > this syscall. I did a bit more poking and it looks like the Linux > ioperm syscall is the only really publicly available means of > accessing this functionality. I could be wrong though. they are defined in /usr/src/sys/amd64/include/sysarch.h (for amd64) and /usr/src/sys/i386/include/sysarch.h (for i386). > Thanks, > -Garrett -- a13x From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 25 22:23: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 BAF1A106564A for ; Mon, 25 Oct 2010 22:23:36 +0000 (UTC) (envelope-from selphie.keller@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 7994E8FC12 for ; Mon, 25 Oct 2010 22:23:36 +0000 (UTC) Received: by gxk9 with SMTP id 9so466189gxk.13 for ; Mon, 25 Oct 2010 15:23:35 -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:content-type; bh=eH3A8PVp7Uo3Aw3okohu+BXCF5dbx2Jp1WbfTKIsRNo=; b=BjDZ6OzgetpY5GDwMT13d6te/SHN2PqArXcFKkfRpqqo2yu6nkCfEFis1VZ9/zLYrG yJHeAKfiQLnjPCkpsPaY1Pud5cxsCELb+xhdFDB/kopEWJnF72Sxx8D3Jn7/eUL67B2e vGKzg8+2mBKPnZt74xIuGembvwryUfKJWd01w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=NVLvnP67lrA31GshDz1O9tJdKlJ8GIwN1ynZ5soguR6yADT3shiO0ErdBk0ssjG5F2 RvnSxTIImXBO895Fsz1ujhaSqSXnYGun3temrZgsOmJvtJ3LzDLLq0uEUQtf/b9Uisg+ rJRgn2fDVL+UMh//YViwb1YBhHraJXN0Qc1aM= MIME-Version: 1.0 Received: by 10.42.170.197 with SMTP id g5mr5193126icz.347.1288044061314; Mon, 25 Oct 2010 15:01:01 -0700 (PDT) Received: by 10.42.164.68 with HTTP; Mon, 25 Oct 2010 15:01:01 -0700 (PDT) Date: Mon, 25 Oct 2010 15:01:01 -0700 Message-ID: From: Selphie Keller To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: SYSCALL_MODULE() macro and modfind() issues X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 25 Oct 2010 22:23:36 -0000 hi fbsd-hackers, Noticed a issue in 8.1-release, 8.1p1-release and 8.1-stable amd64/i386, to where modfind() will no longer find pmap_helper for the /usr/ports/sysutils/pmap port, or other syscall modules using SYSCALL_MODULE() macro. The issue is that modfind() function no longer finds any modules using SYSCALL_MODULE() macro to register the kernel module. Making it difficult for userland apps to call the syscall provided. modfind() always returns -1 which prevents modstat() from getting the required information to perform the syscall. Also tested, the demo syscall module: cat /usr/share/examples/kld/syscall/module/syscall.c /*- * Copyright (c) 1999 Assar Westerlund * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * * $FreeBSD: src/share/examples/kld/syscall/module/syscall.c,v 1.6.2.1.4.1 2010/06/14 02:09:06 kensmith Exp $ */ #include #include #include #include #include #include #include /* * The function for implementing the syscall. */ static int hello(struct thread *td, void *arg) { printf("hello kernel\n"); return (0); } /* * The `sysent' for the new syscall */ static struct sysent hello_sysent = { 0, /* sy_narg */ hello /* sy_call */ }; /* * The offset in sysent where the syscall is allocated. */ static int offset = NO_SYSCALL; /* * The function called at load/unload. */ static int load(struct module *module, int cmd, void *arg) { int error = 0; switch (cmd) { case MOD_LOAD : printf("syscall loaded at %d\n", offset); break; case MOD_UNLOAD : printf("syscall unloaded from %d\n", offset); break; default : error = EOPNOTSUPP; break; } return (error); } SYSCALL_MODULE(syscall, &offset, &hello_sysent, load, NULL); --------------------------------------------------------------------------------------------------------------------- /* userland app to call syscall */ #include #include #include #include int main(int argc, char **argv) { char *endptr; int syscall_num; struct module_stat stat; /*Helloworld syscall test*/ stat.version = sizeof(stat); modstat(modfind("syscall"), &stat); syscall_num = stat.data.intval; syscall (syscall_num); } --------------------------------------------------------------------------------------------------------------------- -Estella Mystagic (Selphie) From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 26 00:01:47 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 A27DB106564A for ; Tue, 26 Oct 2010 00:01:47 +0000 (UTC) (envelope-from gonzo@launchpad.bluezbox.com) Received: from launchpad.bluezbox.com (hq.bluezbox.com [70.38.37.145]) by mx1.freebsd.org (Postfix) with ESMTP id 386718FC0C for ; Tue, 26 Oct 2010 00:01:46 +0000 (UTC) Received: from [140.242.16.2] (helo=[172.23.2.112]) by launchpad.bluezbox.com with esmtpsa (SSLv3:DES-CBC3-SHA:168) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PAWdN-000N6U-3s for hackers@freebsd.org; Mon, 25 Oct 2010 16:39:22 -0700 Message-ID: <4CC61525.2020500@bluezbox.com> Date: Mon, 25 Oct 2010 16:39:17 -0700 From: Oleksandr Tymoshenko User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: gonzo@launchpad.bluezbox.com X-Spam-Level: ---- X-Spam-Report: Spam detection software, running on the system "hq.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: gdb on MIP64 does not read DWARF2 line information correctly if gcc was configured with DWARF_OFFSET_SIZE == 8. .debug_line starts with total length field which could be 12 bytes long or 4 bytes long. If it starts with 0xffffffff - it's 12 bytes long. Depending on its size one of the following field is either 8 bytes or 4 bytes. This one-line patch fixes this issue for MIPS64 but I'm not 100% sure that it doesn't break something else. So I'd appreciate input of someone with better grip on ELF/DWARF stuff then me. [...] Content analysis details: (-4.4 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.0 AWL AWL: From: address is in the auto white-list Cc: Subject: stock gdb bug: DWARF2 with DWARF_OFFSET_SIZE == 8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 00:01:47 -0000 gdb on MIP64 does not read DWARF2 line information correctly if gcc was configured with DWARF_OFFSET_SIZE == 8. .debug_line starts with total length field which could be 12 bytes long or 4 bytes long. If it starts with 0xffffffff - it's 12 bytes long. Depending on its size one of the following field is either 8 bytes or 4 bytes. This one-line patch fixes this issue for MIPS64 but I'm not 100% sure that it doesn't break something else. So I'd appreciate input of someone with better grip on ELF/DWARF stuff then me. Patch: http://people.freebsd.org/~gonzo/patches/mips64gdb.diff Thanks. From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 26 07:28: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 DA859106564A for ; Tue, 26 Oct 2010 07:28:15 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 26E518FC12 for ; Tue, 26 Oct 2010 07:28:14 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA21010; Tue, 26 Oct 2010 10:28:11 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1PAdx5-0002aS-2p; Tue, 26 Oct 2010 10:28:11 +0300 Message-ID: <4CC6830A.10701@icyb.net.ua> Date: Tue, 26 Oct 2010 10:28:10 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: Selphie Keller References: In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Konstantin Belousov Subject: Re: SYSCALL_MODULE() macro and modfind() issues X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 07:28:15 -0000 on 26/10/2010 01:01 Selphie Keller said the following: > hi fbsd-hackers, > > Noticed a issue in 8.1-release, 8.1p1-release and 8.1-stable > amd64/i386, to where modfind() will no longer find pmap_helper for the > /usr/ports/sysutils/pmap port, or other syscall modules using > SYSCALL_MODULE() macro. > The issue is that modfind() function no longer finds any modules using > SYSCALL_MODULE() macro to register the kernel module. Making it > difficult for userland apps to call the syscall provided. modfind() > always returns -1 which prevents modstat() from getting the required > information to perform the syscall. > > Also tested, the demo syscall module: After commit r205320 and, apparently, its MFC you need to prefix the module with "sys/". For example: modstat(modfind("sys/syscall"), &stat); P.S. Perhaps a KPI breakage in a stable branch? -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 26 08:00: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 E7E061065670 for ; Tue, 26 Oct 2010 08:00:15 +0000 (UTC) (envelope-from selphie.keller@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 9FACB8FC17 for ; Tue, 26 Oct 2010 08:00:15 +0000 (UTC) Received: by iwn39 with SMTP id 39so5497668iwn.13 for ; Tue, 26 Oct 2010 01:00:15 -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 :content-transfer-encoding; bh=mmVBE7Y22clxlynp24eur+teSvJQjUdg/tGN6+uWNbM=; b=M9rccneN0gBtcCNsfjFy3poo7a2nl7wsNYxBHUjYaNoiKU2jww7vm39gvza+8e4tT4 KNycM4Iw/8cfKd/EBnouwqPOTvgxr/C0r7dUDKWTep6Oxj7Cnp09Bgvg3iScCiyYKzqF dz/Q1qyK7fu+YCZK1+kKdfzy/h7YNDV8aZMnA= 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:content-transfer-encoding; b=YIyPpD//wRhE9cRR0RkkXWR6e2qH7g+uSsnHEj/+fA9C24jIw+5rrQLLl4kNRi3qzW XOVLkUd5mQFSY3Y1xQShD80y+7RfV/FPPRETwDq1YT6AeBSD7rfbij8lpSXprWXJvVVY zF8Mefo5GHS0W+B+JBTCxLI8QmAvZLstEFjOo= MIME-Version: 1.0 Received: by 10.42.170.197 with SMTP id g5mr5536333icz.347.1288080014968; Tue, 26 Oct 2010 01:00:14 -0700 (PDT) Received: by 10.42.164.68 with HTTP; Tue, 26 Oct 2010 01:00:14 -0700 (PDT) In-Reply-To: <4CC6830A.10701@icyb.net.ua> References: <4CC6830A.10701@icyb.net.ua> Date: Tue, 26 Oct 2010 01:00:14 -0700 Message-ID: From: Selphie Keller To: Andriy Gapon , freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: SYSCALL_MODULE() macro and modfind() issues X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 08:00:16 -0000 Thanks Andriy, Took a look at the change to src/sys/sys/sysent.h @@ -149,7 +149,7 @@ static struct syscall_module_data name## }; \ \ static moduledata_t name##_mod =3D { \ - #name, \ + "sys/" #name, \ syscall_module_handler, \ &name##_syscall_mod \ }; \ applied the MFC prefix to pmap port: --- /usr/ports/sysutils/pmap/work/pmap/pmap/pmap.c.orig 2010-10-26 00:55:32.000000000 -0700 +++ /usr/ports/sysutils/pmap/work/pmap/pmap/pmap.c 2010-10-26 00:56:10.000000000 -0700 @@ -86,12 +86,12 @@ main(int argc, char **argv) struct kinfo_proc *kp; int pmap_helper_syscall; - if ((modid =3D modfind("pmap_helper")) =3D=3D -1) { + if ((modid =3D modfind("sys/pmap_helper")) =3D=3D -1) { /* module not found, try to load */ modid =3D kldload("pmap_helper.ko"); if (modid =3D=3D -1) err(1, "unable to load pmap_helper module"); - modid =3D modfind("pmap_helper"); + modid =3D modfind("sys/pmap_helper"); if (modid =3D=3D -1) err(1, "pmap_helper module loaded but not found"); } which restored functionality on freebsd 8.1. -Estella Mystagic (Selphie) On Tue, Oct 26, 2010 at 12:28 AM, Andriy Gapon wrote: > on 26/10/2010 01:01 Selphie Keller said the following: >> hi fbsd-hackers, >> >> Noticed a issue in 8.1-release, 8.1p1-release and 8.1-stable >> amd64/i386, to where modfind() will no longer find pmap_helper for the >> /usr/ports/sysutils/pmap port, or other syscall modules using >> SYSCALL_MODULE() macro. >> The issue is that modfind() function no longer finds any modules using >> SYSCALL_MODULE() macro to register the kernel module. Making it >> difficult for userland apps to call the syscall provided. modfind() >> always returns -1 which prevents modstat() from getting the required >> information to perform the syscall. >> >> Also tested, the demo syscall module: > > After commit r205320 and, apparently, its MFC you need to prefix the modu= le with > "sys/". =A0For example: > modstat(modfind("sys/syscall"), &stat); > > P.S. > Perhaps a KPI breakage in a stable branch? > -- > Andriy Gapon > From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 26 13:46:04 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 7AD67106572D; Tue, 26 Oct 2010 13:46:04 +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 4B2C88FC13; Tue, 26 Oct 2010 13:46:04 +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 879AA46B46; Tue, 26 Oct 2010 09:46:03 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 71D7D8A01D; Tue, 26 Oct 2010 09:46:02 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Tue, 26 Oct 2010 09:31:36 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <4CC6830A.10701@icyb.net.ua> In-Reply-To: <4CC6830A.10701@icyb.net.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201010260931.36342.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 26 Oct 2010 09:46:02 -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: Konstantin Belousov , Andriy Gapon , Selphie Keller Subject: Re: SYSCALL_MODULE() macro and modfind() issues X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 13:46:04 -0000 On Tuesday, October 26, 2010 3:28:10 am Andriy Gapon wrote: > on 26/10/2010 01:01 Selphie Keller said the following: > > hi fbsd-hackers, > > > > Noticed a issue in 8.1-release, 8.1p1-release and 8.1-stable > > amd64/i386, to where modfind() will no longer find pmap_helper for the > > /usr/ports/sysutils/pmap port, or other syscall modules using > > SYSCALL_MODULE() macro. > > The issue is that modfind() function no longer finds any modules using > > SYSCALL_MODULE() macro to register the kernel module. Making it > > difficult for userland apps to call the syscall provided. modfind() > > always returns -1 which prevents modstat() from getting the required > > information to perform the syscall. > > > > Also tested, the demo syscall module: > > After commit r205320 and, apparently, its MFC you need to prefix the module with > "sys/". For example: > modstat(modfind("sys/syscall"), &stat); > > P.S. > Perhaps a KPI breakage in a stable branch? Ugh, it was a breakage though it's too late to back it out at this point. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 26 13:46:06 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 175B71065670 for ; Tue, 26 Oct 2010 13:46:06 +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 C00338FC16 for ; Tue, 26 Oct 2010 13:46:05 +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 495BF46B5B; Tue, 26 Oct 2010 09:46:05 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 0F0E28A027; Tue, 26 Oct 2010 09:46:04 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Tue, 26 Oct 2010 09:34:57 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <4CC6830A.10701@icyb.net.ua> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201010260934.57247.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 26 Oct 2010 09:46:04 -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: Andriy Gapon , Selphie Keller Subject: Re: SYSCALL_MODULE() macro and modfind() issues X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 13:46:06 -0000 On Tuesday, October 26, 2010 4:00:14 am Selphie Keller wrote: > Thanks Andriy, > > Took a look at the change to src/sys/sys/sysent.h > > @@ -149,7 +149,7 @@ static struct syscall_module_data name## > }; \ > \ > static moduledata_t name##_mod = { \ > - #name, \ > + "sys/" #name, \ > syscall_module_handler, \ > &name##_syscall_mod \ > }; \ > > applied the MFC prefix to pmap port: > > --- /usr/ports/sysutils/pmap/work/pmap/pmap/pmap.c.orig 2010-10-26 > 00:55:32.000000000 -0700 > +++ /usr/ports/sysutils/pmap/work/pmap/pmap/pmap.c 2010-10-26 > 00:56:10.000000000 -0700 > @@ -86,12 +86,12 @@ main(int argc, char **argv) > struct kinfo_proc *kp; > int pmap_helper_syscall; > > - if ((modid = modfind("pmap_helper")) == -1) { > + if ((modid = modfind("sys/pmap_helper")) == -1) { > /* module not found, try to load */ > modid = kldload("pmap_helper.ko"); > if (modid == -1) > err(1, "unable to load pmap_helper module"); > - modid = modfind("pmap_helper"); > + modid = modfind("sys/pmap_helper"); > if (modid == -1) > err(1, "pmap_helper module loaded but not found"); > } > > which restored functionality on freebsd 8.1. The best approach might be to have something like this: static int pmap_find(void) { int modid; modid = modfind("pmap_helper"); if (modid == -1) modid = modfind("sys/pmap_helper"); return (modid); } then in the original main() routine use this: if ((modid = pmap_find()) == -1) { /* module not found, try to load */ modid = kldload("pmap_helper.ko"); if (modid == -1) err(1, "unable to load pmap_helper module"); modid = pmap_find(); if (modid == -1) err(1, "pmap_helper module loaded but not found"); } This would make the code work for both old and new versions. > -Estella Mystagic (Selphie) > > On Tue, Oct 26, 2010 at 12:28 AM, Andriy Gapon wrote: > > on 26/10/2010 01:01 Selphie Keller said the following: > >> hi fbsd-hackers, > >> > >> Noticed a issue in 8.1-release, 8.1p1-release and 8.1-stable > >> amd64/i386, to where modfind() will no longer find pmap_helper for the > >> /usr/ports/sysutils/pmap port, or other syscall modules using > >> SYSCALL_MODULE() macro. > >> The issue is that modfind() function no longer finds any modules using > >> SYSCALL_MODULE() macro to register the kernel module. Making it > >> difficult for userland apps to call the syscall provided. modfind() > >> always returns -1 which prevents modstat() from getting the required > >> information to perform the syscall. > >> > >> Also tested, the demo syscall module: > > > > After commit r205320 and, apparently, its MFC you need to prefix the module with > > "sys/". For example: > > modstat(modfind("sys/syscall"), &stat); > > > > P.S. > > Perhaps a KPI breakage in a stable branch? > > -- > > Andriy Gapon > > > _______________________________________________ > 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" > -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 26 13:46:07 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 A94BA106566C for ; Tue, 26 Oct 2010 13:46:07 +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 771E98FC13 for ; Tue, 26 Oct 2010 13:46:07 +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 1F0FD46B7F; Tue, 26 Oct 2010 09:46:07 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 95E838A029; Tue, 26 Oct 2010 09:46:05 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Tue, 26 Oct 2010 09:39:40 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <4CC61525.2020500@bluezbox.com> In-Reply-To: <4CC61525.2020500@bluezbox.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201010260939.40487.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 26 Oct 2010 09:46:05 -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: stock gdb bug: DWARF2 with DWARF_OFFSET_SIZE == 8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 13:46:07 -0000 On Monday, October 25, 2010 7:39:17 pm Oleksandr Tymoshenko wrote: > gdb on MIP64 does not read DWARF2 line information correctly if > gcc was configured with DWARF_OFFSET_SIZE == 8. > > .debug_line starts with total length field which could be 12 bytes > long or 4 bytes long. If it starts with 0xffffffff - it's 12 bytes > long. Depending on its size one of the following field is either 8 > bytes or 4 bytes. This one-line patch fixes this issue for MIPS64 > but I'm not 100% sure that it doesn't break something else. So > I'd appreciate input of someone with better grip on ELF/DWARF > stuff then me. > > Patch: > http://people.freebsd.org/~gonzo/patches/mips64gdb.diff I looked at GDB 6.6's source and it does pass in &cu->header instead of NULL at the same place, so I think your fix is correct. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 26 18:09: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 E3691106566B; Tue, 26 Oct 2010 18:09:55 +0000 (UTC) (envelope-from yanegomi@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 95A208FC1B; Tue, 26 Oct 2010 18:09:54 +0000 (UTC) Received: by eyb7 with SMTP id 7so2405783eyb.13 for ; Tue, 26 Oct 2010 11:09:53 -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:content-type; bh=wMk+3BDf7uvz0PojjEX/wITLFqnR4ct66VPDI3D0A18=; b=LZb2iuJ8vTRBG1FbTXkFQ05XTqPNBKfsfLkDicHuNkTHn9IPOLKAK+wwl9vK96+4LK PvFpJOnXjD8M3E+Y62ARhSV5YlF/XiuKRV7dwtTwk9Y+pgendSYvMwloQUidX4GrlD7e PnZN1eUN3WM2YrxRg6WCaewMqkFlbfWa5DKBE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=LeHatsEq85yxj0wAA7SjFvGPMzwzFQpHxkYJ46QYwTYFBOP2MeLizLlE8JwCgsivlw wi6g1zorny4GjtlulXykNPildbhqotu4J4wwvKSuUO66MM773uNUzNfJezwfA+BeUGHd fUDbIrJ59U98UwQJSskJhIqeST3hxjXxUgUtU= MIME-Version: 1.0 Received: by 10.216.164.66 with SMTP id b44mr2096087wel.81.1288116593311; Tue, 26 Oct 2010 11:09:53 -0700 (PDT) Received: by 10.216.10.198 with HTTP; Tue, 26 Oct 2010 11:09:53 -0700 (PDT) Date: Tue, 26 Oct 2010 11:09:53 -0700 Message-ID: From: Garrett Cooper To: freebsd-hackers@freebsd.org Content-Type: multipart/mixed; boundary=0016e64967c8f95e77049389033e Subject: [PATCH] mfiutil(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: Tue, 26 Oct 2010 18:09:56 -0000 --0016e64967c8f95e77049389033e Content-Type: text/plain; charset=ISO-8859-1 Because a number of places in the mfiutil(8) code immediately call warn(3) after an error to an API occurred, and because warn(3) employs printf, et all (multiple times) in libc, there's an off-chance that the errno value can get stomped on by the warn(3) calls, which could lead to confusing results from anyone depending on the value being returned from the mfiutil APIs. Thus, the attached patch I'm providing fixes those cases, as well as converts an existing internal API (display_pending_firmware) to an non-void return mechanism. I also made a few stack variable alignment changes to match style(9) as well as got rid of the ad hoc powerof2 call in favor of the value in sys/param.h. I've run a small number of unit tests on my desktop at home with my mfi(4) card, but will test out other failing cases with equipment I have access to at work. Thanks! -Garrett --0016e64967c8f95e77049389033e Content-Type: text/x-patch; charset=US-ASCII; name="mfiutil-capture-errno-values.patch" Content-Disposition: attachment; filename="mfiutil-capture-errno-values.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gfr3a4kx0 SW5kZXg6IHVzci5zYmluL21maXV0aWwvbWZpX2NvbmZpZy5jCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHVzci5z YmluL21maXV0aWwvbWZpX2NvbmZpZy5jCShyZXZpc2lvbiAyMTQyNjApCisrKyB1c3Iuc2Jpbi9t Zml1dGlsL21maV9jb25maWcuYwkod29ya2luZyBjb3B5KQpAQCAtMjksMTIgKzI5LDEzIEBACiAg KiAkRnJlZUJTRCQKICAqLwogCisjaW5jbHVkZSA8c3lzL3BhcmFtLmg+CiAjaW5jbHVkZSA8c3lz L3R5cGVzLmg+CiAjaWZkZWYgREVCVUcKICNpbmNsdWRlIDxzeXMvc3lzY3RsLmg+CiAjZW5kaWYK LSNpbmNsdWRlIDxzeXMvZXJybm8uaD4KICNpbmNsdWRlIDxlcnIuaD4KKyNpbmNsdWRlIDxlcnJu by5oPgogI2luY2x1ZGUgPGxpYnV0aWwuaD4KICNpZmRlZiBERUJVRwogI2luY2x1ZGUgPHN0ZGlu dC5oPgpAQCAtNTIsOCArNTMsNiBAQAogc3RhdGljIGludAlhZGRfc3BhcmUoaW50IGFjLCBjaGFy ICoqYXYpOwogc3RhdGljIGludAlyZW1vdmVfc3BhcmUoaW50IGFjLCBjaGFyICoqYXYpOwogCi0j ZGVmaW5lIHBvd2Vyb2YyKHgpICAgICgoKCh4KS0xKSYoeCkpPT0wKQotCiBzdGF0aWMgbG9uZwog ZGVodW1hbml6ZShjb25zdCBjaGFyICp2YWx1ZSkKIHsKQEAgLTE1MSwxMyArMTUwLDE0IEBACiBj bGVhcl9jb25maWcoaW50IGFjLCBjaGFyICoqYXYpCiB7CiAJc3RydWN0IG1maV9sZF9saXN0IGxp c3Q7Ci0JaW50IGNoLCBmZDsKKwlpbnQgY2gsIGVycm9yLCBmZDsKIAl1X2ludCBpOwogCiAJZmQg PSBtZmlfb3BlbihtZmlfdW5pdCk7CiAJaWYgKGZkIDwgMCkgeworCQllcnJvciA9IGVycm5vOwog CQl3YXJuKCJtZmlfb3BlbiIpOwotCQlyZXR1cm4gKGVycm5vKTsKKwkJcmV0dXJuIChlcnJvcik7 CiAJfQogCiAJaWYgKCFtZmlfcmVjb25maWdfc3VwcG9ydGVkKCkpIHsKQEAgLTE2Nyw4ICsxNjcs OSBAQAogCX0KIAogCWlmIChtZmlfbGRfZ2V0X2xpc3QoZmQsICZsaXN0LCBOVUxMKSA8IDApIHsK KwkJZXJyb3IgPSBlcnJubzsKIAkJd2FybigiRmFpbGVkIHRvIGdldCB2b2x1bWUgbGlzdCIpOwot CQlyZXR1cm4gKGVycm5vKTsKKwkJcmV0dXJuIChlcnJvcik7CiAJfQogCiAJZm9yIChpID0gMDsg aSA8IGxpc3QubGRfY291bnQ7IGkrKykgewpAQCAtMTg5LDggKzE5MCw5IEBACiAJfQogCiAJaWYg KG1maV9kY21kX2NvbW1hbmQoZmQsIE1GSV9EQ01EX0NGR19DTEVBUiwgTlVMTCwgMCwgTlVMTCwg MCwgTlVMTCkgPCAwKSB7CisJCWVycm9yID0gZXJybm87CiAJCXdhcm4oIkZhaWxlZCB0byBjbGVh ciBjb25maWd1cmF0aW9uIik7Ci0JCXJldHVybiAoZXJybm8pOworCQlyZXR1cm4gKGVycm9yKTsK IAl9CiAKIAlwcmludGYoIm1maSVkOiBDb25maWd1cmF0aW9uIGNsZWFyZWRcbiIsIG1maV91bml0 KTsKQEAgLTMzNSw4ICszMzcsOSBAQAogCQkJcmV0dXJuIChlcnJvcik7CiAKIAkJaWYgKG1maV9w ZF9nZXRfaW5mbyhmZCwgZGV2aWNlX2lkLCBwaW5mbywgTlVMTCkgPCAwKSB7CisJCQllcnJvciA9 IGVycm5vOwogCQkJd2FybigiRmFpbGVkIHRvIGZldGNoIGRyaXZlIGluZm8gZm9yIGRyaXZlICVz IiwgY3ApOwotCQkJcmV0dXJuIChlcnJubyk7CisJCQlyZXR1cm4gKGVycm9yKTsKIAkJfQogCiAJ CWlmIChwaW5mby0+Zndfc3RhdGUgIT0gTUZJX1BEX1NUQVRFX1VOQ09ORklHVVJFRF9HT09EKSB7 CkBAIC01NDgsOCArNTUxLDkgQEAKIAkKIAlmZCA9IG1maV9vcGVuKG1maV91bml0KTsKIAlpZiAo ZmQgPCAwKSB7CisJCWVycm9yID0gZXJybm87CiAJCXdhcm4oIm1maV9vcGVuIik7Ci0JCXJldHVy biAoZXJybm8pOworCQlyZXR1cm4gKGVycm9yKTsKIAl9CiAKIAlpZiAoIW1maV9yZWNvbmZpZ19z dXBwb3J0ZWQoKSkgewpAQCAtNjYwLDggKzY2NCw5IEBACiAJICogYXJyYXkgYW5kIHZvbHVtZSBp ZGVudGlmaWVycy4KIAkgKi8KIAlpZiAobWZpX2NvbmZpZ19yZWFkKGZkLCAmY29uZmlnKSA8IDAp IHsKKwkJZXJyb3IgPSBlcnJubzsKIAkJd2FybigiRmFpbGVkIHRvIHJlYWQgY29uZmlndXJhdGlv biIpOwotCQlyZXR1cm4gKGVycm5vKTsKKwkJcmV0dXJuIChlcnJvcik7CiAJfQogCXAgPSAoY2hh ciAqKWNvbmZpZy0+YXJyYXk7CiAJc3RhdGUuYXJyYXlfcmVmID0gMHhmZmZmOwpAQCAtNzQ1LDE0 ICs3NTAsMTQgQEAKICNpZmRlZiBERUJVRwogCWlmIChkdW1wKQogCQlkdW1wX2NvbmZpZyhmZCwg Y29uZmlnKTsKLQllbHNlCiAjZW5kaWYKIAogCS8qIFNlbmQgdGhlIG5ldyBjb25maWcgdG8gdGhl IGNvbnRyb2xsZXIuICovCiAJaWYgKG1maV9kY21kX2NvbW1hbmQoZmQsIE1GSV9EQ01EX0NGR19B REQsIGNvbmZpZywgY29uZmlnX3NpemUsCiAJICAgIE5VTEwsIDAsIE5VTEwpIDwgMCkgeworCQll cnJvciA9IGVycm5vOwogCQl3YXJuKCJGYWlsZWQgdG8gYWRkIHZvbHVtZSIpOwotCQlyZXR1cm4g KGVycm5vKTsKKwkJcmV0dXJuIChlcnJvcik7CiAJfQogCiAJLyogQ2xlYW4gdXAuICovCkBAIC03 NzQsNyArNzc5LDcgQEAKIGRlbGV0ZV92b2x1bWUoaW50IGFjLCBjaGFyICoqYXYpCiB7CiAJc3Ry dWN0IG1maV9sZF9pbmZvIGluZm87Ci0JaW50IGZkOworCWludCBlcnJvciwgZmQ7CiAJdWludDhf dCB0YXJnZXRfaWQsIG1ib3hbNF07CiAKIAkvKgpAQCAtNzk5LDggKzgwNCw5IEBACiAKIAlmZCA9 IG1maV9vcGVuKG1maV91bml0KTsKIAlpZiAoZmQgPCAwKSB7CisJCWVycm9yID0gZXJybm87CiAJ CXdhcm4oIm1maV9vcGVuIik7Ci0JCXJldHVybiAoZXJybm8pOworCQlyZXR1cm4gKGVycm9yKTsK IAl9CiAKIAlpZiAoIW1maV9yZWNvbmZpZ19zdXBwb3J0ZWQoKSkgewpAQCAtODEwLDEzICs4MTYs MTUgQEAKIAl9CiAKIAlpZiAobWZpX2xvb2t1cF92b2x1bWUoZmQsIGF2WzFdLCAmdGFyZ2V0X2lk KSA8IDApIHsKKwkJZXJyb3IgPSBlcnJubzsKIAkJd2FybigiSW52YWxpZCB2b2x1bWUgJXMiLCBh dlsxXSk7Ci0JCXJldHVybiAoZXJybm8pOworCQlyZXR1cm4gKGVycm9yKTsKIAl9CiAKIAlpZiAo bWZpX2xkX2dldF9pbmZvKGZkLCB0YXJnZXRfaWQsICZpbmZvLCBOVUxMKSA8IDApIHsKKwkJZXJy b3IgPSBlcnJubzsKIAkJd2FybigiRmFpbGVkIHRvIGdldCBpbmZvIGZvciB2b2x1bWUgJWQiLCB0 YXJnZXRfaWQpOwotCQlyZXR1cm4gKGVycm5vKTsKKwkJcmV0dXJuIChlcnJvcik7CiAJfQogCiAJ aWYgKG1maV92b2x1bWVfYnVzeShmZCwgdGFyZ2V0X2lkKSkgewpAQCAtODI4LDggKzgzNiw5IEBA CiAJbWJveF9zdG9yZV9sZHJlZihtYm94LCAmaW5mby5sZF9jb25maWcucHJvcGVydGllcy5sZCk7 CiAJaWYgKG1maV9kY21kX2NvbW1hbmQoZmQsIE1GSV9EQ01EX0xEX0RFTEVURSwgTlVMTCwgMCwg bWJveCwKIAkgICAgc2l6ZW9mKG1ib3gpLCBOVUxMKSA8IDApIHsKKwkJZXJyb3IgPSBlcnJubzsK IAkJd2FybigiRmFpbGVkIHRvIGRlbGV0ZSB2b2x1bWUiKTsKLQkJcmV0dXJuIChlcnJubyk7CisJ CXJldHVybiAoZXJyb3IpOwogCX0KIAogCWNsb3NlKGZkKTsKQEAgLTg1OCw4ICs4NjcsOSBAQAog CiAJZmQgPSBtZmlfb3BlbihtZmlfdW5pdCk7CiAJaWYgKGZkIDwgMCkgeworCQllcnJvciA9IGVy cm5vOwogCQl3YXJuKCJtZmlfb3BlbiIpOwotCQlyZXR1cm4gKGVycm5vKTsKKwkJcmV0dXJuIChl cnJvcik7CiAJfQogCiAJZXJyb3IgPSBtZmlfbG9va3VwX2RyaXZlKGZkLCBhdlsxXSwgJmRldmlj ZV9pZCk7CkBAIC04NjcsOCArODc3LDkgQEAKIAkJcmV0dXJuIChlcnJvcik7CiAKIAlpZiAobWZp X3BkX2dldF9pbmZvKGZkLCBkZXZpY2VfaWQsICZpbmZvLCBOVUxMKSA8IDApIHsKKwkJZXJyb3Ig PSBlcnJubzsKIAkJd2FybigiRmFpbGVkIHRvIGZldGNoIGRyaXZlIGluZm8iKTsKLQkJcmV0dXJu IChlcnJubyk7CisJCXJldHVybiAoZXJyb3IpOwogCX0KIAogCWlmIChpbmZvLmZ3X3N0YXRlICE9 IE1GSV9QRF9TVEFURV9VTkNPTkZJR1VSRURfR09PRCkgewpAQCAtODc4LDE0ICs4ODksMTYgQEAK IAogCWlmIChhYyA+IDIpIHsKIAkJaWYgKG1maV9sb29rdXBfdm9sdW1lKGZkLCBhdlsyXSwgJnRh cmdldF9pZCkgPCAwKSB7CisJCQllcnJvciA9IGVycm5vOwogCQkJd2FybigiSW52YWxpZCB2b2x1 bWUgJXMiLCBhdlsyXSk7Ci0JCQlyZXR1cm4gKGVycm5vKTsKKwkJCXJldHVybiAoZXJyb3IpOwog CQl9CiAJfQogCiAJaWYgKG1maV9jb25maWdfcmVhZChmZCwgJmNvbmZpZykgPCAwKSB7CisJCWVy cm9yID0gZXJybm87CiAJCXdhcm4oIkZhaWxlZCB0byByZWFkIGNvbmZpZ3VyYXRpb24iKTsKLQkJ cmV0dXJuIChlcnJubyk7CisJCXJldHVybiAoZXJyb3IpOwogCX0KIAogCXNwYXJlID0gbWFsbG9j KHNpemVvZihzdHJ1Y3QgbWZpX3NwYXJlKSArIHNpemVvZih1aW50MTZfdCkgKgpAQCAtOTM5LDgg Kzk1Miw5IEBACiAJaWYgKG1maV9kY21kX2NvbW1hbmQoZmQsIE1GSV9EQ01EX0NGR19NQUtFX1NQ QVJFLCBzcGFyZSwKIAkgICAgc2l6ZW9mKHN0cnVjdCBtZmlfc3BhcmUpICsgc2l6ZW9mKHVpbnQx Nl90KSAqIHNwYXJlLT5hcnJheV9jb3VudCwKIAkgICAgTlVMTCwgMCwgTlVMTCkgPCAwKSB7CisJ CWVycm9yID0gZXJybm87CiAJCXdhcm4oIkZhaWxlZCB0byBhc3NpZ24gc3BhcmUiKTsKLQkJcmV0 dXJuIChlcnJubyk7CisJCXJldHVybiAoZXJyb3IpOwogCX0KIAogCWNsb3NlKGZkKTsKQEAgLTk2 NCw4ICs5NzgsOSBAQAogCiAJZmQgPSBtZmlfb3BlbihtZmlfdW5pdCk7CiAJaWYgKGZkIDwgMCkg eworCQllcnJvciA9IGVycm5vOwogCQl3YXJuKCJtZmlfb3BlbiIpOwotCQlyZXR1cm4gKGVycm5v KTsKKwkJcmV0dXJuIChlcnJvcik7CiAJfQogCiAJZXJyb3IgPSBtZmlfbG9va3VwX2RyaXZlKGZk LCBhdlsxXSwgJmRldmljZV9pZCk7CkBAIC05NzQsOCArOTg5LDkgQEAKIAogCS8qIEdldCB0aGUg aW5mbyBmb3IgdGhpcyBkcml2ZS4gKi8KIAlpZiAobWZpX3BkX2dldF9pbmZvKGZkLCBkZXZpY2Vf aWQsICZpbmZvLCBOVUxMKSA8IDApIHsKKwkJZXJyb3IgPSBlcnJubzsKIAkJd2FybigiRmFpbGVk IHRvIGZldGNoIGluZm8gZm9yIGRyaXZlICV1IiwgZGV2aWNlX2lkKTsKLQkJcmV0dXJuIChlcnJu byk7CisJCXJldHVybiAoZXJyb3IpOwogCX0KIAogCWlmIChpbmZvLmZ3X3N0YXRlICE9IE1GSV9Q RF9TVEFURV9IT1RfU1BBUkUpIHsKQEAgLTk4Niw4ICsxMDAyLDkgQEAKIAltYm94X3N0b3JlX3Bk cmVmKG1ib3gsICZpbmZvLnJlZik7CiAJaWYgKG1maV9kY21kX2NvbW1hbmQoZmQsIE1GSV9EQ01E X0NGR19SRU1PVkVfU1BBUkUsIE5VTEwsIDAsIG1ib3gsCiAJICAgIHNpemVvZihtYm94KSwgTlVM TCkgPCAwKSB7CisJCWVycm9yID0gZXJybm87CiAJCXdhcm4oIkZhaWxlZCB0byBkZWxldGUgc3Bh cmUiKTsKLQkJcmV0dXJuIChlcnJubyk7CisJCXJldHVybiAoZXJyb3IpOwogCX0KIAogCWNsb3Nl KGZkKTsKQEAgLTEwOTMsNyArMTExMCw3IEBACiBkZWJ1Z19jb25maWcoaW50IGFjLCBjaGFyICoq YXYpCiB7CiAJc3RydWN0IG1maV9jb25maWdfZGF0YSAqY29uZmlnOwotCWludCBmZDsKKwlpbnQg ZXJyb3IsIGZkOwogCiAJaWYgKGFjICE9IDEpIHsKIAkJd2FybngoImRlYnVnOiBleHRyYSBhcmd1 bWVudHMiKTsKQEAgLTExMDIsMTQgKzExMTksMTYgQEAKIAogCWZkID0gbWZpX29wZW4obWZpX3Vu aXQpOwogCWlmIChmZCA8IDApIHsKKwkJZXJyb3IgPSBlcnJubzsKIAkJd2FybigibWZpX29wZW4i KTsKLQkJcmV0dXJuIChlcnJubyk7CisJCXJldHVybiAoZXJyb3IpOwogCX0KIAogCS8qIEdldCB0 aGUgY29uZmlnIGZyb20gdGhlIGNvbnRyb2xsZXIuICovCiAJaWYgKG1maV9jb25maWdfcmVhZChm ZCwgJmNvbmZpZykgPCAwKSB7CisJCWVycm9yID0gZXJybm87CiAJCXdhcm4oIkZhaWxlZCB0byBn ZXQgY29uZmlnIik7Ci0JCXJldHVybiAoZXJybm8pOworCQlyZXR1cm4gKGVycm9yKTsKIAl9CiAK IAkvKiBEdW1wIG91dCB0aGUgY29uZmlndXJhdGlvbi4gKi8KQEAgLTExMjcsNyArMTE0Niw3IEBA CiAJc3RydWN0IG1maV9jb25maWdfZGF0YSAqY29uZmlnOwogCWNoYXIgYnVmWzY0XTsKIAlzaXpl X3QgbGVuOwotCWludCBmZDsKKwlpbnQgZXJyb3IsIGZkOwogCiAJaWYgKGFjICE9IDEpIHsKIAkJ d2FybngoImR1bXA6IGV4dHJhIGFyZ3VtZW50cyIpOwpAQCAtMTEzNiwyMyArMTE1NSwyNiBAQAog CiAJZmQgPSBtZmlfb3BlbihtZmlfdW5pdCk7CiAJaWYgKGZkIDwgMCkgeworCQllcnJvciA9IGVy cm5vOwogCQl3YXJuKCJtZmlfb3BlbiIpOwotCQlyZXR1cm4gKGVycm5vKTsKKwkJcmV0dXJuIChl cnJvcik7CiAJfQogCiAJLyogR2V0IHRoZSBzdGFzaGVkIGNvcHkgb2YgdGhlIGxhc3QgZGNtZCBm cm9tIHRoZSBkcml2ZXIuICovCiAJc25wcmludGYoYnVmLCBzaXplb2YoYnVmKSwgImRldi5tZmku JWQuZGVidWdfY29tbWFuZCIsIG1maV91bml0KTsKIAlpZiAoc3lzY3RsYnluYW1lKGJ1ZiwgTlVM TCwgJmxlbiwgTlVMTCwgMCkgPCAwKSB7CisJCWVycm9yID0gZXJybm87CiAJCXdhcm4oIkZhaWxl ZCB0byByZWFkIGRlYnVnIGNvbW1hbmQiKTsKLQkJaWYgKGVycm5vID09IEVOT0VOVCkKLQkJCWVy cm5vID0gRU9QTk9UU1VQUDsKLQkJcmV0dXJuIChlcnJubyk7CisJCWlmIChlcnJvciA9PSBFTk9F TlQpCisJCQllcnJvciA9IEVPUE5PVFNVUFA7CisJCXJldHVybiAoZXJyb3IpOwogCX0KIAogCWNv bmZpZyA9IG1hbGxvYyhsZW4pOwogCWlmIChzeXNjdGxieW5hbWUoYnVmLCBjb25maWcsICZsZW4s IE5VTEwsIDApIDwgMCkgeworCQllcnJvciA9IGVycm5vOwogCQl3YXJuKCJGYWlsZWQgdG8gcmVh ZCBkZWJ1ZyBjb21tYW5kIik7Ci0JCXJldHVybiAoZXJybm8pOworCQlyZXR1cm4gKGVycm9yKTsK IAl9CiAJZHVtcF9jb25maWcoZmQsIGNvbmZpZyk7CiAJZnJlZShjb25maWcpOwpJbmRleDogdXNy LnNiaW4vbWZpdXRpbC9tZmlfdm9sdW1lLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gdXNyLnNiaW4vbWZpdXRp bC9tZmlfdm9sdW1lLmMJKHJldmlzaW9uIDIxNDI2MCkKKysrIHVzci5zYmluL21maXV0aWwvbWZp X3ZvbHVtZS5jCSh3b3JraW5nIGNvcHkpCkBAIC0xMTQsNiArMTE0LDcgQEAKIHVwZGF0ZV9jYWNo ZV9wb2xpY3koaW50IGZkLCBzdHJ1Y3QgbWZpX2xkX3Byb3BzICpwcm9wcywgdWludDhfdCBuZXdf cG9saWN5LAogICAgIHVpbnQ4X3QgbWFzaykKIHsKKwlpbnQgZXJyb3I7CiAJdWludDhfdCBjaGFu Z2VzLCBwb2xpY3k7CiAKIAlwb2xpY3kgPSAocHJvcHMtPmRlZmF1bHRfY2FjaGVfcG9saWN5ICYg fm1hc2spIHwgbmV3X3BvbGljeTsKQEAgLTE0MCw4ICsxNDEsOSBAQAogCiAJcHJvcHMtPmRlZmF1 bHRfY2FjaGVfcG9saWN5ID0gcG9saWN5OwogCWlmIChtZmlfbGRfc2V0X3Byb3BzKGZkLCBwcm9w cykgPCAwKSB7CisJCWVycm9yID0gZXJybm87CiAJCXdhcm4oIkZhaWxlZCB0byBzZXQgdm9sdW1l IHByb3BlcnRpZXMiKTsKLQkJcmV0dXJuIChlcnJubyk7CisJCXJldHVybiAoZXJyb3IpOwogCX0K IAlyZXR1cm4gKDApOwogfQpAQCAtMTYwLDE4ICsxNjIsMjEgQEAKIAogCWZkID0gbWZpX29wZW4o bWZpX3VuaXQpOwogCWlmIChmZCA8IDApIHsKKwkJZXJyb3IgPSBlcnJubzsKIAkJd2FybigibWZp X29wZW4iKTsKLQkJcmV0dXJuIChlcnJubyk7CisJCXJldHVybiAoZXJyb3IpOwogCX0KIAogCWlm IChtZmlfbG9va3VwX3ZvbHVtZShmZCwgYXZbMV0sICZ0YXJnZXRfaWQpIDwgMCkgeworCQllcnJv ciA9IGVycm5vOwogCQl3YXJuKCJJbnZhbGlkIHZvbHVtZTogJXMiLCBhdlsxXSk7Ci0JCXJldHVy biAoZXJybm8pOworCQlyZXR1cm4gKGVycm9yKTsKIAl9CiAKIAlpZiAobWZpX2xkX2dldF9wcm9w cyhmZCwgdGFyZ2V0X2lkLCAmcHJvcHMpIDwgMCkgeworCQllcnJvciA9IGVycm5vOwogCQl3YXJu KCJGYWlsZWQgdG8gZmV0Y2ggdm9sdW1lIHByb3BlcnRpZXMiKTsKLQkJcmV0dXJuIChlcnJubyk7 CisJCXJldHVybiAoZXJyb3IpOwogCX0KIAogCWlmIChhYyA9PSAyKSB7CkBAIC0yOTgsOCArMzAz LDggQEAKIAkJCQl9CiAJCQkJcHJvcHMuZGlza19jYWNoZV9wb2xpY3kgPSBwb2xpY3k7CiAJCQkJ aWYgKG1maV9sZF9zZXRfcHJvcHMoZmQsICZwcm9wcykgPCAwKSB7CisJCQkJCWVycm9yID0gZXJy bm87CiAJCQkJCXdhcm4oIkZhaWxlZCB0byBzZXQgdm9sdW1lIHByb3BlcnRpZXMiKTsKLQkJCQkJ ZXJyb3IgPSBlcnJubzsKIAkJCQl9CiAJCQl9CiAJCX0gZWxzZSB7CkBAIC0zMTcsNyArMzIyLDcg QEAKIHZvbHVtZV9uYW1lKGludCBhYywgY2hhciAqKmF2KQogewogCXN0cnVjdCBtZmlfbGRfcHJv cHMgcHJvcHM7Ci0JaW50IGZkOworCWludCBlcnJvciwgZmQ7CiAJdWludDhfdCB0YXJnZXRfaWQ7 CiAKIAlpZiAoYWMgIT0gMykgewpAQCAtMzMyLDE4ICszMzcsMjEgQEAKIAogCWZkID0gbWZpX29w ZW4obWZpX3VuaXQpOwogCWlmIChmZCA8IDApIHsKKwkJZXJyb3IgPSBlcnJubzsKIAkJd2Fybigi bWZpX29wZW4iKTsKLQkJcmV0dXJuIChlcnJubyk7CisJCXJldHVybiAoZXJyb3IpOwogCX0KIAog CWlmIChtZmlfbG9va3VwX3ZvbHVtZShmZCwgYXZbMV0sICZ0YXJnZXRfaWQpIDwgMCkgeworCQll cnJvciA9IGVycm5vOwogCQl3YXJuKCJJbnZhbGlkIHZvbHVtZTogJXMiLCBhdlsxXSk7Ci0JCXJl dHVybiAoZXJybm8pOworCQlyZXR1cm4gKGVycm9yKTsKIAl9CiAKIAlpZiAobWZpX2xkX2dldF9w cm9wcyhmZCwgdGFyZ2V0X2lkLCAmcHJvcHMpIDwgMCkgeworCQllcnJvciA9IGVycm5vOwogCQl3 YXJuKCJGYWlsZWQgdG8gZmV0Y2ggdm9sdW1lIHByb3BlcnRpZXMiKTsKLQkJcmV0dXJuIChlcnJu byk7CisJCXJldHVybiAoZXJyb3IpOwogCX0KIAogCXByaW50ZigibWZpJXUgdm9sdW1lICVzIG5h bWUgY2hhbmdlZCBmcm9tIFwiJXNcIiB0byBcIiVzXCJcbiIsIG1maV91bml0LApAQCAtMzUxLDgg KzM1OSw5IEBACiAJYnplcm8ocHJvcHMubmFtZSwgc2l6ZW9mKHByb3BzLm5hbWUpKTsKIAlzdHJj cHkocHJvcHMubmFtZSwgYXZbMl0pOwogCWlmIChtZmlfbGRfc2V0X3Byb3BzKGZkLCAmcHJvcHMp IDwgMCkgeworCQllcnJvciA9IGVycm5vOwogCQl3YXJuKCJGYWlsZWQgdG8gc2V0IHZvbHVtZSBw cm9wZXJ0aWVzIik7Ci0JCXJldHVybiAoZXJybm8pOworCQlyZXR1cm4gKGVycm9yKTsKIAl9CiAK IAljbG9zZShmZCk7CkBAIC0zNjUsNyArMzc0LDcgQEAKIHZvbHVtZV9wcm9ncmVzcyhpbnQgYWMs IGNoYXIgKiphdikKIHsKIAlzdHJ1Y3QgbWZpX2xkX2luZm8gaW5mbzsKLQlpbnQgZmQ7CisJaW50 IGVycm9yLCBmZDsKIAl1aW50OF90IHRhcmdldF9pZDsKIAogCWlmIChhYyAhPSAyKSB7CkBAIC0z NzYsMjAgKzM4NSwyMyBAQAogCiAJZmQgPSBtZmlfb3BlbihtZmlfdW5pdCk7CiAJaWYgKGZkIDwg MCkgeworCQllcnJvciA9IGVycm5vOwogCQl3YXJuKCJtZmlfb3BlbiIpOwotCQlyZXR1cm4gKGVy cm5vKTsKKwkJcmV0dXJuIChlcnJvcik7CiAJfQogCiAJaWYgKG1maV9sb29rdXBfdm9sdW1lKGZk LCBhdlsxXSwgJnRhcmdldF9pZCkgPCAwKSB7CisJCWVycm9yID0gZXJybm87CiAJCXdhcm4oIklu dmFsaWQgdm9sdW1lOiAlcyIsIGF2WzFdKTsKLQkJcmV0dXJuIChlcnJubyk7CisJCXJldHVybiAo ZXJyb3IpOwogCX0KIAogCS8qIEdldCB0aGUgaW5mbyBmb3IgdGhpcyBkcml2ZS4gKi8KIAlpZiAo bWZpX2xkX2dldF9pbmZvKGZkLCB0YXJnZXRfaWQsICZpbmZvLCBOVUxMKSA8IDApIHsKKwkJZXJy b3IgPSBlcnJubzsKIAkJd2FybigiRmFpbGVkIHRvIGZldGNoIGluZm8gZm9yIHZvbHVtZSAlcyIs CiAJCSAgICBtZmlfdm9sdW1lX25hbWUoZmQsIHRhcmdldF9pZCkpOwotCQlyZXR1cm4gKGVycm5v KTsKKwkJcmV0dXJuIChlcnJvcik7CiAJfQogCiAJLyogRGlzcGxheSBhbnkgb2YgdGhlIGFjdGl2 ZSBldmVudHMuICovCkluZGV4OiB1c3Iuc2Jpbi9tZml1dGlsL21maV9kcml2ZS5jCj09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT0KLS0tIHVzci5zYmluL21maXV0aWwvbWZpX2RyaXZlLmMJKHJldmlzaW9uIDIxNDI2MCkKKysr IHVzci5zYmluL21maXV0aWwvbWZpX2RyaXZlLmMJKHdvcmtpbmcgY29weSkKQEAgLTc5LDEwICs3 OSwxMSBAQAogbWZpX2xvb2t1cF9kcml2ZShpbnQgZmQsIGNoYXIgKmRyaXZlLCB1aW50MTZfdCAq ZGV2aWNlX2lkKQogewogCXN0cnVjdCBtZmlfcGRfbGlzdCAqbGlzdDsKLQl1aW50OF90IGVuY2ws IHNsb3Q7CiAJbG9uZyB2YWw7CisJaW50IGVycm9yOwogCXVfaW50IGk7CiAJY2hhciAqY3A7CisJ dWludDhfdCBlbmNsLCBzbG90OwogCiAJLyogTG9vayBmb3IgYSByYXcgZGV2aWNlIGlkIGZpcnN0 LiAqLwogCXZhbCA9IHN0cnRvbChkcml2ZSwgJmNwLCAwKTsKQEAgLTExOCw4ICsxMTksOSBAQAog CQlzbG90ID0gdmFsOwogCiAJCWlmIChtZmlfcGRfZ2V0X2xpc3QoZmQsICZsaXN0LCBOVUxMKSA8 IDApIHsKKwkJCWVycm9yID0gZXJybm87CiAJCQl3YXJuKCJGYWlsZWQgdG8gZmV0Y2ggZHJpdmUg bGlzdCIpOwotCQkJcmV0dXJuIChlcnJubyk7CisJCQlyZXR1cm4gKGVycm9yKTsKIAkJfQogCiAJ CWZvciAoaSA9IDA7IGkgPCBsaXN0LT5jb3VudDsgaSsrKSB7CkBAIC0zMDIsOCArMzA0LDkgQEAK IAogCWZkID0gbWZpX29wZW4obWZpX3VuaXQpOwogCWlmIChmZCA8IDApIHsKKwkJZXJyb3IgPSBl cnJubzsKIAkJd2FybigibWZpX29wZW4iKTsKLQkJcmV0dXJuIChlcnJubyk7CisJCXJldHVybiAo ZXJyb3IpOwogCX0KIAogCWVycm9yID0gbWZpX2xvb2t1cF9kcml2ZShmZCwgZHJpdmUsICZkZXZp Y2VfaWQpOwpAQCAtMzEyLDggKzMxNSw5IEBACiAKIAkvKiBHZXQgdGhlIGluZm8gZm9yIHRoaXMg ZHJpdmUuICovCiAJaWYgKG1maV9wZF9nZXRfaW5mbyhmZCwgZGV2aWNlX2lkLCAmaW5mbywgTlVM TCkgPCAwKSB7CisJCWVycm9yID0gZXJybm87CiAJCXdhcm4oIkZhaWxlZCB0byBmZXRjaCBpbmZv IGZvciBkcml2ZSAldSIsIGRldmljZV9pZCk7Ci0JCXJldHVybiAoZXJybm8pOworCQlyZXR1cm4g KGVycm9yKTsKIAl9CiAKIAkvKiBUcnkgdG8gY2hhbmdlIHRoZSBzdGF0ZS4gKi8KQEAgLTMyNyw5 ICszMzEsMTAgQEAKIAltYm94WzVdID0gbmV3X3N0YXRlID4+IDg7CiAJaWYgKG1maV9kY21kX2Nv bW1hbmQoZmQsIE1GSV9EQ01EX1BEX1NUQVRFX1NFVCwgTlVMTCwgMCwgbWJveCwgNiwKIAkgICAg TlVMTCkgPCAwKSB7CisJCWVycm9yID0gZXJybm87CiAJCXdhcm4oIkZhaWxlZCB0byBzZXQgZHJp dmUgJXUgdG8gJXMiLCBkZXZpY2VfaWQsCiAJCSAgICBtZmlfcGRzdGF0ZShuZXdfc3RhdGUpKTsK LQkJcmV0dXJuIChlcnJubyk7CisJCXJldHVybiAoZXJyb3IpOwogCX0KIAogCWNsb3NlKGZkKTsK QEAgLTM5NSw4ICs0MDAsOSBAQAogCiAJZmQgPSBtZmlfb3BlbihtZmlfdW5pdCk7CiAJaWYgKGZk IDwgMCkgeworCQllcnJvciA9IGVycm5vOwogCQl3YXJuKCJtZmlfb3BlbiIpOwotCQlyZXR1cm4g KGVycm5vKTsKKwkJcmV0dXJuIChlcnJvcik7CiAJfQogCiAJZXJyb3IgPSBtZmlfbG9va3VwX2Ry aXZlKGZkLCBhdlsxXSwgJmRldmljZV9pZCk7CkBAIC00MDUsMTMgKzQxMSwxNCBAQAogCiAJLyog R2V0IHRoZSBpbmZvIGZvciB0aGlzIGRyaXZlLiAqLwogCWlmIChtZmlfcGRfZ2V0X2luZm8oZmQs IGRldmljZV9pZCwgJmluZm8sIE5VTEwpIDwgMCkgeworCQllcnJvciA9IGVycm5vOwogCQl3YXJu KCJGYWlsZWQgdG8gZmV0Y2ggaW5mbyBmb3IgZHJpdmUgJXUiLCBkZXZpY2VfaWQpOwotCQlyZXR1 cm4gKGVycm5vKTsKKwkJcmV0dXJuIChlcnJvcik7CiAJfQogCiAJLyogQ2hlY2sgdGhlIHN0YXRl LCBtdXN0IGJlIFJFQlVJTEQuICovCiAJaWYgKGluZm8uZndfc3RhdGUgIT0gTUZJX1BEX1NUQVRF X1JFQlVJTEQpIHsKLQkJd2FybigiRHJpdmUgJWQgaXMgbm90IGluIHRoZSBSRUJVSUxEIHN0YXRl IiwgZGV2aWNlX2lkKTsKKwkJd2FybngoIkRyaXZlICVkIGlzIG5vdCBpbiB0aGUgUkVCVUlMRCBz dGF0ZSIsIGRldmljZV9pZCk7CiAJCXJldHVybiAoRUlOVkFMKTsKIAl9CiAKQEAgLTQxOSw4ICs0 MjYsOSBAQAogCW1ib3hfc3RvcmVfcGRyZWYoJm1ib3hbMF0sICZpbmZvLnJlZik7CiAJaWYgKG1m aV9kY21kX2NvbW1hbmQoZmQsIE1GSV9EQ01EX1BEX1JFQlVJTERfU1RBUlQsIE5VTEwsIDAsIG1i b3gsIDQsCiAJICAgIE5VTEwpIDwgMCkgeworCQllcnJvciA9IGVycm5vOwogCQl3YXJuKCJGYWls ZWQgdG8gc3RhcnQgcmVidWlsZCBvbiBkcml2ZSAldSIsIGRldmljZV9pZCk7Ci0JCXJldHVybiAo ZXJybm8pOworCQlyZXR1cm4gKGVycm9yKTsKIAl9CiAJY2xvc2UoZmQpOwogCkBAIC00NDQsOCAr NDUyLDkgQEAKIAogCWZkID0gbWZpX29wZW4obWZpX3VuaXQpOwogCWlmIChmZCA8IDApIHsKKwkJ ZXJyb3IgPSBlcnJubzsKIAkJd2FybigibWZpX29wZW4iKTsKLQkJcmV0dXJuIChlcnJubyk7CisJ CXJldHVybiAoZXJyb3IpOwogCX0KIAogCWVycm9yID0gbWZpX2xvb2t1cF9kcml2ZShmZCwgYXZb MV0sICZkZXZpY2VfaWQpOwpAQCAtNDU0LDggKzQ2Myw5IEBACiAKIAkvKiBHZXQgdGhlIGluZm8g Zm9yIHRoaXMgZHJpdmUuICovCiAJaWYgKG1maV9wZF9nZXRfaW5mbyhmZCwgZGV2aWNlX2lkLCAm aW5mbywgTlVMTCkgPCAwKSB7CisJCWVycm9yID0gZXJybm87CiAJCXdhcm4oIkZhaWxlZCB0byBm ZXRjaCBpbmZvIGZvciBkcml2ZSAldSIsIGRldmljZV9pZCk7Ci0JCXJldHVybiAoZXJybm8pOwor CQlyZXR1cm4gKGVycm9yKTsKIAl9CiAKIAkvKiBDaGVjayB0aGUgc3RhdGUsIG11c3QgYmUgUkVC VUlMRC4gKi8KQEAgLTQ2OCw4ICs0NzgsOSBAQAogCW1ib3hfc3RvcmVfcGRyZWYoJm1ib3hbMF0s ICZpbmZvLnJlZik7CiAJaWYgKG1maV9kY21kX2NvbW1hbmQoZmQsIE1GSV9EQ01EX1BEX1JFQlVJ TERfQUJPUlQsIE5VTEwsIDAsIG1ib3gsIDQsCiAJICAgIE5VTEwpIDwgMCkgeworCQllcnJvciA9 IGVycm5vOwogCQl3YXJuKCJGYWlsZWQgdG8gYWJvcnQgcmVidWlsZCBvbiBkcml2ZSAldSIsIGRl dmljZV9pZCk7Ci0JCXJldHVybiAoZXJybm8pOworCQlyZXR1cm4gKGVycm9yKTsKIAl9CiAJY2xv c2UoZmQpOwogCkBAIC00OTIsOCArNTAzLDkgQEAKIAogCWZkID0gbWZpX29wZW4obWZpX3VuaXQp OwogCWlmIChmZCA8IDApIHsKKwkJZXJyb3IgPSBlcnJubzsKIAkJd2FybigibWZpX29wZW4iKTsK LQkJcmV0dXJuIChlcnJubyk7CisJCXJldHVybiAoZXJyb3IpOwogCX0KIAogCWVycm9yID0gbWZp X2xvb2t1cF9kcml2ZShmZCwgYXZbMV0sICZkZXZpY2VfaWQpOwpAQCAtNTAyLDggKzUxNCw5IEBA CiAKIAkvKiBHZXQgdGhlIGluZm8gZm9yIHRoaXMgZHJpdmUuICovCiAJaWYgKG1maV9wZF9nZXRf aW5mbyhmZCwgZGV2aWNlX2lkLCAmaW5mbywgTlVMTCkgPCAwKSB7CisJCWVycm9yID0gZXJybm87 CiAJCXdhcm4oIkZhaWxlZCB0byBmZXRjaCBpbmZvIGZvciBkcml2ZSAldSIsIGRldmljZV9pZCk7 Ci0JCXJldHVybiAoZXJybm8pOworCQlyZXR1cm4gKGVycm9yKTsKIAl9CiAJY2xvc2UoZmQpOwog CkBAIC01NTEsOCArNTY0LDkgQEAKIAogCWZkID0gbWZpX29wZW4obWZpX3VuaXQpOwogCWlmIChm ZCA8IDApIHsKKwkJZXJyb3IgPSBlcnJubzsKIAkJd2FybigibWZpX29wZW4iKTsKLQkJcmV0dXJu IChlcnJubyk7CisJCXJldHVybiAoZXJyb3IpOwogCX0KIAogCWVycm9yID0gbWZpX2xvb2t1cF9k cml2ZShmZCwgYXZbMV0sICZkZXZpY2VfaWQpOwpAQCAtNTYxLDE2ICs1NzUsMTggQEAKIAogCS8q IEdldCB0aGUgaW5mbyBmb3IgdGhpcyBkcml2ZS4gKi8KIAlpZiAobWZpX3BkX2dldF9pbmZvKGZk LCBkZXZpY2VfaWQsICZpbmZvLCBOVUxMKSA8IDApIHsKKwkJZXJyb3IgPSBlcnJubzsKIAkJd2Fy bigiRmFpbGVkIHRvIGZldGNoIGluZm8gZm9yIGRyaXZlICV1IiwgZGV2aWNlX2lkKTsKLQkJcmV0 dXJuIChlcnJubyk7CisJCXJldHVybiAoZXJyb3IpOwogCX0KIAogCW1ib3hfc3RvcmVfcGRyZWYo Jm1ib3hbMF0sICZpbmZvLnJlZik7CiAJaWYgKG1maV9kY21kX2NvbW1hbmQoZmQsIG9wY29kZSwg TlVMTCwgMCwgbWJveCwgNCwgTlVMTCkgPCAwKSB7CisJCWVycm9yID0gZXJybm87CiAJCXdhcm4o IkZhaWxlZCB0byAlcyBjbGVhciBvbiBkcml2ZSAldSIsCiAJCSAgICBvcGNvZGUgPT0gTUZJX0RD TURfUERfQ0xFQVJfU1RBUlQgPyAic3RhcnQiIDogInN0b3AiLAogCQkgICAgZGV2aWNlX2lkKTsK LQkJcmV0dXJuIChlcnJubyk7CisJCXJldHVybiAoZXJyb3IpOwogCX0KIAogCWNsb3NlKGZkKTsK QEAgLTYwNCw4ICs2MjAsOSBAQAogCiAJZmQgPSBtZmlfb3BlbihtZmlfdW5pdCk7CiAJaWYgKGZk IDwgMCkgeworCQllcnJvciA9IGVycm5vOwogCQl3YXJuKCJtZmlfb3BlbiIpOwotCQlyZXR1cm4g KGVycm5vKTsKKwkJcmV0dXJuIChlcnJvcik7CiAJfQogCiAJZXJyb3IgPSBtZmlfbG9va3VwX2Ry aXZlKGZkLCBhdlsxXSwgJmRldmljZV9pZCk7CkBAIC02MTcsMTAgKzYzNCwxMSBAQAogCW1ib3hb Ml0gPSAwOwogCW1ib3hbM10gPSAwOwogCWlmIChtZmlfZGNtZF9jb21tYW5kKGZkLCBvcGNvZGUs IE5VTEwsIDAsIG1ib3gsIDQsIE5VTEwpIDwgMCkgeworCQllcnJvciA9IGVycm5vOwogCQl3YXJu KCJGYWlsZWQgdG8gJXMgbG9jYXRlIG9uIGRyaXZlICV1IiwKIAkJICAgIG9wY29kZSA9PSBNRklf RENNRF9QRF9MT0NBVEVfU1RBUlQgPyAic3RhcnQiIDogInN0b3AiLAogCQkgICAgZGV2aWNlX2lk KTsKLQkJcmV0dXJuIChlcnJubyk7CisJCXJldHVybiAoZXJyb3IpOwogCX0KIAljbG9zZShmZCk7 CiAKSW5kZXg6IHVzci5zYmluL21maXV0aWwvbWZpX2ZsYXNoLmMKPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gdXNy LnNiaW4vbWZpdXRpbC9tZmlfZmxhc2guYwkocmV2aXNpb24gMjE0MjYwKQorKysgdXNyLnNiaW4v bWZpdXRpbC9tZmlfZmxhc2guYwkod29ya2luZyBjb3B5KQpAQCAtNzIsMTYgKzcyLDE4IEBACiAJ ICAgIGZ3X3RpbWVfd2lkdGgsIGNvbXAtPmJ1aWxkX3RpbWUpOwogfQogCi1zdGF0aWMgdm9pZAor c3RhdGljIGludAogZGlzcGxheV9wZW5kaW5nX2Zpcm13YXJlKGludCBmZCkKIHsKIAlzdHJ1Y3Qg bWZpX2N0cmxfaW5mbyBpbmZvOwogCXN0cnVjdCBtZmlfaW5mb19jb21wb25lbnQgaGVhZGVyOwor CWludCBlcnJvcjsKIAl1X2ludCBpOwogCiAJaWYgKG1maV9jdHJsX2dldF9pbmZvKGZkLCAmaW5m bywgTlVMTCkgPCAwKSB7CisJCWVycm9yID0gZXJybm87CiAJCXdhcm4oIkZhaWxlZCB0byBnZXQg Y29udHJvbGxlciBpbmZvIik7Ci0JCXJldHVybjsKKwkJcmV0dXJuIChlcnJvcik7CiAJfQogCiAJ cHJpbnRmKCJtZmklZCBQZW5kaW5nIEZpcm13YXJlIEltYWdlczpcbiIsIG1maV91bml0KTsKQEAg LTk3LDYgKzk5LDggQEAKIAlkaXNwbGF5X2Zpcm13YXJlKCZoZWFkZXIpOwogCWZvciAoaSA9IDA7 IGkgPCBpbmZvLnBlbmRpbmdfaW1hZ2VfY29tcG9uZW50X2NvdW50OyBpKyspCiAJCWRpc3BsYXlf ZmlybXdhcmUoJmluZm8ucGVuZGluZ19pbWFnZV9jb21wb25lbnRbaV0pOworCisJcmV0dXJuICgw KTsKIH0KIAogc3RhdGljIHZvaWQKQEAgLTExNyw3ICsxMjEsNyBAQAogCXNpemVfdCBucmVhZDsK IAljaGFyICpidWY7CiAJc3RydWN0IHN0YXQgc2I7Ci0JaW50IGZkLCBmbGFzaDsKKwlpbnQgZXJy b3IsIGZkLCBmbGFzaDsKIAl1aW50OF90IG1ib3hbNF0sIHN0YXR1czsKIAogCWlmIChhYyAhPSAy KSB7CkBAIC0xMjcsMTMgKzEzMSwxNSBAQAogCiAJZmxhc2ggPSBvcGVuKGF2WzFdLCBPX1JET05M WSk7CiAJaWYgKGZsYXNoIDwgMCkgeworCQllcnJvciA9IGVycm5vOwogCQl3YXJuKCJmbGFzaDog RmFpbGVkIHRvIG9wZW4gJXMiLCBhdlsxXSk7Ci0JCXJldHVybiAoZXJybm8pOworCQlyZXR1cm4g KGVycm9yKTsKIAl9CiAKIAlpZiAoZnN0YXQoZmxhc2gsICZzYikgPCAwKSB7CisJCWVycm9yID0g ZXJybm87CiAJCXdhcm4oImZzdGF0KCVzKSIsIGF2WzFdKTsKLQkJcmV0dXJuIChlcnJubyk7CisJ CXJldHVybiAoZXJyb3IpOwogCX0KIAlpZiAoc2Iuc3Rfc2l6ZSAlIDEwMjQgIT0gMCB8fCBzYi5z dF9zaXplID4gMHg3ZmZmZmZmZikgewogCQl3YXJueCgiSW52YWxpZCBmbGFzaCBmaWxlIHNpemUi KTsKQEAgLTE0Miw4ICsxNDgsOSBAQAogCiAJZmQgPSBtZmlfb3BlbihtZmlfdW5pdCk7CiAJaWYg KGZkIDwgMCkgeworCQllcnJvciA9IGVycm5vOwogCQl3YXJuKCJtZmlfb3BlbiIpOwotCQlyZXR1 cm4gKGVycm5vKTsKKwkJcmV0dXJuIChlcnJvcik7CiAJfQogCiAJLyogRmlyc3QsIGFzayB0aGUg ZmlybXdhcmUgdG8gYWxsb2NhdGUgc3BhY2UgZm9yIHRoZSBmbGFzaCBmaWxlLiAqLwpAQCAtMTkw LDEwICsxOTcsMTAgQEAKIAkJcmV0dXJuIChFTlhJTyk7CiAJfQogCXByaW50ZigiZmluaXNoZWRc biIpOwotCWRpc3BsYXlfcGVuZGluZ19maXJtd2FyZShmZCk7CisJZXJyb3IgPSBkaXNwbGF5X3Bl bmRpbmdfZmlybXdhcmUoZmQpOwogCiAJY2xvc2UoZmQpOwogCi0JcmV0dXJuICgwKTsKKwlyZXR1 cm4gKGVycm9yKTsKIH0KIE1GSV9DT01NQU5EKHRvcCwgZmxhc2gsIGZsYXNoX2FkYXB0ZXIpOwpJ bmRleDogdXNyLnNiaW4vbWZpdXRpbC9tZmlfZXZ0LmMKPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gdXNyLnNiaW4v bWZpdXRpbC9tZmlfZXZ0LmMJKHJldmlzaW9uIDIxNDI2MCkKKysrIHVzci5zYmluL21maXV0aWwv bWZpX2V2dC5jCSh3b3JraW5nIGNvcHkpCkBAIC0zMiw3ICszMiw2IEBACiAjaW5jbHVkZSA8c3lz L3R5cGVzLmg+CiAjaW5jbHVkZSA8c3lzL2Vycm5vLmg+CiAjaW5jbHVkZSA8ZXJyLmg+Ci0vLyNp bmNsdWRlIDxsaWJ1dGlsLmg+CiAjaW5jbHVkZSA8c3RkaW8uaD4KICNpbmNsdWRlIDxzdGRsaWIu aD4KICNpbmNsdWRlIDxzdHJpbmdzLmg+CkBAIC02Nyw3ICs2Niw3IEBACiBzaG93X2xvZ3N0YXRl KGludCBhYywgY2hhciAqKmF2KQogewogCXN0cnVjdCBtZmlfZXZ0X2xvZ19zdGF0ZSBpbmZvOwot CWludCBmZDsKKwlpbnQgZXJyb3IsIGZkOwogCiAJaWYgKGFjICE9IDEpIHsKIAkJd2FybngoInNo b3cgbG9nc3RhdGU6IGV4dHJhIGFyZ3VtZW50cyIpOwpAQCAtNzYsMTMgKzc1LDE1IEBACiAKIAlm ZCA9IG1maV9vcGVuKG1maV91bml0KTsKIAlpZiAoZmQgPCAwKSB7CisJCWVycm9yID0gZXJybm87 CiAJCXdhcm4oIm1maV9vcGVuIik7Ci0JCXJldHVybiAoZXJybm8pOworCQlyZXR1cm4gKGVycm9y KTsKIAl9CiAKIAlpZiAobWZpX2V2ZW50X2dldF9pbmZvKGZkLCAmaW5mbywgTlVMTCkgPCAwKSB7 CisJCWVycm9yID0gZXJybm87CiAJCXdhcm4oIkZhaWxlZCB0byBnZXQgZXZlbnQgbG9nIGluZm8i KTsKLQkJcmV0dXJuIChlcnJubyk7CisJCXJldHVybiAoZXJyb3IpOwogCX0KIAogCXByaW50Zigi bWZpJWQgRXZlbnQgTG9nIFNlcXVlbmNlIE51bWJlcnM6XG4iLCBtZmlfdW5pdCk7CkBAIC01MzYs MTggKzUzNywyMCBAQAogCXNzaXplX3Qgc2l6ZTsKIAl1aW50MzJfdCBzZXEsIHN0YXJ0LCBzdG9w OwogCXVpbnQ4X3Qgc3RhdHVzOwotCWludCBjaCwgZmQsIG51bV9ldmVudHMsIHZlcmJvc2U7CisJ aW50IGNoLCBlcnJvciwgZmQsIG51bV9ldmVudHMsIHZlcmJvc2U7CiAJdV9pbnQgaTsKIAogCWZk ID0gbWZpX29wZW4obWZpX3VuaXQpOwogCWlmIChmZCA8IDApIHsKKwkJZXJyb3IgPSBlcnJubzsK IAkJd2FybigibWZpX29wZW4iKTsKLQkJcmV0dXJuIChlcnJubyk7CisJCXJldHVybiAoZXJyb3Ip OwogCX0KIAogCWlmIChtZmlfZXZlbnRfZ2V0X2luZm8oZmQsICZpbmZvLCBOVUxMKSA8IDApIHsK KwkJZXJyb3IgPSBlcnJubzsKIAkJd2FybigiRmFpbGVkIHRvIGdldCBldmVudCBsb2cgaW5mbyIp OwotCQlyZXR1cm4gKGVycm5vKTsKKwkJcmV0dXJuIChlcnJvcik7CiAJfQogCiAJLyogRGVmYXVs dCBzZXR0aW5ncy4gKi8KQEAgLTU2NSwxNCArNTY4LDE2IEBACiAJCXN3aXRjaCAoY2gpIHsKIAkJ Y2FzZSAnYyc6CiAJCQlpZiAocGFyc2VfY2xhc3Mob3B0YXJnLCAmZmlsdGVyLm1lbWJlcnMuY2xh c3MpIDwgMCkgeworCQkJCWVycm9yID0gZXJybm87CiAJCQkJd2FybigiRXJyb3IgcGFyc2luZyBl dmVudCBjbGFzcyIpOwotCQkJCXJldHVybiAoZXJybm8pOworCQkJCXJldHVybiAoZXJyb3IpOwog CQkJfQogCQkJYnJlYWs7CiAJCWNhc2UgJ2wnOgogCQkJaWYgKHBhcnNlX2xvY2FsZShvcHRhcmcs ICZmaWx0ZXIubWVtYmVycy5sb2NhbGUpIDwgMCkgeworCQkJCWVycm9yID0gZXJybm87CiAJCQkJ d2FybigiRXJyb3IgcGFyc2luZyBldmVudCBsb2NhbGUiKTsKLQkJCQlyZXR1cm4gKGVycm5vKTsK KwkJCQlyZXR1cm4gKGVycm9yKTsKIAkJCX0KIAkJCWJyZWFrOwogCQljYXNlICduJzoKQEAgLTYw OCwyMCArNjEzLDIzIEBACiAJCXJldHVybiAoRUlOVkFMKTsKIAl9CiAJaWYgKGFjID4gMCAmJiBw YXJzZV9zZXEoJmluZm8sIGF2WzBdLCAmc3RhcnQpIDwgMCkgeworCQllcnJvciA9IGVycm5vOwog CQl3YXJuKCJFcnJvciBwYXJzaW5nIHN0YXJ0aW5nIHNlcXVlbmNlIG51bWJlciIpOwotCQlyZXR1 cm4gKGVycm5vKTsKKwkJcmV0dXJuIChlcnJvcik7CiAJfQogCWlmIChhYyA+IDEgJiYgcGFyc2Vf c2VxKCZpbmZvLCBhdlsxXSwgJnN0b3ApIDwgMCkgeworCQllcnJvciA9IGVycm5vOwogCQl3YXJu KCJFcnJvciBwYXJzaW5nIGVuZGluZyBzZXF1ZW5jZSBudW1iZXIiKTsKLQkJcmV0dXJuIChlcnJu byk7CisJCXJldHVybiAoZXJyb3IpOwogCX0KIAogCWxpc3QgPSBtYWxsb2Moc2l6ZSk7CiAJZm9y IChzZXEgPSBzdGFydDs7KSB7CiAJCWlmIChtZmlfZ2V0X2V2ZW50cyhmZCwgbGlzdCwgbnVtX2V2 ZW50cywgZmlsdGVyLCBzZXEsCiAJCSAgICAmc3RhdHVzKSA8IDApIHsKKwkJCWVycm9yID0gZXJy bm87CiAJCQl3YXJuKCJGYWlsZWQgdG8gZmV0Y2ggZXZlbnRzIik7Ci0JCQlyZXR1cm4gKGVycm5v KTsKKwkJCXJldHVybiAoZXJyb3IpOwogCQl9CiAJCWlmIChzdGF0dXMgPT0gTUZJX1NUQVRfTk9U X0ZPVU5EKSB7CiAJCQlpZiAoc2VxID09IHN0YXJ0KQpJbmRleDogdXNyLnNiaW4vbWZpdXRpbC9t Zmlfc2hvdy5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT0KLS0tIHVzci5zYmluL21maXV0aWwvbWZpX3Nob3cuYwkocmV2 aXNpb24gMjE0MjYwKQorKysgdXNyLnNiaW4vbWZpdXRpbC9tZmlfc2hvdy5jCSh3b3JraW5nIGNv cHkpCkBAIC01NCw3ICs1NCw3IEBACiB7CiAJc3RydWN0IG1maV9jdHJsX2luZm8gaW5mbzsKIAlj aGFyIHN0cmlwZVs1XTsKLQlpbnQgZmQsIGNvbW1hOworCWludCBlcnJvciwgZmQsIGNvbW1hOwog CiAJaWYgKGFjICE9IDEpIHsKIAkJd2FybngoInNob3cgYWRhcHRlcjogZXh0cmEgYXJndW1lbnRz Iik7CkBAIC02MywxMyArNjMsMTUgQEAKIAogCWZkID0gbWZpX29wZW4obWZpX3VuaXQpOwogCWlm IChmZCA8IDApIHsKKwkJZXJyb3IgPSBlcnJubzsKIAkJd2FybigibWZpX29wZW4iKTsKLQkJcmV0 dXJuIChlcnJubyk7CisJCXJldHVybiAoZXJyb3IpOwogCX0KIAogCWlmIChtZmlfY3RybF9nZXRf aW5mbyhmZCwgJmluZm8sIE5VTEwpIDwgMCkgeworCQllcnJvciA9IGVycm5vOwogCQl3YXJuKCJG YWlsZWQgdG8gZ2V0IGNvbnRyb2xsZXIgaW5mbyIpOwotCQlyZXR1cm4gKGVycm5vKTsKKwkJcmV0 dXJuIChlcnJvcik7CiAJfQogCXByaW50ZigibWZpJWQgQWRhcHRlcjpcbiIsIG1maV91bml0KTsK IAlwcmludGYoIiAgICBQcm9kdWN0IE5hbWU6ICUuODBzXG4iLCBpbmZvLnByb2R1Y3RfbmFtZSk7 CkBAIC0xMzcsNyArMTM5LDcgQEAKIAlzdHJ1Y3QgbWZpX2JidV9jYXBhY2l0eV9pbmZvIGNhcDsK IAlzdHJ1Y3QgbWZpX2JidV9kZXNpZ25faW5mbyBkZXNpZ247CiAJdWludDhfdCBzdGF0dXM7Ci0J aW50IGZkOworCWludCBlcnJvciwgZmQ7CiAKIAlpZiAoYWMgIT0gMSkgewogCQl3YXJueCgic2hv dyBiYXR0ZXJ5OiBleHRyYSBhcmd1bWVudHMiKTsKQEAgLTE0Niw4ICsxNDgsOSBAQAogCiAJZmQg PSBtZmlfb3BlbihtZmlfdW5pdCk7CiAJaWYgKGZkIDwgMCkgeworCQllcnJvciA9IGVycm5vOwog CQl3YXJuKCJtZmlfb3BlbiIpOwotCQlyZXR1cm4gKGVycm5vKTsKKwkJcmV0dXJuIChlcnJvcik7 CiAJfQogCiAJaWYgKG1maV9kY21kX2NvbW1hbmQoZmQsIE1GSV9EQ01EX0JCVV9HRVRfQ0FQQUNJ VFlfSU5GTywgJmNhcCwKQEAgLTE1NiwxNCArMTU5LDE2IEBACiAJCQlwcmludGYoIm1maSVkOiBO byBiYXR0ZXJ5IHByZXNlbnRcbiIsIG1maV91bml0KTsKIAkJCXJldHVybiAoMCk7CiAJCX0KKwkJ ZXJyb3IgPSBlcnJubzsKIAkJd2FybigiRmFpbGVkIHRvIGdldCBjYXBhY2l0eSBpbmZvIik7Ci0J CXJldHVybiAoZXJybm8pOworCQlyZXR1cm4gKGVycm9yKTsKIAl9CiAKIAlpZiAobWZpX2RjbWRf Y29tbWFuZChmZCwgTUZJX0RDTURfQkJVX0dFVF9ERVNJR05fSU5GTywgJmRlc2lnbiwKIAkgICAg c2l6ZW9mKGRlc2lnbiksIE5VTEwsIDAsIE5VTEwpIDwgMCkgeworCQllcnJvciA9IGVycm5vOwog CQl3YXJuKCJGYWlsZWQgdG8gZ2V0IGRlc2lnbiBpbmZvIik7Ci0JCXJldHVybiAoZXJybm8pOwor CQlyZXR1cm4gKGVycm9yKTsKIAl9CiAKIAlwcmludGYoIm1maSVkOiBCYXR0ZXJ5IFN0YXRlOlxu IiwgbWZpX3VuaXQpOwpAQCAtMjQyLDcgKzI0Nyw3IEBACiAJc3RydWN0IG1maV9wZF9pbmZvIHBp bmZvOwogCXVpbnQxNl90IGRldmljZV9pZDsKIAljaGFyICpwOwotCWludCBmZCwgaSwgajsKKwlp bnQgZXJyb3IsIGZkLCBpLCBqOwogCiAJaWYgKGFjICE9IDEpIHsKIAkJd2FybngoInNob3cgY29u ZmlnOiBleHRyYSBhcmd1bWVudHMiKTsKQEAgLTI1MSwxNCArMjU2LDE2IEBACiAKIAlmZCA9IG1m aV9vcGVuKG1maV91bml0KTsKIAlpZiAoZmQgPCAwKSB7CisJCWVycm9yID0gZXJybm87CiAJCXdh cm4oIm1maV9vcGVuIik7Ci0JCXJldHVybiAoZXJybm8pOworCQlyZXR1cm4gKGVycm9yKTsKIAl9 CiAKIAkvKiBHZXQgdGhlIGNvbmZpZyBmcm9tIHRoZSBjb250cm9sbGVyLiAqLwogCWlmIChtZmlf Y29uZmlnX3JlYWQoZmQsICZjb25maWcpIDwgMCkgeworCQllcnJvciA9IGVycm5vOwogCQl3YXJu KCJGYWlsZWQgdG8gZ2V0IGNvbmZpZyIpOwotCQlyZXR1cm4gKGVycm5vKTsKKwkJcmV0dXJuIChl cnJvcik7CiAJfQogCiAJLyogRHVtcCBvdXQgdGhlIGNvbmZpZ3VyYXRpb24uICovCkBAIC0zMzcs OCArMzQ0LDggQEAKIHsKIAlzdHJ1Y3QgbWZpX2xkX2xpc3QgbGlzdDsKIAlzdHJ1Y3QgbWZpX2xk X2luZm8gaW5mbzsKKwlpbnQgZXJyb3IsIGZkOwogCXVfaW50IGksIGxlbiwgc3RhdGVfbGVuOwot CWludCBmZDsKIAogCWlmIChhYyAhPSAxKSB7CiAJCXdhcm54KCJzaG93IHZvbHVtZXM6IGV4dHJh IGFyZ3VtZW50cyIpOwpAQCAtMzQ3LDE0ICszNTQsMTYgQEAKIAogCWZkID0gbWZpX29wZW4obWZp X3VuaXQpOwogCWlmIChmZCA8IDApIHsKKwkJZXJyb3IgPSBlcnJubzsKIAkJd2FybigibWZpX29w ZW4iKTsKLQkJcmV0dXJuIChlcnJubyk7CisJCXJldHVybiAoZXJyb3IpOwogCX0KIAogCS8qIEdl dCB0aGUgbG9naWNhbCBkcml2ZSBsaXN0IGZyb20gdGhlIGNvbnRyb2xsZXIuICovCiAJaWYgKG1m aV9sZF9nZXRfbGlzdChmZCwgJmxpc3QsIE5VTEwpIDwgMCkgeworCQllcnJvciA9IGVycm5vOwog CQl3YXJuKCJGYWlsZWQgdG8gZ2V0IHZvbHVtZSBsaXN0Iik7Ci0JCXJldHVybiAoZXJybm8pOwor CQlyZXR1cm4gKGVycm9yKTsKIAl9CiAKIAkvKiBMaXN0IHRoZSB2b2x1bWVzLiAqLwpAQCAtMzc2 LDkgKzM4NSwxMCBAQAogCWZvciAoaSA9IDA7IGkgPCBsaXN0LmxkX2NvdW50OyBpKyspIHsKIAkJ aWYgKG1maV9sZF9nZXRfaW5mbyhmZCwgbGlzdC5sZF9saXN0W2ldLmxkLnYudGFyZ2V0X2lkLCAm aW5mbywKIAkJICAgIE5VTEwpIDwgMCkgeworCQkJZXJyb3IgPSBlcnJubzsKIAkJCXdhcm4oIkZh aWxlZCB0byBnZXQgaW5mbyBmb3Igdm9sdW1lICVkIiwKIAkJCSAgICBsaXN0LmxkX2xpc3RbaV0u bGQudi50YXJnZXRfaWQpOwotCQkJcmV0dXJuIChlcnJubyk7CisJCQlyZXR1cm4gKGVycm9yKTsK IAkJfQogCQlwcmludGYoIiU2cyAiLAogCQkgICAgbWZpX3ZvbHVtZV9uYW1lKGZkLCBsaXN0Lmxk X2xpc3RbaV0ubGQudi50YXJnZXRfaWQpKTsKQEAgLTQxNiw3ICs0MjYsNyBAQAogCXN0cnVjdCBt ZmlfcGRfbGlzdCAqbGlzdDsKIAlzdHJ1Y3QgbWZpX3BkX2luZm8gaW5mbzsKIAl1X2ludCBpLCBs ZW4sIHN0YXRlX2xlbjsKLQlpbnQgZmQ7CisJaW50IGVycm9yLCBmZDsKIAogCWlmIChhYyAhPSAx KSB7CiAJCXdhcm54KCJzaG93IGRyaXZlczogZXh0cmEgYXJndW1lbnRzIik7CkBAIC00MjUsMTMg KzQzNSwxNSBAQAogCiAJZmQgPSBtZmlfb3BlbihtZmlfdW5pdCk7CiAJaWYgKGZkIDwgMCkgewor CQllcnJvciA9IGVycm5vOwogCQl3YXJuKCJtZmlfb3BlbiIpOwotCQlyZXR1cm4gKGVycm5vKTsK KwkJcmV0dXJuIChlcnJvcik7CiAJfQogCiAJaWYgKG1maV9wZF9nZXRfbGlzdChmZCwgJmxpc3Qs IE5VTEwpIDwgMCkgeworCQllcnJvciA9IGVycm5vOwogCQl3YXJuKCJGYWlsZWQgdG8gZ2V0IGRy aXZlIGxpc3QiKTsKLQkJcmV0dXJuIChlcnJubyk7CisJCXJldHVybiAoZXJyb3IpOwogCX0KIAog CS8qIFdhbGsgdGhlIGxpc3Qgb2YgZHJpdmVzIHRvIGRldGVybWluZSB3aWR0aCBvZiBzdGF0ZSBj b2x1bW4uICovCkBAIC00NDIsOSArNDU0LDEwIEBACiAKIAkJaWYgKG1maV9wZF9nZXRfaW5mbyhm ZCwgbGlzdC0+YWRkcltpXS5kZXZpY2VfaWQsICZpbmZvLAogCQkgICAgTlVMTCkgPCAwKSB7CisJ CQllcnJvciA9IGVycm5vOwogCQkJd2FybigiRmFpbGVkIHRvIGZldGNoIGluZm8gZm9yIGRyaXZl ICV1IiwKIAkJCSAgICBsaXN0LT5hZGRyW2ldLmRldmljZV9pZCk7Ci0JCQlyZXR1cm4gKGVycm5v KTsKKwkJCXJldHVybiAoZXJyb3IpOwogCQl9CiAJCWxlbiA9IHN0cmxlbihtZmlfcGRzdGF0ZShp bmZvLmZ3X3N0YXRlKSk7CiAJCWlmIChsZW4gPiBzdGF0ZV9sZW4pCkBAIC00NjIsOSArNDc1LDEw IEBACiAJCS8qIEZldGNoIGRldGFpbHMgZm9yIHRoaXMgZHJpdmUuICovCiAJCWlmIChtZmlfcGRf Z2V0X2luZm8oZmQsIGxpc3QtPmFkZHJbaV0uZGV2aWNlX2lkLCAmaW5mbywKIAkJICAgIE5VTEwp IDwgMCkgeworCQkJZXJyb3IgPSBlcnJubzsKIAkJCXdhcm4oIkZhaWxlZCB0byBmZXRjaCBpbmZv IGZvciBkcml2ZSAldSIsCiAJCQkgICAgbGlzdC0+YWRkcltpXS5kZXZpY2VfaWQpOwotCQkJcmV0 dXJuIChlcnJubyk7CisJCQlyZXR1cm4gKGVycm9yKTsKIAkJfQogCiAJCXByaW50X3BkKCZpbmZv LCBzdGF0ZV9sZW4sIDEpOwpAQCAtNTExLDcgKzUyNSw3IEBACiB7CiAJc3RydWN0IG1maV9jdHJs X2luZm8gaW5mbzsKIAlzdHJ1Y3QgbWZpX2luZm9fY29tcG9uZW50IGhlYWRlcjsKLQlpbnQgZmQ7 CisJaW50IGVycm9yLCBmZDsKIAl1X2ludCBpOwogCiAJaWYgKGFjICE9IDEpIHsKQEAgLTUyMSwx MyArNTM1LDE1IEBACiAKIAlmZCA9IG1maV9vcGVuKG1maV91bml0KTsKIAlpZiAoZmQgPCAwKSB7 CisJCWVycm9yID0gZXJybm87CiAJCXdhcm4oIm1maV9vcGVuIik7Ci0JCXJldHVybiAoZXJybm8p OworCQlyZXR1cm4gKGVycm9yKTsKIAl9CiAKIAlpZiAobWZpX2N0cmxfZ2V0X2luZm8oZmQsICZp bmZvLCBOVUxMKSA8IDApIHsKKwkJZXJyb3IgPSBlcnJubzsKIAkJd2FybigiRmFpbGVkIHRvIGdl dCBjb250cm9sbGVyIGluZm8iKTsKLQkJcmV0dXJuIChlcnJubyk7CisJCXJldHVybiAoZXJyb3Ip OwogCX0KIAogCWlmIChpbmZvLnBhY2thZ2VfdmVyc2lvblswXSAhPSAnXDAnKQpJbmRleDogdXNy LnNiaW4vbWZpdXRpbC9tZmlfcGF0cm9sLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gdXNyLnNiaW4vbWZpdXRp bC9tZmlfcGF0cm9sLmMJKHJldmlzaW9uIDIxNDI2MCkKKysrIHVzci5zYmluL21maXV0aWwvbWZp X3BhdHJvbC5jCSh3b3JraW5nIGNvcHkpCkBAIC02MiwxMSArNjIsMTMgQEAKIHN0YXRpYyBpbnQK IHBhdHJvbF9nZXRfcHJvcHMoaW50IGZkLCBzdHJ1Y3QgbWZpX3ByX3Byb3BlcnRpZXMgKnByb3Ap CiB7CisJaW50IGVycm9yOwogCiAJaWYgKG1maV9kY21kX2NvbW1hbmQoZmQsIE1GSV9EQ01EX1BS X0dFVF9QUk9QRVJUSUVTLCBwcm9wLAogCSAgICBzaXplb2YoKnByb3ApLCBOVUxMLCAwLCBOVUxM KSA8IDApIHsKKwkJZXJyb3IgPSBlcnJubzsKIAkJd2FybigiRmFpbGVkIHRvIGdldCBwYXRyb2wg cmVhZCBwcm9wZXJ0aWVzIik7Ci0JCXJldHVybiAoLTEpOworCQlyZXR1cm4gKGVycm5vKTsKIAl9 CiAJcmV0dXJuICgwKTsKIH0KQEAgLTgxLDE5ICs4MywyMyBAQAogCWNoYXIgbGFiZWxbMTZdOwog CXRpbWVfdCBub3c7CiAJdWludDMyX3QgYXQ7Ci0JaW50IGZkOworCWludCBlcnJvciwgZmQ7CiAJ dV9pbnQgaTsKIAogCWZkID0gbWZpX29wZW4obWZpX3VuaXQpOwogCWlmIChmZCA8IDApIHsKKwkJ ZXJyb3IgPSBlcnJubzsKIAkJd2FybigibWZpX29wZW4iKTsKLQkJcmV0dXJuIChlcnJubyk7CisJ CXJldHVybiAoZXJyb3IpOwogCX0KIAogCXRpbWUoJm5vdyk7CiAJbWZpX2dldF90aW1lKGZkLCAm YXQpOwotCWlmIChwYXRyb2xfZ2V0X3Byb3BzKGZkLCAmcHJvcCkgPCAwKQotCQlyZXR1cm4gKGVy cm5vKTsKKwlpZiAoYXQgPT0gMCkKKwkJcmV0dXJuIChFTlhJTyk7CisJZXJyb3IgPSBwYXRyb2xf Z2V0X3Byb3BzKGZkLCAmcHJvcCk7CisJaWYgKGVycm9yKQorCQlyZXR1cm4gKGVycm9yKTsKIAlw cmludGYoIk9wZXJhdGlvbiBNb2RlOiAiKTsKIAlzd2l0Y2ggKHByb3Aub3BfbW9kZSkgewogCWNh c2UgTUZJX1BSX09QTU9ERV9BVVRPOgpAQCAtMTIyLDggKzEyOCw5IEBACiAKIAlpZiAobWZpX2Rj bWRfY29tbWFuZChmZCwgTUZJX0RDTURfUFJfR0VUX1NUQVRVUywgJnN0YXR1cywKIAkgICAgc2l6 ZW9mKHN0YXR1cyksIE5VTEwsIDAsIE5VTEwpIDwgMCkgeworCQllcnJvciA9IGVycm5vOwogCQl3 YXJuKCJGYWlsZWQgdG8gZ2V0IHBhdHJvbCByZWFkIHByb3BlcnRpZXMiKTsKLQkJcmV0dXJuIChl cnJubyk7CisJCXJldHVybiAoZXJyb3IpOwogCX0KIAlwcmludGYoIlJ1bnMgQ29tcGxldGVkOiAl dVxuIiwgc3RhdHVzLm51bV9pdGVyYXRpb24pOwogCXByaW50ZigiQ3VycmVudCBTdGF0ZTogIik7 CkBAIC0xNDYsOCArMTUzLDkgQEAKIAl9CiAJaWYgKHN0YXR1cy5zdGF0ZSA9PSBNRklfUFJfU1RB VEVfQUNUSVZFKSB7CiAJCWlmIChtZmlfcGRfZ2V0X2xpc3QoZmQsICZsaXN0LCBOVUxMKSA8IDAp IHsKKwkJCWVycm9yID0gZXJybm87CiAJCQl3YXJuKCJGYWlsZWQgdG8gZ2V0IGRyaXZlIGxpc3Qi KTsKLQkJCXJldHVybiAoZXJybm8pOworCQkJcmV0dXJuIChlcnJvcik7CiAJCX0KIAogCQlmb3Ig KGkgPSAwOyBpIDwgbGlzdC0+Y291bnQ7IGkrKykgewpAQCAtMTU2LDkgKzE2NCwxMCBAQAogCiAJ CQlpZiAobWZpX3BkX2dldF9pbmZvKGZkLCBsaXN0LT5hZGRyW2ldLmRldmljZV9pZCwgJmluZm8s CiAJCQkgICAgTlVMTCkgPCAwKSB7CisJCQkJZXJyb3IgPSBlcnJubzsKIAkJCQl3YXJuKCJGYWls ZWQgdG8gZmV0Y2ggaW5mbyBmb3IgZHJpdmUgJXUiLAogCQkJCSAgICBsaXN0LT5hZGRyW2ldLmRl dmljZV9pZCk7Ci0JCQkJcmV0dXJuIChlcnJubyk7CisJCQkJcmV0dXJuIChlcnJvcik7CiAJCQl9 CiAJCQlpZiAoaW5mby5wcm9nX2luZm8uYWN0aXZlICYgTUZJX1BEX1BST0dSRVNTX1BBVFJPTCkg ewogCQkJCXNucHJpbnRmKGxhYmVsLCBzaXplb2YobGFiZWwpLCAiICAgIERyaXZlICV1IiwKQEAg LTE3OCwxOCArMTg3LDIwIEBACiBzdGF0aWMgaW50CiBzdGFydF9wYXRyb2woaW50IGFjLCBjaGFy ICoqYXYpCiB7Ci0JaW50IGZkOworCWludCBlcnJvciwgZmQ7CiAKIAlmZCA9IG1maV9vcGVuKG1m aV91bml0KTsKIAlpZiAoZmQgPCAwKSB7CisJCWVycm9yID0gZXJybm87CiAJCXdhcm4oIm1maV9v cGVuIik7Ci0JCXJldHVybiAoZXJybm8pOworCQlyZXR1cm4gKGVycm9yKTsKIAl9CiAKIAlpZiAo bWZpX2RjbWRfY29tbWFuZChmZCwgTUZJX0RDTURfUFJfU1RBUlQsIE5VTEwsIDAsIE5VTEwsIDAs IE5VTEwpIDwKIAkgICAgMCkgeworCQllcnJvciA9IGVycm5vOwogCQl3YXJuKCJGYWlsZWQgdG8g c3RhcnQgcGF0cm9sIHJlYWQiKTsKLQkJcmV0dXJuIChlcnJubyk7CisJCXJldHVybiAoZXJyb3Ip OwogCX0KIAogCWNsb3NlKGZkKTsKQEAgLTIwMSwxOCArMjEyLDIwIEBACiBzdGF0aWMgaW50CiBz dG9wX3BhdHJvbChpbnQgYWMsIGNoYXIgKiphdikKIHsKLQlpbnQgZmQ7CisJaW50IGVycm9yLCBm ZDsKIAogCWZkID0gbWZpX29wZW4obWZpX3VuaXQpOwogCWlmIChmZCA8IDApIHsKKwkJZXJyb3Ig PSBlcnJubzsKIAkJd2FybigibWZpX29wZW4iKTsKLQkJcmV0dXJuIChlcnJubyk7CisJCXJldHVy biAoZXJyb3IpOwogCX0KIAogCWlmIChtZmlfZGNtZF9jb21tYW5kKGZkLCBNRklfRENNRF9QUl9T VE9QLCBOVUxMLCAwLCBOVUxMLCAwLCBOVUxMKSA8CiAJICAgIDApIHsKKwkJZXJyb3IgPSBlcnJu bzsKIAkJd2FybigiRmFpbGVkIHRvIHN0b3AgcGF0cm9sIHJlYWQiKTsKLQkJcmV0dXJuIChlcnJu byk7CisJCXJldHVybiAoZXJyb3IpOwogCX0KIAogCWNsb3NlKGZkKTsKQEAgLTIyNywxMCArMjQw LDEwIEBACiAJc3RydWN0IG1maV9wcl9wcm9wZXJ0aWVzIHByb3A7CiAJbG9uZyB2YWw7CiAJdGlt ZV90IG5vdzsKKwlpbnQgZXJyb3IsIGZkOwogCXVpbnQzMl90IGF0LCBuZXh0X2V4ZWMsIGV4ZWNf ZnJlcTsKIAljaGFyICpjcDsKIAl1aW50OF90IG9wX21vZGU7Ci0JaW50IGZkOwogCiAJZXhlY19m cmVxID0gMDsJLyogR0NDIHRvbyBzdHVwaWQgKi8KIAluZXh0X2V4ZWMgPSAwOwpAQCAtMjcyLDEy ICsyODUsMTQgQEAKIAogCWZkID0gbWZpX29wZW4obWZpX3VuaXQpOwogCWlmIChmZCA8IDApIHsK KwkJZXJyb3IgPSBlcnJubzsKIAkJd2FybigibWZpX29wZW4iKTsKLQkJcmV0dXJuIChlcnJubyk7 CisJCXJldHVybiAoZXJyb3IpOwogCX0KIAotCWlmIChwYXRyb2xfZ2V0X3Byb3BzKGZkLCAmcHJv cCkgPCAwKQotCQlyZXR1cm4gKGVycm5vKTsKKwllcnJvciA9IHBhdHJvbF9nZXRfcHJvcHMoZmQs ICZwcm9wKTsKKwlpZiAoZXJyb3IpCisJCXJldHVybiAoZXJyb3IpOwogCXByb3Aub3BfbW9kZSA9 IG9wX21vZGU7CiAJaWYgKG9wX21vZGUgPT0gTUZJX1BSX09QTU9ERV9BVVRPKSB7CiAJCWlmIChh YyA+IDIpCkBAIC0yOTQsOCArMzA5LDkgQEAKIAl9CiAJaWYgKG1maV9kY21kX2NvbW1hbmQoZmQs IE1GSV9EQ01EX1BSX1NFVF9QUk9QRVJUSUVTLCAmcHJvcCwKIAkgICAgc2l6ZW9mKHByb3ApLCBO VUxMLCAwLCBOVUxMKSA8IDApIHsKKwkJZXJyb3IgPSBlcnJubzsKIAkJd2FybigiRmFpbGVkIHRv IHNldCBwYXRyb2wgcmVhZCBwcm9wZXJ0aWVzIik7Ci0JCXJldHVybiAoZXJybm8pOworCQlyZXR1 cm4gKGVycm9yKTsKIAl9CiAKIAljbG9zZShmZCk7Cg== --0016e64967c8f95e77049389033e-- From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 26 18:38: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 1AD3C106564A for ; Tue, 26 Oct 2010 18:38:41 +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 E13C88FC08 for ; Tue, 26 Oct 2010 18:38:40 +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 8301446B2C; Tue, 26 Oct 2010 14:38:40 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id AB60F8A009; Tue, 26 Oct 2010 14:38:39 -0400 (EDT) From: John Baldwin To: Garrett Cooper Date: Tue, 26 Oct 2010 14:38:10 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201010261438.10387.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 26 Oct 2010 14:38:39 -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: freebsd-hackers@freebsd.org Subject: Re: [PATCH] mfiutil(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: Tue, 26 Oct 2010 18:38:41 -0000 On Tuesday, October 26, 2010 2:09:53 pm Garrett Cooper wrote: > Because a number of places in the mfiutil(8) code immediately call > warn(3) after an error to an API occurred, and because warn(3) employs > printf, et all (multiple times) in libc, there's an off-chance that > the errno value can get stomped on by the warn(3) calls, which could > lead to confusing results from anyone depending on the value being > returned from the mfiutil APIs. Thus, the attached patch I'm providing > fixes those cases, as well as converts an existing internal API > (display_pending_firmware) to an non-void return mechanism. I also > made a few stack variable alignment changes to match style(9) as well > as got rid of the ad hoc powerof2 call in favor of the value in > sys/param.h. > I've run a small number of unit tests on my desktop at home with > my mfi(4) card, but will test out other failing cases with equipment I > have access to at work. Just a few nits: 1) The include of should replace (there's a note about these two headers in style(9), FYI). 2) patrol_get_props() should return 'error' on failure rather than 'errno'. 3) mfi_get_time() failing isn't fatal. The code already handles this case by not printing out a 'next run time' if at is zero. I think you can remove the check for at == 0. If all the other commands work and just that command fails I don't think it should be fatal. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 26 18:52: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 ED0D0106566C; Tue, 26 Oct 2010 18:52:18 +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 7A88A8FC29; Tue, 26 Oct 2010 18:52:18 +0000 (UTC) Received: by ywc21 with SMTP id 21so2245651ywc.13 for ; Tue, 26 Oct 2010 11:52:17 -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=TYXjT18oAXvvbz0OhBEpyrYmxmX4ixRX7KZhhShEA3U=; b=Uy7w1y3Gtze4m5OV6vbT/KJTqPTCEswUxeAcT9u8Zgp5Gjk4dRkbCozuGCPd6jR6w+ ElIfe+3IN8EiSfLsMzcodVB6CM2wTFftAp/H1aK7YHJJYeppDmW/0RAA+P7Tx072CobX wqy+kOavAkDwrfyWnK36aSlRSYUv1u6rN3KT4= 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=czDyfZUt/IsNrIJFaxe2A8sDMmr/E0s/8OpyT/qXk53l/nsaD27czndrY83dRoMnuB fK+9MTgKzvs+jXGSaB08cgtcryBbcFj2S6h1oKubiU+POEGe3VhHNB4pviMXBth0K1km WIntQSwBdoKmqb5uekFWfwk9VVuofGR+blBaA= MIME-Version: 1.0 Received: by 10.216.70.4 with SMTP id o4mr2152535wed.25.1288119136750; Tue, 26 Oct 2010 11:52:16 -0700 (PDT) Received: by 10.216.10.198 with HTTP; Tue, 26 Oct 2010 11:52:16 -0700 (PDT) In-Reply-To: <201010261438.10387.jhb@freebsd.org> References: <201010261438.10387.jhb@freebsd.org> Date: Tue, 26 Oct 2010 11:52:16 -0700 Message-ID: From: Garrett Cooper To: John Baldwin Content-Type: multipart/mixed; boundary=00504502d357930c9b0493899b55 Cc: freebsd-hackers@freebsd.org Subject: Re: [PATCH] mfiutil(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: Tue, 26 Oct 2010 18:52:19 -0000 --00504502d357930c9b0493899b55 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Oct 26, 2010 at 11:38 AM, John Baldwin wrote: > On Tuesday, October 26, 2010 2:09:53 pm Garrett Cooper wrote: >> =A0 =A0 Because a number of places in the mfiutil(8) code immediately ca= ll >> warn(3) after an error to an API occurred, and because warn(3) employs >> printf, et all (multiple times) in libc, there's an off-chance that >> the errno value can get stomped on by the warn(3) calls, which could >> lead to confusing results from anyone depending on the value being >> returned from the mfiutil APIs. Thus, the attached patch I'm providing >> fixes those cases, as well as converts an existing internal API >> (display_pending_firmware) to an non-void return mechanism. I also >> made a few stack variable alignment changes to match style(9) as well >> as got rid of the ad hoc powerof2 call in favor of the value in >> sys/param.h. >> =A0 =A0 I've run a small number of unit tests on my desktop at home with >> my mfi(4) card, but will test out other failing cases with equipment I >> have access to at work. > > Just a few nits: > > 1) The include of should replace (there's a n= ote > about these two headers in style(9), FYI). Done -- thanks for pointing me to that :). > 2) patrol_get_props() should return 'error' on failure rather than 'errno= '. Good catch -- fixed! > 3) mfi_get_time() failing isn't fatal. =A0The code already handles this c= ase by > not printing out a 'next run time' if at is zero. =A0I think you can remo= ve the > check for at =3D=3D 0. =A0If all the other commands work and just that co= mmand fails > I don't think it should be fatal. Ok -- removed the at =3D=3D 0 check. Thanks! -Garrett --00504502d357930c9b0493899b55 Content-Type: text/x-patch; charset=US-ASCII; name="mfiutil-capture-errno-values.patch" Content-Disposition: attachment; filename="mfiutil-capture-errno-values.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gfr4tfub0 SW5kZXg6IHVzci5zYmluL21maXV0aWwvbWZpX2NvbmZpZy5jCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHVzci5z YmluL21maXV0aWwvbWZpX2NvbmZpZy5jCShyZXZpc2lvbiAyMTQyNjApCisrKyB1c3Iuc2Jpbi9t Zml1dGlsL21maV9jb25maWcuYwkod29ya2luZyBjb3B5KQpAQCAtMjksMTIgKzI5LDEyIEBACiAg KiAkRnJlZUJTRCQKICAqLwogCi0jaW5jbHVkZSA8c3lzL3R5cGVzLmg+CisjaW5jbHVkZSA8c3lz L3BhcmFtLmg+CiAjaWZkZWYgREVCVUcKICNpbmNsdWRlIDxzeXMvc3lzY3RsLmg+CiAjZW5kaWYK LSNpbmNsdWRlIDxzeXMvZXJybm8uaD4KICNpbmNsdWRlIDxlcnIuaD4KKyNpbmNsdWRlIDxlcnJu by5oPgogI2luY2x1ZGUgPGxpYnV0aWwuaD4KICNpZmRlZiBERUJVRwogI2luY2x1ZGUgPHN0ZGlu dC5oPgpAQCAtNTIsOCArNTIsNiBAQAogc3RhdGljIGludAlhZGRfc3BhcmUoaW50IGFjLCBjaGFy ICoqYXYpOwogc3RhdGljIGludAlyZW1vdmVfc3BhcmUoaW50IGFjLCBjaGFyICoqYXYpOwogCi0j ZGVmaW5lIHBvd2Vyb2YyKHgpICAgICgoKCh4KS0xKSYoeCkpPT0wKQotCiBzdGF0aWMgbG9uZwog ZGVodW1hbml6ZShjb25zdCBjaGFyICp2YWx1ZSkKIHsKQEAgLTE1MSwxMyArMTQ5LDE0IEBACiBj bGVhcl9jb25maWcoaW50IGFjLCBjaGFyICoqYXYpCiB7CiAJc3RydWN0IG1maV9sZF9saXN0IGxp c3Q7Ci0JaW50IGNoLCBmZDsKKwlpbnQgY2gsIGVycm9yLCBmZDsKIAl1X2ludCBpOwogCiAJZmQg PSBtZmlfb3BlbihtZmlfdW5pdCk7CiAJaWYgKGZkIDwgMCkgeworCQllcnJvciA9IGVycm5vOwog CQl3YXJuKCJtZmlfb3BlbiIpOwotCQlyZXR1cm4gKGVycm5vKTsKKwkJcmV0dXJuIChlcnJvcik7 CiAJfQogCiAJaWYgKCFtZmlfcmVjb25maWdfc3VwcG9ydGVkKCkpIHsKQEAgLTE2Nyw4ICsxNjYs OSBAQAogCX0KIAogCWlmIChtZmlfbGRfZ2V0X2xpc3QoZmQsICZsaXN0LCBOVUxMKSA8IDApIHsK KwkJZXJyb3IgPSBlcnJubzsKIAkJd2FybigiRmFpbGVkIHRvIGdldCB2b2x1bWUgbGlzdCIpOwot CQlyZXR1cm4gKGVycm5vKTsKKwkJcmV0dXJuIChlcnJvcik7CiAJfQogCiAJZm9yIChpID0gMDsg aSA8IGxpc3QubGRfY291bnQ7IGkrKykgewpAQCAtMTg5LDggKzE4OSw5IEBACiAJfQogCiAJaWYg KG1maV9kY21kX2NvbW1hbmQoZmQsIE1GSV9EQ01EX0NGR19DTEVBUiwgTlVMTCwgMCwgTlVMTCwg MCwgTlVMTCkgPCAwKSB7CisJCWVycm9yID0gZXJybm87CiAJCXdhcm4oIkZhaWxlZCB0byBjbGVh ciBjb25maWd1cmF0aW9uIik7Ci0JCXJldHVybiAoZXJybm8pOworCQlyZXR1cm4gKGVycm9yKTsK IAl9CiAKIAlwcmludGYoIm1maSVkOiBDb25maWd1cmF0aW9uIGNsZWFyZWRcbiIsIG1maV91bml0 KTsKQEAgLTMzNSw4ICszMzYsOSBAQAogCQkJcmV0dXJuIChlcnJvcik7CiAKIAkJaWYgKG1maV9w ZF9nZXRfaW5mbyhmZCwgZGV2aWNlX2lkLCBwaW5mbywgTlVMTCkgPCAwKSB7CisJCQllcnJvciA9 IGVycm5vOwogCQkJd2FybigiRmFpbGVkIHRvIGZldGNoIGRyaXZlIGluZm8gZm9yIGRyaXZlICVz IiwgY3ApOwotCQkJcmV0dXJuIChlcnJubyk7CisJCQlyZXR1cm4gKGVycm9yKTsKIAkJfQogCiAJ CWlmIChwaW5mby0+Zndfc3RhdGUgIT0gTUZJX1BEX1NUQVRFX1VOQ09ORklHVVJFRF9HT09EKSB7 CkBAIC01NDgsOCArNTUwLDkgQEAKIAkKIAlmZCA9IG1maV9vcGVuKG1maV91bml0KTsKIAlpZiAo ZmQgPCAwKSB7CisJCWVycm9yID0gZXJybm87CiAJCXdhcm4oIm1maV9vcGVuIik7Ci0JCXJldHVy biAoZXJybm8pOworCQlyZXR1cm4gKGVycm9yKTsKIAl9CiAKIAlpZiAoIW1maV9yZWNvbmZpZ19z dXBwb3J0ZWQoKSkgewpAQCAtNjYwLDggKzY2Myw5IEBACiAJICogYXJyYXkgYW5kIHZvbHVtZSBp ZGVudGlmaWVycy4KIAkgKi8KIAlpZiAobWZpX2NvbmZpZ19yZWFkKGZkLCAmY29uZmlnKSA8IDAp IHsKKwkJZXJyb3IgPSBlcnJubzsKIAkJd2FybigiRmFpbGVkIHRvIHJlYWQgY29uZmlndXJhdGlv biIpOwotCQlyZXR1cm4gKGVycm5vKTsKKwkJcmV0dXJuIChlcnJvcik7CiAJfQogCXAgPSAoY2hh ciAqKWNvbmZpZy0+YXJyYXk7CiAJc3RhdGUuYXJyYXlfcmVmID0gMHhmZmZmOwpAQCAtNzQ1LDE0 ICs3NDksMTQgQEAKICNpZmRlZiBERUJVRwogCWlmIChkdW1wKQogCQlkdW1wX2NvbmZpZyhmZCwg Y29uZmlnKTsKLQllbHNlCiAjZW5kaWYKIAogCS8qIFNlbmQgdGhlIG5ldyBjb25maWcgdG8gdGhl IGNvbnRyb2xsZXIuICovCiAJaWYgKG1maV9kY21kX2NvbW1hbmQoZmQsIE1GSV9EQ01EX0NGR19B REQsIGNvbmZpZywgY29uZmlnX3NpemUsCiAJICAgIE5VTEwsIDAsIE5VTEwpIDwgMCkgeworCQll cnJvciA9IGVycm5vOwogCQl3YXJuKCJGYWlsZWQgdG8gYWRkIHZvbHVtZSIpOwotCQlyZXR1cm4g KGVycm5vKTsKKwkJcmV0dXJuIChlcnJvcik7CiAJfQogCiAJLyogQ2xlYW4gdXAuICovCkBAIC03 NzQsNyArNzc4LDcgQEAKIGRlbGV0ZV92b2x1bWUoaW50IGFjLCBjaGFyICoqYXYpCiB7CiAJc3Ry dWN0IG1maV9sZF9pbmZvIGluZm87Ci0JaW50IGZkOworCWludCBlcnJvciwgZmQ7CiAJdWludDhf dCB0YXJnZXRfaWQsIG1ib3hbNF07CiAKIAkvKgpAQCAtNzk5LDggKzgwMyw5IEBACiAKIAlmZCA9 IG1maV9vcGVuKG1maV91bml0KTsKIAlpZiAoZmQgPCAwKSB7CisJCWVycm9yID0gZXJybm87CiAJ CXdhcm4oIm1maV9vcGVuIik7Ci0JCXJldHVybiAoZXJybm8pOworCQlyZXR1cm4gKGVycm9yKTsK IAl9CiAKIAlpZiAoIW1maV9yZWNvbmZpZ19zdXBwb3J0ZWQoKSkgewpAQCAtODEwLDEzICs4MTUs MTUgQEAKIAl9CiAKIAlpZiAobWZpX2xvb2t1cF92b2x1bWUoZmQsIGF2WzFdLCAmdGFyZ2V0X2lk KSA8IDApIHsKKwkJZXJyb3IgPSBlcnJubzsKIAkJd2FybigiSW52YWxpZCB2b2x1bWUgJXMiLCBh dlsxXSk7Ci0JCXJldHVybiAoZXJybm8pOworCQlyZXR1cm4gKGVycm9yKTsKIAl9CiAKIAlpZiAo bWZpX2xkX2dldF9pbmZvKGZkLCB0YXJnZXRfaWQsICZpbmZvLCBOVUxMKSA8IDApIHsKKwkJZXJy b3IgPSBlcnJubzsKIAkJd2FybigiRmFpbGVkIHRvIGdldCBpbmZvIGZvciB2b2x1bWUgJWQiLCB0 YXJnZXRfaWQpOwotCQlyZXR1cm4gKGVycm5vKTsKKwkJcmV0dXJuIChlcnJvcik7CiAJfQogCiAJ aWYgKG1maV92b2x1bWVfYnVzeShmZCwgdGFyZ2V0X2lkKSkgewpAQCAtODI4LDggKzgzNSw5IEBA CiAJbWJveF9zdG9yZV9sZHJlZihtYm94LCAmaW5mby5sZF9jb25maWcucHJvcGVydGllcy5sZCk7 CiAJaWYgKG1maV9kY21kX2NvbW1hbmQoZmQsIE1GSV9EQ01EX0xEX0RFTEVURSwgTlVMTCwgMCwg bWJveCwKIAkgICAgc2l6ZW9mKG1ib3gpLCBOVUxMKSA8IDApIHsKKwkJZXJyb3IgPSBlcnJubzsK IAkJd2FybigiRmFpbGVkIHRvIGRlbGV0ZSB2b2x1bWUiKTsKLQkJcmV0dXJuIChlcnJubyk7CisJ CXJldHVybiAoZXJyb3IpOwogCX0KIAogCWNsb3NlKGZkKTsKQEAgLTg1OCw4ICs4NjYsOSBAQAog CiAJZmQgPSBtZmlfb3BlbihtZmlfdW5pdCk7CiAJaWYgKGZkIDwgMCkgeworCQllcnJvciA9IGVy cm5vOwogCQl3YXJuKCJtZmlfb3BlbiIpOwotCQlyZXR1cm4gKGVycm5vKTsKKwkJcmV0dXJuIChl cnJvcik7CiAJfQogCiAJZXJyb3IgPSBtZmlfbG9va3VwX2RyaXZlKGZkLCBhdlsxXSwgJmRldmlj ZV9pZCk7CkBAIC04NjcsOCArODc2LDkgQEAKIAkJcmV0dXJuIChlcnJvcik7CiAKIAlpZiAobWZp X3BkX2dldF9pbmZvKGZkLCBkZXZpY2VfaWQsICZpbmZvLCBOVUxMKSA8IDApIHsKKwkJZXJyb3Ig PSBlcnJubzsKIAkJd2FybigiRmFpbGVkIHRvIGZldGNoIGRyaXZlIGluZm8iKTsKLQkJcmV0dXJu IChlcnJubyk7CisJCXJldHVybiAoZXJyb3IpOwogCX0KIAogCWlmIChpbmZvLmZ3X3N0YXRlICE9 IE1GSV9QRF9TVEFURV9VTkNPTkZJR1VSRURfR09PRCkgewpAQCAtODc4LDE0ICs4ODgsMTYgQEAK IAogCWlmIChhYyA+IDIpIHsKIAkJaWYgKG1maV9sb29rdXBfdm9sdW1lKGZkLCBhdlsyXSwgJnRh cmdldF9pZCkgPCAwKSB7CisJCQllcnJvciA9IGVycm5vOwogCQkJd2FybigiSW52YWxpZCB2b2x1 bWUgJXMiLCBhdlsyXSk7Ci0JCQlyZXR1cm4gKGVycm5vKTsKKwkJCXJldHVybiAoZXJyb3IpOwog CQl9CiAJfQogCiAJaWYgKG1maV9jb25maWdfcmVhZChmZCwgJmNvbmZpZykgPCAwKSB7CisJCWVy cm9yID0gZXJybm87CiAJCXdhcm4oIkZhaWxlZCB0byByZWFkIGNvbmZpZ3VyYXRpb24iKTsKLQkJ cmV0dXJuIChlcnJubyk7CisJCXJldHVybiAoZXJyb3IpOwogCX0KIAogCXNwYXJlID0gbWFsbG9j KHNpemVvZihzdHJ1Y3QgbWZpX3NwYXJlKSArIHNpemVvZih1aW50MTZfdCkgKgpAQCAtOTM5LDgg Kzk1MSw5IEBACiAJaWYgKG1maV9kY21kX2NvbW1hbmQoZmQsIE1GSV9EQ01EX0NGR19NQUtFX1NQ QVJFLCBzcGFyZSwKIAkgICAgc2l6ZW9mKHN0cnVjdCBtZmlfc3BhcmUpICsgc2l6ZW9mKHVpbnQx Nl90KSAqIHNwYXJlLT5hcnJheV9jb3VudCwKIAkgICAgTlVMTCwgMCwgTlVMTCkgPCAwKSB7CisJ CWVycm9yID0gZXJybm87CiAJCXdhcm4oIkZhaWxlZCB0byBhc3NpZ24gc3BhcmUiKTsKLQkJcmV0 dXJuIChlcnJubyk7CisJCXJldHVybiAoZXJyb3IpOwogCX0KIAogCWNsb3NlKGZkKTsKQEAgLTk2 NCw4ICs5NzcsOSBAQAogCiAJZmQgPSBtZmlfb3BlbihtZmlfdW5pdCk7CiAJaWYgKGZkIDwgMCkg eworCQllcnJvciA9IGVycm5vOwogCQl3YXJuKCJtZmlfb3BlbiIpOwotCQlyZXR1cm4gKGVycm5v KTsKKwkJcmV0dXJuIChlcnJvcik7CiAJfQogCiAJZXJyb3IgPSBtZmlfbG9va3VwX2RyaXZlKGZk LCBhdlsxXSwgJmRldmljZV9pZCk7CkBAIC05NzQsOCArOTg4LDkgQEAKIAogCS8qIEdldCB0aGUg aW5mbyBmb3IgdGhpcyBkcml2ZS4gKi8KIAlpZiAobWZpX3BkX2dldF9pbmZvKGZkLCBkZXZpY2Vf aWQsICZpbmZvLCBOVUxMKSA8IDApIHsKKwkJZXJyb3IgPSBlcnJubzsKIAkJd2FybigiRmFpbGVk IHRvIGZldGNoIGluZm8gZm9yIGRyaXZlICV1IiwgZGV2aWNlX2lkKTsKLQkJcmV0dXJuIChlcnJu byk7CisJCXJldHVybiAoZXJyb3IpOwogCX0KIAogCWlmIChpbmZvLmZ3X3N0YXRlICE9IE1GSV9Q RF9TVEFURV9IT1RfU1BBUkUpIHsKQEAgLTk4Niw4ICsxMDAxLDkgQEAKIAltYm94X3N0b3JlX3Bk cmVmKG1ib3gsICZpbmZvLnJlZik7CiAJaWYgKG1maV9kY21kX2NvbW1hbmQoZmQsIE1GSV9EQ01E X0NGR19SRU1PVkVfU1BBUkUsIE5VTEwsIDAsIG1ib3gsCiAJICAgIHNpemVvZihtYm94KSwgTlVM TCkgPCAwKSB7CisJCWVycm9yID0gZXJybm87CiAJCXdhcm4oIkZhaWxlZCB0byBkZWxldGUgc3Bh cmUiKTsKLQkJcmV0dXJuIChlcnJubyk7CisJCXJldHVybiAoZXJyb3IpOwogCX0KIAogCWNsb3Nl KGZkKTsKQEAgLTEwOTMsNyArMTEwOSw3IEBACiBkZWJ1Z19jb25maWcoaW50IGFjLCBjaGFyICoq YXYpCiB7CiAJc3RydWN0IG1maV9jb25maWdfZGF0YSAqY29uZmlnOwotCWludCBmZDsKKwlpbnQg ZXJyb3IsIGZkOwogCiAJaWYgKGFjICE9IDEpIHsKIAkJd2FybngoImRlYnVnOiBleHRyYSBhcmd1 bWVudHMiKTsKQEAgLTExMDIsMTQgKzExMTgsMTYgQEAKIAogCWZkID0gbWZpX29wZW4obWZpX3Vu aXQpOwogCWlmIChmZCA8IDApIHsKKwkJZXJyb3IgPSBlcnJubzsKIAkJd2FybigibWZpX29wZW4i KTsKLQkJcmV0dXJuIChlcnJubyk7CisJCXJldHVybiAoZXJyb3IpOwogCX0KIAogCS8qIEdldCB0 aGUgY29uZmlnIGZyb20gdGhlIGNvbnRyb2xsZXIuICovCiAJaWYgKG1maV9jb25maWdfcmVhZChm ZCwgJmNvbmZpZykgPCAwKSB7CisJCWVycm9yID0gZXJybm87CiAJCXdhcm4oIkZhaWxlZCB0byBn ZXQgY29uZmlnIik7Ci0JCXJldHVybiAoZXJybm8pOworCQlyZXR1cm4gKGVycm9yKTsKIAl9CiAK IAkvKiBEdW1wIG91dCB0aGUgY29uZmlndXJhdGlvbi4gKi8KQEAgLTExMjcsNyArMTE0NSw3IEBA CiAJc3RydWN0IG1maV9jb25maWdfZGF0YSAqY29uZmlnOwogCWNoYXIgYnVmWzY0XTsKIAlzaXpl X3QgbGVuOwotCWludCBmZDsKKwlpbnQgZXJyb3IsIGZkOwogCiAJaWYgKGFjICE9IDEpIHsKIAkJ d2FybngoImR1bXA6IGV4dHJhIGFyZ3VtZW50cyIpOwpAQCAtMTEzNiwyMyArMTE1NCwyNiBAQAog CiAJZmQgPSBtZmlfb3BlbihtZmlfdW5pdCk7CiAJaWYgKGZkIDwgMCkgeworCQllcnJvciA9IGVy cm5vOwogCQl3YXJuKCJtZmlfb3BlbiIpOwotCQlyZXR1cm4gKGVycm5vKTsKKwkJcmV0dXJuIChl cnJvcik7CiAJfQogCiAJLyogR2V0IHRoZSBzdGFzaGVkIGNvcHkgb2YgdGhlIGxhc3QgZGNtZCBm cm9tIHRoZSBkcml2ZXIuICovCiAJc25wcmludGYoYnVmLCBzaXplb2YoYnVmKSwgImRldi5tZmku JWQuZGVidWdfY29tbWFuZCIsIG1maV91bml0KTsKIAlpZiAoc3lzY3RsYnluYW1lKGJ1ZiwgTlVM TCwgJmxlbiwgTlVMTCwgMCkgPCAwKSB7CisJCWVycm9yID0gZXJybm87CiAJCXdhcm4oIkZhaWxl ZCB0byByZWFkIGRlYnVnIGNvbW1hbmQiKTsKLQkJaWYgKGVycm5vID09IEVOT0VOVCkKLQkJCWVy cm5vID0gRU9QTk9UU1VQUDsKLQkJcmV0dXJuIChlcnJubyk7CisJCWlmIChlcnJvciA9PSBFTk9F TlQpCisJCQllcnJvciA9IEVPUE5PVFNVUFA7CisJCXJldHVybiAoZXJyb3IpOwogCX0KIAogCWNv bmZpZyA9IG1hbGxvYyhsZW4pOwogCWlmIChzeXNjdGxieW5hbWUoYnVmLCBjb25maWcsICZsZW4s IE5VTEwsIDApIDwgMCkgeworCQllcnJvciA9IGVycm5vOwogCQl3YXJuKCJGYWlsZWQgdG8gcmVh ZCBkZWJ1ZyBjb21tYW5kIik7Ci0JCXJldHVybiAoZXJybm8pOworCQlyZXR1cm4gKGVycm9yKTsK IAl9CiAJZHVtcF9jb25maWcoZmQsIGNvbmZpZyk7CiAJZnJlZShjb25maWcpOwpJbmRleDogdXNy LnNiaW4vbWZpdXRpbC9tZmlfdm9sdW1lLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gdXNyLnNiaW4vbWZpdXRp bC9tZmlfdm9sdW1lLmMJKHJldmlzaW9uIDIxNDI2MCkKKysrIHVzci5zYmluL21maXV0aWwvbWZp X3ZvbHVtZS5jCSh3b3JraW5nIGNvcHkpCkBAIC0xMTQsNiArMTE0LDcgQEAKIHVwZGF0ZV9jYWNo ZV9wb2xpY3koaW50IGZkLCBzdHJ1Y3QgbWZpX2xkX3Byb3BzICpwcm9wcywgdWludDhfdCBuZXdf cG9saWN5LAogICAgIHVpbnQ4X3QgbWFzaykKIHsKKwlpbnQgZXJyb3I7CiAJdWludDhfdCBjaGFu Z2VzLCBwb2xpY3k7CiAKIAlwb2xpY3kgPSAocHJvcHMtPmRlZmF1bHRfY2FjaGVfcG9saWN5ICYg fm1hc2spIHwgbmV3X3BvbGljeTsKQEAgLTE0MCw4ICsxNDEsOSBAQAogCiAJcHJvcHMtPmRlZmF1 bHRfY2FjaGVfcG9saWN5ID0gcG9saWN5OwogCWlmIChtZmlfbGRfc2V0X3Byb3BzKGZkLCBwcm9w cykgPCAwKSB7CisJCWVycm9yID0gZXJybm87CiAJCXdhcm4oIkZhaWxlZCB0byBzZXQgdm9sdW1l IHByb3BlcnRpZXMiKTsKLQkJcmV0dXJuIChlcnJubyk7CisJCXJldHVybiAoZXJyb3IpOwogCX0K IAlyZXR1cm4gKDApOwogfQpAQCAtMTYwLDE4ICsxNjIsMjEgQEAKIAogCWZkID0gbWZpX29wZW4o bWZpX3VuaXQpOwogCWlmIChmZCA8IDApIHsKKwkJZXJyb3IgPSBlcnJubzsKIAkJd2FybigibWZp X29wZW4iKTsKLQkJcmV0dXJuIChlcnJubyk7CisJCXJldHVybiAoZXJyb3IpOwogCX0KIAogCWlm IChtZmlfbG9va3VwX3ZvbHVtZShmZCwgYXZbMV0sICZ0YXJnZXRfaWQpIDwgMCkgeworCQllcnJv ciA9IGVycm5vOwogCQl3YXJuKCJJbnZhbGlkIHZvbHVtZTogJXMiLCBhdlsxXSk7Ci0JCXJldHVy biAoZXJybm8pOworCQlyZXR1cm4gKGVycm9yKTsKIAl9CiAKIAlpZiAobWZpX2xkX2dldF9wcm9w cyhmZCwgdGFyZ2V0X2lkLCAmcHJvcHMpIDwgMCkgeworCQllcnJvciA9IGVycm5vOwogCQl3YXJu KCJGYWlsZWQgdG8gZmV0Y2ggdm9sdW1lIHByb3BlcnRpZXMiKTsKLQkJcmV0dXJuIChlcnJubyk7 CisJCXJldHVybiAoZXJyb3IpOwogCX0KIAogCWlmIChhYyA9PSAyKSB7CkBAIC0yOTgsOCArMzAz LDggQEAKIAkJCQl9CiAJCQkJcHJvcHMuZGlza19jYWNoZV9wb2xpY3kgPSBwb2xpY3k7CiAJCQkJ aWYgKG1maV9sZF9zZXRfcHJvcHMoZmQsICZwcm9wcykgPCAwKSB7CisJCQkJCWVycm9yID0gZXJy bm87CiAJCQkJCXdhcm4oIkZhaWxlZCB0byBzZXQgdm9sdW1lIHByb3BlcnRpZXMiKTsKLQkJCQkJ ZXJyb3IgPSBlcnJubzsKIAkJCQl9CiAJCQl9CiAJCX0gZWxzZSB7CkBAIC0zMTcsNyArMzIyLDcg QEAKIHZvbHVtZV9uYW1lKGludCBhYywgY2hhciAqKmF2KQogewogCXN0cnVjdCBtZmlfbGRfcHJv cHMgcHJvcHM7Ci0JaW50IGZkOworCWludCBlcnJvciwgZmQ7CiAJdWludDhfdCB0YXJnZXRfaWQ7 CiAKIAlpZiAoYWMgIT0gMykgewpAQCAtMzMyLDE4ICszMzcsMjEgQEAKIAogCWZkID0gbWZpX29w ZW4obWZpX3VuaXQpOwogCWlmIChmZCA8IDApIHsKKwkJZXJyb3IgPSBlcnJubzsKIAkJd2Fybigi bWZpX29wZW4iKTsKLQkJcmV0dXJuIChlcnJubyk7CisJCXJldHVybiAoZXJyb3IpOwogCX0KIAog CWlmIChtZmlfbG9va3VwX3ZvbHVtZShmZCwgYXZbMV0sICZ0YXJnZXRfaWQpIDwgMCkgeworCQll cnJvciA9IGVycm5vOwogCQl3YXJuKCJJbnZhbGlkIHZvbHVtZTogJXMiLCBhdlsxXSk7Ci0JCXJl dHVybiAoZXJybm8pOworCQlyZXR1cm4gKGVycm9yKTsKIAl9CiAKIAlpZiAobWZpX2xkX2dldF9w cm9wcyhmZCwgdGFyZ2V0X2lkLCAmcHJvcHMpIDwgMCkgeworCQllcnJvciA9IGVycm5vOwogCQl3 YXJuKCJGYWlsZWQgdG8gZmV0Y2ggdm9sdW1lIHByb3BlcnRpZXMiKTsKLQkJcmV0dXJuIChlcnJu byk7CisJCXJldHVybiAoZXJyb3IpOwogCX0KIAogCXByaW50ZigibWZpJXUgdm9sdW1lICVzIG5h bWUgY2hhbmdlZCBmcm9tIFwiJXNcIiB0byBcIiVzXCJcbiIsIG1maV91bml0LApAQCAtMzUxLDgg KzM1OSw5IEBACiAJYnplcm8ocHJvcHMubmFtZSwgc2l6ZW9mKHByb3BzLm5hbWUpKTsKIAlzdHJj cHkocHJvcHMubmFtZSwgYXZbMl0pOwogCWlmIChtZmlfbGRfc2V0X3Byb3BzKGZkLCAmcHJvcHMp IDwgMCkgeworCQllcnJvciA9IGVycm5vOwogCQl3YXJuKCJGYWlsZWQgdG8gc2V0IHZvbHVtZSBw cm9wZXJ0aWVzIik7Ci0JCXJldHVybiAoZXJybm8pOworCQlyZXR1cm4gKGVycm9yKTsKIAl9CiAK IAljbG9zZShmZCk7CkBAIC0zNjUsNyArMzc0LDcgQEAKIHZvbHVtZV9wcm9ncmVzcyhpbnQgYWMs IGNoYXIgKiphdikKIHsKIAlzdHJ1Y3QgbWZpX2xkX2luZm8gaW5mbzsKLQlpbnQgZmQ7CisJaW50 IGVycm9yLCBmZDsKIAl1aW50OF90IHRhcmdldF9pZDsKIAogCWlmIChhYyAhPSAyKSB7CkBAIC0z NzYsMjAgKzM4NSwyMyBAQAogCiAJZmQgPSBtZmlfb3BlbihtZmlfdW5pdCk7CiAJaWYgKGZkIDwg MCkgeworCQllcnJvciA9IGVycm5vOwogCQl3YXJuKCJtZmlfb3BlbiIpOwotCQlyZXR1cm4gKGVy cm5vKTsKKwkJcmV0dXJuIChlcnJvcik7CiAJfQogCiAJaWYgKG1maV9sb29rdXBfdm9sdW1lKGZk LCBhdlsxXSwgJnRhcmdldF9pZCkgPCAwKSB7CisJCWVycm9yID0gZXJybm87CiAJCXdhcm4oIklu dmFsaWQgdm9sdW1lOiAlcyIsIGF2WzFdKTsKLQkJcmV0dXJuIChlcnJubyk7CisJCXJldHVybiAo ZXJyb3IpOwogCX0KIAogCS8qIEdldCB0aGUgaW5mbyBmb3IgdGhpcyBkcml2ZS4gKi8KIAlpZiAo bWZpX2xkX2dldF9pbmZvKGZkLCB0YXJnZXRfaWQsICZpbmZvLCBOVUxMKSA8IDApIHsKKwkJZXJy b3IgPSBlcnJubzsKIAkJd2FybigiRmFpbGVkIHRvIGZldGNoIGluZm8gZm9yIHZvbHVtZSAlcyIs CiAJCSAgICBtZmlfdm9sdW1lX25hbWUoZmQsIHRhcmdldF9pZCkpOwotCQlyZXR1cm4gKGVycm5v KTsKKwkJcmV0dXJuIChlcnJvcik7CiAJfQogCiAJLyogRGlzcGxheSBhbnkgb2YgdGhlIGFjdGl2 ZSBldmVudHMuICovCkluZGV4OiB1c3Iuc2Jpbi9tZml1dGlsL21maV9kcml2ZS5jCj09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT0KLS0tIHVzci5zYmluL21maXV0aWwvbWZpX2RyaXZlLmMJKHJldmlzaW9uIDIxNDI2MCkKKysr IHVzci5zYmluL21maXV0aWwvbWZpX2RyaXZlLmMJKHdvcmtpbmcgY29weSkKQEAgLTc5LDEwICs3 OSwxMSBAQAogbWZpX2xvb2t1cF9kcml2ZShpbnQgZmQsIGNoYXIgKmRyaXZlLCB1aW50MTZfdCAq ZGV2aWNlX2lkKQogewogCXN0cnVjdCBtZmlfcGRfbGlzdCAqbGlzdDsKLQl1aW50OF90IGVuY2ws IHNsb3Q7CiAJbG9uZyB2YWw7CisJaW50IGVycm9yOwogCXVfaW50IGk7CiAJY2hhciAqY3A7CisJ dWludDhfdCBlbmNsLCBzbG90OwogCiAJLyogTG9vayBmb3IgYSByYXcgZGV2aWNlIGlkIGZpcnN0 LiAqLwogCXZhbCA9IHN0cnRvbChkcml2ZSwgJmNwLCAwKTsKQEAgLTExOCw4ICsxMTksOSBAQAog CQlzbG90ID0gdmFsOwogCiAJCWlmIChtZmlfcGRfZ2V0X2xpc3QoZmQsICZsaXN0LCBOVUxMKSA8 IDApIHsKKwkJCWVycm9yID0gZXJybm87CiAJCQl3YXJuKCJGYWlsZWQgdG8gZmV0Y2ggZHJpdmUg bGlzdCIpOwotCQkJcmV0dXJuIChlcnJubyk7CisJCQlyZXR1cm4gKGVycm9yKTsKIAkJfQogCiAJ CWZvciAoaSA9IDA7IGkgPCBsaXN0LT5jb3VudDsgaSsrKSB7CkBAIC0zMDIsOCArMzA0LDkgQEAK IAogCWZkID0gbWZpX29wZW4obWZpX3VuaXQpOwogCWlmIChmZCA8IDApIHsKKwkJZXJyb3IgPSBl cnJubzsKIAkJd2FybigibWZpX29wZW4iKTsKLQkJcmV0dXJuIChlcnJubyk7CisJCXJldHVybiAo ZXJyb3IpOwogCX0KIAogCWVycm9yID0gbWZpX2xvb2t1cF9kcml2ZShmZCwgZHJpdmUsICZkZXZp Y2VfaWQpOwpAQCAtMzEyLDggKzMxNSw5IEBACiAKIAkvKiBHZXQgdGhlIGluZm8gZm9yIHRoaXMg ZHJpdmUuICovCiAJaWYgKG1maV9wZF9nZXRfaW5mbyhmZCwgZGV2aWNlX2lkLCAmaW5mbywgTlVM TCkgPCAwKSB7CisJCWVycm9yID0gZXJybm87CiAJCXdhcm4oIkZhaWxlZCB0byBmZXRjaCBpbmZv IGZvciBkcml2ZSAldSIsIGRldmljZV9pZCk7Ci0JCXJldHVybiAoZXJybm8pOworCQlyZXR1cm4g KGVycm9yKTsKIAl9CiAKIAkvKiBUcnkgdG8gY2hhbmdlIHRoZSBzdGF0ZS4gKi8KQEAgLTMyNyw5 ICszMzEsMTAgQEAKIAltYm94WzVdID0gbmV3X3N0YXRlID4+IDg7CiAJaWYgKG1maV9kY21kX2Nv bW1hbmQoZmQsIE1GSV9EQ01EX1BEX1NUQVRFX1NFVCwgTlVMTCwgMCwgbWJveCwgNiwKIAkgICAg TlVMTCkgPCAwKSB7CisJCWVycm9yID0gZXJybm87CiAJCXdhcm4oIkZhaWxlZCB0byBzZXQgZHJp dmUgJXUgdG8gJXMiLCBkZXZpY2VfaWQsCiAJCSAgICBtZmlfcGRzdGF0ZShuZXdfc3RhdGUpKTsK LQkJcmV0dXJuIChlcnJubyk7CisJCXJldHVybiAoZXJyb3IpOwogCX0KIAogCWNsb3NlKGZkKTsK QEAgLTM5NSw4ICs0MDAsOSBAQAogCiAJZmQgPSBtZmlfb3BlbihtZmlfdW5pdCk7CiAJaWYgKGZk IDwgMCkgeworCQllcnJvciA9IGVycm5vOwogCQl3YXJuKCJtZmlfb3BlbiIpOwotCQlyZXR1cm4g KGVycm5vKTsKKwkJcmV0dXJuIChlcnJvcik7CiAJfQogCiAJZXJyb3IgPSBtZmlfbG9va3VwX2Ry aXZlKGZkLCBhdlsxXSwgJmRldmljZV9pZCk7CkBAIC00MDUsMTMgKzQxMSwxNCBAQAogCiAJLyog R2V0IHRoZSBpbmZvIGZvciB0aGlzIGRyaXZlLiAqLwogCWlmIChtZmlfcGRfZ2V0X2luZm8oZmQs IGRldmljZV9pZCwgJmluZm8sIE5VTEwpIDwgMCkgeworCQllcnJvciA9IGVycm5vOwogCQl3YXJu KCJGYWlsZWQgdG8gZmV0Y2ggaW5mbyBmb3IgZHJpdmUgJXUiLCBkZXZpY2VfaWQpOwotCQlyZXR1 cm4gKGVycm5vKTsKKwkJcmV0dXJuIChlcnJvcik7CiAJfQogCiAJLyogQ2hlY2sgdGhlIHN0YXRl LCBtdXN0IGJlIFJFQlVJTEQuICovCiAJaWYgKGluZm8uZndfc3RhdGUgIT0gTUZJX1BEX1NUQVRF X1JFQlVJTEQpIHsKLQkJd2FybigiRHJpdmUgJWQgaXMgbm90IGluIHRoZSBSRUJVSUxEIHN0YXRl IiwgZGV2aWNlX2lkKTsKKwkJd2FybngoIkRyaXZlICVkIGlzIG5vdCBpbiB0aGUgUkVCVUlMRCBz dGF0ZSIsIGRldmljZV9pZCk7CiAJCXJldHVybiAoRUlOVkFMKTsKIAl9CiAKQEAgLTQxOSw4ICs0 MjYsOSBAQAogCW1ib3hfc3RvcmVfcGRyZWYoJm1ib3hbMF0sICZpbmZvLnJlZik7CiAJaWYgKG1m aV9kY21kX2NvbW1hbmQoZmQsIE1GSV9EQ01EX1BEX1JFQlVJTERfU1RBUlQsIE5VTEwsIDAsIG1i b3gsIDQsCiAJICAgIE5VTEwpIDwgMCkgeworCQllcnJvciA9IGVycm5vOwogCQl3YXJuKCJGYWls ZWQgdG8gc3RhcnQgcmVidWlsZCBvbiBkcml2ZSAldSIsIGRldmljZV9pZCk7Ci0JCXJldHVybiAo ZXJybm8pOworCQlyZXR1cm4gKGVycm9yKTsKIAl9CiAJY2xvc2UoZmQpOwogCkBAIC00NDQsOCAr NDUyLDkgQEAKIAogCWZkID0gbWZpX29wZW4obWZpX3VuaXQpOwogCWlmIChmZCA8IDApIHsKKwkJ ZXJyb3IgPSBlcnJubzsKIAkJd2FybigibWZpX29wZW4iKTsKLQkJcmV0dXJuIChlcnJubyk7CisJ CXJldHVybiAoZXJyb3IpOwogCX0KIAogCWVycm9yID0gbWZpX2xvb2t1cF9kcml2ZShmZCwgYXZb MV0sICZkZXZpY2VfaWQpOwpAQCAtNDU0LDggKzQ2Myw5IEBACiAKIAkvKiBHZXQgdGhlIGluZm8g Zm9yIHRoaXMgZHJpdmUuICovCiAJaWYgKG1maV9wZF9nZXRfaW5mbyhmZCwgZGV2aWNlX2lkLCAm aW5mbywgTlVMTCkgPCAwKSB7CisJCWVycm9yID0gZXJybm87CiAJCXdhcm4oIkZhaWxlZCB0byBm ZXRjaCBpbmZvIGZvciBkcml2ZSAldSIsIGRldmljZV9pZCk7Ci0JCXJldHVybiAoZXJybm8pOwor CQlyZXR1cm4gKGVycm9yKTsKIAl9CiAKIAkvKiBDaGVjayB0aGUgc3RhdGUsIG11c3QgYmUgUkVC VUlMRC4gKi8KQEAgLTQ2OCw4ICs0NzgsOSBAQAogCW1ib3hfc3RvcmVfcGRyZWYoJm1ib3hbMF0s ICZpbmZvLnJlZik7CiAJaWYgKG1maV9kY21kX2NvbW1hbmQoZmQsIE1GSV9EQ01EX1BEX1JFQlVJ TERfQUJPUlQsIE5VTEwsIDAsIG1ib3gsIDQsCiAJICAgIE5VTEwpIDwgMCkgeworCQllcnJvciA9 IGVycm5vOwogCQl3YXJuKCJGYWlsZWQgdG8gYWJvcnQgcmVidWlsZCBvbiBkcml2ZSAldSIsIGRl dmljZV9pZCk7Ci0JCXJldHVybiAoZXJybm8pOworCQlyZXR1cm4gKGVycm9yKTsKIAl9CiAJY2xv c2UoZmQpOwogCkBAIC00OTIsOCArNTAzLDkgQEAKIAogCWZkID0gbWZpX29wZW4obWZpX3VuaXQp OwogCWlmIChmZCA8IDApIHsKKwkJZXJyb3IgPSBlcnJubzsKIAkJd2FybigibWZpX29wZW4iKTsK LQkJcmV0dXJuIChlcnJubyk7CisJCXJldHVybiAoZXJyb3IpOwogCX0KIAogCWVycm9yID0gbWZp X2xvb2t1cF9kcml2ZShmZCwgYXZbMV0sICZkZXZpY2VfaWQpOwpAQCAtNTAyLDggKzUxNCw5IEBA CiAKIAkvKiBHZXQgdGhlIGluZm8gZm9yIHRoaXMgZHJpdmUuICovCiAJaWYgKG1maV9wZF9nZXRf aW5mbyhmZCwgZGV2aWNlX2lkLCAmaW5mbywgTlVMTCkgPCAwKSB7CisJCWVycm9yID0gZXJybm87 CiAJCXdhcm4oIkZhaWxlZCB0byBmZXRjaCBpbmZvIGZvciBkcml2ZSAldSIsIGRldmljZV9pZCk7 Ci0JCXJldHVybiAoZXJybm8pOworCQlyZXR1cm4gKGVycm9yKTsKIAl9CiAJY2xvc2UoZmQpOwog CkBAIC01NTEsOCArNTY0LDkgQEAKIAogCWZkID0gbWZpX29wZW4obWZpX3VuaXQpOwogCWlmIChm ZCA8IDApIHsKKwkJZXJyb3IgPSBlcnJubzsKIAkJd2FybigibWZpX29wZW4iKTsKLQkJcmV0dXJu IChlcnJubyk7CisJCXJldHVybiAoZXJyb3IpOwogCX0KIAogCWVycm9yID0gbWZpX2xvb2t1cF9k cml2ZShmZCwgYXZbMV0sICZkZXZpY2VfaWQpOwpAQCAtNTYxLDE2ICs1NzUsMTggQEAKIAogCS8q IEdldCB0aGUgaW5mbyBmb3IgdGhpcyBkcml2ZS4gKi8KIAlpZiAobWZpX3BkX2dldF9pbmZvKGZk LCBkZXZpY2VfaWQsICZpbmZvLCBOVUxMKSA8IDApIHsKKwkJZXJyb3IgPSBlcnJubzsKIAkJd2Fy bigiRmFpbGVkIHRvIGZldGNoIGluZm8gZm9yIGRyaXZlICV1IiwgZGV2aWNlX2lkKTsKLQkJcmV0 dXJuIChlcnJubyk7CisJCXJldHVybiAoZXJyb3IpOwogCX0KIAogCW1ib3hfc3RvcmVfcGRyZWYo Jm1ib3hbMF0sICZpbmZvLnJlZik7CiAJaWYgKG1maV9kY21kX2NvbW1hbmQoZmQsIG9wY29kZSwg TlVMTCwgMCwgbWJveCwgNCwgTlVMTCkgPCAwKSB7CisJCWVycm9yID0gZXJybm87CiAJCXdhcm4o IkZhaWxlZCB0byAlcyBjbGVhciBvbiBkcml2ZSAldSIsCiAJCSAgICBvcGNvZGUgPT0gTUZJX0RD TURfUERfQ0xFQVJfU1RBUlQgPyAic3RhcnQiIDogInN0b3AiLAogCQkgICAgZGV2aWNlX2lkKTsK LQkJcmV0dXJuIChlcnJubyk7CisJCXJldHVybiAoZXJyb3IpOwogCX0KIAogCWNsb3NlKGZkKTsK QEAgLTYwNCw4ICs2MjAsOSBAQAogCiAJZmQgPSBtZmlfb3BlbihtZmlfdW5pdCk7CiAJaWYgKGZk IDwgMCkgeworCQllcnJvciA9IGVycm5vOwogCQl3YXJuKCJtZmlfb3BlbiIpOwotCQlyZXR1cm4g KGVycm5vKTsKKwkJcmV0dXJuIChlcnJvcik7CiAJfQogCiAJZXJyb3IgPSBtZmlfbG9va3VwX2Ry aXZlKGZkLCBhdlsxXSwgJmRldmljZV9pZCk7CkBAIC02MTcsMTAgKzYzNCwxMSBAQAogCW1ib3hb Ml0gPSAwOwogCW1ib3hbM10gPSAwOwogCWlmIChtZmlfZGNtZF9jb21tYW5kKGZkLCBvcGNvZGUs IE5VTEwsIDAsIG1ib3gsIDQsIE5VTEwpIDwgMCkgeworCQllcnJvciA9IGVycm5vOwogCQl3YXJu KCJGYWlsZWQgdG8gJXMgbG9jYXRlIG9uIGRyaXZlICV1IiwKIAkJICAgIG9wY29kZSA9PSBNRklf RENNRF9QRF9MT0NBVEVfU1RBUlQgPyAic3RhcnQiIDogInN0b3AiLAogCQkgICAgZGV2aWNlX2lk KTsKLQkJcmV0dXJuIChlcnJubyk7CisJCXJldHVybiAoZXJyb3IpOwogCX0KIAljbG9zZShmZCk7 CiAKSW5kZXg6IHVzci5zYmluL21maXV0aWwvbWZpX2ZsYXNoLmMKPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gdXNy LnNiaW4vbWZpdXRpbC9tZmlfZmxhc2guYwkocmV2aXNpb24gMjE0MjYwKQorKysgdXNyLnNiaW4v bWZpdXRpbC9tZmlfZmxhc2guYwkod29ya2luZyBjb3B5KQpAQCAtNzIsMTYgKzcyLDE4IEBACiAJ ICAgIGZ3X3RpbWVfd2lkdGgsIGNvbXAtPmJ1aWxkX3RpbWUpOwogfQogCi1zdGF0aWMgdm9pZAor c3RhdGljIGludAogZGlzcGxheV9wZW5kaW5nX2Zpcm13YXJlKGludCBmZCkKIHsKIAlzdHJ1Y3Qg bWZpX2N0cmxfaW5mbyBpbmZvOwogCXN0cnVjdCBtZmlfaW5mb19jb21wb25lbnQgaGVhZGVyOwor CWludCBlcnJvcjsKIAl1X2ludCBpOwogCiAJaWYgKG1maV9jdHJsX2dldF9pbmZvKGZkLCAmaW5m bywgTlVMTCkgPCAwKSB7CisJCWVycm9yID0gZXJybm87CiAJCXdhcm4oIkZhaWxlZCB0byBnZXQg Y29udHJvbGxlciBpbmZvIik7Ci0JCXJldHVybjsKKwkJcmV0dXJuIChlcnJvcik7CiAJfQogCiAJ cHJpbnRmKCJtZmklZCBQZW5kaW5nIEZpcm13YXJlIEltYWdlczpcbiIsIG1maV91bml0KTsKQEAg LTk3LDYgKzk5LDggQEAKIAlkaXNwbGF5X2Zpcm13YXJlKCZoZWFkZXIpOwogCWZvciAoaSA9IDA7 IGkgPCBpbmZvLnBlbmRpbmdfaW1hZ2VfY29tcG9uZW50X2NvdW50OyBpKyspCiAJCWRpc3BsYXlf ZmlybXdhcmUoJmluZm8ucGVuZGluZ19pbWFnZV9jb21wb25lbnRbaV0pOworCisJcmV0dXJuICgw KTsKIH0KIAogc3RhdGljIHZvaWQKQEAgLTExNyw3ICsxMjEsNyBAQAogCXNpemVfdCBucmVhZDsK IAljaGFyICpidWY7CiAJc3RydWN0IHN0YXQgc2I7Ci0JaW50IGZkLCBmbGFzaDsKKwlpbnQgZXJy b3IsIGZkLCBmbGFzaDsKIAl1aW50OF90IG1ib3hbNF0sIHN0YXR1czsKIAogCWlmIChhYyAhPSAy KSB7CkBAIC0xMjcsMTMgKzEzMSwxNSBAQAogCiAJZmxhc2ggPSBvcGVuKGF2WzFdLCBPX1JET05M WSk7CiAJaWYgKGZsYXNoIDwgMCkgeworCQllcnJvciA9IGVycm5vOwogCQl3YXJuKCJmbGFzaDog RmFpbGVkIHRvIG9wZW4gJXMiLCBhdlsxXSk7Ci0JCXJldHVybiAoZXJybm8pOworCQlyZXR1cm4g KGVycm9yKTsKIAl9CiAKIAlpZiAoZnN0YXQoZmxhc2gsICZzYikgPCAwKSB7CisJCWVycm9yID0g ZXJybm87CiAJCXdhcm4oImZzdGF0KCVzKSIsIGF2WzFdKTsKLQkJcmV0dXJuIChlcnJubyk7CisJ CXJldHVybiAoZXJyb3IpOwogCX0KIAlpZiAoc2Iuc3Rfc2l6ZSAlIDEwMjQgIT0gMCB8fCBzYi5z dF9zaXplID4gMHg3ZmZmZmZmZikgewogCQl3YXJueCgiSW52YWxpZCBmbGFzaCBmaWxlIHNpemUi KTsKQEAgLTE0Miw4ICsxNDgsOSBAQAogCiAJZmQgPSBtZmlfb3BlbihtZmlfdW5pdCk7CiAJaWYg KGZkIDwgMCkgeworCQllcnJvciA9IGVycm5vOwogCQl3YXJuKCJtZmlfb3BlbiIpOwotCQlyZXR1 cm4gKGVycm5vKTsKKwkJcmV0dXJuIChlcnJvcik7CiAJfQogCiAJLyogRmlyc3QsIGFzayB0aGUg ZmlybXdhcmUgdG8gYWxsb2NhdGUgc3BhY2UgZm9yIHRoZSBmbGFzaCBmaWxlLiAqLwpAQCAtMTkw LDEwICsxOTcsMTAgQEAKIAkJcmV0dXJuIChFTlhJTyk7CiAJfQogCXByaW50ZigiZmluaXNoZWRc biIpOwotCWRpc3BsYXlfcGVuZGluZ19maXJtd2FyZShmZCk7CisJZXJyb3IgPSBkaXNwbGF5X3Bl bmRpbmdfZmlybXdhcmUoZmQpOwogCiAJY2xvc2UoZmQpOwogCi0JcmV0dXJuICgwKTsKKwlyZXR1 cm4gKGVycm9yKTsKIH0KIE1GSV9DT01NQU5EKHRvcCwgZmxhc2gsIGZsYXNoX2FkYXB0ZXIpOwpJ bmRleDogdXNyLnNiaW4vbWZpdXRpbC9tZmlfZXZ0LmMKPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gdXNyLnNiaW4v bWZpdXRpbC9tZmlfZXZ0LmMJKHJldmlzaW9uIDIxNDI2MCkKKysrIHVzci5zYmluL21maXV0aWwv bWZpX2V2dC5jCSh3b3JraW5nIGNvcHkpCkBAIC0zMiw3ICszMiw2IEBACiAjaW5jbHVkZSA8c3lz L3R5cGVzLmg+CiAjaW5jbHVkZSA8c3lzL2Vycm5vLmg+CiAjaW5jbHVkZSA8ZXJyLmg+Ci0vLyNp bmNsdWRlIDxsaWJ1dGlsLmg+CiAjaW5jbHVkZSA8c3RkaW8uaD4KICNpbmNsdWRlIDxzdGRsaWIu aD4KICNpbmNsdWRlIDxzdHJpbmdzLmg+CkBAIC02Nyw3ICs2Niw3IEBACiBzaG93X2xvZ3N0YXRl KGludCBhYywgY2hhciAqKmF2KQogewogCXN0cnVjdCBtZmlfZXZ0X2xvZ19zdGF0ZSBpbmZvOwot CWludCBmZDsKKwlpbnQgZXJyb3IsIGZkOwogCiAJaWYgKGFjICE9IDEpIHsKIAkJd2FybngoInNo b3cgbG9nc3RhdGU6IGV4dHJhIGFyZ3VtZW50cyIpOwpAQCAtNzYsMTMgKzc1LDE1IEBACiAKIAlm ZCA9IG1maV9vcGVuKG1maV91bml0KTsKIAlpZiAoZmQgPCAwKSB7CisJCWVycm9yID0gZXJybm87 CiAJCXdhcm4oIm1maV9vcGVuIik7Ci0JCXJldHVybiAoZXJybm8pOworCQlyZXR1cm4gKGVycm9y KTsKIAl9CiAKIAlpZiAobWZpX2V2ZW50X2dldF9pbmZvKGZkLCAmaW5mbywgTlVMTCkgPCAwKSB7 CisJCWVycm9yID0gZXJybm87CiAJCXdhcm4oIkZhaWxlZCB0byBnZXQgZXZlbnQgbG9nIGluZm8i KTsKLQkJcmV0dXJuIChlcnJubyk7CisJCXJldHVybiAoZXJyb3IpOwogCX0KIAogCXByaW50Zigi bWZpJWQgRXZlbnQgTG9nIFNlcXVlbmNlIE51bWJlcnM6XG4iLCBtZmlfdW5pdCk7CkBAIC01MzYs MTggKzUzNywyMCBAQAogCXNzaXplX3Qgc2l6ZTsKIAl1aW50MzJfdCBzZXEsIHN0YXJ0LCBzdG9w OwogCXVpbnQ4X3Qgc3RhdHVzOwotCWludCBjaCwgZmQsIG51bV9ldmVudHMsIHZlcmJvc2U7CisJ aW50IGNoLCBlcnJvciwgZmQsIG51bV9ldmVudHMsIHZlcmJvc2U7CiAJdV9pbnQgaTsKIAogCWZk ID0gbWZpX29wZW4obWZpX3VuaXQpOwogCWlmIChmZCA8IDApIHsKKwkJZXJyb3IgPSBlcnJubzsK IAkJd2FybigibWZpX29wZW4iKTsKLQkJcmV0dXJuIChlcnJubyk7CisJCXJldHVybiAoZXJyb3Ip OwogCX0KIAogCWlmIChtZmlfZXZlbnRfZ2V0X2luZm8oZmQsICZpbmZvLCBOVUxMKSA8IDApIHsK KwkJZXJyb3IgPSBlcnJubzsKIAkJd2FybigiRmFpbGVkIHRvIGdldCBldmVudCBsb2cgaW5mbyIp OwotCQlyZXR1cm4gKGVycm5vKTsKKwkJcmV0dXJuIChlcnJvcik7CiAJfQogCiAJLyogRGVmYXVs dCBzZXR0aW5ncy4gKi8KQEAgLTU2NSwxNCArNTY4LDE2IEBACiAJCXN3aXRjaCAoY2gpIHsKIAkJ Y2FzZSAnYyc6CiAJCQlpZiAocGFyc2VfY2xhc3Mob3B0YXJnLCAmZmlsdGVyLm1lbWJlcnMuY2xh c3MpIDwgMCkgeworCQkJCWVycm9yID0gZXJybm87CiAJCQkJd2FybigiRXJyb3IgcGFyc2luZyBl dmVudCBjbGFzcyIpOwotCQkJCXJldHVybiAoZXJybm8pOworCQkJCXJldHVybiAoZXJyb3IpOwog CQkJfQogCQkJYnJlYWs7CiAJCWNhc2UgJ2wnOgogCQkJaWYgKHBhcnNlX2xvY2FsZShvcHRhcmcs ICZmaWx0ZXIubWVtYmVycy5sb2NhbGUpIDwgMCkgeworCQkJCWVycm9yID0gZXJybm87CiAJCQkJ d2FybigiRXJyb3IgcGFyc2luZyBldmVudCBsb2NhbGUiKTsKLQkJCQlyZXR1cm4gKGVycm5vKTsK KwkJCQlyZXR1cm4gKGVycm9yKTsKIAkJCX0KIAkJCWJyZWFrOwogCQljYXNlICduJzoKQEAgLTYw OCwyMCArNjEzLDIzIEBACiAJCXJldHVybiAoRUlOVkFMKTsKIAl9CiAJaWYgKGFjID4gMCAmJiBw YXJzZV9zZXEoJmluZm8sIGF2WzBdLCAmc3RhcnQpIDwgMCkgeworCQllcnJvciA9IGVycm5vOwog CQl3YXJuKCJFcnJvciBwYXJzaW5nIHN0YXJ0aW5nIHNlcXVlbmNlIG51bWJlciIpOwotCQlyZXR1 cm4gKGVycm5vKTsKKwkJcmV0dXJuIChlcnJvcik7CiAJfQogCWlmIChhYyA+IDEgJiYgcGFyc2Vf c2VxKCZpbmZvLCBhdlsxXSwgJnN0b3ApIDwgMCkgeworCQllcnJvciA9IGVycm5vOwogCQl3YXJu KCJFcnJvciBwYXJzaW5nIGVuZGluZyBzZXF1ZW5jZSBudW1iZXIiKTsKLQkJcmV0dXJuIChlcnJu byk7CisJCXJldHVybiAoZXJyb3IpOwogCX0KIAogCWxpc3QgPSBtYWxsb2Moc2l6ZSk7CiAJZm9y IChzZXEgPSBzdGFydDs7KSB7CiAJCWlmIChtZmlfZ2V0X2V2ZW50cyhmZCwgbGlzdCwgbnVtX2V2 ZW50cywgZmlsdGVyLCBzZXEsCiAJCSAgICAmc3RhdHVzKSA8IDApIHsKKwkJCWVycm9yID0gZXJy bm87CiAJCQl3YXJuKCJGYWlsZWQgdG8gZmV0Y2ggZXZlbnRzIik7Ci0JCQlyZXR1cm4gKGVycm5v KTsKKwkJCXJldHVybiAoZXJyb3IpOwogCQl9CiAJCWlmIChzdGF0dXMgPT0gTUZJX1NUQVRfTk9U X0ZPVU5EKSB7CiAJCQlpZiAoc2VxID09IHN0YXJ0KQpJbmRleDogdXNyLnNiaW4vbWZpdXRpbC9t Zmlfc2hvdy5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT0KLS0tIHVzci5zYmluL21maXV0aWwvbWZpX3Nob3cuYwkocmV2 aXNpb24gMjE0MjYwKQorKysgdXNyLnNiaW4vbWZpdXRpbC9tZmlfc2hvdy5jCSh3b3JraW5nIGNv cHkpCkBAIC01NCw3ICs1NCw3IEBACiB7CiAJc3RydWN0IG1maV9jdHJsX2luZm8gaW5mbzsKIAlj aGFyIHN0cmlwZVs1XTsKLQlpbnQgZmQsIGNvbW1hOworCWludCBlcnJvciwgZmQsIGNvbW1hOwog CiAJaWYgKGFjICE9IDEpIHsKIAkJd2FybngoInNob3cgYWRhcHRlcjogZXh0cmEgYXJndW1lbnRz Iik7CkBAIC02MywxMyArNjMsMTUgQEAKIAogCWZkID0gbWZpX29wZW4obWZpX3VuaXQpOwogCWlm IChmZCA8IDApIHsKKwkJZXJyb3IgPSBlcnJubzsKIAkJd2FybigibWZpX29wZW4iKTsKLQkJcmV0 dXJuIChlcnJubyk7CisJCXJldHVybiAoZXJyb3IpOwogCX0KIAogCWlmIChtZmlfY3RybF9nZXRf aW5mbyhmZCwgJmluZm8sIE5VTEwpIDwgMCkgeworCQllcnJvciA9IGVycm5vOwogCQl3YXJuKCJG YWlsZWQgdG8gZ2V0IGNvbnRyb2xsZXIgaW5mbyIpOwotCQlyZXR1cm4gKGVycm5vKTsKKwkJcmV0 dXJuIChlcnJvcik7CiAJfQogCXByaW50ZigibWZpJWQgQWRhcHRlcjpcbiIsIG1maV91bml0KTsK IAlwcmludGYoIiAgICBQcm9kdWN0IE5hbWU6ICUuODBzXG4iLCBpbmZvLnByb2R1Y3RfbmFtZSk7 CkBAIC0xMzcsNyArMTM5LDcgQEAKIAlzdHJ1Y3QgbWZpX2JidV9jYXBhY2l0eV9pbmZvIGNhcDsK IAlzdHJ1Y3QgbWZpX2JidV9kZXNpZ25faW5mbyBkZXNpZ247CiAJdWludDhfdCBzdGF0dXM7Ci0J aW50IGZkOworCWludCBlcnJvciwgZmQ7CiAKIAlpZiAoYWMgIT0gMSkgewogCQl3YXJueCgic2hv dyBiYXR0ZXJ5OiBleHRyYSBhcmd1bWVudHMiKTsKQEAgLTE0Niw4ICsxNDgsOSBAQAogCiAJZmQg PSBtZmlfb3BlbihtZmlfdW5pdCk7CiAJaWYgKGZkIDwgMCkgeworCQllcnJvciA9IGVycm5vOwog CQl3YXJuKCJtZmlfb3BlbiIpOwotCQlyZXR1cm4gKGVycm5vKTsKKwkJcmV0dXJuIChlcnJvcik7 CiAJfQogCiAJaWYgKG1maV9kY21kX2NvbW1hbmQoZmQsIE1GSV9EQ01EX0JCVV9HRVRfQ0FQQUNJ VFlfSU5GTywgJmNhcCwKQEAgLTE1NiwxNCArMTU5LDE2IEBACiAJCQlwcmludGYoIm1maSVkOiBO byBiYXR0ZXJ5IHByZXNlbnRcbiIsIG1maV91bml0KTsKIAkJCXJldHVybiAoMCk7CiAJCX0KKwkJ ZXJyb3IgPSBlcnJubzsKIAkJd2FybigiRmFpbGVkIHRvIGdldCBjYXBhY2l0eSBpbmZvIik7Ci0J CXJldHVybiAoZXJybm8pOworCQlyZXR1cm4gKGVycm9yKTsKIAl9CiAKIAlpZiAobWZpX2RjbWRf Y29tbWFuZChmZCwgTUZJX0RDTURfQkJVX0dFVF9ERVNJR05fSU5GTywgJmRlc2lnbiwKIAkgICAg c2l6ZW9mKGRlc2lnbiksIE5VTEwsIDAsIE5VTEwpIDwgMCkgeworCQllcnJvciA9IGVycm5vOwog CQl3YXJuKCJGYWlsZWQgdG8gZ2V0IGRlc2lnbiBpbmZvIik7Ci0JCXJldHVybiAoZXJybm8pOwor CQlyZXR1cm4gKGVycm9yKTsKIAl9CiAKIAlwcmludGYoIm1maSVkOiBCYXR0ZXJ5IFN0YXRlOlxu IiwgbWZpX3VuaXQpOwpAQCAtMjQyLDcgKzI0Nyw3IEBACiAJc3RydWN0IG1maV9wZF9pbmZvIHBp bmZvOwogCXVpbnQxNl90IGRldmljZV9pZDsKIAljaGFyICpwOwotCWludCBmZCwgaSwgajsKKwlp bnQgZXJyb3IsIGZkLCBpLCBqOwogCiAJaWYgKGFjICE9IDEpIHsKIAkJd2FybngoInNob3cgY29u ZmlnOiBleHRyYSBhcmd1bWVudHMiKTsKQEAgLTI1MSwxNCArMjU2LDE2IEBACiAKIAlmZCA9IG1m aV9vcGVuKG1maV91bml0KTsKIAlpZiAoZmQgPCAwKSB7CisJCWVycm9yID0gZXJybm87CiAJCXdh cm4oIm1maV9vcGVuIik7Ci0JCXJldHVybiAoZXJybm8pOworCQlyZXR1cm4gKGVycm9yKTsKIAl9 CiAKIAkvKiBHZXQgdGhlIGNvbmZpZyBmcm9tIHRoZSBjb250cm9sbGVyLiAqLwogCWlmIChtZmlf Y29uZmlnX3JlYWQoZmQsICZjb25maWcpIDwgMCkgeworCQllcnJvciA9IGVycm5vOwogCQl3YXJu KCJGYWlsZWQgdG8gZ2V0IGNvbmZpZyIpOwotCQlyZXR1cm4gKGVycm5vKTsKKwkJcmV0dXJuIChl cnJvcik7CiAJfQogCiAJLyogRHVtcCBvdXQgdGhlIGNvbmZpZ3VyYXRpb24uICovCkBAIC0zMzcs OCArMzQ0LDggQEAKIHsKIAlzdHJ1Y3QgbWZpX2xkX2xpc3QgbGlzdDsKIAlzdHJ1Y3QgbWZpX2xk X2luZm8gaW5mbzsKKwlpbnQgZXJyb3IsIGZkOwogCXVfaW50IGksIGxlbiwgc3RhdGVfbGVuOwot CWludCBmZDsKIAogCWlmIChhYyAhPSAxKSB7CiAJCXdhcm54KCJzaG93IHZvbHVtZXM6IGV4dHJh IGFyZ3VtZW50cyIpOwpAQCAtMzQ3LDE0ICszNTQsMTYgQEAKIAogCWZkID0gbWZpX29wZW4obWZp X3VuaXQpOwogCWlmIChmZCA8IDApIHsKKwkJZXJyb3IgPSBlcnJubzsKIAkJd2FybigibWZpX29w ZW4iKTsKLQkJcmV0dXJuIChlcnJubyk7CisJCXJldHVybiAoZXJyb3IpOwogCX0KIAogCS8qIEdl dCB0aGUgbG9naWNhbCBkcml2ZSBsaXN0IGZyb20gdGhlIGNvbnRyb2xsZXIuICovCiAJaWYgKG1m aV9sZF9nZXRfbGlzdChmZCwgJmxpc3QsIE5VTEwpIDwgMCkgeworCQllcnJvciA9IGVycm5vOwog CQl3YXJuKCJGYWlsZWQgdG8gZ2V0IHZvbHVtZSBsaXN0Iik7Ci0JCXJldHVybiAoZXJybm8pOwor CQlyZXR1cm4gKGVycm9yKTsKIAl9CiAKIAkvKiBMaXN0IHRoZSB2b2x1bWVzLiAqLwpAQCAtMzc2 LDkgKzM4NSwxMCBAQAogCWZvciAoaSA9IDA7IGkgPCBsaXN0LmxkX2NvdW50OyBpKyspIHsKIAkJ aWYgKG1maV9sZF9nZXRfaW5mbyhmZCwgbGlzdC5sZF9saXN0W2ldLmxkLnYudGFyZ2V0X2lkLCAm aW5mbywKIAkJICAgIE5VTEwpIDwgMCkgeworCQkJZXJyb3IgPSBlcnJubzsKIAkJCXdhcm4oIkZh aWxlZCB0byBnZXQgaW5mbyBmb3Igdm9sdW1lICVkIiwKIAkJCSAgICBsaXN0LmxkX2xpc3RbaV0u bGQudi50YXJnZXRfaWQpOwotCQkJcmV0dXJuIChlcnJubyk7CisJCQlyZXR1cm4gKGVycm9yKTsK IAkJfQogCQlwcmludGYoIiU2cyAiLAogCQkgICAgbWZpX3ZvbHVtZV9uYW1lKGZkLCBsaXN0Lmxk X2xpc3RbaV0ubGQudi50YXJnZXRfaWQpKTsKQEAgLTQxNiw3ICs0MjYsNyBAQAogCXN0cnVjdCBt ZmlfcGRfbGlzdCAqbGlzdDsKIAlzdHJ1Y3QgbWZpX3BkX2luZm8gaW5mbzsKIAl1X2ludCBpLCBs ZW4sIHN0YXRlX2xlbjsKLQlpbnQgZmQ7CisJaW50IGVycm9yLCBmZDsKIAogCWlmIChhYyAhPSAx KSB7CiAJCXdhcm54KCJzaG93IGRyaXZlczogZXh0cmEgYXJndW1lbnRzIik7CkBAIC00MjUsMTMg KzQzNSwxNSBAQAogCiAJZmQgPSBtZmlfb3BlbihtZmlfdW5pdCk7CiAJaWYgKGZkIDwgMCkgewor CQllcnJvciA9IGVycm5vOwogCQl3YXJuKCJtZmlfb3BlbiIpOwotCQlyZXR1cm4gKGVycm5vKTsK KwkJcmV0dXJuIChlcnJvcik7CiAJfQogCiAJaWYgKG1maV9wZF9nZXRfbGlzdChmZCwgJmxpc3Qs IE5VTEwpIDwgMCkgeworCQllcnJvciA9IGVycm5vOwogCQl3YXJuKCJGYWlsZWQgdG8gZ2V0IGRy aXZlIGxpc3QiKTsKLQkJcmV0dXJuIChlcnJubyk7CisJCXJldHVybiAoZXJyb3IpOwogCX0KIAog CS8qIFdhbGsgdGhlIGxpc3Qgb2YgZHJpdmVzIHRvIGRldGVybWluZSB3aWR0aCBvZiBzdGF0ZSBj b2x1bW4uICovCkBAIC00NDIsOSArNDU0LDEwIEBACiAKIAkJaWYgKG1maV9wZF9nZXRfaW5mbyhm ZCwgbGlzdC0+YWRkcltpXS5kZXZpY2VfaWQsICZpbmZvLAogCQkgICAgTlVMTCkgPCAwKSB7CisJ CQllcnJvciA9IGVycm5vOwogCQkJd2FybigiRmFpbGVkIHRvIGZldGNoIGluZm8gZm9yIGRyaXZl ICV1IiwKIAkJCSAgICBsaXN0LT5hZGRyW2ldLmRldmljZV9pZCk7Ci0JCQlyZXR1cm4gKGVycm5v KTsKKwkJCXJldHVybiAoZXJyb3IpOwogCQl9CiAJCWxlbiA9IHN0cmxlbihtZmlfcGRzdGF0ZShp bmZvLmZ3X3N0YXRlKSk7CiAJCWlmIChsZW4gPiBzdGF0ZV9sZW4pCkBAIC00NjIsOSArNDc1LDEw IEBACiAJCS8qIEZldGNoIGRldGFpbHMgZm9yIHRoaXMgZHJpdmUuICovCiAJCWlmIChtZmlfcGRf Z2V0X2luZm8oZmQsIGxpc3QtPmFkZHJbaV0uZGV2aWNlX2lkLCAmaW5mbywKIAkJICAgIE5VTEwp IDwgMCkgeworCQkJZXJyb3IgPSBlcnJubzsKIAkJCXdhcm4oIkZhaWxlZCB0byBmZXRjaCBpbmZv IGZvciBkcml2ZSAldSIsCiAJCQkgICAgbGlzdC0+YWRkcltpXS5kZXZpY2VfaWQpOwotCQkJcmV0 dXJuIChlcnJubyk7CisJCQlyZXR1cm4gKGVycm9yKTsKIAkJfQogCiAJCXByaW50X3BkKCZpbmZv LCBzdGF0ZV9sZW4sIDEpOwpAQCAtNTExLDcgKzUyNSw3IEBACiB7CiAJc3RydWN0IG1maV9jdHJs X2luZm8gaW5mbzsKIAlzdHJ1Y3QgbWZpX2luZm9fY29tcG9uZW50IGhlYWRlcjsKLQlpbnQgZmQ7 CisJaW50IGVycm9yLCBmZDsKIAl1X2ludCBpOwogCiAJaWYgKGFjICE9IDEpIHsKQEAgLTUyMSwx MyArNTM1LDE1IEBACiAKIAlmZCA9IG1maV9vcGVuKG1maV91bml0KTsKIAlpZiAoZmQgPCAwKSB7 CisJCWVycm9yID0gZXJybm87CiAJCXdhcm4oIm1maV9vcGVuIik7Ci0JCXJldHVybiAoZXJybm8p OworCQlyZXR1cm4gKGVycm9yKTsKIAl9CiAKIAlpZiAobWZpX2N0cmxfZ2V0X2luZm8oZmQsICZp bmZvLCBOVUxMKSA8IDApIHsKKwkJZXJyb3IgPSBlcnJubzsKIAkJd2FybigiRmFpbGVkIHRvIGdl dCBjb250cm9sbGVyIGluZm8iKTsKLQkJcmV0dXJuIChlcnJubyk7CisJCXJldHVybiAoZXJyb3Ip OwogCX0KIAogCWlmIChpbmZvLnBhY2thZ2VfdmVyc2lvblswXSAhPSAnXDAnKQpJbmRleDogdXNy LnNiaW4vbWZpdXRpbC9tZmlfcGF0cm9sLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gdXNyLnNiaW4vbWZpdXRp bC9tZmlfcGF0cm9sLmMJKHJldmlzaW9uIDIxNDI2MCkKKysrIHVzci5zYmluL21maXV0aWwvbWZp X3BhdHJvbC5jCSh3b3JraW5nIGNvcHkpCkBAIC02MiwxMSArNjIsMTMgQEAKIHN0YXRpYyBpbnQK IHBhdHJvbF9nZXRfcHJvcHMoaW50IGZkLCBzdHJ1Y3QgbWZpX3ByX3Byb3BlcnRpZXMgKnByb3Ap CiB7CisJaW50IGVycm9yOwogCiAJaWYgKG1maV9kY21kX2NvbW1hbmQoZmQsIE1GSV9EQ01EX1BS X0dFVF9QUk9QRVJUSUVTLCBwcm9wLAogCSAgICBzaXplb2YoKnByb3ApLCBOVUxMLCAwLCBOVUxM KSA8IDApIHsKKwkJZXJyb3IgPSBlcnJubzsKIAkJd2FybigiRmFpbGVkIHRvIGdldCBwYXRyb2wg cmVhZCBwcm9wZXJ0aWVzIik7Ci0JCXJldHVybiAoLTEpOworCQlyZXR1cm4gKGVycm9yKTsKIAl9 CiAJcmV0dXJuICgwKTsKIH0KQEAgLTgxLDE5ICs4MywyMSBAQAogCWNoYXIgbGFiZWxbMTZdOwog CXRpbWVfdCBub3c7CiAJdWludDMyX3QgYXQ7Ci0JaW50IGZkOworCWludCBlcnJvciwgZmQ7CiAJ dV9pbnQgaTsKIAogCWZkID0gbWZpX29wZW4obWZpX3VuaXQpOwogCWlmIChmZCA8IDApIHsKKwkJ ZXJyb3IgPSBlcnJubzsKIAkJd2FybigibWZpX29wZW4iKTsKLQkJcmV0dXJuIChlcnJubyk7CisJ CXJldHVybiAoZXJyb3IpOwogCX0KIAogCXRpbWUoJm5vdyk7CiAJbWZpX2dldF90aW1lKGZkLCAm YXQpOwotCWlmIChwYXRyb2xfZ2V0X3Byb3BzKGZkLCAmcHJvcCkgPCAwKQotCQlyZXR1cm4gKGVy cm5vKTsKKwllcnJvciA9IHBhdHJvbF9nZXRfcHJvcHMoZmQsICZwcm9wKTsKKwlpZiAoZXJyb3Ip CisJCXJldHVybiAoZXJyb3IpOwogCXByaW50ZigiT3BlcmF0aW9uIE1vZGU6ICIpOwogCXN3aXRj aCAocHJvcC5vcF9tb2RlKSB7CiAJY2FzZSBNRklfUFJfT1BNT0RFX0FVVE86CkBAIC0xMjIsOCAr MTI2LDkgQEAKIAogCWlmIChtZmlfZGNtZF9jb21tYW5kKGZkLCBNRklfRENNRF9QUl9HRVRfU1RB VFVTLCAmc3RhdHVzLAogCSAgICBzaXplb2Yoc3RhdHVzKSwgTlVMTCwgMCwgTlVMTCkgPCAwKSB7 CisJCWVycm9yID0gZXJybm87CiAJCXdhcm4oIkZhaWxlZCB0byBnZXQgcGF0cm9sIHJlYWQgcHJv cGVydGllcyIpOwotCQlyZXR1cm4gKGVycm5vKTsKKwkJcmV0dXJuIChlcnJvcik7CiAJfQogCXBy aW50ZigiUnVucyBDb21wbGV0ZWQ6ICV1XG4iLCBzdGF0dXMubnVtX2l0ZXJhdGlvbik7CiAJcHJp bnRmKCJDdXJyZW50IFN0YXRlOiAiKTsKQEAgLTE0Niw4ICsxNTEsOSBAQAogCX0KIAlpZiAoc3Rh dHVzLnN0YXRlID09IE1GSV9QUl9TVEFURV9BQ1RJVkUpIHsKIAkJaWYgKG1maV9wZF9nZXRfbGlz dChmZCwgJmxpc3QsIE5VTEwpIDwgMCkgeworCQkJZXJyb3IgPSBlcnJubzsKIAkJCXdhcm4oIkZh aWxlZCB0byBnZXQgZHJpdmUgbGlzdCIpOwotCQkJcmV0dXJuIChlcnJubyk7CisJCQlyZXR1cm4g KGVycm9yKTsKIAkJfQogCiAJCWZvciAoaSA9IDA7IGkgPCBsaXN0LT5jb3VudDsgaSsrKSB7CkBA IC0xNTYsOSArMTYyLDEwIEBACiAKIAkJCWlmIChtZmlfcGRfZ2V0X2luZm8oZmQsIGxpc3QtPmFk ZHJbaV0uZGV2aWNlX2lkLCAmaW5mbywKIAkJCSAgICBOVUxMKSA8IDApIHsKKwkJCQllcnJvciA9 IGVycm5vOwogCQkJCXdhcm4oIkZhaWxlZCB0byBmZXRjaCBpbmZvIGZvciBkcml2ZSAldSIsCiAJ CQkJICAgIGxpc3QtPmFkZHJbaV0uZGV2aWNlX2lkKTsKLQkJCQlyZXR1cm4gKGVycm5vKTsKKwkJ CQlyZXR1cm4gKGVycm9yKTsKIAkJCX0KIAkJCWlmIChpbmZvLnByb2dfaW5mby5hY3RpdmUgJiBN RklfUERfUFJPR1JFU1NfUEFUUk9MKSB7CiAJCQkJc25wcmludGYobGFiZWwsIHNpemVvZihsYWJl bCksICIgICAgRHJpdmUgJXUiLApAQCAtMTc4LDE4ICsxODUsMjAgQEAKIHN0YXRpYyBpbnQKIHN0 YXJ0X3BhdHJvbChpbnQgYWMsIGNoYXIgKiphdikKIHsKLQlpbnQgZmQ7CisJaW50IGVycm9yLCBm ZDsKIAogCWZkID0gbWZpX29wZW4obWZpX3VuaXQpOwogCWlmIChmZCA8IDApIHsKKwkJZXJyb3Ig PSBlcnJubzsKIAkJd2FybigibWZpX29wZW4iKTsKLQkJcmV0dXJuIChlcnJubyk7CisJCXJldHVy biAoZXJyb3IpOwogCX0KIAogCWlmIChtZmlfZGNtZF9jb21tYW5kKGZkLCBNRklfRENNRF9QUl9T VEFSVCwgTlVMTCwgMCwgTlVMTCwgMCwgTlVMTCkgPAogCSAgICAwKSB7CisJCWVycm9yID0gZXJy bm87CiAJCXdhcm4oIkZhaWxlZCB0byBzdGFydCBwYXRyb2wgcmVhZCIpOwotCQlyZXR1cm4gKGVy cm5vKTsKKwkJcmV0dXJuIChlcnJvcik7CiAJfQogCiAJY2xvc2UoZmQpOwpAQCAtMjAxLDE4ICsy MTAsMjAgQEAKIHN0YXRpYyBpbnQKIHN0b3BfcGF0cm9sKGludCBhYywgY2hhciAqKmF2KQogewot CWludCBmZDsKKwlpbnQgZXJyb3IsIGZkOwogCiAJZmQgPSBtZmlfb3BlbihtZmlfdW5pdCk7CiAJ aWYgKGZkIDwgMCkgeworCQllcnJvciA9IGVycm5vOwogCQl3YXJuKCJtZmlfb3BlbiIpOwotCQly ZXR1cm4gKGVycm5vKTsKKwkJcmV0dXJuIChlcnJvcik7CiAJfQogCiAJaWYgKG1maV9kY21kX2Nv bW1hbmQoZmQsIE1GSV9EQ01EX1BSX1NUT1AsIE5VTEwsIDAsIE5VTEwsIDAsIE5VTEwpIDwKIAkg ICAgMCkgeworCQllcnJvciA9IGVycm5vOwogCQl3YXJuKCJGYWlsZWQgdG8gc3RvcCBwYXRyb2wg cmVhZCIpOwotCQlyZXR1cm4gKGVycm5vKTsKKwkJcmV0dXJuIChlcnJvcik7CiAJfQogCiAJY2xv c2UoZmQpOwpAQCAtMjI3LDEwICsyMzgsMTAgQEAKIAlzdHJ1Y3QgbWZpX3ByX3Byb3BlcnRpZXMg cHJvcDsKIAlsb25nIHZhbDsKIAl0aW1lX3Qgbm93OworCWludCBlcnJvciwgZmQ7CiAJdWludDMy X3QgYXQsIG5leHRfZXhlYywgZXhlY19mcmVxOwogCWNoYXIgKmNwOwogCXVpbnQ4X3Qgb3BfbW9k ZTsKLQlpbnQgZmQ7CiAKIAlleGVjX2ZyZXEgPSAwOwkvKiBHQ0MgdG9vIHN0dXBpZCAqLwogCW5l eHRfZXhlYyA9IDA7CkBAIC0yNzIsMTIgKzI4MywxNCBAQAogCiAJZmQgPSBtZmlfb3BlbihtZmlf dW5pdCk7CiAJaWYgKGZkIDwgMCkgeworCQllcnJvciA9IGVycm5vOwogCQl3YXJuKCJtZmlfb3Bl biIpOwotCQlyZXR1cm4gKGVycm5vKTsKKwkJcmV0dXJuIChlcnJvcik7CiAJfQogCi0JaWYgKHBh dHJvbF9nZXRfcHJvcHMoZmQsICZwcm9wKSA8IDApCi0JCXJldHVybiAoZXJybm8pOworCWVycm9y ID0gcGF0cm9sX2dldF9wcm9wcyhmZCwgJnByb3ApOworCWlmIChlcnJvcikKKwkJcmV0dXJuIChl cnJvcik7CiAJcHJvcC5vcF9tb2RlID0gb3BfbW9kZTsKIAlpZiAob3BfbW9kZSA9PSBNRklfUFJf T1BNT0RFX0FVVE8pIHsKIAkJaWYgKGFjID4gMikKQEAgLTI5NCw4ICszMDcsOSBAQAogCX0KIAlp ZiAobWZpX2RjbWRfY29tbWFuZChmZCwgTUZJX0RDTURfUFJfU0VUX1BST1BFUlRJRVMsICZwcm9w LAogCSAgICBzaXplb2YocHJvcCksIE5VTEwsIDAsIE5VTEwpIDwgMCkgeworCQllcnJvciA9IGVy cm5vOwogCQl3YXJuKCJGYWlsZWQgdG8gc2V0IHBhdHJvbCByZWFkIHByb3BlcnRpZXMiKTsKLQkJ cmV0dXJuIChlcnJubyk7CisJCXJldHVybiAoZXJyb3IpOwogCX0KIAogCWNsb3NlKGZkKTsK --00504502d357930c9b0493899b55-- From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 26 19:41: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 4C7FE106564A for ; Tue, 26 Oct 2010 19:41:30 +0000 (UTC) (envelope-from selphie.keller@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 E45498FC14 for ; Tue, 26 Oct 2010 19:41:29 +0000 (UTC) Received: by gwaa18 with SMTP id a18so2848265gwa.13 for ; Tue, 26 Oct 2010 12:41:29 -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 :content-transfer-encoding; bh=3wjGaiPkw1dTGnBEe8LHM8y5PmfvtLd2kqV1xd1GYFY=; b=EjAmkz/4doBsY6DXpKIuGnp6tUPX7wTpUq6ZSyO1X3pSO/IA0993BWnQ70x2/jsISW wAaOm6NBz/yT4RSzjDnq9n9rIlLksTdSNtNg4Bozf03aljk0d1KOPNSzHxHxr6yfdq/9 QRBzUfdFRwObgUl7XcCH/7y6kURD4y2p+ks4o= 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:content-transfer-encoding; b=i+Z1e5n2Ae0jInATlpf0IDbRw5A8TUXdUK0nSmvY3JTTMt8Ovs/ogwZc8O2v5bnEu3 o/bnG/TZRsKjSl9rTJd6UIuGUoUKgZNUzj5+yz6DkAljMAku1REmU9x/2oWhOPQAsggv b9nVduInKAqIRV6bzlTPSwMNLxVniN2sn+RIQ= MIME-Version: 1.0 Received: by 10.42.220.66 with SMTP id hx2mr968399icb.63.1288122088956; Tue, 26 Oct 2010 12:41:28 -0700 (PDT) Received: by 10.42.164.68 with HTTP; Tue, 26 Oct 2010 12:41:28 -0700 (PDT) In-Reply-To: <201010260931.36342.jhb@freebsd.org> References: <4CC6830A.10701@icyb.net.ua> <201010260931.36342.jhb@freebsd.org> Date: Tue, 26 Oct 2010 12:41:28 -0700 Message-ID: From: Selphie Keller To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Konstantin Belousov , Andriy Gapon , romanp@wuppy.net.ru Subject: Re: SYSCALL_MODULE() macro and modfind() issues X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 19:41:30 -0000 John, Yes, your approach is the optimal solution for making pmap work on both 8.1 and lower. I wonder if there is something similiar could be done to the modfind() function itself, but I understand that the goal of "sys/" prefix is to reduce the conflicts and for now can use functions like your pmap_find() to resolve the issue. Thanks John -Estella Mystagic (Selphie) static int pmap_find(void) { int modid; modid =3D modfind("pmap_helper"); if (modid =3D=3D -1) modid =3D modfind("sys/pmap_helper"); return (modid); } then in the original main() routine use this: if ((modid =3D pmap_find()) =3D=3D -1) { /* module not found, try to load */ modid =3D kldload("pmap_helper.ko"); if (modid =3D=3D -1) err(1, "unable to load pmap_helper module"); modid =3D pmap_find(); if (modid =3D=3D -1) err(1, "pmap_helper module loaded but not found"); } On Tue, Oct 26, 2010 at 6:31 AM, John Baldwin wrote: > On Tuesday, October 26, 2010 3:28:10 am Andriy Gapon wrote: >> on 26/10/2010 01:01 Selphie Keller said the following: >> > hi fbsd-hackers, >> > >> > Noticed a issue in 8.1-release, 8.1p1-release and 8.1-stable >> > amd64/i386, to where modfind() will no longer find pmap_helper for the >> > /usr/ports/sysutils/pmap port, or other syscall modules using >> > SYSCALL_MODULE() macro. >> > The issue is that modfind() function no longer finds any modules using >> > SYSCALL_MODULE() macro to register the kernel module. Making it >> > difficult for userland apps to call the syscall provided. modfind() >> > always returns -1 which prevents modstat() from getting the required >> > information to perform the syscall. >> > >> > Also tested, the demo syscall module: >> >> After commit r205320 and, apparently, its MFC you need to prefix the mod= ule with >> "sys/". =A0For example: >> modstat(modfind("sys/syscall"), &stat); >> >> P.S. >> Perhaps a KPI breakage in a stable branch? > > Ugh, it was a breakage though it's too late to back it out at this point. > > -- > John Baldwin > From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 26 21:36:18 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id D3FDB106566C; Tue, 26 Oct 2010 21:36:18 +0000 (UTC) Date: Tue, 26 Oct 2010 21:36:18 +0000 From: Alexander Best To: freebsd-hackers@freebsd.org Message-ID: <20101026213618.GA3013@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: fsync(2) manual and hdd write caching X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 21:36:18 -0000 hi there, since there's a thread on freebsd-questions@ concerning fsync(2) and the fact that hdd write caching can cause this syscall to basically be a no op, could somebody please copy the BUGS section from sync(2) to fsync(2)? cheers. alex -- a13x From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 26 21:43: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 6C0B4106566C for ; Tue, 26 Oct 2010 21:43:18 +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 1DFC08FC08 for ; Tue, 26 Oct 2010 21:43:17 +0000 (UTC) Received: from [192.168.45.11] (180-161.ftth.onsbrabantnet.nl [88.159.161.180]) (authenticated bits=0) by VM01.VEHosting.nl (8.14.3/8.13.8) with ESMTP id o9QLOHXr094421; Tue, 26 Oct 2010 23:24:17 +0200 (CEST) (envelope-from Daan@vehosting.nl) From: Daan Vreeken Organization: http://VEHosting.nl/ To: cronfy Date: Tue, 26 Oct 2010 23:24:12 +0200 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: <201010262324.13164.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: Tue, 26 Oct 2010 21:51:37 +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: Tue, 26 Oct 2010 21:43:18 -0000 Hi Cronfy, On Sunday 24 October 2010 15:15:53 cronfy wrote: > Hello, > > I have a web-server (nginx + apache + mysql, FreeBSD 7.3) with many > sites. Every night it creates a backup of /home on a separate disk. > /home is a RAID1 mirror on Adaptec 3405 (128M write cache) with SAS > drives; /backup is a single SATA drive on the same controller. > > Rsync creates backups using hardlinks, it stores 7 daily and 4 weekly > copies. Total amount of data is ~300G and 11M of files. The server is > under heavy web load every time (appox 100 queries/sec). > > 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. > > I think that problem can be caused by two reasons: > * either bulk of reads on SATA /backup drive, that fills OS > filesystem cache and many file access operations require real disk > read. > * or bulk of writes on /backup fills controller write cache and geom > disk operations queue grown, causing all disk operations to wait. > > This is only my assumption of course, I may be wrong. Try "gstat -a" to see which one it is. I guess you'll see bulk reads on /home and bulk reads on /backup mostly. When rsync starts, it will index the source and the destination directory structures using readdir() and stat() calls to see what files have changed (and need to be copied later on). rsync offers the "--bwlimit" option to lower the network bandwidth between an rsync server and a client, but this won't change the stress the stat() calls generate when rsync() indexes the directories. > How can I find a real reason of these slowdowns, to either conclude > that it is not possible to solve this because of hardware/software > limits, or tune my software/hardware system to make this all work at > an acceptable speed? You could try the patch below to rsync's "syscall.c" file, which will pause rsync for short periods of time every second to reduce the IO pressure it creates. Changing "500" to an even lower value, should almost linearly scale the 'busy' percentage "gstat -a" shows to even lower levels. --- syscall.c.org 2010-10-26 22:47:20.000000000 +0200 +++ syscall.c 2010-10-26 22:47:33.000000000 +0200 @@ -215,8 +215,19 @@ #endif } +void tiny_pause(void) +{ + struct timeval tv; + + // only work in the first half of every second. + gettimeofday(&tv, NULL); + if (tv.tv_usec > 500 * 1000) + usleep(1000 * 1000 - tv.tv_usec); +} + int do_stat(const char *fname, STRUCT_STAT *st) { + tiny_pause(); #ifdef USE_STAT64_FUNCS return stat64(fname, st); #else @@ -226,6 +237,7 @@ int do_lstat(const char *fname, STRUCT_STAT *st) { + tiny_pause(); #ifdef SUPPORT_LINKS # ifdef USE_STAT64_FUNCS return lstat64(fname, st); @@ -239,6 +251,7 @@ int do_fstat(int fd, STRUCT_STAT *st) { + tiny_pause(); #ifdef USE_STAT64_FUNCS return fstat64(fd, st); #else 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 Tue Oct 26 23:19: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 2B2521065674 for ; Tue, 26 Oct 2010 23:19:31 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id D6D508FC15 for ; Tue, 26 Oct 2010 23:19:30 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PAsne-0004MB-8g for freebsd-hackers@freebsd.org; Wed, 27 Oct 2010 01:19:26 +0200 Received: from 78-1-128-133.adsl.net.t-com.hr ([78.1.128.133]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 27 Oct 2010 01:19:26 +0200 Received: from ivoras by 78-1-128-133.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 27 Oct 2010 01:19:26 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Date: Wed, 27 Oct 2010 01:19:18 +0200 Lines: 17 Message-ID: References: <20101026213618.GA3013@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 78-1-128-133.adsl.net.t-com.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20101008 Thunderbird/3.1.4 In-Reply-To: <20101026213618.GA3013@freebsd.org> Subject: Re: fsync(2) manual and hdd write caching X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 23:19:31 -0000 On 10/26/10 23:36, Alexander Best wrote: > hi there, > > since there's a thread on freebsd-questions@ concerning fsync(2) and the fact > that hdd write caching can cause this syscall to basically be a no op, could > somebody please copy the BUGS section from sync(2) to fsync(2)? I don't think they are the same. The "buffers" of sync(2) are not those from the discussion on fsync(2) safety. Or more correctly, they are but those 2 calls work on a different scope. fsync(2) actually does behave as advertised, "auses all modified data and attributes of fd to be moved to a permanent storage device". It is the problem of the "permanent storage device" if it caches this data further. From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 26 23:28:56 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 BB14A106566B; Tue, 26 Oct 2010 23:28:56 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id 557558FC1D; Tue, 26 Oct 2010 23:28:56 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 9D016E801E; Wed, 27 Oct 2010 00:28:55 +0100 (BST) Received: from unknown (client-81-107-142-135.midd.adsl.virginmedia.com [81.107.142.135]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA; Wed, 27 Oct 2010 00:28:53 +0100 (BST) Date: Wed, 27 Oct 2010 00:28:49 +0100 From: Bruce Cran To: Ivan Voras Message-ID: <20101027002849.00002772@unknown> In-Reply-To: References: <20101026213618.GA3013@freebsd.org> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: fsync(2) manual and hdd write caching X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 23:28:56 -0000 On Wed, 27 Oct 2010 01:19:18 +0200 Ivan Voras wrote: > fsync(2) actually does behave as advertised, "auses all modified data > and attributes of fd to be moved to a permanent storage device". It > is the problem of the "permanent storage device" if it caches this > data further. http://www.opengroup.org/onlinepubs/009695399/functions/fsync.html at first suggests it should flush write caches, but does allow for implementations that don't: "The fsync() function is intended to force a physical write of data from the buffer cache, and to assure that after a system crash or other failure that all data up to the time of the fsync() call is recorded on the disk." ... "In the middle ground between these extremes, fsync() might or might not actually cause data to be written where it is safe from a power failure." -- Bruce Cran From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 26 23:32:35 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 4B6E11065670; Tue, 26 Oct 2010 23:32:35 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id 1199D8FC12; Tue, 26 Oct 2010 23:32:35 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 60BABE801E; Wed, 27 Oct 2010 00:32:34 +0100 (BST) Received: from unknown (client-81-107-142-135.midd.adsl.virginmedia.com [81.107.142.135]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA; Wed, 27 Oct 2010 00:32:33 +0100 (BST) Date: Wed, 27 Oct 2010 00:32:29 +0100 From: Bruce Cran To: Alexander Best Message-ID: <20101027003229.00002b91@unknown> In-Reply-To: <20101026213618.GA3013@freebsd.org> References: <20101026213618.GA3013@freebsd.org> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: fsync(2) manual and hdd write caching X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 23:32:35 -0000 On Tue, 26 Oct 2010 21:36:18 +0000 Alexander Best wrote: > since there's a thread on freebsd-questions@ concerning fsync(2) and > the fact that hdd write caching can cause this syscall to basically > be a no op, could somebody please copy the BUGS section from sync(2) > to fsync(2)? Shouldn't the BUGS section of sync(2) be removed? "The sync() system call may return before the buffers are completely flushed." But from http://www.opengroup.org/onlinepubs/009695399/functions/sync.html : "The writing, although scheduled, is not necessarily complete upon return from sync()." That would suggest it's not actually a bug. -- Bruce Cran From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 26 23:40:36 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 8F31F106566C; Tue, 26 Oct 2010 23:40:36 +0000 (UTC) Date: Tue, 26 Oct 2010 23:40:36 +0000 From: Alexander Best To: Bruce Cran Message-ID: <20101026234036.GA17347@freebsd.org> References: <20101026213618.GA3013@freebsd.org> <20101027003229.00002b91@unknown> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101027003229.00002b91@unknown> Cc: freebsd-hackers@freebsd.org Subject: Re: fsync(2) manual and hdd write caching X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 23:40:36 -0000 On Wed Oct 27 10, Bruce Cran wrote: > On Tue, 26 Oct 2010 21:36:18 +0000 > Alexander Best wrote: > > > since there's a thread on freebsd-questions@ concerning fsync(2) and > > the fact that hdd write caching can cause this syscall to basically > > be a no op, could somebody please copy the BUGS section from sync(2) > > to fsync(2)? > > Shouldn't the BUGS section of sync(2) be removed? > > "The sync() system call may return before the buffers are completely > flushed." > > But from > http://www.opengroup.org/onlinepubs/009695399/functions/sync.html : > > "The writing, although scheduled, is not necessarily complete upon > return from sync()." > > That would suggest it's not actually a bug. well...you are right on the one hand. but still this should be documented imo. how about turning BUGS into a CAVEATS section and then adding that section to fsync(2)? the reason posix mentions this sync/fsync behavior is probably the fact that they know that this cannot be avoided. so that statement seems itself to be a caveat rather than a feature. ;) cheers. alex > > -- > Bruce Cran -- a13x From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 27 00:02:10 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 C93A31065693; Wed, 27 Oct 2010 00:02:10 +0000 (UTC) (envelope-from danger@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9A9488FC21; Wed, 27 Oct 2010 00:02:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o9R02AUr028641; Wed, 27 Oct 2010 00:02:10 GMT (envelope-from danger@freefall.freebsd.org) Received: (from danger@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o9R02AnK028634; Wed, 27 Oct 2010 00:02:10 GMT (envelope-from danger) Date: Wed, 27 Oct 2010 00:02:10 +0000 From: Daniel Gerzo To: hackers@freebsd.org Message-ID: <20101027000210.GA18428@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.4.2.3i Cc: stable@freebsd.org, current@freebsd.org Subject: FreeBSD Status Report July - September, 2010 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: monthly@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 00:02:10 -0000 FreeBSD Quarterly Status Report Introduction This report covers FreeBSD-related projects between July and September 2010. It is the third of the four reports planned for 2010. During this period, we were victims of one of the biggest BSD events of the year -- EuroBSDCon. We hope that the ones of you who have been able to attend it have enjoyed your stay. Another good news is that work on the new minor versions of FreeBSD, 7.4 and 8.2, is progressing well. This report, with 55 entries, is the longest report in the whole history and shows a good condition of the FreeBSD community. Thanks to all the reporters for the excellent work! We hope you enjoy reading it. Please note that the deadline for submissions covering the period between October and December 2010 is January 15th, 2011. __________________________________________________________________ Google Summer of Code * Atheros AR913x SoC Support * Binary Package Patch Infrastructure -- pkg_patch * ExtFS Status Report * Packet Capturing Stack -- ringmap * Registration of Optional Kernel Subsystems via sysctl Projects * BSD# Project * BSNMP Enhancements * Capsicum: Practical Capabilities for UNIX * Clang Replacing GCC in the Base System * DAHDI/FreeBSD Project * External Toolchain Support * GELI Additions * gptboot Improvements * HAST (Highly Available Storage) Improvements * Kernel-level Stacked Cryptographic File System -- PEFS * pc-sysinstall * Target Big Endian Must Die * Userland DTrace * V4L Support in Linux Emulator * ZFSv28 is Ready for Wider Testing FreeBSD Team Reports * FreeBSD Bugbusting Team * FreeBSD KDE Team * FreeBSD Release Engineering Team * The FreeBSD Foundation Status Report Network Infrastructure * Enhancing the FreeBSD TCP Implementation * Five New TCP Congestion Control Algorithms for FreeBSD * Syncing pf(4) with OpenBSD 4.5 Kernel * Kernel Event Timers Infrastructure * Netdump Support * Resource Containers * USB Stack Documentation * mandoc/mdocml -- groff Replacement for Rendering Manual Pages in FreeBSD * The FreeBSD German Documentation Project * The FreeBSD Japanese Documentation Project * Web Feeds for UPDATING Files Userland Programs * FreeBSD Services Control (fsc) * Updating Base Tools to Accommodate Ports Requirements * xz Compression for Packages and Log Files Architectures * Bringing up ARM to FreeBSD Tree * FreeBSD on the Playstation 3 * FreeBSD/mips on Octeon * FreeBSD/mips Ralink RT3052F/Broadcom BCM5354 * FreeBSD/sparc64 Ports * Chromium Web Browser * OpenAFS Port * pkg_upgrade (sysutils/bsdadminscripts) * Ports Collection * Ports Distfile and WWW Checker * Valgrind Port Miscellaneous * BSD-Day@2010 * EuroBSDCon 2010 * EuroBSDCon 2011 * FreeBSD Developer Summit, Karlsruhe * FreeBSD Developer Summit, meetBSD California 2010 * PC-BSD __________________________________________________________________ Atheros AR913x SoC Support URL: http://wiki.FreeBSD.org/AdrianChadd/AtherosStuff URL: http://wiki.FreeBSD.org/AdrianChadd/AtherosHalStuff Contact: Adrian Chadd FreeBSD-CURRENT runs on the AR9132 SoC. Minor platform-specific tweaks are needed to use it on a given piece of hardware (eg., where in flash the Ethernet MAC address is stored.) The AR910x wireless MAC/PHY is supported. The only available test platform uses a 2.4GHz radio; 5GHz 11a mode has not been tested. As with other Atheros chipset support in FreeBSD, 11n support is not yet finished. The current development platform is the TP-Link TP-WN1043ND 802.11n wireless bridge/router. It is currently being successfully used as a 11bg access point. Open tasks: 1. USB support is currently not functional. 2. There is currently no support for the Realtek Gigabit switch/PHY chip. This is being worked on. __________________________________________________________________ Binary Package Patch Infrastructure -- pkg_patch URL: http://wiki.FreeBSD.org/IvanVoras/pkg_patch Contact: Ivan Voras pkg_patch is a tool meant to be used with the rest of the pkg_* utilities whose job is to create and apply binary patches to FreeBSD package archives. The SoC project was successfully completed but there are some open issues about the integration of the tool in the FreeBSD system. Some changes are necessary to the port/patch infrastructure to support the "update" mode instead of "remove+add". Open tasks: 1. Solve pending issues about the ports install/upgrade workflow, probably within the pkg_install2 effort. __________________________________________________________________ Bringing up ARM to FreeBSD Tree Contact: Warner Losh Contact: Mohammed Farrag We are still in the beginning of the project since we started it after the summer of code. Open tasks: 1. Reading ARM structure. 2. Reading MicroC OS. 3. Using Qemu to emulate the work. __________________________________________________________________ BSD# Project URL: http://code.google.com/p/bsd-sharp/ URL: http://www.mono-project.org/ Contact: Romain Tartičre The BSD# Project is devoted to porting the Mono .NET framework and applications to the FreeBSD operating system. Mono 2.8 has been released a few days ago and is already available in the BSD# repository. The update breaks a few ports so the lang/mono update in the FreeBSD ports tree will be delayed until those programs are fixed for a smoother update experience. Work is in progress to include some long-awaited ports such as deskutils/gnome-do but they require a lot of testing and hacking because they have clearly been designed to run on GNU/Linux and portability has never been a priority (which is quite amusing if you consider portability is the main reason to be for mono). Open tasks: 1. If you have some time, test mono ports and send feedback. 2. If you have more time, join the BSD# Team! There are many ways to help out! 3. Currently low priority, some mono hackers who do not use FreeBSD would be interested in a debug live-image of FreeBSD to help us diagnose and fix bugs more effectively. __________________________________________________________________ BSD-Day@2010 URL: http://wiki.FreeBSD.org/BSDDay_2010 Contact: Gábor Páli The purpose of this one-day event is to gather Central European developers of today's open-source BSD systems to popularize their work and their organizations, and to meet each other in the real life. We would also like to motivate potential future developers and users, especially undergraduate university students to work with BSD systems. This year's BSD-Day will be held in Budapest, Hungary at Eötvös Loránd University, Faculty of Informatics on November 20, 2010. Everybody is welcome! __________________________________________________________________ BSNMP Enhancements URL: http://wiki.FreeBSD.org/CategorySNMP URL: http://p4db.FreeBSD.org/depotTreeBrowser.cgi?FSPC=//depot/user/syrinx/s nmp_ieee80211&HIDEDEL=NO URL: http://p4db.FreeBSD.org/depotTreeBrowser.cgi?FSPC=//depot/user/syrinx/s yrinx_bsnmpv3&HIDEDEL=NO Contact: Shteryana Shopova Contact: Philip Paeps During the previous few months several additions were developed to FreeBSD's built-in SNMP daemon -- bsnmpd(1). First a snmp_wlan(3) module was developed that allows monitoring and configuration of wlan(4) interfaces operating in various modes, including statistics, attached/neighboring station information, MAC access control entries and mesh routing information. The module's code was submitted in SVN and is now a part of the FreeBSD base system. Next, SNMPv3 authentication and encryption support were added to bsnmplib(3), bsnmpd(1) and bsnmptools (which are available via the ports system currently). The message digest and cipher calculation calls use the implementation of the relevant cryptographic algorithm implementation in OpenSSL's crypto(3) library. bsnmpd(1) may still optionally be compiled without the crypto(3) library, in which case only unauthenticated plain-text SNMPv3 PDUs may be processed. In addition, a snmp_usm(3) module was developed that is used to configure SNMPv3 users parameters (name, authentication & encryption algorithms used and relevant keys, etc.) into bsnmpd(1) as per RFC 3414. Finally, a snmp_vacm(3) module was developed that allows configuration of view-based access control as per RFC 3415, and relevant checks are made by bsnmpd(1) that allow or restrict access to specific SNMPv1/SNMPv2 communities or SNMPv3 users to certain MIB subtrees as per the configuration in the snmp_vacm(3) module. If none of the SNMPv3-related modules is loaded, bsnmpd(1) preserves its current behavior with SNMPv1/SNMPv2c PDUs. This work is being funded by the FreeBSD Foundation. Open tasks: 1. Update Wiki Page to reflect latest work and document proper use. 2. Finish cleanup and have it reviewed. 3. More extensive user testing. __________________________________________________________________ Capsicum: Practical Capabilities for UNIX URL: http://www.cl.cam.ac.uk/research/security/capsicum/ URL: https://lists.cam.ac.uk/mailman/listinfo/cl-capsicum-discuss URL: http://www.cl.cam.ac.uk/research/security/capsicum/papers/2010usenix-se curity-capsicum-website.pdf Contact: Robert Watson Contact: Jonathan Anderson Contact: Ben Laurie Contact: Kris Kennaway Capsicum is a lightweight OS capability and sandbox framework developed at the University of Cambridge Computer Laboratory, supported by a grant from Google. Capsicum extends the POSIX API, providing several new OS primitives to support object-capability security on UNIX-like operating systems: capabilities, a new sandboxed capability mode for processes, anonymous shared memory objects, process descriptors, and a modified C runtime able to support distributed applications within sandboxes. Capsicum has been prototyped on FreeBSD -CURRENT, with a 8-STABLE backport. Capsicum is intended to supplement existing system-centric mandatory access control protections by providing an application-centric protection model, which better supports compartmentalised user programs that set up one (or many) sandboxes to process untrustworthy data in. A number of applications, from tcpdump to the Chromium web browser, have been modified to use sandboxing to confine risky activities such as the parsing of untrusted packets and HTML/JavaScript rendering. We plan to begin merging the core Capsicum kernel features to FreeBSD -CURRENT in November/December 2010 once a number of known problems have been resolved. Following a KBI analysis, we will consider merging our 8-STABLE backport to Subversion. For the time being, and while APIs stabilise, we plan to distribute the Capsicum libraries via ports. However, simply having the kernel features in place is sufficient to support sandboxing in tcpdump and Chromium. The Capsicum paper by Robert Watson / Jonathan Anderson (Cambridge) and Ben Laurie / Kris Kennaway (Google) won a best paper award at the 2010 USENIX Security Symposium! Open tasks: 1. More aggressively test (and as needed, fix) possible UNIX domain socket garbage collector interactions with Capsicum. 2. Using results of our recent model checking analysis of the namei() sandboxing approach, make robustness improvements. 3. Merge to FreeBSD -CURRENT in November/December. 4. KBI analysis for possible 8-STABLE merge. 5. Convert more applications to use Capsicum sandboxing! __________________________________________________________________ Chromium Web Browser URL: http://chromium.hybridsource.org URL: http://chromium.hybridsource.org/issues Contact: Ruben Chromium is a Webkit-based web browser that is largely BSD licensed and was recently committed to ports. It has been working well on FreeBSD and supports new features like HTML 5 video. Newer builds use the Clang compiler, Clang first compiled a non-debug build of Chromium, a very large C++ project, on FreeBSD. This porting effort employs a new hybrid-source model: portions of the latest FreeBSD patches are kept closed for a limited time and new builds are made available only to paying subscribers, while older builds are eventually spun off to ports. Further work remains to port all of Chromium to FreeBSD, I am now porting the task manager to use FreeBSD's libkvm and the ALSA audio backend needs to be ported to OSS. There are other issues listed at the porting summary, contact me if you would like to pitch in. __________________________________________________________________ Clang Replacing GCC in the Base System URL: http://wiki.FreeBSD.org/BuildingFreeBSDWithClang Contact: Ed Schouten Contact: Roman Divacky Contact: Brooks Davis Contact: Pawel Worach Contact: Dimitry Andric We recently imported the 2.8 release of Clang into -CURRENT. This release contains many new features and improvements. The integrated assembler ships with this version, but it is not ready for general use yet. Since r212979, all necessary changes have been committed to be able to build world with Clang, at least on amd64 and i386. It can also be installed and run, and we are now starting the process of shaking out the inevitable bugs. Because LLVM and Clang are still being improved continuously, we want to import new versions regularly, approximately every two months, to gain access to new features, bug fixes and performance improvements. There is also an effort on behalf of the ports people, to make as many ports as possible compile and run properly with Clang. Most of the time, this means fixing the incorrect assumption that gcc is the only existing compiler, but sometimes more complicated issues pop up. Help in this area is greatly appreciated. Open tasks: 1. Importing new Clang snapshots fairly regularly (approximately bi-monthly). 2. Seeing if Clang can be used to build world for ARM (volunteers and ARM experts wanted). 3. Fixing as many ports as possible to build with Clang. 4. Running periodical ports exp builds with Clang (on amd64 and i386), for example once a month. __________________________________________________________________ DAHDI/FreeBSD Project URL: http://www.asterisk.org/dahdi/ URL: http://svn.digium.com/svn/dahdi/freebsd/ URL: https://spreadsheets.google.com/pub?key=0Arw6eRL10yIwdGhLdGJWUHF4b3ExQz Bsd3BGd2tublE&hl=en&single=true&gid=0&output=html Contact: Max Khon The purpose of DAHDI/FreeBSD project is to make it possible to use FreeBSD as a base system for software PBX solutions. DAHDI (Digium/Asterisk Hardware Device Interface) is an open-source device driver framework and a set of hardware drivers for E1/T1, ISDN digital, and FXO/FXS analog cards [1]. Asterisk is one of the most popular open-source software PBX solutions [2]. The project includes porting DAHDI framework and hardware drivers for E1/T1, FXO/FXS analog, and ISDN digital cards to FreeBSD. This also includes TDMoE support, software and hardware echo cancellation (Octasic, VPMADT032), and hardware transcoding support (TC400B). The work is ongoing in the official DAHDI SVN repository with the close collaboration with DAHDI folks at Digium. DAHDI/FreeBSD project is completed. ports/misc/dahdi now contains the most recent DAHDI/FreeBSD version and additional stuff that is not available in DAHDI/FreeBSD SVN repository due to licensing and copyright restrictions (OSLEC echo canceler, experimental zaphfc driver). Experimental sparc64 support is also implemented and is currently being tested. There is a pile of minor changes in queue that will be handled soon: * Add ability to run asterisk+dahdi under non-root user account. * Add support for bri_net_ptmp ISDN signalling to asterisk port and drop old and outdated zaptel+asterisk-bristuff ports. Periodic merges from DAHDI/Linux SVN will be continued on a regular basis with rolling out new DAHDI/FreeBSD releases (most likely synchronized with DAHDI/Linux releases). __________________________________________________________________ Enhancing the FreeBSD TCP Implementation URL: http://caia.swin.edu.au/freebsd/etcp09/ URL: http://caia.swin.edu.au/urp/newtcp/ URL: http://www.FreeBSDFoundation.org/projects.shtml URL: http://people.FreeBSD.org/~lstewart/patches/tcp_ffcaia2008/ Contact: Lawrence Stewart All outstanding patches have been committed to -CURRENT after a lengthy review process. It is anticpated to merge all of the project's SIFTR and reassembly queue-related patches from -CURRENT to the stable branches in time for the upcoming 7.4 and 8.2 releases. __________________________________________________________________ EuroBSDCon 2010 URL: http://2010.EuroBSDCon.org/ URL: http://2011.EuroBSDCon.org/ Contact: Wolfgang Zenker Contact: Gábor Páli EuroBSDCon 2010 happened in Karlsruhe, Germany, with many users, developers, friends, and others. We had many tutorials, and 22 interesting presentations on various topics connected to FreeBSD, OpenBSD, NetBSD, like the new USB stack, jail improvements, Virtual Private Systems, SSH and PGP convergence, ZFS, journaled Soft-Updates, BSD certification, porting to the latest ARM processors, and pc-sysinstall. The event was opened by a keynote speech from Poul-Henning Kamp on software tools and their future, and it was closed by short status reports on different BSD flavors. __________________________________________________________________ EuroBSDCon 2011 URL: http://2011.eurobsdcon.org/ URL: http://2011.eurobsdcon.org/CfP.html Contact: Philip Paeps EuroBSDCon is the European technical conference for users and developers on BSD based systems. The EuroBSDCon 2011 conference will be held in the Netherlands from Thursday 6 October 2011 to Sunday 9 October 2011, with tutorials on Thursday and Friday and talks on Saturday and Sunday. The EuroBSDCon conference is inviting developers and users of BSD based systems to submit innovative and original papers not submitted to other European conferences on BSD-related topics. Please see the EuroBSDCon 2011 website for more details. __________________________________________________________________ External Toolchain Support Contact: Warner Losh One problem that the project has with its push towards embedded platforms is with the toolchain. The compilers and linkers and such in the current FreeBSD support the architectures generically, but often times silicon vendors produce specialized toolchains to wring the most performance out of their silicon. Right now, it is difficult to compile FreeBSD with these tools, as many manual steps are required to make things 'just so'. The external toolchain project will leverage some of the work done by the Clang team to support Clang in the base system (breaking the strict dependency on CC=cc (except for the broken intel CC support)). In addition, the orchestration of the build (make buildworld) will change to avoid bootstrapping certain tools, or compiling the compilers at all. In addition, support for using alternate assemblers, linkers, etc., will be added. The work will be done in subversion in projects/xtc (for eXternal Tool Chain). __________________________________________________________________ ExtFS Status Report URL: http://wiki.FreeBSD.org/SOC2010ZhengLiu URL: http://p4web.FreeBSD.org/@md=d&cd=//depot/projects/soc2010/extfs/src/sy s/fs/&c=rFV@//depot/projects/soc2010/extfs/src/sys/fs/ext2fs/?ac=83 URL: http://p4web.FreeBSD.org/@md=d&cd=//depot/projects/soc2010/ext4fs/src/s ys/fs/&c=cc4@//depot/projects/soc2010/ext4fs/src/sys/fs/ext4fs/?ac=83 Contact: Zheng Liu This project has two goals: pre-allocation algorithm for ext2fs and ext4 read-only mode. Aim of the pre-allocation algorithm is to implement a reservation window mechanism. This mechanism has been implemented and a patch have been submitted. The aim of ext4 read-only mode is to make it possible to read ext4 file systems in read-only mode when the disk is formatted with default features. Until now it can read data from ext4 file systems with default features in read-only mode. A patch has been submitted a patch to the freebsd-fs mailing list and there is a new kernel module, called ext4fs, is under development for it. Open tasks: 1. More testing of the pre-allocation algorithm. __________________________________________________________________ Five New TCP Congestion Control Algorithms for FreeBSD URL: http://caia.swin.edu.au/freebsd/5cc/ URL: http://caia.swin.edu.au/urp/newtcp/ URL: http://www.FreeBSDFoundation.org/projects.shtml URL: http://people.FreeBSD.org/~lstewart/patches/5cc/ Contact: David Hayes Contact: Lawrence Stewart Contact: Grenville Armitage Contact: Rui Paulo Work has commenced on a newly funded FreeBSD Foundation project to bring six modular TCP congestion control (CC) algorithm implementations (the existing NewReno and five new algorithms: HTCP, CUBIC, Vegas, HD and CHD) to the FreeBSD kernel. See the CAIA 5cc and NewTCP websites for more details on the algorithms. To support the project's primary deliverable, we will also be incorporating the CAIA modular CC and Khelp frameworks into the FreeBSD kernel, along with the Enhanced Round Trip Time Khelp module. The project will make a sizable, state-of-the-art contribution to FreeBSD and in certain areas, add completely novel work unavailable in any other operating system known to us. We anticipate a number of benefits, including vastly improved researcher friendliness, reduced work for TCP oriented vendors of FreeBSD-based appliances, and greater choice for system administrators who operate FreeBSD systems in atypical network scenarios. Keep an eye on the freebsd-net mailing list for project-related announcements. __________________________________________________________________ FreeBSD Bugbusting Team URL: http://www.FreeBSD.org/support.html#gnats URL: http://wiki.FreeBSD.org/BugBusting URL: http://people.FreeBSD.org/~linimon/studies/prs/ Contact: Gavin Atkinson Contact: Mark Linimon Contact: Remko Lodder Contact: Volker Werth The bugbusting team continue work on trying to make the contents of the GNATS PR database cleaner, more accessible and easier for committers to find and resolve PRs, by tagging PRs to indicate the areas involved, and by ensuring that there is sufficient info within each PR to resolve each issue. July saw the addition of Alexander Best (arundel@) to this bugbusting team, he is helping with the triaging PRs as they come in, creating patches for problems and working with submitters to get the solutions tested, and working through the PR backlog. Also in July, Gavin Atkinson worked with Hans Petter Selasky on the USB PRs, attempting to go through many of them and determine the status of each of them. As a result, nearly 10% of the USB PRs were determined to be closeable, with many more either being marked as patched already or able to be committed quickly. Several PRs that only affect the old (pre-8.0) USB stack were also identified and marked as such. More work will take place in this area in the future. August saw us host another bugathon, with an aim of investigating and getting into a committable state several of the PRs with patches. Turnout was not as great as in the past -- mainly believed to be die to the short notice, but still several PRs were progressed, with several commits made and several PRs closed. The number of PRs has held steady over the last three months, with improvements in numbers in some categories (especially usb and bin) being offset by slight increases in others. Reports continue to be produced from the PR database, all of which can be found from the links above. Committers interested in custom reports are encouraged to discuss requirements with bugmeister@ -- we are happy to create new reports where needs are identified. As always, anybody interested in helping out with the PR queue is welcome to join us in #freebsd-bugbusters on EFnet. We are always looking for additional help, whether your interests lie in triaging incoming PRs, generating patches to resolve existing problems, or simply helping with the database housekeeping (identifying duplicate PRs, ones that have already been resolved, etc). This is a great way of getting more involved with FreeBSD! Open tasks: 1. Try to find ways to get more committers helping us with closing PRs that the team has already analyzed. 2. Try to get more non-committers involved with the triaging of PRs as they come in, and generating patches to fix reported problems. __________________________________________________________________ FreeBSD Developer Summit, Karlsruhe URL: http://wiki.FreeBSD.org/201010DevSummit Contact: Gábor Páli We were happy to have more than 40 FreeBSD developers and guests attending the FreeBSD Developer Summit prior to EuroBSDCon 2010 in Karlsruhe, Germany. This workshop-style event was hosted at Karlsruhe Institute of Technology, and included prepared presentations in the morning, as well as group hacking and discussion sections in the afternoon. We had various talks on several topics, covering the USB subsystem, state of the toolchain, the FreeBSD documentation, NanoBSD improvements, FreeBSD port of PF, jails, Virtual Private Systems, cooperation with the PC-BSD Project, FreeNAS, the new event timers subsystems, bugbusting discussions and Ports Tinderbox presentations, and many of this year's and last year's Google Summer of Code projects. Photos, videos, and slides for most of the talks are available on the wiki page. __________________________________________________________________ FreeBSD Developer Summit, meetBSD California 2010 URL: http://wiki.FreeBSD.org/201011DevSummit Contact: Warner Losh We will be having a developers summit meeting at meetBSD California 2010 on November 4th, the day before the conference. Based on who is in attendance, we will be talking about the status of pressing issues; working on pressing problems and using the opportunity for face to face meetings to work out issues that are difficult in email. This is an invitation-only event, but any developer can invite people they think would help drive this meeting forward. An agenda will be published closer to the date. __________________________________________________________________ FreeBSD KDE Team URL: http://FreeBSD.kde.org Contact: FreeBSD KDE Team Contact: Thomas Abthorpe Contact: Max Brazhnikov Contact: Kris Moore Contact: Dima Panov Contact: Alberto Villa The FreeBSD KDE team has been actively keeping pace with development cycle as it is released by the KDE developers. Often having KDE in the ports tree within the same week it has been released. An integral part of maintaining KDE exists in supporting the Qt toolchain. As Nokia releases Qt, our team is keeping pace making it available in our development repository. We are fortunate to have a strong contributor base that helps to keep the process moving along. Our heartfelt thanks go out to all that have helped with patches, maintaining ports, and responding with help on the mailing lists. Open tasks: 1. KDE 4.5.4 is due out at the end of November, with 4.6.0 to be released early in 2011. 2. The FreeBSD KDE team is always looking for helpers, if you are interested in assisting, please feel free to contact any of our team members. __________________________________________________________________ FreeBSD on the Playstation 3 URL: svn://svn.FreeBSD.org/base/user/nwhitehorn/ps3 URL: http://people.FreeBSD.org/~nwhitehorn/ps3 Contact: Nathan Whitehorn Contact: Peter Grehan FreeBSD/powerpc64 now boots multi-user SMP and is self-hosting on the Playstation 3. Booting requires a PS3 console with the OtherOS capability (fat model console with firmware < 3.21). The only supported hardware at present is USB and the Ethernet controller. Open tasks: 1. SATA support. 2. Boot loader enhancements to allow user input at the loader prompt. 3. Support for the Cell SPU units. __________________________________________________________________ FreeBSD Release Engineering Team URL: http://www.FreeBSD.org/releng/ Contact: Release Engineering Team The Release Engineering Team has announced the schedule for the upcoming joint release of FreeBSD 7.4 and 8.2. The schedules are available on the web site: * 7.4-RELEASE schedule * 8.2-RELEASE schedule It is expected that 7.4 will be the last of the 7.X releases. __________________________________________________________________ FreeBSD Services Control (fsc) URL: http://people.FreeBSD.org/~trhodes/fsc/ Contact: Tom Rhodes FreeBSD Services Control is a mix of binaries which integrate into the rc.d system and provide for service (daemon) monitoring. It knows about signals, pidfiles, and uses very little resources. The fsc daemon (fscd) runs in the background once the system has started. Services are then added to this daemon via the fscadm control utility and from there they will be monitored. When they die, depending on the reason, they will be restarted. Certain signals may be ignored (list not decided), and fscd will remove that service from monitoring. Every action is logged to the system logging daemon. Additionally, the fscadm utility may be used to inquire about what services are monitored, their pidfile location, and current process id. FSC provides several advantages over the third-party daemontools package. For example, fscd uses push notifications instead of polling; fscd is an internal, FreeBSD-maintained software package accessible to all developers where daemontools would have to be a port and require us to maintain patches; fscd could be easily integrated with the current rc.d infrastructure. Partially based on the ideas of daemontools and Solaris Service Management Facility (SMF), this could be an extremely useful tool for FreeBSD systems. Since the last status report, two bugs have been fixed and the documentation has been updated. In the coming weeks we hope to get more developer attention and review, perhaps even push to commit the code into FreeBSD. Open tasks: 1. Testing and feedback would be really helpful. __________________________________________________________________ FreeBSD/mips on Octeon URL: http://wiki.FreeBSD.org/FreeBSD/mips/Octeon Contact: Juli Mallett All Octeon development is now ongoing in -CURRENT and most Octeon-specific and general MIPS changes from the old Octeon branch have been checked in. The Simple Executive from the Cavium Octeon SDK has been checked into Subversion and most of the Octeon port has been updated to use it where appropriate, including moving to a port of the Linux Ethernet driver, octe. SMP support is stable on 2-core systems and has seen some testing on systems with up to 16 cores. Open tasks: 1. Some PCI devices still do not seem to work completely. 2. Host-mode USB support is incomplete and needs further testing and debugging. 3. Work on an ATA-based Compact Flash driver for boards that support DMA has begun. 4. A GPIO driver should be trivial using the Simple Executive. 5. Performance in the Linux-derived octe Ethernet driver could be improved. Support for some switch chipsets that are commonly present in Octeon-based equipment is in progress. __________________________________________________________________ FreeBSD/mips Ralink RT3052F/Broadcom BCM5354 URL: http://wiki.ddteam.net/wiki.cgi?page=DIR-320+FreeBSD URL: http://my.ddteam.net/hg/BASE/ Contact: Aleksandr Rybalko FreeBSD/mips has been ported to D-Link DAP-1350, wireless AP/router based on Ralink RT3052F SoC. Drivers status: * rt2860: Ralink RT2860 802.11n -- Worked, but RT3022 2.4G 2T2R radio tuning required. * rt: Ralink RT3052F onChip Ethernet MAC -- Done. * rtsw: OnChip Ethernet switch -- Not done (initialized by UBoot). * usb-otg: DWC like USB OTG controller -- Worked. * gpio: RT3052F onChip GPIO -- Worked (LEDs, Buttons). * cfi: CFI NOR Flash -- Worked. FreeBSD/mips D-Link DIR-320 project(BCM5354 SoC). New profile openvpn-router available for testing. Open tasks: 1. Debug/Fix USB OTG driver (RT3052F). 2. Debug/Fix 802.11n driver (RT3052F). 3. Write rtswitch driver (RT3052F). 4. Implement Timer unit driver (RT3052F). 5. Implement Hardware NAT/PPPoE/VLAN offload (RT3052F). 6. Implement I2C/I2S/PCM/SPI drivers (RT3052F). 7. switch configuration utility (BCM5354). __________________________________________________________________ FreeBSD/sparc64 Contact: Marius Strobl Apart from the constant bug fixing and adaptions to machine-independent changes that pretty much always take place, not much has happened in the area of sparc64 since the last status report. The only noteworthy exception are some performance optimizations which take advantage of features of Fujitsu SPARC64 CPUs. These were a bit too risky for putting them in shortly before FreeBSD 8.1-RELEASE but will be part of 7.4-RELEASE and 8.2-RELEASE now that they have received the necessary testing. Part of reasons why not much has happened in this spot was some lack of time on my side but also due to nobody showing up with a not yet supported sun4u machine lately and me delving in the network land instead, which yielded some things to report about in the next status report. On the other hand I recently got a hold of a Sun Fire 3800, so these and other models from the same family likely will be supported by FreeBSD at some point in the future. __________________________________________________________________ GELI Additions Contact: Pawel Jakub Dawidek There are three new GELI (a disk encryption GEOM class) features available in -CURRENT: * AES-XTS encryption. XTS mode is a standard that is recommended these days for storage encryption. This is the default now. AES-XTS support was also added to opencrypto framework and aesni(4) driver. * Multiple encryption keys. GELI will use one encryption key for at most 2^20 blocks (sectors), as it is not recommended to use the same encryption key for too much data. It generates a key array from the master key on attach and uses it accordingly. This is the default now. * Passphrase can now also be loaded from a file (-J and -j options). __________________________________________________________________ gptboot Improvements URL: http://lists.FreeBSD.org/pipermail/svn-src-head/2010-September/020957.h tml Contact: Pawel Jakub Dawidek The gptboot now fully follows GPT specification (verifies checksums and falls back to backup header and table if primary is corrupted). One can now use new attributes to configure partition that gptboot will try to boot only once from and in case of a failure it will fall back to the previous one. For more information check out the commit message. __________________________________________________________________ HAST (Highly Available Storage) Improvements Contact: Pawel Jakub Dawidek HAST is now better than ever! Some recent improvements include: * Hooks supports -- HAST will execute the given command on various events (connect, disconnect, synchronization start, synchronization completed, synchronization interrupted, split-brain condition, role change). * Configuration reload on SIGHUP, a very missing functionality. * Internal keepalive mechanism. * Many bug fixes, majority of them reported by Mikolaj Golub. __________________________________________________________________ Kernel Event Timers Infrastructure URL: http://wiki.FreeBSD.org/201010DevSummit?action=AttachFile&do=get&target =timers.pdf URL: http://people.FreeBSD.org/~mav/tm6292_idle.patch Contact: Alexander Motin Work on new event timers infrastructure continues. In -CURRENT amd64, arm (Marvell), i386, mips, pc98, powerpc, sparc64, sun4v architectures were refactored to use new timers API. New machine-independent timers management code was written. It can utilize both legacy periodic and new one-shot timer operation modes. Using one-shot mode allows to significantly reduce the number of timer interrupts and respectively increase CPU sleep time during idle periods. Timer interrupts on idle CPUs are now generated only when they are needed to handle registered time-based events. Busy CPUs unluckily still receive the full interrupt rate for purposes of resource accounting, scheduling and timekeeping. With some additional tuning it is now possible to have an 8-core system, receiving only about 100 interrupts per second and respectively have CPU idle periods up to 100ms. This allows to effectively use any supported CPU idle states (C-states), that reduces power consumption and increases effect of the Intel TurboBoost technology. New manual pages were written to document this functionality: eventtimers(7), attimer(4), atrtc(4), hpet(4). Open tasks: 1. Troubleshoot possible hardware issues. 2. Refactor remaining architectures (arm, ia64, XEN PV). 3. Do some optimizations in different subsystems to reduce number of time-based events. Extend callout API with terms of precision, allowing to group close events. 4. Make schedulers tickless, or at least less depending on time events to make skipping timer interrupts possible when CPUs are busy. 5. Merge code into 8-STABLE when it is considered ready. __________________________________________________________________ Kernel-level Stacked Cryptographic File System -- PEFS URL: http://wiki.FreeBSD.org/PEFS URL: http://github.com/glk/pefs Contact: Gleb Kurtsou PEFS is a kernel level stacked cryptographic file system, i.e. it stacks on top of existing mounted filesystems. AES and Camellia algorithms in XTS mode are supported. The project has matured since Summer of Code 2009, most important improvements for last few months include: switch to use XTS encryption mode, implementation of sparse file support, fixing rename bugs including race and livelock conditions, addition of ext2 support. PEFS suite contains pam module facilitating user authentication with file system key and adding keys to mounted file system on login. PEFS passes fsx, pjdfstest, blogbench and dbench tests running on top of UFS and ZFS. __________________________________________________________________ mandoc/mdocml -- groff Replacement for Rendering Manual Pages in FreeBSD URL: http://mdocml.bsd.lv/ URL: https://www.spoerlein.net/cgit/cgit.cgi/freebsd.work/log/?h=mdocml Contact: Ulrich Spörlein Kristaps' groff-replacement (only for rendering manual pages) is already available in NetBSD and OpenBSD, and used to render the base system manpages for the latter. This project aims to do similar things for FreeBSD. mandoc(1) is more strict in what it accepts as input and is still lacking some features that are used by some selected few manpages. Getting manual page fixes accepted by upstream vendors has been challenging. Waiting for them to round-trip back into FreeBSD will take even longer. Future work will therefore result in direct commits to our contrib/ and gnu/ repository areas, in the hope this will not impact future vendor imports too much. Open tasks: 1. Finish the Big Manpage Cleanup of 2010. 2. Write a textproc/groff port for the latest groff version. 3. Import mandoc(1), switch to catpages for base. 4. Supply necessary ports infrastructure to opt-in to mandoc(1). 5. Discuss future of groff(1) in base wrt. share/doc. __________________________________________________________________ Netdump Support URL: http://wiki.FreeBSD.org/Netdump URL: svn://svn.FreeBSD.org/base/project/sv/ Contact: Attilio Rao Contact: Ed Maste Netdump provides kernel core dumping over the network, instead of to a local disk. It implements a very minimal TCP/IPv4 stack and uses a custom UDP protocol to transmit the dump to the netdump server running on another host. Network interfaces selected for dumping perform I/O in polling mode. Netdump should find its use in diskless workstation clusters, PXE-booted test machines, and perhaps when doing disk driver development. Open tasks: 1. General FreeBSD dumping mechanism refinements. 2. Implement checksum on UDP packets. 3. Investigate the possibility to replace the custom protocol with tftp. 4. Investigate the possibility to replace the custom TCP/IPv4 stack with Contiki. 5. Implement network console and gdb backend using a shared debug context stack. 6. Add IPv6 support. __________________________________________________________________ OpenAFS Port URL: http://openafs.org URL: http://web.mit.edu/freebsd/openafs/openafs.shar Contact: Benjamin Kaduk Contact: Derrick Brashear AFS is a distributed network file system that originated from the Andrew Project at Carnegie-Mellon University; the OpenAFS client implementation has not been particularly useful on FreeBSD since the FreeBSD 4.X releases. The previous status report brought the OpenAFS client to a useful form on -CURRENT, though with many rough edges. Only a couple of those edges have been smoothed out during the past few months, as developer time was scarce. A mismatch between file size and vmobject size tracking was resolved (allowing executables to be run from AFS), and our system call entry has been updated on -CURRENT and 8-STABLE to match reality. Thanks to Kostik Belusov for both of those! The code is useful enough that we plan to submit an openafs-devel port to the Ports Collection in the coming cycle. There are several known outstanding issues that are being worked on, but detailed bug reports are welcome at port-freebsd@openafs.org. Open tasks: 1. Rework vnode locking for lookup operations to avoid an easily-triggered deadlock between two threads when one is looking up the parent directory. 2. Update VFS locking to allow the use of disk-based client caches as well as memory-based caches. 3. Track down races and deadlocks that appear under load. 4. Integrate with the bsd.kmod.mk kernel-module build infrastructure. __________________________________________________________________ Packet Capturing Stack -- ringmap URL: http://code.google.com/p/ringmap/ URL: http://ringmap.googlecode.com/files/ringmap_slides.pdf URL: http://wiki.FreeBSD.org/AlexandreFiveg Contact: Alexander Fiveg Ringmap is a complete FreeBSD packet capturing stack specialized for very high-speed networks. The goal of this project is to develop the software for efficient packet capturing and integrate it with the generic network drivers and libpcap. Current Status: * Integrated with the lem driver. Intel network controllers: 8254X are supported. * Packet filtering using BPF in both kernel and user space. * Partly integrated with ixgbe driver for 10Gb capturing. Open tasks: 1. Support for hardware timestamping. 2. Writing packets to the disc from within the kernel. 3. Multiqueue support. 4. Extending the "ringmap" for packet transmission. __________________________________________________________________ PC-BSD URL: http://www.pcbsd.org URL: http://trac.pcbsd.org/browser/pcbsd/current/ Contact: Kris Moore Work is progressing quickly on a major re-factoring of PC-BSD tools and the PBI format for 9.0. Our GUI tools have been converted to compile / run within native QT without KDE now, allowing us to begin offering support for other desktop environments for 9.0, such as Gnome, XFCE, LXDE, KDE, etc. The PBI format has undergone a complete evolution, and is now entirely command-line based for all aspects of it, with only a few dependencies upon curl & xdg-utils. This will allow us to begin offering PBIs for traditional FreeBSD users starting with 9.0, who will be able to install the pbi-manager from ports in the near future. Open tasks: 1. We are still busy converting / fixing all our tools to play nicely with various DE's, but making quick progress. 2. The new PBI format is still undergoing extensive testing, and bugs are being isolated and fixed. __________________________________________________________________ pc-sysinstall URL: http://it.toolbox.com/blogs/bsd-guru/eurobsdcon-presentation-on-pcsysin stall-41831 Contact: Kris Moore Contact: John Hixson Contact: Josh Paetzel pc-sysinstall was imported into CURRENT recently. For the moment it is feature complete, although progress on the text front end for it may expose additional functionality it needs. Open tasks: 1. The automated/scripted install features of pc-sysinstall need wider testing and use to expose potential weaknesses, bugs, and additional features it may require. 2. Related tasks include getting a text front-end to pc-sysinstall working and hooking up pc-sysinstall to the build so install media is generated that runs pc-sysinstall. __________________________________________________________________ pkg_upgrade (sysutils/bsdadminscripts) URL: http://sf.net/projects/bsdadminscripts URL: http://sf.net/projects/bsdadminscripts/files/publications/2010-10-eurob sdcon/ Contact: Dominic Fandrey pkg_upgrade was (to my knowledge) the first binary packages only update tool for the FreeBSD ports. Using it does not require a copy of the ports tree. Currently the tool is in the final stages of a recode, that will greatly improve support for sharing packages over NFS or nullfs mounts (e.g. for distributing packages into jails) and also offers improved dependency tracking and performance, more in line with how pointyhat and Tinderbox build packages. I recently had the opportunity to present my work at the EuroBSDCon 2010. Open tasks: 1. Complete session code. 2. Add INDEX generator script that harvests information directly from packages and hence is always accurate. 3. Testing. __________________________________________________________________ Ports Collection URL: http://www.FreeBSD.org/ports/ URL: http://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/contributing-ports/ URL: http://portsmon.FreeBSD.org/index.html URL: http://www.FreeBSD.org/portmgr/index.html URL: http://blogs.FreeBSDish.org/portmgr/ URL: http://www.twitter.com/freebsd_portmgr/ URL: http://www.facebook.com/group.php?gid=135441496471197 URL: http://tinderbox.marcuscom.com/ Contact: Thomas Abthorpe Contact: Port Management Team The ports tree count now exceeds 22,000. With the assistance of many people, especially Philip Gollucci, the open PR count is below 1000 for the first time in quite a while. This is very encouraging progress. Since the last report, we added five new committers, and took in two commit bits for safe keeping. With onsite assistance from jhb@, gnn@, skreuzer@, and pgollucci@, we now have 11 new servers at NYI. The machines still need testing for stability and will soon be assigned for package building. The Ports Management team have been running -exp runs on an on-going basis, verifying how base system updates may affect the ports tree, as well as providing QA runs for major ports updates. Of note, -exp runs were done for: * des: test libfetch * gabor: tests for BSD iconv and grep * mezz: switch www/neon28 to www/neon29 * beat: update www/libxul * johans: update devel/bison and devel/m4 * dinoex: update graphics/tiff * jpaetzel: update devel/popt * ade: multiple runs autotools upgrade * gerald: setting USE_GCC=4.5 as default * ashish: changes to Mk/bsd.license.mk * kwm: test of Clang in -CURRENT Open tasks: 1. Looking for help fixing ports broken on -CURRENT. 2. Looking for help with Tier-2 architectures. 3. Most ports PRs are assigned, we now need to focus on testing, committing and closing. __________________________________________________________________ Ports Distfile and WWW Checker URL: http://people.FreeBSD.org/~ehaupt/distilator/ Contact: Emanuel Haupt Given the current status of fenner's Distfiles Survey, a new distfile checker was written in order to have an overview for the state of each distfile in the ports tree. The distfile checker is also able to verify WWW entries in pkg-descr files. This is an attempt to weed out broken MASTER_SITES and outdated WWW entries. The current version uses a MySQL database backend and is able to verify 432512 distfiles (30 concurrent threads) within 24 hours. Open tasks: 1. Provide JavaScript to sort/filter/search tables. __________________________________________________________________ Registration of Optional Kernel Subsystems via sysctl URL: http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/fr eebsd/t127230759508 URL: http://wiki.FreeBSD.org/201010DevSummit?action=AttachFile&do=view&targe t=kibab_sysctlreg.pdf Contact: Ilya Bakulin All work is now in Perforce. Rich set of features is added to the kernel, userland tools and libc modifications are ready, documentation is ready. Open tasks: 1. Documentation review. 2. Presentation of feature set on the various mailing lists. 3. Committing to -CURRENT, possibly merging to stable branches (changes do not break ABI/KBI). __________________________________________________________________ Resource Containers Contact: Edward Tomasz Napierala The goal of this project is to implement resource containers and a simple per-jail resource limits mechanism. Resource containers are also a prerequisite for other resource management mechanisms, such as Hierarchical Resource Limits, for "Collective Limits on Set of Processes (aka. Jobs)" Google Summer of Code 2010 project, for implementing mechanism similar to Linux cgroups, and might be also used to e.g. provide precise resource usage accounting for administrative or billing purposes. So far, a generic resource usage framework has been developed, along with limit enforcement for most resources. Work is on-going on adding limits for remaining resources, debugging and generally improving the implementation. This project is being sponsored by The FreeBSD Foundation. __________________________________________________________________ Syncing pf(4) with OpenBSD 4.5 URL: http://svn.FreeBSD.org/viewvc/base/user/eri/pf45/ URL: http://svn.FreeBSD.org/base/user/eri/pf45/head/ URL: http://lists.FreeBSD.org/pipermail/freebsd-pf/2010-October/005842.html Contact: Ermal Luçi This work is based on OpenBSD 4.5 state of pf(4). It includes many improvements over the code currently present in FreeBSD. The actual new feature present in pf45 repository is support for divert(4), which should allow tools like snort_inline to work with pf(4) too. This work also enables pfsync(4) to be loaded as a module as well. Currently, this work is considered stable and a patch against -CURRENT has been released on freebsd-pf mailing list. The reason why this work is based off of OpenBSD 4.5 is that after this release they have changed the syntax which is not backwards compatible. After importing this one the work will go on the newest version and decisions on it will then be done. Open tasks: 1. Make a decision whether we need pflow(4) in base. 2. More regression testing is needed. __________________________________________________________________ Target Big Endian Must Die Contact: Warner Losh The "tbemd" or Target Big Endian Must Die effort is nearing completion. Most of the big sweeping changes to the tree have been committed. The last change, actually pulling the switch, is stalled waiting for make universe improvements. This work will change the TARGET_ARCH from a plain 'mips' to 'mipsel' or 'mipseb' based on which endian the platform has. It introduces the concept of multiple architectures being implemented with one set of files, and regularizes that design pattern into the FreeBSD build process. In the past, you had to set TARGET_BIG_ENDIAN=t to compile for big endian, but that had a number of problems: can not share /usr/obj between little and big endian targets, sometimes the produced compilers will not work right unless TARGET_BIG_ENDIAN is defined in the environment, etc. Open tasks: 1. Update make universe to cope with the new architectures when building kernels. __________________________________________________________________ The FreeBSD Foundation Status Report URL: http://www.FreeBSDFoundation.org Contact: Deb Goodkin We were proud to be a sponsor for MeetBSD 2010 Poland and KyivBSD 2010 in Kiev, Ukraine. We also committed to sponsoring BSDDay Argentina 2010, MeetBSD California 2010, and NYBSDCon 2010 all in November. The Foundation was also represented at MeetBSD Poland and Ohio LinuxFest. Completed the Foundation funded projects: "FreeBSD Jail-Based Virtualization" by Bjoern Zeeb and "DTrace Userland" by Rui Paulo. We kicked off a new project by Swinburne University called "Five New TCP Congestion Control Algorithms for FreeBSD". We continued our work on infrastructure projects to beef up hardware for package-building, network-testing, etc. This includes purchasing equipment as well as managing equipment donations. We are three quarters of the way through the year and we have raised around $160,000 towards our goal of $350,000. Find out how to make a donation at http://www.FreeBSDFoundation.org/donate/ Stop by and visit with us at MeetBSD California (Nov 5-6), LISA (Nov 10-11), and NYCBSDCon (Nov 12-14). __________________________________________________________________ The FreeBSD German Documentation Project URL: http://doc.bsdgroup.de Contact: Johann Kois Contact: Benedict Reuschling The committers to the German Documentation Project were mostly trying to keep the documents and the website translations in sync with the ones on FreeBSD.org. Fabian Ruch was helpful in catching up with the changes to the Porters Handbook. Benedict translated the Solid State article into German because this is becoming a good addition to traditional hard drive storage. We tried to re-activate committers who did not contribute for some time but most of them are currently unable to free up enough time. We hope to gain fresh contributor blood as we are getting occasional reports about bugs and grammar in the German translation. Open tasks: 1. Submit grammar, spelling or other errors you find in the German documents and the website. 2. Translate more articles and other open handbook sections. __________________________________________________________________ The FreeBSD Japanese Documentation Project URL: http://www.FreeBSD.org/ja/ URL: http://www.jp.FreeBSD.org/doc-jp/ Contact: Hiroki Sato Contact: Ryusuke Suzuki The www/ja and doc/ja_JP.eucJP/ have been updated constantly since the last status report. We committed a big patch for the "Installing FreeBSD" chapter of the FreeBSD Handbook which was contributed by many people since a long time. This chapter is still outdated and needs more work. Some progress was made in the Porter's Handbook as well. Open tasks: 1. Further translation of the FreeBSD Handbook and contents of the www.FreeBSD.org site to the Japanese language. 2. Pre-/post-commit review of the translation. __________________________________________________________________ Updating Base Tools to Accommodate Ports Requirements Contact: Gordon Tetlow The goal of the project is to allow easier extension of base system tools by the ports system. Ideally, no files in /etc should need to be modified by a port installation. The man toolset was recently reimplemented as a BSDL version instead of the old GPL version. It is also a single shell script instead of multiple C programs. Ports can extend the man functionality by dropping files into /usr/local/etc/man.d/portname.conf. Next up on the list is to finish the implementation for newsyslog thereby allowing ports that need logs rotated to take advantage of that tool. __________________________________________________________________ USB Stack URL: http://svn.FreeBSD.org/viewvc/base/head/sys/dev/usb/controller/xhci.c?v iew=log Contact: Hans Petter Selasky During the last two months the USB stack in -CURRENT has been enhanced to support USB 3.0 and the XHCI USB 3.0 chipset from Intel. The XHCI chip will eventually replace the EHCI, OHCI and UHCI chips. Open tasks: 1. FreeBSD testers which have access to USB 3.0 hardware are wanted. __________________________________________________________________ Userland DTrace URL: http://wiki.FreeBSD.org/DTrace/userland Contact: Rui Paulo Userland DTrace support was a FreeBSD Foundation sponsored project that was developed during this summer. The project aimed to bring the userland DTracing functionality to FreeBSD as it is available on OpenSolaris. FreeBSD now supports the pid provider and the usdt probes. plockstat is available with a separate patch. Dtruss, a DTrace script that works similarly to ktrace, but with other advantages was imported into FreeBSD. The mysql-server and postgresql-server ports also have DTrace support. __________________________________________________________________ V4L Support in Linux Emulator URL: http://opal.com/freebsd/sys/compat/linux/ Contact: J.R. Oldroyd The V4L support in the Linux emulator has been merged to 8-STABLE allowing use of video in Skype calls using a camera supported by the pwcbsd or video4bsd drivers. A known issue for Skype is that your camera must support YUV420 mode which is what Skype uses. Note that V4L2 support is not included in the current work, and remains as a project for anyone interested. __________________________________________________________________ Valgrind Port URL: http://wiki.freebsd.org/Valgrind URL: http://bitbucket.org/stass/valgrind-freebsd/overview URL: https://bugs.kde.org/show_bug.cgi?id=208531 Contact: Stanislav Sedov Contact: Ed Maste Valgrind is a tool for detecting memory management and threading bugs, and profiling. Version 3.6.0 has recently been released and the FreeBSD port has now been updated. Development of the Valgrind port has moved from Perforce to bitbucket.org, in order to make it easier for others to track changes as we progress towards getting the port into shape to commit upstream. The repository's Bitbucket address is at the beginning of the report. A bugzilla entry has been submitted to track the FreeBSD Valgrind port. You can see the status and vote for the bug to express your interest at https://bugs.kde.org/show_bug.cgi?id=208531. Open tasks: 1. Port exp-ptrcheck valgrind tool and fix outstanding issues that show up in memcheck/helgrind/DRD in the Valgrind regression tests suite. 2. More testing (please, help). 3. Integrate our patches upstream. __________________________________________________________________ Web Feeds for UPDATING Files URL: http://updating.versia.com/ Contact: Alexander Kojevnikov updating.versia.com features web feeds for UPDATING files from ports, head, stable/7 and stable/8. These feeds provide an easy way to track important changes in the ports tree and the base system. __________________________________________________________________ xz Compression for Packages and Log Files Contact: Martin Matuska Support for xz compression has been enabled in bsdtar (-CURRENT 8-STABLE) and added to pkg_create(1) and pkg_add(1) (-CURRRENT). Packages with the .txz suffix can be created and installed. Log file compression using xz in newsyslog(8) will be integrated soon. Benchmarks show 15-30% better compression ratios and up to halved decompression times when compared to bzip2. A switch from the default package format from .tbz to .txz is to be considered. Open tasks: 1. Test building all FreeBSD packages with xz compression. __________________________________________________________________ ZFSv28 is Ready for Wider Testing URL: http://lists.FreeBSD.org/pipermail/freebsd-fs/2010-August/009197.html Contact: Pawel Jakub Dawidek ZFS v28 which includes data deduplication and plenty of other shiny new features is ready for testing. For more information check out the announcement. __________________________________________________________________ (c) 1995-2010 The FreeBSD Project. All rights reserved. From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 27 00:14: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 1A41A1065695; Wed, 27 Oct 2010 00:14:22 +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 7B4598FC15; Wed, 27 Oct 2010 00:14:21 +0000 (UTC) Received: by wyb42 with SMTP id 42so94827wyb.13 for ; Tue, 26 Oct 2010 17:14:20 -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=f3Z9HAwTZ3qLUMj23203+aiBT1laz6y9jwv9Xtmc9bE=; b=GdJ2KBC15Xpo7h5aYUiBk9GTFbnTYl+WsA8j/TPf2G/Qw5Po87UZJn1HzhlU2SwZ5n 0ND7bdLOxjW0oVVadN5H4h1Tpz0PsN4OcROW4u+uRZzIQ/Sh5xmEplSFhklGay4IinrY V8izP6axE8CZ/Xo1xFlOnCysFyMgiiNM5cgds= 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=r1fA7bu+fAIr1eOQe2YD7KH8hnIjnN0LhibEfMpQs3NmxCcYg7i5Hnc845SDRGA5Er lS13G4K5s6SOr4eUWNQ0YmhvNhyU40ShE79WLOHw5Ey50nS79gkatM/lr0rrRmz+emyX 5jyqT6zI9hYFB2sW/MluaN+mJsBnexJQD2R/0= MIME-Version: 1.0 Received: by 10.216.231.168 with SMTP id l40mr539102weq.18.1288138458648; Tue, 26 Oct 2010 17:14:18 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.216.10.198 with HTTP; Tue, 26 Oct 2010 17:14:18 -0700 (PDT) In-Reply-To: <20101026234036.GA17347@freebsd.org> References: <20101026213618.GA3013@freebsd.org> <20101027003229.00002b91@unknown> <20101026234036.GA17347@freebsd.org> Date: Tue, 26 Oct 2010 17:14:18 -0700 X-Google-Sender-Auth: IconfCQFlG5yaiLziqowEYqB4Wg Message-ID: From: Garrett Cooper To: Alexander Best Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Bruce Cran , freebsd-hackers@freebsd.org Subject: Re: fsync(2) manual and hdd write caching X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 27 Oct 2010 00:14:22 -0000 On Tue, Oct 26, 2010 at 4:40 PM, Alexander Best wrote= : > On Wed Oct 27 10, Bruce Cran wrote: >> On Tue, 26 Oct 2010 21:36:18 +0000 >> Alexander Best wrote: >> >> > since there's a thread on freebsd-questions@ concerning fsync(2) and >> > the fact that hdd write caching can cause this syscall to basically >> > be a no op, could somebody please copy the BUGS section from sync(2) >> > to fsync(2)? >> >> Shouldn't the BUGS section of sync(2) be removed? >> >> "The sync() system call may return before the buffers are completely >> =A0 =A0 =A0flushed." >> >> But from >> http://www.opengroup.org/onlinepubs/009695399/functions/sync.html : >> >> "The writing, although scheduled, is not necessarily complete upon >> return from sync()." >> >> That would suggest it's not actually a bug. > > well...you are right on the one hand. but still this should be documented= imo. > how about turning BUGS into a CAVEATS section and then adding that sectio= n to > fsync(2)? > > the reason posix mentions this sync/fsync behavior is probably the fact t= hat > they know that this cannot be avoided. so that statement seems itself to = be a > caveat rather than a feature. ;) Just a sidenote, but that's POSIX 2004[.6?] spec, not POSIX 2008.1 (which is the most current spec -- http://www.unix.org/2008edition/ ). I double checked and the wording didn't differ for the fsync(2) system interface, but it could differ in others. HTH, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 27 06:23: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 8CDFF106566C for ; Wed, 27 Oct 2010 06:23:33 +0000 (UTC) (envelope-from lars@chaotika.org) Received: from diogenes.chaotika.org (cl-2124.ham-01.de.sixxs.net [IPv6:2001:6f8:900:84b::2]) by mx1.freebsd.org (Postfix) with ESMTP id 1F6978FC18 for ; Wed, 27 Oct 2010 06:23:33 +0000 (UTC) Received: from [192.168.0.109] (intern.tbh.eu [213.146.244.186]) by diogenes.chaotika.org (Postfix) with ESMTPSA id 491C032272F for ; Wed, 27 Oct 2010 08:23:31 +0200 (CEST) From: Lars Hartmann To: freebsd-hackers@freebsd.org Content-Type: multipart/mixed; boundary="=-PROci6iyh13rFY44Y7HR" Date: Wed, 27 Oct 2010 08:23:30 +0200 Message-ID: <1288160610.4280.18.camel@apollon> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Subject: [PATCH] Fix 'implicit declaration' warning and update vgone(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 27 Oct 2010 06:23:33 -0000 --=-PROci6iyh13rFY44Y7HR Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit The vgonel function isnt declarated in any header, the vgonel prototype in vgone(9) isnt correct - found by Ben Kaduk -- Lars Hartmann --=-PROci6iyh13rFY44Y7HR Content-Disposition: attachment; filename="vgone.9.patch" Content-Type: text/x-patch; name="vgone.9.patch"; charset="UTF-8" Content-Transfer-Encoding: 7bit fixed vgonel prototype in vgone.9 - found by Ben Kaduk From: Lars Hartmann --- share/man/man9/vgone.9 | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/share/man/man9/vgone.9 b/share/man/man9/vgone.9 index fa30c1e..a23d468 100644 --- a/share/man/man9/vgone.9 +++ b/share/man/man9/vgone.9 @@ -38,7 +38,7 @@ .Ft void .Fn vgone "struct vnode *vp" .Ft void -.Fn vgonel "struct vnode *vp" "struct thread *td" +.Fn vgonel "struct vnode *vp" .Sh DESCRIPTION .Fn vgone and --=-PROci6iyh13rFY44Y7HR Content-Disposition: attachment; filename="vgonel.patch" Content-Type: text/x-patch; name="vgonel.patch"; charset="UTF-8" Content-Transfer-Encoding: 7bit fix implicit declaration warning - found by Ben Kaduk From: Lars Hartmann --- sys/sys/vnode.h | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/sys/sys/vnode.h b/sys/sys/vnode.h index e82f8ea..8ec8d1f 100644 --- a/sys/sys/vnode.h +++ b/sys/sys/vnode.h @@ -626,6 +626,7 @@ void vdestroy(struct vnode *); int vflush(struct mount *mp, int rootrefs, int flags, struct thread *td); int vget(struct vnode *vp, int lockflag, struct thread *td); void vgone(struct vnode *vp); +void vgone(struct vnode *vp); void vhold(struct vnode *); void vholdl(struct vnode *); int vinvalbuf(struct vnode *vp, int save, int slpflag, int slptimeo); --=-PROci6iyh13rFY44Y7HR-- From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 27 06:36:08 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 BF529106566B for ; Wed, 27 Oct 2010 06:36:08 +0000 (UTC) (envelope-from lars@chaotika.org) Received: from diogenes.chaotika.org (cl-2124.ham-01.de.sixxs.net [IPv6:2001:6f8:900:84b::2]) by mx1.freebsd.org (Postfix) with ESMTP id 5CA858FC16 for ; Wed, 27 Oct 2010 06:36:08 +0000 (UTC) Received: from [192.168.0.109] (intern.tbh.eu [213.146.244.186]) by diogenes.chaotika.org (Postfix) with ESMTPSA id 9E1E532276C for ; Wed, 27 Oct 2010 08:36:07 +0200 (CEST) From: Lars Hartmann To: freebsd-hackers@freebsd.org In-Reply-To: <1288160610.4280.18.camel@apollon> References: <1288160610.4280.18.camel@apollon> Content-Type: multipart/mixed; boundary="=-Q0aIyj34DgKHBcvqwOoZ" Date: Wed, 27 Oct 2010 08:36:07 +0200 Message-ID: <1288161367.4280.21.camel@apollon> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Subject: Re: [PATCH] Fix 'implicit declaration' warning and update vgone(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 27 Oct 2010 06:36:08 -0000 --=-Q0aIyj34DgKHBcvqwOoZ Content-Type: text/plain Content-Transfer-Encoding: 7bit attached the fixed vgonel.patch -- Lars Hartmann --=-Q0aIyj34DgKHBcvqwOoZ Content-Disposition: attachment; filename="vgonel.patch" Content-Type: text/x-patch; name="vgonel.patch"; charset="UTF-8" Content-Transfer-Encoding: 7bit fix implicit declaration warning - found by Ben Kaduk From: Lars Hartmann --- sys/sys/vnode.h | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/sys/sys/vnode.h b/sys/sys/vnode.h index e82f8ea..8ec8d1f 100644 --- a/sys/sys/vnode.h +++ b/sys/sys/vnode.h @@ -626,6 +626,7 @@ void vdestroy(struct vnode *); int vflush(struct mount *mp, int rootrefs, int flags, struct thread *td); int vget(struct vnode *vp, int lockflag, struct thread *td); void vgone(struct vnode *vp); +void vgonel(struct vnode *vp); void vhold(struct vnode *); void vholdl(struct vnode *); int vinvalbuf(struct vnode *vp, int save, int slpflag, int slptimeo); --=-Q0aIyj34DgKHBcvqwOoZ-- From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 27 09:40: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 55E391065698; Wed, 27 Oct 2010 09:40:18 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [199.26.172.34]) by mx1.freebsd.org (Postfix) with ESMTP id 344648FC16; Wed, 27 Oct 2010 09:40:17 +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 o9R9BFM5027735 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 27 Oct 2010 02:11:15 -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 o9R9BFUb027734; Wed, 27 Oct 2010 02:11:15 -0700 (PDT) Received: from fbsd61 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA09065; Wed, 27 Oct 10 02:01:09 PDT Date: Wed, 27 Oct 2010 02:00:51 -0700 From: perryh@pluto.rain.com To: ivoras@freebsd.org Message-Id: <4cc7ea44.ApOaxS8Xr4Sxu+0x%perryh@pluto.rain.com> References: <20101026213618.GA3013@freebsd.org> 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: fsync(2) manual and hdd write caching X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 27 Oct 2010 09:40:18 -0000 Ivan Voras wrote: > fsync(2) actually does behave as advertised, "auses all modified > data and attributes of fd to be moved to a permanent storage > device". It is the problem of the "permanent storage device" > if it caches this data further. IMO, volatile RAM without battery backup cannot reasonably be considered a "permanent storage device", regardless of where it is physically located. Short of mounting synchronously, with the attendant performance hit, would it not make sense for fsync(2) to issue ATA_FLUSHCACHE or SCSI "SYNCHRONIZE CACHE" after it has finished writing data to the drive? Surely the low-level capability to issue those commands must already exist, else we would have no way to safely prepare for power off. From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 27 10:11: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 C68621065672; Wed, 27 Oct 2010 10:11:30 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id 892668FC08; Wed, 27 Oct 2010 10:11:30 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id D2568E7FB5; Wed, 27 Oct 2010 11:11:29 +0100 (BST) Received: from unknown (client-81-107-142-135.midd.adsl.virginmedia.com [81.107.142.135]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA; Wed, 27 Oct 2010 11:11:29 +0100 (BST) Date: Wed, 27 Oct 2010 11:11:24 +0100 From: Bruce Cran To: perryh@pluto.rain.com Message-ID: <20101027111124.00007450@unknown> In-Reply-To: <4cc7ea44.ApOaxS8Xr4Sxu+0x%perryh@pluto.rain.com> References: <20101026213618.GA3013@freebsd.org> <4cc7ea44.ApOaxS8Xr4Sxu+0x%perryh@pluto.rain.com> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, ivoras@freebsd.org Subject: Re: fsync(2) manual and hdd write caching X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 27 Oct 2010 10:11:30 -0000 On Wed, 27 Oct 2010 02:00:51 -0700 perryh@pluto.rain.com wrote: > Short of mounting synchronously, with the attendant performance > hit, would it not make sense for fsync(2) to issue ATA_FLUSHCACHE > or SCSI "SYNCHRONIZE CACHE" after it has finished writing data > to the drive? Surely the low-level capability to issue those > commands must already exist, else we would have no way to safely > prepare for power off. mounting synchronously won't help, will it? As I understand it that just makes sure that data is sent straight to disk and not left in memory; the data will still be stored in the HDD cache for a while. -- Bruce Cran From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 27 10:18:48 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 60E621065786 for ; Wed, 27 Oct 2010 10:18:48 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 16D958FC13 for ; Wed, 27 Oct 2010 10:18:47 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PB35d-0003xT-C2 for freebsd-hackers@freebsd.org; Wed, 27 Oct 2010 12:18:41 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 27 Oct 2010 12:18:41 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 27 Oct 2010 12:18:41 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Date: Wed, 27 Oct 2010 12:18:31 +0200 Lines: 23 Message-ID: References: <20101026213618.GA3013@freebsd.org> <4cc7ea44.ApOaxS8Xr4Sxu+0x%perryh@pluto.rain.com> <20101027111124.00007450@unknown> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.12) Gecko/20101018 Thunderbird/3.0.8 In-Reply-To: <20101027111124.00007450@unknown> X-Enigmail-Version: 1.0.1 Subject: Re: fsync(2) manual and hdd write caching X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 27 Oct 2010 10:18:48 -0000 On 10/27/10 12:11, Bruce Cran wrote: > On Wed, 27 Oct 2010 02:00:51 -0700 > perryh@pluto.rain.com wrote: > >> Short of mounting synchronously, with the attendant performance >> hit, would it not make sense for fsync(2) to issue ATA_FLUSHCACHE >> or SCSI "SYNCHRONIZE CACHE" after it has finished writing data >> to the drive? Surely the low-level capability to issue those >> commands must already exist, else we would have no way to safely >> prepare for power off. > > mounting synchronously won't help, will it? As I understand it that > just makes sure that data is sent straight to disk and not left in > memory; the data will still be stored in the HDD cache for a > while. Correct. The problem is actually pretty hard - since AFAIK SoftUpdates doesn't have "checkpoints" in the sense that it groups writes and all data "before" can guaranteed to be on-disk, the problem is *when* to issue BIO_FLUSH requests. One possible solution is to simply decide on a heuristic like: "ok, doing BIO_FLUSH all the time will destroy performance, we will only do it for every metadata write". Possibly with a sysctl tunable or per-mount option. From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 27 11:12:20 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 7E4E4106564A; Wed, 27 Oct 2010 11:12:20 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 15F888FC0A; Wed, 27 Oct 2010 11:12:19 +0000 (UTC) Received: by qyk7 with SMTP id 7so3490064qyk.13 for ; Wed, 27 Oct 2010 04:12:19 -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 :content-transfer-encoding; bh=RFyAMaQKU0FDKAngtijD/gUZrOuMc1yhVlrpv0ZG2p8=; b=NW+Ua1opi4erMHVC2ZIcy79YFbXENdMDh3P0Pc1b/q9eL4AX4RyWZo5xbqlEo5wIyg LBmXUwxWlWnmBLot2DZL+IL42X0Okm7A4uhjIEwTtHrx945yUs/xXVScspDi/Gg+g/SN p+Tua7eZK5IRIoi0C0PE6bRPYvBw29aSbKSV4= 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:content-transfer-encoding; b=capePENnATxKL/+hDt2UyhN8tF36hsb4bUZnjrPzYtKXwvqtqVRXfeIjQmf4KTfMtv ZmtJEd7DmVESdBwVv0S41VFbLcV1uWxEfV1Azzn0Ny0XEfn1PQVYAUbHPLklyd0xZitR nutQJw2x05/h+OZoW/mbIdCdoxTApMc+/8IQw= MIME-Version: 1.0 Received: by 10.229.248.79 with SMTP id mf15mr8764613qcb.181.1288177939355; Wed, 27 Oct 2010 04:12:19 -0700 (PDT) Received: by 10.229.69.135 with HTTP; Wed, 27 Oct 2010 04:12:19 -0700 (PDT) In-Reply-To: <201010260934.57247.jhb@freebsd.org> References: <4CC6830A.10701@icyb.net.ua> <201010260934.57247.jhb@freebsd.org> Date: Wed, 27 Oct 2010 15:12:19 +0400 Message-ID: From: Sergey Kandaurov To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Selphie Keller , Andriy Gapon Subject: Re: SYSCALL_MODULE() macro and modfind() issues X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 27 Oct 2010 11:12:20 -0000 On 26 October 2010 17:34, John Baldwin wrote: > On Tuesday, October 26, 2010 4:00:14 am Selphie Keller wrote: >> Thanks Andriy, >> >> Took a look at the change to src/sys/sys/sysent.h >> >> @@ -149,7 +149,7 @@ static struct syscall_module_data name## >> =A0}; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \ >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \ >> =A0static moduledata_t name##_mod =3D { =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 \ >> - =A0 =A0 =A0 #name, =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\ >> + =A0 =A0 =A0 "sys/" #name, =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \ >> =A0 =A0 =A0 =A0 syscall_module_handler, =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \ >> =A0 =A0 =A0 =A0 &name##_syscall_mod =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \ >> =A0}; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \ >> >> applied the MFC prefix to pmap port: >> >> --- /usr/ports/sysutils/pmap/work/pmap/pmap/pmap.c.orig 2010-10-26 >> 00:55:32.000000000 -0700 >> +++ /usr/ports/sysutils/pmap/work/pmap/pmap/pmap.c =A0 =A0 =A02010-10-26 >> 00:56:10.000000000 -0700 >> @@ -86,12 +86,12 @@ main(int argc, char **argv) >> =A0 =A0 =A0struct kinfo_proc *kp; >> =A0 =A0 =A0int =A0 =A0 =A0 =A0pmap_helper_syscall; >> >> - =A0 =A0if ((modid =3D modfind("pmap_helper")) =3D=3D -1) { >> + =A0 =A0if ((modid =3D modfind("sys/pmap_helper")) =3D=3D -1) { >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* module not found, try to load */ >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 modid =3D kldload("pmap_helper.ko"); >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (modid =3D=3D -1) >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 err(1, "unable to load p= map_helper module"); >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 modid =3D modfind("pmap_helper"); >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 modid =3D modfind("sys/pmap_helper"); >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (modid =3D=3D -1) >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 err(1, "pmap_helper modu= le loaded but not found"); >> =A0 =A0 =A0 =A0 } >> >> which restored functionality on freebsd 8.1. > > The best approach might be to have something like this: > > static int > pmap_find(void) > { > =A0 =A0 =A0 =A0int modid; > > =A0 =A0 =A0 =A0modid =3D modfind("pmap_helper"); > =A0 =A0 =A0 =A0if (modid =3D=3D -1) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0modid =3D modfind("sys/pmap_helper"); > =A0 =A0 =A0 =A0return (modid); > } > > then in the original main() routine use this: > > =A0 =A0 =A0 =A0if ((modid =3D pmap_find()) =3D=3D -1) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* module not found, try to load */ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0modid =A0=3D kldload("pmap_helper.ko"); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (modid =3D=3D -1) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0err(1, "unable to load pma= p_helper module"); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0modid =3D pmap_find(); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (modid =3D=3D -1) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0err(1, "pmap_helper module= loaded but not found"); > =A0 =A0 =A0 =A0} > > This would make the code work for both old and new versions. Just another foo of many which I use at work generally. It lacks compat32 syscalls handling though (we don't use them). /* * We have to extract __FreeBSD_version from live kernel * as we depend on kernel feature and can run on an older world. */ if (sysctlbyname("kern.osreldate", &osreldate, &intlen, NULL, 0) < = 0) err(-2, "sysctl(kern.osreldate)"); if (osreldate >=3D 800505) /* See r206346 in stable/8. */ strcpy(modname, "sys/foo"); else strcpy(modname, "foo"); --=20 wbr, pluknet From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 27 11:33: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 BDB62106566B for ; Wed, 27 Oct 2010 11:33:14 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 753CD8FC17 for ; Wed, 27 Oct 2010 11:33:14 +0000 (UTC) Received: by qyk33 with SMTP id 33so599545qyk.13 for ; Wed, 27 Oct 2010 04:33:13 -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=H9BarpYbEommN7/37tgyzYxP5bfNn0zNblxX33V9ciQ=; b=O0phsBzffUxW0vglYtNBgIhSZKvtduCCbzBykIag4+O39coHg5QISMw1yJCySyko4I MLt+IjFDVY9QMJpUOOfR0hnNdDNROwUHsuMq9EHxQLeMNvI52Nfb6+XpjJ4kq0lR7B2N 4SHUJogz10shdF7vpDOFzNaLJDuNl0zdkRBJU= 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=wIhhHhykK9TRrMWzUghXbN2Z3e+S8fpd9imqpfoNJRVcKZmy7VofMROFgFpekP9ht0 fI64DjVidBgeNUIKvz2OU/CERab1ZwmHq6c6IvqE55Bdw617GNwtclgowoowIi3AYbVX 3CuDbfUBHxEP+GIYSEMt0CDk62IfAt9xMFI6o= MIME-Version: 1.0 Received: by 10.229.35.16 with SMTP id n16mr8575133qcd.172.1288179193764; Wed, 27 Oct 2010 04:33:13 -0700 (PDT) Received: by 10.229.69.135 with HTTP; Wed, 27 Oct 2010 04:33:13 -0700 (PDT) In-Reply-To: <1288160610.4280.18.camel@apollon> References: <1288160610.4280.18.camel@apollon> Date: Wed, 27 Oct 2010 15:33:13 +0400 Message-ID: From: Sergey Kandaurov To: Lars Hartmann Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: [PATCH] Fix 'implicit declaration' warning and update vgone(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 27 Oct 2010 11:33:14 -0000 On 27 October 2010 10:23, Lars Hartmann wrote: > The vgonel function isnt declarated in any header, the vgonel prototype > in vgone(9) isnt correct - found by Ben Kaduk Hi. I'm afraid it's just an overlooked man page after many VFS changes in 5.x. As vgonel() is a static (i.e. private and not visible from outside) function IMO it should be removed from vgone(9) man page. -- wbr, pluknet From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 27 12:41:13 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 349681065673; Wed, 27 Oct 2010 12:41:13 +0000 (UTC) Date: Wed, 27 Oct 2010 12:41:13 +0000 From: Alexander Best To: Bruce Cran Message-ID: <20101027124113.GA6206@freebsd.org> References: <201009161742.24228.tijl@coosemans.org> <201009161619.o8GGJAmv035378@lurza.secnetix.de> <20101018155944.GA12425@freebsd.org> <868w1r92rf.fsf@ds4.des.no> <20101021122110.GA65490@freebsd.org> <86zku77mj6.fsf@ds4.des.no> <20101021135442.000054c9@unknown> <20101021134114.GB72290@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20101021134114.GB72290@freebsd.org> Cc: Dag-Erling =?iso-8859-15?Q?Sm=F8rgrav?= , mav@freebsd.org, Tijl Coosemans , Oliver Fromme , freebsd-hackers@freebsd.org Subject: Re: Summary: Re: Spin down HDD after disk sync or before power off X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 27 Oct 2010 12:41:13 -0000 On Thu Oct 21 10, Alexander Best wrote: > On Thu Oct 21 10, Bruce Cran wrote: > > On Thu, 21 Oct 2010 14:33:49 +0200 > > Dag-Erling Smørgrav wrote: > > > > > The problem with setting a short idle timeout is that, on a typical > > > laptop or desktop system, you end up spinning the disk down and back > > > up several hundred times a day, which increases power consumption, I/O > > > latency and wear. > > > > Do we think our users are silly enough to set a short timeout of just a > > few minutes? I'd think most would use a setting of 20-30 minutes at > > a minimum. I never did understand why there were so many warnings; > > after all, some laptops even come with a default APM scheme in their > > HDDs that powers the disk down after 7 seconds! > > personally i still think something like the attached patch would be nice to > have. there's a chance users might type the following: > > 'atacontrol spindown device 10' > > thinking the timeout value is measured in minutes. although this gets mentioned > in atacontrol(4) it might still be worth reminding the user that he/she is > performing actions which could damage the hardware. i just stumbled upon PR 144770, where a somebody seems to have mistaken the spindown value for minutes instead of seconds. so i really think we should have this warning in atacontrol! +1 from brucec, if i understood him correctly. another possibility would be of course changing the spindown value from seconds to minutes. imo this seems very reasonable, because measuring spindown time in seconds is too fine grained and not intuitive. just like specifying the 'shutdown -p XX' delay in microseconds would not be useful. ;) cheers. alex > > cheers. > alex > > > > > -- > > Bruce Cran > > -- > a13x > diff --git a/sbin/atacontrol/atacontrol.c b/sbin/atacontrol/atacontrol.c > index 4354ddf..75a131a 100644 > --- a/sbin/atacontrol/atacontrol.c > +++ b/sbin/atacontrol/atacontrol.c > @@ -317,6 +317,10 @@ ata_spindown(int fd, const char *dev, const char *arg) > > if (arg != NULL) { > tmo = strtoul(arg, NULL, 0); > + if (tmo < 600) > + warnx("setting spindown timeout below 10 minutes is \ > + not recommended (see EXAMPLES section of \ > + atacontrol(8))\n"); > if (ioctl(fd, IOCATASSPINDOWN, &tmo) < 0) > err(1, "ioctl(IOCATASSPINDOWN)"); > } else { -- a13x From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 27 12:46: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 20C7B106566B; Wed, 27 Oct 2010 12:46:00 +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 54FA18FC0C; Wed, 27 Oct 2010 12:45:59 +0000 (UTC) Received: by wyb42 with SMTP id 42so643011wyb.13 for ; Wed, 27 Oct 2010 05:45:58 -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=KvJvK0wCz8BXVKIvYAIXVW4cD0oLIpI7SubyOswwMhM=; b=L7KRjrHGptlVNEow8jJM7tV9A9jI+xRiyzYNRacvFtZY/ic9uwmtaDiqXP9ku6j80Z B8qkDZt+8o+8n7OVZpoc8IZK4nwCw04HxPhNoJnmuhVfoseyRM8H7F0uiNYrREiZ99dt E6h8yOruHLuwVnLlJMXCZZBfXR6SCrjs0EyQM= 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=uc4DlP48LmGjJp+ouAV43oiKkZGCz7m+cdfyjedI0inwjjK3EIpsaPAA4nlu8vHckx BmHT0i3Sl+EUvEtOFfRie8GXoE1UapghA3tcj7AfUa8/0GmfnBP5+wk8XZIVyeWvkO19 WP44deBqrWYh0z4y8kx4sisDOzY3DQoeop5jM= MIME-Version: 1.0 Received: by 10.216.132.166 with SMTP id o38mr9017301wei.16.1288183558387; Wed, 27 Oct 2010 05:45:58 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.216.10.198 with HTTP; Wed, 27 Oct 2010 05:45:57 -0700 (PDT) In-Reply-To: <20101027124113.GA6206@freebsd.org> References: <201009161742.24228.tijl@coosemans.org> <201009161619.o8GGJAmv035378@lurza.secnetix.de> <20101018155944.GA12425@freebsd.org> <868w1r92rf.fsf@ds4.des.no> <20101021122110.GA65490@freebsd.org> <86zku77mj6.fsf@ds4.des.no> <20101021135442.000054c9@unknown> <20101021134114.GB72290@freebsd.org> <20101027124113.GA6206@freebsd.org> Date: Wed, 27 Oct 2010 05:45:57 -0700 X-Google-Sender-Auth: lJ5HB0B3JkZK_kyPwsiw2ldltKY Message-ID: From: Garrett Cooper To: Alexander Best Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Bruce Cran , Tijl Coosemans , Oliver Fromme , freebsd-hackers@freebsd.org, mav@freebsd.org, =?ISO-8859-1?Q?Dag=2DErling_Sm=F8rgrav?= Subject: Re: Summary: Re: Spin down HDD after disk sync or before power off X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 27 Oct 2010 12:46:00 -0000 On Wed, Oct 27, 2010 at 5:41 AM, Alexander Best wrote= : > On Thu Oct 21 10, Alexander Best wrote: >> On Thu Oct 21 10, Bruce Cran wrote: >> > On Thu, 21 Oct 2010 14:33:49 +0200 >> > Dag-Erling Sm=F8rgrav wrote: >> > >> > > The problem with setting a short idle timeout is that, on a typical >> > > laptop or desktop system, you end up spinning the disk down and back >> > > up several hundred times a day, which increases power consumption, I= /O >> > > latency and wear. >> > >> > Do we think our users are silly enough to set a short timeout of just = a >> > few minutes? =A0I'd think most would use a setting of 20-30 minutes at >> > a minimum. I never did understand why there were so many warnings; >> > after all, some laptops even come with a default APM scheme in their >> > HDDs that powers the disk down after 7 seconds! >> >> personally i still think something like the attached patch would be nice= to >> have. there's a chance users might type the following: >> >> 'atacontrol spindown device 10' >> >> thinking the timeout value is measured in minutes. although this gets me= ntioned >> in atacontrol(4) it might still be worth reminding the user that he/she = is >> performing actions which could damage the hardware. > > i just stumbled upon PR 144770, where a somebody seems to have mistaken t= he > spindown value for minutes instead of seconds. so i really think we shoul= d have > this warning in atacontrol! > > +1 from brucec, if i understood him correctly. > > another possibility would be of course changing the spindown value from s= econds > to minutes. imo this seems very reasonable, because measuring spindown ti= me in > seconds is too fine grained and not intuitive. just like specifying the > 'shutdown -p XX' delay in microseconds would not be useful. ;) > > cheers. > alex > >> >> cheers. >> alex >> >> > >> > -- >> > Bruce Cran >> >> -- >> a13x > >> diff --git a/sbin/atacontrol/atacontrol.c b/sbin/atacontrol/atacontrol.c >> index 4354ddf..75a131a 100644 >> --- a/sbin/atacontrol/atacontrol.c >> +++ b/sbin/atacontrol/atacontrol.c >> @@ -317,6 +317,10 @@ ata_spindown(int fd, const char *dev, const char *a= rg) >> >> =A0 =A0 =A0 if (arg !=3D NULL) { >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 tmo =3D strtoul(arg, NULL, 0); >> + =A0 =A0 =A0 =A0 =A0 =A0 if (tmo < 600) >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 warnx("setting spindown timeou= t below 10 minutes is \ >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 not recommended (s= ee EXAMPLES section of \ >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 atacontrol(8))\n")= ; >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (ioctl(fd, IOCATASSPINDOWN, &tmo) < 0) >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 err(1, "ioctl(IOCATASSPINDOW= N)"); >> =A0 =A0 =A0 } else { Why not just be consistent with other interfaces and provide suffixes for the values to parse out integral times (i.e. 1 [second], 1m, 2h)? As long as the value is behavior is properly documented in the manpage (and potentially as examples in the usage message), that should be enough. Thanks, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 27 12:54:53 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 4720A1065674; Wed, 27 Oct 2010 12:54:53 +0000 (UTC) Date: Wed, 27 Oct 2010 12:54:53 +0000 From: Alexander Best To: Garrett Cooper Message-ID: <20101027125453.GA8433@freebsd.org> References: <201009161742.24228.tijl@coosemans.org> <201009161619.o8GGJAmv035378@lurza.secnetix.de> <20101018155944.GA12425@freebsd.org> <868w1r92rf.fsf@ds4.des.no> <20101021122110.GA65490@freebsd.org> <86zku77mj6.fsf@ds4.des.no> <20101021135442.000054c9@unknown> <20101021134114.GB72290@freebsd.org> <20101027124113.GA6206@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Cc: Bruce Cran , Tijl Coosemans , Oliver Fromme , freebsd-hackers@freebsd.org, mav@freebsd.org, Dag-Erling =?iso-8859-15?Q?Sm=F8rgrav?= Subject: Re: Summary: Re: Spin down HDD after disk sync or before power off X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 27 Oct 2010 12:54:53 -0000 On Wed Oct 27 10, Garrett Cooper wrote: > On Wed, Oct 27, 2010 at 5:41 AM, Alexander Best wrote: > > On Thu Oct 21 10, Alexander Best wrote: > >> On Thu Oct 21 10, Bruce Cran wrote: > >> > On Thu, 21 Oct 2010 14:33:49 +0200 > >> > Dag-Erling Smørgrav wrote: > >> > > >> > > The problem with setting a short idle timeout is that, on a typical > >> > > laptop or desktop system, you end up spinning the disk down and back > >> > > up several hundred times a day, which increases power consumption, I/O > >> > > latency and wear. > >> > > >> > Do we think our users are silly enough to set a short timeout of just a > >> > few minutes?  I'd think most would use a setting of 20-30 minutes at > >> > a minimum. I never did understand why there were so many warnings; > >> > after all, some laptops even come with a default APM scheme in their > >> > HDDs that powers the disk down after 7 seconds! > >> > >> personally i still think something like the attached patch would be nice to > >> have. there's a chance users might type the following: > >> > >> 'atacontrol spindown device 10' > >> > >> thinking the timeout value is measured in minutes. although this gets mentioned > >> in atacontrol(4) it might still be worth reminding the user that he/she is > >> performing actions which could damage the hardware. > > > > i just stumbled upon PR 144770, where a somebody seems to have mistaken the > > spindown value for minutes instead of seconds. so i really think we should have > > this warning in atacontrol! > > > > +1 from brucec, if i understood him correctly. > > > > another possibility would be of course changing the spindown value from seconds > > to minutes. imo this seems very reasonable, because measuring spindown time in > > seconds is too fine grained and not intuitive. just like specifying the > > 'shutdown -p XX' delay in microseconds would not be useful. ;) > > > > cheers. > > alex > > > >> > >> cheers. > >> alex > >> > >> > > >> > -- > >> > Bruce Cran > >> > >> -- > >> a13x > > > >> diff --git a/sbin/atacontrol/atacontrol.c b/sbin/atacontrol/atacontrol.c > >> index 4354ddf..75a131a 100644 > >> --- a/sbin/atacontrol/atacontrol.c > >> +++ b/sbin/atacontrol/atacontrol.c > >> @@ -317,6 +317,10 @@ ata_spindown(int fd, const char *dev, const char *arg) > >> > >>       if (arg != NULL) { > >>               tmo = strtoul(arg, NULL, 0); > >> +             if (tmo < 600) > >> +                     warnx("setting spindown timeout below 10 minutes is \ > >> +                           not recommended (see EXAMPLES section of \ > >> +                           atacontrol(8))\n"); > >>               if (ioctl(fd, IOCATASSPINDOWN, &tmo) < 0) > >>                       err(1, "ioctl(IOCATASSPINDOWN)"); > >>       } else { > > Why not just be consistent with other interfaces and provide > suffixes for the values to parse out integral times (i.e. 1 [second], > 1m, 2h)? As long as the value is behavior is properly documented in > the manpage (and potentially as examples in the usage message), that > should be enough. that would increase usability, since users don't have to specify large values in seconds, if they e.g. want the spindown to happen after 24 hours (24*60*60). but this will not solve the real issue: specifying 'atacontrol spindown 1s' WILL damage your hardware! imo users should be reminded about this even if this is already mentioned in the manual. also: will current scripts which set 'atacontrol spindown 600' e.g. continue to work after implementing the use of suffixes? > Thanks, > -Garrett -- a13x From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 27 13:02:02 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 6EBF2106564A; Wed, 27 Oct 2010 13:02:02 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id 97B048FC13; Wed, 27 Oct 2010 13:02:01 +0000 (UTC) Received: by wwi18 with SMTP id 18so1533924wwi.1 for ; Wed, 27 Oct 2010 06:02: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=R2bQPTQxe6Gm+mSj6EXmuSsshccXrgEovaqRB5pxXZo=; b=G3FND6PPd4XvGNmOKAPExSAWir/MAmP7JlgnQCP9u1N9Flq3XaloDnM5jy6GCMfL1U /keZQyrremh8gs05SHsf0CkfHkXzCVPZUtt8zJ8Hnr42wdCozywaIXqdeOBugk8wR0wm WBm6zMlweZUF9Pvo7kunkr0jR6DPamyAzKzH4= 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=AUTtvK5Nvf1zUiuZp6wLcwA2OPeWYXjCm2xC52wpyv42pKSQyZi70DlrfK35elj5WR yMY+HEqqyv/QGe4MLhs3jXDi2YbuQQQETBXNLIAe2XEXVfRb4eim2Leidg6ZqHrfyB/W Z/XKwRW+kqfYwycd0MvbB0fwS5vpXDzcAh+gM= MIME-Version: 1.0 Received: by 10.227.134.142 with SMTP id j14mr9286672wbt.228.1288184520416; Wed, 27 Oct 2010 06:02:00 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.216.10.198 with HTTP; Wed, 27 Oct 2010 06:02:00 -0700 (PDT) In-Reply-To: <20101027125453.GA8433@freebsd.org> References: <201009161742.24228.tijl@coosemans.org> <201009161619.o8GGJAmv035378@lurza.secnetix.de> <20101018155944.GA12425@freebsd.org> <868w1r92rf.fsf@ds4.des.no> <20101021122110.GA65490@freebsd.org> <86zku77mj6.fsf@ds4.des.no> <20101021135442.000054c9@unknown> <20101021134114.GB72290@freebsd.org> <20101027124113.GA6206@freebsd.org> <20101027125453.GA8433@freebsd.org> Date: Wed, 27 Oct 2010 06:02:00 -0700 X-Google-Sender-Auth: Z0pwczK4aykoq2EyPFPpVxiHlg8 Message-ID: From: Garrett Cooper To: Alexander Best Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Bruce Cran , Tijl Coosemans , Oliver Fromme , freebsd-hackers@freebsd.org, mav@freebsd.org, =?ISO-8859-1?Q?Dag=2DErling_Sm=F8rgrav?= Subject: Re: Summary: Re: Spin down HDD after disk sync or before power off X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 27 Oct 2010 13:02:02 -0000 On Wed, Oct 27, 2010 at 5:54 AM, Alexander Best wrote= : > On Wed Oct 27 10, Garrett Cooper wrote: >> On Wed, Oct 27, 2010 at 5:41 AM, Alexander Best wr= ote: >> > On Thu Oct 21 10, Alexander Best wrote: >> >> On Thu Oct 21 10, Bruce Cran wrote: >> >> > On Thu, 21 Oct 2010 14:33:49 +0200 >> >> > Dag-Erling Sm=F8rgrav wrote: >> >> > >> >> > > The problem with setting a short idle timeout is that, on a typic= al >> >> > > laptop or desktop system, you end up spinning the disk down and b= ack >> >> > > up several hundred times a day, which increases power consumption= , I/O >> >> > > latency and wear. >> >> > >> >> > Do we think our users are silly enough to set a short timeout of ju= st a >> >> > few minutes? =A0I'd think most would use a setting of 20-30 minutes= at >> >> > a minimum. I never did understand why there were so many warnings; >> >> > after all, some laptops even come with a default APM scheme in thei= r >> >> > HDDs that powers the disk down after 7 seconds! >> >> >> >> personally i still think something like the attached patch would be n= ice to >> >> have. there's a chance users might type the following: >> >> >> >> 'atacontrol spindown device 10' >> >> >> >> thinking the timeout value is measured in minutes. although this gets= mentioned >> >> in atacontrol(4) it might still be worth reminding the user that he/s= he is >> >> performing actions which could damage the hardware. >> > >> > i just stumbled upon PR 144770, where a somebody seems to have mistake= n the >> > spindown value for minutes instead of seconds. so i really think we sh= ould have >> > this warning in atacontrol! >> > >> > +1 from brucec, if i understood him correctly. >> > >> > another possibility would be of course changing the spindown value fro= m seconds >> > to minutes. imo this seems very reasonable, because measuring spindown= time in >> > seconds is too fine grained and not intuitive. just like specifying th= e >> > 'shutdown -p XX' delay in microseconds would not be useful. ;) >> > >> > cheers. >> > alex >> > >> >> >> >> cheers. >> >> alex >> >> >> >> > >> >> > -- >> >> > Bruce Cran >> >> >> >> -- >> >> a13x >> > >> >> diff --git a/sbin/atacontrol/atacontrol.c b/sbin/atacontrol/atacontro= l.c >> >> index 4354ddf..75a131a 100644 >> >> --- a/sbin/atacontrol/atacontrol.c >> >> +++ b/sbin/atacontrol/atacontrol.c >> >> @@ -317,6 +317,10 @@ ata_spindown(int fd, const char *dev, const char= *arg) >> >> >> >> =A0 =A0 =A0 if (arg !=3D NULL) { >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 tmo =3D strtoul(arg, NULL, 0); >> >> + =A0 =A0 =A0 =A0 =A0 =A0 if (tmo < 600) >> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 warnx("setting spindown tim= eout below 10 minutes is \ >> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 not recommended= (see EXAMPLES section of \ >> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 atacontrol(8))\= n"); >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (ioctl(fd, IOCATASSPINDOWN, &tmo) < 0) >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 err(1, "ioctl(IOCATASSPIN= DOWN)"); >> >> =A0 =A0 =A0 } else { >> >> =A0 =A0 Why not just be consistent with other interfaces and provide >> suffixes for the values to parse out integral times (i.e. 1 [second], >> 1m, 2h)? As long as the value is behavior is properly documented in >> the manpage (and potentially as examples in the usage message), that >> should be enough. > > that would increase usability, since users don't have to specify large va= lues > in seconds, if they e.g. want the spindown to happen after 24 hours (24*6= 0*60). > but this will not solve the real issue: specifying 'atacontrol spindown 1= s' > WILL damage your hardware! imo users should be reminded about this even i= f this > is already mentioned in the manual. Maybe something similar to kern.geom.debugflags should be implemented for this feature as a safety belt for people doing something stupid? > also: will current scripts which set 'atacontrol spindown 600' e.g. conti= nue to > work after implementing the use of suffixes? Yeah... why not :)? Thanks! -Garrett From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 27 13:05:06 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 5F8641065679; Wed, 27 Oct 2010 13:05:06 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0D17B8FC16; Wed, 27 Oct 2010 13:05:04 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id o9RD4ela043181; Wed, 27 Oct 2010 15:04:55 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id o9RD4e9Q043179; Wed, 27 Oct 2010 15:04:40 +0200 (CEST) (envelope-from olli) From: Oliver Fromme Message-Id: <201010271304.o9RD4e9Q043179@lurza.secnetix.de> To: arundel@FreeBSD.ORG (Alexander Best) Date: Wed, 27 Oct 2010 15:04:39 +0200 (CEST) In-Reply-To: <20101027124113.GA6206@freebsd.org> X-Mailer: ELM [version 2.5 PL8] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.5 (lurza.secnetix.de [127.0.0.1]); Wed, 27 Oct 2010 15:04:55 +0200 (CEST) Cc: Bruce Cran , Dag-Erling =?iso-8859-15?Q?Sm=F8rgrav?= , mav@FreeBSD.ORG, Tijl Coosemans , freebsd-hackers@FreeBSD.ORG Subject: Re: Summary: Re: Spin down HDD after disk sync or before power off X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 27 Oct 2010 13:05:06 -0000 Alexander Best wrote: > i just stumbled upon PR 144770, where a somebody seems to have mistaken the > spindown value for minutes instead of seconds. so i really think we should have > this warning in atacontrol! > > +1 from brucec, if i understood him correctly. > > another possibility would be of course changing the spindown value from seconds > to minutes. imo this seems very reasonable, because measuring spindown time in > seconds is too fine grained and not intuitive. just like specifying the > 'shutdown -p XX' delay in microseconds would not be useful. ;) No, please don't. Changing the meaning of the value from seconds to minutes will break people's existing setups. I'm also against printing a warning for values less than 600. If I want to set the value to 300, I don't want to be slapped with a useless warning. Also note that 300 (and even much less) might be perfectly reasonable, depending on the kind of device! As a rule of thumb, the smaller a drive, the better it is optimized for many spin up/down cycles. For example, I've got a portable HDD mp3 player that contains a 1.8" disk. When playing an mp3 file, it spins up every 20 seconds or so, reads 500 KB, then spins down again. In my opinion, this is purely a documentation issue. If it is well-documented that the spindown value is given in seconds, then that should be sufficient. Supporting values like "5m" or "1h" would be fine, as long as a value without a letter still means seconds. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Python is an experiment in how much freedom programmers need. Too much freedom and nobody can read another's code; too little and expressiveness is endangered." -- Guido van Rossum From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 27 13:21: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 8FDC21065679 for ; Wed, 27 Oct 2010 13:21:31 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id EB7CB8FC1D for ; Wed, 27 Oct 2010 13:21:30 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id o9RDLEOW043779; Wed, 27 Oct 2010 15:21:29 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id o9RDLEkP043777; Wed, 27 Oct 2010 15:21:14 +0200 (CEST) (envelope-from olli) From: Oliver Fromme Message-Id: <201010271321.o9RDLEkP043777@lurza.secnetix.de> To: arundel@FreeBSD.ORG (Alexander Best) Date: Wed, 27 Oct 2010 15:21:14 +0200 (CEST) In-Reply-To: <20101027125453.GA8433@freebsd.org> X-Mailer: ELM [version 2.5 PL8] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.5 (lurza.secnetix.de [127.0.0.1]); Wed, 27 Oct 2010 15:21:30 +0200 (CEST) Cc: Bruce Cran , Tijl Coosemans , freebsd-hackers@FreeBSD.ORG, mav@FreeBSD.ORG, Garrett Cooper , Dag-Erling =?iso-8859-15?Q?Sm=F8rgrav?= Subject: Re: Summary: Re: Spin down HDD after disk sync or before power off X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 27 Oct 2010 13:21:31 -0000 Alexander Best wrote: > but this will not solve the real issue: specifying 'atacontrol > spindown 1s' WILL damage your hardware! You're making assumptions. I can very well imagine scenarios where 1s might make sense and will not damage the hardware, for example when there is no file system mounted from the disk in question. For several years I ran a BBS machine that ran off a memory disk. Every 24 hours it made a backup of its current state by writing a tar file to the raw device of a physical disk (there were no file systems mounted from that disk). Having a spindown time of 1s in such a context certainly wouldn't hurt. Best regards Oliver PS: Please allow me to copy a few things from my collection of quotes which fit very well here: "UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things." -- Doug Gwyn "If you aim the gun at your foot and pull the trigger, it's UNIX's job to ensure reliable delivery of the bullet to where you aimed the gun (in this case, Mr. Foot)." -- Terry Lambert "Unix gives you just enough rope to hang yourself -- and then a couple of more feet, just to be sure." -- Eric Allman -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd I suggested holding a "Python Object Oriented Programming Seminar", but the acronym was unpopular. -- Joseph Strout From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 27 13:26: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 DF41D106564A for ; Wed, 27 Oct 2010 13:26:14 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 91F0F8FC0A for ; Wed, 27 Oct 2010 13:26:14 +0000 (UTC) Received: by qyk7 with SMTP id 7so3598743qyk.13 for ; Wed, 27 Oct 2010 06:26:13 -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=UVYrvRzvJuQHYhIyQOJ742DdPARhfUZ572wQuF0VV5g=; b=Gf3+IvbpsZNVFRZXJjFDRtsCYskezzumOPKQpu75RCVmc22eU2JJwejQHbC2gT0e7K cA3h6+Lc2C3smhmdt90jmPya2XXQ7mfb41HUj/1Rc9GYuAr1WStKJ1sSs/Xi+vrjUjUg MN5U8WRGx4Na3FvRbPIJsXeQr2BjAYHRdy5cs= 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=vcQ7vYzN6yr88aMwodu+x/BrehX7Gk3GdZG3OwN2Vst2JGYifb8PfTIgZNpC4aazE7 0fniuNrF0AUlxjKaRX6iQl8mgaMUW2VMR9dKMDwRcOoGbBfYfLc9imro7Lz746SvvbM8 zjFFDX5/OSICHXZKi+7aXPP4/jrR3J5IP4rZ8= MIME-Version: 1.0 Received: by 10.224.54.68 with SMTP id p4mr2583675qag.312.1288185973582; Wed, 27 Oct 2010 06:26:13 -0700 (PDT) Received: by 10.229.69.135 with HTTP; Wed, 27 Oct 2010 06:26:13 -0700 (PDT) In-Reply-To: References: <1288160610.4280.18.camel@apollon> Date: Wed, 27 Oct 2010 17:26:13 +0400 Message-ID: From: Sergey Kandaurov To: FreeBSD Hackers Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [PATCH] Fix 'implicit declaration' warning and update vgone(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 27 Oct 2010 13:26:15 -0000 On 27 October 2010 15:33, Sergey Kandaurov wrote: > On 27 October 2010 10:23, Lars Hartmann wrote: >> The vgonel function isnt declarated in any header, the vgonel prototype >> in vgone(9) isnt correct - found by Ben Kaduk > > Hi. > > I'm afraid it's just an overlooked man page after many VFS changes in 5.x. > As vgonel() is a static (i.e. private and not visible from outside) function > IMO it should be removed from vgone(9) man page. > Something like this I'd like to check in. Comments? Index: ObsoleteFiles.inc =================================================================== --- ObsoleteFiles.inc (revision 214414) +++ ObsoleteFiles.inc (working copy) @@ -14,6 +14,8 @@ # The file is partitioned: OLD_FILES first, then OLD_LIBS and OLD_DIRS last. # +# 20101027: vgonel(9) has gone to private API a while ago +OLD_FILES+=usr/share/man/man9/vgonel.9.gz # 20101020: catch up with vm_page_sleep_if_busy rename OLD_FILES+=usr/share/man/man9/vm_page_sleep_busy.9.gz # 20101011: removed subblock.h from liblzma Index: share/man/man9/Makefile =================================================================== --- share/man/man9/Makefile (revision 214413) +++ share/man/man9/Makefile (working copy) @@ -1317,7 +1317,6 @@ vfs_getopt.9 vfs_setopt_part.9 \ vfs_getopt.9 vfs_setopts.9 MLINKS+=VFS_LOCK_GIANT.9 VFS_UNLOCK_GIANT.9 -MLINKS+=vgone.9 vgonel.9 MLINKS+=vhold.9 vdrop.9 \ vhold.9 vdropl.9 \ vhold.9 vholdl.9 Index: share/man/man9/vgone.9 =================================================================== --- share/man/man9/vgone.9 (revision 214413) +++ share/man/man9/vgone.9 (working copy) @@ -26,24 +26,21 @@ .\" .\" $FreeBSD$ .\" -.Dd November 21, 2001 +.Dd October 27, 2010 .Dt VGONE 9 .Os .Sh NAME -.Nm vgone , vgonel +.Nm vgone .Nd "prepare a vnode for reuse" .Sh SYNOPSIS .In sys/param.h .In sys/vnode.h .Ft void .Fn vgone "struct vnode *vp" -.Ft void -.Fn vgonel "struct vnode *vp" "struct thread *td" .Sh DESCRIPTION +The .Fn vgone -and -.Fn vgonel -prepare a vnode for reuse by another file system. +function prepares a vnode for reuse by another file system. The preparation includes the cleaning of all file system specific data and the removal from its mount point vnode list. .Pp @@ -55,17 +52,11 @@ as in most cases the vnode is about to be reused, or its file system is being unmounted. .Pp -The difference between +The .Fn vgone -and -.Fn vgonel -is that -.Fn vgone -locks the vnode interlock and then calls -.Fn vgonel -while -.Fn vgonel -expects the interlock to already be locked. +function takes an unlocked vnode and returns with the vnode unlocked. +.Sh SEE ALSO +.Xr vnode 9 .Sh AUTHORS This manual page was written by .An Chad David Aq davidc@acns.ab.ca . Index: share/man/man9/vflush.9 =================================================================== --- share/man/man9/vflush.9 (revision 214413) +++ share/man/man9/vflush.9 (working copy) @@ -75,7 +75,6 @@ will be returned. .Sh SEE ALSO .Xr vgone 9 , -.Xr vgonel 9 , .Xr vrele 9 .Sh AUTHORS This manual page was written by -- wbr, pluknet From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 27 13:27: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 AF48D106564A for ; Wed, 27 Oct 2010 13:27:57 +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 80A688FC13 for ; Wed, 27 Oct 2010 13:27:57 +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 3231746B2E; Wed, 27 Oct 2010 09:27:57 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id DB37E8A009; Wed, 27 Oct 2010 09:27:55 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Wed, 27 Oct 2010 09:12:47 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <1288160610.4280.18.camel@apollon> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201010270912.47076.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 27 Oct 2010 09:27:55 -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: Lars Hartmann , Sergey Kandaurov Subject: Re: [PATCH] Fix 'implicit declaration' warning and update vgone(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 27 Oct 2010 13:27:57 -0000 On Wednesday, October 27, 2010 7:33:13 am Sergey Kandaurov wrote: > On 27 October 2010 10:23, Lars Hartmann wrote: > > The vgonel function isnt declarated in any header, the vgonel prototype > > in vgone(9) isnt correct - found by Ben Kaduk > > Hi. > > I'm afraid it's just an overlooked man page after many VFS changes in 5.x. > As vgonel() is a static (i.e. private and not visible from outside) function > IMO it should be removed from vgone(9) man page. Agreed. It certainly should not be added to vnode.h. I'm curious how the reporter is getting a warning since there is a static prototype for vgonel() in vfs_subr.c. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 27 13:29:08 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 81B60106566B; Wed, 27 Oct 2010 13:29:08 +0000 (UTC) (envelope-from mavbsd@gmail.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 A0F0F8FC2B; Wed, 27 Oct 2010 13:29:07 +0000 (UTC) Received: by bwz3 with SMTP id 3so550491bwz.13 for ; Wed, 27 Oct 2010 06:29:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=t7v9XW2GvWEdMioej4IMrJpO2AB5TSp4CvMk/a4GUaE=; b=CNRJ56M51sntM4r7zpzMnoV6KWOqMq0FQ5m+V7SEQyxqq8htOTCCkZRzr1p0Q4rWPw LvcK+NIeFzkXuKBuulmQcxQjpGlUW/lecKZuCwnQ3W+xiW5LpgRjUjZXa/RvVuU5oKcG baZHVAjpJSbRNoe8jtqf6u001KF40gnLoYWhc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=Mo4U9WvRvP2DWgQX1Hvk3prPrPDMk1CQKk5cERomahd5K3bxGW6JQmXsCsLT3gLi9X zhpcG223PQ4wJGmgKdVJg94KmuJwDzVquhvdrES+39HqjtNm0Mf/79AYWl1NJtwhy8ia Ggl18W9a5Bw0pFjnN0cpxtSZDaYvPVFXaetUw= Received: by 10.204.73.13 with SMTP id o13mr7162565bkj.173.1288186146348; Wed, 27 Oct 2010 06:29:06 -0700 (PDT) Received: from mavbook.mavhome.dp.ua ([91.198.175.253]) by mx.google.com with ESMTPS id 4sm6972290bki.1.2010.10.27.06.29.03 (version=SSLv3 cipher=RC4-MD5); Wed, 27 Oct 2010 06:29:04 -0700 (PDT) Sender: Alexander Motin Message-ID: <4CC8291E.1060002@FreeBSD.org> Date: Wed, 27 Oct 2010 16:29:02 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: Alexander Best References: <201009161742.24228.tijl@coosemans.org> <201009161619.o8GGJAmv035378@lurza.secnetix.de> <20101018155944.GA12425@freebsd.org> <868w1r92rf.fsf@ds4.des.no> <20101021122110.GA65490@freebsd.org> <86zku77mj6.fsf@ds4.des.no> <20101021135442.000054c9@unknown> <20101021134114.GB72290@freebsd.org> <20101027124113.GA6206@freebsd.org> <20101027125453.GA8433@freebsd.org> In-Reply-To: <20101027125453.GA8433@freebsd.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: Bruce Cran , Tijl Coosemans , Oliver Fromme , freebsd-hackers@freebsd.org, Garrett Cooper , =?ISO-8859-15?Q?Dag-Erling_Sm=F8rgrav?= Subject: Re: Summary: Re: Spin down HDD after disk sync or before power off X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 27 Oct 2010 13:29:08 -0000 Alexander Best wrote: > On Wed Oct 27 10, Garrett Cooper wrote: >> Why not just be consistent with other interfaces and provide >> suffixes for the values to parse out integral times (i.e. 1 [second], >> 1m, 2h)? As long as the value is behavior is properly documented in >> the manpage (and potentially as examples in the usage message), that >> should be enough. > > that would increase usability, since users don't have to specify large values > in seconds, if they e.g. want the spindown to happen after 24 hours (24*60*60). Largest value that could be set more or less precisely for ATA disks is 5.5hours. Absolute maximum is 12 hours. So 24h interval is just inapplicable. > but this will not solve the real issue: specifying 'atacontrol spindown 1s' > WILL damage your hardware! imo users should be reminded about this even if this > is already mentioned in the manual. I would say "WILL" depends on hardware. And it's reasonability also depends on situation. -- Alexander Motin From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 27 13:30:50 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 DD502106566B; Wed, 27 Oct 2010 13:30:50 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id 6D7B78FC16; Wed, 27 Oct 2010 13:30:50 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id ACA42E801E; Wed, 27 Oct 2010 14:30:49 +0100 (BST) Received: from unknown (client-81-107-142-135.midd.adsl.virginmedia.com [81.107.142.135]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA; Wed, 27 Oct 2010 14:30:48 +0100 (BST) Date: Wed, 27 Oct 2010 14:30:44 +0100 From: Bruce Cran To: Oliver Fromme Message-ID: <20101027143044.00005b14@unknown> In-Reply-To: <201010271304.o9RD4e9Q043179@lurza.secnetix.de> References: <20101027124113.GA6206@freebsd.org> <201010271304.o9RD4e9Q043179@lurza.secnetix.de> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Dag-Erling, Tijl Coosemans , freebsd-hackers@FreeBSD.ORG, mav@FreeBSD.ORG, =?ISO-8859-1?Q?grav?= , Alexander Best Subject: Re: Summary: Re: Spin down HDD after disk sync or before power off X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 27 Oct 2010 13:30:50 -0000 On Wed, 27 Oct 2010 15:04:39 +0200 (CEST) Oliver Fromme wrote: > I'm also against printing a warning for values less than 600. > If I want to set the value to 300, I don't want to be slapped > with a useless warning. Having just checked Windows and seen that it lets you specify a timeout down to 1 minute with no warnings, I don't think we want to make it more difficult for people to do the same thing on FreeBSD. I don't know if atacontrol already does this, but maybe we could have a log entry, for example: > atacontrol /dev/ad0 spindown 60 spin-down timer set to 60 seconds. -- Bruce Cran From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 27 14:41:59 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 76C75106566B for ; Wed, 27 Oct 2010 14:41:59 +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 1096A8FC18 for ; Wed, 27 Oct 2010 14:41:58 +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 o9REfsT3086335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Oct 2010 17:41:54 +0300 (EEST) (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 o9REfsmf054599; Wed, 27 Oct 2010 17:41:54 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o9REfsqp054598; Wed, 27 Oct 2010 17:41:54 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 27 Oct 2010 17:41:54 +0300 From: Kostik Belousov To: Sergey Kandaurov Message-ID: <20101027144154.GR2392@deviant.kiev.zoral.com.ua> References: <1288160610.4280.18.camel@apollon> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="riavyPkMxoG9YVVB" Content-Disposition: inline In-Reply-To: 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 Subject: Re: [PATCH] Fix 'implicit declaration' warning and update vgone(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 27 Oct 2010 14:41:59 -0000 --riavyPkMxoG9YVVB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 27, 2010 at 05:26:13PM +0400, Sergey Kandaurov wrote: > On 27 October 2010 15:33, Sergey Kandaurov wrote: > > On 27 October 2010 10:23, Lars Hartmann wrote: > >> The vgonel function isnt declarated in any header, the vgonel prototype > >> in vgone(9) isnt correct - found by Ben Kaduk > > > > Hi. > > > > I'm afraid it's just an overlooked man page after many VFS changes in 5= .x. > > As vgonel() is a static (i.e. private and not visible from outside) fun= ction > > IMO it should be removed from vgone(9) man page. > > >=20 > Something like this I'd like to check in. Comments? >=20 > Index: ObsoleteFiles.inc > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- ObsoleteFiles.inc (revision 214414) > +++ ObsoleteFiles.inc (working copy) > @@ -14,6 +14,8 @@ > # The file is partitioned: OLD_FILES first, then OLD_LIBS and OLD_DIRS l= ast. > # >=20 > +# 20101027: vgonel(9) has gone to private API a while ago > +OLD_FILES+=3Dusr/share/man/man9/vgonel.9.gz > # 20101020: catch up with vm_page_sleep_if_busy rename > OLD_FILES+=3Dusr/share/man/man9/vm_page_sleep_busy.9.gz > # 20101011: removed subblock.h from liblzma > Index: share/man/man9/Makefile > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- share/man/man9/Makefile (revision 214413) > +++ share/man/man9/Makefile (working copy) > @@ -1317,7 +1317,6 @@ > vfs_getopt.9 vfs_setopt_part.9 \ > vfs_getopt.9 vfs_setopts.9 > MLINKS+=3DVFS_LOCK_GIANT.9 VFS_UNLOCK_GIANT.9 > -MLINKS+=3Dvgone.9 vgonel.9 > MLINKS+=3Dvhold.9 vdrop.9 \ > vhold.9 vdropl.9 \ > vhold.9 vholdl.9 > Index: share/man/man9/vgone.9 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- share/man/man9/vgone.9 (revision 214413) > +++ share/man/man9/vgone.9 (working copy) > @@ -26,24 +26,21 @@ > .\" > .\" $FreeBSD$ > .\" > -.Dd November 21, 2001 > +.Dd October 27, 2010 > .Dt VGONE 9 > .Os > .Sh NAME > -.Nm vgone , vgonel > +.Nm vgone > .Nd "prepare a vnode for reuse" > .Sh SYNOPSIS > .In sys/param.h > .In sys/vnode.h > .Ft void > .Fn vgone "struct vnode *vp" > -.Ft void > -.Fn vgonel "struct vnode *vp" "struct thread *td" > .Sh DESCRIPTION > +The > .Fn vgone > -and > -.Fn vgonel > -prepare a vnode for reuse by another file system. > +function prepares a vnode for reuse by another file system. I think it is more correct now "prepares the vnode to be destroyed" instead. > The preparation includes the cleaning of all file system specific data a= nd > the removal from its mount point vnode list. > .Pp --riavyPkMxoG9YVVB Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAkzIOjEACgkQC3+MBN1Mb4iBVQCdGJsG687kEDbkwUJiL2Ytnics gdIAnA+DTpXGxcB9FSnaoGsd862MSH4x =wQWq -----END PGP SIGNATURE----- --riavyPkMxoG9YVVB-- From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 27 15:00:02 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 47359106566B for ; Wed, 27 Oct 2010 15:00:02 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-6.mit.edu (DMZ-MAILSEC-SCANNER-6.MIT.EDU [18.7.68.35]) by mx1.freebsd.org (Postfix) with ESMTP id 61F6B8FC12 for ; Wed, 27 Oct 2010 15:00:00 +0000 (UTC) X-AuditID: 12074423-b7bd0ae000000a00-b3-4cc83e7061c4 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-6.mit.edu (Symantec Brightmail Gateway) with SMTP id 3B.41.02560.07E38CC4; Wed, 27 Oct 2010 11:00:00 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id o9RExxGP016599; Wed, 27 Oct 2010 11:00:00 -0400 Received: from multics.mit.edu (MULTICS.MIT.EDU [18.187.1.73]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id o9RExvj7012547 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 27 Oct 2010 10:59:58 -0400 (EDT) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id o9RExuuj006083; Wed, 27 Oct 2010 10:59:56 -0400 (EDT) Date: Wed, 27 Oct 2010 10:59:56 -0400 (EDT) From: Benjamin Kaduk To: John Baldwin In-Reply-To: <201010270912.47076.jhb@freebsd.org> Message-ID: References: <1288160610.4280.18.camel@apollon> <201010270912.47076.jhb@freebsd.org> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Brightmail-Tracker: AAAAAA== Cc: freebsd-hackers@freebsd.org, Sergey Kandaurov , Lars Hartmann Subject: Re: [PATCH] Fix 'implicit declaration' warning and update vgone(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 27 Oct 2010 15:00:02 -0000 On Wed, 27 Oct 2010, John Baldwin wrote: > On Wednesday, October 27, 2010 7:33:13 am Sergey Kandaurov wrote: >> On 27 October 2010 10:23, Lars Hartmann wrote: >>> The vgonel function isnt declarated in any header, the vgonel prototype >>> in vgone(9) isnt correct - found by Ben Kaduk >> >> Hi. >> >> I'm afraid it's just an overlooked man page after many VFS changes in 5.x. >> As vgonel() is a static (i.e. private and not visible from outside) function >> IMO it should be removed from vgone(9) man page. > > Agreed. It certainly should not be added to vnode.h. I'm curious how the > reporter is getting a warning since there is a static prototype for vgonel() > in vfs_subr.c. It's for a third-party kernel module, for the OpenAFS filesystem (which has been unloved for FreeBSD since the 4.X days). The AFS code is currently using unlocked accesses to v_usecount (which, unsurprisingly, led to a race condition that caused an invariant check to fail), and I was going through and adding the interlock around them. At the place that I suspect to be the main cause of this race [1], the usecount was checked to be nonpositive along with a couple other conditions, and a little later vgone() was called. Holding the interlock across both of these calls (and therefore using vgonel()) seems to have closed the race condition I was seeing. (Other checks of v_usecount were changed to grab the interlock, but drop it before doing anything else.) However, looking at the commit message for vfs_subr.c:1.631, I guess this is not the locking strategy I'm supposed to be using? I saw a warning of implicit declaration when compiling the kernel module, but the kernel linker was happy to load it. I forget whether it matters that vgonel is only declared static at its declaration but not its definition. -Ben Kaduk [1] The old (racy) function is osi_TryEvictVCache, here: http://git.openafs.org/?p=openafs.git;a=blob;f=src/afs/FBSD/osi_vcache.c;h=c2060c74f0155a610d2ea94f3c7f508e8ca4373a;hb=HEAD From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 27 15:35: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 726A51065674; Wed, 27 Oct 2010 15:35:14 +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 0705E8FC20; Wed, 27 Oct 2010 15:35:13 +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 o9RFY3HB090484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Oct 2010 18:34:03 +0300 (EEST) (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 o9RFY39v090140; Wed, 27 Oct 2010 18:34:03 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o9RFY2MX090139; Wed, 27 Oct 2010 18:34:02 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 27 Oct 2010 18:34:02 +0300 From: Kostik Belousov To: Benjamin Kaduk Message-ID: <20101027153402.GS2392@deviant.kiev.zoral.com.ua> References: <1288160610.4280.18.camel@apollon> <201010270912.47076.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="37ZONDoqvyhZS3Cx" Content-Disposition: inline In-Reply-To: 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=-2.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_05, 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, Sergey Kandaurov , Lars Hartmann Subject: Re: [PATCH] Fix 'implicit declaration' warning and update vgone(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 27 Oct 2010 15:35:14 -0000 --37ZONDoqvyhZS3Cx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 27, 2010 at 10:59:56AM -0400, Benjamin Kaduk wrote: > On Wed, 27 Oct 2010, John Baldwin wrote: >=20 > >On Wednesday, October 27, 2010 7:33:13 am Sergey Kandaurov wrote: > >>On 27 October 2010 10:23, Lars Hartmann wrote: > >>>The vgonel function isnt declarated in any header, the vgonel prototype > >>>in vgone(9) isnt correct - found by Ben Kaduk > >> > >>Hi. > >> > >>I'm afraid it's just an overlooked man page after many VFS changes in 5= .x. > >>As vgonel() is a static (i.e. private and not visible from outside)=20 > >>function > >>IMO it should be removed from vgone(9) man page. > > > >Agreed. It certainly should not be added to vnode.h. I'm curious how t= he > >reporter is getting a warning since there is a static prototype for=20 > >vgonel() > >in vfs_subr.c. >=20 > It's for a third-party kernel module, for the OpenAFS filesystem (which= =20 > has been unloved for FreeBSD since the 4.X days). The AFS code is=20 > currently using unlocked accesses to v_usecount (which, unsurprisingly,= =20 > led to a race condition that caused an invariant check to fail), and I wa= s=20 > going through and adding the interlock around them. At the place that I= =20 > suspect to be the main cause of this race [1], the usecount was checked t= o=20 > be nonpositive along with a couple other conditions, and a little later= =20 > vgone() was called. Holding the interlock across both of these calls (an= d=20 > therefore using vgonel()) seems to have closed the race condition I was= =20 > seeing. (Other checks of v_usecount were changed to grab the interlock,= =20 > but drop it before doing anything else.) > However, looking at the commit message for vfs_subr.c:1.631, I guess this= =20 > is not the locking strategy I'm supposed to be using? >=20 > I saw a warning of implicit declaration when compiling the kernel module,= =20 > but the kernel linker was happy to load it. I forget whether it matters= =20 > that vgonel is only declared static at its declaration but not its=20 > definition. >=20 > -Ben Kaduk >=20 >=20 > [1] The old (racy) function is osi_TryEvictVCache, here: > http://git.openafs.org/?p=3Dopenafs.git;a=3Dblob;f=3Dsrc/afs/FBSD/osi_vca= che.c;h=3Dc2060c74f0155a610d2ea94f3c7f508e8ca4373a;hb=3DHEAD The function looks very strange for much more serious reasons. Why do you try to manage the vnode revocation in the filesystem module at all ? VFS will (assumedly in a right way) revoke and destroy non-referenced vnodes when needed. Anyway, you need to hold vnode lock before checking for the vnode refcounte= r. See the vfs_subr.c:vlrureclaim() for the correct dance with vholdl()/vn_loc= k() sequence that does the revocation I mentioned in the race-free way. --37ZONDoqvyhZS3Cx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAkzIRmoACgkQC3+MBN1Mb4hBfgCgj/TfCiP37gkAWduqkwKUcVUu znIAnAjXynCj/fREjD+isFv8JUSwMxko =dK3o -----END PGP SIGNATURE----- --37ZONDoqvyhZS3Cx-- From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 27 17:43:42 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with SMTP id 6AB06106566C; Wed, 27 Oct 2010 17:43:41 +0000 (UTC) (envelope-from nork@FreeBSD.org) Date: Thu, 28 Oct 2010 02:43:40 +0900 From: Norikatsu Shigemura To: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Message-Id: <20101028024340.38c88103.nork@FreeBSD.org> X-Mailer: Sylpheed 3.0.3 (GTK+ 2.20.1; i386-portbld-freebsd8.1) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Thu__28_Oct_2010_02_43_40_+0900_JtScQ_e/yKAD9/CK" Cc: tss-project@genua.de, Hans-Joerg Hoexer , nork@FreeBSD.org, takawata@FreeBSD.org Subject: [CFT] TPM(Trusted Platform Modules) replated ports X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 17:43:43 -0000 This is a multi-part message in MIME format. --Multipart=_Thu__28_Oct_2010_02_43_40_+0900_JtScQ_e/yKAD9/CK Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi TPM users! I reworked bsssd[*] ports as modern-improved ports. So please test attached ports. If test is ok, I'll commit these. [*] http://bsssd.sourceforge.net/download.html#id5 Ports in bsssd are following status: TrouSerS reworked, quite ok tpm_tools reworked, quite ok openssl_tpm_engine crashed on my environment, so now reworking as high priority opencryptoki reworked, quite ok Trusted GRUB not interesting, so I don't rework it TPMemulator reworked, maybe well, but not tested TPM testsuite not interesting, but I'll rework as middle priority I discussed MFC to RELENG_8 with takawata@, so I decided to do MFC by me. (takawata, thanks for my following-up!) Please wait a middle time:-). I tested these ports and got following results on 9-current: (installed) TrouSerS, opencryptoki and tpm_tools (started daemons) service tcsd start; service pkcsslotd start $ id nork uid=1000(nork) gid=1000(users) groups=1000(users),0(wheel),5(operator),602(_pkcs11),601(_tss) $ tpm_version TPM 1.2 Version Info: Chip Version: 1.2.3.16 Spec Level: 2 Errata Revision: 2 TPM Vendor ID: IFX Vendor Specific data: 0310000a 00 TPM Version: 01010000 Manufacturer Info: 49465800 $ tpm_getpubek Public Endorsement Key: Version: 01010000 Usage: 0x0002 (Unknown) Flags: 0x00000000 (!VOLATILE, !MIGRATABLE, !REDIRECTION) AuthUsage: 0x00 (Never) Algorithm: 0x00000020 (Unknown) Encryption Scheme: 0x00000012 (Unknown) Signature Scheme: 0x00000010 (Unknown) Public Key: baa42f29 16a038da eb41f256 d7ad3351 d324b802 d380d92a 7414102e 274331b0 abdfc8a6 b731f365 29f64975 eabaca79 8b254f66 b7496fa8 2fc580d4 6d7cfc2a : $ tpm_setpresence -a Tspi_TPM_SetStatus failed: 0x00000003 - layer=tpm, code=0003 (3), Bad Parameter Change to Physical Presence Failed $ tpm_clear -f Tspi_TPM_ClearOwner failed: 0x0000002d - layer=tpm, code=002d (45), Bad physical presence value (I did these operations on single user mode, so I initialized by BIOS instead of these). $ tpm_takeownership -y -z (no messages, ok) $ pkcsconf -s -c0 Slot #0 Info Description: FreeBSD 9.0-CURRENT FreeBSD (TPM) Manufacturer: FreeBSD 9.0-CURRENT Flags: 0x5 (TOKEN_PRESENT|HW_SLOT) Hardware Version: 0.0 $ pkcsconf -I -c0 Enter the SO PIN: ********** Enter a unique token label: IBM PKCS#11 TPM Token $ pkcsconf -t -c0 Token #0 Info: Label: IBM PKCS#11 TPM Token Manufacturer: IBM Corp. Model: TPM v1.1 Token Serial Number: 123 Flags: 0x880445 (RNG|LOGIN_REQUIRED|CLOCK_ON_TOKEN|TOKEN_INITIALIZED|USER_PIN_TO_BE_CHANGED|SO_PIN_TO_BE_CHANGED) Sessions: -1/-1 R/W Sessions: -1/-1 PIN Length: 6-127 Public Memory: 0xFFFFFFFF/0xFFFFFFFF Private Memory: 0xFFFFFFFF/0xFFFFFFFF Hardware Version: 1.0 Firmware Version: 1.0 Time: 02:13:50 $ tpmtoken_init -k "IBM PKCS#11 TPM Token" Warning: The TPM token has already been initialized. Reinitializing the TPM token will cause all TPM token data to be lost. Clear the TPM token data? [y/N]: y Enter the TPM security officer password: ********** A new TPM security officer password is needed. The password must be between 6 and 127 characters in length. Enter new password: ********** Confirm password: ********** C_SetPIN failed: 0x00000006 (6) (Hum.......) $ ssh -vv -Ilibopencryptoki.so localhost OpenSSH_5.5p1 FreeBSD-20100428, OpenSSL 0.9.8n 24 Mar 2010 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * : debug1: manufacturerID cryptokiVersion 2.11 libraryDescription libraryVersion 2.3 debug1: label manufacturerID model serial <123> flags 0x880445 debug1: label manufacturerID model serial <123> flags 0x880045 no keys : I want to use on ssh, wpa_spplicant, SSL and firefox. But I don't know how to. There are few tutorials to do my hope:-(. Please teach me TPM related 'can do'! SEE ALSO: http://www.ibm.com/developerworks/linux/library/s-pkcs/ http://www.osxbook.com/book/bonus/chapter10/tpm/ http://blog.4zal.net/2009/06/12/kryptografia-trusted-platform-module-i-ubuntu/ http://infond.blogspot.com/2010/03/trusted-platforms-module-tpm-openssl.html http://infond.blogspot.com/2010/04/tutorial-mutual-authentication-trusted.html Thank you. -- Norikatsu Shigemura --Multipart=_Thu__28_Oct_2010_02_43_40_+0900_JtScQ_e/yKAD9/CK Content-Type: text/plain; name="trousers.shar" Content-Disposition: attachment; filename="trousers.shar" Content-Transfer-Encoding: 7bit # This is a shell archive. Save it in a file, remove anything before # this line, and then unpack it by entering "sh file". Note, it may # create directories; files and directories will be owned by you and # have default permissions. # # This archive contains: # # trousers # trousers/Makefile # trousers/Makefile.man # trousers/distinfo # trousers/files # trousers/files/patch-configure.in # trousers/files/patch-dist-Makefile.am # trousers/files/patch-dist-tcsd.conf.in # trousers/files/patch-src-include-biosem.h # trousers/files/patch-src-include-linux-tpm.h # trousers/files/patch-src-include-tcs_tsp.h # trousers/files/patch-src-include-tcs_utils.h # trousers/files/patch-src-include-tcsd.h # trousers/files/patch-src-include-tcsd_ops.h # trousers/files/patch-src-include-threads.h # trousers/files/patch-src-include-trousers_types.h # trousers/files/patch-src-include-tss-platform.h # trousers/files/patch-src-tcs-ps-ps_utils.c # trousers/files/patch-src-tcs-ps-tcsps.c # trousers/files/patch-src-tcs-tcs_aik.c # trousers/files/patch-src-tcs-tcs_auth_mgr.c # trousers/files/patch-src-tcsd-svrside.c # trousers/files/patch-src-trspi-Makefile.am # trousers/files/patch-src-tspi-Makefile.am # trousers/files/patch-src-tspi-ps-ps_utils.c # trousers/files/patch-src-tspi-ps-tspps.c # trousers/files/patch-src-tspi-rpc-hosttable.c # trousers/files/patch-src-tspi-rpc-tcstp-rpc.c # trousers/files/pkg-install.in # trousers/files/pkg-message.in # trousers/files/tcsd.in # trousers/pkg-descr # trousers/pkg-plist # echo c - trousers mkdir -p trousers > /dev/null 2>&1 echo x - trousers/Makefile sed 's/^X//' >trousers/Makefile << '62cc97af3c4d7d373e6c5baff3fdd904' X# New ports collection makefile for: trousers X# Date created: 18 Sep 2007 X# Whom: Sebastian Schuetz X# X# $FreeBSD$ X# X XPORTNAME= trousers XPORTVERSION= 0.3.6 XCATEGORIES= security XMASTER_SITES= SF/${PORTNAME}/${PORTNAME}/${PORTVERSION} X XMAINTAINER= nork@FreeBSD.org XCOMMENT= The open-source TCG Software Stack X XUSE_GMAKE= YES XUSE_ICONV= YES XUSE_OPENSSL= YES XUSE_LDCONFIG= YES XUSE_AUTOTOOLS= autoconf:268 libtool:22 XGNU_CONFIGURE= YES XMAKE_JOBS_SAFE= YES X XSUB_FILES= pkg-message pkg-install XSUB_LIST= TSS_USER=${TSS_USER} TSS_UID=${TSS_UID} \ X TSS_GROUP=${TSS_GROUP} TSS_GID=${TSS_GID} XPKGINSTALL= ${WRKDIR}/pkg-install XPKGDEINSTALL= ${WRKDIR}/pkg-install XUSE_RC_SUBR= tcsd X X.include "Makefile.man" X XCONFIGURE_ARGS= --with-gui=none \ X --localstatedir=${PREFIX}/var \ X --with-tssuser=${TSS_USER} --with-tssgroup=${TSS_GROUP} X XTSS_USER= _tss XTSS_GROUP= _tss XTSS_UID= 601 XTSS_GID= 601 X XOPTIONS= EMULATOR "Build for use with the tpm-emulator" off \ X DEBUG "Build with debugging flags" off X XWRKSRC= ${WRKDIR}/${DISTNAME} X X.include X X.if defined(WITH_EMULATOR) XPKGNAMESUFFIX+= -no_tddl XLIB_DEPENDS+= tddl:${PORTSDIR}/security/tpm-emulator X Xpost-patch:: X ${REINPLACE_CMD} -e 's|\.\.\/tddl\/libtddl\.a|${LOCALBASE}\/lib\/libtddl\.a|g' ${WRKSRC}/src/tcs/Makefile.am X ${REINPLACE_CMD} -e 's|\.\.\/tddl\/libtddl\.a|${LOCALBASE}\/lib\/libtddl\.a|g' ${WRKSRC}/src/tcs/Makefile.in X ${REINPLACE_CMD} -e 's|\.\.\/tddl\/libtddl\.a|${LOCALBASE}\/lib\/libtddl\.a|g' ${WRKSRC}/src/tcsd/Makefile.am X ${REINPLACE_CMD} -e 's|\.\.\/tddl\/libtddl\.a|${LOCALBASE}\/lib\/libtddl\.a|g' ${WRKSRC}/src/tcsd/Makefile.in X ${REINPLACE_CMD} -e 's|libtddl\.a||g' ${WRKSRC}/src/tddl/Makefile.in X ${REINPLACE_CMD} -e 's|libtddl\.a||g' ${WRKSRC}/src/tddl/Makefile.am X X# The emulator has already a libttddl.so, so comment out trousers' libtddl in the pkg-plist XPLIST_SUB+= TDDL="@comment " X.else XPKGNAMESUFFIX+= -tddl XCONFLICTS+= tpm-emulator-0* XPLIST_SUB+= TDDL="" X.endif X X.if defined(WITH_DEBUG) XPKGNAMESUFFIX+= -debug XCONFIGURE_ARGS+=--enable-debug X.endif X Xpre-configure: X cd ${WRKSRC} && ${SETENV} ${CONFIGURE_ENV} ${AUTORECONF} -i X Xpre-install: X ${SETENV} PKG_PREFIX=${PREFIX} ${SH} ${PKGINSTALL} ${PKGNAME} PRE-INSTALL X Xpost-install: X ${MKDIR} ${EXAMPLESDIR} X ${INSTALL_DATA} -o ${TSS_USER} -g ${TSS_GROUP} -m 0600 \ X ${WRKSRC}/dist/tcsd.conf ${EXAMPLESDIR}/tcsd.conf X [ -f ${PREFIX}/etc/tcsd.conf ] || \ X ${CP} -p ${EXAMPLESDIR}/tcsd.conf ${PREFIX}/etc/tcsd.conf X ${CAT} ${PKGMESSAGE} X Xpost-deinstall: X ${SETENV} PKG_PREFIX=${PREFIX} ${SH} ${PKGDEINSTALL} ${PORTNAME} POST-DEINSTALL X X.include 62cc97af3c4d7d373e6c5baff3fdd904 echo x - trousers/Makefile.man sed 's/^X//' >trousers/Makefile.man << '81f6552ec0e9044742900ca70ec96d81' XMAN3= Tspi_ChangeAuth.3 \ X Tspi_ChangeAuthAsym.3 \ X Tspi_Context_Close.3 \ X Tspi_Context_CloseObject.3 \ X Tspi_Context_Connect.3 \ X Tspi_Context_Create.3 \ X Tspi_Context_CreateObject.3 \ X Tspi_Context_FreeMemory.3 \ X Tspi_Context_GetCapability.3 \ X Tspi_Context_GetDefaultPolicy.3 \ X Tspi_Context_GetKeyByPublicInfo.3 \ X Tspi_Context_GetKeyByUUID.3 \ X Tspi_Context_GetRegisteredKeysByUUID.3 \ X Tspi_Context_GetRegisteredKeysByUUID2.3 \ X Tspi_Context_GetTpmObject.3 \ X Tspi_Context_LoadKeyByBlob.3 \ X Tspi_Context_LoadKeyByUUID.3 \ X Tspi_Context_RegisterKey.3 \ X Tspi_Context_UnregisterKey.3 \ X Tspi_DAA_IssueCredential.3 \ X Tspi_DAA_IssueInit.3 \ X Tspi_DAA_IssueSetup.3 \ X Tspi_DAA_IssuerKeyVerification.3 \ X Tspi_DAA_VerifyInit.3 \ X Tspi_DAA_VerifySignature.3 \ X Tspi_Data_Bind.3 \ X Tspi_Data_Seal.3 \ X Tspi_Data_Unbind.3 \ X Tspi_Data_Unseal.3 \ X Tspi_DecodeBER_TssBlob.3 \ X Tspi_EncodeDER_TssBlob.3 \ X Tspi_GetAttribData.3 \ X Tspi_GetAttribUint32.3 \ X Tspi_GetPolicyObject.3 \ X Tspi_Hash_GetHashValue.3 \ X Tspi_Hash_SetHashValue.3 \ X Tspi_Hash_Sign.3 \ X Tspi_Hash_UpdateHashValue.3 \ X Tspi_Hash_VerifySignature.3 \ X Tspi_Key_CertifyKey.3 \ X Tspi_Key_ConvertMigrationBlob.3 \ X Tspi_Key_CreateKey.3 \ X Tspi_Key_CreateMigrationBlob.3 \ X Tspi_Key_GetPubKey.3 \ X Tspi_Key_LoadKey.3 \ X Tspi_Key_UnloadKey.3 \ X Tspi_Key_WrapKey.3 \ X Tspi_PcrComposite_GetPcrValue.3 \ X Tspi_PcrComposite_SelectPcrIndex.3 \ X Tspi_PcrComposite_SetPcrValue.3 \ X Tspi_Policy_AssignToObject.3 \ X Tspi_Policy_FlushSecret.3 \ X Tspi_Policy_SetSecret.3 \ X Tspi_SetAttribData.3 \ X Tspi_SetAttribUint32.3 \ X Tspi_TPM_AuthorizeMigrationTicket.3 \ X Tspi_TPM_CertifySelfTest.3 \ X Tspi_TPM_CheckMaintenancePubKey.3 \ X Tspi_TPM_ClearOwner.3 \ X Tspi_TPM_CollateIdentityRequest.3 \ X Tspi_TPM_CreateEndorsementKey.3 \ X Tspi_TPM_CreateMaintenanceArchive.3 \ X Tspi_TPM_CMKSetRestrictions.3 \ X Tspi_TPM_DAA_JoinCreateDaaPubKey.3 \ X Tspi_TPM_DAA_JoinInit.3 \ X Tspi_TPM_DAA_JoinStoreCredential.3 \ X Tspi_TPM_DAA_Sign.3 \ X Tspi_TPM_DirRead.3 \ X Tspi_TPM_DirWrite.3 \ X Tspi_TPM_GetAuditDigest.3 \ X Tspi_TPM_GetCapability.3 \ X Tspi_TPM_GetEvent.3 \ X Tspi_TPM_GetEventLog.3 \ X Tspi_TPM_GetEvents.3 \ X Tspi_TPM_GetPubEndorsementKey.3 \ X Tspi_TPM_GetRandom.3 \ X Tspi_TPM_GetStatus.3 \ X Tspi_TPM_GetTestResult.3 \ X Tspi_TPM_KillMaintenanceFeature.3 \ X Tspi_TPM_LoadMaintenancePubKey.3 \ X Tspi_TPM_OwnerGetSRKPubKey.3 \ X Tspi_TPM_PcrExtend.3 \ X Tspi_TPM_PcrRead.3 \ X Tspi_TPM_Quote.3 \ X Tspi_TPM_SelfTestFull.3 \ X Tspi_TPM_SetStatus.3 \ X Tspi_TPM_StirRandom.3 \ X Tspi_TPM_TakeOwnership.3 XMAN5= tcsd.conf.5 XMAN8= tcsd.8 81f6552ec0e9044742900ca70ec96d81 echo x - trousers/distinfo sed 's/^X//' >trousers/distinfo << '7c76982f1ae82672bfeaa5709c291459' XMD5 (trousers-0.3.6.tar.gz) = f4609e6446099e1403e23bb671df87f4 XSHA256 (trousers-0.3.6.tar.gz) = 91025f60248af44df192e8df16fa6b0c0f1e48c54f6dc51626567ed95758b0d6 XSIZE (trousers-0.3.6.tar.gz) = 1335084 7c76982f1ae82672bfeaa5709c291459 echo c - trousers/files mkdir -p trousers/files > /dev/null 2>&1 echo x - trousers/files/patch-configure.in sed 's/^X//' >trousers/files/patch-configure.in << '54f263a9bad252dea887f04414abf6ac' X--- configure.in.orig 2010-07-09 05:35:18.000000000 +0900 X+++ configure.in 2010-10-24 22:31:30.040556068 +0900 X@@ -75,6 +75,21 @@ X [CFLAGS="$CFLAGS -ftest-coverage -fprofile-arcs" X AC_MSG_RESULT([*** Enabling gcov at user request ***])],) X X+# Check for tss user X+AC_ARG_WITH(tssuser, X+ [ --with-tssuser[[=USER]] set tss user [[tss]]], X+ [tss_user=$withval], X+ [tss_user=tss] X+) X+# Check for tss group X+AC_ARG_WITH(tssgroup, X+ [ --with-tssgroup[[=GROUP]] set tss group [[tss]]], X+ [tss_group=$withval], X+ [tss_group=tss] X+) X+AC_SUBST(TSS_USER_NAME, $tss_user) X+AC_SUBST(TSS_GROUP_NAME, $tss_group) X+ X # profiling support X AC_ARG_ENABLE(gprof, X [AC_HELP_STRING([--enable-gprof], [enable profiling with gprof [default=off]])], X@@ -352,6 +367,8 @@ X AC_C_BIGENDIAN([AC_DEFINE(_BIG_ENDIAN, 1, [big-endian host])]) X AC_CHECK_DECL(htole32, [AC_DEFINE(HTOLE_DEFINED, 1, [htole32 function is available])]) X AC_CHECK_HEADER(sys/byteorder.h, [AC_DEFINE(HAVE_BYTEORDER_H, 1, [sys/byteorder.h header])]) X+AC_CHECK_HEADER(endian.h, [AC_DEFINE(HAVE_ENDIAN_H, 1, [endian.h header])]) X+AC_CHECK_HEADER(sys/endian.h, [AC_DEFINE(HAVE_SYS_ENDIAN_H, 1, [sys/endian.h header])]) X AC_CHECK_FUNC(daemon, [ AC_DEFINE(HAVE_DAEMON, 1, [daemon function is available]) ]) X X if test "x${GCC}" = "xyes"; then X@@ -359,6 +376,7 @@ X fi X X CFLAGS="$CFLAGS -I../include \ X+ -DTSS_USER_NAME=\\\"$tss_user\\\" -DTSS_GROUP_NAME=\\\"$tss_group\\\" \ X -DTCSD_DEFAULT_PORT=${TCSD_DEFAULT_PORT} -DTSS_VER_MAJOR=${TSS_VER_MAJOR} \ X -DTSS_VER_MINOR=${TSS_VER_MINOR} -DTSS_SPEC_MAJOR=${TSS_SPEC_MAJOR} \ X -DTSS_SPEC_MINOR=${TSS_SPEC_MINOR}" 54f263a9bad252dea887f04414abf6ac echo x - trousers/files/patch-dist-Makefile.am sed 's/^X//' >trousers/files/patch-dist-Makefile.am << '504a086ffac7e812f037fa97f29c1f74' X--- dist/Makefile.am.orig 2010-03-12 05:41:54.000000000 +0900 X+++ dist/Makefile.am 2010-10-24 21:04:04.818560844 +0900 X@@ -1,17 +1,7 @@ X EXTRA_DIST = system.data.auth system.data.noauth \ X fedora/fedora.initrd.tcsd X install: install-exec-hook X- if test ! -e ${DESTDIR}/@sysconfdir@/tcsd.conf; then mkdir -p ${DESTDIR}/@sysconfdir@ && cp tcsd.conf ${DESTDIR}/@sysconfdir@; fi X- /bin/chown tss:tss ${DESTDIR}/@sysconfdir@/tcsd.conf || true X- /bin/chmod 0600 ${DESTDIR}/@sysconfdir@/tcsd.conf X X install-exec-hook: X- /usr/sbin/groupadd tss || true X- /usr/sbin/useradd -r tss -g tss || true X- /bin/sh -c 'if [ ! -e ${DESTDIR}/@localstatedir@/lib/tpm ];then mkdir -p ${DESTDIR}/@localstatedir@/lib/tpm; fi' X- /bin/chown tss:tss ${DESTDIR}/@localstatedir@/lib/tpm || true X- /bin/chmod 0700 ${DESTDIR}/@localstatedir@/lib/tpm X X uninstall-hook: X- /usr/sbin/userdel tss || true X- /usr/sbin/groupdel tss || true 504a086ffac7e812f037fa97f29c1f74 echo x - trousers/files/patch-dist-tcsd.conf.in sed 's/^X//' >trousers/files/patch-dist-tcsd.conf.in << 'ba08a8d0974ffb0250885a2fab9cb801' X--- dist/tcsd.conf.in.orig 2010-01-29 01:27:50.000000000 +0900 X+++ dist/tcsd.conf.in 2010-10-25 00:06:25.565556476 +0900 X@@ -35,7 +35,7 @@ X # log data. The interface to this log is usually provided by the TPM X # device driver. X # X-# firmware_log_file = /sys/kernel/security/tpm0/binary_bios_measurements X+# firmware_log_file = /var/run/tpm/binary_bios_measurements X # X X # Option: kernel_log_file X@@ -46,7 +46,7 @@ X # http://sf.net/projects/linux-ima for more info on getting IMA. X # X # X-# kernel_log_file = /sys/kernel/security/ima/binary_runtime_measurements X+# kernel_log_file = /var/run/ima/binary_runtime_measurements X # X X # Option: firmware_pcrs ba08a8d0974ffb0250885a2fab9cb801 echo x - trousers/files/patch-src-include-biosem.h sed 's/^X//' >trousers/files/patch-src-include-biosem.h << '7baa126b3bf782564a424ad400333179' X--- src/include/biosem.h.orig 2010-03-12 05:22:36.000000000 +0900 X+++ src/include/biosem.h 2010-10-24 21:04:04.820558727 +0900 X@@ -26,7 +26,7 @@ X UINT32 eventType; X BYTE digest[20]; X UINT32 eventDataSize; X- BYTE event[0];/* (eventSize) bytes of event data follows */ X+ BYTE event[1];/* (eventSize) bytes of event data follows */ X } TCG_PCClientPCREventStruc; X X #define EVLOG_SOURCE_BIOS 1 7baa126b3bf782564a424ad400333179 echo x - trousers/files/patch-src-include-linux-tpm.h sed 's/^X//' >trousers/files/patch-src-include-linux-tpm.h << 'd0bf3e4824bc76aa3a977b72f0ab172c' X--- src/include/linux/tpm.h.orig 2010-01-29 01:27:51.000000000 +0900 X+++ src/include/linux/tpm.h 2010-10-24 21:04:04.821560671 +0900 X@@ -20,6 +20,8 @@ X #include X #elif (defined (__OpenBSD__) || defined (__FreeBSD__)) X #include X+#elif (defined (SOLARIS)) X+#include X #endif X X /* ioctl commands */ d0bf3e4824bc76aa3a977b72f0ab172c echo x - trousers/files/patch-src-include-tcs_tsp.h sed 's/^X//' >trousers/files/patch-src-include-tcs_tsp.h << '205b92e92f124faba1b040f5badf21a3' X--- src/include/tcs_tsp.h.orig 2010-01-29 01:27:51.000000000 +0900 X+++ src/include/tcs_tsp.h 2010-10-24 21:04:04.822560729 +0900 X@@ -79,7 +79,13 @@ X /* XXX Get rid of this, there's no reason to set an arbitrary limit */ X #define MAX_KEY_CHILDREN 10 X X+#ifndef STRUCTURE_PACKING_ATTRIBUTE X+#ifdef __GCC X #define STRUCTURE_PACKING_ATTRIBUTE __attribute__((packed)) X+#else X+#define STRUCTURE_PACKING_ATTRIBUTE /* */ X+#endif X+#endif X X #ifdef TSS_DEBUG X #define DBG_ASSERT(x) assert(x) 205b92e92f124faba1b040f5badf21a3 echo x - trousers/files/patch-src-include-tcs_utils.h sed 's/^X//' >trousers/files/patch-src-include-tcs_utils.h << '6a7d860e30e992a9fb04fb59af41bf96' X--- src/include/tcs_utils.h.orig 2010-01-29 01:27:51.000000000 +0900 X+++ src/include/tcs_utils.h 2010-10-24 21:04:04.824555399 +0900 X@@ -18,6 +18,20 @@ X #include "tcs_tsp.h" X #include "trousers_types.h" X X+ X+ X+/* X+ * XXX malloc wrapper X+ * X+ * Linux: malloc(0) => '\0' X+ * *BSD: malloc(0) => invalid to dereference X+ * X+ * => so wrap malloc(0) => calloc(1, 16) to create X+ * a 16Byte array containing '\0' X+ * X+ */ X+#define malloc(x) ((x) == 0 ? calloc(1, 16) : calloc(1, (x))) X+ X struct key_mem_cache X { X TCPA_KEY_HANDLE tpm_handle; 6a7d860e30e992a9fb04fb59af41bf96 echo x - trousers/files/patch-src-include-tcsd.h sed 's/^X//' >trousers/files/patch-src-include-tcsd.h << 'a1693b5207fb7ec025bd1b08b4943608' X--- src/include/tcsd.h.orig 2010-05-03 11:54:15.000000000 +0900 X+++ src/include/tcsd.h 2010-10-24 22:28:52.708555289 +0900 X@@ -50,14 +50,22 @@ X X #define TCSD_CONFIG_FILE ETC_PREFIX "/tcsd.conf" X X+#ifndef TSS_USER_NAME X #define TSS_USER_NAME "tss" X+#endif X+#ifndef TSS_GROUP_NAME X #define TSS_GROUP_NAME "tss" X+#endif X+ X+#ifndef TPM_PREFIX X+#define TPM_PREFIX "/lib/tpm" X+#endif X X #define TCSD_DEFAULT_MAX_THREADS 10 X-#define TCSD_DEFAULT_SYSTEM_PS_FILE VAR_PREFIX "/lib/tpm/system.data" X-#define TCSD_DEFAULT_SYSTEM_PS_DIR VAR_PREFIX "/lib/tpm" X-#define TCSD_DEFAULT_FIRMWARE_LOG_FILE "/sys/kernel/security/tpm0/binary_bios_measurements" X-#define TCSD_DEFAULT_KERNEL_LOG_FILE "/sys/kernel/security/ima/binary_runtime_measurements" X+#define TCSD_DEFAULT_SYSTEM_PS_FILE VAR_PREFIX TPM_PREFIX "/system.data" X+#define TCSD_DEFAULT_SYSTEM_PS_DIR VAR_PREFIX TPM_PREFIX X+#define TCSD_DEFAULT_FIRMWARE_LOG_FILE "/var/run/tpm/binary_bios_measurements" X+#define TCSD_DEFAULT_KERNEL_LOG_FILE "/var/run/ima/binary_runtime_measurements" X #define TCSD_DEFAULT_FIRMWARE_PCRS 0x00000000 X #define TCSD_DEFAULT_KERNEL_PCRS 0x00000000 X a1693b5207fb7ec025bd1b08b4943608 echo x - trousers/files/patch-src-include-tcsd_ops.h sed 's/^X//' >trousers/files/patch-src-include-tcsd_ops.h << '8b827ea9e570d8942278825f46e5566f' X--- src/include/tcsd_ops.h.orig 2010-01-29 01:27:51.000000000 +0900 X+++ src/include/tcsd_ops.h 2010-10-24 21:04:04.827558718 +0900 X@@ -123,7 +123,7 @@ X X struct tcsd_op { X char *name; X- int op[]; X+ int op[20]; X }; X X struct tcsd_op tcsd_op_seal = {"seal", {TCSD_OP_SEAL}}; 8b827ea9e570d8942278825f46e5566f echo x - trousers/files/patch-src-include-threads.h sed 's/^X//' >trousers/files/patch-src-include-threads.h << '6168776c8b0ad74f1579e2ede29ae072' X--- src/include/threads.h.orig 2010-05-03 11:54:15.000000000 +0900 X+++ src/include/threads.h 2010-10-24 21:04:04.828558009 +0900 X@@ -31,7 +31,7 @@ X #define COND_SIGNAL(c) pthread_cond_signal(c) X X /* thread abstractions */ X-#define THREAD_ID ((THREAD_TYPE)pthread_self()) X+#define THREAD_ID (long int)((THREAD_TYPE)pthread_self()) X #define THREAD_TYPE pthread_t X #define THREAD_JOIN pthread_join X #define THREAD_DETACH pthread_detach 6168776c8b0ad74f1579e2ede29ae072 echo x - trousers/files/patch-src-include-trousers_types.h sed 's/^X//' >trousers/files/patch-src-include-trousers_types.h << '8743a61ad1dea5b846b7e649be895c9c' X--- src/include/trousers_types.h.orig 2010-05-20 02:45:55.000000000 +0900 X+++ src/include/trousers_types.h 2010-10-24 21:04:04.829561420 +0900 X@@ -11,6 +11,14 @@ X #ifndef _TROUSERS_TYPES_H_ X #define _TROUSERS_TYPES_H_ X X+#ifndef STRUCTURE_PACKING_ATTRIBUTE X+#ifdef __GCC X+#define STRUCTURE_PACKING_ATTRIBUTE __attribute__((packed)) X+#else X+#define STRUCTURE_PACKING_ATTRIBUTE /* */ X+#endif X+#endif X+ X #define TCPA_NONCE_SIZE sizeof(TCPA_NONCE) X #define TCPA_DIGEST_SIZE sizeof(TCPA_DIGEST) X #define TCPA_ENCAUTH_SIZE sizeof(TCPA_ENCAUTH) X@@ -100,7 +108,7 @@ X typedef struct tdTSS_KEY12_HDR { X TPM_STRUCTURE_TAG tag; X UINT16 fill; X-} __attribute__((packed)) TSS_KEY12_HDR; X+} STRUCTURE_PACKING_ATTRIBUTE TSS_KEY12_HDR; X X typedef struct tdTSS_KEY { X union { X@@ -118,11 +126,10 @@ X BYTE *encData; X } TSS_KEY; X X-#if (defined (__linux) || defined (linux) || defined (SOLARIS) || defined (__GLIBC__)) X-#define BSD_CONST X-#elif (defined (__OpenBSD__) || defined (__FreeBSD__)) X+#if defined (__FreeBSD__) X #define BSD_CONST const X-#endif X- X+#else X+#define BSD_CONST /* */ X+#endif X X #endif 8743a61ad1dea5b846b7e649be895c9c echo x - trousers/files/patch-src-include-tss-platform.h sed 's/^X//' >trousers/files/patch-src-include-tss-platform.h << '46d11322ecc7db5e1fa5cdd802b2d150' X--- src/include/tss/platform.h.orig 2010-01-29 01:27:51.000000000 +0900 X+++ src/include/tss/platform.h 2010-10-24 21:04:04.830556101 +0900 X@@ -15,7 +15,7 @@ X #if !defined(WIN32) X #include X typedef uint8_t BYTE; X- typedef int8_t TSS_BOOL; X+ typedef uint8_t TSS_BOOL; X typedef uint16_t UINT16; X typedef uint32_t UINT32; X typedef uint64_t UINT64; 46d11322ecc7db5e1fa5cdd802b2d150 echo x - trousers/files/patch-src-tcs-ps-ps_utils.c sed 's/^X//' >trousers/files/patch-src-tcs-ps-ps_utils.c << '80440b00a9b5029159a65203cb68f7d7' X--- src/tcs/ps/ps_utils.c.orig 2010-07-01 00:15:00.000000000 +0900 X+++ src/tcs/ps/ps_utils.c 2010-10-24 21:04:04.832556427 +0900 X@@ -16,10 +16,18 @@ X #if defined(HAVE_BYTEORDER_H) X #include X #elif defined(HTOLE_DEFINED) X+#if defined(HAVE_ENDIAN_H) X #include X #define LE_16 htole16 X #define LE_32 htole32 X #define LE_64 htole64 X+#endif X+#if defined(HAVE_SYS_ENDIAN_H) X+#include X+#define LE_16 htole16 X+#define LE_32 htole32 X+#define LE_64 htole64 X+#endif X #else X #define LE_16(x) (x) X #define LE_32(x) (x) X@@ -39,6 +47,24 @@ X #include "tcs_utils.h" X #include "tcslog.h" X X+#ifndef LE_16 X+static UINT16 htole16(UINT16 x) X+{ X+ BYTE *b = &x; X+ return (UINT16) (b[0] + (b[1] << 8)); X+} X+#define LE_16 htole16 X+#endif X+ X+#ifndef LE_32 X+static UINT32 htole32(UINT32 x) X+{ X+ BYTE *b = &x; X+ return (UINT32) (b[0] + (b[1] << 8) + (b[2] << 16) + (b[3] << 24)); X+} X+#define LE_32 htole32 X+#endif X+ X struct key_disk_cache *key_disk_cache_head = NULL; X X 80440b00a9b5029159a65203cb68f7d7 echo x - trousers/files/patch-src-tcs-ps-tcsps.c sed 's/^X//' >trousers/files/patch-src-tcs-ps-tcsps.c << '28f3bb3e5f973f722dce227a4368092f' X--- src/tcs/ps/tcsps.c.orig 2010-05-02 11:39:11.000000000 +0900 X+++ src/tcs/ps/tcsps.c 2010-10-24 21:04:04.833559489 +0900 X@@ -24,6 +24,11 @@ X #define LE_16 htole16 X #define LE_32 htole32 X #define LE_64 htole64 X+#elif defined (HAVE_SYS_ENDIAN_H) X+#include X+#define LE_16 htole16 X+#define LE_32 htole32 X+#define LE_64 htole64 X #else X #define LE_16(x) (x) X #define LE_32(x) (x) X@@ -33,6 +38,26 @@ X #include X #include X X+#ifdef __sun X+#define LOCK_EX F_LOCK X+#define LOCK_UN F_ULOCK X+#define flock(fd, func) lockf(fd, func, 0) X+#endif X+ X+#ifndef LOCK_SH X+#define LOCK_SH 1 /* shared lock */ X+#endif X+#ifndef LOCK_EX X+#define LOCK_EX 2 /* exclusive lock */ X+#endif X+#ifndef LOCK_NB X+#define LOCK_NB 4 /* don't block when locking */ X+#endif X+#ifndef LOCK_UN X+#define LOCK_UN 8 /* unlock */ X+#endif X+ X+ X #include "trousers/tss.h" X #include "trousers_types.h" X #include "tcsps.h" X@@ -43,6 +68,25 @@ X #include "tcsd_wrap.h" X #include "tcsd.h" X X+#ifndef LE_16 X+static UINT16 htole16(UINT16 x) X+{ X+ BYTE *b = &x; X+ return (UINT16) (b[0] + (b[1] << 8)); X+} X+#define LE_16 htole16 X+#endif X+ X+#ifndef LE_32 X+static UINT32 htole32(UINT32 x) X+{ X+ BYTE *b = &x; X+ return (UINT32) (b[0] + (b[1] << 8) + (b[2] << 16) + (b[3] << 24)); X+} X+#define LE_32 htole32 X+#endif X+ X+ X int system_ps_fd = -1; X MUTEX_DECLARE(disk_cache_lock); X 28f3bb3e5f973f722dce227a4368092f echo x - trousers/files/patch-src-tcs-tcs_aik.c sed 's/^X//' >trousers/files/patch-src-tcs-tcs_aik.c << 'dd628e1bc6fd1f40a25a3f9b9a9d6def' X--- src/tcs/tcs_aik.c.orig 2010-06-10 05:20:44.000000000 +0900 X+++ src/tcs/tcs_aik.c 2010-10-24 21:04:04.834556754 +0900 X@@ -66,7 +66,7 @@ X UnloadBlob_UINT16(offset, &key->size, blob); X X if (key->size > 0) { X- key->data = (BYTE *)malloc(key->size); X+ key->data = malloc(key->size); X if (key->data == NULL) { X LogError("malloc of %hu bytes failed.", key->size); X key->size = 0; dd628e1bc6fd1f40a25a3f9b9a9d6def echo x - trousers/files/patch-src-tcs-tcs_auth_mgr.c sed 's/^X//' >trousers/files/patch-src-tcs-tcs_auth_mgr.c << '5b678d6fbc6f41ef8327daed159e7ab4' X--- src/tcs/tcs_auth_mgr.c.orig 2010-06-10 05:21:32.000000000 +0900 X+++ src/tcs/tcs_auth_mgr.c 2010-10-24 21:04:04.836560084 +0900 X@@ -108,7 +108,7 @@ X auth_mgr_swap_in() X { X if (auth_mgr.overflow[auth_mgr.of_tail] != NULL) { X- LogDebug("waking up thread %lddd, auth slot has opened", THREAD_ID); X+ LogDebug("waking up thread %ld, auth slot has opened", THREAD_ID); X /* wake up the next sleeping thread in order and increment tail */ X COND_SIGNAL(auth_mgr.overflow[auth_mgr.of_tail]); X auth_mgr.overflow[auth_mgr.of_tail] = NULL; X@@ -149,7 +149,7 @@ X auth_mgr.overflow[auth_mgr.of_head] = cond; X auth_mgr.of_head = (auth_mgr.of_head + 1) % auth_mgr.overflow_size; X /* go to sleep */ X- LogDebug("thread %lddd going to sleep until auth slot opens", THREAD_ID); X+ LogDebug("thread %ld going to sleep until auth slot opens", THREAD_ID); X auth_mgr.sleeping_threads++; X COND_WAIT(cond, &tcsp_lock); X auth_mgr.sleeping_threads--; X@@ -180,7 +180,7 @@ X auth_mgr.of_tail = 0; X auth_mgr.overflow[auth_mgr.of_head] = cond; X auth_mgr.of_head = (auth_mgr.of_head + 1) % auth_mgr.overflow_size; X- LogDebug("thread %lddd going to sleep until auth slot opens", THREAD_ID); X+ LogDebug("thread %ld going to sleep until auth slot opens", THREAD_ID); X auth_mgr.sleeping_threads++; X COND_WAIT(cond, &tcsp_lock); X auth_mgr.sleeping_threads--; 5b678d6fbc6f41ef8327daed159e7ab4 echo x - trousers/files/patch-src-tcsd-svrside.c sed 's/^X//' >trousers/files/patch-src-tcsd-svrside.c << 'a8b09c7ee713f81933bfec58be62413b' X--- src/tcsd/svrside.c.orig 2010-06-10 05:19:00.000000000 +0900 X+++ src/tcsd/svrside.c 2010-10-24 21:04:04.838555802 +0900 X@@ -20,7 +20,6 @@ X #include X #include X #include X-#include X #if (defined (__OpenBSD__) || defined (__FreeBSD__)) X #include X #endif X@@ -41,11 +40,9 @@ X X struct tcsd_config tcsd_options; X struct tpm_properties tpm_metrics; X-static volatile int hup = 0, term = 0; X-extern char *optarg; X X-static void X-tcsd_shutdown(void) X+void X+tcsd_shutdown() X { X /* order is important here: X * allow all threads to complete their current request */ X@@ -57,27 +54,44 @@ X EVENT_LOG_final(); X } X X-static void X-tcsd_signal_term(int signal) X+void X+tcsd_signal_int(int signal) X { X- term = 1; X+ switch (signal) { X+ case SIGINT: X+ LogInfo("Caught SIGINT. Cleaning up and exiting."); X+ break; X+ case SIGHUP: X+ LogInfo("Caught SIGHUP. Cleaning up and exiting."); X+ break; X+ default: X+ LogError("Caught signal %d (which I didn't register for!)." X+ " Ignoring.", signal); X+ break; X+ } X+ tcsd_shutdown(); X+ exit(signal); X } X X void X-tcsd_signal_hup(int signal) X+tcsd_signal_chld(int signal) X { X- hup = 1; X+ /* kill zombies */ X+ wait3(NULL, WNOHANG, NULL); X } X X-static TSS_RESULT X-signals_init(void) X+TSS_RESULT X+signals_init() X { X int rc; X sigset_t sigmask; X- struct sigaction sa; X X sigemptyset(&sigmask); X- if ((rc = sigaddset(&sigmask, SIGTERM))) { X+ if ((rc = sigaddset(&sigmask, SIGCHLD))) { X+ LogError("sigaddset: %s", strerror(errno)); X+ return TCSERR(TSS_E_INTERNAL_ERROR); X+ } X+ if ((rc = sigaddset(&sigmask, SIGINT))) { X LogError("sigaddset: %s", strerror(errno)); X return TCSERR(TSS_E_INTERNAL_ERROR); X } X@@ -91,25 +105,30 @@ X return TCSERR(TSS_E_INTERNAL_ERROR); X } X X- sa.sa_flags = 0; X- sigemptyset(&sa.sa_mask); X- sa.sa_handler = tcsd_signal_term; X- if ((rc = sigaction(SIGTERM, &sa, NULL))) { X- LogError("signal SIGTERM not registered: %s", strerror(errno)); X+ tcsd_sa_int.sa_handler = tcsd_signal_int; X+ tcsd_sa_chld.sa_handler = tcsd_signal_chld; X+ tcsd_sa_chld.sa_flags = SA_RESTART; X+ X+ if ((rc = sigaction(SIGINT, &tcsd_sa_int, NULL))) { X+ LogError("signal SIGINT not registered: %s", strerror(errno)); X return TCSERR(TSS_E_INTERNAL_ERROR); X } X X- sa.sa_handler = tcsd_signal_hup; X- if ((rc = sigaction(SIGHUP, &sa, NULL))) { X+ if ((rc = sigaction(SIGHUP, &tcsd_sa_int, NULL))) { X LogError("signal SIGHUP not registered: %s", strerror(errno)); X return TCSERR(TSS_E_INTERNAL_ERROR); X } X X+ if ((rc = sigaction(SIGCHLD, &tcsd_sa_chld, NULL))) { X+ LogError("signal SIGCHLD not registered: %s", strerror(errno)); X+ return TCSERR(TSS_E_INTERNAL_ERROR); X+ } X+ X return TSS_SUCCESS; X } X X-static TSS_RESULT X-tcsd_startup(void) X+TSS_RESULT X+tcsd_startup() X { X TSS_RESULT result; X X@@ -183,7 +202,6 @@ X return TSS_SUCCESS; X } X X- X void X usage(void) X { X@@ -195,19 +213,6 @@ X fprintf(stderr, "\n"); X } X X-static TSS_RESULT X-reload_config(void) X-{ X- TSS_RESULT result; X- hup = 0; X- X- // FIXME: reload the config - work in progress X- result = TSS_SUCCESS; X- X- return result; X-} X- X- X int X main(int argc, char **argv) X { X@@ -216,7 +221,6 @@ X int sd, newsd, c, option_index = 0; X unsigned client_len; X char *hostname = NULL; X- struct passwd *pwd; X struct hostent *client_hostent = NULL; X struct option long_options[] = { X {"help", 0, NULL, 'h'}, X@@ -245,6 +249,14 @@ X if ((result = tcsd_startup())) X return (int)result; X X+ if (getenv("TCSD_FOREGROUND") == NULL) { X+ if (daemon(0, 0) == -1) { X+ perror("daemon"); X+ tcsd_shutdown(); X+ return -1; X+ } X+ } X+ X sd = socket(AF_INET, SOCK_STREAM, 0); X if (sd < 0) { X LogError("Failed socket: %s", strerror(errno)); X@@ -268,51 +280,20 @@ X LogError("Failed bind: %s", strerror(errno)); X return -1; X } X-#ifndef SOLARIS X- pwd = getpwnam(TSS_USER_NAME); X- if (pwd == NULL) { X- if (errno == 0) { X- LogError("User \"%s\" not found, please add this user" X- " manually.", TSS_USER_NAME); X- } else { X- LogError("getpwnam(%s): %s", TSS_USER_NAME, strerror(errno)); X- } X- return TCSERR(TSS_E_INTERNAL_ERROR); X- } X- setuid(pwd->pw_uid); X-#endif X if (listen(sd, TCSD_MAX_SOCKETS_QUEUED) < 0) { X LogError("Failed listen: %s", strerror(errno)); X return -1; X } X client_len = (unsigned)sizeof(client_addr); X X- if (getenv("TCSD_FOREGROUND") == NULL) { X- if (daemon(0, 0) == -1) { X- perror("daemon"); X- tcsd_shutdown(); X- return -1; X- } X- } X- X LogInfo("%s: TCSD up and running.", PACKAGE_STRING); X do { X newsd = accept(sd, (struct sockaddr *) &client_addr, &client_len); X+ LogDebug("accepted socket %i", newsd); X if (newsd < 0) { X- if (errno == EINTR) { X- if (term) X- break; X- else if (hup) { X- if (reload_config() != TSS_SUCCESS) X- LogError("Failed reloading config"); X- } X- continue; X- } else { X- LogError("Failed accept: %s", strerror(errno)); X- continue; X- } X+ LogError("Failed accept: %s", strerror(errno)); X+ break; X } X- LogDebug("accepted socket %i", newsd); X X if ((client_hostent = gethostbyaddr((char *) &client_addr.sin_addr, X sizeof(client_addr.sin_addr), X@@ -332,12 +313,8 @@ X X tcsd_thread_create(newsd, hostname); X hostname = NULL; X- if (hup) { X- if (reload_config() != TSS_SUCCESS) X- LogError("Failed reloading config"); X- } X- } while (term ==0); X+ } while (1); X X- /* To close correctly, we must receive a SIGTERM */ X- return 0; X+ /* To close correctly, we must recieve a SIGHUP */ X+ return -1; X } a8b09c7ee713f81933bfec58be62413b echo x - trousers/files/patch-src-trspi-Makefile.am sed 's/^X//' >trousers/files/patch-src-trspi-Makefile.am << '0be92f57c62240321e262f33752c1360' X--- src/trspi/Makefile.am.orig 2010-03-12 05:41:54.000000000 +0900 X+++ src/trspi/Makefile.am 2010-10-24 21:04:04.839558584 +0900 X@@ -1,7 +1,8 @@ X noinst_LTLIBRARIES=libtrousers.la X X libtrousers_la_SOURCES=trousers.c crypto/@CRYPTO_PACKAGE@/hash.c X-libtrousers_la_CFLAGS=-DAPPID=\"TSPI\" -I${top_srcdir}/src/include X+libtrousers_la_CFLAGS=-DAPPID=\"TSPI\" -I${top_srcdir}/src/include \ X+ -I${LOCALBASE}/include -I@prefix@/include X X if TSS_BUILD_ASYM_CRYPTO X libtrousers_la_SOURCES+=crypto/@CRYPTO_PACKAGE@/rsa.c 0be92f57c62240321e262f33752c1360 echo x - trousers/files/patch-src-tspi-Makefile.am sed 's/^X//' >trousers/files/patch-src-tspi-Makefile.am << '81ce7a6f4b4a23d02fcefc49bc510760' X--- src/tspi/Makefile.am.orig 2010-03-12 05:41:54.000000000 +0900 X+++ src/tspi/Makefile.am 2010-10-24 21:04:04.840556827 +0900 X@@ -17,7 +17,7 @@ X # 5. If any interfaces have been added since the last public release, then increment age. X # 6. If any interfaces have been removed since the last public release, then set age to 0. X X-libtspi_la_LDFLAGS=-version-info 2:3:1 -lpthread @CRYPTOLIB@ X+libtspi_la_LDFLAGS=-version-info 2:3:1 -lpthread @CRYPTOLIB@ -L@prefix@/lib -liconv X X libtspi_la_CFLAGS=-I$(top_srcdir)/src/include -DAPPID=\"TSPI\" -DVAR_PREFIX=\"@localstatedir@\" -DETC_PREFIX=\"@sysconfdir@\" X 81ce7a6f4b4a23d02fcefc49bc510760 echo x - trousers/files/patch-src-tspi-ps-ps_utils.c sed 's/^X//' >trousers/files/patch-src-tspi-ps-ps_utils.c << '55878de93b9e90775c3af677ac1df5d3' X--- src/tspi/ps/ps_utils.c.orig 2010-01-29 01:27:51.000000000 +0900 X+++ src/tspi/ps/ps_utils.c 2010-10-24 21:04:04.841558702 +0900 X@@ -22,7 +22,7 @@ X #include "tspps.h" X #include "tsplog.h" X X-inline TSS_RESULT X+TSS_RESULT X read_data(int fd, void *data, UINT32 size) X { X int rc; X@@ -39,7 +39,7 @@ X return TSS_SUCCESS; X } X X-inline TSS_RESULT X+TSS_RESULT X write_data(int fd, void *data, UINT32 size) X { X int rc; 55878de93b9e90775c3af677ac1df5d3 echo x - trousers/files/patch-src-tspi-ps-tspps.c sed 's/^X//' >trousers/files/patch-src-tspi-ps-tspps.c << '28832ebe24df8265a9be5f333b3175d2' X--- src/tspi/ps/tspps.c.orig 2010-05-02 11:39:11.000000000 +0900 X+++ src/tspi/ps/tspps.c 2010-10-24 21:04:04.843557352 +0900 X@@ -29,6 +29,11 @@ X #define LE_16 htole16 X #define LE_32 htole32 X #define LE_64 htole64 X+#elif defined(HAVE_SYS_ENDIAN_H) X+#include X+#define LE_16 htole16 X+#define LE_32 htole32 X+#define LE_64 htole64 X #else X #define LE_16(x) (x) X #define LE_32(x) (x) X@@ -43,11 +48,26 @@ X #include "tspps.h" X #include "tsplog.h" X X+#ifndef LE_16 X+static UINT16 htole16(UINT16 x) X+{ X+ BYTE *b = &x; X+ return (UINT16) (b[0] + (b[1] << 8)); X+} X+#define LE_16 htole16 X+#endif X+ X+#ifndef LE_32 X+static UINT32 htole32(UINT32 x) X+{ X+ BYTE *b = &x; X+ return (UINT32) (b[0] + (b[1] << 8) + (b[2] << 16) + (b[3] << 24)); X+} X+#define LE_32 htole32 X+#endif X+ X static int user_ps_fd = -1; X static MUTEX_DECLARE_INIT(user_ps_lock); X-#if (defined (__FreeBSD__) || defined (__OpenBSD__)) X-static MUTEX_DECLARE_INIT(user_ps_path); X-#endif X #if defined (SOLARIS) X static struct flock fl = { X 0, X@@ -70,9 +90,7 @@ X TSS_RESULT result; X char *file_name = NULL, *home_dir = NULL; X struct passwd *pwp; X-#if (defined (__linux) || defined (linux) || defined(__GLIBC__)) X struct passwd pw; X-#endif X struct stat stat_buf; X char buf[PASSWD_BUFSIZE]; X uid_t euid; X@@ -82,10 +100,6 @@ X *file = strdup(file_name); X return (*file) ? TSS_SUCCESS : TSPERR(TSS_E_OUTOFMEMORY); X } X-#if (defined (__FreeBSD__) || defined (__OpenBSD__)) X- MUTEX_LOCK(user_ps_path); X-#endif X- X euid = geteuid(); X X #if defined (SOLARIS) X@@ -98,32 +112,14 @@ X */ X rc = snprintf(buf, sizeof (buf), "%s/%d", TSS_USER_PS_DIR, euid); X #else X- setpwent(); X- while (1) { X-#if (defined (__linux) || defined (linux) || defined(__GLIBC__)) X- rc = getpwent_r(&pw, buf, PASSWD_BUFSIZE, &pwp); X- if (rc) { X- LogDebugFn("USER PS: Error getting path to home directory: getpwent_r: %s", X- strerror(rc)); X- endpwent(); X- return TSPERR(TSS_E_INTERNAL_ERROR); X- } X+ rc = getpwuid_r(euid, &pw, buf, PASSWD_BUFSIZE, &pwp); X+ if (rc) { X+ LogDebugFn("USER PS: Error getting path to home directory: " X+ "getpwent_r: %s", strerror(rc)); X+ return TSPERR(TSS_E_INTERNAL_ERROR); X+ } X X-#elif (defined (__FreeBSD__) || defined (__OpenBSD__)) X- if ((pwp = getpwent()) == NULL) { X- LogDebugFn("USER PS: Error getting path to home directory: getpwent: %s", X- strerror(rc)); X- endpwent(); X- MUTEX_UNLOCK(user_ps_path); X- return TSPERR(TSS_E_INTERNAL_ERROR); X- } X-#endif X- if (euid == pwp->pw_uid) { X- home_dir = strdup(pwp->pw_dir); X- break; X- } X- } X- endpwent(); X+ home_dir = strdup(pwp->pw_dir); X X if (!home_dir) X return TSPERR(TSS_E_OUTOFMEMORY); 28832ebe24df8265a9be5f333b3175d2 echo x - trousers/files/patch-src-tspi-rpc-hosttable.c sed 's/^X//' >trousers/files/patch-src-tspi-rpc-hosttable.c << '38ae0b43adfebd024b3dd0ad4ee5c632' X--- src/tspi/rpc/hosttable.c.orig 2010-05-02 11:39:11.000000000 +0900 X+++ src/tspi/rpc/hosttable.c 2010-10-24 21:04:04.845560543 +0900 X@@ -36,8 +36,8 @@ X } X X #ifdef SOLARIS X-#pragma init(_init) X-void _init(void) X+#pragma init(_init_hosttable) X+void _init_hosttable(void) X #else X void __attribute__ ((constructor)) my_init(void) X #endif X@@ -51,6 +51,8 @@ X { X struct host_table_entry *hte, *next = NULL; X X+ if( ht == NULL ) return; X+ X MUTEX_LOCK(ht->lock); X X for (hte = ht->entries; hte; hte = next) { X@@ -70,8 +72,8 @@ X } X X #ifdef SOLARIS X-#pragma fini(_fini) X-void _fini(void) X+#pragma fini(_fini_hosttable) X+void _fini_hosttable(void) X #else X void __attribute__ ((destructor)) my_fini(void) X #endif X@@ -84,6 +86,8 @@ X { X struct host_table_entry *entry, *tmp; X X+ if( ht == NULL ) return TSPERR(TSS_E_OUTOFMEMORY); X+ X entry = calloc(1, sizeof(struct host_table_entry)); X if (entry == NULL) { X LogError("malloc of %zd bytes failed.", sizeof(struct host_table_entry)); X@@ -134,6 +138,8 @@ X { X struct host_table_entry *hte, *prev = NULL; X X+ if( ht == NULL ) return; X+ X MUTEX_LOCK(ht->lock); X X for (hte = ht->entries; hte; prev = hte, hte = hte->next) { X@@ -158,6 +164,8 @@ X { X struct host_table_entry *index = NULL; X X+ if( ht == NULL ) return NULL; X+ X MUTEX_LOCK(ht->lock); X X for (index = ht->entries; index; index = index->next) { 38ae0b43adfebd024b3dd0ad4ee5c632 echo x - trousers/files/patch-src-tspi-rpc-tcstp-rpc.c sed 's/^X//' >trousers/files/patch-src-tspi-rpc-tcstp-rpc.c << 'd9742557d1dface6a70f071ae69df411' X--- src/tspi/rpc/tcstp/rpc.c.orig 2010-03-12 05:26:51.000000000 +0900 X+++ src/tspi/rpc/tcstp/rpc.c 2010-10-24 21:04:04.846552639 +0900 X@@ -306,7 +306,7 @@ X errno = 0; X if ((recv_size = recv(sock, buffer+recv_total, size-recv_total, 0)) <= 0) { X if (recv_size < 0) { X- if (errno == EINTR) X+ if (errno == EINTR || errno == EAGAIN) X continue; X LogError("Socket receive connection error: %s.", strerror(errno)); X } else { d9742557d1dface6a70f071ae69df411 echo x - trousers/files/pkg-install.in sed 's/^X//' >trousers/files/pkg-install.in << '9176e57905e2f26a08f561de15df0f20' X#!/bin/sh X XPATH=/bin:/usr/bin:/usr/sbin X XPREFIX=${PKG_PREFIX:-%%PREFIX%%} XUSER=%%TSS_USER%% XGROUP=%%TSS_GROUP%% XUID=%%TSS_UID%% XGID=%%TSS_GID%% X Xcase $2 in X PRE-INSTALL) X X if pw group show "${GROUP}" 2>/dev/null; then X echo "You already have a group \"${GROUP}\", so I will use it." X else X if pw groupadd ${GROUP} -g ${GID}; then X echo "Added group \"${GROUP}\"." X else X echo "Adding group \"${GROUP}\" failed..." X fi X fi X X if pw user show "${USER}" 2>/dev/null; then X echo "You already have a user \"${USER}\", so I will use it." X else X if pw useradd ${USER} -u ${UID} -g ${GROUP} -h - \ X -s /usr/sbin/nologin -L daemon -d /var/empty -c "TrouSerS user" X then X echo "Added user \"${USER}\"." X else X echo "Adding user \"${USER}\" failed..." X exit 1 X fi X fi X X if pw groupmod ${GROUP} -m ${USER}; then X echo "Added user \"${USER}\" to group \"${GROUP}\"." X else X echo "Adding user \"${USER}\" to group \"${GROUP}\" failed..." X fi X X install -d -o root -g ${GROUP} -m 0700 /var/run/tpm X install -d -o root -g ${GROUP} -m 0700 /var/run/ima X install -d -o root -g ${GROUP} -m 0700 ${PREFIX}/var/lib/tpm X X ;; X X POST-DEINSTALL) X X rmdir /var/run/tpm /var/run/ima 2> /dev/null || true X X# if pw user show "${USER}" 2>/dev/null; then X# if pw userdel ${USER} -u ${UID}; then X# echo "Deleted user \"${USER}\"." X# fi X# fi X X# if pw group show "${GROUP}" 2>/dev/null; then X# if pw groupdel ${GROUP} -g ${GID}; then X# echo "Deleted group \"${GROUP}\"." X# fi X# fi X X ;; X Xesac 9176e57905e2f26a08f561de15df0f20 echo x - trousers/files/pkg-message.in sed 's/^X//' >trousers/files/pkg-message.in << '1f220de02a946ea9b8d3d5db7d809bcf' XTo run tcsd automatically add the following line to /etc/rc.conf X Xtcsd_enable="YES" X XYou might want to edit %%PREFIX%%/etc/tcsd.conf to reflect your setup. 1f220de02a946ea9b8d3d5db7d809bcf echo x - trousers/files/tcsd.in sed 's/^X//' >trousers/files/tcsd.in << '3fafd7e59fa591bc4ccd271ab9f177f4' X#!/bin/sh X X# $FreeBSD$ X# X# PROVIDE: tcsd X# REQUIRE: LOGIN X# KEYWORD: shutdown X# X# Add the following lines to /etc/rc.conf.local or /etc/rc.conf X# to enable this service: X# X# tcsd_enable (bool): Set to NO by default. X# Set it to YES to enable tcsd. X X. /etc/rc.subr X Xname=tcsd Xrcvar=`set_rcvar` Xcommand="%%PREFIX%%/sbin/${name}" X Xload_rc_config $name X X: tcsd_enable=${tcsd_enable-"NO"} X Xrun_rc_command "$1" 3fafd7e59fa591bc4ccd271ab9f177f4 echo x - trousers/pkg-descr sed 's/^X//' >trousers/pkg-descr << '2a7c4d6acfdaa2823ffc7d484f1976d8' XTrouSerS is an CPL (Common Public License) licensed Trusted Computing XSoftware Stack. It is mostly compliant with the TSS 1.2 specification. 2a7c4d6acfdaa2823ffc7d484f1976d8 echo x - trousers/pkg-plist sed 's/^X//' >trousers/pkg-plist << 'ec75e402f06a6acdd6a48c4cc7c7d7cc' X@unexec cmp -s %D/etc/tcsd.conf %D/%%EXAMPLESDIR%%/tcsd.conf && rm -f %D/etc/tcsd.conf || true X%%EXAMPLESDIR%%/tcsd.conf X@exec [ -f %D/etc/tcsd.conf ] || cp -p %B/%f %D/etc/tcsd.conf Xinclude/trousers/trousers.h Xinclude/trousers/tss.h Xinclude/tss/compat11b.h Xinclude/tss/platform.h Xinclude/tss/tcpa_defines.h Xinclude/tss/tcpa_error.h Xinclude/tss/tcpa_struct.h Xinclude/tss/tcpa_typedef.h Xinclude/tss/tcs.h Xinclude/tss/tcs_defines.h Xinclude/tss/tcs_error.h Xinclude/tss/tcs_structs.h Xinclude/tss/tcs_typedef.h Xinclude/tss/tddl_error.h Xinclude/tss/tddlapi_error.h Xinclude/tss/tddli.h Xinclude/tss/tpm.h Xinclude/tss/tpm_error.h Xinclude/tss/tpm_ordinal.h Xinclude/tss/tspi.h Xinclude/tss/tss_defines.h Xinclude/tss/tss_error.h Xinclude/tss/tss_error_basics.h Xinclude/tss/tss_structs.h Xinclude/tss/tss_typedef.h X%%TDDL%%lib/libtddl.a Xlib/libtspi.a Xlib/libtspi.la Xlib/libtspi.so Xlib/libtspi.so.2 Xsbin/tcsd X@dirrm %%EXAMPLESDIR%% X@dirrmtry var/lib/tpm X@dirrmtry var/lib X@dirrmtry var X@dirrm include/tss X@dirrm include/trousers X@comment @dirrmtry var run tpm X@comment @dirrmtry var run ima ec75e402f06a6acdd6a48c4cc7c7d7cc exit --Multipart=_Thu__28_Oct_2010_02_43_40_+0900_JtScQ_e/yKAD9/CK Content-Type: text/plain; name="opencryptoki.shar" Content-Disposition: attachment; filename="opencryptoki.shar" Content-Transfer-Encoding: 7bit # This is a shell archive. Save it in a file, remove anything before # this line, and then unpack it by entering "sh file". Note, it may # create directories; files and directories will be owned by you and # have default permissions. # # This archive contains: # # opencryptoki # opencryptoki/Makefile # opencryptoki/distinfo # opencryptoki/files # opencryptoki/files/patch-configure.in # opencryptoki/files/patch-usr-include-pkcs11-apictl.h # opencryptoki/files/patch-usr-include-pkcs11-slotmgr.h # opencryptoki/files/patch-usr-include-pkcs11-stdll.h # opencryptoki/files/patch-usr-lib-pkcs11-aep_stdll-Makefile.am # opencryptoki/files/patch-usr-lib-pkcs11-api-Makefile.am # opencryptoki/files/patch-usr-lib-pkcs11-api-api_interface.c # opencryptoki/files/patch-usr-lib-pkcs11-api-apiutil.c # opencryptoki/files/patch-usr-lib-pkcs11-api-shrd_mem.c.in # opencryptoki/files/patch-usr-lib-pkcs11-bcom_stdll-Makefile.am # opencryptoki/files/patch-usr-lib-pkcs11-cca_stdll-host_defs.h # opencryptoki/files/patch-usr-lib-pkcs11-cca_stdll-loadsave.c # opencryptoki/files/patch-usr-lib-pkcs11-cca_stdll-new_host.c # opencryptoki/files/patch-usr-lib-pkcs11-cca_stdll-tok_spec_struct.h # opencryptoki/files/patch-usr-lib-pkcs11-common-host_defs.h # opencryptoki/files/patch-usr-lib-pkcs11-common-loadsave.c # opencryptoki/files/patch-usr-lib-pkcs11-common-new_host.c # opencryptoki/files/patch-usr-lib-pkcs11-common-tok_spec_struct.h # opencryptoki/files/patch-usr-lib-pkcs11-common-utility.c # opencryptoki/files/patch-usr-lib-pkcs11-cr_stdll-Makefile.am # opencryptoki/files/patch-usr-lib-pkcs11-ica_s390_stdll-Makefile.am # opencryptoki/files/patch-usr-lib-pkcs11-ica_stdll-Makefile.am # opencryptoki/files/patch-usr-lib-pkcs11-soft_stdll-Makefile.am # opencryptoki/files/patch-usr-lib-pkcs11-tpm_stdll-host_defs.h # opencryptoki/files/patch-usr-lib-pkcs11-tpm_stdll-loadsave.c # opencryptoki/files/patch-usr-lib-pkcs11-tpm_stdll-new_host.c # opencryptoki/files/patch-usr-lib-pkcs11-tpm_stdll-tok_spec_struct.h # opencryptoki/files/patch-usr-lib-pkcs11-tpm_stdll-utility.c # opencryptoki/files/patch-usr-sbin-pkcs11_startup-Makefile.am # opencryptoki/files/patch-usr-sbin-pkcs11_startup-pkcs11_startup.in # opencryptoki/files/patch-usr-sbin-pkcs_slot-pkcs_slot.in # opencryptoki/files/patch-usr-sbin-pkcsconf-Makefile.am # opencryptoki/files/patch-usr-sbin-pkcsconf-pkcsconf.c # opencryptoki/files/patch-usr-sbin-pkcsslotd-err.c # opencryptoki/files/patch-usr-sbin-pkcsslotd-mutex.c # opencryptoki/files/patch-usr-sbin-pkcsslotd-pkcsslotd.h # opencryptoki/files/patch-usr-sbin-pkcsslotd-shmem.c # opencryptoki/files/pkcsslotd.in # opencryptoki/files/pkg-install.in # opencryptoki/files/pkg-message.in # opencryptoki/pkg-descr # opencryptoki/pkg-plist # echo c - opencryptoki mkdir -p opencryptoki > /dev/null 2>&1 echo x - opencryptoki/Makefile sed 's/^X//' >opencryptoki/Makefile << 'f31207dec89f8136d8713efd103a8521' X# New ports collection makefile for: opencryptoki X# Date created: 2010-07-16 X# Whom: Ralf Meister X# X# $FreeBSD$ X# X XPORTNAME= opencryptoki XPORTVERSION= 2.3.2 XCATEGORIES= security XMASTER_SITES= SF/${PORTNAME}/${PORTNAME}/${PORTVERSION} X XMAINTAINER= nork@FreeBSD.org XCOMMENT= An open PKCS\#11 implementation library X XLIB_DEPENDS+= tspi.2:${PORTSDIR}/security/trousers X XUSE_BZIP2= YES XUSE_GMAKE= YES XUSE_LDCONFIG= YES XUSE_AUTOTOOLS= autoconf:268 libtool:22 automake:111 XHAS_CONFIGURE= YES XMAKE_JOBS_SAFE= YES X XSUB_FILES= pkg-install XSUB_LIST= PKCS11_USER=${PKCS11_USER} PKCS11_UID=${PKCS11_UID} \ X PKCS11_GROUP=${PKCS11_GROUP} PKCS11_GID=${PKCS11_GID} XPKGINSTALL= ${WRKDIR}/pkg-install X#PKGDEINSTALL= ${WRKDIR}/pkg-install XUSE_RC_SUBR= pkcsslotd X XMAN1= pkcs11_startup.1 pkcsconf.1 XMAN5= pk_config_data.5 XMAN7= opencryptoki.7 XMAN8= pkcsslotd.8 X XCONFIGURE_ARGS= --enable-swtok --enable-tpmtok \ X --disable-crtok --disable-aeptok \ X --disable-ccatok --disable-bcomtok \ X --disable-pkcscca_migrate \ X --libdir=${PREFIX}/lib \ X --sbindir=${PREFIX}/sbin \ X --localstatedir=${PREFIX}/var \ X --with-pkcs11user=${PKCS11_USER} \ X --with-pkcs11group=${PKCS11_GROUP} XCONFIGURE_ENV+= CFLAGS="${CFLAGS} -I${LOCALBASE}/include" XCONFIGURE_ENV+= LDFLAGS="-L${LOCALBASE}/lib" X XPKCS11_USER= _pkcs11 XPKCS11_GROUP= _pkcs11 XPKCS11_UID= 602 XPKCS11_GID= 602 X Xpre-configure: X cd ${WRKSRC} && ${SETENV} ${CONFIGURE_ENV} ${ACLOCAL} X cd ${WRKSRC} && ${SETENV} ${CONFIGURE_ENV} ${LIBTOOLIZE} --force -c X cd ${WRKSRC} && ${SETENV} ${CONFIGURE_ENV} ${AUTOMAKE} --add-missing -c X cd ${WRKSRC} && ${SETENV} ${CONFIGURE_ENV} ${AUTOCONF} X Xpre-install: X ${SETENV} PKG_PREFIX=${PREFIX} ${SH} ${PKGINSTALL} ${PKGNAME} PRE-INSTALL X Xpost-install: X cd ${PREFIX}/lib && ${LN} -s opencryptoki/libopencryptoki* . X ${SETENV} PKG_PREFIX=${PREFIX} ${SH} ${PKGINSTALL} ${PKGNAME} POST-INSTALL X X.include f31207dec89f8136d8713efd103a8521 echo x - opencryptoki/distinfo sed 's/^X//' >opencryptoki/distinfo << 'd6dd4730871d9b94afb052a3c15ab7f9' XMD5 (opencryptoki-2.3.2.tar.bz2) = eada4c72c2563f2c9a1b44fc6d1856db XSHA256 (opencryptoki-2.3.2.tar.bz2) = 44fdf74a9eab2586240a69779c5c323e8378e8f2fde21cd4f8bd9186a24c30f7 XSIZE (opencryptoki-2.3.2.tar.bz2) = 665134 d6dd4730871d9b94afb052a3c15ab7f9 echo c - opencryptoki/files mkdir -p opencryptoki/files > /dev/null 2>&1 echo x - opencryptoki/files/patch-configure.in sed 's/^X//' >opencryptoki/files/patch-configure.in << 'ba603af54cc49bec829d0ca77000ec79' X--- configure.in.orig 2010-07-29 21:28:41.000000000 +0900 X+++ configure.in 2010-10-20 01:31:02.971984782 +0900 X@@ -8,6 +8,9 @@ X X AM_INIT_AUTOMAKE([foreign 1.6]) X X+AC_DEFINE(_BSD_SOURCE, 1, BSD functions) X+AC_DEFINE(__BSD_VISIBLE, 1, BSD extensions) X+ X dnl Get the canonical host type X AC_CANONICAL_TARGET X X@@ -30,6 +33,7 @@ X AC_FUNC_STRFTIME X AC_FUNC_VPRINTF X AC_CHECK_FUNCS([getcwd]) X+AC_CHECK_FUNCS([asprintf]) X X dnl Used in various scripts X AC_PATH_PROG([ID], [id], [/us/bin/id]) X@@ -193,6 +197,21 @@ X [], X [with_xcryptolinz=check]) X X+dnl --- check for pkcs11 user X+AC_ARG_WITH([pkcs11user], X+ AC_HELP_STRING([--with-pkcs11user[[=USER]]], [set pkcs11 user [[pkcs11]]]), X+ [pkcs11_user=$withval], X+ [pkcs11_user=pkcs11]) X+ X+dnl --- check for pkcs11 group X+AC_ARG_WITH(pkcs11group, X+ AC_HELP_STRING([--with-pkcs11group[[=GROUP]]], [set pkcs11 group [[pkcs11]]]), X+ [pkcs11_group=$withval], X+ [pkcs11_group=pkcs11]) X+ X+AC_SUBST(PKCS11USER, $pkcs11_user) X+AC_SUBST(PKCS11GROUP, $pkcs11_group) X+ X dnl --- X dnl --- X dnl --- Now that we have all the options, let's check for a valid build X@@ -630,11 +649,15 @@ X X CFLAGS="$CFLAGS $DEBUG_CFLAGS -DPKCS64 -D_XOPEN_SOURCE=500" X X-CFLAGS+=' -DCONFIG_PATH=\"$(localstatedir)/lib/opencryptoki\" -DSBIN_PATH=\"$(sbindir)\" -DLIB_PATH=\"$(libdir)\"' X+CFLAGS="$CFLAGS -DCONFIG_PATH='\"$localstatedir/lib/opencryptoki\"' -DSBIN_PATH='\"$sbindir\"' -DLIB_PATH='\"$libdir\"'" X+ X+CFLAGS="$CFLAGS -DPKCS11USER='\"${pkcs11_user}\"' -DPKCS11GROUP='\"${pkcs11_group}\"'" X X # At this point, CFLAGS is set to something sensible X AC_PROG_CC X X+AC_SUBST(FPIC, $lt_prog_compiler_pic) X+ X AC_OUTPUT([Makefile usr/Makefile \ X usr/include/Makefile \ X usr/include/pkcs11/Makefile \ ba603af54cc49bec829d0ca77000ec79 echo x - opencryptoki/files/patch-usr-include-pkcs11-apictl.h sed 's/^X//' >opencryptoki/files/patch-usr-include-pkcs11-apictl.h << 'b18558c4d5a71fc05ffa7ebbb02f84d7' X--- usr/include/pkcs11/apictl.h.orig 2010-07-29 21:28:41.000000000 +0900 X+++ usr/include/pkcs11/apictl.h 2010-10-19 23:42:04.580983829 +0900 X@@ -296,7 +296,7 @@ X X X #include X-#include X+#include X #include X #include X #include b18558c4d5a71fc05ffa7ebbb02f84d7 echo x - opencryptoki/files/patch-usr-include-pkcs11-slotmgr.h sed 's/^X//' >opencryptoki/files/patch-usr-include-pkcs11-slotmgr.h << 'faca460c2cea8089314a86016a985336' X--- usr/include/pkcs11/slotmgr.h.orig 2010-07-29 21:28:41.000000000 +0900 X+++ usr/include/pkcs11/slotmgr.h 2010-10-19 23:42:55.423984058 +0900 X@@ -301,7 +301,7 @@ X X X #include X-#include X+#include X #include X #include X faca460c2cea8089314a86016a985336 echo x - opencryptoki/files/patch-usr-include-pkcs11-stdll.h sed 's/^X//' >opencryptoki/files/patch-usr-include-pkcs11-stdll.h << 'a4a465f74d95fdbcda24a07cf27e78c0' X--- usr/include/pkcs11/stdll.h.orig 2010-07-29 21:28:41.000000000 +0900 X+++ usr/include/pkcs11/stdll.h 2010-10-19 23:43:40.418984281 +0900 X@@ -302,7 +302,7 @@ X X X #include X-#include X+#include X #include X #include X a4a465f74d95fdbcda24a07cf27e78c0 echo x - opencryptoki/files/patch-usr-lib-pkcs11-aep_stdll-Makefile.am sed 's/^X//' >opencryptoki/files/patch-usr-lib-pkcs11-aep_stdll-Makefile.am << '3f24ba189b1ba4dee357140896e27b09' X--- usr/lib/pkcs11/aep_stdll/Makefile.am.orig 2010-07-29 21:28:41.000000000 +0900 X+++ usr/lib/pkcs11/aep_stdll/Makefile.am 2010-10-19 23:45:36.945982287 +0900 X@@ -6,7 +6,7 @@ X X # Not all versions of automake observe libname_CFLAGS X opencryptoki_stdll_libpkcs11_aep_la_CFLAGS = -DSPINXPL -DDEV \ X--D_THREAD_SAFE -fPIC -DSHALLOW=0 -DSWTOK=1 -DLITE=0 -DNOCDMF -DNOMD2 \ X+-D_THREAD_SAFE $(FPIC) -DSHALLOW=0 -DSWTOK=1 -DLITE=0 -DNOCDMF -DNOMD2 \ X -DNODSA -DDEBUGON -DAEP_GENERIC -DNORIPE -DSTDLL_NAME=\"aeptok\" X X opencryptoki_stdll_libpkcs11_aep_la_SOURCES = ../common/asn1.c \ 3f24ba189b1ba4dee357140896e27b09 echo x - opencryptoki/files/patch-usr-lib-pkcs11-api-Makefile.am sed 's/^X//' >opencryptoki/files/patch-usr-lib-pkcs11-api-Makefile.am << 'a623a243874976260a04ed84d947e9c2' X--- usr/lib/pkcs11/api/Makefile.am.orig 2010-07-29 21:28:41.000000000 +0900 X+++ usr/lib/pkcs11/api/Makefile.am 2010-10-19 23:49:45.125982519 +0900 X@@ -4,13 +4,13 @@ X SO_REVISION=0 X SO_AGE=0 X X-opencryptoki_libopencryptoki_la_LDFLAGS = -shared -Wl,-Bsymbolic -lc -ldl \ X+opencryptoki_libopencryptoki_la_LDFLAGS = -shared -Wl,-Bsymbolic -lc \ X -lpthread -version-info \ X $(SO_CURRENT):$(SO_REVISION):$(SO_AGE) X X # Not all versions of automake observe libname_CFLAGS X opencryptoki_libopencryptoki_la_CFLAGS = -DSPINXPL -DAPI -DDEV -D_THREAD_SAFE \ X- -fPIC -I../. -I../../../include/pkcs11 X+ $(FPIC) -I../. -I../../../include/pkcs11 X X opencryptoki_libopencryptoki_la_SOURCES = api_interface.c shrd_mem.c apiutil.c X a623a243874976260a04ed84d947e9c2 echo x - opencryptoki/files/patch-usr-lib-pkcs11-api-api_interface.c sed 's/^X//' >opencryptoki/files/patch-usr-lib-pkcs11-api-api_interface.c << 'cbc74013fef61cf67a1298020a0675cf' X--- usr/lib/pkcs11/api/api_interface.c.orig 2010-07-29 21:28:41.000000000 +0900 X+++ usr/lib/pkcs11/api/api_interface.c 2010-10-19 23:52:25.355983620 +0900 X@@ -2390,7 +2390,7 @@ X C_GetFunctionList ( CK_FUNCTION_LIST_PTR_PTR ppFunctionList ) X { X X- _init(); X+ api_init(); X X LOG("C_GetFunctionList"); X FuncList.version.major = VERSION_MAJOR; X@@ -5168,7 +5168,11 @@ X X } X X+#ifdef __sun X+#pragma init(api_init) X+#else X void api_init(void) __attribute__((constructor)); X+#endif X X void X api_init(void) X@@ -5194,7 +5198,11 @@ X X } X X+#ifdef __sun X+#pragma fini(api_fini) X+#else X void api_fini(void) __attribute__((destructor)); X+#endif X X void X api_fini() cbc74013fef61cf67a1298020a0675cf echo x - opencryptoki/files/patch-usr-lib-pkcs11-api-apiutil.c sed 's/^X//' >opencryptoki/files/patch-usr-lib-pkcs11-api-apiutil.c << '9c1475523ef8e41b383d8926ead6c09a' X--- usr/lib/pkcs11/api/apiutil.c.orig 2010-07-29 21:28:41.000000000 +0900 X+++ usr/lib/pkcs11/api/apiutil.c 2010-10-19 23:54:52.374982634 +0900 X@@ -305,10 +305,10 @@ X #include X #include X #include X-#include X #include X #include X #include X+#include X X #include X X@@ -325,10 +325,28 @@ X #include X #include X #include X-#include X static int xplfd=-1; X #endif X X+#ifdef __sun X+#define LOCK_EX F_LOCK X+#define LOCK_UN F_ULOCK X+#define flock(fd, func) lockf(fd, func, 0) X+#endif X+ X+#ifndef LOCK_SH X+#define LOCK_SH 1 /* shared lock */ X+#endif X+#ifndef LOCK_EX X+#define LOCK_EX 2 /* exclusive lock */ X+#endif X+#ifndef LOCK_NB X+#define LOCK_NB 4 /* don't block when locking */ X+#endif X+#ifndef LOCK_UN X+#define LOCK_UN 8 /* unlock */ X+#endif X+ X #include X X #define LIBLOCATION LIB_PATH 9c1475523ef8e41b383d8926ead6c09a echo x - opencryptoki/files/patch-usr-lib-pkcs11-api-shrd_mem.c.in sed 's/^X//' >opencryptoki/files/patch-usr-lib-pkcs11-api-shrd_mem.c.in << '233d06ea6eb5773680be5746327d0383' X--- usr/lib/pkcs11/api/shrd_mem.c.in.orig 2010-07-29 21:28:41.000000000 +0900 X+++ usr/lib/pkcs11/api/shrd_mem.c.in 2010-10-19 23:56:22.728981736 +0900 X@@ -353,7 +353,7 @@ X X X // SAB check for the group id here and membership here as well X- grp = getgrnam("pkcs11"); X+ grp = getgrnam(PKCS11GROUP); X if ( grp ) { X int i=0; X char member=0; 233d06ea6eb5773680be5746327d0383 echo x - opencryptoki/files/patch-usr-lib-pkcs11-bcom_stdll-Makefile.am sed 's/^X//' >opencryptoki/files/patch-usr-lib-pkcs11-bcom_stdll-Makefile.am << '4b300e6041f3cd546cd76d646ad887e7' X--- usr/lib/pkcs11/bcom_stdll/Makefile.am.orig 2010-07-29 21:28:41.000000000 +0900 X+++ usr/lib/pkcs11/bcom_stdll/Makefile.am 2010-10-19 23:57:38.434983522 +0900 X@@ -8,7 +8,7 @@ X X # Not all versions of automake observe libname_CFLAGS X opencryptoki_stdll_libpkcs11_bc_la_CFLAGS = -DSPINXPL -DDEV \ X--D_THREAD_SAFE -fPIC $(VARIANT) -DNOCDMF -DNOMD2 -DNODSA -DNOAES \ X+-D_THREAD_SAFE $(FPIC) $(VARIANT) -DNOCDMF -DNOMD2 -DNODSA -DNOAES \ X -DNODH -DDEBUGON -DNORIPE -DSTDLL_NAME=\"bcomtok\" X X opencryptoki_stdll_libpkcs11_bc_la_SOURCES = ../common/asn1.c \ 4b300e6041f3cd546cd76d646ad887e7 echo x - opencryptoki/files/patch-usr-lib-pkcs11-cca_stdll-host_defs.h sed 's/^X//' >opencryptoki/files/patch-usr-lib-pkcs11-cca_stdll-host_defs.h << 'fcd67028a5743a97083888e6e3fce52c' X--- usr/lib/pkcs11/cca_stdll/host_defs.h.orig 2010-07-29 21:28:41.000000000 +0900 X+++ usr/lib/pkcs11/cca_stdll/host_defs.h 2010-10-19 23:59:33.363984758 +0900 X@@ -10,13 +10,24 @@ X */ X X X+#include X #include X #ifndef _HOST_DEFS_H X #define _HOST_DEFS_H X X #include X #include X+#if defined(__OpenBSD__) || defined(__FreeBSD__) X+#include X+#ifdef _BYTE_ORDER X+#define __BYTE_ORDER _BYTE_ORDER X+#endif X+#ifdef _LITTLE_ENDIAN X+#define __LITTLE_ENDIAN _LITTLE_ENDIAN X+#endif X+#else X #include X+#endif X X #include "pkcs32.h" X // Both of the strings below have a length of 32 chars and must be fcd67028a5743a97083888e6e3fce52c echo x - opencryptoki/files/patch-usr-lib-pkcs11-cca_stdll-loadsave.c sed 's/^X//' >opencryptoki/files/patch-usr-lib-pkcs11-cca_stdll-loadsave.c << '5c92c9c229f35515bb4671f61df8a54f' X--- usr/lib/pkcs11/cca_stdll/loadsave.c.orig 2010-07-29 21:28:41.000000000 +0900 X+++ usr/lib/pkcs11/cca_stdll/loadsave.c 2010-10-20 01:49:50.769984323 +0900 X@@ -22,11 +22,9 @@ X #include X #include X #include X-#include X #include X #include X #include X-#include X #include X X #include X@@ -51,7 +49,7 @@ X // Set absolute permissions or rw-rw-r-- X fchmod(file,S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP|S_IROTH); X X- grp = getgrnam("pkcs11"); // Obtain the group id X+ grp = getgrnam(PKCS11GROUP); // Obtain the group id X if (grp){ X fchown(file,getuid(),grp->gr_gid); // set ownership to root, and pkcs11 group X } 5c92c9c229f35515bb4671f61df8a54f echo x - opencryptoki/files/patch-usr-lib-pkcs11-cca_stdll-new_host.c sed 's/^X//' >opencryptoki/files/patch-usr-lib-pkcs11-cca_stdll-new_host.c << 'd40d0b7dec7ca3e3fc985e9123c9e636' X--- usr/lib/pkcs11/cca_stdll/new_host.c.orig 2010-07-29 21:28:41.000000000 +0900 X+++ usr/lib/pkcs11/cca_stdll/new_host.c 2010-10-20 00:06:26.575983974 +0900 X@@ -298,7 +298,7 @@ X struct group *grp; X int rc = 0; X gid_t gid,egid; X- grp = getgrnam("pkcs11"); X+ grp = getgrnam(PKCS11GROUP); X if (grp) { X // Check for member of group.. X // SAB get login seems to not work with some X@@ -786,7 +786,19 @@ X // X object_mgr_destroy_token_objects(); X #if 0 /* TODO: Implement delete_all_files_in_dir() */ X+#if HAVE_ASPRINTF X local_rc = asprintf(&pk_full_path, "%s/%s", pk_dir, PK_LITE_OBJ_DIR); X+#else X+ pk_full_path = malloc(1024); X+ if( pk_full_path != NULL ) { X+ local_rc = snprintf(pk_full_path, 1023, "%s/%s", X+ pk_dir, PK_LITE_OBJ_DIR); X+ if( local_rc == -1 ) free(pk_full_path); X+ } X+ else { X+ local_rc = -1; X+ } X+#endif X if (local_rc == -1) { X rc = CKR_HOST_MEMORY; X goto out; X@@ -797,8 +809,20 @@ X goto out; X } X #endif X+#if HAVE_ASPRINTF X local_rc = asprintf(&s, "%s %s/%s/* > /dev/null 2>&1", DEL_CMD, pk_dir, X PK_LITE_OBJ_DIR); X+#else X+ s = malloc(1024); X+ if( s != NULL ) { X+ local_rc = snprintf(s, 1023, "%s %s/%s/* > /dev/null 2>&1", X+ DEL_CMD, pk_dir, PK_LITE_OBJ_DIR); X+ if( local_rc == -1 ) free(s); X+ } X+ else { X+ local_rc = -1; X+ } X+#endif X if (local_rc == -1) { X rc = CKR_HOST_MEMORY; X goto out; d40d0b7dec7ca3e3fc985e9123c9e636 echo x - opencryptoki/files/patch-usr-lib-pkcs11-cca_stdll-tok_spec_struct.h sed 's/^X//' >opencryptoki/files/patch-usr-lib-pkcs11-cca_stdll-tok_spec_struct.h << 'e5f074c237888e86017dd50b2276b829' X--- usr/lib/pkcs11/cca_stdll/tok_spec_struct.h.orig 2010-07-29 21:28:41.000000000 +0900 X+++ usr/lib/pkcs11/cca_stdll/tok_spec_struct.h 2010-10-20 00:08:00.317982423 +0900 X@@ -22,9 +22,9 @@ X #define _TOK_SPECIFIC_STRUCT X X struct token_specific_struct{ X- CK_BYTE token_directory[2048]; // Used to be in the token_local.h as a #def X- CK_BYTE token_subdir[2048]; // subdirectory X- CK_BYTE token_debug_tag[2048]; // debug logging tag X+ CK_BYTE *token_directory; // Used to be in the token_local.h as a #def X+ CK_BYTE *token_subdir; // subdirectory X+ CK_BYTE *token_debug_tag; // debug logging tag X X CK_RV (*t_init)(char *,CK_SLOT_ID); // Initialization function X int (*t_slot2local)(); // convert the PKCS#11 slot to a local index e5f074c237888e86017dd50b2276b829 echo x - opencryptoki/files/patch-usr-lib-pkcs11-common-host_defs.h sed 's/^X//' >opencryptoki/files/patch-usr-lib-pkcs11-common-host_defs.h << '39ed08aa6515acd003ce4a19841060e1' X--- usr/lib/pkcs11/common/host_defs.h.orig 2010-07-29 21:28:41.000000000 +0900 X+++ usr/lib/pkcs11/common/host_defs.h 2010-10-20 00:10:01.398983092 +0900 X@@ -294,13 +294,24 @@ X /* (C) COPYRIGHT International Business Machines Corp. 2001,2002 */ X X X+#include X #include X #ifndef _HOST_DEFS_H X #define _HOST_DEFS_H X X #include X #include X+#if defined(__OpenBSD__) || defined(__FreeBSD__) X+#include X+#ifdef _BYTE_ORDER X+#define __BYTE_ORDER _BYTE_ORDER X+#endif X+#ifdef _LITTLE_ENDIAN X+#define __LITTLE_ENDIAN _LITTLE_ENDIAN X+#endif X+#else X #include X+#endif X X #include "pkcs32.h" X // Both of the strings below have a length of 32 chars and must be 39ed08aa6515acd003ce4a19841060e1 echo x - opencryptoki/files/patch-usr-lib-pkcs11-common-loadsave.c sed 's/^X//' >opencryptoki/files/patch-usr-lib-pkcs11-common-loadsave.c << '4276b6e56c02ebbaa9e25b90fdeb9451' X--- usr/lib/pkcs11/common/loadsave.c.orig 2010-07-29 21:28:41.000000000 +0900 X+++ usr/lib/pkcs11/common/loadsave.c 2010-10-20 00:11:28.399983780 +0900 X@@ -301,11 +301,9 @@ X #include X #include X #include X-#include X #include X #include X #include X-#include X #include X X #include X@@ -328,7 +326,7 @@ X // Set absolute permissions or rw-rw-r-- X fchmod(file,S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP|S_IROTH); X X- grp = getgrnam("pkcs11"); // Obtain the group id X+ grp = getgrnam(PKCS11GROUP); // Obtain the group id X if (grp){ X fchown(file,getuid(),grp->gr_gid); // set ownership to root, and pkcs11 group X } 4276b6e56c02ebbaa9e25b90fdeb9451 echo x - opencryptoki/files/patch-usr-lib-pkcs11-common-new_host.c sed 's/^X//' >opencryptoki/files/patch-usr-lib-pkcs11-common-new_host.c << '539830893ffa52debc0f93f634b96128' X--- usr/lib/pkcs11/common/new_host.c.orig 2010-07-29 21:28:41.000000000 +0900 X+++ usr/lib/pkcs11/common/new_host.c 2010-10-20 00:16:08.274985517 +0900 X@@ -576,7 +576,7 @@ X struct group *grp; X int rc = 0; X gid_t gid,egid; X- grp = getgrnam("pkcs11"); X+ grp = getgrnam(PKCS11GROUP); X if (grp) { X // Check for member of group.. X // SAB get login seems to not work with some X@@ -1064,7 +1064,19 @@ X // X object_mgr_destroy_token_objects(); X #if 0 /* TODO: Implement delete_all_files_in_dir() */ X+#if HAVE_ASPRINTF X local_rc = asprintf(&pk_full_path, "%s/%s", pk_dir, PK_LITE_OBJ_DIR); X+#else X+ pk_full_path = malloc(1024); X+ if( pk_full_path != NULL ) { X+ local_rc = snprintf(pk_full_path, 1023, "%s/%s", X+ pk_dir, PK_LITE_OBJ_DIR); X+ if( local_rc == -1 ) free(pk_full_path); X+ } X+ else { X+ local_rc = -1; X+ } X+#endif X if (local_rc == -1) { X rc = CKR_HOST_MEMORY; X goto out; X@@ -1075,8 +1087,20 @@ X goto out; X } X #endif X+#if HAVE_ASPRINTF X local_rc = asprintf(&s, "%s %s/%s/* > /dev/null 2>&1", DEL_CMD, pk_dir, X PK_LITE_OBJ_DIR); X+#else X+ s = malloc(1024); X+ if( s != NULL ) { X+ local_rc = snprintf(s, 1023, "%s %s/%s/* > /dev/null 2>&1", X+ DEL_CMD, pk_dir, PK_LITE_OBJ_DIR); X+ if( local_rc == -1 ) free(s); X+ } X+ else { X+ local_rc = -1; X+ } X+#endif X if (local_rc == -1) { X rc = CKR_HOST_MEMORY; X goto out; 539830893ffa52debc0f93f634b96128 echo x - opencryptoki/files/patch-usr-lib-pkcs11-common-tok_spec_struct.h sed 's/^X//' >opencryptoki/files/patch-usr-lib-pkcs11-common-tok_spec_struct.h << 'c149cce0a7390bc1c5e7bc9fe6f2ee60' X--- usr/lib/pkcs11/common/tok_spec_struct.h.orig 2010-07-29 21:28:41.000000000 +0900 X+++ usr/lib/pkcs11/common/tok_spec_struct.h 2010-10-20 00:17:28.288984976 +0900 X@@ -308,9 +308,9 @@ X #define _TOK_SPECIFIC_STRUCT X X struct token_specific_struct{ X- CK_BYTE token_directory[PATH_MAX]; // Used to be in the token_local.h as a #def X- CK_BYTE token_subdir[PATH_MAX]; // subdirectory X- CK_BYTE token_debug_tag[PATH_MAX]; // debug logging tag X+ CK_BYTE *token_directory; // Used to be in the token_local.h as a #def X+ CK_BYTE *token_subdir; // subdirectory X+ CK_BYTE *token_debug_tag; // debug logging tag X X CK_RV (*t_init)(char *,CK_SLOT_ID); // Initialization function X int (*t_slot2local)(); // convert the PKCS#11 slot to a local index c149cce0a7390bc1c5e7bc9fe6f2ee60 echo x - opencryptoki/files/patch-usr-lib-pkcs11-common-utility.c sed 's/^X//' >opencryptoki/files/patch-usr-lib-pkcs11-common-utility.c << '77e8868c45982b0cfee169bb03f75a5d' X--- usr/lib/pkcs11/common/utility.c.orig 2010-07-29 21:28:41.000000000 +0900 X+++ usr/lib/pkcs11/common/utility.c 2010-10-20 00:19:02.740983592 +0900 X@@ -302,6 +302,26 @@ X #include X #include X X+#include X+ X+#ifdef __sun X+#define LOCK_EX F_LOCK X+#define LOCK_UN F_ULOCK X+#define flock(fd, func) lockf(fd, func, 0) X+#endif X+ X+#ifndef LOCK_SH X+#define LOCK_SH 1 /* shared lock */ X+#endif X+#ifndef LOCK_EX X+#define LOCK_EX 2 /* exclusive lock */ X+#endif X+#ifndef LOCK_NB X+#define LOCK_NB 4 /* don't block when locking */ X+#endif X+#ifndef LOCK_UN X+#define LOCK_UN 8 /* unlock */ X+#endif X X #include "pkcs11types.h" X #include "defs.h" 77e8868c45982b0cfee169bb03f75a5d echo x - opencryptoki/files/patch-usr-lib-pkcs11-cr_stdll-Makefile.am sed 's/^X//' >opencryptoki/files/patch-usr-lib-pkcs11-cr_stdll-Makefile.am << '44e019f344ba07311bc6ff07fbcf9363' X--- usr/lib/pkcs11/cr_stdll/Makefile.am.orig 2010-07-29 21:28:41.000000000 +0900 X+++ usr/lib/pkcs11/cr_stdll/Makefile.am 2010-10-20 00:20:46.987982761 +0900 X@@ -2,13 +2,13 @@ X X opencryptoki_stdll_libpkcs11_cr_la_LDFLAGS = $(LCRYPTO) $(CR_LIB_DIRS) \ X -nostartfiles -shared -Wl,-Bsymbolic -Wl,-soname,PKCS11_BC.so.1 -lc \ X--lpthread -lsocketarmor -ldl -lcrypto X+-lpthread -lsocketarmor -lcrypto X X VARIANT = -DSHALLOW=0 -DSWTOK=1 -DLITE=0 X X # Not all versions of automake observe libname_CFLAGS X opencryptoki_stdll_libpkcs11_cr_la_CFLAGS = -DSPINXPL -DDEV \ X--D_THREAD_SAFE -fPIC $(VARIANT) -DNOCDMF -DNOMD2 -DNODSA -DDEBUGON X+-D_THREAD_SAFE $(FPIC) $(VARIANT) -DNOCDMF -DNOMD2 -DNODSA -DDEBUGON X X opencryptoki_stdll_libpkcs11_cr_la_SOURCES = ../common/asn1.c \ X ../common/cert.c ../common/hwf_obj.c ../common/dp_obj.c \ 44e019f344ba07311bc6ff07fbcf9363 echo x - opencryptoki/files/patch-usr-lib-pkcs11-ica_s390_stdll-Makefile.am sed 's/^X//' >opencryptoki/files/patch-usr-lib-pkcs11-ica_s390_stdll-Makefile.am << '8c93a57494e6120cf53add028bc14f01' X--- usr/lib/pkcs11/ica_s390_stdll/Makefile.am.orig 2010-07-29 21:28:41.000000000 +0900 X+++ usr/lib/pkcs11/ica_s390_stdll/Makefile.am 2010-10-20 00:22:00.867981839 +0900 X@@ -2,11 +2,11 @@ X X opencryptoki_stdll_libpkcs11_ica_la_LDFLAGS = $(LCRYPTO) \ X $(ICA_LIB_DIRS) -nostartfiles -shared -Wl,-Bsymbolic -Wl,-soname,$@ \ X--Wl,-Bsymbolic -lc -lpthread -lica -ldl -lcrypto X+-Wl,-Bsymbolic -lc -lpthread -lica -lcrypto X X # Not all versions of automake observe libname_CFLAGS X opencryptoki_stdll_libpkcs11_ica_la_CFLAGS = -DSPINXPL -DDEV \ X--D_THREAD_SAFE -fPIC -DSHALLOW=0 -DSWTOK=0 -DLITE=1 -DNODH \ X+-D_THREAD_SAFE $(FPIC) -DSHALLOW=0 -DSWTOK=0 -DLITE=1 -DNODH \ X -DNOCDMF -DNOMD2 -DNODSA -DSTDLL_NAME=\"icatok\" X X opencryptoki_stdll_libpkcs11_ica_la_SOURCES = ../common/asn1.c \ 8c93a57494e6120cf53add028bc14f01 echo x - opencryptoki/files/patch-usr-lib-pkcs11-ica_stdll-Makefile.am sed 's/^X//' >opencryptoki/files/patch-usr-lib-pkcs11-ica_stdll-Makefile.am << 'b83bc89dfb09f3cc0910f849a8f74138' X--- usr/lib/pkcs11/ica_stdll/Makefile.am.orig 2010-07-29 21:28:41.000000000 +0900 X+++ usr/lib/pkcs11/ica_stdll/Makefile.am 2010-10-20 00:23:51.161996275 +0900 X@@ -2,15 +2,15 @@ X X opencryptoki_stdll_libpkcs11_ica_la_LDFLAGS = $(LCRYPTO) \ X $(ICA_LIB_DIRS) -nostartfiles -shared -Wl,-Bsymbolic \ X--Wl,-soname,PKCS11_ICA.so.1 -lc -lpthread -ldl -lica X+-Wl,-soname,PKCS11_ICA.so.1 -lc -lpthread -lica X X # Not all versions of automake observe libname_CFLAGS X opencryptoki_stdll_libpkcs11_ica_la_CFLAGS = -DSPINXPL -DDEV \ X--D_THREAD_SAFE -fPIC -DSHALLOW=0 -DSWTOK=0 -DLITE=1 -DNOCDMF -DNOMD2 \ X+-D_THREAD_SAFE $(FPIC) -DSHALLOW=0 -DSWTOK=0 -DLITE=1 -DNOCDMF -DNOMD2 \ X -DNODSA -DNOAES -DNODH -DNORIPE -DSTDLL_NAME=\"icatok\" X X # Not all versions of automake observe libname_CFLAGS X-AM_CFLAGS = -DSPINXPL -DDEV -D_THREAD_SAFE -fPIC -DSHALLOW=0 -DSWTOK=0 \ X+AM_CFLAGS = -DSPINXPL -DDEV -D_THREAD_SAFE $(FPIC) -DSHALLOW=0 -DSWTOK=0 \ X -DLITE=1 -DNOCDMF -DNOMD2 -DNODSA -DNOAES -DNODH -DNORIPE X X opencryptoki_stdll_libpkcs11_ica_la_SOURCES= ../common/asn1.c \ b83bc89dfb09f3cc0910f849a8f74138 echo x - opencryptoki/files/patch-usr-lib-pkcs11-soft_stdll-Makefile.am sed 's/^X//' >opencryptoki/files/patch-usr-lib-pkcs11-soft_stdll-Makefile.am << '573ae8919b6e13d479790124e490c7b7' X--- usr/lib/pkcs11/soft_stdll/Makefile.am.orig 2010-07-29 21:28:41.000000000 +0900 X+++ usr/lib/pkcs11/soft_stdll/Makefile.am 2010-10-20 00:25:03.227984225 +0900 X@@ -7,7 +7,7 @@ X opencryptoki_stdll_libpkcs11_sw_la_CFLAGS = -DSPINXPL -DDEV -D_THREAD_SAFE \ X -DSHALLOW=0 -DSWTOK=1 -DLITE=0 \ X -DNOCDMF -DNOMD2 -DNODSA -DNORIPE \ X- -DDEBUGON -fPIC \ X+ -DDEBUGON $(FPIC) \ X -I/usr/include -I. \ X -I../../../include/pkcs11/stdll \ X -I../../../include/pkcs11 \ 573ae8919b6e13d479790124e490c7b7 echo x - opencryptoki/files/patch-usr-lib-pkcs11-tpm_stdll-host_defs.h sed 's/^X//' >opencryptoki/files/patch-usr-lib-pkcs11-tpm_stdll-host_defs.h << 'e052f0434b86a0e14c8810f6a03db6fd' X--- usr/lib/pkcs11/tpm_stdll/host_defs.h.orig 2010-07-29 21:28:41.000000000 +0900 X+++ usr/lib/pkcs11/tpm_stdll/host_defs.h 2010-10-20 00:26:48.474982648 +0900 X@@ -2,13 +2,25 @@ X /* (C) COPYRIGHT International Business Machines Corp. 2001, 2002, 2005*/ X X X+#include X #include X #ifndef _HOST_DEFS_H X #define _HOST_DEFS_H X X #include X #include X+ X+#if defined(__OpenBSD__) || defined(__FreeBSD__) X+#include X+#ifdef _BYTE_ORDER X+#define __BYTE_ORDER _BYTE_ORDER X+#endif X+#ifdef _LITTLE_ENDIAN X+#define __LITTLE_ENDIAN _LITTLE_ENDIAN X+#endif X+#else X #include X+#endif X X #include "pkcs32.h" X // Both of the strings below have a length of 32 chars and must be e052f0434b86a0e14c8810f6a03db6fd echo x - opencryptoki/files/patch-usr-lib-pkcs11-tpm_stdll-loadsave.c sed 's/^X//' >opencryptoki/files/patch-usr-lib-pkcs11-tpm_stdll-loadsave.c << '7f2fcb4011b87cbfa62228aa77f5246a' X--- usr/lib/pkcs11/tpm_stdll/loadsave.c.orig 2010-07-29 21:28:41.000000000 +0900 X+++ usr/lib/pkcs11/tpm_stdll/loadsave.c 2010-10-20 00:27:47.109983972 +0900 X@@ -339,7 +339,7 @@ X fchmod(file,S_IRUSR|S_IWUSR); X X #if 0 X- grp = getgrnam("pkcs11"); // Obtain the group id X+ grp = getgrnam(PKCS11GROUP); // Obtain the group id X if (grp){ X fchown(file,getuid(),grp->gr_gid); // set ownership to root, and pkcs11 group X } 7f2fcb4011b87cbfa62228aa77f5246a echo x - opencryptoki/files/patch-usr-lib-pkcs11-tpm_stdll-new_host.c sed 's/^X//' >opencryptoki/files/patch-usr-lib-pkcs11-tpm_stdll-new_host.c << '24f2426f6be8691303853d0c1117ca14' X--- usr/lib/pkcs11/tpm_stdll/new_host.c.orig 2010-07-29 21:28:41.000000000 +0900 X+++ usr/lib/pkcs11/tpm_stdll/new_host.c 2010-10-20 00:29:17.108984288 +0900 X@@ -356,7 +356,7 @@ X int rc = 0; X int index = 0; X gid_t gid,egid; X- grp = getgrnam("pkcs11"); X+ grp = getgrnam(PKCS11GROUP); X if ( grp ) { X // Check for member of group.. X 24f2426f6be8691303853d0c1117ca14 echo x - opencryptoki/files/patch-usr-lib-pkcs11-tpm_stdll-tok_spec_struct.h sed 's/^X//' >opencryptoki/files/patch-usr-lib-pkcs11-tpm_stdll-tok_spec_struct.h << 'dc54ee9fd8bf2e2cc64593f9499647b5' X--- usr/lib/pkcs11/tpm_stdll/tok_spec_struct.h.orig 2010-07-29 21:28:41.000000000 +0900 X+++ usr/lib/pkcs11/tpm_stdll/tok_spec_struct.h 2010-10-20 00:30:22.991986453 +0900 X@@ -33,9 +33,9 @@ X #define _TOK_SPECIFIC_STRUCT X X struct token_specific_struct{ X- CK_BYTE token_directory[PATH_MAX]; // Used to be in the token_local.h as a #def X- CK_BYTE token_subdir[PATH_MAX]; // subdirectory X- CK_BYTE token_debug_tag[PATH_MAX]; // debug logging tag X+ CK_BYTE *token_directory; // Used to be in the token_local.h as a #def X+ CK_BYTE *token_subdir; // subdirectory X+ CK_BYTE *token_debug_tag; // debug logging tag X X CK_RV (*t_init)(char *,CK_SLOT_ID); // Initialization function X int (*t_slot2local)(); // convert the PKCS#11 slot to a local index dc54ee9fd8bf2e2cc64593f9499647b5 echo x - opencryptoki/files/patch-usr-lib-pkcs11-tpm_stdll-utility.c sed 's/^X//' >opencryptoki/files/patch-usr-lib-pkcs11-tpm_stdll-utility.c << '420526561e1928908234af336d8466d4' X--- usr/lib/pkcs11/tpm_stdll/utility.c.orig 2010-07-29 21:28:41.000000000 +0900 X+++ usr/lib/pkcs11/tpm_stdll/utility.c 2010-10-20 00:33:02.810983787 +0900 X@@ -44,6 +44,27 @@ X #include "tok_spec_struct.h" X #include "pkcs32.h" X X+#include X+ X+#ifdef __sun X+#define LOCK_EX F_LOCK X+#define LOCK_UN F_ULOCK X+#define flock(fd, func) lockf(fd, func, 0) X+#endif X+ X+#ifndef LOCK_SH X+#define LOCK_SH 1 /* shared lock */ X+#endif X+#ifndef LOCK_EX X+#define LOCK_EX 2 /* exclusive lock */ X+#endif X+#ifndef LOCK_NB X+#define LOCK_NB 4 /* don't block when locking */ X+#endif X+#ifndef LOCK_UN X+#define LOCK_UN 8 /* unlock */ X+#endif X+ X #if (SPINXPL) X #include X #endif 420526561e1928908234af336d8466d4 echo x - opencryptoki/files/patch-usr-sbin-pkcs11_startup-Makefile.am sed 's/^X//' >opencryptoki/files/patch-usr-sbin-pkcs11_startup-Makefile.am << 'e638cfb2518512a41c7f4bd7ebebc006' X--- usr/sbin/pkcs11_startup/Makefile.am.orig 2010-07-29 21:28:41.000000000 +0900 X+++ usr/sbin/pkcs11_startup/Makefile.am 2010-10-22 00:59:30.397048865 +0900 X@@ -12,6 +12,8 @@ X -e s!\@ID\@!"@ID@"!g \ X -e s!\@CAT\@!"@CAT@"!g \ X -e s!\@SED\@!"@SED@"!g \ X+ -e s!\@PKCS11USER\@!"@PKCS11USER@"!g \ X+ -e s!\@PKCS11GROUP\@!"@PKCS11GROUP@"!g \ X -e s!\@GROUPADD\@!"@GROUPADD@"!g \ X -e s!\@USERMOD\@!"@USERMOD@"!g < $< > $@-t X @CHMOD@ +x $@-t e638cfb2518512a41c7f4bd7ebebc006 echo x - opencryptoki/files/patch-usr-sbin-pkcs11_startup-pkcs11_startup.in sed 's/^X//' >opencryptoki/files/patch-usr-sbin-pkcs11_startup-pkcs11_startup.in << 'f01391ab670353b99f14d4208feeefd2' X--- usr/sbin/pkcs11_startup/pkcs11_startup.in.orig 2010-07-29 21:28:41.000000000 +0900 X+++ usr/sbin/pkcs11_startup/pkcs11_startup.in 2010-10-22 00:57:35.508983672 +0900 X@@ -1,4 +1,4 @@ X-#!/bin/bash X+#!/bin/sh X X # X # X@@ -310,29 +310,20 @@ X X X # Create the pkcs11 group if it does not exist... X-cat /etc/group|grep pkcs11 >/dev/null 2>&1 X+cat /etc/group|grep @PKCS11GROUP@ >/dev/null 2>&1 X rc=$? X if [ $rc = 1 ] X then X if [ -x @GROUPADD@ ] X then X- @GROUPADD@ pkcs11 >/dev/null 2>&1 X+ @GROUPADD@ @PKCS11GROUP@ >/dev/null 2>&1 X X else X- echo "Couldn't execute @GROUPADD@. Please add the group 'pkcs11' manually." X+ echo "Couldn't execute @GROUPADD@. Please add the group '@PKCS11GROUP@' manually." X fi X fi X X X-if [ -x @USERMOD@ -a -x @ID@ ] X-then X- # add the pkcs group X- # replace spaces by commas X- @USERMOD@ -G $( @ID@ --groups --name root | @SED@ -e 'y/ /,/'),pkcs11 root X-else X- echo "Couldn't execute @USERMOD@. Please add root to the group 'pkcs11' manually." X-fi X- X X # For each card run the status command and if successful X # create the odm stanza for the file f01391ab670353b99f14d4208feeefd2 echo x - opencryptoki/files/patch-usr-sbin-pkcs_slot-pkcs_slot.in sed 's/^X//' >opencryptoki/files/patch-usr-sbin-pkcs_slot-pkcs_slot.in << 'dabbf41c80650a92864c60ab257f1e9b' X--- usr/sbin/pkcs_slot/pkcs_slot.in.orig 2010-07-29 21:28:41.000000000 +0900 X+++ usr/sbin/pkcs_slot/pkcs_slot.in 2010-10-22 00:42:38.286985256 +0900 X@@ -1,4 +1,4 @@ X-#!/bin/bash X+#!/bin/sh X X # X # X@@ -360,7 +360,7 @@ X if [ ! -d @localstatedir@/lib/opencryptoki ] X then X @MKDIR_P@ @localstatedir@/lib/opencryptoki X- @CHGRP@ pkcs11 @localstatedir@/lib/opencryptoki X+ @CHGRP@ @PKCS11GROUP@ @localstatedir@/lib/opencryptoki X @CHMOD@ -R g+rwX @localstatedir@/lib/opencryptoki X fi X X@@ -372,9 +372,9 @@ X if [ $? -ne 0 ] X then X mkdir $SOFT_DIR X- @CHGRP@ pkcs11 $SOFT_DIR X+ @CHGRP@ @PKCS11GROUP@ $SOFT_DIR X mkdir "$SOFT_DIR"/TOK_OBJ X- @CHGRP@ pkcs11 "$SOFT_DIR"/TOK_OBJ X+ @CHGRP@ @PKCS11GROUP@ "$SOFT_DIR"/TOK_OBJ X fi X SYS_SLOT="Soft" X fi X@@ -386,7 +386,7 @@ X if [ $? -ne 0 ] X then X mkdir $TPM_DIR X- @CHGRP@ pkcs11 $TPM_DIR X+ @CHGRP@ @PKCS11GROUP@ $TPM_DIR X fi X SYS_SLOT="TPM" X fi X@@ -397,7 +397,7 @@ X if [ $? -ne 0 ] X then X mkdir $CCA_DIR X- @CHGRP@ pkcs11 $CCA_DIR X+ @CHGRP@ @PKCS11GROUP@ $CCA_DIR X mkdir "$CCA_DIR"/TOK_OBJ X @CHGRP@ pkcs11 "$CCA_DIR"/TOK_OBJ X fi X@@ -406,7 +406,7 @@ X X # If we are using a shallow device, make sure that the directory X # to store token objects is available, if not create it and change X-# the ownership to the pkcs11 group X+# the ownership to the @PKCS11GROUP@ group X X X if [ $DEPTH = "ica" ] X@@ -415,9 +415,9 @@ X if [ $? -ne 0 ] X then X mkdir $ICA_DIR X- @CHGRP@ pkcs11 $ICA_DIR X+ @CHGRP@ @PKCS11GROUP@ $ICA_DIR X mkdir "$ICA_DIR"/TOK_OBJ X- @CHGRP@ pkcs11 "$ICA_DIR"/TOK_OBJ X+ @CHGRP@ @PKCS11GROUP@ "$ICA_DIR"/TOK_OBJ X fi X SYS_SLOT="ICA" X fi X@@ -428,9 +428,9 @@ X if [ $? -ne 0 ] X then X mkdir $BCOM_DIR X- @CHGRP@ pkcs11 $BCOM_DIR X+ @CHGRP@ @PKCS11GROUP@ $BCOM_DIR X mkdir "$BCOM_DIR"/TOK_OBJ X- @CHGRP@ pkcs11 "$BCOM_DIR"/TOK_OBJ X+ @CHGRP@ @PKCS11GROUP@ "$BCOM_DIR"/TOK_OBJ X fi X SYS_SLOT="BCOM" X fi X@@ -441,9 +441,9 @@ X if [ $? -ne 0 ] X then X mkdir $AEP_DIR X- @CHGRP@ pkcs11 $AEP_DIR X+ @CHGRP@ @PKCS11GROUP@ $AEP_DIR X mkdir "$AEP_DIR"/TOK_OBJ X- @CHGRP@ pkcs11 "$AEP_DIR"/TOK_OBJ X+ @CHGRP@ @PKCS11GROUP@ "$AEP_DIR"/TOK_OBJ X fi X SYS_SLOT="AEP" X fi X@@ -454,9 +454,9 @@ X if [ $? -ne 0 ] X then X mkdir $CR_DIR X- @CHGRP@ pkcs11 $CR_DIR X+ @CHGRP@ @PKCS11GROUP@ $CR_DIR X mkdir "$CR_DIR"/TOK_OBJ X- @CHGRP@ pkcs11 "$CR_DIR"/TOK_OBJ X+ @CHGRP@ @PKCS11GROUP@ "$CR_DIR"/TOK_OBJ X fi X SYS_SLOT="CRNT" X fi X@@ -477,29 +477,29 @@ X X if [ $DEPTH = "deep" ] X then X-echo "TRUE|0|$SLOT_DESCRIPTION|$MANUFACTURER|TRUE|FALSE|TRUE|0|0|1|1|$DEVICE|$DEEP4758_DLL_FN|$DEEP4758_INIT" >>$CFGFILE X+echo "TRUE|0|$SLOT_DESCRIPTION|$MANUFACTURER|TRUE|FALSE|TRUE|0|0|1|1|$DEVICE|$DEEP4758_DLL|$DEEP4758_INIT" >>$CFGFILE X X elif [ $DEPTH = "ica" ] X then X-echo "TRUE|0|$SLOT_DESCRIPTION|$MANUFACTURER|TRUE|FALSE|TRUE|0|0|1|1|NONE|$ICA_DLL_FN|$ICA_INIT" >>$CFGFILE X+echo "TRUE|0|$SLOT_DESCRIPTION|$MANUFACTURER|TRUE|FALSE|TRUE|0|0|1|1|NONE|$ICA_DLL|$ICA_INIT" >>$CFGFILE X elif [ $DEPTH = "bcom" ] X then X-echo "TRUE|0|$SLOT_DESCRIPTION|$MANUFACTURER|TRUE|FALSE|TRUE|0|0|1|1|NONE|$BCOM_DLL_FN|$BCOM_INIT" >>$CFGFILE X+echo "TRUE|0|$SLOT_DESCRIPTION|$MANUFACTURER|TRUE|FALSE|TRUE|0|0|1|1|NONE|$BCOM_DLL|$BCOM_INIT" >>$CFGFILE X elif [ $DEPTH = "aep" ] X then X-echo "TRUE|0|$SLOT_DESCRIPTION|$MANUFACTURER|TRUE|FALSE|TRUE|0|0|1|1|NONE|$AEP_DLL_FN|$AEP_INIT" >>$CFGFILE X+echo "TRUE|0|$SLOT_DESCRIPTION|$MANUFACTURER|TRUE|FALSE|TRUE|0|0|1|1|NONE|$AEP_DLL|$AEP_INIT" >>$CFGFILE X elif [ $DEPTH = "cr" ] X then X-echo "TRUE|0|$SLOT_DESCRIPTION|$MANUFACTURER|TRUE|FALSE|TRUE|0|0|1|1|NONE|$CR_DLL_FN|$CR_INIT" >>$CFGFILE X+echo "TRUE|0|$SLOT_DESCRIPTION|$MANUFACTURER|TRUE|FALSE|TRUE|0|0|1|1|NONE|$CR_DLL|$CR_INIT" >>$CFGFILE X elif [ $DEPTH = "soft" ] X then X-echo "TRUE|0|$SLOT_DESCRIPTION|$MANUFACTURER|TRUE|FALSE|FALSE|0|0|1|1|NONE|$SOFT_DLL_FN|$SOFT_INIT" >>$CFGFILE X+echo "TRUE|0|$SLOT_DESCRIPTION|$MANUFACTURER|TRUE|FALSE|FALSE|0|0|1|1|NONE|$SOFT_DLL|$SOFT_INIT" >>$CFGFILE X elif [ $DEPTH = "tpm" ] X then X-echo "TRUE|0|$SLOT_DESCRIPTION|$MANUFACTURER|TRUE|FALSE|TRUE|0|0|1|1|NONE|$TPM_DLL_FN|$TPM_INIT" >>$CFGFILE X+echo "TRUE|0|$SLOT_DESCRIPTION|$MANUFACTURER|TRUE|FALSE|TRUE|0|0|1|1|NONE|$TPM_DLL|$TPM_INIT" >>$CFGFILE X elif [ $DEPTH = "cca" ] X then X-echo "TRUE|0|$SLOT_DESCRIPTION|$MANUFACTURER|TRUE|FALSE|TRUE|0|0|1|1|NONE|$CCA_DLL_FN|$CCA_INIT" >>$CFGFILE X+echo "TRUE|0|$SLOT_DESCRIPTION|$MANUFACTURER|TRUE|FALSE|TRUE|0|0|1|1|NONE|$CCA_DLL|$CCA_INIT" >>$CFGFILE X fi X X @CHMOD@ -R g+wrX @localstatedir@/lib/opencryptoki dabbf41c80650a92864c60ab257f1e9b echo x - opencryptoki/files/patch-usr-sbin-pkcsconf-Makefile.am sed 's/^X//' >opencryptoki/files/patch-usr-sbin-pkcsconf-Makefile.am << 'd30fd3117805ef384d8fab8f854bb96a' X--- usr/sbin/pkcsconf/Makefile.am.orig 2010-07-29 21:28:41.000000000 +0900 X+++ usr/sbin/pkcsconf/Makefile.am 2010-10-20 00:46:34.600985372 +0900 X@@ -1,6 +1,6 @@ X sbin_PROGRAMS=pkcsconf X X-pkcsconf_LDFLAGS = -lpthread -ldl X+pkcsconf_LDFLAGS = -lpthread X X # Not all versions of automake observe sbinname_CFLAGS X pkcsconf_CFLAGS = -DSPINXPL -D_THREAD_SAFE -DDEBUG -DDEV -DAPI d30fd3117805ef384d8fab8f854bb96a echo x - opencryptoki/files/patch-usr-sbin-pkcsconf-pkcsconf.c sed 's/^X//' >opencryptoki/files/patch-usr-sbin-pkcsconf-pkcsconf.c << 'bc76b15dc0416402cd2da19022323e72' X--- usr/sbin/pkcsconf/pkcsconf.c.orig 2010-07-29 21:28:41.000000000 +0900 X+++ usr/sbin/pkcsconf/pkcsconf.c 2010-10-20 00:47:46.462984231 +0900 X@@ -654,6 +654,8 @@ X free (newpin2); X } X X+ cleanup(); X+ X return rc; X X } bc76b15dc0416402cd2da19022323e72 echo x - opencryptoki/files/patch-usr-sbin-pkcsslotd-err.c sed 's/^X//' >opencryptoki/files/patch-usr-sbin-pkcsslotd-err.c << '885d321e2542d044a5681817002baac8' X--- usr/sbin/pkcsslotd/err.c.orig 2010-07-29 21:28:41.000000000 +0900 X+++ usr/sbin/pkcsslotd/err.c 2010-10-20 01:17:17.245985003 +0900 X@@ -288,6 +288,7 @@ X X /* (C) COPYRIGHT International Business Machines Corp. 2001 */ X X+#include X X #include "pthread.h" X X@@ -331,14 +332,30 @@ X CONSTINFO(ERANGE), X CONSTINFO(ENOMSG), X CONSTINFO(EIDRM), X+#ifdef ECHRNG X CONSTINFO(ECHRNG), X+#endif X+#ifdef EL2NSYNC X CONSTINFO(EL2NSYNC), X+#endif X+#ifdef EL3HLT X CONSTINFO(EL3HLT), X+#endif X+#ifdef EL3RST X CONSTINFO(EL3RST), X+#endif X+#ifdef ELNRNG X CONSTINFO(ELNRNG), X+#endif X+#ifdef EUNATCH X CONSTINFO(EUNATCH), X+#endif X+#ifdef ENOCSI X CONSTINFO(ENOCSI), X+#endif X+#ifdef EL2HLT X CONSTINFO(EL2HLT), X+#endif X CONSTINFO(EDEADLK), X CONSTINFO(ESTALE), X CONSTINFO(EWOULDBLOCK), X@@ -369,7 +386,9 @@ X CONSTINFO(ECONNREFUSED), X CONSTINFO(EHOSTDOWN), X CONSTINFO(EHOSTUNREACH), X+#ifdef ERESTART X CONSTINFO(ERESTART), X+#endif X CONSTINFO(EUSERS), X CONSTINFO(ELOOP), X CONSTINFO(ENAMETOOLONG), X@@ -380,16 +399,34 @@ X CONSTINFO(ETOOMANYREFS), X CONSTINFO(EILSEQ), X CONSTINFO(ECANCELED), X+#ifdef ENOSR X CONSTINFO(ENOSR), X+#endif X+#ifdef ETIME X CONSTINFO(ETIME), X+#endif X+#ifdef EBADMSG X CONSTINFO(EBADMSG), X+#endif X+#ifdef EPROTO X CONSTINFO(EPROTO), X+#endif X+#ifdef ENODATA X CONSTINFO(ENODATA), X+#endif X+#ifdef ENOSTR X CONSTINFO(ENOSTR), X+#endif X CONSTINFO(ENOTSUP), X+#ifdef EMULTIHOP X CONSTINFO(EMULTIHOP), X+#endif X+#ifdef ENOLINK X CONSTINFO(ENOLINK), X+#endif X+#ifdef EOVERFLOW X CONSTINFO(EOVERFLOW), X+#endif X X }; X X@@ -424,14 +461,20 @@ X CONSTINFO(SIGXCPU), X CONSTINFO(SIGXFSZ), X CONSTINFO(SIGWINCH), X+#ifdef SIGPWR X CONSTINFO(SIGPWR), X+#endif X CONSTINFO(SIGUSR1), X CONSTINFO(SIGUSR2), X CONSTINFO(SIGPROF), X CONSTINFO(SIGVTALRM), X CONSTINFO(SIGIOT), X+#ifdef SIGCLD X CONSTINFO(SIGCLD), X+#endif X+#ifdef SIGPOLL X CONSTINFO(SIGPOLL), X+#endif X #if 0 X CONSTINFO(SIG_DFL), X CONSTINFO(SIG_IGN), 885d321e2542d044a5681817002baac8 echo x - opencryptoki/files/patch-usr-sbin-pkcsslotd-mutex.c sed 's/^X//' >opencryptoki/files/patch-usr-sbin-pkcsslotd-mutex.c << '6df008249a1d8796bc0e8713ccdc0567' X--- usr/sbin/pkcsslotd/mutex.c.orig 2010-07-29 21:28:41.000000000 +0900 X+++ usr/sbin/pkcsslotd/mutex.c 2010-10-20 01:19:28.613984045 +0900 X@@ -293,6 +293,26 @@ X X #include "pkcsslotd.h" X X+#include X+ X+#ifdef __sun X+#define LOCK_EX F_LOCK X+#define LOCK_UN F_ULOCK X+#define flock(fd, func) lockf(fd, func, 0) X+#endif X+ X+#ifndef LOCK_SH X+#define LOCK_SH 1 /* shared lock */ X+#endif X+#ifndef LOCK_EX X+#define LOCK_EX 2 /* exclusive lock */ X+#endif X+#ifndef LOCK_NB X+#define LOCK_NB 4 /* don't block when locking */ X+#endif X+#ifndef LOCK_UN X+#define LOCK_UN 8 /* unlock */ X+#endif X X #if SYSVSEM X #error "Caveat Emptor... this does not work" X@@ -315,7 +335,6 @@ X #include X #include X #include X-#include X static int xplfd=-1; X #endif X 6df008249a1d8796bc0e8713ccdc0567 echo x - opencryptoki/files/patch-usr-sbin-pkcsslotd-pkcsslotd.h sed 's/^X//' >opencryptoki/files/patch-usr-sbin-pkcsslotd-pkcsslotd.h << '8ea35fc8c0ea5d77b0d72b9c285851bc' X--- usr/sbin/pkcsslotd/pkcsslotd.h.orig 2010-07-29 21:28:41.000000000 +0900 X+++ usr/sbin/pkcsslotd/pkcsslotd.h 2010-10-20 01:20:18.253984238 +0900 X@@ -353,7 +353,7 @@ X #include X X #include X-#include X+#include X #include X #include X #include 8ea35fc8c0ea5d77b0d72b9c285851bc echo x - opencryptoki/files/patch-usr-sbin-pkcsslotd-shmem.c sed 's/^X//' >opencryptoki/files/patch-usr-sbin-pkcsslotd-shmem.c << '22c3cc0c492381c803955a9e2480f74b' X--- usr/sbin/pkcsslotd/shmem.c.orig 2010-07-29 21:28:41.000000000 +0900 X+++ usr/sbin/pkcsslotd/shmem.c 2010-10-20 01:23:03.203984101 +0900 X@@ -338,9 +338,9 @@ X } X // SAB Get the group information for the PKCS#11 group... fail if X // it does not exist X- grp = getgrnam("pkcs11"); X+ grp = getgrnam(PKCS11GROUP); X if ( !grp ) { X- ErrLog("Group PKCS#11 does not exist "); X+ ErrLog("Group " PKCS11GROUP " does not exist "); X return FALSE; // Group does not exist... setup is wrong.. X } X X@@ -409,9 +409,9 @@ X int i; X char *buffer; X X- grp = getgrnam("pkcs11"); X+ grp = getgrnam(PKCS11GROUP); X if ( !grp ) { X- ErrLog("Group \"pkcs11\" does not exist! Please run %s/pkcs11_startup.", X+ ErrLog("Group " PKCS11GROUP " does not exist! Please run %s/pkcs11_startup.", X SBIN_PATH); X return FALSE; // Group does not exist... setup is wrong.. X } X@@ -431,7 +431,7 @@ X return FALSE; X } X if (fchown(fd, 0, grp->gr_gid) == -1) { X- ErrLog("%s: fchown(%s, root, pkcs11): %s", __FUNCTION__, MAPFILENAME, X+ ErrLog("%s: fchown(%s, root, %s): %s", __FUNCTION__, MAPFILENAME, PKCS11GROUP, X strerror(errno)); X close(fd); X return FALSE; 22c3cc0c492381c803955a9e2480f74b echo x - opencryptoki/files/pkcsslotd.in sed 's/^X//' >opencryptoki/files/pkcsslotd.in << '1f11ad2bb42314f125197258d0cc9de3' X#!/bin/sh X X# $FreeBSD$ X# X# PROVIDE: pkcsslotd X# REQUIRE: LOGIN tcsd X# KEYWORD: shutdown X# X# Add the following lines to /etc/rc.conf.local or /etc/rc.conf X# to enable this service: X# X# pkcsslotd_enable (bool): Set to NO by default. X# Set it to YES to enable pkcsslotd. X# X X. /etc/rc.subr X Xname=pkcsslotd Xrcvar=`set_rcvar` Xcommand=%%PREFIX%%/sbin/${name} Xstart_precmd=${name}_prestart X Xpkcsslotd_prestart () { X [ -f %%PREFIX%%/var/lib/opencryptoki/pk_config_data ] || \ X %%PREFIX%%/sbin/pkcs11_startup X} X Xload_rc_config ${name} X X: pkcsslotd_enable=${pkcsslotd_enable-"NO"} X Xrun_rc_command "$1" X 1f11ad2bb42314f125197258d0cc9de3 echo x - opencryptoki/files/pkg-install.in sed 's/^X//' >opencryptoki/files/pkg-install.in << '30f4da3abe0ccab7d7e530e7f8a9d413' X#!/bin/sh X XPATH=/bin:/usr/sbin X XPREFIX=${PKG_PREFIX:-%%PREFIX%%} XUSER=%%PKCS11_USER%% XGROUP=%%PKCS11_GROUP%% XUID=%%PKCS11_UID%% XGID=%%PKCS11_GID%% X Xcase $2 in X PRE-INSTALL) X X if pw group show "${GROUP}" 2>/dev/null; then X echo "You already have a group \"${GROUP}\", so I will use it." X else X if pw groupadd ${GROUP} -g ${GID}; then X echo "Added group \"${GROUP}\"." X else X echo "Adding group \"${GROUP}\" failed..." X fi X fi X X if pw user show "${USER}" 2>/dev/null; then X echo "You already have a user \"${USER}\", so I will use it." X else X if pw useradd ${USER} -u ${UID} -g ${GROUP} -h - \ X -s /usr/sbin/nologin -L daemon -d /var/empty -c "opencryptoki user" X then X echo "Added user \"${USER}\"." X else X echo "Adding user \"${USER}\" failed..." X exit 1 X fi X fi X X if pw groupmod ${GROUP} -m ${USER}; then X echo "Added user \"${USER}\" to group \"${GROUP}\"." X else X echo "Adding user \"${USER}\" to group \"${GROUP}\" failed..." X fi X X ;; X X X DEINSTALL) X X# rm -rf ${PKG_PREFIX}/var/lib/opencryptoki/* X# rm -f ${PKG_PREFIX}/var/lib/opencryptoki/.slotpid X X ;; X X POST-DEINSTALL) X X# if pw user show "${USER}" 2>/dev/null; then X# if pw userdel ${USER} -u ${UID}; then X# echo "Deleted user \"${USER}\"." X# fi X# fi X X# if pw group show "${GROUP}" 2>/dev/null; then X# if pw groupdel ${GROUP} -g ${GID}; then X# echo "Deleted group \"${GROUP}\"." X# fi X# fi X X ;; Xesac 30f4da3abe0ccab7d7e530e7f8a9d413 echo x - opencryptoki/files/pkg-message.in sed 's/^X//' >opencryptoki/files/pkg-message.in << 'e78db1fca7ce94405657b3a3ec855f74' XTo run pkcsslotd automatically add the following line to /etc/rc.conf X Xpkcsslotd_enable="YES" X e78db1fca7ce94405657b3a3ec855f74 echo x - opencryptoki/pkg-descr sed 's/^X//' >opencryptoki/pkg-descr << '3f96db8570c34fc8c749f3067c73f2c3' XopenCryptoki is a PKCS#11 implementation. 3f96db8570c34fc8c749f3067c73f2c3 echo x - opencryptoki/pkg-plist sed 's/^X//' >opencryptoki/pkg-plist << 'be37b4b35c3978156f8b74f96105f5c5' Xinclude/opencryptoki/apiclient.h Xinclude/opencryptoki/pkcs11.h Xinclude/opencryptoki/pkcs11types.h Xlib/libopencryptoki.la Xlib/libopencryptoki.so Xlib/libopencryptoki.so.0 Xlib/opencryptoki/PKCS11_API.so Xlib/opencryptoki/libopencryptoki.la Xlib/opencryptoki/libopencryptoki.so Xlib/opencryptoki/libopencryptoki.so.0 Xlib/opencryptoki/methods Xlib/opencryptoki/stdll/PKCS11_SW.so Xlib/opencryptoki/stdll/libpkcs11_sw.la Xlib/opencryptoki/stdll/libpkcs11_sw.so Xlib/opencryptoki/stdll/libpkcs11_sw.so.0 Xlib/opencryptoki/stdll/PKCS11_TPM.so Xlib/opencryptoki/stdll/libpkcs11_tpm.la Xlib/opencryptoki/stdll/libpkcs11_tpm.so Xlib/opencryptoki/stdll/libpkcs11_tpm.so.0 Xlib/pkcs11/PKCS11_API.so Xlib/pkcs11/libopencryptoki.so Xlib/pkcs11/methods Xlib/pkcs11/stdll Xsbin/pkcs11_startup Xsbin/pkcs_slot Xsbin/pkcsconf Xsbin/pkcsslotd X@dirrmtry var/lib/opencryptoki X@dirrmtry var/lib X@dirrmtry var X@dirrm lib/pkcs11 X@dirrm lib/opencryptoki/stdll X@dirrm lib/opencryptoki X@dirrm include/opencryptoki be37b4b35c3978156f8b74f96105f5c5 exit --Multipart=_Thu__28_Oct_2010_02_43_40_+0900_JtScQ_e/yKAD9/CK Content-Type: text/plain; name="tpm-tools.shar" Content-Disposition: attachment; filename="tpm-tools.shar" Content-Transfer-Encoding: 7bit # This is a shell archive. Save it in a file, remove anything before # this line, and then unpack it by entering "sh file". Note, it may # create directories; files and directories will be owned by you and # have default permissions. # # This archive contains: # # tpm-tools # tpm-tools/Makefile # tpm-tools/distinfo # tpm-tools/files # tpm-tools/files/patch-lib-tpm_utils.c # tpm-tools/files/patch-src-cmds-Makefile.am # tpm-tools/files/patch-src-cmds-Makefile.in # tpm-tools/files/patch-src-tpm_mgmt-tpm_present.c # tpm-tools/pkg-descr # tpm-tools/pkg-plist # echo c - tpm-tools mkdir -p tpm-tools > /dev/null 2>&1 echo x - tpm-tools/Makefile sed 's/^X//' >tpm-tools/Makefile << 'e616569e13415541b00ced234ba46e9a' X# New ports collection makefile for: tpm-tools X# Date created: 18 Sep 2007 X# Whom: Sebastian Schuetz X# X# $FreeBSD$ X# X XPORTNAME= tpm-tools XPORTVERSION= 1.3.5 XCATEGORIES= security XMASTER_SITES= SF/trousers/${PORTNAME}/${PORTVERSION} X XMAINTAINER= nork@freebsd.org XCOMMENT= Provides a basic set of TPM tools X XLIB_DEPENDS= tspi.2:${PORTSDIR}/security/trousers XBUILD_DEPENDS= pkcsconf:${PORTSDIR}/security/opencryptoki XRUN_DEPENDS= ${LOCALBASE}/sbin/tcsd:${PORTSDIR}/security/trousers XRUN_DEPENDS+= ${LOCALBASE}/lib/pkcs11/libopencryptoki.so:${PORTSDIR}/security/opencryptoki X XUSE_GMAKE= YES XUSE_GETTEXT= YES XUSE_LDCONFIG= YES XUSE_AUTOTOOLS= autoconf:268 XGNU_CONFIGURE= YES XCONFIGURE_ENV+= LDFLAGS="-L${LOCALBASE}/lib -lintl -liconv" XMAKE_JOBS_SAFE= YES X X.include e616569e13415541b00ced234ba46e9a echo x - tpm-tools/distinfo sed 's/^X//' >tpm-tools/distinfo << '5be4d99d59b3e97ccab7b89908cb03db' XMD5 (tpm-tools-1.3.5.tar.gz) = b64baa248cf30a57ad0e5fb6f096e7dc XSHA256 (tpm-tools-1.3.5.tar.gz) = 60717336302bffff5044ed945a79f07594962fa3b989cf37f6eb042874d8fc45 XSIZE (tpm-tools-1.3.5.tar.gz) = 439922 5be4d99d59b3e97ccab7b89908cb03db echo c - tpm-tools/files mkdir -p tpm-tools/files > /dev/null 2>&1 echo x - tpm-tools/files/patch-lib-tpm_utils.c sed 's/^X//' >tpm-tools/files/patch-lib-tpm_utils.c << '382e2c559dcfb1aa9ef3febed4781190' X--- lib/tpm_utils.c.orig 2010-02-02 02:17:23.000000000 +0900 X+++ lib/tpm_utils.c 2010-10-25 01:55:31.065559348 +0900 X@@ -55,6 +55,7 @@ X CmdHelpFunction tCmdHelp = ( a_tCmdHelpFunction ) ? a_tCmdHelpFunction X : logCmdHelp; X X+#ifdef __GCC X char szShortOpts[strlen( pszGenShortOpts ) X + ( ( a_pszShortOpts == NULL ) ? 0 : strlen( a_pszShortOpts ) ) X + 1]; X@@ -64,6 +65,26 @@ X X int iOpt; X int rc; X+#else X+ int iOpt; X+ int rc; X+ X+ char *szShortOpts; X+ int iNumShortOpts, iNumGenLongOpts; X+ struct option *sLongOpts; X+ X+ iNumShortOpts = strlen( pszGenShortOpts ) + X+ ( ( a_pszShortOpts == NULL ) ? 0 : strlen( a_pszShortOpts ) ); X+ iNumGenLongOpts = sizeof( sGenLongOpts ) / sizeof( struct option ); X+ X+ szShortOpts = malloc(iNumShortOpts + 1); X+ sLongOpts = malloc((iNumGenLongOpts + a_iNumOpts + 1) X+ * sizeof(struct option)); X+ if( (szShortOpts == NULL) || (sLongOpts == NULL) ) { X+ perror("malloc"); X+ return -1; X+ } X+#endif X X strcpy( szShortOpts, pszGenShortOpts); X if ( a_pszShortOpts ) 382e2c559dcfb1aa9ef3febed4781190 echo x - tpm-tools/files/patch-src-cmds-Makefile.am sed 's/^X//' >tpm-tools/files/patch-src-cmds-Makefile.am << '7fcd9b82bdd922713fbb782067ba3236' X--- src/cmds/Makefile.am.orig 2010-02-02 02:17:23.000000000 +0900 X+++ src/cmds/Makefile.am 2010-10-25 01:55:31.067559744 +0900 X@@ -30,7 +30,7 @@ X AM_CPPFLAGS = -I$(top_srcdir)/include -D_LINUX X endif X X-LDADD = $(top_builddir)/lib/libtpm_tspi.la -ltspi $(top_builddir)/lib/libtpm_unseal.la -ltpm_unseal X+LDADD = $(top_builddir)/lib/libtpm_tspi.la -ltspi $(top_builddir)/lib/libtpm_unseal.la X X tpm_sealdata_SOURCES = tpm_sealdata.c X tpm_unsealdata_SOURCES = tpm_unsealdata.c 7fcd9b82bdd922713fbb782067ba3236 echo x - tpm-tools/files/patch-src-cmds-Makefile.in sed 's/^X//' >tpm-tools/files/patch-src-cmds-Makefile.in << 'e49f990f4a699cbddd4cfd2d06d85fd0' X--- src/cmds/Makefile.in.orig 2010-02-02 05:59:31.000000000 +0900 X+++ src/cmds/Makefile.in 2010-10-25 01:55:31.069555531 +0900 X@@ -242,7 +242,7 @@ X top_srcdir = @top_srcdir@ X @TSS_LIB_IS_12_FALSE@AM_CPPFLAGS = -I$(top_srcdir)/include -D_LINUX X @TSS_LIB_IS_12_TRUE@AM_CPPFLAGS = -I$(top_srcdir)/include -D_LINUX -DTSS_LIB_IS_12 X-LDADD = $(top_builddir)/lib/libtpm_tspi.la -ltspi $(top_builddir)/lib/libtpm_unseal.la -ltpm_unseal X+LDADD = $(top_builddir)/lib/libtpm_tspi.la -ltspi $(top_builddir)/lib/libtpm_unseal.la X tpm_sealdata_SOURCES = tpm_sealdata.c X tpm_unsealdata_SOURCES = tpm_unsealdata.c X all: all-am e49f990f4a699cbddd4cfd2d06d85fd0 echo x - tpm-tools/files/patch-src-tpm_mgmt-tpm_present.c sed 's/^X//' >tpm-tools/files/patch-src-tpm_mgmt-tpm_present.c << '26c32265380323ccda4b4848e7e65183' X--- src/tpm_mgmt/tpm_present.c.orig 2009-08-20 23:46:31.000000000 +0900 X+++ src/tpm_mgmt/tpm_present.c 2010-10-25 01:55:31.071556276 +0900 X@@ -168,7 +168,7 @@ X TSS_HPOLICY hTpmPolicy; X char *pwd = NULL; X int pswd_len; X- char rsp[5]; X+ char rsp[6]; X int scanCount; X X //get status w/o owner auth (FAILS 1.1, should PASS 1.2) 26c32265380323ccda4b4848e7e65183 echo x - tpm-tools/pkg-descr sed 's/^X//' >tpm-tools/pkg-descr << '449287a8e37a8c5d061423b998fd09ff' Xtpm-tools package provides a basic TPM management suite. 449287a8e37a8c5d061423b998fd09ff echo x - tpm-tools/pkg-plist sed 's/^X//' >tpm-tools/pkg-plist << '2af157faaa2d37cac091513593fd18f2' Xbin/tpm_sealdata Xbin/tpm_unsealdata Xbin/tpmtoken_import Xbin/tpmtoken_init Xbin/tpmtoken_objects Xbin/tpmtoken_protect Xbin/tpmtoken_setpasswd Xinclude/tpm_tools/tpm_unseal.h Xlib/libtpm_unseal.la Xlib/libtpm_unseal.so Xlib/libtpm_unseal.so.1 Xman/man1/tpm_sealdata.1 Xman/man1/tpm_version.1 Xman/man1/tpmtoken_import.1 Xman/man1/tpmtoken_init.1 Xman/man1/tpmtoken_objects.1 Xman/man1/tpmtoken_protect.1 Xman/man1/tpmtoken_setpasswd.1 Xman/man3/tpmUnsealFile.3 Xman/man3/tpmUnsealShred.3 Xman/man3/tpmUnsealStrerror.3 Xman/man8/tpm_changeownerauth.8 Xman/man8/tpm_clear.8 Xman/man8/tpm_createek.8 Xman/man8/tpm_getpubek.8 Xman/man8/tpm_resetdalock.8 Xman/man8/tpm_restrictpubek.8 Xman/man8/tpm_revokeek.8 Xman/man8/tpm_selftest.8 Xman/man8/tpm_setactive.8 Xman/man8/tpm_setclearable.8 Xman/man8/tpm_setenable.8 Xman/man8/tpm_setoperatorauth.8 Xman/man8/tpm_setownable.8 Xman/man8/tpm_setpresence.8 Xman/man8/tpm_takeownership.8 Xsbin/tpm_changeownerauth Xsbin/tpm_clear Xsbin/tpm_createek Xsbin/tpm_getpubek Xsbin/tpm_resetdalock Xsbin/tpm_restrictpubek Xsbin/tpm_restrictsrk Xsbin/tpm_revokeek Xsbin/tpm_selftest Xsbin/tpm_setactive Xsbin/tpm_setclearable Xsbin/tpm_setenable Xsbin/tpm_setoperatorauth Xsbin/tpm_setownable Xsbin/tpm_setpresence Xsbin/tpm_takeownership Xsbin/tpm_version X@dirrm include/tpm_tools 2af157faaa2d37cac091513593fd18f2 exit --Multipart=_Thu__28_Oct_2010_02_43_40_+0900_JtScQ_e/yKAD9/CK Content-Type: text/plain; name="tpm-emulator.shar" Content-Disposition: attachment; filename="tpm-emulator.shar" Content-Transfer-Encoding: 7bit # This is a shell archive. Save it in a file, remove anything before # this line, and then unpack it by entering "sh file". Note, it may # create directories; files and directories will be owned by you and # have default permissions. # # This archive contains: # # tpm-emulator # tpm-emulator/Makefile # tpm-emulator/distinfo # tpm-emulator/files # tpm-emulator/files/patch-CMakeLists.txt # tpm-emulator/files/patch-mtm-mtm_structures.h # tpm-emulator/files/patch-tddl-CMakeLists.txt # tpm-emulator/files/patch-tpm-tpm_ticks.c # tpm-emulator/files/patch-tpmd-CMakeLists.txt # tpm-emulator/files/patch-tpmd-unix-CMakeLists.txt # tpm-emulator/files/patch-tpmd_dev-CMakeLists.txt # tpm-emulator/files/patch-tpmd_dev-openbsd-Makefile # tpm-emulator/files/patch-tpmd_dev-openbsd-tpmd_dev.c # tpm-emulator/files/patch-tpmd_dev-openbsd-tpmd_dev.h # tpm-emulator/files/pkg-install.in # tpm-emulator/pkg-descr # tpm-emulator/pkg-plist # echo c - tpm-emulator mkdir -p tpm-emulator > /dev/null 2>&1 echo x - tpm-emulator/Makefile sed 's/^X//' >tpm-emulator/Makefile << '77e8d7f016b1d8fccb95ce1b1166c793' X# New ports collection makefile for: tpm-emulator X# Date created: 18 Sep 2007 X# Whom: Sebastian Schuetz X# X# $FreeBSD$ X# X XPORTNAME= tpm-emulator XPORTVERSION= 0.7.1 XCATEGORIES= emulators XMASTER_SITES= BERLIOS/${PORTNAME} XDISTNAME= ${PORTNAME:S/-/_/}-${PORTVERSION} X XMAINTAINER= nork@freebsd.org XCOMMENT= Trusted Platform Module (TPM) emulator X XLIB_DEPENDS= gmp.10:${PORTSDIR}/math/gmp X XUSE_CMAKE= YES XUSE_LDCONFIG= YES X#USE_AUTOTOOLS= libtool:22 X XCONFLICTS= trousers-tddl* X XWANTLIB+= c XCMAKE_VERBOSE= YES XCMAKE_SOURCE_PATH= ${WRKSRC} XNO_CONFIGURE= YES XBUILD_WRKSRC= ${CONFIGURE_WRKSRC} XINSTALL_WRKSRC= ${CONFIGURE_WRKSRC} XCONFIGURE_WRKSRC= ${CMAKE_SOURCE_PATH}/build X XCMAKE_ARGS+= -DCMAKE_INCLUDE_PATH="${LOCALBASE}/include" \ X -DCMAKE_EXE_LINKER_FLAGS="-L${LOCALBASE}/lib" X XSUB_FILES= pkg-install XSUB_LIST= TSS_USER=${TSS_USER} TSS_UID=${TSS_UID} \ X TSS_GROUP=${TSS_GROUP} TSS_GID=${TSS_GID} XPKGINSTALL= ${WRKDIR}/pkg-install X XTSS_USER= _tss XTSS_GROUP= _tss XTSS_UID= 601 XTSS_GID= 601 X XWRKSRC= ${WRKDIR}/${PORTNAME:S/-/_/}-${PORTVERSION} X Xpost-patch: X @${MKDIR} ${WRKSRC}/build X Xpre-install: X @${SETENV} PKG_PREFIX=${PREFIX} ${SH} ${PKGINSTALL} ${PKGNAME} PRE-INSTALL X X.include 77e8d7f016b1d8fccb95ce1b1166c793 echo x - tpm-emulator/distinfo sed 's/^X//' >tpm-emulator/distinfo << 'd373adfa96e33606f6c96255c8a6ba49' XMD5 (tpm_emulator-0.7.1.tar.gz) = ada4af190af2e4bd9da4469f72459d34 XSHA256 (tpm_emulator-0.7.1.tar.gz) = 7c10a753206bf0f32a767dc69039a866bd8d3eb8a4834f5e722c7510a9f54c24 XSIZE (tpm_emulator-0.7.1.tar.gz) = 207497 d373adfa96e33606f6c96255c8a6ba49 echo c - tpm-emulator/files mkdir -p tpm-emulator/files > /dev/null 2>&1 echo x - tpm-emulator/files/patch-CMakeLists.txt sed 's/^X//' >tpm-emulator/files/patch-CMakeLists.txt << '873e4acb22dce03bed901917a5f14b77' X--- CMakeLists.txt.orig 2010-07-06 06:21:20.000000000 +0900 X+++ CMakeLists.txt 2010-10-25 02:56:43.617558705 +0900 X@@ -5,13 +5,13 @@ X X project(TPM_Emulator C) X X-cmake_minimum_required(VERSION 2.6) X+cmake_minimum_required(VERSION 2.4) X X # enforce out of source build X string(COMPARE EQUAL "${CMAKE_SOURCE_DIR}" "${CMAKE_BINARY_DIR}" IS_INSOURCE) X if(IS_INSOURCE) X message(FATAL_ERROR "${PROJECT_NAME} requires an out of source build.") X-endif() X+endif(IS_INSOURCE) X X # set project and build version X set(${PROJECT_NAME}_VERSION_MAJOR 0) X@@ -29,14 +29,14 @@ X set(TPM_SOCKET_NAME "/private/var/run/tpm/tpmd_socket:0") X set(TPM_STORAGE_NAME "/private/var/lib/tpm/tpm_emulator-1_2_${${PROJECT_NAME}_VERSION_MAJOR}_${${PROJECT_NAME}_VERSION_MINOR}") X set(TPM_DEVICE_NAME "/dev/tpm") X-else() X+else(WIN32) X set(TPM_LOG_FILE "/var/log/tpmd.log") X set(TPM_SOCKET_NAME "/var/run/tpm/tpmd_socket:0") X set(TPM_STORAGE_NAME "/var/lib/tpm/tpm_emulator-1_2_${${PROJECT_NAME}_VERSION_MAJOR}_${${PROJECT_NAME}_VERSION_MINOR}") X set(TPM_DEVICE_NAME "/dev/tpm") X-endif() X+endif(WIN32) X configure_file(${CMAKE_CURRENT_SOURCE_DIR}/config.h.in ${CMAKE_CURRENT_BINARY_DIR}/config.h) X-add_definitions(-Wall -Werror -Wextra -Wno-unused-parameter -Wpointer-arith -Wcast-align -Wwrite-strings) X+add_definitions(-Wall -Werror -Wno-unused-parameter -Wpointer-arith -Wcast-align -Wwrite-strings) X X # configure CPack X set(CPACK_PACKAGE_VERSION_MAJOR ${${PROJECT_NAME}_VERSION_MAJOR}) X@@ -51,6 +51,7 @@ X # include root directories X include_directories(${CMAKE_SOURCE_DIR}) X include_directories(${CMAKE_BINARY_DIR}) X+include_directories("/usr/local/include") X X # add internal libraries X add_subdirectory(tpm) 873e4acb22dce03bed901917a5f14b77 echo x - tpm-emulator/files/patch-mtm-mtm_structures.h sed 's/^X//' >tpm-emulator/files/patch-mtm-mtm_structures.h << '643c39a73d9e4fd081dd6ea123fb9422' X--- mtm/mtm_structures.h.orig 2010-07-06 06:21:20.000000000 +0900 X+++ mtm/mtm_structures.h 2010-10-25 02:56:43.619561686 +0900 X@@ -228,8 +228,6 @@ X MTM_PERMANENT_DATA data; X } permanent; X struct { X- } stclear; X- struct { X MTM_STANY_FLAGS flags; X } stany; X } MTM_DATA; 643c39a73d9e4fd081dd6ea123fb9422 echo x - tpm-emulator/files/patch-tddl-CMakeLists.txt sed 's/^X//' >tpm-emulator/files/patch-tddl-CMakeLists.txt << '946b8c2206569c17f1b5906d910b23d7' X--- tddl/CMakeLists.txt.orig 2010-07-06 06:21:20.000000000 +0900 X+++ tddl/CMakeLists.txt 2010-10-25 02:56:43.620555878 +0900 X@@ -5,18 +5,21 @@ X X set(tddl_SRCS "tddl.c" "tddl.h") X add_library(tddl SHARED ${tddl_SRCS}) X+add_library(tddlStatic STATIC ${tddl_SRCS}) X if(UNIX) X set_target_properties(tddl PROPERTIES SOVERSION "1.2" X VERSION "1.2.${${PROJECT_NAME}_VERSION_MAJOR}.${${PROJECT_NAME}_VERSION_MINOR}") X+ set_target_properties(tddlStatic PROPERTIES OUTPUT_NAME tddl) X elseif(WIN32) X set_target_properties(tddl PROPERTIES OUTPUT_NAME ifxtpm) X set_target_properties(tddl PROPERTIES PREFIX "") X-endif() X+endif(UNIX) X X install(TARGETS tddl DESTINATION lib) X+install(TARGETS tddlStatic DESTINATION lib) X install(FILES "tddl.h" DESTINATION include) X X include_directories(${CMAKE_CURRENT_SOURCE_DIR}) X add_executable(test_tddl test_tddl.c) X-target_link_libraries(test_tddl tddl) X+target_link_libraries(test_tddl tddlStatic) X 946b8c2206569c17f1b5906d910b23d7 echo x - tpm-emulator/files/patch-tpm-tpm_ticks.c sed 's/^X//' >tpm-emulator/files/patch-tpm-tpm_ticks.c << 'ed5eef403d205e08ab4eab3dac4a9380' X--- tpm/tpm_ticks.c.orig 2010-07-06 06:21:20.000000000 +0900 X+++ tpm/tpm_ticks.c 2010-10-25 02:56:43.622559766 +0900 X@@ -42,7 +42,7 @@ X { X TPM_RESULT res; X TPM_KEY_DATA *key; X- BYTE *info, *ptr; X+ BYTE *info_buffer, *ptr; X UINT32 info_length, len; X info("TPM_TickStampBlob()"); X /* get key */ X@@ -66,21 +66,21 @@ X if (*sig == NULL) return TPM_FAIL; X /* setup TPM_SIGN_INFO structure */ X info_length = 30 + sizeof(TPM_DIGEST) + sizeof_TPM_CURRENT_TICKS(currentTicks); X- info = tpm_malloc(info_length); X- if (info == NULL) { X+ info_buffer = tpm_malloc(info_length); X+ if (info_buffer == NULL) { X tpm_free(*sig); X return TPM_FAIL; X } X- memcpy(&info[0], "\x00\x05TSTP", 6); X- memcpy(&info[6], antiReplay->nonce, 20); X- ptr = &info[26]; len = info_length - 26; X+ memcpy(&info_buffer[0], "\x00\x05TSTP", 6); X+ memcpy(&info_buffer[6], antiReplay->nonce, 20); X+ ptr = &info_buffer[26]; len = info_length - 26; X tpm_marshal_UINT32(&ptr, &len, info_length - 30); X memcpy(ptr, digestToStamp->digest, sizeof(TPM_DIGEST)); X ptr += sizeof(TPM_DIGEST); len -= sizeof(TPM_DIGEST); X if (tpm_marshal_TPM_CURRENT_TICKS(&ptr, &len, currentTicks) X- || tpm_rsa_sign(&key->key, RSA_SSA_PKCS1_SHA1, info, info_length, *sig)) { X+ || tpm_rsa_sign(&key->key, RSA_SSA_PKCS1_SHA1, info_buffer, info_length, *sig)) { X tpm_free(*sig); X- tpm_free(info); X+ tpm_free(info_buffer); X return TPM_FAIL; X } X return TPM_SUCCESS; ed5eef403d205e08ab4eab3dac4a9380 echo x - tpm-emulator/files/patch-tpmd-CMakeLists.txt sed 's/^X//' >tpm-emulator/files/patch-tpmd-CMakeLists.txt << 'f452f31d62e4ee1075ceb07e6345caad' X--- tpmd/CMakeLists.txt.orig 2010-07-06 06:21:20.000000000 +0900 X+++ tpmd/CMakeLists.txt 2010-10-25 02:56:43.624559116 +0900 X@@ -11,5 +11,5 @@ X X add_subdirectory(windows) X X-endif() X+endif(UNIX) X f452f31d62e4ee1075ceb07e6345caad echo x - tpm-emulator/files/patch-tpmd-unix-CMakeLists.txt sed 's/^X//' >tpm-emulator/files/patch-tpmd-unix-CMakeLists.txt << '12f93ef13f089c880896ef8034b05bef' X--- tpmd/unix/CMakeLists.txt.orig 2010-07-06 06:21:20.000000000 +0900 X+++ tpmd/unix/CMakeLists.txt 2010-10-25 02:56:43.633558246 +0900 X@@ -10,8 +10,8 @@ X if(MTM_EMULATOR) X add_definitions(-DMTM_EMULATOR) X target_link_libraries(tpmd mtm tpm crypto) X-else() X+else(MTM_EMULATOR) X target_link_libraries(tpmd tpm crypto) X-endif() X+endif(MTM_EMULATOR) X install(TARGETS tpmd RUNTIME DESTINATION bin) X 12f93ef13f089c880896ef8034b05bef echo x - tpm-emulator/files/patch-tpmd_dev-CMakeLists.txt sed 's/^X//' >tpm-emulator/files/patch-tpmd_dev-CMakeLists.txt << '7ad97596d776d088f7580ee3acf82b1a' X--- tpmd_dev/CMakeLists.txt.orig 2010-07-06 06:21:20.000000000 +0900 X+++ tpmd_dev/CMakeLists.txt 2010-10-25 02:56:43.626557976 +0900 X@@ -17,8 +17,8 @@ X set(tpmd_dev_SOURCE_DIR "${CMAKE_CURRENT_SOURCE_DIR}/openbsd") X set(tpmd_dev_BINARY_DIR "${CMAKE_CURRENT_BINARY_DIR}/openbsd") X set(tpmd_dev_OBJ "${tpmd_dev_BINARY_DIR}/tpmd_dev.o") X-set(tpmd_dev_BUILD_CMD make -C ${tpmd_dev_BINARY_DIR}) X-set(tpmd_dev_INSTALL_CMD make -C ${tpmd_dev_BINARY_DIR} install) X+set(tpmd_dev_BUILD_CMD gmake -C ${tpmd_dev_BINARY_DIR}) X+set(tpmd_dev_INSTALL_CMD gmake -C ${tpmd_dev_BINARY_DIR} install) X X elseif(CMAKE_SYSTEM_NAME STREQUAL "Darwin") X X@@ -28,7 +28,7 @@ X set(tpmd_dev_BUILD_CMD make -C ${tpmd_dev_BINARY_DIR}) X set(tpmd_dev_INSTALL_CMD make -C ${tpmd_dev_BINARY_DIR} install) X X-endif() X+endif(CMAKE_SYSTEM_NAME STREQUAL "Linux") X X # compile module X if(tpmd_dev_OBJ) X@@ -45,5 +45,5 @@ X X install(CODE "EXECUTE_PROCESS(COMMAND ${tpmd_dev_INSTALL_CMD})") X X-endif() X+endif(tpmd_dev_OBJ) X 7ad97596d776d088f7580ee3acf82b1a echo x - tpm-emulator/files/patch-tpmd_dev-openbsd-Makefile sed 's/^X//' >tpm-emulator/files/patch-tpmd_dev-openbsd-Makefile << '9f421f1851467b5331355b2330f1f32f' X--- tpmd_dev/openbsd/Makefile.orig 2010-07-06 06:21:20.000000000 +0900 X+++ tpmd_dev/openbsd/Makefile 2010-10-25 02:56:43.628559140 +0900 X@@ -6,14 +6,15 @@ X X CFLAGS= -D_KERNEL -I/usr/src/sys X SRC= tpmd_dev.c X+OBJ= tpmd_dev.obj X MODULE= tpmd_dev.o X X all: X- cc -c $(SRC) $(CFLAGS) X- ld -r -o $(MODULE) $(SRC:.c=.o) X+ cc -o $(OBJ) -c $(SRC) $(CFLAGS) X+ ld -r -o $(MODULE) $(OBJ) X X clean: X- rm -rf $(SRC:.c=.o) X+ rm -rf $(OBJ) X rm -f $(MODULE) X X load: all mknod X@@ -27,3 +28,6 @@ X X rmnod: X rm /dev/tpm X+ X+install: X+ 9f421f1851467b5331355b2330f1f32f echo x - tpm-emulator/files/patch-tpmd_dev-openbsd-tpmd_dev.c sed 's/^X//' >tpm-emulator/files/patch-tpmd_dev-openbsd-tpmd_dev.c << '2bce3479c0b6bc088ca782fc2a955038' X--- tpmd_dev/openbsd/tpmd_dev.c.orig 2010-07-06 06:21:20.000000000 +0900 X+++ tpmd_dev/openbsd/tpmd_dev.c 2010-10-25 02:56:43.630557372 +0900 X@@ -32,7 +32,7 @@ X #include X #include X X-#include "tpm_dev.h" X+#include "tpmd_dev.h" X X X int tpmopen __P((dev_t dev, int oflags, int devtype, struct proc *p)); X@@ -57,7 +57,7 @@ X cdev_decl(tpm); X X /* define our cdev struct containing the functions */ X-static struct cdevsw cdev_tpm = cdev_tpm_init(1,tpm); X+static struct cdevsw cdev_tpm = cdev_tpmd_init(1,tpm); X X /* fill in the lkm_dev structure */ X MOD_DEV("tpm",LM_DT_CHAR,-1,&cdev_tpm); X@@ -213,7 +213,7 @@ X * sometime returns EINTR X */ X tpmd_sock->so_rcv.sb_flags |= SB_NOINTR; X- error = soreceive(tpmd_sock,NULL,uio,NULL,NULL,NULL); X+ error = soreceive(tpmd_sock,NULL,uio,NULL,NULL,NULL,0); X X if (error) { X debug("soreceive() failed %i",error); 2bce3479c0b6bc088ca782fc2a955038 echo x - tpm-emulator/files/patch-tpmd_dev-openbsd-tpmd_dev.h sed 's/^X//' >tpm-emulator/files/patch-tpmd_dev-openbsd-tpmd_dev.h << 'f6b99e1a81f107eae3f2eb7220549964' X--- tpmd_dev/openbsd/tpmd_dev.h.orig 2010-07-06 06:21:20.000000000 +0900 X+++ tpmd_dev/openbsd/tpmd_dev.h 2010-10-25 02:56:43.632557559 +0900 X@@ -20,7 +20,7 @@ X X #include "config.h" X X-#define cdev_tpm_init(c,n) { \ X+#define cdev_tpmd_init(c,n) { \ X dev_init(c,n,open),dev_init(c,n,close),dev_init(c,n,read), \ X dev_init(c,n,write), dev_init(c,n,ioctl),(dev_type_stop((*))) lkmenodev, \ X 0,(dev_type_poll((*))) lkmenodev,(dev_type_mmap((*))) lkmenodev } f6b99e1a81f107eae3f2eb7220549964 echo x - tpm-emulator/files/pkg-install.in sed 's/^X//' >tpm-emulator/files/pkg-install.in << '1b9371219f217e714ca8bcbd5465efbf' X#!/bin/sh X XPATH=/bin:/usr/sbin X XPREFIX=${PKG_PREFIX:-%%PREFIX%%} XUSER=%%TSS_USER%% XGROUP=%%TSS_GROUP%% XUID=%%TSS_UID%% XGID=%%TSS_GID%% X Xcase $2 in X PRE-INSTALL) X X if pw group show "${GROUP}" 2>/dev/null; then X echo "You already have a group \"${GROUP}\", so I will use it." X else X if pw groupadd ${GROUP} -g ${GID}; then X echo "Added group \"${GROUP}\"." X else X echo "Adding group \"${GROUP}\" failed..." X fi X fi X X if pw user show "${USER}" 2>/dev/null; then X echo "You already have a user \"${USER}\", so I will use it." X else X if pw useradd ${USER} -u ${UID} -g ${GROUP} -h - \ X -s /usr/sbin/nologin -L daemon -d /var/empty -c "TrouSerS user" X then X echo "Added user \"${USER}\"." X else X echo "Adding user \"${USER}\" failed..." X exit 1 X fi X fi X X if pw groupmod ${GROUP} -m ${USER}; then X echo "Added user \"${USER}\" to group \"${GROUP}\"." X else X echo "Adding user \"${USER}\" to group \"${GROUP}\" failed..." X fi X X ;; X X POST-DEINSTALL) X X# if pw user show "${USER}" 2>/dev/null; then X# if pw userdel ${USER} -u ${UID}; then X# echo "Deleted user \"${USER}\"." X# fi X# fi X X# if pw group show "${GROUP}" 2>/dev/null; then X# if pw groupdel ${GROUP} -g ${GID}; then X# echo "Deleted group \"${GROUP}\"." X# fi X# fi X X ;; X Xesac 1b9371219f217e714ca8bcbd5465efbf echo x - tpm-emulator/pkg-descr sed 's/^X//' >tpm-emulator/pkg-descr << '1caa38e70a34b545e2de6a85bf003cb0' XThe project aims to create a fully working Trusted Platform Module (TPM) Xemulator follwing the specifications of the Trusted Computing Group. XThe port provides a driver library libtddl which can be linked against programs Xproviding a Trusted Software Stack to redirect TPM calls to the emulator. 1caa38e70a34b545e2de6a85bf003cb0 echo x - tpm-emulator/pkg-plist sed 's/^X//' >tpm-emulator/pkg-plist << 'afb9f3e41cbb6fd2469711c7791b39df' Xinclude/tddl.h Xlib/libtddl.so.1.2.0.7 Xlib/libtddl.so.1.2 Xlib/libtddl.a Xbin/tpmd X@unexec rm -f /var/tpm/tpmd_socket* X@unexec rm -rf /var/tpm afb9f3e41cbb6fd2469711c7791b39df exit --Multipart=_Thu__28_Oct_2010_02_43_40_+0900_JtScQ_e/yKAD9/CK-- From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 27 18:17: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 EC2DA1065670 for ; Wed, 27 Oct 2010 18:17:09 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id AA1418FC08 for ; Wed, 27 Oct 2010 18:17:09 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id AD63B1FFC38; Wed, 27 Oct 2010 18:17:08 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id C7BD284507; Wed, 27 Oct 2010 20:17:06 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Peter Jeremy References: <4CC44E5B.9040902@infracaninophile.co.uk> <20101024152835.GA62748@muon.cran.org.uk> <19652.22833.731361.647776@y.dockes.com> <20101025093149.GA67314@server.vk2pj.dyndns.org> Date: Wed, 27 Oct 2010 20:17:06 +0200 In-Reply-To: <20101025093149.GA67314@server.vk2pj.dyndns.org> (Peter Jeremy's message of "Mon, 25 Oct 2010 20:31:49 +1100") Message-ID: <86y69jxzz1.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Jean-Francois Dockes , freebsd-hackers@freebsd.org Subject: Re: dump cache performance X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 18:17:10 -0000 Peter Jeremy writes: > I've mostly convered to ZFS but still have UFS root (which is basically > a full base install without /var but including /usr/src - 94k inodes > and 1.7GB). I've run both the 8-stable ("stable") and patched ("jfd") du= mp=20 > alternately 4 times with 50/250MB cache with the following results: > > x stable > + jfd > +------------------------------------------------------------+ > | +| > | +| > | x +| > |x xx +| > ||AM A| > +------------------------------------------------------------+ > N Min Max Median Avg Stdd= ev > x 4 9413 9673 9568 9555.5 107.121= 43 > + 4 15359 15359 15359 15359 = 0 9413 what? Puppies? DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 27 18:27: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 5D4F0106564A for ; Wed, 27 Oct 2010 18:27:52 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail13.syd.optusnet.com.au (mail13.syd.optusnet.com.au [211.29.132.194]) by mx1.freebsd.org (Postfix) with ESMTP id DBF2F8FC26 for ; Wed, 27 Oct 2010 18:27:51 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail13.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o9RIRdjR018648 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Oct 2010 05:27:41 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.4/8.14.4) with ESMTP id o9RIRbGi044832; Thu, 28 Oct 2010 05:27:37 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.4/8.14.4/Submit) id o9RIRbIq044831; Thu, 28 Oct 2010 05:27:37 +1100 (EST) (envelope-from peter) Date: Thu, 28 Oct 2010 05:27:37 +1100 From: Peter Jeremy To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= Message-ID: <20101027182737.GB78665@server.vk2pj.dyndns.org> References: <4CC44E5B.9040902@infracaninophile.co.uk> <20101024152835.GA62748@muon.cran.org.uk> <19652.22833.731361.647776@y.dockes.com> <20101025093149.GA67314@server.vk2pj.dyndns.org> <86y69jxzz1.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RASg3xLB4tUQ4RcS" Content-Disposition: inline In-Reply-To: <86y69jxzz1.fsf@ds4.des.no> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Jean-Francois Dockes , freebsd-hackers@freebsd.org Subject: Re: dump cache performance X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 18:27:52 -0000 --RASg3xLB4tUQ4RcS Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2010-Oct-27 20:17:06 +0200, Dag-Erling Sm=F8rgrav wrote: >Peter Jeremy writes: >> I've mostly convered to ZFS but still have UFS root (which is basically >> a full base install without /var but including /usr/src - 94k inodes >> and 1.7GB). I've run both the 8-stable ("stable") and patched ("jfd") d= ump=20 >> alternately 4 times with 50/250MB cache with the following results: >> >> x stable >> + jfd >> +------------------------------------------------------------+ >> | +| >> | +| >> | x +| >> |x xx +| >> ||AM A| >> +------------------------------------------------------------+ >> N Min Max Median Avg Std= dev >> x 4 9413 9673 9568 9555.5 107.12= 143 >> + 4 15359 15359 15359 15359 = 0 > >9413 what? Puppies? Ooops, sorry - KB/sec as reported in the dump summary. --=20 Peter Jeremy --RASg3xLB4tUQ4RcS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iEYEARECAAYFAkzIbxgACgkQ/opHv/APuIdLcwCeLl71MWUATT1vSEQEJ3mh6vcB wUIAnjidzWESTV0Yh/6HrpfAeL8UYDKu =BDpg -----END PGP SIGNATURE----- --RASg3xLB4tUQ4RcS-- From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 27 18:37:42 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 027961065673 for ; Wed, 27 Oct 2010 18:37:42 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id B383B8FC21 for ; Wed, 27 Oct 2010 18:37:41 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 970321FFC53; Wed, 27 Oct 2010 18:37:40 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 65AB184507; Wed, 27 Oct 2010 20:37:40 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Peter Jeremy References: <4CC44E5B.9040902@infracaninophile.co.uk> <20101024152835.GA62748@muon.cran.org.uk> <19652.22833.731361.647776@y.dockes.com> <20101025093149.GA67314@server.vk2pj.dyndns.org> <86y69jxzz1.fsf@ds4.des.no> <20101027182737.GB78665@server.vk2pj.dyndns.org> Date: Wed, 27 Oct 2010 20:37:40 +0200 In-Reply-To: <20101027182737.GB78665@server.vk2pj.dyndns.org> (Peter Jeremy's message of "Thu, 28 Oct 2010 05:27:37 +1100") Message-ID: <86lj5jxz0r.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Jean-Francois Dockes , freebsd-hackers@freebsd.org Subject: Re: dump cache performance X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 18:37:42 -0000 Peter Jeremy writes: > Dag-Erling Sm=C3=B8rgrav wrote: > > 9413 what? Puppies? > Ooops, sorry - KB/sec as reported in the dump summary. Thank you :) DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 27 19:43: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 3FACF1065673 for ; Wed, 27 Oct 2010 19:43:51 +0000 (UTC) (envelope-from drbaud@yahoo.com) Received: from web120719.mail.ne1.yahoo.com (web120719.mail.ne1.yahoo.com [98.138.83.126]) by mx1.freebsd.org (Postfix) with SMTP id E39118FC16 for ; Wed, 27 Oct 2010 19:43:50 +0000 (UTC) Received: (qmail 29536 invoked by uid 60001); 27 Oct 2010 19:17:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1288207030; bh=QG2xnxqtl3HUPQA+XF03weYjpIqtSv3CX8FylsMeGV4=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=koHme6v25Gmn9HXxefXVD7zm+abxR+PBruBLJWcsaY8b4spBBswCnI5IRf1itPbcf7DA+S/BTfKsjT4NKEWyddI4r0kXSRWlUj7haNhKDwYc19Fu590lHT1oIy1SnT+TUepG0MCyPgS52+W3yxu8/9DdUj792YT6JUzSrm86GOI= 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=D4ZHCJCcMGh5kg8Zx6wVjNEoQAah56zdASXhmxkzUBaNTGaFcONqiUY68oB0D4PR0nDCkxydjGY9VxQC9M+T8bhqtdDySE7t085sLRe9MweHNqRR9iXiwFO/A40exssYw02EtrPj8NOK6ZldMfsLmLotPXcL0f4q4kpz/KCRS3U=; Message-ID: <89857.29286.qm@web120719.mail.ne1.yahoo.com> X-YMail-OSG: XVsSWbAVM1lntr4qb.yTYuuyEQpUnCBXPunqzORd2ugJIrU gCWfohjI5vBaPCrsUoehco.26pE97JvSDBds7iYjP2uQsaECVpExahj.e7bb WFoWOGDxkjDk9H5NBtDCGi3h2jxu_TZHu8SoL0fZQZdp5Fz0m5jo7ilZ2wUW lFFQQ.4VAtZzWq9.mzmlLPyFvc6PmZAXERRWuac4HY0vpwj52YGwQSmoDr0V JtQrwDX9UciyB1y1Oifq9D7Ie.uPhCozX_7_yWCWY Received: from [64.238.244.146] by web120719.mail.ne1.yahoo.com via HTTP; Wed, 27 Oct 2010 12:17:10 PDT X-Mailer: YahooMailRC/504.5 YahooMailWebService/0.8.107.284920 Date: Wed, 27 Oct 2010 12:17:10 -0700 (PDT) From: "Dr. Baud" To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Wed, 27 Oct 2010 20:06:13 +0000 Subject: Contiguous physical memory X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 27 Oct 2010 19:43:51 -0000 Can anyone suggest a method/formula to monitor contiguous physical memory allocations such that one could predict when contigmalloc(), make that bus_dmamem_alloc might fail? Dr From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 27 20:46:35 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 C7B56106566B for ; Wed, 27 Oct 2010 20:46:35 +0000 (UTC) (envelope-from alan.l.cox@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 558AA8FC0C for ; Wed, 27 Oct 2010 20:46:34 +0000 (UTC) Received: by ewy28 with SMTP id 28so701326ewy.13 for ; Wed, 27 Oct 2010 13:46:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:cc :content-type; bh=QczVcChXWJmnKkHFJswmh6GKyqJrigg1zJK8bGOITlA=; b=PfBdJKTxpyF/3HDs1mTBJJUqhHYDW6WQKQoJBd2NflgsdNl7oDOCD/1cqKIfyJbaHT qwMKAq7sgm+BZFESI2YLv//tC8aX+I6N4p3LxvSUz+jbpeARbQMjNZ+1MFjFSTivJSaY LurS8Q8Kcdp6yItrVb2uCfl7eMl1Xb30st7c0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=Tl8ajhRJxLIVoiVplBKmDgWQoXbw7VnKASxq81OiCZT+UK6NZcp5YqXIB7HGd1AY7Z CpuH5L82M5F7IaH4LB7KXCe3EeVv25NjGnDoWN/58lQ0Ha7RMYNclVBIzLALaXl2qe0L z9XaaGicYHI+7ppprj3iin5sZuufyp9uNipQ8= MIME-Version: 1.0 Received: by 10.223.97.75 with SMTP id k11mr2968531fan.55.1288212393973; Wed, 27 Oct 2010 13:46:33 -0700 (PDT) Received: by 10.223.94.68 with HTTP; Wed, 27 Oct 2010 13:46:33 -0700 (PDT) In-Reply-To: <89857.29286.qm@web120719.mail.ne1.yahoo.com> References: <89857.29286.qm@web120719.mail.ne1.yahoo.com> Date: Wed, 27 Oct 2010 15:46:33 -0500 Message-ID: From: Alan Cox To: "Dr. Baud" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: Contiguous physical memory X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: alc@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 20:46:35 -0000 On Wed, Oct 27, 2010 at 2:17 PM, Dr. Baud wrote: > > Can anyone suggest a method/formula to monitor contiguous physical > memory > allocations such that one could predict when contigmalloc(), make that > bus_dmamem_alloc might fail? > > >From the command line you can obtain this information with "sysctl vm.phys_free". Alan From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 28 03:57:35 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 B778E106564A for ; Thu, 28 Oct 2010 03:57:35 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-8.mit.edu (DMZ-MAILSEC-SCANNER-8.MIT.EDU [18.7.68.37]) by mx1.freebsd.org (Postfix) with ESMTP id 6F73B8FC17 for ; Thu, 28 Oct 2010 03:57:35 +0000 (UTC) X-AuditID: 12074425-b7c98ae000000a04-5d-4cc8f4aebf81 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-8.mit.edu (Symantec Brightmail Gateway) with SMTP id E4.5C.02564.EA4F8CC4; Wed, 27 Oct 2010 23:57:34 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id o9S3vYCp020611; Wed, 27 Oct 2010 23:57:34 -0400 Received: from multics.mit.edu (MULTICS.MIT.EDU [18.187.1.73]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id o9S3vWFT020124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 27 Oct 2010 23:57:34 -0400 (EDT) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id o9S3vWNh015943; Wed, 27 Oct 2010 23:57:32 -0400 (EDT) Date: Wed, 27 Oct 2010 23:57:31 -0400 (EDT) From: Benjamin Kaduk To: Kostik Belousov In-Reply-To: <20101027153402.GS2392@deviant.kiev.zoral.com.ua> Message-ID: References: <1288160610.4280.18.camel@apollon> <201010270912.47076.jhb@freebsd.org> <20101027153402.GS2392@deviant.kiev.zoral.com.ua> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: AAAAAA== Cc: freebsd-hackers@freebsd.org Subject: Re: [PATCH] Fix 'implicit declaration' warning and update vgone(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 28 Oct 2010 03:57:35 -0000 On Wed, 27 Oct 2010, Kostik Belousov wrote: > On Wed, Oct 27, 2010 at 10:59:56AM -0400, Benjamin Kaduk wrote: >> [1] The old (racy) function is osi_TryEvictVCache, here: >> http://git.openafs.org/?p=openafs.git;a=blob;f=src/afs/FBSD/osi_vcache.c;h=c2060c74f0155a610d2ea94f3c7f508e8ca4373a;hb=HEAD > The function looks very strange for much more serious reasons. Why do you > try to manage the vnode revocation in the filesystem module at all ? I am still becoming familiar with the AFS code, but I think this is largely due to a difference in the vfs structure that AFS has been using and the FreeBSD standard. E.g. vop_inactive/vop_reclaim do not actually free filesystem-specific resources, instead keeping a free list of "vcache" entries. So, the original authors of this AFS code were approaching the problem in a somewhat different way. Therefore, are somewhat-orthogonal pools of vcaches and vnodes (with some intersection). If the vcaches are all in use in use, there is a routine which tries to "shake some loose"; if it can free up vcaches, their associated vnodes also need to be cleaned up in some fashion. It may be that no additional code is actually needed to do this, though -- I am not sure. > VFS will (assumedly in a right way) revoke and destroy non-referenced > vnodes when needed. > You are, in essence, suggesting that the body of the conditional should be just "return 1;"? (In my incomplete testing the vref() call was always made.) > Anyway, you need to hold vnode lock before checking for the vnode refcounter. > See the vfs_subr.c:vlrureclaim() for the correct dance with vholdl()/vn_lock() > sequence that does the revocation I mentioned in the race-free way. Unless I am mistaken, the path you refer to still uses vgonel(), which is not available to me. Is it safe to drop and reaquire the interlock between the vgone and vdrop? Many thanks, Ben From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 28 07:48: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 772CD106564A for ; Thu, 28 Oct 2010 07:48:11 +0000 (UTC) (envelope-from eknath.iyer@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 C52D98FC13 for ; Thu, 28 Oct 2010 07:48:10 +0000 (UTC) Received: by fxm17 with SMTP id 17so1662595fxm.13 for ; Thu, 28 Oct 2010 00:48: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:date:message-id :subject:from:to:content-type; bh=bV8oEZZKwPHKFEPWh345w923xLQ4WwMbzWe8Zjf47qQ=; b=qzOwtNRbgcD3wu7qsTYmSbbfU7hZTGwOPPtlZPy9GSBfiUVETKIUGMBqh/ODcGKCw5 t4plu2RbQZjRGi2uB4w2b9Q9GEKqrE7ecT3VW681f3+5GxxYEn5hpMDJ6dCbNO9jbIPy iT3QpC9Tg5IpfoHW54O6pAMNQZjdcGwMmICdQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=S8fO6y9wTcZU4p8XkCHac+DYBIMvtuX+KmgDSBS3lzhgkOy/GdPUJbUEUOsMWOrZBm McNSMacfcmC7k6grDIZrv7t6jX/pikAYU88D83EAnIb/xGfnDiMboMhQhrOcL78YaQ15 NCrsZX46y1m3VYzD2u73mb+MG5JsYb7nBS5sA= MIME-Version: 1.0 Received: by 10.239.135.8 with SMTP id b8mr671465hbb.28.1288252089464; Thu, 28 Oct 2010 00:48:09 -0700 (PDT) Received: by 10.239.150.67 with HTTP; Thu, 28 Oct 2010 00:48:09 -0700 (PDT) Date: Thu, 28 Oct 2010 03:48:09 -0400 Message-ID: From: Eknath Venkataramani To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: vm_object ref_count question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 07:48:11 -0000 ref_count is defined inside struct vm_object. and it is incremented everytime the object is referenced How is the page reference logged then? rather in which variable? -- Eknath Venkataramani From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 28 08:11: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 955CF106564A; Thu, 28 Oct 2010 08:11:32 +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 3BB0B8FC0A; Thu, 28 Oct 2010 08:11:32 +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 o9S8BVFr069241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 28 Oct 2010 01:11:31 -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 o9S8BVKe069240; Thu, 28 Oct 2010 01:11:31 -0700 (PDT) Received: from fbsd61 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA13450; Thu, 28 Oct 10 01:02:13 PDT Date: Thu, 28 Oct 2010 01:01:53 -0700 From: perryh@pluto.rain.com To: ivoras@freebsd.org Message-Id: <4cc92df1.Z0CRaJOCdvd/ZJSL%perryh@pluto.rain.com> References: <20101026213618.GA3013@freebsd.org> <4cc7ea44.ApOaxS8Xr4Sxu+0x%perryh@pluto.rain.com> <20101027111124.00007450@unknown> 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: fsync(2) manual and hdd write caching X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 28 Oct 2010 08:11:32 -0000 Ivan Voras wrote: > ... The problem is actually pretty hard - since AFAIK SoftUpdates > doesn't have "checkpoints" in the sense that it groups writes and > all data "before" can guaranteed to be on-disk, the problem is > *when* to issue BIO_FLUSH requests. Seems to me the originally-stated problem -- making fsync(2) do what it claims to do -- is not hard at all. Just issue a BIO_FLUSH request as the final step in handling fsync(2). While we're at it, perhaps do the same in close(2). I _hope_ we are already doing it in unmount(2). From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 28 13:21: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 96F78106566B for ; Thu, 28 Oct 2010 13:21: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 302718FC18 for ; Thu, 28 Oct 2010 13:21:11 +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 o9SDKe3i087007 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Oct 2010 16:20:40 +0300 (EEST) (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 o9SDKepQ017420; Thu, 28 Oct 2010 16:20:40 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o9SDKe0D017419; Thu, 28 Oct 2010 16:20:40 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 28 Oct 2010 16:20:40 +0300 From: Kostik Belousov To: Benjamin Kaduk Message-ID: <20101028132040.GV2392@deviant.kiev.zoral.com.ua> References: <1288160610.4280.18.camel@apollon> <201010270912.47076.jhb@freebsd.org> <20101027153402.GS2392@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rBv5AOddlEkG746b" Content-Disposition: inline In-Reply-To: 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 Subject: Re: [PATCH] Fix 'implicit declaration' warning and update vgone(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 28 Oct 2010 13:21:12 -0000 --rBv5AOddlEkG746b Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 27, 2010 at 11:57:31PM -0400, Benjamin Kaduk wrote: > On Wed, 27 Oct 2010, Kostik Belousov wrote: >=20 > >On Wed, Oct 27, 2010 at 10:59:56AM -0400, Benjamin Kaduk wrote: > >>[1] The old (racy) function is osi_TryEvictVCache, here: > >>http://git.openafs.org/?p=3Dopenafs.git;a=3Dblob;f=3Dsrc/afs/FBSD/osi_v= cache.c;h=3Dc2060c74f0155a610d2ea94f3c7f508e8ca4373a;hb=3DHEAD > >The function looks very strange for much more serious reasons. Why do you > >try to manage the vnode revocation in the filesystem module at all ? >=20 > I am still becoming familiar with the AFS code, but I think this is=20 > largely due to a difference in the vfs structure that AFS has been using= =20 > and the FreeBSD standard. E.g. vop_inactive/vop_reclaim do not actually= =20 > free filesystem-specific resources, instead keeping a free list of=20 > "vcache" entries. So, the original authors of this AFS code were=20 > approaching the problem in a somewhat different way. > Therefore, are somewhat-orthogonal pools of vcaches and vnodes (with some= =20 > intersection). If the vcaches are all in use in use, there is a routine= =20 > which tries to "shake some loose"; if it can free up vcaches, their=20 > associated vnodes also need to be cleaned up in some fashion. It may be= =20 > that no additional code is actually needed to do this, though -- I am not= =20 > sure. I think the best would be to move the code to vop_reclaim(), possibly calli= ng vgone() from vop_inactivate(). >=20 > >VFS will (assumedly in a right way) revoke and destroy non-referenced > >vnodes when needed. > > >=20 > You are, in essence, suggesting that the body of the conditional should= =20 > be just "return 1;"? (In my incomplete testing the vref() call was alway= s=20 > made.) See above. >=20 > >Anyway, you need to hold vnode lock before checking for the vnode=20 > >refcounter. > >See the vfs_subr.c:vlrureclaim() for the correct dance with=20 > >vholdl()/vn_lock() > >sequence that does the revocation I mentioned in the race-free way. >=20 > Unless I am mistaken, the path you refer to still uses vgonel(), which is= =20 > not available to me. Is it safe to drop and reaquire the interlock=20 > between the vgone and vdrop? vgonel() use is an optimization to avoid dropping/reacquiring the vnode interlock. Correct code can call vdrop() after vgone() call, without doing anything with interlock. Please note that vnode lock should be dropped between vgone and vdrop. --rBv5AOddlEkG746b Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAkzJeKYACgkQC3+MBN1Mb4hsrgCdFQG74NlbbWc11/wK8dqwOrRq 1rcAoINyikHIyz7RRAPGQOdFSXlncjPE =cEbt -----END PGP SIGNATURE----- --rBv5AOddlEkG746b-- From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 28 17:35:20 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 78B24106566B for ; Thu, 28 Oct 2010 17:35:20 +0000 (UTC) (envelope-from alan.l.cox@gmail.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 02FE78FC08 for ; Thu, 28 Oct 2010 17:35:19 +0000 (UTC) Received: by bwz3 with SMTP id 3so1793441bwz.13 for ; Thu, 28 Oct 2010 10:35:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:cc :content-type; bh=cFFO0lLYD66eezJ962xJU0ZqQGW6sXoy+44Qn4RoEWI=; b=DsuMp8STbKpFT7R7oJwGVq0W98FIjx1ffcJouWkdnUXAMiG8gtgMf81OBEia6sx9Rl dMIMvl9duflb5N6a7fZYz00CWC2XVGhqJMjAAhrg7OL9LyXaYfx3T/6pFR23xH+NklYe iMAeZozpnRNuO080PFudPtUkA+5RlL2Jd3inU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=Cm1r2hLK4VLkr5RjfsD1ewfyjxt0D48h1Aptm9Jc7lH5q3E+Y4eQJ8Dq8DCWZcbn++ 6nZ2+3Nc8EA17lL9XC0NkEK7raqlOmbk4q8Xi20JR1IDbMUyrlaayUuko+L2R26mgOL/ F3iAB52/2DsKAiT8a5L+8vWQSvECiUGufGiec= MIME-Version: 1.0 Received: by 10.204.77.8 with SMTP id e8mr739911bkk.108.1288287318483; Thu, 28 Oct 2010 10:35:18 -0700 (PDT) Received: by 10.223.94.68 with HTTP; Thu, 28 Oct 2010 10:35:18 -0700 (PDT) In-Reply-To: References: Date: Thu, 28 Oct 2010 12:35:18 -0500 Message-ID: From: Alan Cox To: Eknath Venkataramani Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: vm_object ref_count question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: alc@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 17:35:20 -0000 On Thu, Oct 28, 2010 at 2:48 AM, Eknath Venkataramani wrote: > ref_count is defined inside struct vm_object. > and it is incremented everytime the object is referenced > How is the page reference logged then? rather in which variable? > > There is no per-page reference. There is, however, a garbage-collection-like process performed by vm_object_collapse(). Regards, Alan From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 29 15:18:54 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 68C82106564A for ; Fri, 29 Oct 2010 15:18:54 +0000 (UTC) (envelope-from jh@FreeBSD.org) Received: from gw03.mail.saunalahti.fi (gw03.mail.saunalahti.fi [195.197.172.111]) by mx1.freebsd.org (Postfix) with ESMTP id 231FA8FC24 for ; Fri, 29 Oct 2010 15:18:53 +0000 (UTC) Received: from a91-153-123-205.elisa-laajakaista.fi (a91-153-123-205.elisa-laajakaista.fi [91.153.123.205]) by gw03.mail.saunalahti.fi (Postfix) with SMTP id 12154216677; Fri, 29 Oct 2010 18:18:50 +0300 (EEST) Date: Fri, 29 Oct 2010 18:18:03 +0300 From: Jaakko Heinonen To: Garrett Cooper Message-ID: <20101029151803.GB1400@a91-153-123-205.elisa-laajakaista.fi> 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] Add SF_ARCHIVED to EPERM in chflags(2) ERROR section X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 29 Oct 2010 15:18:54 -0000 On 2010-10-23, Garrett Cooper wrote: > The SF_ARCHIVED flag isn't noted in the chflags(2) ERROR section. > The attached patch adds the entry. > If no one has any objections, could someone help me commit this? > Index: lib/libc/sys/chflags.2 > =================================================================== > --- lib/libc/sys/chflags.2 (revision 213377) > +++ lib/libc/sys/chflags.2 (working copy) > @@ -148,14 +148,14 @@ > the effective user ID is not the super-user. > .It Bq Er EPERM > One of > -.Dv SF_IMMUTABLE , SF_APPEND , > +.Dv SF_ARCHIVED , SF_IMMUTABLE , SF_APPEND , > or > .Dv SF_NOUNLINK > is set and the user is either not the super-user or > securelevel is greater than 0. This is not correct. SF_ARCHIVED doesn't prevent setting of the flags. > .It Bq Er EPERM > A non-super-user tries to set one of > -.Dv SF_IMMUTABLE , SF_APPEND , > +.Dv SF_ARCHIVED , SF_IMMUTABLE , SF_APPEND , > or > .Dv SF_NOUNLINK . > .It Bq Er EPERM I have committed this in r214514. Thanks! -- Jaakko From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 29 16:58:08 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 79416106564A for ; Fri, 29 Oct 2010 16:58:08 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4C2918FC1E for ; Fri, 29 Oct 2010 16:58:08 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id F1A8A46B2E; Fri, 29 Oct 2010 12:58:07 -0400 (EDT) Date: Fri, 29 Oct 2010 17:58:07 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Benjamin Kaduk In-Reply-To: Message-ID: References: <1288160610.4280.18.camel@apollon> <201010270912.47076.jhb@freebsd.org> <20101027153402.GS2392@deviant.kiev.zoral.com.ua> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Kostik Belousov , freebsd-hackers@freebsd.org Subject: Re: [PATCH] Fix 'implicit declaration' warning and update vgone(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 29 Oct 2010 16:58:08 -0000 On Wed, 27 Oct 2010, Benjamin Kaduk wrote: > On Wed, 27 Oct 2010, Kostik Belousov wrote: > >> On Wed, Oct 27, 2010 at 10:59:56AM -0400, Benjamin Kaduk wrote: >>> [1] The old (racy) function is osi_TryEvictVCache, here: >>> http://git.openafs.org/?p=openafs.git;a=blob;f=src/afs/FBSD/osi_vcache.c;h=c2060c74f0155a610d2ea94f3c7f508e8ca4373a;hb=HEAD >> The function looks very strange for much more serious reasons. Why do you >> try to manage the vnode revocation in the filesystem module at all ? > > I am still becoming familiar with the AFS code, but I think this is largely > due to a difference in the vfs structure that AFS has been using and the > FreeBSD standard. E.g. vop_inactive/vop_reclaim do not actually free > filesystem-specific resources, instead keeping a free list of "vcache" > entries. So, the original authors of this AFS code were approaching the > problem in a somewhat different way. Therefore, are somewhat-orthogonal > pools of vcaches and vnodes (with some intersection). If the vcaches are > all in use in use, there is a routine which tries to "shake some loose"; if > it can free up vcaches, their associated vnodes also need to be cleaned up > in some fashion. It may be that no additional code is actually needed to do > this, though -- I am not sure. I have a hazy recollection, from quite a long time ago, that OpenAFS used to be a bit special with regard to vnodes -- allocating its own, or something along those lines. I expect it no longer does that, but it could be that it feels it "owns" the vnodes more than your average file system does, which may play less well with global management of vnodes. Derrick would probably have more to say on this. Robert From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 29 19:18:45 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 161221065693 for ; Fri, 29 Oct 2010 19:18:45 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id C11158FC12 for ; Fri, 29 Oct 2010 19:18:44 +0000 (UTC) Received: by qyk7 with SMTP id 7so6298463qyk.13 for ; Fri, 29 Oct 2010 12:18:43 -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=H3Mzut5iqEfqZPIhV4gdhhy0JseNDYmpeQ/IUW0n2Yk=; b=uhVFfWqiVRlObt4hk/UUB0xi0UDch0UQD6sIfte7bpGg9gY4GKU7KAfG7mweW2CoRi 87xW3TvmrfRba6eCYHaTuKMX1Bo05vK3PGgNwA723Zk2OtaBryeXT1cpJBmnineGMlNU RfbB4Y9m6d5xq2uHOZqp8Ml4HK6eGYejlW1Tk= 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=kiwgZN2Yu4TlFnZz/GNQWoJjPs/C57LndQSXRfLerQ4fB4FAbPdQvKzuutxIqjvd+6 tImiNSlDUKBr6g6QMaK7cmZ17JgRP5EqQufQAE4hhfkk1PoTDkPvRi08tp1/y1/sPttY NNBZk9m6O2DbZPc30PawHGRwmF/kVWXnndBUc= Received: by 10.224.177.205 with SMTP id bj13mr5317775qab.170.1288379923820; Fri, 29 Oct 2010 12:18:43 -0700 (PDT) Received: from mark-laptop-bsd.mark-home (mail1.sandvine.com [64.7.137.162]) by mx.google.com with ESMTPS id n7sm2597986qcu.40.2010.10.29.12.18.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 29 Oct 2010 12:18:43 -0700 (PDT) Date: Fri, 29 Oct 2010 15:18:27 -0400 From: Mark Johnston To: freebsd-hackers@freebsd.org Message-ID: <20101029191827.GC1443@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: Generating userland debugging symbols X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 29 Oct 2010 19:18:45 -0000 Hello all, I've been working on some changes to the system build scripts that make it easier to create and install debugging symbols files for the base userland. What we do in the tree at my work (Sandvine) is use a script that invokes strip(1) and objcopy(1) to create a separate file containing the debugging symbols for each binary; so for example, the symbols for /bin/ls get placed in another directory, e.g. /usr/local/lib/debug/bin/ls.symbols. The name of the symbols file for each binary is encoded in the .gnu_debuglink segment; when gdb comes across it, it searches a set of directories for the debug symbols file and loads it if found. It turns out to be pretty convenient - one can keep the debugging symbols on a separate slice or on an NFS-mounted directory if space is an issue, or package the debug symbols separately and keep them on an FTP server, ready to install if needed. I'm not aware of any infrastructure in place that makes it easy to do this for the userland programs. What I'm hoping to find out is whether there's any interest in adding such support. I've discussed this with Ed Maste to some degree, but it'd be nice to get some additional feedback. My basic idea is to add an option to /etc/src.conf that indicates that the build system should build all the userland programs with debugging symbols and later extract them. So a user would define something like WITH_DEBUG_SYMBOLS in src.conf, and then in bsd.own.mk, have something like .if !defined(_WITHOUT_SRCCONF) .if defined(WITH_DEBUG_SYMBOLS) SYMBOLS_DIR?=/usr/local/lib/debug STRIP_BIN:=" ${SYMBOLS_DIR}" .endif .endif and then in bsd.prog.mk: .if defined(STRIP_BIN) .PHONY: export STRIPBIN=${STRIP_BIN} .endif so that when install(1) gets run, STRIPBIN will be in the environment. In our setup, STRIPBIN points to a script which just uses strip(1) and objcopy(1) to extract the debug symbols for each binary that gets installed. Ed suggested that I could just add an option to strip(1) to do all of this in one command so that we wouldn't need to add a separate script to the FreeBSD tree for this. It's pretty simple to do - I can post the patch if anyone wants to see it. This also requires a smallish change to install(1) which I can also post. Any thoughts or suggestions on this approach in general? I'm still getting to know the FreeBSD system, so I'm open to alternatives. If there's agreement that this feature might be useful, I'll post my patches. Thanks, -Mark From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 29 23:39: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 EEF99106566C for ; Fri, 29 Oct 2010 23:39:04 +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 809838FC1B for ; Fri, 29 Oct 2010 23:39:04 +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 o9TNd003047592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 30 Oct 2010 02:39:00 +0300 (EEST) (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 o9TNd0gm034132; Sat, 30 Oct 2010 02:39:00 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o9TNd0rm034131; Sat, 30 Oct 2010 02:39:00 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 30 Oct 2010 02:39:00 +0300 From: Kostik Belousov To: Mark Johnston Message-ID: <20101029233900.GC2392@deviant.kiev.zoral.com.ua> References: <20101029191827.GC1443@mark-laptop-bsd.mark-home> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wD/HYRFy5EhJhSwd" Content-Disposition: inline In-Reply-To: <20101029191827.GC1443@mark-laptop-bsd.mark-home> 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 Subject: Re: Generating userland debugging symbols X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 29 Oct 2010 23:39:05 -0000 --wD/HYRFy5EhJhSwd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 29, 2010 at 03:18:27PM -0400, Mark Johnston wrote: > Hello all, >=20 > I've been working on some changes to the system build scripts that make > it easier to create and install debugging symbols files for the base > userland. What we do in the tree at my work (Sandvine) is use a script > that invokes strip(1) and objcopy(1) to create a separate file containing > the debugging symbols for each binary; so for example, the symbols for=20 > /bin/ls get placed in another directory, e.g. > /usr/local/lib/debug/bin/ls.symbols. >=20 > The name of the symbols file for each binary is encoded in the > .gnu_debuglink segment; when gdb comes across it, it searches a set > of directories for the debug symbols file and loads it if found. >=20 > It turns out to be pretty convenient - one can keep the debugging symbols > on a separate slice or on an NFS-mounted directory if space is an issue, > or package the debug symbols separately and keep them on an FTP server, > ready to install if needed. >=20 > I'm not aware of any infrastructure in place that makes it easy to do > this for the userland programs. What I'm hoping to find out is whether > there's any interest in adding such support. I've discussed this with > Ed Maste to some degree, but it'd be nice to get some additional feedback. >=20 > My basic idea is to add an option to /etc/src.conf that indicates that the > build system should build all the userland programs with debugging symbols > and later extract them. So a user would define something like > WITH_DEBUG_SYMBOLS in src.conf, and then in bsd.own.mk, have something > like >=20 > .if !defined(_WITHOUT_SRCCONF) > .if defined(WITH_DEBUG_SYMBOLS) > SYMBOLS_DIR?=3D/usr/local/lib/debug > STRIP_BIN:=3D" ${SYMBOLS_DIR}" > .endif > .endif >=20 > and then in bsd.prog.mk: >=20 > .if defined(STRIP_BIN) > .PHONY: > export STRIPBIN=3D${STRIP_BIN} > .endif >=20 > so that when install(1) gets run, STRIPBIN will be in the environment. >=20 > In our setup, STRIPBIN points to a script which just uses strip(1) and > objcopy(1) to extract the debug symbols for each binary that gets > installed. Ed suggested that I could just add an option to strip(1) to > do all of this in one command so that we wouldn't need to add a separate > script to the FreeBSD tree for this. It's pretty simple to do - I can > post the patch if anyone wants to see it. This also requires a smallish > change to install(1) which I can also post. >=20 > Any thoughts or suggestions on this approach in general? I'm still > getting to know the FreeBSD system, so I'm open to alternatives. If > there's agreement that this feature might be useful, I'll post my patches. I do think that something like this would be useful. But, shouldn't the DEBUG_FLAGS be also involved in the patch ? The goal would be to have debug symbols for userland staff. esp. the libraries, handled in a similar manner to kernel symbols. But I do like the intent of keeping the symbols in the separate directory. --wD/HYRFy5EhJhSwd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAkzLWxQACgkQC3+MBN1Mb4imDQCfZ0lNu/wit2eu9hl3sJjxX0ih ZigAoOMeQqE2cWedSI/ApbrFsty3n1ZA =1ADu -----END PGP SIGNATURE----- --wD/HYRFy5EhJhSwd-- From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 30 00:12:09 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 019781065694 for ; Sat, 30 Oct 2010 00:12:09 +0000 (UTC) (envelope-from gonzo@launchpad.bluezbox.com) Received: from launchpad.bluezbox.com (hq.bluezbox.com [70.38.37.145]) by mx1.freebsd.org (Postfix) with ESMTP id C1B718FC18 for ; Sat, 30 Oct 2010 00:12:08 +0000 (UTC) Received: from localhost ([127.0.0.1]) by launchpad.bluezbox.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PBz3F-000JNI-Os for hackers@freebsd.org; Fri, 29 Oct 2010 17:12:06 -0700 Message-ID: <4CCB62D6.1050808@bluezbox.com> Date: Fri, 29 Oct 2010 17:12:06 -0700 From: Oleksandr Tymoshenko User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: gonzo@launchpad.bluezbox.com X-Spam-Level: ---- X-Spam-Report: Spam detection software, running on the system "hq.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: 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 [...] Content analysis details: (-4.4 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] Cc: Subject: [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: Sat, 30 Oct 2010 00:12:09 -0000 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? From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 30 01:05: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 55911106564A for ; Sat, 30 Oct 2010 01:05:10 +0000 (UTC) (envelope-from yanegomi@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 0BDC58FC12 for ; Sat, 30 Oct 2010 01:05:09 +0000 (UTC) Received: by gxk9 with SMTP id 9so2498635gxk.13 for ; Fri, 29 Oct 2010 18:05:09 -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=a2XvN3oU11OSO/hEM+QNbe6daZTuEXtewdvur5KOrd8=; b=dDjBQvB6JaE8dXBnWVDUXC611IoAH5jVmVbuGLi9XZWymGSOhjlXXXjnoOme0+8tyG KyItaE9CvAiCeJfQ4uZ92kz0WyvnGhayyXmI2TKE+UyM4JiCq/IDjX4roOiFt/1MlZYJ xIoULeSkG6bmJ4vtF4Z6uZ1wZLMxFyQTnbZTI= 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=WfQXJppmnqSPD04MJwPYwXLE2FZHG4uwV1I8o2X91eGPOoo4srjxAbbMeUhED+vElw EwChPXGxAC58dPfsF5uampDai82VLPt0RkSRL4VnAgBzaRtZb/bdMaMf/FSuIC7U8H/s 0fvLo26gHryBCtLfdm1bunsjnjoms3ablNl+I= MIME-Version: 1.0 Received: by 10.90.2.20 with SMTP id 20mr5236264agb.69.1288400708626; Fri, 29 Oct 2010 18:05:08 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.90.70.19 with HTTP; Fri, 29 Oct 2010 18:05:08 -0700 (PDT) In-Reply-To: <20101029233900.GC2392@deviant.kiev.zoral.com.ua> References: <20101029191827.GC1443@mark-laptop-bsd.mark-home> <20101029233900.GC2392@deviant.kiev.zoral.com.ua> Date: Fri, 29 Oct 2010 18:05:08 -0700 X-Google-Sender-Auth: cA2TwomkZkmTR-ZozfM4qgnuCJ4 Message-ID: From: Garrett Cooper To: Kostik Belousov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Mark Johnston Subject: Re: Generating userland debugging symbols X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 30 Oct 2010 01:05:10 -0000 On Fri, Oct 29, 2010 at 4:39 PM, Kostik Belousov wrot= e: > On Fri, Oct 29, 2010 at 03:18:27PM -0400, Mark Johnston wrote: >> Hello all, >> >> I've been working on some changes to the system build scripts that make >> it easier to create and install debugging symbols files for the base >> userland. What we do in the tree at my work (Sandvine) is use a script >> that invokes strip(1) and objcopy(1) to create a separate file containin= g >> the debugging symbols for each binary; so for example, the symbols for >> /bin/ls get placed in another directory, e.g. >> /usr/local/lib/debug/bin/ls.symbols. >> >> The name of the symbols file for each binary is encoded in the >> .gnu_debuglink segment; when gdb comes across it, it searches a set >> of directories for the debug symbols file and loads it if found. >> >> It turns out to be pretty convenient - one can keep the debugging symbol= s >> on a separate slice or on an NFS-mounted directory if space is an issue, >> or package the debug symbols separately and keep them on an FTP server, >> ready to install if needed. >> >> I'm not aware of any infrastructure in place that makes it easy to do >> this for the userland programs. What I'm hoping to find out is whether >> there's any interest in adding such support. I've discussed this with >> Ed Maste to some degree, but it'd be nice to get some additional feedbac= k. >> >> My basic idea is to add an option to /etc/src.conf that indicates that t= he >> build system should build all the userland programs with debugging symbo= ls >> and later extract them. So a user would define something like >> WITH_DEBUG_SYMBOLS in src.conf, and then in bsd.own.mk, have something >> like >> >> .if !defined(_WITHOUT_SRCCONF) >> .if defined(WITH_DEBUG_SYMBOLS) >> SYMBOLS_DIR?=3D/usr/local/lib/debug >> STRIP_BIN:=3D" ${SYMBOLS_DIR}" >> .endif >> .endif >> >> and then in bsd.prog.mk: >> >> .if defined(STRIP_BIN) >> .PHONY: >> =A0 =A0 =A0 export STRIPBIN=3D${STRIP_BIN} >> .endif >> >> so that when install(1) gets run, STRIPBIN will be in the environment. >> >> In our setup, STRIPBIN points to a script which just uses strip(1) and >> objcopy(1) to extract the debug symbols for each binary that gets >> installed. Ed suggested that I could just add an option to strip(1) to >> do all of this in one command so that we wouldn't need to add a separate >> script to the FreeBSD tree for this. It's pretty simple to do - I can >> post the patch if anyone wants to see it. This also requires a smallish >> change to install(1) which I can also post. But having a strip script might be useful. Some companies brand binaries for their own purposes, so having a hook into a strip script (it should be no more than a few lines), should suffice. Something that my old group used was similar to what's described in the objcopy manpage: The intention is that this option will be used in conjunction w= ith --add-gnu-debuglink to create a two part executable. One= a stripped binary which will occupy less space in RAM and in a d= is- tribution and the second a debugging information file which is o= nly needed if debugging abilities are required. The suggested pro= ce- dure to create these files is as follows: 1. "foo" then... 1. create a file containing the debugging info. 1. stripped executable. 1. to add a link to the debugging info into the stripped e= xe- cutable. That's probably similar to what your group is doing... Of course a more generalized solution also might be smart if clang / llvm decides to go off in a completely different direction syntactically from binutils. Hence a custom tailored set of scripts may or may not be the way to go (is pmake's .USE directive another option?). >> Any thoughts or suggestions on this approach in general? I'm still >> getting to know the FreeBSD system, so I'm open to alternatives. If >> there's agreement that this feature might be useful, I'll post my patche= s. > I do think that something like this would be useful. But, shouldn't > the DEBUG_FLAGS be also involved in the patch ? The goal would be > to have debug symbols for userland staff. esp. the libraries, > handled in a similar manner to kernel symbols. > > But I do like the intent of keeping the symbols in the separate directory= . I agree with kib@ on both counts and I like this idea. Maybe the directory should be something like /usr/obj/stripped for the stripped binaries and /usr/obj/debug for the debug symbols? (just something I'm tossing out... the hierarchy could be better organized than that..). It might get a bit more hairy to clean up later, but oh well, it's for development :D... Thanks! -Garrett From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 30 01:58:44 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 6C5A5106566C for ; Sat, 30 Oct 2010 01:58:44 +0000 (UTC) (envelope-from markjdb@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 21B818FC16 for ; Sat, 30 Oct 2010 01:58:43 +0000 (UTC) Received: by gya6 with SMTP id 6so2548149gya.13 for ; Fri, 29 Oct 2010 18:58:43 -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=Khnn+X0clG/+aFwXLypJsEbDPjyroIsG4AXupb4gzDs=; b=Xoqn/tZ+dCm5kFEhy7ukX9S/HD6uKopl2r/otIKwr81yskzZCqalo7iYLZGgS8L3mf VFmqJPRJ2T2nEsKR8IGlUQyp/qXCoJqLp59M9FUpwkMw5hbB8ny1haQTXaexsDGgJIL6 CDc6QdRvErK2oFg8kYPWvjSz8V78iuey6R/Uw= 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=SFlXB/9mMplXUVx7kzRYDTUyM/8Fg3Rng17jijUe8tCPUUbNpVpMdlcelmbz+Ck+r3 GWfyKKeczvSiaFh5pBms7BDujS1986IIQ3MyLzqUQPDZjFj9ymsg8sNNw8sRav9QTXgt ynIYjjC+2sZ4eX4JjFJaNt1619wQNB2t4+p7I= Received: by 10.151.26.14 with SMTP id d14mr23282985ybj.266.1288403923376; Fri, 29 Oct 2010 18:58:43 -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 z33sm2263289yhc.33.2010.10.29.18.58.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 29 Oct 2010 18:58:42 -0700 (PDT) Date: Fri, 29 Oct 2010 21:58:26 -0400 From: Mark Johnston To: Kostik Belousov Message-ID: <20101030015826.GA1305@mark-laptop-bsd.mark-home> References: <20101029191827.GC1443@mark-laptop-bsd.mark-home> <20101029233900.GC2392@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101029233900.GC2392@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hackers@freebsd.org Subject: Re: Generating userland debugging symbols X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 30 Oct 2010 01:58:44 -0000 On Sat, Oct 30, 2010 at 02:39:00AM +0300, Kostik Belousov wrote: > I do think that something like this would be useful. But, shouldn't > the DEBUG_FLAGS be also involved in the patch ? The goal would be > to have debug symbols for userland staff. esp. the libraries, > handled in a similar manner to kernel symbols. > > But I do like the intent of keeping the symbols in the separate directory. Yes, you're right. What I would probably do is have make(1) set DEBUG_FLAGS=-g automatically if WITH_DEBUG_SYMBOLS is defined in /etc/src.conf. I've been using the source tree at my work, which has another Makefile and some other scripts on top of the FreeBSD build system, so they're probably doing some things I don't know about. Based on what I've seen however, it shouldn't be too much work to port the necessary changes over. -Mark From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 30 02:10:19 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 33066106564A for ; Sat, 30 Oct 2010 02:10:19 +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 DB83F8FC08 for ; Sat, 30 Oct 2010 02:10:18 +0000 (UTC) Received: by yxl31 with SMTP id 31so2511153yxl.13 for ; Fri, 29 Oct 2010 19:10:18 -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=FgyRkDs8GSUFSSus5780+y27PuU9wt8TYMuRdUndPE4=; b=Eeo0CiH1jy98JiVPiCc0xdv6cC88+MHFF4ZJYDqr0urKwFvlqy9IMOVEXsqxbO0eoj S/mYTJz3ZuS/yjEYaoR99pt9O0/j9DXGSm4yp0lybsI+XA3vQX/eeNQEbU8B7CMPemhL GSccSBUjdKgkN4roDeo42pFuKEp9CuKKLMuaQ= 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=gjVAwPS18zVIDKucNT25QlpfcGenFmmK/lqar4j5rUJLXDC9EvU4krAxYNXEKEXZR5 6zaC97BPeDNEa3BEVNB0fWs06AhubdiiHXAuZN22R54yt52HaCDLrT1ZXgzAGRGi+1cu m/05FZXP+6SylJAgd5qeWUlco3mCIoN3Y+YYM= Received: by 10.91.42.15 with SMTP id u15mr5300339agj.203.1288404617875; Fri, 29 Oct 2010 19:10:17 -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 i69sm2278983yha.8.2010.10.29.19.10.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 29 Oct 2010 19:10:16 -0700 (PDT) Date: Fri, 29 Oct 2010 22:10:00 -0400 From: Mark Johnston To: Garrett Cooper Message-ID: <20101030021000.GA1328@mark-laptop-bsd.mark-home> References: <20101029191827.GC1443@mark-laptop-bsd.mark-home> <20101029233900.GC2392@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Kostik Belousov , freebsd-hackers@freebsd.org Subject: Re: Generating userland debugging symbols X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 30 Oct 2010 02:10:19 -0000 On Fri, Oct 29, 2010 at 06:05:08PM -0700, Garrett Cooper wrote: > But having a strip script might be useful. Some companies brand > binaries for their own purposes, so having a hook into a strip script > (it should be no more than a few lines), should suffice. Something > that my old group used was similar to what's described in the objcopy > manpage: > > The intention is that this option will be used in conjunction with > --add-gnu-debuglink to create a two part executable. One a > stripped binary which will occupy less space in RAM and in a dis- > tribution and the second a debugging information file which is only > needed if debugging abilities are required. The suggested proce- > dure to create these files is as follows: > > 1. > "foo" then... > > 1. > create a file containing the debugging info. > > 1. > stripped executable. > > 1. > to add a link to the debugging info into the stripped exe- > cutable. > > That's probably similar to what your group is doing... > Of course a more generalized solution also might be smart if clang > / llvm decides to go off in a completely different direction > syntactically from binutils. Hence a custom tailored set of scripts > may or may not be the way to go (is pmake's .USE directive another > option?). That's almost exactly what we're doing. I also think it's easier to go with a script, but the required changes to strip(1) and install(1) are pretty basic. strip(1) and objcopy(1) are both generated from the same source file, so it's just a matter of adding an extra option that performs the above operations in one command. I have no specific preference on this point though. I'm not familiar with pmake - I'll take a look into it. > > I agree with kib@ on both counts and I like this idea. Maybe the > directory should be something like /usr/obj/stripped for the stripped > binaries and /usr/obj/debug for the debug symbols? (just something I'm > tossing out... the hierarchy could be better organized than that..). > It might get a bit more hairy to clean up later, but oh well, it's for > development :D... > Thanks! > -Garrett It took me a while to figure this out, but the absolute path to the debug symbols isn't encoded in the .gnu_debuglink segment - just the filename is placed there. When gdb loads a binary, it searches a predefined set of directories for the file recorded in .gnu_debuglink and loads it if it finds it. One of the directories is global - on FreeBSD it seems to be /usr/local/lib/debug/ by default. You can configure it with show debug-file-directory and set debug-file-directory Thanks, -Mark From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 30 02:48: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 638F7106566C for ; Sat, 30 Oct 2010 02:48:33 +0000 (UTC) (envelope-from yanegomi@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 1864B8FC12 for ; Sat, 30 Oct 2010 02:48:32 +0000 (UTC) Received: by gxk9 with SMTP id 9so2521904gxk.13 for ; Fri, 29 Oct 2010 19:48: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 :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=EcI0zmElslmOLGpIelHGPVSUUMQvanIqE+EldaWEQR4=; b=rFQUEPgZAj9mmIArgcvG+bXSuq/6HJdkldiZSyBV4HjMDbHSVffJsmLtoOwrTyeO6e 4QoyEfcfpCqs2b8gBCADjboqmsN6K7Ey58mtSSD9NIRUo12mt3TRjgYTKH/k2X5wZMVh DDuewnHMDx8EYI7QlWgbszOrSFYbUiBnl/jhE= 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=TgAt2tdZ9mHWGcH5X/qohTrwN7913tqCjDoe/xaAUPKkedBQtUp6RdnP0RGO3qLmce wn1//8rQlqPZHNBVZ6ivAJj/opgpAE0gHTDZ4tgkeYY8K/aKtTugFV0CMlFelZMrCXTQ 1XSCzUaaza4xCCaFoB9P22b2u/QDUg+pJ8tPA= MIME-Version: 1.0 Received: by 10.90.22.29 with SMTP id 29mr5339629agv.14.1288406911917; Fri, 29 Oct 2010 19:48:31 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.90.70.19 with HTTP; Fri, 29 Oct 2010 19:48:31 -0700 (PDT) In-Reply-To: <20101030021000.GA1328@mark-laptop-bsd.mark-home> References: <20101029191827.GC1443@mark-laptop-bsd.mark-home> <20101029233900.GC2392@deviant.kiev.zoral.com.ua> <20101030021000.GA1328@mark-laptop-bsd.mark-home> Date: Fri, 29 Oct 2010 19:48:31 -0700 X-Google-Sender-Auth: JE2hZbnDcyranD3x2b4xoZuaOhw Message-ID: From: Garrett Cooper To: Mark Johnston Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Kostik Belousov , freebsd-hackers@freebsd.org Subject: Re: Generating userland debugging symbols X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 30 Oct 2010 02:48:33 -0000 On Fri, Oct 29, 2010 at 7:10 PM, Mark Johnston wrote: > On Fri, Oct 29, 2010 at 06:05:08PM -0700, Garrett Cooper wrote: >> =A0 =A0 But having a strip script might be useful. Some companies brand >> binaries for their own purposes, so having a hook into a strip script >> (it should be no more than a few lines), should suffice. Something >> that my old group used was similar to what's described in the objcopy >> manpage: >> >> =A0 =A0 =A0 =A0 =A0 =A0The =A0intention is that this option will be used= in conjunction with >> =A0 =A0 =A0 =A0 =A0 =A0--add-gnu-debuglink =A0to =A0create =A0a =A0two = =A0part =A0executable. =A0 One =A0a >> =A0 =A0 =A0 =A0 =A0 =A0stripped =A0binary =A0which will occupy less spac= e in RAM and in a dis- >> =A0 =A0 =A0 =A0 =A0 =A0tribution and the second a debugging information = file which is only >> =A0 =A0 =A0 =A0 =A0 =A0needed =A0if =A0debugging abilities are required.= =A0The suggested proce- >> =A0 =A0 =A0 =A0 =A0 =A0dure to create these files is as follows: >> >> =A0 =A0 =A0 =A0 =A0 =A01. >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"foo" then... >> >> =A0 =A0 =A0 =A0 =A0 =A01. >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0create a file containing the debugging in= fo. >> >> =A0 =A0 =A0 =A0 =A0 =A01. >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0stripped executable. >> >> =A0 =A0 =A0 =A0 =A0 =A01. > I'm not familiar with pmake - I'll take a look into it. > > pmake is FreeBSD's make: http://www.freebsd.org/doc/en/books/pmake/ Ah... I'm still getting to know FreeBSD. =) I'll take a look through the docs when I have some spare time this weekend. > > >> I agree with kib@ on both counts and I like this idea. Maybe the > >> directory should be something like /usr/obj/stripped for the stripped > >> binaries and /usr/obj/debug for the debug symbols? (just something I'm > >> tossing out... the hierarchy could be better organized than that..). > >> It might get a bit more hairy to clean up later, but oh well, it's for > >> development :D... > >> Thanks! > >> -Garrett > > > > It took me a while to figure this out, but the absolute path to the > > debug symbols isn't encoded in the .gnu_debuglink segment - just the > > filename is placed there. When gdb loads a binary, it searches a > > predefined set of directories for the file recorded in .gnu_debuglink > > and loads it if it finds it. One of the directories is global - on > > FreeBSD it seems to be /usr/local/lib/debug/ by default. You can > > configure it with > > Hmmm... didn't realize it all went there. What about cases with > compat libraries where we need versioning? That's a good point. Symbols files for libraries should be named by version, so that, say, /lib/libc.so.7 would have its gnu_debuglink point to /usr/local/lib/debug/lib/libc.7.symbols. Is this what you're referring to? Thanks, -Mark From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 30 04:58:37 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 B353E1065672 for ; Sat, 30 Oct 2010 04:58:37 +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 3E9DA8FC12 for ; Sat, 30 Oct 2010 04:58:36 +0000 (UTC) Received: by wyb42 with SMTP id 42so3788528wyb.13 for ; Fri, 29 Oct 2010 21:58:36 -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=j8+nxyEWeWYzkADLDxMURLbeME59k4/4t2Ebv8KTMjw=; b=f/pw+pG8fbtnLEarUUkj49jPnSKhZ0iKgqPyPEc5DyYS0Ud02+Cv+CHci/4cAkkbuf /8O+2RD8+jf6udcCevTnSxfrX8Xv2+LRaHCiyzWqB1krQ81aLPYJ85P7qJXDK5Vedw2p pShor6ZY0gblYExeAs91TMLVyMFke4yddWDTg= 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=EEquLbV4JziBrZB5FpFnWdA1gijlMNl6ns2QIfDwX3MccU4jw7i0H3ziVQy3d1UZ3z 6x1muNuA68zCL06pT8209f3H2xmJq1EUwgOct7L/YocICaOJXIGW9rpNh0cnKyoYHE7H IYarzm0w2CIeVrhb04sus+z6cfUeZpmpji3eA= MIME-Version: 1.0 Received: by 10.216.172.9 with SMTP id s9mr12904286wel.56.1288414715599; Fri, 29 Oct 2010 21:58:35 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.216.10.198 with HTTP; Fri, 29 Oct 2010 21:58:35 -0700 (PDT) In-Reply-To: <20101030033559.GA1387@mark-laptop-bsd.mark-home> References: <20101029191827.GC1443@mark-laptop-bsd.mark-home> <20101029233900.GC2392@deviant.kiev.zoral.com.ua> <20101030021000.GA1328@mark-laptop-bsd.mark-home> <20101030033559.GA1387@mark-laptop-bsd.mark-home> Date: Fri, 29 Oct 2010 21:58:35 -0700 X-Google-Sender-Auth: T9HfxsTxhus-8RhUSDKC1CMsUJc Message-ID: From: Garrett Cooper To: Mark Johnston Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: Generating userland debugging symbols X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 30 Oct 2010 04:58:37 -0000 On Fri, Oct 29, 2010 at 8:35 PM, Mark Johnston wrote: > On Fri, Oct 29, 2010 at 07:48:31PM -0700, Garrett Cooper wrote: >> On Fri, Oct 29, 2010 at 7:10 PM, Mark Johnston wrote= : >> > On Fri, Oct 29, 2010 at 06:05:08PM -0700, Garrett Cooper wrote: >> > >> > That's almost exactly what we're doing. I also think it's easier to go= with a >> > script, but the required changes to strip(1) and install(1) are pretty >> > basic. strip(1) and objcopy(1) are both generated from the same source >> > file, so it's just a matter of adding an extra option that performs th= e >> > above operations in one command. I have no specific preference on this >> > point though. >> >> Well.. perhaps, but this would impact the performance of standard make >> operations across the board, outside of FreeBSD make; trivially I'm >> sure, but it's just easier in this case probably to make it shell >> based and keep it confined to the FreeBSD build as it's a FreeBSD >> specific feature (unless the feature is truly useful enough and you >> can get enough folks on the bandwagon to standardize the feature) :/. >> > > I can't see how there'd be any performance difference - all I did was > add two options to strip(1), so that instead of pointing STRIPBIN to > a script that does > > strip -o /usr/local/lib/debug/bin/foo.symbols --only-keep-debug /bin/foo > strip /bin/foo > objcopy --add-gnu-debuglink=3Dfoo.symbols /bin/foo > > I can just use > > STRIPBIN=3D"strip -e --prefix-dir=3D/usr/local/lib/debug" > > Currently, install(1) treats STRIPBIN as a program name; it essentially > does a execve(getenv(STRIPBIN)); my change just has it split any argument= s > into an argv which then can be passed into execve. I'm not sure if this > change might be useful on its own. > > On the whole, I agree that using a script for this is better though. > It'll make things easier to change later on, and it's less work to > maintain - I doubt my changes to strip(1) would be accepted upsteam > anyway, they don't implement any new functionality. Yeah. The Unix philosophy typically aligns itself with simplicity in construction, which isn't always simplicity in execution (that's OSX / Windows / etc). Simplicity in execution typically involves complexity, which can make code tricky and unmanageable longterm... *cough*. >> > I'm not familiar with pmake - I'll take a look into it. >> >> pmake is FreeBSD's make: http://www.freebsd.org/doc/en/books/pmake/ > > Ah... I'm still getting to know FreeBSD. =3D) > I'll take a look through the docs when I have some spare time this > weekend. man make too :) (yes, we have manpages unlike some other Unix clones out there :P..). >> > It took me a while to figure this out, but the absolute path to the >> > debug symbols isn't encoded in the .gnu_debuglink segment - just the >> > filename is placed there. When gdb loads a binary, it searches a >> > predefined set of directories for the file recorded in .gnu_debuglink >> > and loads it if it finds it. One of the directories is global - on >> > FreeBSD it seems to be /usr/local/lib/debug/ by default. You can >> > configure it with >> >> =A0 =A0 Hmmm... didn't realize it all went there. What about cases with >> compat libraries where we need versioning? > > That's a good point. Symbols files for libraries should be named by > version, so that, say, /lib/libc.so.7 would have its gnu_debuglink point > to /usr/local/lib/debug/lib/libc.7.symbols. Is this what you're > referring to? The easiest way to look at this is to install /usr/ports/misc/compat*x ; IronPort (my employer) does some potentially `clever' linker lookup tricks to determine which compat libs to load, but vanilla FreeBSD for the most part jams all of the libs into /usr/local/lib/compat/ -- which unfortunately means that you lose versioning between minor versions of FreeBSD *shrugs*. Anyhow... hope that helps fill in some gaps :). Thanks! -Garrett From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 30 14:41:35 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 E0A0E1065675 for ; Sat, 30 Oct 2010 14:41:35 +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 A0B5F8FC14 for ; Sat, 30 Oct 2010 14:41:35 +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, 30 Oct 2010 10:41:35 -0400 Received: by labgw2.phaedrus.sandvine.com (Postfix, from userid 10332) id BDD2233C00; Sat, 30 Oct 2010 10:41:34 -0400 (EDT) Date: Sat, 30 Oct 2010 10:41:34 -0400 From: Ed Maste To: Mark Johnston Message-ID: <20101030144134.GA35688@sandvine.com> References: <20101029191827.GC1443@mark-laptop-bsd.mark-home> <20101029233900.GC2392@deviant.kiev.zoral.com.ua> <20101030015826.GA1305@mark-laptop-bsd.mark-home> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20101030015826.GA1305@mark-laptop-bsd.mark-home> User-Agent: Mutt/1.4.2.1i Cc: Kostik Belousov , freebsd-hackers@freebsd.org Subject: Re: Generating userland debugging symbols X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 30 Oct 2010 14:41:36 -0000 On Fri, Oct 29, 2010 at 09:58:26PM -0400, Mark Johnston wrote: > On Sat, Oct 30, 2010 at 02:39:00AM +0300, Kostik Belousov wrote: > > I do think that something like this would be useful. But, shouldn't > > the DEBUG_FLAGS be also involved in the patch ? The goal would be > > to have debug symbols for userland staff. esp. the libraries, > > handled in a similar manner to kernel symbols. > > > > But I do like the intent of keeping the symbols in the separate directory. > > Yes, you're right. What I would probably do is have make(1) set > DEBUG_FLAGS=-g automatically if WITH_DEBUG_SYMBOLS is defined in > /etc/src.conf. I've been using the source tree at my work, which > has another Makefile and some other scripts on top of the FreeBSD build > system, so they're probably doing some things I don't know about. Based > on what I've seen however, it shouldn't be too much work to port the > necessary changes over. Ahh yes, the way it was being done (before the change to build .symbols files) is that the buildworld was done using a make.conf with DEBUG_FLAGS=-g while the installworld omitted it; the /usr/obj tree then had the debug information but the installed binaries and libraries did not. It looks like the .symbols change built on top of this. -Ed From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 30 19:27:46 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 06C80106564A for ; Sat, 30 Oct 2010 19:27:46 +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 C20748FC17 for ; Sat, 30 Oct 2010 19:27:45 +0000 (UTC) Received: by iwn39 with SMTP id 39so5150609iwn.13 for ; Sat, 30 Oct 2010 12:27:45 -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:content-type; bh=xMxuSM2qsUgSEqqnX6hzsqkNMip9MHJxktFhzHu1c0A=; b=INU1F7nvm+S8UHd5L4l7qK1pdyRljqu/kL4FQrt/iZ5HlMC0kpBemxJ5Ytg+LCP7pc dWRxqTjhtpIrNi1/Wg9qZDyRXehH6UF8s4+mW77K4rPj661U39Xd3tVzKJQJHhQU60Ry JOjAQAFDUNrGOJBWjX1Xjx3y9/h99Z+JGud7Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=ntf82cwNZigLfmkU3HUFNJc2abVuNj8kYoFn5U/T6T22uNEsMFY13tKyVX/4gfeIaz 9npMAOxosWoFUrudfXdEPPneijSW/aT3QH9l4koI953W5+0LWQX+F7kNCwVcG62KJVpw EoRuAFMJ/OlQfoH4ovg+uynjpIH9ZAfoC8f5E= MIME-Version: 1.0 Received: by 10.42.214.10 with SMTP id gy10mr1052083icb.370.1288464978172; Sat, 30 Oct 2010 11:56:18 -0700 (PDT) Received: by 10.231.38.7 with HTTP; Sat, 30 Oct 2010 11:56:18 -0700 (PDT) Date: Sat, 30 Oct 2010 20:56:18 +0200 Message-ID: From: Harald Servat To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: 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: Sat, 30 Oct 2010 19:27:46 -0000 Hello -hackers, (although this is a network topic, I think this may be the appropiate list to ask. If you think it's not, please, tell me) I'm trying to configure my wifi SSID within /etc/rc.conf in FreeBSD 8.1 amd64 , but I've found that I'm unable to get it working at boot time (although I can do it after boot in cmd line). My SSID has an space character and I don't know how to deal with it. So my question is easy, how do I add an space in the SSID? I've tried wrapping the SSID using \" , \' also adding \(space), changing " for ' and others without success. As an example my rc.conf entry looks like ifconfig_wlan0="ssid SSID WITH SPACE dhcp" and after booting I see that ifconfig tried to connect to SSID instead to "SSID WITH SPACE". As I said, if I run ifconfig wlan0 ssid "SSID WITH SPACE" from the command line, works fine. Any clues on how to solve this in rc.conf? Thank you very much!! -- _________________________________________________________________ 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 Sat Oct 30 20:11:53 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 C510310656FA for ; Sat, 30 Oct 2010 20:11:53 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx23.fluidhosting.com [204.14.89.6]) by mx1.freebsd.org (Postfix) with ESMTP id 5211B8FC15 for ; Sat, 30 Oct 2010 20:11:53 +0000 (UTC) Received: (qmail 32752 invoked by uid 399); 30 Oct 2010 20:11:52 -0000 Received: from localhost (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 30 Oct 2010 20:11:52 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4CCC7C07.8080903@FreeBSD.org> Date: Sat, 30 Oct 2010 13:11:51 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101028 Thunderbird/3.1.6 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Sat, 30 Oct 2010 20:11:53 -0000 On 10/30/10 11:56, Harald Servat wrote: > Hello -hackers, > > (although this is a network topic, I think this may be the appropiate list > to ask. If you think it's not, please, tell me) > > I'm trying to configure my wifi SSID within /etc/rc.conf in FreeBSD 8.1 > amd64 , but I've found that I'm unable to get it working at boot time > (although I can do it after boot in cmd line). > > My SSID has an space character and I don't know how to deal with it. So my > question is easy, how do I add an space in the SSID? I've tried wrapping the > SSID using \" , \' also adding \(space), changing " for ' and others without > success. > > As an example my rc.conf entry looks like > ifconfig_wlan0="ssid SSID WITH SPACE dhcp" > and after booting I see that ifconfig tried to connect to SSID instead to > "SSID WITH SPACE". > > As I said, if I run ifconfig wlan0 ssid "SSID WITH SPACE" from the command > line, works fine. The best solution would be to change the SSID to one without spaces. :) If you can't or won't do that, one of these should work, please report back which one does: ='ssid "ssid with space" DHCP' ='ssid \"ssid with space\" DHCP' ="ssid 'ssid with space' DHCP" ="ssid \'ssid with space\' DHCP" hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 30 21:13: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 04FD2106564A; Sat, 30 Oct 2010 21:13:49 +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 62CD18FC0C; Sat, 30 Oct 2010 21:13:47 +0000 (UTC) Received: by fxm17 with SMTP id 17so4209076fxm.13 for ; Sat, 30 Oct 2010 14:13:47 -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=qCw4dJ25nqCpDnWgENoAkjv10URRWUJNBn4Giz0JJPQ=; b=o+xBK17+00TMkcYbiJMsW9FvoJqmkNGKRjlMQNuOgNiefuOBHwimTPo5FXLT5mxfPQ u8gbLNHP/Oc5LHkKyMP2c3Kf289GaoopezX7PJgS+EJAbq4dSW6kXPzG3LsMlQ/KgVUy 7TYqSgSFkY++fib9PXBwjLkl+P6InpgnrR5/s= 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=QoF+YMHNYhKJIXxE2aBPPLwPZepZGKWUTZyIT4WQbmloSMoTGBqh8Ec3tQd2WkhGua 86wYUQ384w/I1Uu88XAOczCrkbrWg7nt+pAJ3UIhlZlnvDznIdo5ozZaSH+uv8Rf+COK r6qqsqwBHn6pBMG5UPrDbrQdutRAa28vsr4XU= MIME-Version: 1.0 Received: by 10.223.115.130 with SMTP id i2mr4006131faq.1.1288471498831; Sat, 30 Oct 2010 13:44:58 -0700 (PDT) Received: by 10.223.108.194 with HTTP; Sat, 30 Oct 2010 13:44:58 -0700 (PDT) In-Reply-To: <4CCC7C07.8080903@FreeBSD.org> References: <4CCC7C07.8080903@FreeBSD.org> Date: Sat, 30 Oct 2010 15:44:58 -0500 Message-ID: From: Adam Vande More To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org 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: Sat, 30 Oct 2010 21:13:49 -0000 On Sat, Oct 30, 2010 at 3:11 PM, Doug Barton wrote: > On 10/30/10 11:56, Harald Servat wrote: > >> Hello -hackers, >> >> (although this is a network topic, I think this may be the appropiate >> list >> to ask. If you think it's not, please, tell me) >> >> I'm trying to configure my wifi SSID within /etc/rc.conf in FreeBSD 8.1 >> amd64 , but I've found that I'm unable to get it working at boot time >> (although I can do it after boot in cmd line). >> >> My SSID has an space character and I don't know how to deal with it. So >> my >> question is easy, how do I add an space in the SSID? I've tried wrapping >> the >> SSID using \" , \' also adding \(space), changing " for ' and others >> without >> success. >> >> As an example my rc.conf entry looks like >> ifconfig_wlan0="ssid SSID WITH SPACE dhcp" >> and after booting I see that ifconfig tried to connect to SSID instead >> to >> "SSID WITH SPACE". >> >> As I said, if I run ifconfig wlan0 ssid "SSID WITH SPACE" from the >> command >> line, works fine. >> > > The best solution would be to change the SSID to one without spaces. :) > > If you can't or won't do that, one of these should work, please report back > which one does: > > ='ssid "ssid with space" DHCP' > ='ssid \"ssid with space\" DHCP' > ="ssid 'ssid with space' DHCP" > ="ssid \'ssid with space\' DHCP" > I changed the ssid to an ascii representation, and it worked. Can't remember if it was decimal or hex though. -- Adam Vande More From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 30 21:49:17 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 DE0B1106566B for ; Sat, 30 Oct 2010 21:49:16 +0000 (UTC) (envelope-from cronfy@gmail.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 6B5C08FC13 for ; Sat, 30 Oct 2010 21:49:16 +0000 (UTC) Received: by bwz3 with SMTP id 3so3568201bwz.13 for ; Sat, 30 Oct 2010 14:49:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:content-type; bh=8DLMZpKT40AQ+dMoDFwi3597TNrJH60sVlMMDfMkn5c=; b=EuNowpBf94mlDGeCV/iXvW2UgTOHFNJMaeoTDc/5p+gdmGo0Q9wnxudKzqlVIC1bRM qhIIGQorXZiyXfCDbKzmbwiaRIsDjjod2JfDxr2wwppc427xurRw9WQp1CF/B6JlKGUn J+LWoafOuTIGX4R27GzCuSREQqXcrQfujDyZo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=GCG+Rgd/jrcxtpUZbq4SFTcZOKvLO6F+ASfJztTqqgXwcsBu9NbdSh8xgFkGT9lC8I bXsZCHyUwqmfULJdEAUNoWyz/IYfi3PqiigQV7DZd91mNMu3zMdXvqUfbpa3K4Ex5fg4 hC6uWgCHj9q9WcScwIJAgv5XF4k2+aZP5nC7c= Received: by 10.204.137.80 with SMTP id v16mr10624517bkt.46.1288475355310; Sat, 30 Oct 2010 14:49:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.73.135 with HTTP; Sat, 30 Oct 2010 14:48:45 -0700 (PDT) In-Reply-To: References: From: cronfy Date: Sun, 31 Oct 2010 01:48:45 +0400 Message-ID: To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 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: Sat, 30 Oct 2010 21:49:17 -0000 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. Matthew, yes, I know about --bwlimit in rsync, but this will mostly slow down the transfer of data and not stat() operations that are used for comparing files. I afraid bwlimiting will not make any better (I tried it some time ago without success). Daan, thanks for the patch! I will try it. A lot of impact also produced by rm -rf of old backups. I assume that low performance is also related to a large numbers of hardlinks. There was a moment when I had ~15 backups hardlinked by rsync, and rm -rf of single backup was VERY slow and slowed down the server dramatically. I had no choice except installing a new clean disk for backups, limiting number of future backups and issuing a newfs over old backup disk. When there is less number of hardlinked copies, backups cleanup works much better. Can large number of hardlinks produce such an impact on filesystem operations? May be it is possible to increase disk performance somehow? Server has a lot of memory. At this time vfs.ufs.dirhash_maxmem = 67108864 (max monitored value for vfs.ufs.dirhash_mem was 52290119) and kern.maxvnodes = 500000 (max monitored value for vfs.numvnodes was 450567). Can increasing of these (or other) sysctls help? I ask because (as you can see) these tunables are already incremented, and I am not sure further increment really makes sense. 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)... Or, probably, it is possible to limit the IO bandwith for a particular device somehow? I would then limit disk operations for SATA backup disk to prevent it affecting the rest of services that work on SAS mirror. And also, maybe there are other ways to create incremental backups instead of using rsync/hardlinks? I was thinking about generating list of changed files with own script and packing it with tar, but I did not find a way to remove old backups with such an easy way as it is with hardlnks.. Thanks in advance! -- // cronfy From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 30 22:08: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 A1E17106566B; Sat, 30 Oct 2010 22:08:30 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) by mx1.freebsd.org (Postfix) with ESMTP id 652848FC15; Sat, 30 Oct 2010 22:08:30 +0000 (UTC) Received: from turtle.stack.nl (turtle.stack.nl [IPv6:2001:610:1108:5010::132]) by mx1.stack.nl (Postfix) with ESMTP id 9DCF835A852; Sun, 31 Oct 2010 00:08:28 +0200 (CEST) Received: by turtle.stack.nl (Postfix, from userid 1677) id 884FB170C5; Sun, 31 Oct 2010 00:08:28 +0200 (CEST) Date: Sun, 31 Oct 2010 00:08:28 +0200 From: Jilles Tjoelker To: Doug Barton Message-ID: <20101030220828.GA24395@stack.nl> References: <4CCC7C07.8080903@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CCC7C07.8080903@FreeBSD.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hackers@freebsd.org 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: Sat, 30 Oct 2010 22:08:30 -0000 On Sat, Oct 30, 2010 at 01:11:51PM -0700, Doug Barton wrote: > On 10/30/10 11:56, Harald Servat wrote: > > My SSID has an space character and I don't know how to deal with > > it. So my question is easy, how do I add an space in the SSID? > > I've tried wrapping the SSID using \" , \' also adding \(space), > > changing " for ' and others without success. > > As an example my rc.conf entry looks like > > ifconfig_wlan0="ssid SSID WITH SPACE dhcp" > > and after booting I see that ifconfig tried to connect to SSID instead to > > "SSID WITH SPACE". > > As I said, if I run ifconfig wlan0 ssid "SSID WITH SPACE" from > > the command line, works fine. > The best solution would be to change the SSID to one without spaces. :) Well, as mentioned elsewhere in the thread write the SSID in hex. You also need this if *, ? or [ occur in the SSID. > If you can't or won't do that, one of these should work, please report > back which one does: > ='ssid "ssid with space" DHCP' > ='ssid \"ssid with space\" DHCP' > ="ssid 'ssid with space' DHCP" > ="ssid \'ssid with space\' DHCP" This will not work, as the value is stored in a variable and then split on IFS characters by expanding the variable outside quotes. There is no escape mechanism - either the whole variable is split or none of it (if in double-quotes). One workaround would be to set IFS to something not containing , for example , and then delimiting fields with tabs instead of spaces. Apart from the general ugliness all over the rc.confs (including the defaults/ one), breakage would probably also happen in rc.subr and network.subr. Doug's suggestions point to something like eval "set -- ${ifconfig_FOO}" ifconfig $_if "$@" This has potential security issues with arbitrary stuff from untrusted sources (say, some sort of privilege separation where someone may configure the network but not do arbitrary things) in /etc/rc.conf: ifconfig_wlan0='ssid $(chown evilhacker topsecretfile) dhcp' is perfectly safe now, but will be insecure. (Pathname generation may lead to information disclosure, but not executing arbitrary commands.) Also, the syntax for the keywords such as DHCP is too flexible. This currently does not do much harm other than stopping you from using "DHCP" as an ssid or something, but is hard to remove from "$@" in the above code. If they were restricted to appear at the start only, simple comparisons of "$1" and shift would do the job, but removing from the middle requires constructing a string with quoting characters and then using eval on that string. 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 From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 30 22:40:19 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 47E721065694 for ; Sat, 30 Oct 2010 22:40:19 +0000 (UTC) (envelope-from markjdb@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 09F4A8FC08 for ; Sat, 30 Oct 2010 22:40:18 +0000 (UTC) Received: by iwn39 with SMTP id 39so5277355iwn.13 for ; Sat, 30 Oct 2010 15:40:18 -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=gIsK3jNIQqISiGrl2SujRQhrzbXk3XO+b51IugKFQ1E=; b=Evnus5RMj5byt2tUl1JCxHpMjWh6M+AxWtaUNoMVQk2LWQz94apL3o4TDQip83s6AM VkNclrVPv6o/zvQT4v+Ym7uoYv0y967IK4JWI5TAYn5pHlODDVhJflWVuQTf0HUjK8nV zzFlx3HuZ7NPHV1Ak+jFQFvKEp6eEzao/YNKM= 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=Lw+tlZux1ILY18zRVk3o7J7cIYPkqKHvhTaH2VT/WNh5m8FOifhtLX36kcO0aSJxjY vHb2XP5bN2DRftKhEq4tiCXnwmHdSwU31ZUECddzvdGCiPyJS8Yxf2ZUuNqq6Ekerqc5 +PzI02Fskbv5MWOl/KxHfkLVcmYiR0bditTQU= Received: by 10.42.191.139 with SMTP id dm11mr209016icb.391.1288478418336; Sat, 30 Oct 2010 15:40:18 -0700 (PDT) Received: from mark-laptop-bsd.mark-home ([38.112.100.65]) by mx.google.com with ESMTPS id u6sm5829617ibd.0.2010.10.30.15.40.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 30 Oct 2010 15:40:17 -0700 (PDT) Date: Sat, 30 Oct 2010 18:40:01 -0400 From: Mark Johnston To: Jilles Tjoelker Message-ID: <20101030224001.GA10529@mark-laptop-bsd.mark-home> References: <4CCC7C07.8080903@FreeBSD.org> <20101030220828.GA24395@stack.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101030220828.GA24395@stack.nl> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hackers@freebsd.org 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: Sat, 30 Oct 2010 22:40:19 -0000 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 From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 30 22:48:48 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 D301C106566B for ; Sat, 30 Oct 2010 22:48:48 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.freebsd.org (Postfix) with ESMTP id 3743A8FC16 for ; Sat, 30 Oct 2010 22:48:48 +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 o9UMb1YG032372; Sat, 30 Oct 2010 15:37:01 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.14.4/8.13.4/Submit) id o9UMb157032371; Sat, 30 Oct 2010 15:37:01 -0700 (PDT) Date: Sat, 30 Oct 2010 15:37:01 -0700 (PDT) From: Matthew Dillon Message-Id: <201010302237.o9UMb157032371@apollo.backplane.com> To: cronfy References: 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: Sat, 30 Oct 2010 22:48:49 -0000 :Thank you all for the answers. : :.. :A lot of impact also produced by rm -rf of old backups. I assume that :low performance is also related to a large numbers of hardlinks. There :was a moment when I had ~15 backups hardlinked by rsync, and rm -rf of Yes, hardlinked backups pretty much destroy performance, mainly because it destroys all locality of reference on the storage media when files are slowly modified and get their own copies, mixed with other 'old' files which have not been modified. But theoretically that should only effect the backup target storage and not the server's production storage. Here is what I would suggest: Move the backups off the production machine and onto another totally separate machine, then rsync between the two machines. That will solve most of your problems I think. If the backup disk is a single drive then just use a junk box lying around somewhere for your backup system with the disk installed in it. -- The other half of the problem is the stat()ing of every single file on the production server (whether via local rsync or remote rsync). If your original statement is accurate and you have in excess of 11 million files then the stat()ing will likely force the system vnode cache on the production system to cycle, whether it has a max of 100,000 or 500,000... doesn't matter, it isn't 11 million so it will cycle. This in turn will tend to cause the buffer and VM page caches (which are linked to the vnode cache) to get blown away as well. The vnode cache should have code to detect stat() style accesses and avoid blowing away unrelated cached vnodes which have cached data associated with them, but it's kinda hit-or-miss how well that works. It is very hard to tune those sorts of algorithms and when one is talking about a inode:cache ratio of 22:1 even a good algorithm will tend to break down. Generally speaking when caches become inefficient server throughput goes to hell. You go from e.g. 10uS to access a file to 6mS to access a file, a 1:600 loss. :May be it is possible to increase disk performance somehow? Server has :a lot of memory. At this time vfs.ufs.dirhash_maxmem = 67108864 (max :monitored value for vfs.ufs.dirhash_mem was 52290119) and :kern.maxvnodes = 500000 (max monitored value for vfs.numvnodes was :450567). Can increasing of these (or other) sysctls help? I ask :because (as you can see) these tunables are already incremented, and I :am not sure further increment really makes sense. I'm not sure how this can be best dealt with in FreeBSD. If you are using ZFS it should be possible to localize or cache the meta-data associated with those 11 million+ files in some very fast storage (i.e. like a SSD). Doing so will make the stat() portion of the rsync go very fast (getting it over with as quickly as possible). With UFS the dirhash stuff only caches the directory entries, not the inode contents (though I'm not 100% positive on that), so it won't help much. The directory entries are already linear and unless you have thousands of files in each directory ufs dirhash will not save much in the way of I/O. :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)... No, unfortunately there isn't much you can do about this due to the fact that the files are hardlinked, other than moving the backup storage entirely off the production server or otherwise determining why disk I/O to the backup storage is effecting your primary storage and hacking a fix. The effect could be indirect... the accesses to the backup storage are blowing away the system caches and causing the production storage to get overloaded with I/O. I don't think there is an easy solution other than to move the work off the production server entirely. :And also, maybe there are other ways to create incremental backups :instead of using rsync/hardlinks? I was thinking about generating :list of changed files with own script and packing it with tar, but I :did not find a way to remove old backups with such an easy way as it :is with hardlnks.. : :Thanks in advance! :... :-- :// cronfy Yes. Use snapshots. ZFS is probably your best bet here in FreeBSDland as ZFS not only has snapshots it also has a streaming backup feature that you can use to stream changes from one ZFS filesystem (i.e. on your production system) to another (i.e. on your backup system). Both the production system AND the backup system would have to be running ZFS to make proper use of the feature. But before you start worrying about all of that I suggest taking the first step, which is to move the backups entirely off the production system. There are many ways to handle LAN backups. My personal favorite (which doesn't help w/ the stat problem but which is easy to set up) is for the backup system to NFS mount the production system and periodically 'cpdup' the production system's filesystems over to the backup system. Then create a snapshot (don't use hardlinks), and repeat. As a fringe benefit the backup system does not have to rely on backup management scripts running on the production system... i.e. the production system can be oblivious to the mechanics of the backup. And with NFS's (NFSv3 here) rdirplus scanning the production filesystem via NFS should go pretty quickly. It is possible for files to be caught mid-change but also fairly easy to detect the case if it winds up being a problem. And, of course, more sophisticated methodologies can be built on top. -Matt Matthew Dillon