From owner-freebsd-hackers@freebsd.org Sun Mar 5 02:30:27 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ECEC3CF76A4 for ; Sun, 5 Mar 2017 02:30:27 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AD0AF19CB for ; Sun, 5 Mar 2017 02:30:27 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: by mail-qk0-x233.google.com with SMTP id 1so110051184qkl.3 for ; Sat, 04 Mar 2017 18:30:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=QtVVJaSyHa8vnM1wFt4hNw94ipF4YieCjV3JwYbHANU=; b=VRgz88RqeLdECZ8u70jujn9nW6F8eDs/w1tc7MzruWAZMjwRBK2h/DlYq+dillgBG/ aPDDNf0V5Bo+SHG9aVcZkVuiPftsXEuHSzz8laIFOGv9T3B6Pi4nQsPY2YpOK0cjqx5d 42Hrdp1lFafymiVgMqUn9ZAJhTVxGbkRcrni4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=QtVVJaSyHa8vnM1wFt4hNw94ipF4YieCjV3JwYbHANU=; b=HLrqUDT+GH0Ovqik61wvXekPQLE0PW5pGooklB2TQ1DMHeczR0iNE019a53x3AocSe WFnNOn1pECizWeN6oItbFMuGnecoVSutOawnA1Jk7JfQ1mT0ZJhAJTEGoumKEJsJpXq3 kWO5uZNpKTRt4cm3Zi1Xm6pHQMrxLDvSSZEE+4d/bi9sFIWxWigLYILSxm028KcrQo/m jNc7iuePADP9f2jYP44kj4TuxPWbt+5TMz5goVuvLZC6q7db/UDJQRRaGLRcWVCpuys+ 3lROL2dcoC/aayH+CwhL37zI1B5a8qyi0szoOX6xz5VY+kS2Df4QU3RrqAycN7NQ2A+Z 8TPQ== X-Gm-Message-State: AMke39n7bHRpmzvjtfizCaTKj/9Jy44CVZ1sZu1jOUQBoDe+xeoodT9gWEVpVFQdlXwmVQ== X-Received: by 10.55.113.134 with SMTP id m128mr3379152qkc.208.1488681026744; Sat, 04 Mar 2017 18:30:26 -0800 (PST) Received: from [192.168.0.11] ([186.236.217.98]) by smtp.googlemail.com with ESMTPSA id k51sm9327122qtf.31.2017.03.04.18.30.25 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 04 Mar 2017 18:30:26 -0800 (PST) To: "freebsd-hackers@freebsd.org" From: =?UTF-8?B?T3RhY8OtbGlv?= Subject: Simple program immediately killed when running on a NFS Message-ID: Date: Sat, 4 Mar 2017 23:29:57 -0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2017 02:30:28 -0000 Dears I'm trying to compile a simple hello world program on my RPI3. The program is on a directory mounted using NFS and stored in the amd64 machine. When I compile and try to run the program in the NFS mounted path it does not work, when I copy the same program to a local dir it work, and then when I copy the program from the local dir to the NFS dir it works !? !?!?! Someone can, please, explain it? Look at the historic program. root@rpi3:/usr/ports/benchmarks/netperf/work/netperf-2.7.0 # cc -o conftest conftest.c root@rpi3:/usr/ports/benchmarks/netperf/work/netperf-2.7.0 # ./conftest Killed root@rpi3:/usr/ports/benchmarks/netperf/work/netperf-2.7.0 # cp conftest /usr/home/ota/conftest root@rpi3:/usr/ports/benchmarks/netperf/work/netperf-2.7.0 # /usr/home/ota/conftest Hello world! root@rpi3:/usr/ports/benchmarks/netperf/work/netperf-2.7.0 # cp /usr/home/ota/conftest ./conftest root@rpi3:/usr/ports/benchmarks/netperf/work/netperf-2.7.0 # ./conftest Hello world! root@rpi3:/usr/ports/benchmarks/netperf/work/netperf-2.7.0 # mount /dev/mmcsd0s2a on / (ufs, local, noatime, journaled soft-updates, nfsv4acls) devfs on /dev (devfs, local, multilabel) /dev/mmcsd0s1 on /boot/efi (msdosfs, local, noatime) /dev/md0 on /tmp (ufs, local, noatime, soft-updates) /dev/md1 on /var/log (ufs, local, noatime, soft-updates) /dev/md2 on /var/tmp (ufs, local, noatime, soft-updates) squitch:/usr/ports on /usr/ports (nfs) Thanks a lot! []'s -Otacílio From owner-freebsd-hackers@freebsd.org Sun Mar 5 09:48:54 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2EB73CF90A9 for ; Sun, 5 Mar 2017 09:48:54 +0000 (UTC) (envelope-from emorrasg@yahoo.es) Received: from nm40-vm1.bullet.mail.ir2.yahoo.com (nm40-vm1.bullet.mail.ir2.yahoo.com [212.82.97.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A3874126C for ; Sun, 5 Mar 2017 09:48:53 +0000 (UTC) (envelope-from emorrasg@yahoo.es) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.es; s=s2048; t=1488707215; bh=Ui8IjuEj5kFE0gmO/4f70YiplxXn8/pBRXw1Nxj30xg=; h=Date:From:To:Subject:In-Reply-To:References:From:Subject; b=WpE6BqbncmeAFSSXCu0gsMz4MBjOaEmsFZtO7tqZGkcN3d41XIyr3iamfXLLJkzKn/S/u6Tz8cT6A9YvLkel+wwjOjwzV+g4d3XJKfYWQTrTno/4kwf3OcVV4C2pBkpUDRHjXmgqVnjexlYn4b9YrJGFYDCxeLjMxllO+ppNioOnju+9xqiTuu2Cg3+Jt89wgpAF0H+7xV+z9rPYgjLfZ0rQaWf4f+7trYXxO4D4CI7kC3U1UuKR8QwhDtgPGfYDtcDICERVUqbbV5r3UK2vkv0UV5bqVreosB0ZFhwe8IMe/AmawgvcqS+ml1iFnlVhxqO2VzkqWAIhnL5Vc/kYhA== Received: from [212.82.98.126] by nm40.bullet.mail.ir2.yahoo.com with NNFMP; 05 Mar 2017 09:46:55 -0000 Received: from [46.228.39.77] by tm19.bullet.mail.ir2.yahoo.com with NNFMP; 05 Mar 2017 09:46:55 -0000 Received: from [127.0.0.1] by smtp114.mail.ir2.yahoo.com with NNFMP; 05 Mar 2017 09:46:55 -0000 X-Yahoo-Newman-Id: 872871.78901.bm@smtp114.mail.ir2.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: VJv3svcVM1nGBNhHKSKPalHW8Gx00R3eWLWkvrko5lypZiu QN_B8P0g7pI1ATFvN9o1fP8xALdBX0ih5v.LFBDA5mT3pdV4BjbFzH4gJ8mJ _0Nqm8bxkEQdArUcjlfnLtpdZib804ZXWk7M7CYLb3G9vLt4jNxfGcQV75x. qiFRwmLg8q_XEJTIZYkzSykgGSVmZjq22mfpU821zi69Plpn7wAgL7LbDxP2 QcfCF9WaovfDowgj4UHY.9Z_YB7yCyWA64kqEh4dr.0zM8pQd.63qEx56fZj FaoTMx7rga6Dvp7dkUFFpVUheQFxnKUa.IEhanPI88bbDbSMRoPa.AEVEVtr dhSyaeq.sq0MKoS9bxAIva_e67oB8FYq8q00zleWdh8iolkkOuM36Ix95tNe FPw53vpu8P6PyWKBL7zgFhPVhkO.9kmD73ajVWOP_2uNnXCu_1Ul2aRzsZy2 D79Nx5d_3Be5IeanlWCXSXPCBzEHBKqVcJW9hPtpO48xpOJ8QrUqm8N7Ps5O 2wRqaBWr416_FOqUuaPrNHRqSGGKTtbo4zLj.9lJg9CImvVz4UMaJAV6nIOo Z X-Yahoo-SMTP: mX392iiswBAeJNdO_s.EW62LZDJR Date: Sun, 5 Mar 2017 10:48:32 +0100 From: Eduardo Morras To: freebsd-hackers@freebsd.org Subject: Re: Simple program immediately killed when running on a NFS Message-Id: <20170305104832.56d4e358bc968c4e03eca2b2@yahoo.es> In-Reply-To: References: X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2017 09:48:54 -0000 On Sat, 4 Mar 2017 23:29:57 -0300 Otac=EDlio wrote: > Dears >=20 > I'm trying to compile a simple hello world program on my RPI3. The=20 > program is on a directory mounted using NFS and stored in the amd64=20 > machine. When I compile and try to run the program in the NFS mounted=20 > path it does not work, when I copy the same program to a local dir it=20 > work, and then when I copy the program from the local dir to the NFS > dir it works !? !?!?! Someone can, please, explain it? Look at the > historic program. I assume you crosscompiled it to arm, but .. DId you static linked it? If n= ot, it gets requiered .so from nfs server and crash, becuase they are amd64= binary. --- --- Eduardo Morras From owner-freebsd-hackers@freebsd.org Sun Mar 5 10:10:03 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CA654CF97EB for ; Sun, 5 Mar 2017 10:10:03 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8E6BE1D4C for ; Sun, 5 Mar 2017 10:10:03 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: by mail-qk0-x230.google.com with SMTP id n127so234839761qkf.0 for ; Sun, 05 Mar 2017 02:10:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=7p2AOThBXphP/bfzOwgKkqhxhs1Qt0WTXihD3VQTN7M=; b=PMlNnB6RSZcNLbmN40XplaOR7lYK596W/Osk0GOSGeAV8A8yU7CM7ar84igjg/sN3S wV/7RSO+I8CU4hLE304w+XHGBcAw+Ck0PE+OSsBfBs2hMfkyWMxvZ+XSTQ0J87f+dyKI hApoyzHGnCuUOCRem+/oDoYXQFaQlM2fWX3P0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=7p2AOThBXphP/bfzOwgKkqhxhs1Qt0WTXihD3VQTN7M=; b=YwTi1jLMieqkvZbAL76B8DObr4fYOZS9jTBRLrSHOWey7RSHpJ41yqWMzajqUpSthW yIG4g5gKVQE/n278yqkg7mdOp1VW/DPasotUJV5PDzw90thQqGIgvgIsaoPI0xruwX8f lvwNkAcEhdBGgxGtWXH5YBH7pJq040S6skqLNW34kQcbZ+Oa8Z3/8WTadcZWGRbct73D eDN96B8sZjP8SqwlBNF0eB/fIAj8T9zyW6S81exT7Z8H0jx9WI9gXdpRprKG+VC3IfTX Ww8spKX6fN4koztPhrLBK8magIfpFsIaaOPY7Io+DWFsgmnlmJ6Zr+zTfPsePJz55Q1G Wuug== X-Gm-Message-State: AMke39mUawYvYadC+jWW9LrYtJZBxZzHtmk8DYId6xxmcB5oYqYqFC/9U7WZ4UDv1EAfgw== X-Received: by 10.55.104.134 with SMTP id d128mr9816486qkc.86.1488708602300; Sun, 05 Mar 2017 02:10:02 -0800 (PST) Received: from [192.168.0.11] ([186.236.217.98]) by smtp.googlemail.com with ESMTPSA id l6sm3556583qkd.66.2017.03.05.02.10.01 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 05 Mar 2017 02:10:01 -0800 (PST) Subject: Re: Simple program immediately killed when running on a NFS To: freebsd-hackers@freebsd.org References: <20170305104832.56d4e358bc968c4e03eca2b2@yahoo.es> From: =?UTF-8?B?T3RhY8OtbGlv?= Message-ID: Date: Sun, 5 Mar 2017 07:09:27 -0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <20170305104832.56d4e358bc968c4e03eca2b2@yahoo.es> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2017 10:10:03 -0000 Em 05/03/2017 06:48, Eduardo Morras via freebsd-hackers escreveu: > On Sat, 4 Mar 2017 23:29:57 -0300 > Otacílio wrote: > >> Dears >> >> I'm trying to compile a simple hello world program on my RPI3. The >> program is on a directory mounted using NFS and stored in the amd64 >> machine. When I compile and try to run the program in the NFS mounted >> path it does not work, when I copy the same program to a local dir it >> work, and then when I copy the program from the local dir to the NFS >> dir it works !? !?!?! Someone can, please, explain it? Look at the >> historic program. > I assume you crosscompiled it to arm, but .. DId you static linked it? If not, it gets requiered .so from nfs server and crash, becuase they are amd64 binary. > > > I'm not compiling using the server tools. I'm compiling using the RPI3 tools inside the RPI3. The server is only exporting the /usr/ports. I mounted this on PRI3 /usr/ports and I'm compiling using the RPI3 clang. On this same scenario, when using a BBB this works. []s -Otacilio From owner-freebsd-hackers@freebsd.org Sun Mar 5 11:25:55 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8B667CF9481 for ; Sun, 5 Mar 2017 11:25:55 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from fry.fubar.geek.nz (fry.fubar.geek.nz [139.59.165.16]) by mx1.freebsd.org (Postfix) with ESMTP id 4B7141E36; Sun, 5 Mar 2017 11:25:54 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from [IPv6:2a02:c7f:1e13:cf00:90a0:2138:1383:27fb] (unknown [IPv6:2a02:c7f:1e13:cf00:90a0:2138:1383:27fb]) by fry.fubar.geek.nz (Postfix) with ESMTPSA id 67B134E648; Sun, 5 Mar 2017 11:25:48 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Simple program immediately killed when running on a NFS From: Andrew Turner In-Reply-To: Date: Sun, 5 Mar 2017 11:25:47 +0000 Cc: freebsd-hackers@freebsd.org, rmacklem@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <1E759624-BA9B-4039-8E70-711D7435EB4B@fubar.geek.nz> References: <20170305104832.56d4e358bc968c4e03eca2b2@yahoo.es> To: =?utf-8?B?T3RhY8OtbGlv?= X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2017 11:25:55 -0000 > On 5 Mar 2017, at 10:09, Otac=C3=ADlio = wrote: >=20 > Em 05/03/2017 06:48, Eduardo Morras via freebsd-hackers escreveu: >> On Sat, 4 Mar 2017 23:29:57 -0300 >> Otac=C3=ADlio wrote: >>=20 >>> Dears >>>=20 >>> I'm trying to compile a simple hello world program on my RPI3. The >>> program is on a directory mounted using NFS and stored in the amd64 >>> machine. When I compile and try to run the program in the NFS = mounted >>> path it does not work, when I copy the same program to a local dir = it >>> work, and then when I copy the program from the local dir to the NFS >>> dir it works !? !?!?! Someone can, please, explain it? Look at the >>> historic program. >> I assume you crosscompiled it to arm, but .. DId you static linked = it? If not, it gets requiered .so from nfs server and crash, becuase = they are amd64 binary. >>=20 >>=20 >>=20 >=20 > I'm not compiling using the server tools. I'm compiling using the RPI3 = tools inside the RPI3. The server is only exporting the /usr/ports. I = mounted this on PRI3 /usr/ports and I'm compiling using the RPI3 clang. = On this same scenario, when using a BBB this works. I=E2=80=99ve seen this on a ThunderX in the netsurf cluster. It seems to = be getting the check in [1] (CC=E2=80=99d the author of said code). = Building as a static binary doesn=E2=80=99t affect it. I=E2=80=99ve added debugging to & found np->n_mtime and = np->n_vattr.na_mtime can be out by up to a few seconds. Even when the = second is the same, the tv_nsec value are different, however I don=E2=80=99= t know the nfs code well enough to know where these values come from. Andrew [1] http://fxr.watson.org/fxr/source/fs/nfsclient/nfs_clbio.c#L1633= From owner-freebsd-hackers@freebsd.org Sun Mar 5 16:54:33 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E2AC5CFA537 for ; Sun, 5 Mar 2017 16:54:33 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C2ED1100C; Sun, 5 Mar 2017 16:54:33 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1235) id 1E4677999; Sun, 5 Mar 2017 16:54:33 +0000 (UTC) Date: Sun, 5 Mar 2017 17:54:32 +0100 From: Baptiste Daroussin To: rgrimes@freebsd.org Cc: freebsd-hackers@freebsd.org Subject: Re: svn commit: r314693 - head/usr.sbin/rmt Message-ID: <20170305165432.zkv3vifhoxeo5f7d@ivaldir.net> References: <20170305134226.px4ivdtjjppbgiyf@ivaldir.net> <201703051626.v25GQWNd083561@pdx.rh.CN85.dnsmgr.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2s4snrmstqz6e4ci" Content-Disposition: inline In-Reply-To: <201703051626.v25GQWNd083561@pdx.rh.CN85.dnsmgr.net> User-Agent: NeoMutt/20170225 (1.8.0) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2017 16:54:34 -0000 --2s4snrmstqz6e4ci Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Mar 05, 2017 at 08:26:32AM -0800, Rodney W. Grimes wrote: > Moved thread to -hackers for a quick discussion. >=20 > > On Sun, Mar 05, 2017 at 05:19:28AM -0800, Rodney W. Grimes wrote: > > > -- Start of PGP signed section. > > > > On Sun, Mar 05, 2017 at 04:09:18AM +0000, Rodney W. Grimes wrote: > > > > > Author: rgrimes > > > > > Date: Sun Mar 5 04:09:18 2017 > > > > > New Revision: 314693 > > > > > URL: https://svnweb.freebsd.org/changeset/base/314693 > > > > >=20 > > > > > Log: > > > > > Change /etc/rmt symlink from absolute to relative path, > > > > > correcting the mistake made in r6499 > > > > > =20 > > > > > Approved by: grehan > > > > > MFC after: 1 week > > > > >=20 > > > > > Modified: > > > > > head/usr.sbin/rmt/Makefile > > > > >=20 > > > > > Modified: head/usr.sbin/rmt/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=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > > > > > --- head/usr.sbin/rmt/Makefile Sun Mar 5 04:02:47 2017 (r314692) > > > > > +++ head/usr.sbin/rmt/Makefile Sun Mar 5 04:09:18 2017 (r314693) > > > > > @@ -7,6 +7,6 @@ MAN=3D rmt.8 > > > > > # called from /usr/src/etc/Makefile > > > > > etc-rmt: > > > > > rm -f ${DESTDIR}/etc/rmt > > > > > - ln -s ${BINDIR}/rmt ${DESTDIR}/etc/rmt > > > > > + ln -s ..${BINDIR}/rmt ${DESTDIR}/etc/rmt > > > >=20 > > > > I think this should be ${INSTALL_RSYMLINK} ${BINDIR}/rmt ${DESTDIR}= /etc/rmt > > >=20 > > > find /usr/src | xargs grep INSTALL_RSYM > > > (no results) > > >=20 > > > Sorry, no prior work does this, perhaps once I get done sweeping the > > > absolutes out of the tree (about 10 or 15 IIRC) a pass can be made to > > > sweep all ln -s out and propage this internal bsd.lib.mk function out > > > to the rest of the source tree? > >=20 > > There is also no Makefiles that do ls -sf directly beside that one. > Unless I have missed a commit: > ./crypto/openssh/contrib/cygwin/Makefile: cd $(DESTDIR)$(mandir)/ma= n1 && ln -s ssh.1.gz slogin.1.gz This is withing contrib hence not used to build > ./usr.sbin/sendmail/Makefile: ln -sf ${.ALLSRC} ${.TARGET} This is different this is a built time > ./usr.sbin/rmt/Makefile: ln -s ${BINDIR}/rmt ${DESTDIR}/etc/rmt This one is the one we are speaking about :) > ... > A summary is there are 50 instances of ln -sf, 28 other variants of ln -= s, > and 5 ln -fs. I did not search for other permutaions of ln and s f optio= ns. >=20 >=20 > > INSTALL_RSYMLINK has exactly be done to be use everywhere it is needed.= (I wrote > > it for that exact reason :)) >=20 > Wonderful!! I'll investigate a sweep to finish implementing this tree wi= de > in my spare time.... I notice that SYMLINKS=3D is hard coded to use > INSTALL_SYMLINKS so that can't be used to fix some of these. > How would you propose I proceed in that area?? Thank you >=20 > And investigation into using INSTALL_RSYMLINK in SYMLINKS=3D should be do= ne, > I can not think of a reason when you DONT want a relative link installed, > but I may be missing some new odd use for symlinks by the FreeBSD base > system. Actually when I implemented INSTALL_RSYMLINK the goal I was targetting was having all the library built in a way we have by default a usable sysroot. Then I planned to sweep on all other use cases but somehow never did it. > > >=20 > > > find /usr/share/mk/ | xargs grep INSTALL_RSYM > > > /usr/share/mk/bsd.own.mk:INSTALL_RSYMLINK?=3D ${INSTALL} ${RSYMLI= NK} > > > /usr/share/mk/bsd.lib.mk: ${INSTALL_RSYMLINK} ${TAG_ARGS:D${TAG= _ARGS},development} ${SHLIB_NAME} ${DESTDIR}${_LIBDIR}/${SHLIB_LINK} > > > /usr/share/mk/bsd.lib.mk: ${INSTALL_RSYMLINK} ${TAG_ARGS} ${DES= TDIR}${_SHLIBDIR}/${SHLIB_NAME} \ > > > /usr/share/mk/bsd.lib.mk: ${INSTALL_RSYMLINK} ${TAG_ARGS:D${TAG= _ARGS},development} ${DESTDIR}${_SHLIBDIR}/${SHLIB_NAME} \ > > > /usr/share/mk/bsd.lib.mk: ${INSTALL_RSYMLINK} ${TAG_ARGS} ${DES= TDIR}${_SHLIBDIR}/${SHLIB_NAME} \ > > >=20 > > > This is called from within bsd.lib.mk only, do we want to use this for > > > all symbolics links in the source tree? If so I would of though the > > > person adding this functionality to the .mk files would of made > > > a tree sweeping looking for that and making those changes as well. > >=20 > > When I did it only bsd.lib.mk was using it iirc >=20 > And that appears to still be the case. >=20 > > > > The rm -f before can then be removed, the symlink will be relative = and the > > > > METALOG will be respected=20 > > >=20 > > > METALOG? The only documentation I can find on this seems to be part = of > > > src/tootls/tools/makeroot.8. > > >=20 > > > It appears that something in Makefile.inc uses it and there are refer= ences > > > to it in etc/Makefile. > > >=20 > > > Where is this METALOG documented? =20 > >=20 > > It is really badly documented and should be :( it is a mtree file that = is > > generated when built is done via -DNO_ROOT for the purpose of being abl= e to > > generate disk with makefs as a user > >=20 > > I have reused it for packaging base. > >=20 > > This was designed IIRC by adrian and brooks iirc. > >=20 > > Embedded people relies a lot on it. > > Everything not going though the install(1) command is not tracked that = is why > > this is an issue. >=20 > I guess then that these 83 things I have found are not so important to th= em? Having an embedded system using /etc/rmt is probably something you don't fi= nd often :) That said, it is very import for packaging base. >=20 > Lets take this to -hackers, discuss it where it should be, and get it fix= ed. Best regards, Bapt --2s4snrmstqz6e4ci Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEgOTj3suS2urGXVU3Y4mL3PG3PloFAli8QsQACgkQY4mL3PG3 PloPJxAA1NPVcQF29XJgq6cUrC76RF2E9E+7oRUqGeCPylRR0NtDCDdIc3CJIWyB CX5/TTh0lJ95OOQrCUxhuatRv2SSUHo4Q2XYxET5sSBZxzbHswFoyVMyosKUGNyV gd97ruPmXasbLlIrhL8mpDdxWdtPE81PwZvOgOPaG4iXhz88KsaCws3zSYtSAFwJ 6s2Nslo64WUIQQXND5U9KosX/14Nqz/lJfV4hkVibgE7Xl9/htM6X+4znPgNmuvQ /IlS0DzqavTpXDurKnm+4BMunCjiZZi+p+oFiyHFX4QimMy9cMShkIbU2el8OB53 z82qT84cn5VeSmCFYo8knryZUW0zM4bBN/lYOCSaTgRnO7iajjQJoFsQzIDc6oAK T5/NAkZOCD47qj+UCcjlB0eXxgu3zdIwl83Cab/Lreqd1m++2qkTTmhQuOHtz+/M 1D9uvb1O8u44U/3wAL+4RICk4JmmY32lYNIDOW+NSPeVsNwg2mlbefp61UcqVmcS quqLiwhBoFqRl5ZyzcCCb0mTgV99lhljZuYO3Ao3QP4hJJ26G02xwapu42Ibb/ms npFG6DAZi8E+P5phCz150+QdCERbxgjTaiZ4+3PUcxmI7eRbQI/diLOUXZ1uDqGc u+TxmrBWvOsTSP+472sNnyZ1NgsqZVIHa/1NMtqmQ+wMKWvRABY= =fuLx -----END PGP SIGNATURE----- --2s4snrmstqz6e4ci-- From owner-freebsd-hackers@freebsd.org Sun Mar 5 16:26:38 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 164ACCFABED; Sun, 5 Mar 2017 16:26:38 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8624A1CE7; Sun, 5 Mar 2017 16:26:37 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id v25GQYli083562; Sun, 5 Mar 2017 08:26:34 -0800 (PST) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id v25GQWNd083561; Sun, 5 Mar 2017 08:26:32 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <201703051626.v25GQWNd083561@pdx.rh.CN85.dnsmgr.net> Subject: Re: svn commit: r314693 - head/usr.sbin/rmt In-Reply-To: <20170305134226.px4ivdtjjppbgiyf@ivaldir.net> To: Baptiste Daroussin Date: Sun, 5 Mar 2017 08:26:32 -0800 (PST) CC: freebsd-hackers@freebsd.org Reply-To: rgrimes@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Sun, 05 Mar 2017 17:30:16 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2017 16:26:38 -0000 Moved thread to -hackers for a quick discussion. > On Sun, Mar 05, 2017 at 05:19:28AM -0800, Rodney W. Grimes wrote: > > -- Start of PGP signed section. > > > On Sun, Mar 05, 2017 at 04:09:18AM +0000, Rodney W. Grimes wrote: > > > > Author: rgrimes > > > > Date: Sun Mar 5 04:09:18 2017 > > > > New Revision: 314693 > > > > URL: https://svnweb.freebsd.org/changeset/base/314693 > > > > > > > > Log: > > > > Change /etc/rmt symlink from absolute to relative path, > > > > correcting the mistake made in r6499 > > > > > > > > Approved by: grehan > > > > MFC after: 1 week > > > > > > > > Modified: > > > > head/usr.sbin/rmt/Makefile > > > > > > > > Modified: head/usr.sbin/rmt/Makefile > > > > ============================================================================== > > > > --- head/usr.sbin/rmt/Makefile Sun Mar 5 04:02:47 2017 (r314692) > > > > +++ head/usr.sbin/rmt/Makefile Sun Mar 5 04:09:18 2017 (r314693) > > > > @@ -7,6 +7,6 @@ MAN= rmt.8 > > > > # called from /usr/src/etc/Makefile > > > > etc-rmt: > > > > rm -f ${DESTDIR}/etc/rmt > > > > - ln -s ${BINDIR}/rmt ${DESTDIR}/etc/rmt > > > > + ln -s ..${BINDIR}/rmt ${DESTDIR}/etc/rmt > > > > > > I think this should be ${INSTALL_RSYMLINK} ${BINDIR}/rmt ${DESTDIR}/etc/rmt > > > > find /usr/src | xargs grep INSTALL_RSYM > > (no results) > > > > Sorry, no prior work does this, perhaps once I get done sweeping the > > absolutes out of the tree (about 10 or 15 IIRC) a pass can be made to > > sweep all ln -s out and propage this internal bsd.lib.mk function out > > to the rest of the source tree? > > There is also no Makefiles that do ls -sf directly beside that one. Unless I have missed a commit: ./crypto/openssh/contrib/cygwin/Makefile: cd $(DESTDIR)$(mandir)/man1 && ln -s ssh.1.gz slogin.1.gz ./usr.sbin/sendmail/Makefile: ln -sf ${.ALLSRC} ${.TARGET} ./usr.sbin/rmt/Makefile: ln -s ${BINDIR}/rmt ${DESTDIR}/etc/rmt ... A summary is there are 50 instances of ln -sf, 28 other variants of ln -s, and 5 ln -fs. I did not search for other permutaions of ln and s f options. > INSTALL_RSYMLINK has exactly be done to be use everywhere it is needed. (I wrote > it for that exact reason :)) Wonderful!! I'll investigate a sweep to finish implementing this tree wide in my spare time.... I notice that SYMLINKS= is hard coded to use INSTALL_SYMLINKS so that can't be used to fix some of these. How would you propose I proceed in that area?? And investigation into using INSTALL_RSYMLINK in SYMLINKS= should be done, I can not think of a reason when you DONT want a relative link installed, but I may be missing some new odd use for symlinks by the FreeBSD base system. > > > > find /usr/share/mk/ | xargs grep INSTALL_RSYM > > /usr/share/mk/bsd.own.mk:INSTALL_RSYMLINK?= ${INSTALL} ${RSYMLINK} > > /usr/share/mk/bsd.lib.mk: ${INSTALL_RSYMLINK} ${TAG_ARGS:D${TAG_ARGS},development} ${SHLIB_NAME} ${DESTDIR}${_LIBDIR}/${SHLIB_LINK} > > /usr/share/mk/bsd.lib.mk: ${INSTALL_RSYMLINK} ${TAG_ARGS} ${DESTDIR}${_SHLIBDIR}/${SHLIB_NAME} \ > > /usr/share/mk/bsd.lib.mk: ${INSTALL_RSYMLINK} ${TAG_ARGS:D${TAG_ARGS},development} ${DESTDIR}${_SHLIBDIR}/${SHLIB_NAME} \ > > /usr/share/mk/bsd.lib.mk: ${INSTALL_RSYMLINK} ${TAG_ARGS} ${DESTDIR}${_SHLIBDIR}/${SHLIB_NAME} \ > > > > This is called from within bsd.lib.mk only, do we want to use this for > > all symbolics links in the source tree? If so I would of though the > > person adding this functionality to the .mk files would of made > > a tree sweeping looking for that and making those changes as well. > > When I did it only bsd.lib.mk was using it iirc And that appears to still be the case. > > > The rm -f before can then be removed, the symlink will be relative and the > > > METALOG will be respected > > > > METALOG? The only documentation I can find on this seems to be part of > > src/tootls/tools/makeroot.8. > > > > It appears that something in Makefile.inc uses it and there are references > > to it in etc/Makefile. > > > > Where is this METALOG documented? > > It is really badly documented and should be :( it is a mtree file that is > generated when built is done via -DNO_ROOT for the purpose of being able to > generate disk with makefs as a user > > I have reused it for packaging base. > > This was designed IIRC by adrian and brooks iirc. > > Embedded people relies a lot on it. > Everything not going though the install(1) command is not tracked that is why > this is an issue. I guess then that these 83 things I have found are not so important to them? Lets take this to -hackers, discuss it where it should be, and get it fixed. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Sun Mar 5 17:24:24 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 21A4BCFAC93 for ; Sun, 5 Mar 2017 17:24:24 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DA7811E9D for ; Sun, 5 Mar 2017 17:24:23 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id v25HOMAS083772 for ; Sun, 5 Mar 2017 09:24:22 -0800 (PST) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id v25HOM7h083771 for freebsd-hackers@freebsd.org; Sun, 5 Mar 2017 09:24:22 -0800 (PST) (envelope-from freebsd) Received: from mx2.freebsd.org (mx2.freebsd.org [8.8.178.116]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id v25FBqO2083316 for ; Sun, 5 Mar 2017 07:11:54 -0800 (PST) (envelope-from julian@freebsd.org) Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx2.freebsd.org (Postfix) with ESMTPS id 4C8536B33A for ; Sun, 5 Mar 2017 15:11:50 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F1ED1156E for ; Sun, 5 Mar 2017 15:11:49 +0000 (UTC) (envelope-from julian@freebsd.org) Received: by freefall.freebsd.org (Postfix) id 42F51649B; Sun, 5 Mar 2017 15:11:49 +0000 (UTC) Delivered-To: rgrimes@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id F293F649A; Sun, 5 Mar 2017 15:11:48 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 21D7F1566; Sun, 5 Mar 2017 15:11:47 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (106-68-109-205.dyn.iinet.net.au [106.68.109.205]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id v25FBf6X043253 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 5 Mar 2017 07:11:44 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: svn commit: r314693 - head/usr.sbin/rmt To: rgrimes@freebsd.org, Baptiste Daroussin References: <201703051319.v25DJSGt082916@pdx.rh.CN85.dnsmgr.net> cc: svn-src-all@freebsd.org, svn-src-head@freebsd.org From: Julian Elischer Message-ID: <761e6ecf-89aa-6356-4650-08f3c5c9d6a8@freebsd.org> Date: Sun, 5 Mar 2017 23:11:35 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <201703051319.v25DJSGt082916@pdx.rh.CN85.dnsmgr.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: freebsd@pdx.rh.CN85.dnsmgr.net X-Mailman-Approved-At: Sun, 05 Mar 2017 18:22:33 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2017 17:24:24 -0000 On 5/3/17 9:19 pm, Rodney W. Grimes wrote: > -- Start of PGP signed section. >> On Sun, Mar 05, 2017 at 04:09:18AM +0000, Rodney W. Grimes wrote: >>> Author: rgrimes >>> Date: Sun Mar 5 04:09:18 2017 >>> New Revision: 314693 >>> URL: https://svnweb.freebsd.org/changeset/base/314693 >>> >>> Log: >>> Change /etc/rmt symlink from absolute to relative path, >>> correcting the mistake made in r6499 >>> >>> Approved by: grehan >>> MFC after: 1 week >>> >>> Modified: >>> head/usr.sbin/rmt/Makefile >>> >>> Modified: head/usr.sbin/rmt/Makefile >>> ============================================================================== >>> --- head/usr.sbin/rmt/Makefile Sun Mar 5 04:02:47 2017 (r314692) >>> +++ head/usr.sbin/rmt/Makefile Sun Mar 5 04:09:18 2017 (r314693) >>> @@ -7,6 +7,6 @@ MAN= rmt.8 >>> # called from /usr/src/etc/Makefile >>> etc-rmt: >>> rm -f ${DESTDIR}/etc/rmt >>> - ln -s ${BINDIR}/rmt ${DESTDIR}/etc/rmt >>> + ln -s ..${BINDIR}/rmt ${DESTDIR}/etc/rmt >> I think this should be ${INSTALL_RSYMLINK} ${BINDIR}/rmt ${DESTDIR}/etc/rmt > find /usr/src | xargs grep INSTALL_RSYM > (no results) > > Sorry, no prior work does this, perhaps once I get done sweeping the > absolutes out of the tree (about 10 or 15 IIRC) a pass can be made to > sweep all ln -s out and propage this internal bsd.lib.mk function out > to the rest of the source tree? > > find /usr/share/mk/ | xargs grep INSTALL_RSYM > /usr/share/mk/bsd.own.mk:INSTALL_RSYMLINK?= ${INSTALL} ${RSYMLINK} > /usr/share/mk/bsd.lib.mk: ${INSTALL_RSYMLINK} ${TAG_ARGS:D${TAG_ARGS},development} ${SHLIB_NAME} ${DESTDIR}${_LIBDIR}/${SHLIB_LINK} > /usr/share/mk/bsd.lib.mk: ${INSTALL_RSYMLINK} ${TAG_ARGS} ${DESTDIR}${_SHLIBDIR}/${SHLIB_NAME} \ > /usr/share/mk/bsd.lib.mk: ${INSTALL_RSYMLINK} ${TAG_ARGS:D${TAG_ARGS},development} ${DESTDIR}${_SHLIBDIR}/${SHLIB_NAME} \ > /usr/share/mk/bsd.lib.mk: ${INSTALL_RSYMLINK} ${TAG_ARGS} ${DESTDIR}${_SHLIBDIR}/${SHLIB_NAME} \ > > This is called from within bsd.lib.mk only, do we want to use this for > all symbolics links in the source tree? If so I would of though the > person adding this functionality to the .mk files would of made > a tree sweeping looking for that and making those changes as well. I've been playing around with libpathconv which converts abs paths to relative paths etc. I'w working on the patch to ln to add the -a and -r options that some other versions have. you can specify an absolute path but ln -r (abspath) will generate a relative link. my target was the exact absolute symlinks that you are targeting. Work commitments have made me lay down tools but this reminds me to pick it up again. (libpathconv is in the tree at /lib/libpathconv, but I got interrupted half way through.. I'll do the other half.. >> The rm -f before can then be removed, the symlink will be relative and the >> METALOG will be respected > METALOG? The only documentation I can find on this seems to be part of > src/tootls/tools/makeroot.8. > > It appears that something in Makefile.inc uses it and there are references > to it in etc/Makefile. > > Where is this METALOG documented? > >> Best regards, >> Bapt > -- End of PGP section, PGP failed! > From owner-freebsd-hackers@freebsd.org Sun Mar 5 21:09:19 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 247E2CFAECE for ; Sun, 5 Mar 2017 21:09:19 +0000 (UTC) (envelope-from dirkx@webweaving.org) Received: from weser.webweaving.org (weser.webweaving.org [148.251.234.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.webweaving.org", Issuer "RapidSSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C63A91F0D for ; Sun, 5 Mar 2017 21:09:18 +0000 (UTC) (envelope-from dirkx@webweaving.org) Received: from [10.11.0.204] (5ED06D14.cm-7-1b.dynamic.ziggo.nl [94.208.109.20]) (authenticated bits=0) by weser.webweaving.org (8.15.2/8.15.2) with ESMTPSA id v25L7rV4001677 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 5 Mar 2017 22:07:53 +0100 (CET) (envelope-from dirkx@webweaving.org) X-Authentication-Warning: weser.webweaving.org: Host 5ED06D14.cm-7-1b.dynamic.ziggo.nl [94.208.109.20] claimed to be [10.11.0.204] From: Dirk-Willem van Gulik Message-Id: Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: kill -0 --- side effect or supported Date: Sun, 5 Mar 2017 22:08:01 +0100 In-Reply-To: <35C6F2AA-309E-4D58-8191-AB99F0195BEC@gmail.com> Cc: "Rodney W. Grimes" , freebsd-hackers@freebsd.org To: "Ngie Cooper (yaneurabeya)" References: <201703032230.v23MUg5b072955@pdx.rh.CN85.dnsmgr.net> <35C6F2AA-309E-4D58-8191-AB99F0195BEC@gmail.com> X-Mailer: Apple Mail (2.3259) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (weser.webweaving.org [148.251.234.232]); Sun, 05 Mar 2017 22:07:54 +0100 (CET) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2017 21:09:19 -0000 > On 3 Mar 2017, at 23:42, Ngie Cooper (yaneurabeya) = wrote: >=20 >>=20 >> On Mar 3, 2017, at 14:30, Rodney W. Grimes = wrote: >>=20 >> -- Start of PGP signed section. >> [ Charset UTF-8 unsupported, converting... ] >>>=20 >>>> On Mar 3, 2017, at 14:12, Dirk-Willem van Gulik = wrote: >>>>=20 >>>> I regularly use 'kill -0 ' on FreeBSD as a way to test if a = certain process is still running (but without actually sending the = signal). And I think it has worked reliably since the mid 80's. >>>>=20 >>>> Is it actually a properly supported use - as I recently happened to = notice that it does not seem to be all that documented in kill( >>>=20 >>> It better work. I have code that relies on it :)? >>>=20 >>> It does work as you noted, according to truss: >>>=20 >>> # sudo truss -ff kill -0 1 2>&1 >>> ... >>> 79940: kill(1,0) =3D 0 (0x0) >>> ? >>> # >>>=20 >>> As noted in kill(2), this is one of the valid values: >>>=20 >>> a group of processes. The sig argument may be one of the signals >>> specified in sigaction(2) or it may be 0, in which case error = checking is >> ^^^^^^^^^^^^^^^^ >>=20 >> That bit of information should be promoted from kill(2) to kill(1) by >> adding 0 to the list as ?. >=20 > Actually=E2=80=A6 it is mentioned in kill(1) =E2=80=94 you just have = to read between the lines: >=20 > -signal_number > A non-negative decimal integer, specifying the signal to = be sent > instead of the default TERM. >=20 > 0 is technically a non-negative real number. >=20 > It might be a good idea to clarify this point/behavior by pointing to = kill(2) for the signal behavior/description noted above. Posix @ Opengroup says: = http://pubs.opengroup.org/onlinepubs/009695399/functions/kill.html The kill() function shall send a signal to a process or a group = of processes specified by pid. The signal to be sent is specified by sig = and is either one from the list given in or 0. If sig is 0 = (the null signal), error checking is performed but no signal is actually = sent. The null signal can be used to check the validity of pid. I guess this could be added - with perhaps the note/warning on the = 'zombie' processes - as this is subtly different between unixes. Dw From owner-freebsd-hackers@freebsd.org Sun Mar 5 21:13:15 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8D901CFA16A for ; Sun, 5 Mar 2017 21:13:15 +0000 (UTC) (envelope-from dirkx@webweaving.org) Received: from weser.webweaving.org (weser.webweaving.org [148.251.234.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.webweaving.org", Issuer "RapidSSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3804E1313 for ; Sun, 5 Mar 2017 21:13:14 +0000 (UTC) (envelope-from dirkx@webweaving.org) Received: from [10.11.0.204] (5ED06D14.cm-7-1b.dynamic.ziggo.nl [94.208.109.20]) (authenticated bits=0) by weser.webweaving.org (8.15.2/8.15.2) with ESMTPSA id v25LBunt001786 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sun, 5 Mar 2017 22:11:57 +0100 (CET) (envelope-from dirkx@webweaving.org) Resent-Message-Id: <201703052111.v25LBunt001786@weser.webweaving.org> X-Authentication-Warning: weser.webweaving.org: Host 5ED06D14.cm-7-1b.dynamic.ziggo.nl [94.208.109.20] claimed to be [10.11.0.204] Subject: Re: PCI speed Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Content-Type: text/plain; charset=us-ascii From: Dirk-Willem van Gulik Resent-From: Dirk-Willem van Gulik In-Reply-To: Date: Sun, 5 Mar 2017 22:01:32 +0100 Content-Transfer-Encoding: quoted-printable Resent-Date: Sun, 5 Mar 2017 22:12:05 +0100 Message-Id: <18D26C89-0202-40F6-9396-586ADA79C67C@webweaving.org> Resent-To: freebsd-hackers@freebsd.org References: <03745A05-DE0E-4071-B432-BFE58C3A7E16@webweaving.org> To: Warner Losh X-Mailer: Apple Mail (2.3259) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (weser.webweaving.org [148.251.234.232]); Sun, 05 Mar 2017 22:11:57 +0100 (CET) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2017 21:13:15 -0000 > On 3 Mar 2017, at 23:52, Warner Losh wrote: >=20 > On Fri, Mar 3, 2017 at 3:34 PM, Dirk-Willem van Gulik > wrote: >> Forgive me my ignorance - but for some cards - pciconf(8) nicely = lists the speed of the bus: >>=20 >>> ciss0@pci0:12:0:0: class=3D0x010400 card=3D0x3243103c = chip=3D0x323a103c rev=3D0x01 hdr=3D0x00 >> ... >>> cap 10[70] =3D PCI-Express 2 endpoint max data 128(256) RO NS >>> link x4(x8) speed 5.0(5.0) >>=20 >> and that matches exactly with what it is. While for other cards it = does not seem to report that: >=20 > So you have a x8 card in a x4 slot. Hope that's OK. It's also > reporting errors on the PCIe link level. That doesn't sound too > correct. It ended up being quite a rat-hole - further examination showed that = some on motherboard soldered P410 and NC382i ethernets where reporting = just as oddly! >>> mpt4@pci0:7:8:1: class=3D0x010000 card=3D0x10b01000 = chip=3D0x00301000 rev=3D0x08 hdr=3D0x00 >> .... >>> cap 07[68] =3D PCI-X 64-bit supports 133MHz, 2048 burst read, 8 = split transactions >>=20 >> and in fact seems to mis report the bus - this is a PCIe Gen 2 x4 = bus with a x8 Connector Width >> holding a LSI 22320SE Ultra320 SCSI dual channel PCIe X4 card. >=20 >> How should one interpret this ? >=20 > That's odd. I'd have expected it to report correctly... It does for us = at work. > What version of FreeBSD? FreeBSD 11.0 - p7. The HW are fairly plain DL385 G7 and G8 frames with = AMD cpu's and two risers (One bus x8, connector 16 and two x4bus and x8 = connector). Two hold an P410i/2048MB cards; two P222/512Mb cards and one = LSILogic 1030 Ultra4 Adapter. We've since looked at multiple DL385's and found the results to be a = total mess; with reports even differing between the first boot after a = hard power cycle and the next boot(s). Googling & Escalation within HPE = suggests that it is one large firmware mess with conflicting reports = (P2222 cards clashing with the Qlogic needs).=20 So I guess this is a rathole best left closed. Old HP kit is essentially = not worth it anymore given their serial#/paid-support burden. Dw. From owner-freebsd-hackers@freebsd.org Sun Mar 5 21:15:42 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 05518CFA2AF for ; Sun, 5 Mar 2017 21:15:42 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CBC481517; Sun, 5 Mar 2017 21:15:41 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id E735E22BD; Sun, 5 Mar 2017 21:15:40 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 5739035C61; Sun, 5 Mar 2017 21:15:36 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id FTjrrTA5Fe1U; Sun, 5 Mar 2017 21:15:23 +0000 (UTC) Subject: Re: svn commit: r314693 - head/usr.sbin/rmt DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 2A8B735C5C To: rgrimes@freebsd.org, Baptiste Daroussin References: <201703051626.v25GQWNd083561@pdx.rh.CN85.dnsmgr.net> Cc: freebsd-hackers@freebsd.org From: Bryan Drewery Organization: FreeBSD Message-ID: <1283ca30-a827-8b32-3021-658548447c22@FreeBSD.org> Date: Sun, 5 Mar 2017 13:15:21 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <201703051626.v25GQWNd083561@pdx.rh.CN85.dnsmgr.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="NKpRxNDOhNMeNIJIM17CONpFkP9s5hLsm" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2017 21:15:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --NKpRxNDOhNMeNIJIM17CONpFkP9s5hLsm Content-Type: multipart/mixed; boundary="sc1C8DOpCx3wfL6vevMrDiRFHgHpjNQ98"; protected-headers="v1" From: Bryan Drewery To: rgrimes@freebsd.org, Baptiste Daroussin Cc: freebsd-hackers@freebsd.org Message-ID: <1283ca30-a827-8b32-3021-658548447c22@FreeBSD.org> Subject: Re: svn commit: r314693 - head/usr.sbin/rmt References: <201703051626.v25GQWNd083561@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <201703051626.v25GQWNd083561@pdx.rh.CN85.dnsmgr.net> --sc1C8DOpCx3wfL6vevMrDiRFHgHpjNQ98 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 3/5/17 8:26 AM, Rodney W. Grimes wrote: > Moved thread to -hackers for a quick discussion. >=20 >> On Sun, Mar 05, 2017 at 05:19:28AM -0800, Rodney W. Grimes wrote: >>> -- Start of PGP signed section. >>>> On Sun, Mar 05, 2017 at 04:09:18AM +0000, Rodney W. Grimes wrote: >>>>> Author: rgrimes >>>>> Date: Sun Mar 5 04:09:18 2017 >>>>> New Revision: 314693 >>>>> URL: https://svnweb.freebsd.org/changeset/base/314693 >>>>> >>>>> Log: >>>>> Change /etc/rmt symlink from absolute to relative path, >>>>> correcting the mistake made in r6499 >>>>> =20 >>>>> Approved by: grehan >>>>> MFC after: 1 week >>>>> >>>>> Modified: >>>>> head/usr.sbin/rmt/Makefile >>>>> >>>>> Modified: head/usr.sbin/rmt/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=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >>>>> --- head/usr.sbin/rmt/Makefile Sun Mar 5 04:02:47 2017 (r314692) >>>>> +++ head/usr.sbin/rmt/Makefile Sun Mar 5 04:09:18 2017 (r314693) >>>>> @@ -7,6 +7,6 @@ MAN=3D rmt.8 >>>>> # called from /usr/src/etc/Makefile >>>>> etc-rmt: >>>>> rm -f ${DESTDIR}/etc/rmt >>>>> - ln -s ${BINDIR}/rmt ${DESTDIR}/etc/rmt >>>>> + ln -s ..${BINDIR}/rmt ${DESTDIR}/etc/rmt >>>> >>>> I think this should be ${INSTALL_RSYMLINK} ${BINDIR}/rmt ${DESTDIR}/= etc/rmt >>> >>> find /usr/src | xargs grep INSTALL_RSYM >>> (no results) >>> >>> Sorry, no prior work does this, perhaps once I get done sweeping the >>> absolutes out of the tree (about 10 or 15 IIRC) a pass can be made to= >>> sweep all ln -s out and propage this internal bsd.lib.mk function out= >>> to the rest of the source tree? >> >> There is also no Makefiles that do ls -sf directly beside that one. > Unless I have missed a commit: > ./crypto/openssh/contrib/cygwin/Makefile: cd $(DESTDIR)$(mandir)/= man1 && ln -s ssh.1.gz slogin.1.gz > ./usr.sbin/sendmail/Makefile: ln -sf ${.ALLSRC} ${.TARGET} > ./usr.sbin/rmt/Makefile: ln -s ${BINDIR}/rmt ${DESTDIR}/etc/rmt > ... Keep in mind that INSTALL_*SYMLINK should only be used for *installing* a symlink, not for intermediate build files. All of the direct 'ln' usage in the tree should be not installed. Brooks and I and others have done passes before to ensure that any installed symlink uses INSTALL_*SYMLINK. The reasoning is that the -DNO_ROOT build requires that 'install' be used since it is logging the file in a meta log that is later used to build an image from. This is also important for the DIRDEPS_BUILD feature. > A summary is there are 50 instances of ln -sf, 28 other variants of ln= -s, > and 5 ln -fs. I did not search for other permutaions of ln and s f opt= ions. >=20 >=20 >> INSTALL_RSYMLINK has exactly be done to be use everywhere it is needed= =2E (I wrote >> it for that exact reason :)) >=20 > Wonderful!! I'll investigate a sweep to finish implementing this tree = wide > in my spare time.... I notice that SYMLINKS=3D is hard coded to use > INSTALL_SYMLINKS so that can't be used to fix some of these. > How would you propose I proceed in that area?? >=20 > And investigation into using INSTALL_RSYMLINK in SYMLINKS=3D should be = done, > I can not think of a reason when you DONT want a relative link install= ed, > but I may be missing some new odd use for symlinks by the FreeBSD base > system. >>> >>> find /usr/share/mk/ | xargs grep INSTALL_RSYM >>> /usr/share/mk/bsd.own.mk:INSTALL_RSYMLINK?=3D ${INSTALL} ${RSYMLI= NK} >>> /usr/share/mk/bsd.lib.mk: ${INSTALL_RSYMLINK} ${TAG_ARGS:D${TAG= _ARGS},development} ${SHLIB_NAME} ${DESTDIR}${_LIBDIR}/${SHLIB_LINK} >>> /usr/share/mk/bsd.lib.mk: ${INSTALL_RSYMLINK} ${TAG_ARGS} ${DES= TDIR}${_SHLIBDIR}/${SHLIB_NAME} \ >>> /usr/share/mk/bsd.lib.mk: ${INSTALL_RSYMLINK} ${TAG_ARGS:D${TAG= _ARGS},development} ${DESTDIR}${_SHLIBDIR}/${SHLIB_NAME} \ >>> /usr/share/mk/bsd.lib.mk: ${INSTALL_RSYMLINK} ${TAG_ARGS} ${DES= TDIR}${_SHLIBDIR}/${SHLIB_NAME} \ >>> >>> This is called from within bsd.lib.mk only, do we want to use this fo= r >>> all symbolics links in the source tree? If so I would of though the >>> person adding this functionality to the .mk files would of made >>> a tree sweeping looking for that and making those changes as well. >> >> When I did it only bsd.lib.mk was using it iirc >=20 > And that appears to still be the case. >=20 >>>> The rm -f before can then be removed, the symlink will be relative a= nd the >>>> METALOG will be respected=20 >>> >>> METALOG? The only documentation I can find on this seems to be part = of >>> src/tootls/tools/makeroot.8. >>> >>> It appears that something in Makefile.inc uses it and there are refer= ences >>> to it in etc/Makefile. >>> >>> Where is this METALOG documented? =20 >> >> It is really badly documented and should be :( it is a mtree file that= is >> generated when built is done via -DNO_ROOT for the purpose of being ab= le to >> generate disk with makefs as a user >> >> I have reused it for packaging base. >> >> This was designed IIRC by adrian and brooks iirc. >> >> Embedded people relies a lot on it. >> Everything not going though the install(1) command is not tracked that= is why >> this is an issue. >=20 > I guess then that these 83 things I have found are not so important to = them? >=20 > Lets take this to -hackers, discuss it where it should be, and get it f= ixed. >=20 --=20 Regards, Bryan Drewery --sc1C8DOpCx3wfL6vevMrDiRFHgHpjNQ98-- --NKpRxNDOhNMeNIJIM17CONpFkP9s5hLsm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJYvH/qAAoJEDXXcbtuRpfPkowIAKOBALSd8A9revHHonmA+Zny 6iOcwWHkgf1SsUA0iibAwOJffUWEEZxS9al1m/yoNmf9dH81u0wAAceor8P72Q7A /OEUw5aNbaBV2TzmqPRBOw52MGJHaIRPM6hAAkqvYCokHdJm4Zf8hY39lzZes0Jl 8ynoDUcUzGr3gHXVNLJGlma3kQpwOi9VoBFpGmYbfGdSWUEOZTCcO3NRx37qv03i 8W0RD0Dr4oMteufZyRccgzqZV0BxGMYpQLIbgs3Zhu71OA1q7D/PFJR4aQqOSSrT iIWNTi2R3rlgv+UloXYg0Jo9noq4xJLCn8zlq7fBAaNSx3WX3pLQpNZW+duzQHo= =D6xS -----END PGP SIGNATURE----- --NKpRxNDOhNMeNIJIM17CONpFkP9s5hLsm-- From owner-freebsd-hackers@freebsd.org Sun Mar 5 21:42:07 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 04A90CFAB7A for ; Sun, 5 Mar 2017 21:42:07 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C581A15AC; Sun, 5 Mar 2017 21:42:06 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 4FF1E28A9; Sun, 5 Mar 2017 21:41:58 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 577F935D41; Sun, 5 Mar 2017 21:41:57 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id MZOM1-Nq7qC9; Sun, 5 Mar 2017 21:41:42 +0000 (UTC) Subject: Re: svn commit: r314693 - head/usr.sbin/rmt DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 4E7C335D3C To: rgrimes@FreeBSD.org References: <201703052139.v25Ld6iR084880@pdx.rh.CN85.dnsmgr.net> Cc: Baptiste Daroussin , freebsd-hackers@FreeBSD.org From: Bryan Drewery Organization: FreeBSD Message-ID: <957a873a-cf20-5a2a-638a-c6f7c154bf84@FreeBSD.org> Date: Sun, 5 Mar 2017 13:41:25 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <201703052139.v25Ld6iR084880@pdx.rh.CN85.dnsmgr.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="cQQiMtCMIh5XgWScQb0upBpvsBXH9JSrX" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2017 21:42:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cQQiMtCMIh5XgWScQb0upBpvsBXH9JSrX Content-Type: multipart/mixed; boundary="aVlGD1bQiHLK42nu7JO0hcDkAme54iXJ5"; protected-headers="v1" From: Bryan Drewery To: rgrimes@FreeBSD.org Cc: Baptiste Daroussin , freebsd-hackers@FreeBSD.org Message-ID: <957a873a-cf20-5a2a-638a-c6f7c154bf84@FreeBSD.org> Subject: Re: svn commit: r314693 - head/usr.sbin/rmt References: <201703052139.v25Ld6iR084880@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <201703052139.v25Ld6iR084880@pdx.rh.CN85.dnsmgr.net> --aVlGD1bQiHLK42nu7JO0hcDkAme54iXJ5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 3/5/17 1:39 PM, Rodney W. Grimes wrote: >> On 3/5/17 8:26 AM, Rodney W. Grimes wrote: >>> Moved thread to -hackers for a quick discussion. >>> >>>> On Sun, Mar 05, 2017 at 05:19:28AM -0800, Rodney W. Grimes wrote: >>>>> -- Start of PGP signed section. >>>>>> On Sun, Mar 05, 2017 at 04:09:18AM +0000, Rodney W. Grimes wrote: >>>>>>> Author: rgrimes >>>>>>> Date: Sun Mar 5 04:09:18 2017 >>>>>>> New Revision: 314693 >>>>>>> URL: https://svnweb.freebsd.org/changeset/base/314693 >>>>>>> >>>>>>> Log: >>>>>>> Change /etc/rmt symlink from absolute to relative path, >>>>>>> correcting the mistake made in r6499 >>>>>>> =20 >>>>>>> Approved by: grehan >>>>>>> MFC after: 1 week >>>>>>> >>>>>>> Modified: >>>>>>> head/usr.sbin/rmt/Makefile >>>>>>> >>>>>>> Modified: head/usr.sbin/rmt/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=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >>>>>>> --- head/usr.sbin/rmt/Makefile Sun Mar 5 04:02:47 2017 (r314692)= >>>>>>> +++ head/usr.sbin/rmt/Makefile Sun Mar 5 04:09:18 2017 (r314693)= >>>>>>> @@ -7,6 +7,6 @@ MAN=3D rmt.8 >>>>>>> # called from /usr/src/etc/Makefile >>>>>>> etc-rmt: >>>>>>> rm -f ${DESTDIR}/etc/rmt >>>>>>> - ln -s ${BINDIR}/rmt ${DESTDIR}/etc/rmt >>>>>>> + ln -s ..${BINDIR}/rmt ${DESTDIR}/etc/rmt >>>>>> >>>>>> I think this should be ${INSTALL_RSYMLINK} ${BINDIR}/rmt ${DESTDIR= }/etc/rmt >>>>> >>>>> find /usr/src | xargs grep INSTALL_RSYM >>>>> (no results) >>>>> >>>>> Sorry, no prior work does this, perhaps once I get done sweeping th= e >>>>> absolutes out of the tree (about 10 or 15 IIRC) a pass can be made = to >>>>> sweep all ln -s out and propage this internal bsd.lib.mk function o= ut >>>>> to the rest of the source tree? >>>> >>>> There is also no Makefiles that do ls -sf directly beside that one. >>> Unless I have missed a commit: >>> ./crypto/openssh/contrib/cygwin/Makefile: cd $(DESTDIR)$(mandir= )/man1 && ln -s ssh.1.gz slogin.1.gz >>> ./usr.sbin/sendmail/Makefile: ln -sf ${.ALLSRC} ${.TARGET} >>> ./usr.sbin/rmt/Makefile: ln -s ${BINDIR}/rmt ${DESTDIR}/etc/rm= t >>> ... >> >> Keep in mind that INSTALL_*SYMLINK should only be used for *installing= * >> a symlink, not for intermediate build files. All of the direct 'ln' >> usage in the tree should be not installed. Brooks and I and others ha= ve >> done passes before to ensure that any installed symlink uses >> INSTALL_*SYMLINK. The reasoning is that the -DNO_ROOT build requires >> that 'install' be used since it is logging the file in a meta log that= >> is later used to build an image from. This is also important for the >> DIRDEPS_BUILD feature. >=20 > In those several passes you have missed at least this one here in rmt > that has been there since the refer commit of r6499. This is not a > new link someone added recently. I simply corrected the arguments to > the command so that we no longer have an absolute link inside > of ${DESTDIR}. Yup it looks like we missed the 'etc'/configuration ones. Those are kind of special in those 2 build modes I mentioned which is probably why they've been missed. >=20 > Let me review my other 10 or so pending commits again, but I think all > of those are errors in SYMLINKS=3D. Bapt did not answer my question > on how to deal with SYMLINKS hardcoded to use INSTALL_SYMLINKS but > I well need it to use INSTALL_RSYMLINKS for some of these corrections. >=20 > For now I have just feed the proper arguments to SYMLINKS so that it > creates proper relative paths. =20 >=20 >>> A summary is there are 50 instances of ln -sf, 28 other variants of = ln -s, >>> and 5 ln -fs. I did not search for other permutaions of ln and s f o= ptions. > ... > REVIEWING my patches I see this: > --- share/termcap/Makefile (revision 314708) > +++ share/termcap/Makefile (working copy) > @@ -24,6 +24,6 @@ > cap_mkdb ${CAP_MKDB_ENDIAN} -f ${.TARGET:R} ${.ALLSRC} >=20 > etc-termcap: > - ${INSTALL_SYMLINK} ${BINDIR}/misc/termcap ${DESTDIR}/etc/termca= p > + ${INSTALL_SYMLINK} ..${BINDIR}/misc/termcap ${DESTDIR}/etc/term= cap >=20 > .include >=20 > I'll convert that to INSTALL_RSYMLINK, all others are in > SYMLINK lists. That should get handled by your .mk modifications to > do the right thing. >=20 >=20 --=20 Regards, Bryan Drewery --aVlGD1bQiHLK42nu7JO0hcDkAme54iXJ5-- --cQQiMtCMIh5XgWScQb0upBpvsBXH9JSrX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJYvIYFAAoJEDXXcbtuRpfPO2QIAOESVU99vUk0JSNWGzA7QWzA I4RD44bO9stQ/Yj0B3cOl2/SgBondKSCKMAYL+qTomxPSf1Bgu06Zp1W5KM4HQJh QSPDy5DMODuh1mNcCz8sEtmiirfKS1hoLvfUgaYt1cJI9fa5xmwKol3iP9/B3I+P l7VIpJMBOTJc+tmy0Vt0sWr611hwT1hC1BiQlQZAW5KILHhCke+NQcougpfA+u90 g61mfE6Ehx+EI2VyZiIFyIoI1rgefk+fl3sFZlwEptFvgJ6j3O8GImyC7oy2cLC5 ktWGZD0aJ0FrZF/87mRayeTqjlRKVykRE9dE2bx/K02E0745xyE0wH1nj6cYpk4= =22Nu -----END PGP SIGNATURE----- --cQQiMtCMIh5XgWScQb0upBpvsBXH9JSrX-- From owner-freebsd-hackers@freebsd.org Sun Mar 5 22:03:42 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4E927CFA4D2 for ; Sun, 5 Mar 2017 22:03:42 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2118E15BA; Sun, 5 Mar 2017 22:03:42 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 519172FAD; Sun, 5 Mar 2017 22:03:41 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id E029D35DE5; Sun, 5 Mar 2017 22:03:39 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id fLEpcBlLmPBc; Sun, 5 Mar 2017 22:03:24 +0000 (UTC) Subject: Re: svn commit: r314693 - head/usr.sbin/rmt DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 3420735DE0 To: rgrimes@FreeBSD.org References: <201703052158.v25Lwbu9084977@pdx.rh.CN85.dnsmgr.net> Cc: Baptiste Daroussin , freebsd-hackers@FreeBSD.org From: Bryan Drewery Organization: FreeBSD Message-ID: <0dfcbda8-2a5d-3b42-9cf3-2ea78d9e318d@FreeBSD.org> Date: Sun, 5 Mar 2017 14:03:22 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <201703052158.v25Lwbu9084977@pdx.rh.CN85.dnsmgr.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="UH78c8lEK1mT47CS92seImqj4a1KDs3SI" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2017 22:03:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --UH78c8lEK1mT47CS92seImqj4a1KDs3SI Content-Type: multipart/mixed; boundary="qK5u2g7hsjqhUmiASdK0JbQX4dvncFUof"; protected-headers="v1" From: Bryan Drewery To: rgrimes@FreeBSD.org Cc: Baptiste Daroussin , freebsd-hackers@FreeBSD.org Message-ID: <0dfcbda8-2a5d-3b42-9cf3-2ea78d9e318d@FreeBSD.org> Subject: Re: svn commit: r314693 - head/usr.sbin/rmt References: <201703052158.v25Lwbu9084977@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <201703052158.v25Lwbu9084977@pdx.rh.CN85.dnsmgr.net> --qK5u2g7hsjqhUmiASdK0JbQX4dvncFUof Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 3/5/17 1:58 PM, Rodney W. Grimes wrote: > ... >>> Let me review my other 10 or so pending commits again, but I think al= l >>> of those are errors in SYMLINKS=3D. Bapt did not answer my question >>> on how to deal with SYMLINKS hardcoded to use INSTALL_SYMLINKS but >>> I well need it to use INSTALL_RSYMLINKS for some of these corrections= =2E >>> >>> For now I have just feed the proper arguments to SYMLINKS so that it >>> creates proper relative paths. =20 >=20 > Both bapt and yourself have not responded to how I should deal with the= > issue of relativie link paths needed in SYMLINKS=3D so I am going forwa= rd > with my pathces as they are, this at least gets a distrubution built > without any absolute links again, something that hasnt happened since > 1995. >=20 Yes I think your plan is fine for now. We could maybe add an RSYMLINKS list, but it will cause some complexity for DIRDEPS_BUILD that I don't have time to look at right now. --=20 Regards, Bryan Drewery --qK5u2g7hsjqhUmiASdK0JbQX4dvncFUof-- --UH78c8lEK1mT47CS92seImqj4a1KDs3SI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJYvIsrAAoJEDXXcbtuRpfPxtkH/1OKoEcDL3VG775OTF35DiLf nuLKhnkIrHv4A2/RcCSBnX5gn5PI0DruefyuEQKoCmD6Ofoz869Pkb44rxg4PYBf QU5S5nv08dqsJABH/P1bBL4ZtEwwpndp1MHnfcqJEPZGHsUUnCbZwU/yzDyhxMuK iBxEwgb0A72yHwrZ30zyH95eYtDWY2YRSumtLmKRRG/tN+diHf79rBQbdBJqRcND kEtdSF7FLBfvHCyQAJbo43F7HnlR/9/pWAlC6GUvkg9WBKm+sJFeGqIEFXaieeNN x7tePIBgU/bReNRVkmE9Am3KRrqoeHwoqkgZhZ9ZSYwTbYrlB6i+ANZwZYh/Cik= =zPjx -----END PGP SIGNATURE----- --UH78c8lEK1mT47CS92seImqj4a1KDs3SI-- From owner-freebsd-hackers@freebsd.org Sun Mar 5 21:39:08 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B2C80CFA969 for ; Sun, 5 Mar 2017 21:39:08 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 733DE118E; Sun, 5 Mar 2017 21:39:07 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id v25Ld6bj084881; Sun, 5 Mar 2017 13:39:06 -0800 (PST) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id v25Ld6iR084880; Sun, 5 Mar 2017 13:39:06 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <201703052139.v25Ld6iR084880@pdx.rh.CN85.dnsmgr.net> Subject: Re: svn commit: r314693 - head/usr.sbin/rmt In-Reply-To: <1283ca30-a827-8b32-3021-658548447c22@FreeBSD.org> To: Bryan Drewery Date: Sun, 5 Mar 2017 13:39:06 -0800 (PST) CC: rgrimes@FreeBSD.org, Baptiste Daroussin , freebsd-hackers@FreeBSD.org Reply-To: rgrimes@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Sun, 05 Mar 2017 22:43:54 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2017 21:39:08 -0000 > On 3/5/17 8:26 AM, Rodney W. Grimes wrote: > > Moved thread to -hackers for a quick discussion. > > > >> On Sun, Mar 05, 2017 at 05:19:28AM -0800, Rodney W. Grimes wrote: > >>> -- Start of PGP signed section. > >>>> On Sun, Mar 05, 2017 at 04:09:18AM +0000, Rodney W. Grimes wrote: > >>>>> Author: rgrimes > >>>>> Date: Sun Mar 5 04:09:18 2017 > >>>>> New Revision: 314693 > >>>>> URL: https://svnweb.freebsd.org/changeset/base/314693 > >>>>> > >>>>> Log: > >>>>> Change /etc/rmt symlink from absolute to relative path, > >>>>> correcting the mistake made in r6499 > >>>>> > >>>>> Approved by: grehan > >>>>> MFC after: 1 week > >>>>> > >>>>> Modified: > >>>>> head/usr.sbin/rmt/Makefile > >>>>> > >>>>> Modified: head/usr.sbin/rmt/Makefile > >>>>> ============================================================================== > >>>>> --- head/usr.sbin/rmt/Makefile Sun Mar 5 04:02:47 2017 (r314692) > >>>>> +++ head/usr.sbin/rmt/Makefile Sun Mar 5 04:09:18 2017 (r314693) > >>>>> @@ -7,6 +7,6 @@ MAN= rmt.8 > >>>>> # called from /usr/src/etc/Makefile > >>>>> etc-rmt: > >>>>> rm -f ${DESTDIR}/etc/rmt > >>>>> - ln -s ${BINDIR}/rmt ${DESTDIR}/etc/rmt > >>>>> + ln -s ..${BINDIR}/rmt ${DESTDIR}/etc/rmt > >>>> > >>>> I think this should be ${INSTALL_RSYMLINK} ${BINDIR}/rmt ${DESTDIR}/etc/rmt > >>> > >>> find /usr/src | xargs grep INSTALL_RSYM > >>> (no results) > >>> > >>> Sorry, no prior work does this, perhaps once I get done sweeping the > >>> absolutes out of the tree (about 10 or 15 IIRC) a pass can be made to > >>> sweep all ln -s out and propage this internal bsd.lib.mk function out > >>> to the rest of the source tree? > >> > >> There is also no Makefiles that do ls -sf directly beside that one. > > Unless I have missed a commit: > > ./crypto/openssh/contrib/cygwin/Makefile: cd $(DESTDIR)$(mandir)/man1 && ln -s ssh.1.gz slogin.1.gz > > ./usr.sbin/sendmail/Makefile: ln -sf ${.ALLSRC} ${.TARGET} > > ./usr.sbin/rmt/Makefile: ln -s ${BINDIR}/rmt ${DESTDIR}/etc/rmt > > ... > > Keep in mind that INSTALL_*SYMLINK should only be used for *installing* > a symlink, not for intermediate build files. All of the direct 'ln' > usage in the tree should be not installed. Brooks and I and others have > done passes before to ensure that any installed symlink uses > INSTALL_*SYMLINK. The reasoning is that the -DNO_ROOT build requires > that 'install' be used since it is logging the file in a meta log that > is later used to build an image from. This is also important for the > DIRDEPS_BUILD feature. In those several passes you have missed at least this one here in rmt that has been there since the refer commit of r6499. This is not a new link someone added recently. I simply corrected the arguments to the command so that we no longer have an absolute link inside of ${DESTDIR}. Let me review my other 10 or so pending commits again, but I think all of those are errors in SYMLINKS=. Bapt did not answer my question on how to deal with SYMLINKS hardcoded to use INSTALL_SYMLINKS but I well need it to use INSTALL_RSYMLINKS for some of these corrections. For now I have just feed the proper arguments to SYMLINKS so that it creates proper relative paths. > > A summary is there are 50 instances of ln -sf, 28 other variants of ln -s, > > and 5 ln -fs. I did not search for other permutaions of ln and s f options. ... REVIEWING my patches I see this: --- share/termcap/Makefile (revision 314708) +++ share/termcap/Makefile (working copy) @@ -24,6 +24,6 @@ cap_mkdb ${CAP_MKDB_ENDIAN} -f ${.TARGET:R} ${.ALLSRC} etc-termcap: - ${INSTALL_SYMLINK} ${BINDIR}/misc/termcap ${DESTDIR}/etc/termcap + ${INSTALL_SYMLINK} ..${BINDIR}/misc/termcap ${DESTDIR}/etc/termcap .include I'll convert that to INSTALL_RSYMLINK, all others are in SYMLINK lists. That should get handled by your .mk modifications to do the right thing. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Sun Mar 5 21:58:38 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DD396CFA094 for ; Sun, 5 Mar 2017 21:58:38 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B3D631102; Sun, 5 Mar 2017 21:58:38 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id v25LwbfX084978; Sun, 5 Mar 2017 13:58:37 -0800 (PST) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id v25Lwbu9084977; Sun, 5 Mar 2017 13:58:37 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <201703052158.v25Lwbu9084977@pdx.rh.CN85.dnsmgr.net> Subject: Re: svn commit: r314693 - head/usr.sbin/rmt In-Reply-To: <957a873a-cf20-5a2a-638a-c6f7c154bf84@FreeBSD.org> To: Bryan Drewery Date: Sun, 5 Mar 2017 13:58:37 -0800 (PST) CC: rgrimes@FreeBSD.org, Baptiste Daroussin , freebsd-hackers@FreeBSD.org Reply-To: rgrimes@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Sun, 05 Mar 2017 22:44:02 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2017 21:58:39 -0000 ... > > Let me review my other 10 or so pending commits again, but I think all > > of those are errors in SYMLINKS=. Bapt did not answer my question > > on how to deal with SYMLINKS hardcoded to use INSTALL_SYMLINKS but > > I well need it to use INSTALL_RSYMLINKS for some of these corrections. > > > > For now I have just feed the proper arguments to SYMLINKS so that it > > creates proper relative paths. Both bapt and yourself have not responded to how I should deal with the issue of relativie link paths needed in SYMLINKS= so I am going forward with my pathces as they are, this at least gets a distrubution built without any absolute links again, something that hasnt happened since 1995. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Mon Mar 6 02:53:04 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 18497CF9F6C for ; Mon, 6 Mar 2017 02:53:04 +0000 (UTC) (envelope-from embaudarm@gmail.com) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C961C1924 for ; Mon, 6 Mar 2017 02:53:03 +0000 (UTC) (envelope-from embaudarm@gmail.com) Received: by mail-oi0-x22e.google.com with SMTP id 126so27097256oig.3 for ; Sun, 05 Mar 2017 18:53:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ulqQn5g72/7+hC4uT09ZTfTxjBAqgWBuSV8OBzQmVNA=; b=QzekDUbOtypSh2wwlgmrjMQHvdQsGbAYFtlF5yzgDtxeKYyVuVrsIwpixEj2/3tD/D vyjlm/lNCCNgf0mInHwOwulJqyFey9OIpUsdOcu7M50pcmpprbka7pDczMzwrSKoFmyH UieVvhP3GjudDuscqNgtHOOMac1XENsf1nUbun+NF5BwObDZ1w+OuKx0MANMDnm0eZRk CzkuzyvihZ9BShRbaJb4RAIzgc/gHk07bueXui3CkkC/4dLSQXOi/Uad8cQXBTuWAZWi dJKg/6F7wO/BWv1FKAdxxscGEXXCzEI6pUvs/KkUwqrLv2mCFYwSotynCjIMFXRDB0sV JBKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ulqQn5g72/7+hC4uT09ZTfTxjBAqgWBuSV8OBzQmVNA=; b=opsuOT5Qq07qmNDZ6v19wsjSKNCNdLEnV/IhLIPkjxpcw0eW92X4uK6Sl1hawjsoRq YEqXe5hDHlrxbScfHizZ0GpF3a8BB2AzLs8xyoHIT8mjoBFkRtt7I1gITkUFJgfHwq14 yAHmSP0MjwtRFNl0vxPDkPzVbdqfbdHeKO0qqwwK094yICQUzSdtykZPEFpceTJhJT6n mYoJXGX+FQJ5CIALdeoMcf+aEXzaUZWboYL7z1fcqUNP52cKvyCls0++rsF9H9wMBwlg VjGPKYbQuX+ikv3Pr/hwhF/jNglRlvkNvrISwZBw1vbySrH7B6HGIrH4P3zHtJdgflXV muQA== X-Gm-Message-State: AMke39kDACvqJABnwtgyZ4fXRpbijJ9wQVvScOY8wYaWkog6x5xJNelK8N6Qc3os895pHaaIh8T3idmCiYJowA== X-Received: by 10.202.240.70 with SMTP id o67mr7300064oih.195.1488768783152; Sun, 05 Mar 2017 18:53:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.31.46 with HTTP; Sun, 5 Mar 2017 18:52:22 -0800 (PST) In-Reply-To: References: From: Lee D Date: Sun, 5 Mar 2017 21:52:22 -0500 Message-ID: Subject: Re: How approach debugging a kernel crash? To: Alexander Tarasikov Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 02:53:04 -0000 Thank you, I will give that a try. I didn't know about the FAR. Lee On Fri, Mar 3, 2017 at 9:57 AM, Alexander Tarasikov < alexander.tarasikov@gmail.com> wrote: > Hi, > the kernel prints the FAR, the fault address register, and the registers. > Looks like it crashes inside the fault handler itself? > > I would go to the "abort_handler" or "exception_exit" and add debugging > prints to UART into there to catch the initial abort. Hope this leads > somewhere > > From owner-freebsd-hackers@freebsd.org Mon Mar 6 18:00:41 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6F485CFAEF1 for ; Mon, 6 Mar 2017 18:00:41 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B981810B3; Mon, 6 Mar 2017 18:00:40 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id AADE95A9F27; Mon, 6 Mar 2017 18:00:39 +0000 (UTC) Date: Mon, 6 Mar 2017 18:00:39 +0000 From: Brooks Davis To: rgrimes@FreeBSD.org Cc: Bryan Drewery , freebsd-hackers@FreeBSD.org, Baptiste Daroussin Subject: Re: svn commit: r314693 - head/usr.sbin/rmt Message-ID: <20170306180039.GC84620@spindle.one-eyed-alien.net> References: <1283ca30-a827-8b32-3021-658548447c22@FreeBSD.org> <201703052139.v25Ld6iR084880@pdx.rh.CN85.dnsmgr.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mvpLiMfbWzRoNl4x" Content-Disposition: inline In-Reply-To: <201703052139.v25Ld6iR084880@pdx.rh.CN85.dnsmgr.net> User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 18:00:41 -0000 --mvpLiMfbWzRoNl4x Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Mar 05, 2017 at 01:39:06PM -0800, Rodney W. Grimes wrote: > > On 3/5/17 8:26 AM, Rodney W. Grimes wrote: > > > Moved thread to -hackers for a quick discussion. > > >=20 > > >> On Sun, Mar 05, 2017 at 05:19:28AM -0800, Rodney W. Grimes wrote: > > >>> -- Start of PGP signed section. > > >>>> On Sun, Mar 05, 2017 at 04:09:18AM +0000, Rodney W. Grimes wrote: > > >>>>> Author: rgrimes > > >>>>> Date: Sun Mar 5 04:09:18 2017 > > >>>>> New Revision: 314693 > > >>>>> URL: https://svnweb.freebsd.org/changeset/base/314693 > > >>>>> > > >>>>> Log: > > >>>>> Change /etc/rmt symlink from absolute to relative path, > > >>>>> correcting the mistake made in r6499 > > >>>>> =20 > > >>>>> Approved by: grehan > > >>>>> MFC after: 1 week > > >>>>> > > >>>>> Modified: > > >>>>> head/usr.sbin/rmt/Makefile > > >>>>> > > >>>>> Modified: head/usr.sbin/rmt/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=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > > >>>>> --- head/usr.sbin/rmt/Makefile Sun Mar 5 04:02:47 2017 (r314692) > > >>>>> +++ head/usr.sbin/rmt/Makefile Sun Mar 5 04:09:18 2017 (r314693) > > >>>>> @@ -7,6 +7,6 @@ MAN=3D rmt.8 > > >>>>> # called from /usr/src/etc/Makefile > > >>>>> etc-rmt: > > >>>>> rm -f ${DESTDIR}/etc/rmt > > >>>>> - ln -s ${BINDIR}/rmt ${DESTDIR}/etc/rmt > > >>>>> + ln -s ..${BINDIR}/rmt ${DESTDIR}/etc/rmt > > >>>> > > >>>> I think this should be ${INSTALL_RSYMLINK} ${BINDIR}/rmt ${DESTDIR= }/etc/rmt > > >>> > > >>> find /usr/src | xargs grep INSTALL_RSYM > > >>> (no results) > > >>> > > >>> Sorry, no prior work does this, perhaps once I get done sweeping the > > >>> absolutes out of the tree (about 10 or 15 IIRC) a pass can be made = to > > >>> sweep all ln -s out and propage this internal bsd.lib.mk function o= ut > > >>> to the rest of the source tree? > > >> > > >> There is also no Makefiles that do ls -sf directly beside that one. > > > Unless I have missed a commit: > > > ./crypto/openssh/contrib/cygwin/Makefile: cd $(DESTDIR)$(mandir= )/man1 && ln -s ssh.1.gz slogin.1.gz > > > ./usr.sbin/sendmail/Makefile: ln -sf ${.ALLSRC} ${.TARGET} > > > ./usr.sbin/rmt/Makefile: ln -s ${BINDIR}/rmt ${DESTDIR}/etc/rmt > > > ... > >=20 > > Keep in mind that INSTALL_*SYMLINK should only be used for *installing* > > a symlink, not for intermediate build files. All of the direct 'ln' > > usage in the tree should be not installed. Brooks and I and others have > > done passes before to ensure that any installed symlink uses > > INSTALL_*SYMLINK. The reasoning is that the -DNO_ROOT build requires > > that 'install' be used since it is logging the file in a meta log that > > is later used to build an image from. This is also important for the > > DIRDEPS_BUILD feature. >=20 > In those several passes you have missed at least this one here in rmt > that has been there since the refer commit of r6499. This is not a > new link someone added recently. I simply corrected the arguments to > the command so that we no longer have an absolute link inside > of ${DESTDIR}. The main issue is certainly that we haven't built tools to validate installworld/installkernel. We should be checking that a) every object created in DESTDIR has an entry in METALOG and b) that there is exactly one such entry. Ideally we'd run this in jenkins. -- Brooks --mvpLiMfbWzRoNl4x Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJYvaPHAAoJEKzQXbSebgfAbqgIAJVqx7T2axTZsdW83t8nbPhA NxRDX4yPigr+PGhNUFRmJ5LgHN6THQqOxg+ylnwRStnxrfSy/Jj0mpARnDotVgo/ 2zZ6iHLv/3OnIcG0NXsOW1XYcE7uTfcJLLLCfdhuOD+jLg9TFG4h32blMxiilkUs T/VaNzpnUM2vrcbeh0+HEUSCD+ocSM8UqitCQC9kYkNX5jRtdtuunPOD4uoOeTh9 Mc2CsnM+sXHlsWl/3PGtXoltTDjYmdA8DWEGNAv05LB68z5OFbPG+OJkzGv3BqXN 3xj5giH2pd2uzcO41N1a+wqolRPFlkpb0jHk2gpKnxgsrTiODjJyAzM0mLQKeOA= =Demg -----END PGP SIGNATURE----- --mvpLiMfbWzRoNl4x-- From owner-freebsd-hackers@freebsd.org Tue Mar 7 04:50:43 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 290BFD0134D; Tue, 7 Mar 2017 04:50:43 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EDF66196D; Tue, 7 Mar 2017 04:50:42 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-pg0-x233.google.com with SMTP id b129so74345421pgc.2; Mon, 06 Mar 2017 20:50:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:date:message-id:cc:to:mime-version; bh=a0gIyYotWW2r6nvEwp8wghdNGw5OGaAAi2ZFdZgrh8I=; b=hREQREAahi1sUU0hJKfTn1WeKAg7VktOYIjPG/WyWHwgIxTNFTgecJhlTNNTIpWXUz VPp4jGhxLWINCabNAmrouuiMW87HuF4aCZ7zzOngR3h0IoKooXeswqkY1yZ9+LHZmGOA A+3i8iTUEAq7Ta5p1fhHpbMBZqy69kyzXJKy6oRGUVEjMdD0c+84uHR5Gzb/8BPnMyOV akmD6Lr3k/yGTq97//8+YG7OrPQXXgt6L0LyhvY92kKLR93uvTIrWAhdxswNOKU9ixR0 RXWR/7v7PLowF+JCz5nrVAJa6vDA1ESUXTIcD1ZrpwlNjT0JxSvFpRGArR2tsmc6jeXk +oWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:date:message-id:cc:to:mime-version; bh=a0gIyYotWW2r6nvEwp8wghdNGw5OGaAAi2ZFdZgrh8I=; b=Lj+Lb3M3nYe8IuK945ma3camjAaw15uz2NmMjDPylFGdzk+z17MgSSjL1019YPccoS hmiGk3kh/sGUorQrW0Yj2bMOTlMFaOs7aZn8a2cfRac8Wr/hbBaseL6MUMxlCZZGNewN M8p/TDKCI9xpemdPT2ouoaGqpxixwgNGpf2JZ4p7mRZZwYzJFBrXDrqmgBGVMzVy4Nhe 4T84wcYctYEFEsOMxPPEUeZnMNe/APWdRFT0pmnPoCppvqArnlN3dhnqGn8/wC4e0idL QaUWiqFH0P6yfm0+LKT50MHrm0jl/DQTBUWAzq0EFTy8LhvCRl3V58oE8txcUxaDVTgV LfZw== X-Gm-Message-State: AMke39nSnqtiUtBOlnZxBvWdnNpBpjwUd6Zis1HyNOklVUBKqzGP9Q9v6q638t9wvUz6ZA== X-Received: by 10.99.117.85 with SMTP id f21mr25047428pgn.62.1488862242322; Mon, 06 Mar 2017 20:50:42 -0800 (PST) Received: from pinklady.local (c-73-19-52-228.hsd1.wa.comcast.net. [73.19.52.228]) by smtp.gmail.com with ESMTPSA id v143sm42722037pgb.47.2017.03.06.20.50.41 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 06 Mar 2017 20:50:41 -0800 (PST) From: "Ngie Cooper (yaneurabeya)" X-Pgp-Agent: GPGMail Content-Type: multipart/signed; boundary="Apple-Mail=_806658F5-C68E-4E65-BC78-CCCA416A0B2B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Subject: SRCTOP/OBJTOP refactoring in ^/head Date: Mon, 6 Mar 2017 20:50:40 -0800 Message-Id: <8787E0E4-CD5D-4E53-BDF4-5E0ED1FD7069@gmail.com> Cc: FreeBSD Hackers To: "freebsd-arch@freebsd.org" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 04:50:43 -0000 --Apple-Mail=_806658F5-C68E-4E65-BC78-CCCA416A0B2B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, I=E2=80=99m posting an official follow up to the numerous = commits I=E2=80=99ve been doing on ^/head to convert paths in Makefiles = from .CURDIR/.OBJDIR-relative paths to source (SRCTOP) / object (OBJTOP) = tree relative paths, e.g., like the following make snippet, $ svn diff | less # ... Index: Makefile.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 --- Makefile.inc (revision 314827) +++ Makefile.inc (working copy) @@ -1,3 +1,4 @@ -.if exists(${.CURDIR}/../../Makefile.inc) -.include "${.CURDIR}/../../Makefile.inc" -.endif +FORTUNE_SRC=3D ${SRCTOP}/usr.bin/fortune +FORTUNE_OBJ=3D ${OBJTOP}/usr.bin/fortune + +.include "${SRCTOP}/usr.bin/Makefile.inc=E2=80=9D Index: fortune/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 --- fortune/Makefile (revision 314827) +++ fortune/Makefile (working copy) @@ -3,7 +3,7 @@ PROG=3D fortune MAN=3D fortune.6 -CFLAGS+=3D-DDEBUG -I${.CURDIR}/../strfile +CFLAGS+=3D-DDEBUG -I${FORTUNE_SRC}/strfile .include # ... Doing this has several benefits: 1. The make output is more abbreviated because it=E2=80=99s now = normalized to SRCTOP/OBJTOP. i. This benefits tools that take paths literally, like = Jenkins (it helped reduce the warning count by ~1,500 warnings in = r312513 because Jenkins was double-counting warnings for sys/modules/ath = ). ii. Logfiles will be smaller, which means that data = retention stress from CI services like Jenkins and Travis CI will be = reduced. iii. Less required I/O, which means: I. This reduces needed bandwidth when = transmitting the build output II. Speeds up terminal output. III. Reduces unnecessary writing to disk. 2. It makes it easier for humans to understand the layout of the = tree. 3. It makes it easier for humans/vendors to build on/customize = the components, instead of copy-pasting entire Makefiles and having to = keep them up-to-date, e.g., allows me for instance to .include = usr.sbin/syslogd/Makefile from foo/bar/syslogd/Makefile . Some of my changes I introduced previously manipulated = .CURDIR/.OBJDIR with the :H operator (strip one component, e.g., = foo/bar/baz.c -> foo/bar ). I had 3 individuals (bdrewery, imp, rgrimes) = ask for me to replace all :H uses I introduced in my refactoring with = SRCTOP/OBJTOP paths (I completely agree with the requests =E2=80=94 I = was just trying to keep the spirit of the original Makefiles intact). I will likely go back to committing by individual subdirectories = as the approach I took this past weekend (based on a suggestion from = rgrimes about not committing one directory at a time) was met with some = complaints from users about downstream vendors/projects dealing with = merge conflicts (I don=E2=80=99t care so much about MFCing changes=E2=80=A6= it=E2=80=99s pretty straightforward/mechanical and easier to test one = directory at a time if possible). Questions, comments, and other things (as long as there aren=E2=80= =99t too many torches/pitchforks) are more than welcome. Thanks, -Ngie --Apple-Mail=_806658F5-C68E-4E65-BC78-CCCA416A0B2B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYvjwhAAoJEPWDqSZpMIYV5GQP/iA1oelzKbcK8hvEbWM+6tsh rQ8LEYy4t6JKNk6diwgrVvNazmuIidOVU7u1EWDuMH1e51C6iB8WDRUqSnz7EF65 V2tfcaQ49dxy2FvrGRt/o0G2C2IHfcHbtywIzMeGPhQ0LB1Rc+TmHOrDK+8wvPZx 4DHmktySn4YCp4jNXlGYMqkPdW8ateIlOuOxUqQg5WIBUkf0OmgPqsvPYzYfB08Z fbY2GZAxIci91/488VyIyVKFRyPP/Fyt/Y9D5IEq4WPhx2Hav2cOVYePdUVjhlXD 1lpfX7WkpYXD/oY0Ul53lrCrgL2LzTa3irKBZu0+Do/Co4t2Uu3JJcsE3bbZ0gl+ jPNmx/D5tWgh9jazi07H3YNLoOjc08W7k61qp879qJaiCitpFI4Anrx4NuOWLPhe 7CehsIZQvMiXuo2RaK4L+5hzvJ0jCrlfZVKXI7zLSveo8ov4O591OITWHfWTEL2+ sq4+pi+Q9u7qU4wyiq0DcrhrfK5iD6RW8n1se/+UDl0B1LyRuZzJ6/MBT93L2iF+ /ZqqPadbGYKnQc+F59fQr3iCxZ+wrRUFXRgVGPb9K9gHQdJBVH7I1OcaT9xcGb97 VgLo5AJtUWu0VXLqaXTzMagmflhSOByZIKfv4DFsT3X2+YySnjVsp9Bl9zlsRsv4 SPJ2FIj9Qy11SRE/DP2e =eFbb -----END PGP SIGNATURE----- --Apple-Mail=_806658F5-C68E-4E65-BC78-CCCA416A0B2B-- From owner-freebsd-hackers@freebsd.org Tue Mar 7 11:33:31 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7E5BDD01246 for ; Tue, 7 Mar 2017 11:33:31 +0000 (UTC) (envelope-from emorrasg@yahoo.es) Received: from nm17-vm8.bullet.mail.ir2.yahoo.com (nm17-vm8.bullet.mail.ir2.yahoo.com [212.82.96.223]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E7A13126C for ; Tue, 7 Mar 2017 11:33:30 +0000 (UTC) (envelope-from emorrasg@yahoo.es) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.es; s=s2048; t=1488886222; bh=azwDxYTsSgl9Tfatk2GcohnRQf5j74NKSRMhf9jaQNI=; h=Date:From:To:Subject:From:Subject; b=WOPNe5DFJ4f0fISt6u8pKIJyp5K4F3HPnaGz+Mw3WuyuR8ZDjcJoE5FKKsRIdWD7SgR/p5ZOWwj0fSnmT6PPlCssk+xP5JNg0xFiC6XK2/WlWX4WDZtoSPXzDtNJPPUeDKG1Yi6moyQs38/BBdrZDWW1/Xf2k+sIrnb3jDE5SALuS5cx4x15805whUyKRDRKqfVNNtcq4yGea13ukA0azDnJPlHSomb5xLkz/Pl9LDYfsntMVdK6HC5mwFPG5buUDQVJuQE1qG8ufVCYTz4Fy1xt5X4Rt6lbRQl+JZFDBkigy8X1b4cRZLLl0WSCepnTYoD73CIWJqAOYrqTaD710g== Received: from [212.82.98.50] by nm17.bullet.mail.ir2.yahoo.com with NNFMP; 07 Mar 2017 11:30:22 -0000 Received: from [46.228.39.100] by tm3.bullet.mail.ir2.yahoo.com with NNFMP; 07 Mar 2017 11:30:22 -0000 Received: from [127.0.0.1] by smtp137.mail.ir2.yahoo.com with NNFMP; 07 Mar 2017 11:30:22 -0000 X-Yahoo-Newman-Id: 276562.96803.bm@smtp137.mail.ir2.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: A8UW8PQVM1k.rdkWzUTrAeCEpK3udWQaJjC7EhmK8AfpHGw 7YMQsHM0teQEOpZXlyt783AVzUFM1F3IdBR5Cww83oQlTXuhhJ7CjAX7Gu_j nOBCQGWB3qqxuvVxlntBsBwlIbC1chwBGRUBWQBhw33yytlszVOt0uwAgbQO H1FB9_DI2jn3gCHwzSXjzQ1nM.k6Va8B9YA63k8YojcK_7tBAYhc_MQkdEBq Xo48OYOjw34_FN2I2o2dE6CyrZL5mggXU_RG8hX0OESrBdvNHvwn7_XOdJBE awdLiSwVpNA_H6fpSSyUkGxXNP6e7cdHcU_M1vOlZMwRs89SzSa1tf6wgpDp IeQQSVJ8M_x.YdcJwsxpjjdU6OEsOVfsIuz4EWzLu.TDva3UHyCNTFN8k3TN BPR5.7lOP2BdkNaC.toftrj_gWOtaYRXUzZnJQ32v9pEZJEZYaY54zCVtALj inVj.tRlpHDH3PyYOGAU3WKs41Lbh_oHUvGKYj66ySquET6RoIvRzNOfBvvQ bGOzdJM_z..2R.0K04qljc70sbCqbHFpJxj0PAHBzJsq5STjD41kCuuEchOv 6acOWTO2_F0bR9rL_ X-Yahoo-SMTP: mX392iiswBAeJNdO_s.EW62LZDJR Date: Tue, 7 Mar 2017 12:31:57 +0100 From: Eduardo Morras To: freebsd-hackers@freebsd.org Subject: Sendfile and sctp questions Message-Id: <20170307123157.50ce7fc601f50bbc476614b5@yahoo.es> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 11:33:31 -0000 Hello, I'm developing sctp programs and want to use zero-copy sendfile(2) with SOCK_STREAM sctp connection type, I used sendfile with tcp sockets without problems, but under sctp I have some questions: a) Is this the right list? b) How can I be sure that it's really a zero-copy? c) Will send it as a regular "fair player" message inside the sctp association or will cheat blocking other messages until file transfer ends? d) Will corrupt my association and shoot my multiple feet? I dont' use a unique message, I send multiple messages simultaneusly. Thanks in Advance --- --- Eduardo Morras From owner-freebsd-hackers@freebsd.org Tue Mar 7 18:38:59 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 117ACD004F1 for ; Tue, 7 Mar 2017 18:38:59 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from marvin.harmless.hu (marvin.harmless.hu [195.56.55.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C9F7C1B15 for ; Tue, 7 Mar 2017 18:38:58 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from 84-236-108-40.pool.digikabel.hu ([84.236.108.40] helo=[10.219.16.1]) by marvin.harmless.hu with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88 (FreeBSD)) (envelope-from ) id 1clK0d-000A9T-5W for freebsd-hackers@freebsd.org; Tue, 07 Mar 2017 18:38:55 +0000 To: freebsd-hackers@freebsd.org From: Gergely Czuczy Subject: SPI communication from userspace Message-ID: <313fdb93-92c6-609f-57c9-3dec0ce84798@harmless.hu> Date: Tue, 7 Mar 2017 19:38:54 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 18:38:59 -0000 Hello, I would like to ask for some help, on how to communicate with an Adafruit MAX31856 breakout board over the SPI bus under freebsd, on an RPi3. As far as I can see, the spibus(4) driver is there, but there's no driver for this chip, and I can't access the SPI calls from userspace either. I could try to write a driver, however I don't have the experience working with the FreeBSD kernel. SPI communication is quite simple, you send a single byte to the device, and if the MSB was 1 it's a write, if it's 0 it's a read operation, remaining 7 bits is the address. Then you either write a byte to the address, or wait for the device to respond by the next cycle. Other difficulty is, the RPi3 provides 2 PINs for CS, and I have 3 devices, so I either have to use generic GPIO PINs, or de/multiplex it, which might require a userspace call for device selection on the bus. So, how should I start? What would be a good way to do the userspace-kernelspace communication? Also, I'm not sure whether I should do a specific driver for this device, or a generic one, and writing the specifics in userspace. Also, if you could point me to some documentation which would explain how to work with the kernel, make a custom module, the possible user/kernelspace communication possibilities, and how to call another kernel module's functions, would be quite appreciated. Also, if someone knows where could I find docs on the spibus driver, would be quite nice since, it's just code so far. Best regards, Gergely From owner-freebsd-hackers@freebsd.org Tue Mar 7 19:04:18 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 67080D00FA1 for ; Tue, 7 Mar 2017 19:04:18 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [45.55.20.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3DA291249 for ; Tue, 7 Mar 2017 19:04:17 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from [127.0.0.1] (helo=id.bluezbox.com) by id.bluezbox.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87 (FreeBSD)) (envelope-from ) id 1clKP1-000FxU-OC; Tue, 07 Mar 2017 11:04:14 -0800 Received: (from gonzo@localhost) by id.bluezbox.com (8.15.2/8.15.2/Submit) id v27J47f8061347; Tue, 7 Mar 2017 11:04:07 -0800 (PST) (envelope-from gonzo@bluezbox.com) X-Authentication-Warning: id.bluezbox.com: gonzo set sender to gonzo@bluezbox.com using -f Date: Tue, 7 Mar 2017 11:04:06 -0800 From: Oleksandr Tymoshenko To: Gergely Czuczy Cc: freebsd-hackers@freebsd.org Subject: Re: SPI communication from userspace Message-ID: <20170307190406.GA61203@bluezbox.com> References: <313fdb93-92c6-609f-57c9-3dec0ce84798@harmless.hu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <313fdb93-92c6-609f-57c9-3dec0ce84798@harmless.hu> X-Operating-System: FreeBSD/11.0-RELEASE-p2 (amd64) User-Agent: Mutt/1.6.1 (2016-04-27) X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: Gergely Czuczy (gergely.czuczy@harmless.hu) wrote: > Hello, > > I would like to ask for some help, on how to communicate with an > Adafruit MAX31856 breakout board over the SPI bus under freebsd, on an > RPi3. As far as I can see, the spibus(4) driver is there, but there's no > driver for this chip, and I can't access the SPI calls from userspace > either. I could try to write a driver, however I don't have the > experience working with the FreeBSD kernel. > > SPI communication is quite simple, you send a single byte to the device, > and if the MSB was 1 it's a write, if it's 0 it's a read operation, > remaining 7 bits is the address. Then you either write a byte to the > address, or wait for the device to respond by the next cycle. > > Other difficulty is, the RPi3 provides 2 PINs for CS, and I have 3 > devices, so I either have to use generic GPIO PINs, or de/multiplex it, > which might require a userspace call for device selection on the bus. > > So, how should I start? What would be a good way to do the > userspace-kernelspace communication? Also, I'm not sure whether I should > do a specific driver for this device, or a generic one, and writing the > specifics in userspace. > > Also, if you could point me to some documentation which would explain > how to work with the kernel, make a custom module, the possible > user/kernelspace communication possibilities, and how to call another > kernel module's functions, would be quite appreciated. Also, if someone > knows where could I find docs on the spibus driver, would be quite nice > since, it's just code so far. [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: github.com] -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 19:04:18 -0000 Gergely Czuczy (gergely.czuczy@harmless.hu) wrote: > Hello, > > I would like to ask for some help, on how to communicate with an > Adafruit MAX31856 breakout board over the SPI bus under freebsd, on an > RPi3. As far as I can see, the spibus(4) driver is there, but there's no > driver for this chip, and I can't access the SPI calls from userspace > either. I could try to write a driver, however I don't have the > experience working with the FreeBSD kernel. > > SPI communication is quite simple, you send a single byte to the device, > and if the MSB was 1 it's a write, if it's 0 it's a read operation, > remaining 7 bits is the address. Then you either write a byte to the > address, or wait for the device to respond by the next cycle. > > Other difficulty is, the RPi3 provides 2 PINs for CS, and I have 3 > devices, so I either have to use generic GPIO PINs, or de/multiplex it, > which might require a userspace call for device selection on the bus. > > So, how should I start? What would be a good way to do the > userspace-kernelspace communication? Also, I'm not sure whether I should > do a specific driver for this device, or a generic one, and writing the > specifics in userspace. > > Also, if you could point me to some documentation which would explain > how to work with the kernel, make a custom module, the possible > user/kernelspace communication possibilities, and how to call another > kernel module's functions, would be quite appreciated. Also, if someone > knows where could I find docs on the spibus driver, would be quite nice > since, it's just code so far. Hi Gregory, To access raw SPI from userland you can use spidev. Unfortunately functionality of this driver is limited and there is not much documentation around. There are plans to replace it with more versatile linux-like API but no actual implementation yet. I put together some demos for spidev: https://github.com/gonzoua/freebsd-embedded-demos More info on these demos: https://kernelnomicon.org/?p=757 As an alternative you can code custom driver that talks to SPI bus in kernel and exposes control to userland via sysctls. You can get some references on how to use in-kernel SPI API looking at mx25l flash driver: https://github.com/freebsd/freebsd/blob/master/sys/dev/flash/mx25l.c And use DS3231 driver as a reference for reporting temperature as sysctl: https://github.com/freebsd/freebsd/blob/master/sys/dev/iicbus/ds3231.c Actual implementation will depend on your requirements -- gonzo From owner-freebsd-hackers@freebsd.org Tue Mar 7 20:00:09 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 453F7D026A7 for ; Tue, 7 Mar 2017 20:00:09 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from marvin.harmless.hu (marvin.harmless.hu [195.56.55.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0984A1836 for ; Tue, 7 Mar 2017 20:00:08 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from 84-236-108-40.pool.digikabel.hu ([84.236.108.40] helo=[10.219.16.1]) by marvin.harmless.hu with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88 (FreeBSD)) (envelope-from ) id 1clLHC-000AiU-Rr; Tue, 07 Mar 2017 20:00:06 +0000 Subject: Re: SPI communication from userspace To: Oleksandr Tymoshenko References: <313fdb93-92c6-609f-57c9-3dec0ce84798@harmless.hu> <20170307190406.GA61203@bluezbox.com> Cc: freebsd-hackers@freebsd.org From: Gergely Czuczy Message-ID: Date: Tue, 7 Mar 2017 21:00:05 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <20170307190406.GA61203@bluezbox.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 20:00:09 -0000 On 2017. 03. 07. 20:04, Oleksandr Tymoshenko wrote: > Gergely Czuczy (gergely.czuczy@harmless.hu) wrote: >> Hello, >> >> I would like to ask for some help, on how to communicate with an >> Adafruit MAX31856 breakout board over the SPI bus under freebsd, on an >> RPi3. As far as I can see, the spibus(4) driver is there, but there's no >> driver for this chip, and I can't access the SPI calls from userspace >> either. I could try to write a driver, however I don't have the >> experience working with the FreeBSD kernel. >> >> SPI communication is quite simple, you send a single byte to the device, >> and if the MSB was 1 it's a write, if it's 0 it's a read operation, >> remaining 7 bits is the address. Then you either write a byte to the >> address, or wait for the device to respond by the next cycle. >> >> Other difficulty is, the RPi3 provides 2 PINs for CS, and I have 3 >> devices, so I either have to use generic GPIO PINs, or de/multiplex it, >> which might require a userspace call for device selection on the bus. >> >> So, how should I start? What would be a good way to do the >> userspace-kernelspace communication? Also, I'm not sure whether I should >> do a specific driver for this device, or a generic one, and writing the >> specifics in userspace. >> >> Also, if you could point me to some documentation which would explain >> how to work with the kernel, make a custom module, the possible >> user/kernelspace communication possibilities, and how to call another >> kernel module's functions, would be quite appreciated. Also, if someone >> knows where could I find docs on the spibus driver, would be quite nice >> since, it's just code so far. > Hi Gregory, > > To access raw SPI from userland you can use spidev. Unfortunately > functionality of this driver is limited and there is not much > documentation around. There are plans to replace it with more > versatile linux-like API but no actual implementation yet. This is quite interesting, actually seems like the stuff I wanted to write. However, I've found spigen.c in the kernel source, but I couldn't find how to load it. There are no modules under /boot/kernel/ and kldload -v doesn't show it up either. Also, there are no /dev/spi* devices, however spibus is loaded: # kldstat -v | grep spi 259 simplebus/bcm2835_spi 109 spi/spibus 108 spi/ofw_spibus Could you please give me some help how to load it? Might be the stuff I'm actually looking for. Only question is, whether does it allows me to do a manual CS, instead of automatically using the dedicated pins. > > I put together some demos for spidev: > https://github.com/gonzoua/freebsd-embedded-demos > > More info on these demos: https://kernelnomicon.org/?p=757 > > As an alternative you can code custom driver that talks to SPI > bus in kernel and exposes control to userland via sysctls. > > You can get some references on how to use in-kernel SPI API looking > at mx25l flash driver: > https://github.com/freebsd/freebsd/blob/master/sys/dev/flash/mx25l.c > > And use DS3231 driver as a reference for reporting temperature as > sysctl: > https://github.com/freebsd/freebsd/blob/master/sys/dev/iicbus/ds3231.c > > Actual implementation will depend on your requirements Thank you, I will take a look at these as well. From owner-freebsd-hackers@freebsd.org Tue Mar 7 20:04:39 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 25750D028F6 for ; Tue, 7 Mar 2017 20:04:39 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [45.55.20.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EB2EC1C94 for ; Tue, 7 Mar 2017 20:04:38 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from [127.0.0.1] (helo=id.bluezbox.com) by id.bluezbox.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87 (FreeBSD)) (envelope-from ) id 1clLLZ-000G5x-P5; Tue, 07 Mar 2017 12:04:38 -0800 Received: (from gonzo@localhost) by id.bluezbox.com (8.15.2/8.15.2/Submit) id v27K4bRi061872; Tue, 7 Mar 2017 12:04:37 -0800 (PST) (envelope-from gonzo@bluezbox.com) X-Authentication-Warning: id.bluezbox.com: gonzo set sender to gonzo@bluezbox.com using -f Date: Tue, 7 Mar 2017 12:04:36 -0800 From: Oleksandr Tymoshenko To: Gergely Czuczy Cc: freebsd-hackers@freebsd.org Subject: Re: SPI communication from userspace Message-ID: <20170307200436.GA61854@bluezbox.com> References: <313fdb93-92c6-609f-57c9-3dec0ce84798@harmless.hu> <20170307190406.GA61203@bluezbox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD/11.0-RELEASE-p2 (amd64) User-Agent: Mutt/1.6.1 (2016-04-27) X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: Gergely Czuczy (gergely.czuczy@harmless.hu) wrote: > > > On 2017. 03. 07. 20:04, Oleksandr Tymoshenko wrote: > > Gergely Czuczy (gergely.czuczy@harmless.hu) wrote: > >> Hello, > >> > >> I would like to ask for some help, on how to communicate with an > >> Adafruit MAX31856 breakout board over the SPI bus under freebsd, on an > >> RPi3. As far as I can see, the spibus(4) driver is there, but there's no > >> driver for this chip, and I can't access the SPI calls from userspace > >> either. I could try to write a driver, however I don't have the > >> experience working with the FreeBSD kernel. > >> > >> SPI communication is quite simple, you send a single byte to the device, > >> and if the MSB was 1 it's a write, if it's 0 it's a read operation, > >> remaining 7 bits is the address. Then you either write a byte to the > >> address, or wait for the device to respond by the next cycle. > >> > >> Other difficulty is, the RPi3 provides 2 PINs for CS, and I have 3 > >> devices, so I either have to use generic GPIO PINs, or de/multiplex it, > >> which might require a userspace call for device selection on the bus. > >> > >> So, how should I start? What would be a good way to do the > >> userspace-kernelspace communication? Also, I'm not sure whether I should > >> do a specific driver for this device, or a generic one, and writing the > >> specifics in userspace. > >> > >> Also, if you could point me to some documentation which would explain > >> how to work with the kernel, make a custom module, the possible > >> user/kernelspace communication possibilities, and how to call another > >> kernel module's functions, would be quite appreciated. Also, if someone > >> knows where could I find docs on the spibus driver, would be quite nice > >> since, it's just code so far. > > Hi Gregory, > > > > To access raw SPI from userland you can use spidev. Unfortunately > > functionality of this driver is limited and there is not much > > documentation around. There are plans to replace it with more > > versatile linux-like API but no [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: harmless.hu] -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 20:04:39 -0000 Gergely Czuczy (gergely.czuczy@harmless.hu) wrote: > > > On 2017. 03. 07. 20:04, Oleksandr Tymoshenko wrote: > > Gergely Czuczy (gergely.czuczy@harmless.hu) wrote: > >> Hello, > >> > >> I would like to ask for some help, on how to communicate with an > >> Adafruit MAX31856 breakout board over the SPI bus under freebsd, on an > >> RPi3. As far as I can see, the spibus(4) driver is there, but there's no > >> driver for this chip, and I can't access the SPI calls from userspace > >> either. I could try to write a driver, however I don't have the > >> experience working with the FreeBSD kernel. > >> > >> SPI communication is quite simple, you send a single byte to the device, > >> and if the MSB was 1 it's a write, if it's 0 it's a read operation, > >> remaining 7 bits is the address. Then you either write a byte to the > >> address, or wait for the device to respond by the next cycle. > >> > >> Other difficulty is, the RPi3 provides 2 PINs for CS, and I have 3 > >> devices, so I either have to use generic GPIO PINs, or de/multiplex it, > >> which might require a userspace call for device selection on the bus. > >> > >> So, how should I start? What would be a good way to do the > >> userspace-kernelspace communication? Also, I'm not sure whether I should > >> do a specific driver for this device, or a generic one, and writing the > >> specifics in userspace. > >> > >> Also, if you could point me to some documentation which would explain > >> how to work with the kernel, make a custom module, the possible > >> user/kernelspace communication possibilities, and how to call another > >> kernel module's functions, would be quite appreciated. Also, if someone > >> knows where could I find docs on the spibus driver, would be quite nice > >> since, it's just code so far. > > Hi Gregory, > > > > To access raw SPI from userland you can use spidev. Unfortunately > > functionality of this driver is limited and there is not much > > documentation around. There are plans to replace it with more > > versatile linux-like API but no actual implementation yet. > This is quite interesting, actually seems like the stuff I wanted to > write. However, I've found spigen.c in the kernel source, but I couldn't > find how to load it. There are no modules under /boot/kernel/ and > kldload -v doesn't show it up either. Also, there are no /dev/spi* > devices, however spibus is loaded: > # kldstat -v | grep spi > 259 simplebus/bcm2835_spi > 109 spi/spibus > 108 spi/ofw_spibus > > Could you please give me some help how to load it? Might be the stuff > I'm actually looking for. Only question is, whether does it allows me to > do a manual CS, instead of automatically using the dedicated pins. You will have to modify kernel config to add "device spigen" and recompile kernel. I will be adding module for spigen soon though. spigen API does not have neither CS control nor SPI mode control that's why there are plans to replace it with more flexible API. -- gonzo From owner-freebsd-hackers@freebsd.org Tue Mar 7 20:29:48 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E157AD02089; Tue, 7 Mar 2017 20:29:48 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-ua0-x244.google.com (mail-ua0-x244.google.com [IPv6:2607:f8b0:400c:c08::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A72B81A98; Tue, 7 Mar 2017 20:29:48 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: by mail-ua0-x244.google.com with SMTP id 72so2676754uaf.1; Tue, 07 Mar 2017 12:29:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=c7V23IEUlgIt6PhlZHJt9kZ8ynZqdukuFygrFP5v0yk=; b=MlMUlTMMySclqV7c/eUrxqXstSi2Tsa93vDMR8fitNcxDCBy7nm2xa7yQEf8IOCrkT 5YQltvsRDWVYmta18ihFUslIu8k8Y/vK/ZJXf7uXzRiALlYkfX7ipbS7g8uVjJbI0jal koWIS2uz4Guw2i+lsPCzDFyxsNVFRpA6zXcwtZOklf0w82EEeExhWnQcbRWgH1gh57L7 a0NV9ceCWedSxjqQAioXAEXejh2doo/n8XSWLM7VvpBAmt0Tg/6VRnS674HwLOfE/5/O Tm2mgSfijCYtG68xtdGm5WaumRdVjsC7PCJU14e4tlmz2mcKajNT0iwl/M5Dper60q1/ 2JAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=c7V23IEUlgIt6PhlZHJt9kZ8ynZqdukuFygrFP5v0yk=; b=so0FuFe4XjEBJVGx4mSuTZzBYEUzgbM4z8iXXm6fhio/ebVn3kWZ+EMcMKxCa7lI8s m5pmdWi5/iqlrr+HtHc0cxW4zszgipBjXp61H082GtJaFUipvgvjQBWij3/rEG2ZyAc4 CwEa+DEujPA9EBtniFFaO7T97U4TWM3ns8WBiFJF3DsqeUvv36FmQ1R0Q5njV9xLBR/j nE+04XNAVSfUhspRPfqQ1abayVfmtub6VX9wRaUeIfUHK//cO6+jD2xrrPoCwbVYaKm1 vuD1S554SDRCbRoK61ygTyN/HXI4ipmRi9l/EVvYm9Zc7Ci4fRnOAFwrHeV/JRQYS/jz OfkA== X-Gm-Message-State: AMke39kJOA4DnlK8IQfp+flYzhRs0/X6/DlIj4crCM49ymtd2AkO+hL/amUDKkHqZpCCK/raRPqiuyKsMf7aoQ== X-Received: by 10.176.83.142 with SMTP id k14mr1259753uaa.64.1488918587627; Tue, 07 Mar 2017 12:29:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.48.143 with HTTP; Tue, 7 Mar 2017 12:29:07 -0800 (PST) From: grarpamp Date: Tue, 7 Mar 2017 15:29:07 -0500 Message-ID: Subject: WikiLeaks CIA Exploits: FreeBSD References Within To: freebsd-security@freebsd.org Cc: freebsd-hackers@freebsd.org, freebsd-questions@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Tue, 07 Mar 2017 20:56:27 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 20:29:49 -0000 https://search.wikileaks.org/?q=freebsd Currently returns many pages similarly named... "Shell Code Database This page includes local links to a shellcode database discovered at shell-storm.org." (And a pentest report mention from much older HBGary. Plus some other unlikely miscellaneous hits.) As this is only part 1 of a supposedly multipart release of potentially new exploits, it makes sense to establish ongoing search and review of this dataset for any as yet unfixed exploits. Included as fyi on cc: questions@ and hackers@ . Discussion is likely better moved in reply to just security@ , with reporting of any actual unfixed exploits found to the FreeBSD Bugzilla tracker. From owner-freebsd-hackers@freebsd.org Wed Mar 8 02:12:11 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1E835CFB277 for ; Wed, 8 Mar 2017 02:12:11 +0000 (UTC) (envelope-from bob@immure.com) Received: from maul.immure.com (108-84-10-9.lightspeed.austtx.sbcglobal.net [108.84.10.9]) by mx1.freebsd.org (Postfix) with ESMTP id F3D48173B for ; Wed, 8 Mar 2017 02:12:10 +0000 (UTC) (envelope-from bob@immure.com) Received: from rancor.immure.com ([10.1.132.9]) by maul.immure.com with esmtp (Exim 4.88 (FreeBSD)) (envelope-from ) id 1clQq7-000Dnm-34 for freebsd-hackers@freebsd.org; Tue, 07 Mar 2017 19:56:31 -0600 Received: from rancor.immure.com (localhost [127.0.0.1]) by rancor.immure.com (8.15.2/8.15.2) with ESMTP id v281uUhm014560 for ; Tue, 7 Mar 2017 19:56:30 -0600 (CST) (envelope-from bob@rancor.immure.com) Received: (from bob@localhost) by rancor.immure.com (8.15.2/8.14.9/Submit) id v281uUMW014559 for freebsd-hackers@freebsd.org; Tue, 7 Mar 2017 19:56:30 -0600 (CST) (envelope-from bob) Date: Tue, 7 Mar 2017 19:56:30 -0600 From: Bob Willcox To: hackers list Subject: Help with silent reboot of 10.3-stable system Message-ID: <20170308015630.GE22199@rancor.immure.com> Reply-To: Bob Willcox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.7.1 (2016-10-04) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 02:12:11 -0000 Over the past month or so my network fileserver system (NFS support for my entire, small, network) has begun silently rebooting itself. Here is the uname -a output: FreeBSD vader.immure.com 10.3-STABLE FreeBSD 10.3-STABLE #15 r313997: Mon Feb 20 14:40:00 CST 2017 bob@vader.immure.com:/usr/obj/usr/src/sys/GENERIC amd64 At first I suspected that it might be the power supply as it was a couple of years old so I replaced that. Unfortunately, it has begun doing it again (had a couple of weeks respite) so now my suspicions seem to have been incorrect. I was hoping that someone might be able to give me some clues on what I can do to reveal the problem. Are there any general debug settings for the kernel (or elsewhere) that would maybe give an indication of why it is being rebooted (assuming it's a software problem)? Thanks for any suggestions you may have! Bob -- Bob Willcox | If a program is useful, it will be changed. bob@immure.com | Austin, TX | From owner-freebsd-hackers@freebsd.org Wed Mar 8 02:36:24 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B8F81CFBE56; Wed, 8 Mar 2017 02:36:24 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 53F181643; Wed, 8 Mar 2017 02:36:23 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 12074424-697ff7000000628d-fa-58bf6e1bba52 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id F2.3A.25229.B1E6FB85; Tue, 7 Mar 2017 21:36:12 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id v282aBR0028074; Tue, 7 Mar 2017 21:36:11 -0500 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v282a7an017940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 7 Mar 2017 21:36:10 -0500 Date: Tue, 7 Mar 2017 20:36:07 -0600 From: Benjamin Kaduk To: freebsd-hackers@FreeBSD.org Cc: freebsd-current@FreeBSD.org Subject: Call for 2017Q1 quarterly status reports Message-ID: <20170308023607.GG30306@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.6.1 (2016-04-27) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDIsWRmVeSWpSXmKPExsUixCmqrSuTtz/C4MQHfYs5bz4wWWzf/I/R gcljxqf5LAGMUVw2Kak5mWWpRfp2CVwZ2+fOYC6YyV1x6PFk5gbG5ZxdjJwcEgImEi3T77J0 MXJxCAm0MUm07DjMBuFsYJRovXORGaRKSOAKk8SKXvsuRg4OFgEViSXvzEHCbAJqEutXXAMr ERGQl9jX9J4dxGYGsn9tbQKzhQUMJT413gGr4QVatuTncxYIW1Di5MwnLBD1WhI3/r1kAhnP LCAtsfwfB0hYVEBZomHGA+YJjHyzkHTMQtIxC6FjASPzKkbZlNwq3dzEzJzi1GTd4uTEvLzU Il1zvdzMEr3UlNJNjKBAY3dR2cHY3eN9iFGAg1GJh/fDqX0RQqyJZcWVuYcYJTmYlER5D2bu jxDiS8pPqcxILM6ILyrNSS0+xCjBwawkwttuCZTjTUmsrEotyodJSXOwKInzims0RggJpCeW pGanphakFsFkZTg4lCR4PXKBGgWLUtNTK9Iyc0oQ0kwcnCDDeYCGK+aADC8uSMwtzkyHyJ9i VJQS59UHSQiAJDJK8+B6QYlAInt/zStGcaBXhHnXg1TxAJMIXPcroMFMQIO1XfeCDC5JREhJ NTCWFj096HEkZM3ysKe57LzVpv9/sRSe33Dm5M9kjo1tqlpCMzew7fom396Xy7znT4jwmiN/ 1tys+nz62/NOyTXSu7ZMaBJVtwrf62V04sOa4rBJC2Y75JwpTTqhynpj9dpTzWXX1nd8d3XI Ym1eubd+AV/rocdOmt1eutXbLxqu2x7/7XDI5w83lFiKMxINtZiLihMB2RSYuN8CAAA= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 02:36:24 -0000 Dear FreeBSD Community, The deadline for the next FreeBSD Quarterly Status update is April 7, 2017, for work done in January through March. Status report submissions do not need to be very long. They may be about anything happening in the FreeBSD project and community, and provide a great way to inform FreeBSD users and developers about work that is underway and completed. Submission of reports is not restricted to committers; anyone doing anything interesting and FreeBSD related can -- and should -- write one! The preferred and easiest submission method is to use the XML generator [1] with the results emailed to the status report team at monthly@FreeBSD.org . (Do be sure, though, to save the form output and not the form itself!) There is also an XML template [2] that can be filled out manually and attached if preferred. For the expected content and style, please study our guidelines on how to write a good status report [3]. You can also review previous issues [4][5] for ideas on the style and format. We look forward to seeing your 2016Q4 reports! Thanks, Ben (on behalf of monthly@) [1] https://www.FreeBSD.org/cgi/monthly.cgi [2] https://www.FreeBSD.org/news/status/report-sample.xml [3] https://www.FreeBSD.org/news/status/howto.html [4] https://www.FreeBSD.org/news/status/report-2016-07-2016-09.html [5] https://www.FreeBSD.org/news/status/report-2016-10-2016-12.html From owner-freebsd-hackers@freebsd.org Wed Mar 8 08:28:28 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B458AD00EE0 for ; Wed, 8 Mar 2017 08:28:28 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9888B1CBB; Wed, 8 Mar 2017 08:28:28 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from Xins-MBP.ut.rhv.delphij.net (unknown [IPv6:2601:646:8882:752a:a8d6:fd69:266d:e100]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id F2701228C2; Wed, 8 Mar 2017 00:28:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1488961702; x=1488976102; bh=9iL3BpKBN21Vzj112WUOG9QdxNn+VuUiWSKJNbm7K/E=; h=Cc:To:From:Subject:Date; b=Fq4DX5bBqOcwvHYOy2NVS1amu4zkhe1hGtCJXorQIrSXZI/cTpdcAz36P3mhRMmCw RyN0wG+wYLw65gjp9WDfCg+2H3td2URthAhk8jv/hGssbIbcbUlXCCbB6CBlBD5npd 4uPOEMyVNOg9YEgGoHGOHnLmZHP0dPQeWkttMlwc= Cc: d@delphij.net To: Baptiste Daroussin , "freebsd-hackers@freebsd.org" , theraven@freebsd.org From: Xin Li Subject: Why en_US.UTF-8 locale consider a < A? Message-ID: <062a0098-1975-6d2b-b017-f623e46ca20b@delphij.net> Date: Wed, 8 Mar 2017 00:28:16 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="2uO2WtiBGsEunjP2AijJAEmEua5EBi2bi" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 08:28:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2uO2WtiBGsEunjP2AijJAEmEua5EBi2bi Content-Type: multipart/mixed; boundary="hSbMb4m6mGil29OljLiVnhJvbOfcxU3ir"; protected-headers="v1" From: Xin Li To: Baptiste Daroussin , "freebsd-hackers@freebsd.org" , theraven@freebsd.org Cc: d@delphij.net Message-ID: <062a0098-1975-6d2b-b017-f623e46ca20b@delphij.net> Subject: Why en_US.UTF-8 locale consider a < A? --hSbMb4m6mGil29OljLiVnhJvbOfcxU3ir Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, I recently noticed that when LANG and LC_CTYPE are set to en_US.UTF-8, the following file: %%%%% 1 2 A a B b %%%% I got: $ LANG=3DC LC_CTYPE=3DC sort testcase 1 2 A B a b $ LANG=3Den_US.UTF-8 LC_CTYPE=3Den_US.UTF-8 sort testcase 1 2 a A b B Is this result correct? It matches some Debian behavior but not macOS behavior. Cheers, --hSbMb4m6mGil29OljLiVnhJvbOfcxU3ir-- --2uO2WtiBGsEunjP2AijJAEmEua5EBi2bi Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYv8CkAAoJEJW2GBstM+nsPrYQAKCmyXuN6kMAWriAW3o9+30a ciPBjVn+Z0Vf3Dj9yYYS/5UI2iJ4jEbGa5VPxNwH1GC4PYbB42Ngx3R4SNvE8keW vwgfd8/taZWUkRFFBnvKK+ItTeVjx6OnlwoWsPiwIpF/XCIFYXlVJQgk6tNezhim BMuBF3ha4bT33QAfMGL+hlDpm2mvvr3Lx5/qxgQc8+qmLLWx0VuKgn/H1B2GIeLd 50RG9wyJ5bV0i0Xang2fqgzWvUXk2PmiZtsIqdaN+B+kPf6GWWVNqCiXa7Gfns7T 8/V9Zm3NT/B8Ao/cuyxI/joMV1ioWdufttnl1gAceZCGiZMcAXw2mmTZliLBed6d hvdOrrnTOGpj8ymVIPjVTX4xRCxtKAYGG2TGOkT+1RXGIHR9qKlGv+txksFv9DXI MllwEq2QO+/4tbW55akA/I66An21xEK2XsARFIRJqpuda/Tmc0RVeeb3WyigTlhT kkEqJUNIzTITwri8UuXcg1PfLEB6xUzeoR0JgxMYuN/Hfmy0cxA1qkXTJ/b7l8t7 V40kzj/cTYvDt5y/7QHsexV2FT0B3yfb4Eexn4tbFmd5Unp1Z2K2HdaMLt/KKAip klhWkX2T3VH658Psb7DGZznqPQFciF2BpRyhnbBUXQGyYZw6ZiH4uXun21VUEQrp +9sKJEgvJ8dsHmAXWTub =jDQN -----END PGP SIGNATURE----- --2uO2WtiBGsEunjP2AijJAEmEua5EBi2bi-- From owner-freebsd-hackers@freebsd.org Wed Mar 8 08:40:48 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 97D3FD01255 for ; Wed, 8 Mar 2017 08:40:48 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 75CB5126B; Wed, 8 Mar 2017 08:40:48 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1235) id BD6532A00; Wed, 8 Mar 2017 08:40:47 +0000 (UTC) Date: Wed, 8 Mar 2017 09:40:47 +0100 From: Baptiste Daroussin To: Xin Li Cc: "freebsd-hackers@freebsd.org" , theraven@freebsd.org, d@delphij.net Subject: Re: Why en_US.UTF-8 locale consider a < A? Message-ID: <20170308084047.qc2j3vnrh5hycg32@ivaldir.net> References: <062a0098-1975-6d2b-b017-f623e46ca20b@delphij.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ndygghjg7rmiqrog" Content-Disposition: inline In-Reply-To: <062a0098-1975-6d2b-b017-f623e46ca20b@delphij.net> User-Agent: NeoMutt/20170225 (1.8.0) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 08:40:48 -0000 --ndygghjg7rmiqrog Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 08, 2017 at 12:28:16AM -0800, Xin Li wrote: > Hi, >=20 > I recently noticed that when LANG and LC_CTYPE are set to en_US.UTF-8, > the following file: >=20 > %%%%% > 1 > 2 > A > a > B > b > %%%% >=20 > I got: >=20 > $ LANG=3DC LC_CTYPE=3DC sort testcase > 1 > 2 > A > B > a > b > $ LANG=3Den_US.UTF-8 LC_CTYPE=3Den_US.UTF-8 sort testcase > 1 > 2 > a > A > b > B >=20 > Is this result correct? It matches some Debian behavior but not macOS > behavior. Yes the result is correct, macOS does not have unicode collation if you wan= t to match the macos behaviour you have to set LC_COLLATE=3DC Best regards, Bapt --ndygghjg7rmiqrog Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEgOTj3suS2urGXVU3Y4mL3PG3PloFAli/w4cACgkQY4mL3PG3 Plr9zg/8Dow6c0uY5UYnTpKsXs3K3JXX3DCCHbzi+dhYquG6Mi38xke3AkF2HVCg sc+ZvBsB8c0uBhYNIqqeIhYf3OIYjX20Jwky7FPso59eENUEXClw6RJ95PS74KdP odT2p3h0FLlMtBwbn9X5PDr4hiAnE/zGU1fsoj3ZII662YjUAxJHcyoFiXW/7P9X e2d6M0NPpru7ualgzD4JhOqE0ZR7u9tHAawWHZYHlArSE0yJZaz7EMAEaRPqstag mP3klTVUrdJc+7uvExI7dE+8fDHYexzv8cF1RmYhE81D+XAkE6G9ylZplKIuSy7D 7GPFfNWX4/F5eTBkqrXBtkI7j6D+4CEScqQ5r92AB3/7exDTfaAE9bDsaErRLVEF Ioxj/68dZWlOJn8M5mXwwKkJEEBx6EapTTrHHP4Rb9EFO430roigq5AMRRGcGW9i AfIsg/cuPzyqx8PTRZmeQEbDKYTsSxnrig4QDQZBfoSpcofimqry1u0MIeXWdKQ6 Dua3GHMRVYo+m7D57d9QVKk1kTMk8tZUUmGulpA94f3RY3V+3BsRDQUe/sgAKFIi OYdPesKoZGbMKg6KxPfRBoDEGFVtMtQKN8BmU6jU/s6URTvFegoDz+CMJMCbyDgh iEKkwgZpAJYgUcWbSOdc1v23p8rZ6KQiPOcnoax7yWwcZuMI4UA= =CZAb -----END PGP SIGNATURE----- --ndygghjg7rmiqrog-- From owner-freebsd-hackers@freebsd.org Wed Mar 8 08:51:16 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 24958D01640 for ; Wed, 8 Mar 2017 08:51:16 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AF74D187B; Wed, 8 Mar 2017 08:51:15 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from Xins-MBP.ut.rhv.delphij.net (unknown [IPv6:2601:646:8882:752a:a8d6:fd69:266d:e100]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id CF6E222985; Wed, 8 Mar 2017 00:51:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1488963074; x=1488977474; bh=qJACHxr1O6QX5p0SQKIpDnDe/tADrX5mbhWYbSqwVfw=; h=Subject:To:References:Cc:From:Date:In-Reply-To; b=SxqqXdQ+GCMQWyD1Q3/1SnlX9sAgoYeIkON6UIfGb+VCltnZTdbUTJqGrev3EGO8b v2/Hs0O/Znmlj9MHbT8pq0eTCVbzsTsDex5GLT1Z3qRrDqdR+b9fvb0mJuiwpDW9O0 e1dKUrkKM97ThJaJLIY0kYLWrg6jnNTuQgVoqVX8= Subject: Re: Why en_US.UTF-8 locale consider a < A? To: Baptiste Daroussin References: <062a0098-1975-6d2b-b017-f623e46ca20b@delphij.net> <20170308084047.qc2j3vnrh5hycg32@ivaldir.net> Cc: d@delphij.net, "freebsd-hackers@freebsd.org" , theraven@freebsd.org From: Xin Li Message-ID: <7ad51573-c575-ad2f-b3bd-b011d15981ed@delphij.net> Date: Wed, 8 Mar 2017 00:51:11 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <20170308084047.qc2j3vnrh5hycg32@ivaldir.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="jXD7SAfLjkD2B2WihE0b9Kklo1fFpQj7I" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 08:51:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jXD7SAfLjkD2B2WihE0b9Kklo1fFpQj7I Content-Type: multipart/mixed; boundary="mXVJ3PLsrcaaiMlWwu4HwBGnTAbPKkmkM"; protected-headers="v1" From: Xin Li To: Baptiste Daroussin Cc: d@delphij.net, "freebsd-hackers@freebsd.org" , theraven@freebsd.org Message-ID: <7ad51573-c575-ad2f-b3bd-b011d15981ed@delphij.net> Subject: Re: Why en_US.UTF-8 locale consider a < A? References: <062a0098-1975-6d2b-b017-f623e46ca20b@delphij.net> <20170308084047.qc2j3vnrh5hycg32@ivaldir.net> In-Reply-To: <20170308084047.qc2j3vnrh5hycg32@ivaldir.net> --mXVJ3PLsrcaaiMlWwu4HwBGnTAbPKkmkM Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 3/8/17 00:40, Baptiste Daroussin wrote: >> Is this result correct? It matches some Debian behavior but not macOS= >> behavior. >=20 > Yes the result is correct, macOS does not have unicode collation if you= want to > match the macos behaviour you have to set LC_COLLATE=3DC Thanks, I also found this https://www.cl.cam.ac.uk/~mgk25/unicode.html just for the record if someone else hits the same issue. Cheers, --mXVJ3PLsrcaaiMlWwu4HwBGnTAbPKkmkM-- --jXD7SAfLjkD2B2WihE0b9Kklo1fFpQj7I Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYv8YCAAoJEJW2GBstM+nskRQQAKdU0b0v3HXN/c9Y66RFq/Kg 432iq1/Uf5jCYFE8XHjNikxQMjwSg7iH1AlQbOxqnT0DUo7UL10CbLN7PhnisIx2 rWSx32TBAuPx4sIEqAKsqr9xU53ofE1XFKY7BqZRvoVDA2HBWA2q5TjSi4BlUe4Z qvQfV+eprtc6DWNRVX2h6z2AThk6H/qV08vQ71yR2umDqZLIW5CaVcVD7l0CK27g aJV521crIY0cFLEOjI4PAkTKN3Acxyt5Mm9L/6fFG7TmztX74La/Axrmz5SBVUfY yaZ10NbBPK8IvttcxtC5EJip9XngMw14k9YXAocbuNz58Gjv9kGXEvSn35cP//4y 6aZVh5kR3ZsXoJtpeyY1Nfor+CJHws+dYgxpu3ipo8TJssW/xcydb5bdIXHwxz3I 1Fz7Ws+y0mLUN7rRUJBDd3x78Wp0MJVLjhJjXxU8fZBt2eYEyxAflfuyzUlv1BDm pJ9+YgkYsmQgGjRxeaTfN5f7GpOr5oExoxsUgEFRJpGITj6vRHlO8cHITMk1J3qf FvvYDiOtODl9vaRDzUOa4HFGHmgK0PPbDHUsdnzaL1pSjAiQXgbHZRN+r+QwT7tr S2ROo3nDokfQxrD9aLzSFBD6f7h6hwtEP3nsCmehRTXkyPmHHev4lD3k6vrIYYVb XEbmHanGfq8WML9QJx6M =fMik -----END PGP SIGNATURE----- --jXD7SAfLjkD2B2WihE0b9Kklo1fFpQj7I-- From owner-freebsd-hackers@freebsd.org Wed Mar 8 05:41:59 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9589DD0254E for ; Wed, 8 Mar 2017 05:41:59 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5E2E01917 for ; Wed, 8 Mar 2017 05:41:59 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id v285ftxi098707; Tue, 7 Mar 2017 21:41:55 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id v285ftuW098706; Tue, 7 Mar 2017 21:41:55 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201703080541.v285ftuW098706@pdx.rh.CN85.dnsmgr.net> Subject: Re: Help with silent reboot of 10.3-stable system In-Reply-To: <20170308015630.GE22199@rancor.immure.com> To: Bob Willcox Date: Tue, 7 Mar 2017 21:41:55 -0800 (PST) CC: hackers list X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Wed, 08 Mar 2017 12:08:20 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 05:41:59 -0000 > Over the past month or so my network fileserver system (NFS support for my > entire, small, network) has begun silently rebooting itself. Here is the uname > -a output: > > FreeBSD vader.immure.com 10.3-STABLE FreeBSD 10.3-STABLE #15 r313997: Mon Feb 20 14:40:00 CST 2017 bob@vader.immure.com:/usr/obj/usr/src/sys/GENERIC amd64 > > At first I suspected that it might be the power supply as it was a couple of > years old so I replaced that. Unfortunately, it has begun doing it again (had > a couple of weeks respite) so now my suspicions seem to have been incorrect. > > I was hoping that someone might be able to give me some clues on what I can do > to reveal the problem. Are there any general debug settings for the kernel (or > elsewhere) that would maybe give an indication of why it is being rebooted > (assuming it's a software problem)? > > Thanks for any suggestions you may have! Given that you have already suspected hardware I'll continue down that road and leave the software road for others to persue. Was it rebooting more often than every couple of weeks? It sounds as if a power supply swap fixed the problem for a short period, but it has come back. If that is true my suspecion would be bad primary side filter caps in the cpu vrm on the motherboard. Your replacment powersupply has nice new filter caps, if you did put in a new power supply, if you put in a used one, go get a brand now one. PC power supplies are junk when it comes to there output filter stages, and I dont care how expenive of a supply you buy. No one engineers a life of more than 3 years into them anymore. Anyway, changing this cleaned up the primary side of the vrm for a while, but since those capacitors are degrading this let them get even worse as when caps start leaking they make heat and the hotter they get the more they leak and it spirals into a cook off that usually ends in the cap leaking blank gunk out the top, or in some cases out the bottom. Please look very carefully at the MB CPU filter caps, google can help you if your now a hardware type to find what your looking for. Google: motherboard bad caps How old is the is motherboard? Anything more than 2 years old can easily have degraded caps. Unless it is using solid polymer types, then I give them 3 or 4 years. Again nothing is engineered to last much beyond warranty. Any life beyond warranty is not by design, but simply the accidental nature of things often work better than speced. > Bob > -- > Bob Willcox | If a program is useful, it will be changed. > bob@immure.com | > Austin, TX | > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Wed Mar 8 14:01:29 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 11BD7D033D7 for ; Wed, 8 Mar 2017 14:01:29 +0000 (UTC) (envelope-from bob@immure.com) Received: from maul.immure.com (108-84-10-9.lightspeed.austtx.sbcglobal.net [108.84.10.9]) by mx1.freebsd.org (Postfix) with ESMTP id E4CD31DD3 for ; Wed, 8 Mar 2017 14:01:28 +0000 (UTC) (envelope-from bob@immure.com) Received: from rancor.immure.com ([10.1.132.9]) by maul.immure.com with esmtp (Exim 4.88 (FreeBSD)) (envelope-from ) id 1clc9e-000JCl-9R; Wed, 08 Mar 2017 08:01:27 -0600 Received: from rancor.immure.com (localhost [127.0.0.1]) by rancor.immure.com (8.15.2/8.15.2) with ESMTP id v28E1P6I017243; Wed, 8 Mar 2017 08:01:25 -0600 (CST) (envelope-from bob@rancor.immure.com) Received: (from bob@localhost) by rancor.immure.com (8.15.2/8.14.9/Submit) id v28E1PxJ017242; Wed, 8 Mar 2017 08:01:25 -0600 (CST) (envelope-from bob) Date: Wed, 8 Mar 2017 08:01:25 -0600 From: Bob Willcox To: "Rodney W. Grimes" Cc: hackers list Subject: Re: Help with silent reboot of 10.3-stable system Message-ID: <20170308140125.GF22199@rancor.immure.com> Reply-To: Bob Willcox References: <20170308015630.GE22199@rancor.immure.com> <201703080541.v285ftuW098706@pdx.rh.CN85.dnsmgr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201703080541.v285ftuW098706@pdx.rh.CN85.dnsmgr.net> User-Agent: Mutt/1.7.1 (2016-10-04) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 14:01:29 -0000 On Tue, Mar 07, 2017 at 09:41:55PM -0800, Rodney W. Grimes wrote: > > Over the past month or so my network fileserver system (NFS support for my > > entire, small, network) has begun silently rebooting itself. Here is the uname > > -a output: > > > > FreeBSD vader.immure.com 10.3-STABLE FreeBSD 10.3-STABLE #15 r313997: Mon Feb 20 14:40:00 CST 2017 bob@vader.immure.com:/usr/obj/usr/src/sys/GENERIC amd64 > > > > At first I suspected that it might be the power supply as it was a couple of > > years old so I replaced that. Unfortunately, it has begun doing it again (had > > a couple of weeks respite) so now my suspicions seem to have been incorrect. > > > > I was hoping that someone might be able to give me some clues on what I can do > > to reveal the problem. Are there any general debug settings for the kernel (or > > elsewhere) that would maybe give an indication of why it is being rebooted > > (assuming it's a software problem)? > > > > Thanks for any suggestions you may have! > > Given that you have already suspected hardware I'll continue down that > road and leave the software road for others to persue. > > Was it rebooting more often than every couple of weeks? It sounds > as if a power supply swap fixed the problem for a short period, > but it has come back. If that is true my suspecion would be > bad primary side filter caps in the cpu vrm on the motherboard. > > Your replacment powersupply has nice new filter caps, if you > did put in a new power supply, if you put in a used one, go > get a brand now one. PC power supplies are junk when it comes > to there output filter stages, and I dont care how expenive > of a supply you buy. No one engineers a life of more than > 3 years into them anymore. Anyway, changing this cleaned > up the primary side of the vrm for a while, but since those > capacitors are degrading this let them get even worse as > when caps start leaking they make heat and the hotter they > get the more they leak and it spirals into a cook off that > usually ends in the cap leaking blank gunk out the top, > or in some cases out the bottom. > > Please look very carefully at the MB CPU filter caps, google can help you > if your now a hardware type to find what your looking for. > Google: motherboard bad caps > > How old is the is motherboard? Anything more than 2 years old can easily > have degraded caps. Unless it is using solid polymer types, then I give > them 3 or 4 years. Again nothing is engineered to last much beyond > warranty. Any life beyond warranty is not by design, but simply the > accidental nature of things often work better than speced. > > > Bob > > -- > > Bob Willcox | If a program is useful, it will be changed. > > bob@immure.com | > > Austin, TX | > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > -- > Rod Grimes rgrimes@freebsd.org Thanks for the reply Rod. My fear is that you may well be right. This system is about two years old now and it had been running flawlessly right up until last month with if first started doing what appears to be a temporary shutdown of power. The power supply that I installed recently is a new one (over the years I have become quite distrustful of power supplies in general). Unfortunately, replacing the motherboard is going to be painful as this is a Silverstone 8 drive NAS case (DS380B), and although a great case, it leaves very little room to work inside (and it's full). Also, being my networks main file server I depend on it almost totally so I'm reluctant to start tearing it apart. I may bite the bullet and build a complete replacement system while this one is still (mostly) working. Quite expensive, but seems it will be the safest path. Bob -- Bob Willcox | If a program is useful, it will be changed. bob@immure.com | Austin, TX | From owner-freebsd-hackers@freebsd.org Wed Mar 8 15:52:09 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 00315D037CA; Wed, 8 Mar 2017 15:52: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 B493D1D86; Wed, 8 Mar 2017 15:52:08 +0000 (UTC) (envelope-from des@des.no) Received: from desk.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id 59DE010BA6; Wed, 8 Mar 2017 15:52:07 +0000 (UTC) Received: by desk.des.no (Postfix, from userid 1001) id 714AA7026; Wed, 8 Mar 2017 16:52:08 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: grarpamp Cc: freebsd-security@freebsd.org, freebsd-hackers@freebsd.org, freebsd-questions@freebsd.org Subject: Re: WikiLeaks CIA Exploits: FreeBSD References Within References: Date: Wed, 08 Mar 2017 16:52:08 +0100 In-Reply-To: (grarpamp@gmail.com's message of "Tue, 7 Mar 2017 15:29:07 -0500") Message-ID: <86innjojfb.fsf@desk.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 15:52:09 -0000 grarpamp writes: > https://search.wikileaks.org/?q=3Dfreebsd > > Currently returns many pages similarly named... > > "Shell Code Database > This page includes local links to a shellcode > database discovered at shell-storm.org." That doesn't indicate a vulnerability. Shell code is what you use to exploit a remote code execution vulnerability once you've found it. It usually needs to be tailored to the target operating system, sometimes to the exact environment and to the application used to inject it, so it makes sense that a shell code database would reference FreeBSD. > [...] it makes sense to establish ongoing search and review of this > dataset for any as yet unfixed exploits. Note to anyone thinking of getting involved in this: depending on your jurisdiction and employment situation, downloading material from the CIA dump may be illegal and / or a firing offense. Simply browsing it online may or may not be safe; get legal advice before you do. IANAL. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@freebsd.org Wed Mar 8 15:59:45 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EBDF2D03C0F for ; Wed, 8 Mar 2017 15:59:45 +0000 (UTC) (envelope-from jan@digitaldaemon.com) Received: from digitaldaemon.com (digitaldaemon.com [162.217.114.50]) by mx1.freebsd.org (Postfix) with SMTP id 92DBE633 for ; Wed, 8 Mar 2017 15:59:45 +0000 (UTC) (envelope-from jan@digitaldaemon.com) Received: (qmail 97889 invoked by uid 89); 8 Mar 2017 15:53:02 -0000 Received: from c-73-198-164-157.hsd1.nj.comcast.net (HELO iMac.local) (jan@digitaldaemon.com@73.198.164.157) by digitaldaemon.com with SMTP; 8 Mar 2017 15:53:02 -0000 From: Jan Knepper Subject: Re: Help with silent reboot of 10.3-stable system To: Bob Willcox , hackers list References: <20170308015630.GE22199@rancor.immure.com> Message-ID: <86b89c6c-9a00-1033-4181-a7e0da2ed66f@digitaldaemon.com> Date: Wed, 8 Mar 2017 10:53:02 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <20170308015630.GE22199@rancor.immure.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 15:59:46 -0000 Is your system swapping to disk? Heavily? Might want to check the swap space on disk. I had spontaneous reboots some years ago because of bad swap space on disk. (Got a new disk, 'dd'-ed the old disk to the new disk, reboot on the new disk and everything was fine) Jan On 03/07/2017 20:56, Bob Willcox wrote: > Over the past month or so my network fileserver system (NFS support for my > entire, small, network) has begun silently rebooting itself. Here is the uname > -a output: > > FreeBSD vader.immure.com 10.3-STABLE FreeBSD 10.3-STABLE #15 r313997: Mon Feb 20 14:40:00 CST 2017 bob@vader.immure.com:/usr/obj/usr/src/sys/GENERIC amd64 > > At first I suspected that it might be the power supply as it was a couple of > years old so I replaced that. Unfortunately, it has begun doing it again (had > a couple of weeks respite) so now my suspicions seem to have been incorrect. > > I was hoping that someone might be able to give me some clues on what I can do > to reveal the problem. Are there any general debug settings for the kernel (or > elsewhere) that would maybe give an indication of why it is being rebooted > (assuming it's a software problem)? > > Thanks for any suggestions you may have! > > Bob > From owner-freebsd-hackers@freebsd.org Wed Mar 8 15:59:58 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B93CED03C55 for ; Wed, 8 Mar 2017 15:59:58 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 20DFE75D; Wed, 8 Mar 2017 15:59:58 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from [88.217.107.178] (helo=localhost.unixarea.de) by ms-10.1blu.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1cle0C-0006iX-MU; Wed, 08 Mar 2017 16:59:48 +0100 Received: from localhost.my.domain (c720-r292778-amd64 [127.0.0.1]) by localhost.unixarea.de (8.15.2/8.14.9) with ESMTPS id v28FxlvB004212 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 8 Mar 2017 16:59:47 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.15.2/8.14.9/Submit) id v28Fxl53004211; Wed, 8 Mar 2017 16:59:47 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Wed, 8 Mar 2017 16:59:47 +0100 From: Matthias Apitz To: Xin Li Cc: Baptiste Daroussin , "freebsd-hackers@freebsd.org" , d@delphij.net, theraven@freebsd.org Subject: Re: Why en_US.UTF-8 locale consider a < A? Message-ID: <20170308155947.GA4129@c720-r292778-amd64> Reply-To: Matthias Apitz Mail-Followup-To: Matthias Apitz , Xin Li , Baptiste Daroussin , "freebsd-hackers@freebsd.org" , d@delphij.net, theraven@freebsd.org References: <062a0098-1975-6d2b-b017-f623e46ca20b@delphij.net> <20170308084047.qc2j3vnrh5hycg32@ivaldir.net> <7ad51573-c575-ad2f-b3bd-b011d15981ed@delphij.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <7ad51573-c575-ad2f-b3bd-b011d15981ed@delphij.net> X-Operating-System: FreeBSD 11.0-CURRENT r292778 (amd64) User-Agent: Mutt/1.5.24 (2015-08-30) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 88.217.107.178 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 15:59:58 -0000 El día Wednesday, March 08, 2017 a las 12:51:11AM -0800, Xin Li escribió: > > > On 3/8/17 00:40, Baptiste Daroussin wrote: > >> Is this result correct? It matches some Debian behavior but not macOS > >> behavior. > > > > Yes the result is correct, macOS does not have unicode collation if you want to > > match the macos behaviour you have to set LC_COLLATE=C > > Thanks, I also found this https://www.cl.cam.ac.uk/~mgk25/unicode.html > just for the record if someone else hits the same issue. I recently came across with a related problem and have two questions (unresolved until now): 1. Using sort, reading the man page of it, it should be sufficient to set LC_COLLATE correctly. It seems that setting LANG (or unsetting it) changes the sort Order, why? 2. Speaking about German Umlauts, should they be treated as their normal letters, i.e. 'ä' is like 'a', as one can read in Wiki, or how they are sorted exactly? matthias -- Matthias Apitz, ✉ guru@unixarea.de, ⌂ http://www.unixarea.de/ ☎ +49-176-38902045 From owner-freebsd-hackers@freebsd.org Wed Mar 8 17:28:01 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 04B8FD03769 for ; Wed, 8 Mar 2017 17:28:01 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A7C10137A for ; Wed, 8 Mar 2017 17:28:00 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id v28HRvht001741; Wed, 8 Mar 2017 09:27:57 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id v28HRvp6001740; Wed, 8 Mar 2017 09:27:57 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201703081727.v28HRvp6001740@pdx.rh.CN85.dnsmgr.net> Subject: Re: Help with silent reboot of 10.3-stable system In-Reply-To: <86b89c6c-9a00-1033-4181-a7e0da2ed66f@digitaldaemon.com> To: Jan Knepper Date: Wed, 8 Mar 2017 09:27:57 -0800 (PST) CC: Bob Willcox , hackers list X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Wed, 08 Mar 2017 17:47:09 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 17:28:01 -0000 > Is your system swapping to disk? Heavily? > > Might want to check the swap space on disk. > > I had spontaneous reboots some years ago because of bad swap space on > disk. (Got a new disk, 'dd'-ed the old disk to the new disk, reboot on > the new disk and everything was fine) > > Jan Good possibilty too, though usually this one causes console message to be spewed out and evetually a swap pager panic. Though no evidence is left behind beccase the disk couldnt be used to indicate an issue. Your probably not around the console when this happens Bob? It may be possible to hook up a serial console and capture the panic if it is happening. There are other failue modes that leave no on disk trace as well, but well spit out a panic to a serial console. > On 03/07/2017 20:56, Bob Willcox wrote: > > Over the past month or so my network fileserver system (NFS support for my > > entire, small, network) has begun silently rebooting itself. Here is the uname > > -a output: > > > > FreeBSD vader.immure.com 10.3-STABLE FreeBSD 10.3-STABLE #15 r313997: Mon Feb 20 14:40:00 CST 2017 bob@vader.immure.com:/usr/obj/usr/src/sys/GENERIC amd64 > > > > At first I suspected that it might be the power supply as it was a couple of > > years old so I replaced that. Unfortunately, it has begun doing it again (had > > a couple of weeks respite) so now my suspicions seem to have been incorrect. > > > > I was hoping that someone might be able to give me some clues on what I can do > > to reveal the problem. Are there any general debug settings for the kernel (or > > elsewhere) that would maybe give an indication of why it is being rebooted > > (assuming it's a software problem)? > > > > Thanks for any suggestions you may have! > > > > Bob > > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Wed Mar 8 17:59:13 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9F692D034C8 for ; Wed, 8 Mar 2017 17:59:13 +0000 (UTC) (envelope-from bob@immure.com) Received: from maul.immure.com (108-84-10-9.lightspeed.austtx.sbcglobal.net [108.84.10.9]) by mx1.freebsd.org (Postfix) with ESMTP id 7E23279E for ; Wed, 8 Mar 2017 17:59:13 +0000 (UTC) (envelope-from bob@immure.com) Received: from rancor.immure.com ([10.1.132.9]) by maul.immure.com with esmtp (Exim 4.88 (FreeBSD)) (envelope-from ) id 1clfrh-000Jnj-Qe; Wed, 08 Mar 2017 11:59:10 -0600 Received: from rancor.immure.com (localhost [127.0.0.1]) by rancor.immure.com (8.15.2/8.15.2) with ESMTP id v28Hx92S018126; Wed, 8 Mar 2017 11:59:09 -0600 (CST) (envelope-from bob@rancor.immure.com) Received: (from bob@localhost) by rancor.immure.com (8.15.2/8.14.9/Submit) id v28Hx9mT018125; Wed, 8 Mar 2017 11:59:09 -0600 (CST) (envelope-from bob) Date: Wed, 8 Mar 2017 11:59:09 -0600 From: Bob Willcox To: "Rodney W. Grimes" Cc: Jan Knepper , hackers list Subject: Re: Help with silent reboot of 10.3-stable system Message-ID: <20170308175909.GH22199@rancor.immure.com> Reply-To: Bob Willcox References: <86b89c6c-9a00-1033-4181-a7e0da2ed66f@digitaldaemon.com> <201703081727.v28HRvp6001740@pdx.rh.CN85.dnsmgr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201703081727.v28HRvp6001740@pdx.rh.CN85.dnsmgr.net> User-Agent: Mutt/1.7.1 (2016-10-04) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 17:59:13 -0000 On Wed, Mar 08, 2017 at 09:27:57AM -0800, Rodney W. Grimes wrote: > > Is your system swapping to disk? Heavily? > > > > Might want to check the swap space on disk. > > > > I had spontaneous reboots some years ago because of bad swap space on > > disk. (Got a new disk, 'dd'-ed the old disk to the new disk, reboot on > > the new disk and everything was fine) > > > > Jan > > Good possibilty too, though usually this one causes console message > to be spewed out and evetually a swap pager panic. Though no evidence > is left behind beccase the disk couldnt be used to indicate an issue. > > Your probably not around the console when this happens Bob? > It may be possible to hook up a serial console and capture > the panic if it is happening. > > There are other failue modes that leave no on disk trace as well, > but well spit out a panic to a serial console. It has typically happened when the load is light. Since this system is mostly just an NFS file and DLNA server it is usually lightly loaded. And yes, so far I haven't been near the console (it's in a room I'm usually not in). The MB doesn't have a serial port on it. I could try a USB to rs232 adapter, but haven't attempted to use one of those with FreeBSD before. > > > On 03/07/2017 20:56, Bob Willcox wrote: > > > Over the past month or so my network fileserver system (NFS support for my > > > entire, small, network) has begun silently rebooting itself. Here is the uname > > > -a output: > > > > > > FreeBSD vader.immure.com 10.3-STABLE FreeBSD 10.3-STABLE #15 r313997: Mon Feb 20 14:40:00 CST 2017 bob@vader.immure.com:/usr/obj/usr/src/sys/GENERIC amd64 > > > > > > At first I suspected that it might be the power supply as it was a couple of > > > years old so I replaced that. Unfortunately, it has begun doing it again (had > > > a couple of weeks respite) so now my suspicions seem to have been incorrect. > > > > > > I was hoping that someone might be able to give me some clues on what I can do > > > to reveal the problem. Are there any general debug settings for the kernel (or > > > elsewhere) that would maybe give an indication of why it is being rebooted > > > (assuming it's a software problem)? > > > > > > Thanks for any suggestions you may have! > > > > > > Bob > > > > > > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > > > -- > Rod Grimes rgrimes@freebsd.org -- Bob Willcox | If a program is useful, it will be changed. bob@immure.com | Austin, TX | From owner-freebsd-hackers@freebsd.org Wed Mar 8 18:05:58 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1188ED037BF for ; Wed, 8 Mar 2017 18:05:58 +0000 (UTC) (envelope-from stesin@gmail.com) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DB5BAFAA for ; Wed, 8 Mar 2017 18:05:57 +0000 (UTC) (envelope-from stesin@gmail.com) Received: by mail-it0-x22f.google.com with SMTP id m27so44948438iti.1 for ; Wed, 08 Mar 2017 10:05:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4ar6Sx9x3t554nbs81zrUu96b1TBuvOQSkxQUxXBQ9Q=; b=JvyWpUCnDHZZlaCP1GlIOYu6Gh/TyjOrUuGHOz/AULoWACsfJnO5vt+IwN1sJcjEjA DOI8fljt27PDS1OOwIt1UNF2vhJ1rxAT/uwt5R5BrVSx5+DKbMyKzs+YNH+O35m/GS+I Rwg9oZKEnAzo9UkXaoK48u5uP5/pR7sw+CnhMMVSlt947p7patdhgjv6kE/NUdevNh0V XqcmpUUQfohP3qLORC2AuZb/LjQufEJ/3Dsw1du3kxUDy1wBRDUil8D2jDq078Zt+K/e UAi5j6+L/muLSCufSbtE7F2ib+EVw33cR7pvzShGP1LXJl79bbtfacxvOwoyFfyATQmj sB4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4ar6Sx9x3t554nbs81zrUu96b1TBuvOQSkxQUxXBQ9Q=; b=VXY3/Q2InOdqui/nFOpWjaYIb4y4rFnUiGcefLbxpC7MdzUdLYWBtoI9JcLIJcXbvm 69kkEHahNUm9LVSkWu0w3y+1p2qbuvme6y86bsLF2EesMqWpbK+VCptNyJv05MTuS6ED yTVNInsNOfuEYMraL6Mqj4j4Hp6zNe2d4CU+wleps8SsVzRZqvkGrvlrcoGtACLi/i+c ZHj2l6rFVGRNS/I/kkiJLsVRRWHA8PajJ4XEK3fLDhV7Eu45XTvEp1kdQ2bAX9pQoRXL 2fZiMR6HW624nAdVxBZZ0gy5rY7euvXeXOxLnovJDzgEyKsrMwxr4Pi1t3eDhDGCdrjU S+Cg== X-Gm-Message-State: AMke39lR2DV+AYz/8jICwzBJwIMpjJNoly5WMjvDO2nAkvolYSEzCKa/+K2F7fmOIUO8+gIrF5fIwLJEdPU52w== X-Received: by 10.107.167.204 with SMTP id q195mr8540525ioe.170.1488996357134; Wed, 08 Mar 2017 10:05:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.36.5.195 with HTTP; Wed, 8 Mar 2017 10:05:55 -0800 (PST) Received: by 10.36.5.195 with HTTP; Wed, 8 Mar 2017 10:05:55 -0800 (PST) In-Reply-To: <201703081727.v28HRvp6001740@pdx.rh.CN85.dnsmgr.net> References: <86b89c6c-9a00-1033-4181-a7e0da2ed66f@digitaldaemon.com> <201703081727.v28HRvp6001740@pdx.rh.CN85.dnsmgr.net> From: Andrii Stesin Date: Wed, 8 Mar 2017 20:05:55 +0200 Message-ID: Subject: Re: Help with silent reboot of 10.3-stable system To: "Rodney W. Grimes" Cc: hackers list , Jan Knepper Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 18:05:58 -0000 I bet for faulty RAM module On Mar 8, 2017 19:47, "Rodney W. Grimes" wrote: > > Is your system swapping to disk? Heavily? > > > > Might want to check the swap space on disk. > > > > I had spontaneous reboots some years ago because of bad swap space on > > disk. (Got a new disk, 'dd'-ed the old disk to the new disk, reboot on > > the new disk and everything was fine) > > > > Jan > > Good possibilty too, though usually this one causes console message > to be spewed out and evetually a swap pager panic. Though no evidence > is left behind beccase the disk couldnt be used to indicate an issue. > > Your probably not around the console when this happens Bob? > It may be possible to hook up a serial console and capture > the panic if it is happening. > > There are other failue modes that leave no on disk trace as well, > but well spit out a panic to a serial console. > > > On 03/07/2017 20:56, Bob Willcox wrote: > > > Over the past month or so my network fileserver system (NFS support > for my > > > entire, small, network) has begun silently rebooting itself. Here is > the uname > > > -a output: > > > > > > FreeBSD vader.immure.com 10.3-STABLE FreeBSD 10.3-STABLE #15 r313997: > Mon Feb 20 14:40:00 CST 2017 bob@vader.immure.com:/usr/obj/usr/src/sys/GENERIC > amd64 > > > > > > At first I suspected that it might be the power supply as it was a > couple of > > > years old so I replaced that. Unfortunately, it has begun doing it > again (had > > > a couple of weeks respite) so now my suspicions seem to have been > incorrect. > > > > > > I was hoping that someone might be able to give me some clues on what > I can do > > > to reveal the problem. Are there any general debug settings for the > kernel (or > > > elsewhere) that would maybe give an indication of why it is being > rebooted > > > (assuming it's a software problem)? > > > > > > Thanks for any suggestions you may have! > > > > > > Bob > > > > > > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@ > freebsd.org" > > > > -- > Rod Grimes > rgrimes@freebsd.org > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@freebsd.org Wed Mar 8 22:54:24 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B159CD0323A for ; Wed, 8 Mar 2017 22:54:24 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8AF3A1ADB for ; Wed, 8 Mar 2017 22:54:24 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by mail.baldwin.cx (Postfix) with ESMTPSA id 55E1F10A7B9; Wed, 8 Mar 2017 17:54:23 -0500 (EST) From: John Baldwin To: freebsd-hackers@freebsd.org Cc: Gordon Ross Subject: Re: How to get better debugging for the kernel. Date: Wed, 08 Mar 2017 14:07:42 -0800 Message-ID: <2018412.jBpSkhkZIY@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.0-STABLE; KDE/4.14.10; amd64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Wed, 08 Mar 2017 17:54:23 -0500 (EST) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 22:54:24 -0000 On Saturday, August 13, 2016 11:55:03 AM Gordon Ross wrote: > I heard a rumor someone might be working on a port of illumos "mdb". > Anyone know if that's true, and how far along it went? > > We depend heavily upon this tool for production support; > so much that I'm not sure how we'd live without it. I have been (slowly) working on a port of mdb to FreeBSD for debugging kernels. It does not support userland debugging, only live kernels and kernel crash dumps. What do you use mdb for? -- John Baldwin From owner-freebsd-hackers@freebsd.org Wed Mar 8 22:54:28 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B1ABAD0324C for ; Wed, 8 Mar 2017 22:54:28 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8C5A51AE8 for ; Wed, 8 Mar 2017 22:54:28 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by mail.baldwin.cx (Postfix) with ESMTPSA id E758C10A7FA; Wed, 8 Mar 2017 17:54:21 -0500 (EST) From: John Baldwin To: freebsd-hackers@freebsd.org Cc: Karl Denninger Subject: Re: Kernel UMA current occupancy statistics Date: Wed, 08 Mar 2017 14:27:15 -0800 Message-ID: <2800890.fCNZHq2Y8P@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.0-STABLE; KDE/4.14.10; amd64; ; ) In-Reply-To: <18fdca3b-9002-db60-504b-388c628fab0e@denninger.net> References: <18fdca3b-9002-db60-504b-388c628fab0e@denninger.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Wed, 08 Mar 2017 17:54:22 -0500 (EST) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 22:54:28 -0000 On Wednesday, August 31, 2016 08:02:06 AM Karl Denninger wrote: > Working on the ZFS ARC code I'm trying to find documentation on the > means by which I can determine the occupancy of a UMA slab. > > There is a userland set of calls but I assume those are not the correct > way to approach this in the kernel context. include/sys/vm/uma.h > declares that the returned structure is to be opaque to users of the > facility, and the only occupancy-related function I can find is > uma_zone_get_cur, which gives me the number of items allocated but > uma_zone_get_max states that it will return "0" if no limit on > allocations has been set. > > Any hints on how to determine, if for example there are 50,000 "units" > of memory that are currently held out of kmem in a given slab how many > are actually allocated and how many are free and reusable without a > further kernel memory allocation? > > What I'm trying to determine is this (from vmstat -z): > > ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP > zio_buf_512: 512, 0, 79865, 199359, 6495950, 0, 0 > > In other words how do I programmatically, inside a kernel routine (in > this case zfs/arc.c) retrieve the "used" and "free" values if I have a > given slab's pointer (which I can use to call kmem_cache_reap_now)? > > Thanks in advance; vmstat -z retrieves these using memstat_sysctl_uma() from libmemstat which in turn uses the vm.zone_stats sysctl. Looking in that function, it seems that the used field (mt_count) is computed this way: mtp->mt_count = mtp->mt_numallocs - mtp->mt_numfrees; Where numallocs and numfrees are computed by summing a set of per-CPU stats: for (j = 0; j < maxcpus; j++) { mtp->mt_numallocs += upsp->ups_allocs; mtp->mt_numfrees += upsp->ups_frees; } The free field (mt_free) is calculated similarly. First with a global count followed by per-CPU counts: mtp->mt_numfrees = uthp->uth_frees; for (j = 0; j < maxcpus; j++) { mtp->mt_free += upsp->ups_cache_free; } The vm.zone_stats sysctl is implemented by sysctl_vm_zone_stats() in sys/vm/uma_core.c. It seems like 'uma_zone_get_cur()' might give you USED. You would need to add a new function to let you calculate FREE. You can probably use 'uma_zone_get_cur()' as a template for implementing that other function. uma_zone_sumstat() might also be useful as a reference. -- John Baldwin From owner-freebsd-hackers@freebsd.org Wed Mar 8 23:13:45 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 05CE0D039AD for ; Wed, 8 Mar 2017 23:13:45 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BC5ED18B2; Wed, 8 Mar 2017 23:13:44 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1clkm4-000ArG-9y; Thu, 09 Mar 2017 02:13:40 +0300 Date: Thu, 9 Mar 2017 02:13:40 +0300 From: Slawa Olhovchenkov To: John Baldwin Cc: freebsd-hackers@freebsd.org, Karl Denninger Subject: Re: Kernel UMA current occupancy statistics Message-ID: <20170308231340.GT15630@zxy.spb.ru> References: <18fdca3b-9002-db60-504b-388c628fab0e@denninger.net> <2800890.fCNZHq2Y8P@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2800890.fCNZHq2Y8P@ralph.baldwin.cx> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 23:13:45 -0000 On Wed, Mar 08, 2017 at 02:27:15PM -0800, John Baldwin wrote: > On Wednesday, August 31, 2016 08:02:06 AM Karl Denninger wrote: > > Working on the ZFS ARC code I'm trying to find documentation on the > > means by which I can determine the occupancy of a UMA slab. > > > > There is a userland set of calls but I assume those are not the correct > > way to approach this in the kernel context. include/sys/vm/uma.h > > declares that the returned structure is to be opaque to users of the > > facility, and the only occupancy-related function I can find is > > uma_zone_get_cur, which gives me the number of items allocated but > > uma_zone_get_max states that it will return "0" if no limit on > > allocations has been set. > > > > Any hints on how to determine, if for example there are 50,000 "units" > > of memory that are currently held out of kmem in a given slab how many > > are actually allocated and how many are free and reusable without a > > further kernel memory allocation? > > > > What I'm trying to determine is this (from vmstat -z): > > > > ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP > > zio_buf_512: 512, 0, 79865, 199359, 6495950, 0, 0 > > > > In other words how do I programmatically, inside a kernel routine (in > > this case zfs/arc.c) retrieve the "used" and "free" values if I have a > > given slab's pointer (which I can use to call kmem_cache_reap_now)? > > > > Thanks in advance; > > vmstat -z retrieves these using memstat_sysctl_uma() from libmemstat > which in turn uses the vm.zone_stats sysctl. Looking in that function, > it seems that the used field (mt_count) is computed this way: > > mtp->mt_count = mtp->mt_numallocs - mtp->mt_numfrees; > > Where numallocs and numfrees are computed by summing a set of per-CPU > stats: > > for (j = 0; j < maxcpus; j++) { > mtp->mt_numallocs += upsp->ups_allocs; > mtp->mt_numfrees += upsp->ups_frees; > } > > The free field (mt_free) is calculated similarly. First with a global > count followed by per-CPU counts: > > mtp->mt_numfrees = uthp->uth_frees; > for (j = 0; j < maxcpus; j++) { > mtp->mt_free += upsp->ups_cache_free; > } > > The vm.zone_stats sysctl is implemented by sysctl_vm_zone_stats() in > sys/vm/uma_core.c. > > It seems like 'uma_zone_get_cur()' might give you USED. You would > need to add a new function to let you calculate FREE. You can probably > use 'uma_zone_get_cur()' as a template for implementing that other > function. uma_zone_sumstat() might also be useful as a reference. I am wrote such function as part of D7538: https://reviews.freebsd.org/D7538#f080cd65 From owner-freebsd-hackers@freebsd.org Wed Mar 8 23:25:59 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1DCB7D03C31 for ; Wed, 8 Mar 2017 23:25:59 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 926F31DCE for ; Wed, 8 Mar 2017 23:25:58 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: by mail-lf0-x22d.google.com with SMTP id y193so21139081lfd.3 for ; Wed, 08 Mar 2017 15:25:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:date:to:subject:message-id:mime-version :content-transfer-encoding; bh=34l4/l4K1fSl4JKBPmBSw1MYI1iU7anLgtCWfwX3O3c=; b=Ic8aK9UNWRWNL//ZUYXnmyxN421bDmfDilL8ihpetu5yK3s161KQYO6/0NPmGNPXq2 M9G435Y4g+8h7XWCU1LszgVE1DhIs1DDB/eCcZIgZq88T/jtU251YPR8JvpO38bXqiX9 4YfqyhyHveGvjW5VwO1zbjT2D3NjFz6anNzReqHnk/1RAlNw6bxbaScUgGIfIF+80NGF PS887aig1D9SRUL98jWKeoNNjAPESzu4+P2Zv1Bx8dbd30v43YYKAwlyk1QjocjEUajG cQt4TDzpXzPM4Bm1IHPWNB1o3vCt/LUY/DUh9JCMe+pbtnwE7GcZlN6UgSAbiZq9Oyqa OPtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:subject:message-id:mime-version :content-transfer-encoding; bh=34l4/l4K1fSl4JKBPmBSw1MYI1iU7anLgtCWfwX3O3c=; b=hnoqM7L1OXAtI27w0FAFQrtWvJl23UHX8NzN1dbXyqW941tU+LNUd8hulnuQHmXYox pqJslnH846e2sQw0BZ5nYEDO3Kb7SgH1L7xPWOCwp0fS7esy+hhZ9svo/u6+CO6c1QF8 FDyQg0OoB7ToybJkatHyGFKz47XjUdw6ihCiR4oCsoMaNIE8uCdZb/1lIgJbIh1m1hu4 KiV0Ozd4asZ00yJi9q22mZ7Xe3MQgoHJZAeNEJUvPkvPgwPsjyzu72eqDDwXCC3PiUhX Zbxzhomo4N45V8qEScggRj6akyEsuU3+zq2psWw8HIX4iCAHNa9ooFw+1cZpqS6TnoLq +fxw== X-Gm-Message-State: AMke39mS8/jpM4dYbDFIasdF65Y/SqO0AoXV2Ms209pJmkqjboBKWTUOtXZf6T3Bh3lxWg== X-Received: by 10.25.31.141 with SMTP id f135mr980607lff.56.1489015556830; Wed, 08 Mar 2017 15:25:56 -0800 (PST) Received: from rimwks ([2001:470:28:81a:6ef0:49ff:fe75:38e3]) by smtp.gmail.com with ESMTPSA id o91sm908955lfg.1.2017.03.08.15.25.55 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 08 Mar 2017 15:25:56 -0800 (PST) From: Rozhuk Ivan X-Google-Original-From: Rozhuk Ivan Date: Thu, 9 Mar 2017 02:25:54 +0300 To: freebsd-hackers@freebsd.org, Rozhuk Ivan Subject: open(): O_EVTONLY and O_NOATIME Message-ID: <20170309022554.18875d07@rimwks> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 23:25:59 -0000 Hi! Can some one add O_EVTONLY and O_NOATIME to open()? https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214338 devel/glib20: patch: new kqueue() backend for file monitoring Without O_NOATIME open() on file/dir always update attributes -> file browsing via sshfs/internet get very slow. Without O_EVTONLY kqueue() cant monitor dirs/files than locked, also this cause unmount proublems. IMHO O_NOATIME - easy to add. From owner-freebsd-hackers@freebsd.org Wed Mar 8 23:50:22 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DE0C2D0240F for ; Wed, 8 Mar 2017 23:50:22 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7710E19E7 for ; Wed, 8 Mar 2017 23:50:22 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v28NoHll030956 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 9 Mar 2017 01:50:17 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v28NoHll030956 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v28NoG68030952; Thu, 9 Mar 2017 01:50:16 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 9 Mar 2017 01:50:16 +0200 From: Konstantin Belousov To: Rozhuk Ivan Cc: freebsd-hackers@freebsd.org Subject: Re: open(): O_EVTONLY and O_NOATIME Message-ID: <20170308235016.GT30979@kib.kiev.ua> References: <20170309022554.18875d07@rimwks> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170309022554.18875d07@rimwks> User-Agent: Mutt/1.8.0 (2017-02-23) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 23:50:23 -0000 On Thu, Mar 09, 2017 at 02:25:54AM +0300, Rozhuk Ivan wrote: > Hi! > > Can some one add O_EVTONLY and O_NOATIME to open()? Sure, somebody can, but it might be that nobody will. > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214338 devel/glib20: patch: new kqueue() backend for file monitoring > > Without O_NOATIME open() on file/dir always update attributes -> file browsing via sshfs/internet get very slow. > Without O_EVTONLY kqueue() cant monitor dirs/files than locked, also this cause unmount proublems. What do you mean by 'cannot monitor files that are locked' ? In particular, what user-settable locks (advisory locks ?) prevent kqueue(2) event reporting ? > > > IMHO O_NOATIME - easy to add. Hmm. There is an architectural question about allowing user to override the administrator mounting option. If the system configuration mounted the volume without noatime mount option, then why should we allow user to escape the policy ? In particular, access times might provide some important information WRT undesirable incidents, esp. on sealed machines. We might add a new mount option, which would not disable atime, but allow user to request O_NOATIME behaviour. E.g., it could be specified for the monitored volumes on desktops, if I follow your use case. That said, I see two practical troubles with implementation: 1. The atime update is filesystem-specific, i.e. you must teach each filesystem how to react to the flag. At least, UFS, ZFS, msdosfs and tmpfs must be adapted. 2. If you look at any of the filesystems in the list of the #1, you would note that atime is set in the context which already lost any reference to the file which initiated the operation. For instance, consider the most often cause for atime update, read(2): VFS translates the syscall through all its layers into VOP_READ() call for fs-specific action, and the signature of the call is VOP_READ(struct vnode *, struct uio *, int ioflag, struct ucred *); As you see, there file is already down-casted to vnode, and of course we do not want the vnode to loose atime updates just because one file is opened which asked for no atime updates. As result, upper VFS layers must pass a flag to VOP_READ(). You are welcome to finish the analysis and to prototype the solution. From owner-freebsd-hackers@freebsd.org Thu Mar 9 00:15:38 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C84EED011F8 for ; Thu, 9 Mar 2017 00:15:38 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DB921B3D for ; Thu, 9 Mar 2017 00:15:38 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: by mail-lf0-x22b.google.com with SMTP id j90so21549826lfk.2 for ; Wed, 08 Mar 2017 16:15:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:date:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=AqojGE3+EtsQkQUbhKccl7/UHqDEwMgLLln+k5mMxtQ=; b=bcod/FxpLbR4ouBPNA/OsOhEqJlL2HPHegXj6TkYuUeG5oScQzi7P4wcdUpnnYe0V1 6Kh9c+5Bry2mAH2kBKxiXrjhIqKKsUITNGte9TxPqVyM3dD2ls0TvRSABTi4qV0wuTMq KjptQ+qD1Gfz1u1z4oXamLz4ihj3R0fsWMtUU3tCYvF/xVlnKJwKq6U5bZNJP8JvO+13 eYYEY3RccLtR9CqVlCux3vfbAjK/dm73BBCMo8a94d/5vvNDZBQbN7b44lvE9DNaybe0 yLOh/2RVo2aB56lUvdRsYa0V8Fxxrl8jRproYxejhFkJwVg9o+RomtaWVHHymfeY0ZoN mPxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=AqojGE3+EtsQkQUbhKccl7/UHqDEwMgLLln+k5mMxtQ=; b=lu0xYec2XAab+U9Z68ybrB93EJ5cnaZw4di6xtPAbBVCOvJ7fNSrgkgavkXSlYlqjQ XrnJLMf4hgllEy5nbfCN/sAQ5V+6/TsPnhL3hqtmzHFpIELJhBKIrNf6WZ+EQE4VLOQA RfNzsVmli3Dg0gt/mYGy+Gi+NTEriKXeNjqtR2JYtxycA3kmfwK2zstnhK7G/zsPTxUj lBsTZzhBQ2chnIR2JJPoqw6FzDGLd46lN2US4U8qQJmI0F3CvUX6g2jDi0MRxHTIoeit 6Vm0Ir9MowCJ4KgVkB/Y+KuisNhzKhU17jzfdd93gu54ZBcnxOK2HC+x2UST1blGhzZ8 BOzg== X-Gm-Message-State: AMke39mSf+sFQZsyYd4VgC8sTXuI97ar/Ut5V7cBxqcP12vuwlBy6EWmS3Q9E98BWmXN9w== X-Received: by 10.46.69.215 with SMTP id s206mr3073694lja.26.1489018535231; Wed, 08 Mar 2017 16:15:35 -0800 (PST) Received: from rimwks ([2001:470:28:81a:6ef0:49ff:fe75:38e3]) by smtp.gmail.com with ESMTPSA id p27sm935110lfg.5.2017.03.08.16.15.34 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 08 Mar 2017 16:15:34 -0800 (PST) From: Rozhuk Ivan X-Google-Original-From: Rozhuk Ivan Date: Thu, 9 Mar 2017 03:15:32 +0300 To: Konstantin Belousov Cc: freebsd-hackers@freebsd.org Subject: Re: open(): O_EVTONLY and O_NOATIME Message-ID: <20170309031532.0079ab35@rimwks> In-Reply-To: <20170308235016.GT30979@kib.kiev.ua> References: <20170309022554.18875d07@rimwks> <20170308235016.GT30979@kib.kiev.ua> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 00:15:38 -0000 On Thu, 9 Mar 2017 01:50:16 +0200 Konstantin Belousov wrote: > > Can some one add O_EVTONLY and O_NOATIME to open()? > Sure, somebody can, but it might be that nobody will. > O_EVTONLY require knowledge about kqueue internals, I have not it. > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214338 > > devel/glib20: patch: new kqueue() backend for file monitoring > > > > Without O_NOATIME open() on file/dir always update attributes -> > > file browsing via sshfs/internet get very slow. Without O_EVTONLY > > kqueue() cant monitor dirs/files than locked, also this cause > > unmount proublems. > What do you mean by 'cannot monitor files that are locked' ? In > particular, what user-settable locks (advisory locks ?) prevent > kqueue(2) event reporting ? If some one already open and lock dir/file you can not open it. > > IMHO O_NOATIME - easy to add. > > Hmm. There is an architectural question about allowing user to > override the administrator mounting option. If the system > configuration mounted the volume without noatime mount option, then > why should we allow user to escape the policy ? In particular, access > times might provide some important information WRT undesirable > incidents, esp. on sealed machines. > > We might add a new mount option, which would not disable atime, but > allow user to request O_NOATIME behaviour. E.g., it could be > specified for the monitored volumes on desktops, if I follow your use > case. > May be we should do like other OS that already have O_NOATIME? > That said, I see two practical troubles with implementation: > > 1. The atime update is filesystem-specific, i.e. you must teach each > filesystem how to react to the flag. At least, UFS, ZFS, msdosfs and > tmpfs must be adapted. > > 2. If you look at any of the filesystems in the list of the #1, you > would note that atime is set in the context which already lost any > reference to the file which initiated the operation. For instance, > consider the most often cause for atime update, read(2): VFS > translates the syscall through all its layers into VOP_READ() call > for fs-specific action, and the signature of the call is > VOP_READ(struct vnode *, struct uio *, int ioflag, struct > ucred *); As you see, there file is already down-casted to vnode, and > of course we do not want the vnode to loose atime updates just > because one file is opened which asked for no atime updates. As > result, upper VFS layers must pass a flag to VOP_READ(). > > You are welcome to finish the analysis and to prototype the solution. ???? If file system cant be mount with NOATIME - then it already ready to support O_NOATIME. From owner-freebsd-hackers@freebsd.org Thu Mar 9 00:33:18 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2E4E3D01D58 for ; Thu, 9 Mar 2017 00:33:18 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CB1E21111 for ; Thu, 9 Mar 2017 00:33:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v290X8wl040821 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 9 Mar 2017 02:33:08 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v290X8wl040821 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v290X8Ln040820; Thu, 9 Mar 2017 02:33:08 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 9 Mar 2017 02:33:08 +0200 From: Konstantin Belousov To: Rozhuk Ivan Cc: freebsd-hackers@freebsd.org Subject: Re: open(): O_EVTONLY and O_NOATIME Message-ID: <20170309003308.GU30979@kib.kiev.ua> References: <20170309022554.18875d07@rimwks> <20170308235016.GT30979@kib.kiev.ua> <20170309031532.0079ab35@rimwks> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170309031532.0079ab35@rimwks> User-Agent: Mutt/1.8.0 (2017-02-23) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 00:33:18 -0000 On Thu, Mar 09, 2017 at 03:15:32AM +0300, Rozhuk Ivan wrote: > On Thu, 9 Mar 2017 01:50:16 +0200 > Konstantin Belousov wrote: > > > > Can some one add O_EVTONLY and O_NOATIME to open()? > > Sure, somebody can, but it might be that nobody will. > > > > O_EVTONLY require knowledge about kqueue internals, I have not it. > > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214338 > > > devel/glib20: patch: new kqueue() backend for file monitoring > > > > > > Without O_NOATIME open() on file/dir always update attributes -> > > > file browsing via sshfs/internet get very slow. Without O_EVTONLY > > > kqueue() cant monitor dirs/files than locked, also this cause > > > unmount proublems. > > What do you mean by 'cannot monitor files that are locked' ? In > > particular, what user-settable locks (advisory locks ?) prevent > > kqueue(2) event reporting ? > > If some one already open and lock dir/file you can not open it. I have to repeat the question. Which lock could be applied by user which prevents other opens ? > > > > > IMHO O_NOATIME - easy to add. > > > > Hmm. There is an architectural question about allowing user to > > override the administrator mounting option. If the system > > configuration mounted the volume without noatime mount option, then > > why should we allow user to escape the policy ? In particular, access > > times might provide some important information WRT undesirable > > incidents, esp. on sealed machines. > > > > We might add a new mount option, which would not disable atime, but > > allow user to request O_NOATIME behaviour. E.g., it could be > > specified for the monitored volumes on desktops, if I follow your use > > case. > > > > May be we should do like other OS that already have O_NOATIME? What other OSes do ? > > > > That said, I see two practical troubles with implementation: > > > > 1. The atime update is filesystem-specific, i.e. you must teach each > > filesystem how to react to the flag. At least, UFS, ZFS, msdosfs and > > tmpfs must be adapted. > > > > 2. If you look at any of the filesystems in the list of the #1, you > > would note that atime is set in the context which already lost any > > reference to the file which initiated the operation. For instance, > > consider the most often cause for atime update, read(2): VFS > > translates the syscall through all its layers into VOP_READ() call > > for fs-specific action, and the signature of the call is > > VOP_READ(struct vnode *, struct uio *, int ioflag, struct > > ucred *); As you see, there file is already down-casted to vnode, and > > of course we do not want the vnode to loose atime updates just > > because one file is opened which asked for no atime updates. As > > result, upper VFS layers must pass a flag to VOP_READ(). > > > > You are welcome to finish the analysis and to prototype the solution. > > ???? > If file system cant be mount with NOATIME - then it already ready to support O_NOATIME. I do not understand this statement. From owner-freebsd-hackers@freebsd.org Thu Mar 9 04:28:04 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0B2E7D036FC for ; Thu, 9 Mar 2017 04:28:04 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B4F481B04 for ; Thu, 9 Mar 2017 04:28:03 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: by mail-wr0-x22c.google.com with SMTP id u108so36662378wrb.3 for ; Wed, 08 Mar 2017 20:28:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nFU/3ETG8KwSi4EbBgpql9weX4EZQgYmJ0d5N3dGtKs=; b=DNgg2gZSGSsAJVS9FrNppSHPdhZt6arnsfA5UFM7/J9IJGzpQ9Rfix14VnRN6LAwEK Pn3OyGwWLxVeSMqJtrR+e8YijhaVhmHulWpskIQf3OIooBel/2OINBzMWaaoDDaJWU2P lfYU6vaOFX5o67qHfcSw8v02c1QuWyRaAA3+DNYvx3pLKIOX8dGMYLpOHznglc5V8Lr1 KdrCs9pAvjrS0y2MH+ecD/46AKXPBG7NkUjjP1NliY6COskNvPU4BNJ5HEAKWl0AWP5q 1CdXyJIY0XB8gUNrM3dd9/Gi47TaeXuyYq/8tcox8f+al5j95vk/kGj+BgyjNdi50ytC ldtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nFU/3ETG8KwSi4EbBgpql9weX4EZQgYmJ0d5N3dGtKs=; b=uXZy/ldE01YScck7R4B24THdINfBv5s1nAGzFjPv3RuAUNDb0ttyjlXGHf5zhEcXB/ fRQ1QY666tkFzbSoElzkrdzzVzSP6qrdoR9SSC4A8SB7gqXgRNUSqUsFBI0oncmqmW+d r0fcBKyg6AN7bAGl1ZxeZ/HxiK1aq7SmEnn50t910GRxWxDRaDj5nikS2aRk/unIgREj ujRmOJJd02RNUs4vWrfVhFez3JymNzpS1lieW4tt7WumQ7RymIkEEEc/Spg87FVzKODc sjMcHcSiGYYZSfsOc0qwmznFtHQuAPViUEiNHzHvm2SZE5ITXKoEMbAYoO9BFnA1vh6I I2YQ== X-Gm-Message-State: AMke39laJDL3IuTqUG1Nnc+SX3UNyrwIFJl5jU4ybozgJ8jIPOdcFYSDqmjdEDiGD+ILxgo6Jj6gIUuWVuab2A== X-Received: by 10.223.128.5 with SMTP id 5mr8299224wrk.163.1489033682058; Wed, 08 Mar 2017 20:28:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.164.65 with HTTP; Wed, 8 Mar 2017 20:28:01 -0800 (PST) In-Reply-To: <20170308015630.GE22199@rancor.immure.com> References: <20170308015630.GE22199@rancor.immure.com> From: Adam Vande More Date: Wed, 8 Mar 2017 22:28:01 -0600 Message-ID: Subject: Re: Help with silent reboot of 10.3-stable system To: Bob Willcox Cc: hackers list Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 04:28:04 -0000 On Tue, Mar 7, 2017 at 7:56 PM, Bob Willcox wrote: > Over the past month or so my network fileserver system (NFS support for my > entire, small, network) has begun silently rebooting itself. Here is the > uname > -a output: > > FreeBSD vader.immure.com 10.3-STABLE FreeBSD 10.3-STABLE #15 r313997: Mon > Feb 20 14:40:00 CST 2017 bob@vader.immure.com:/usr/obj/usr/src/sys/GENERIC > amd64 > > At first I suspected that it might be the power supply as it was a couple > of > years old so I replaced that. Unfortunately, it has begun doing it again > (had > a couple of weeks respite) so now my suspicions seem to have been > incorrect. > > I was hoping that someone might be able to give me some clues on what I > can do > to reveal the problem. Are there any general debug settings for the kernel > (or > elsewhere) that would maybe give an indication of why it is being rebooted > (assuming it's a software problem)? > > Thanks for any suggestions you may have! > https://lists.freebsd.org/pipermail/freebsd-questions/2009-July/202210.html kern.panic_reboot_wait_time may also be available. -- Adam From owner-freebsd-hackers@freebsd.org Thu Mar 9 04:40:44 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7B79CD03E01 for ; Thu, 9 Mar 2017 04:40:44 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by mx1.freebsd.org (Postfix) with ESMTP id 10E9D1F7 for ; Thu, 9 Mar 2017 04:40:43 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from ppp121-45-87-165.bras1.adl6.internode.on.net (HELO midget.dons.net.au) ([121.45.87.165]) by ipmail06.adl6.internode.on.net with ESMTP; 09 Mar 2017 15:05:33 +1030 Received: from midget.dons.net.au (localhost [127.0.0.1]) by midget.dons.net.au (8.15.1/8.14.9) with ESMTPS id v294ZN1N091273 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 9 Mar 2017 15:05:23 +1030 (CST) (envelope-from darius@dons.net.au) Received: (from mailnull@localhost) by midget.dons.net.au (8.15.1/8.14.9/Submit) id v294KcF8081429 for ; Thu, 9 Mar 2017 14:50:38 +1030 (CST) (envelope-from darius@dons.net.au) X-Authentication-Warning: midget.dons.net.au: mailnull set sender to using -f Received: from [10.176.136.153] (ns.dons.net.au [10.0.2.1]) by ns.dons.net.au (envelope-sender ) (MIMEDefang) with ESMTP id v294Kamt081426; Thu, 09 Mar 2017 14:50:38 +1030 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: open(): O_EVTONLY and O_NOATIME From: "O'Connor, Daniel" In-Reply-To: <20170309031532.0079ab35@rimwks> Date: Thu, 9 Mar 2017 14:50:36 +1030 Cc: Konstantin Belousov , freebsd-hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170309022554.18875d07@rimwks> <20170308235016.GT30979@kib.kiev.ua> <20170309031532.0079ab35@rimwks> To: Rozhuk Ivan X-Mailer: Apple Mail (2.3259) X-Spam-Score: -1 () No, score=-1.0 required=5.0 tests=ALL_TRUSTED, RP_MATCHES_RCVD autolearn=unavailable autolearn_force=no version=3.4.0 X-Scanned-By: MIMEDefang 2.75 on 10.0.2.1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 04:40:44 -0000 > On 9 Mar 2017, at 10:45, Rozhuk Ivan wrote: >=20 >> consider the most often cause for atime update, read(2): VFS >> translates the syscall through all its layers into VOP_READ() call >> for fs-specific action, and the signature of the call is >> VOP_READ(struct vnode *, struct uio *, int ioflag, struct >> ucred *); As you see, there file is already down-casted to vnode, and >> of course we do not want the vnode to loose atime updates just >> because one file is opened which asked for no atime updates. As >> result, upper VFS layers must pass a flag to VOP_READ(). >>=20 >> You are welcome to finish the analysis and to prototype the solution. >=20 > ???? > If file system cant be mount with NOATIME - then it already ready to = support O_NOATIME. Konstantin means that due to the way the file system driver gets = requests there is no information about how they were opened in the first = place. This means that there is no way it could look at all the FDs which have = this file open and see they are all noatime and then disable atime just = for that one. You are right in that if an FS can be mounted noatime it should be able = to work but unfortunately there is no plumbing between the open of the = file and the file system that supports that. -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-hackers@freebsd.org Thu Mar 9 09:26:43 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D47E9D0229C for ; Thu, 9 Mar 2017 09:26:43 +0000 (UTC) (envelope-from Mark.Martinec+freebsd@ijs.si) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 90745D32 for ; Thu, 9 Mar 2017 09:26:43 +0000 (UTC) (envelope-from Mark.Martinec+freebsd@ijs.si) Received: from amavis-ori.ijs.si (localhost [IPv6:::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.ijs.si (Postfix) with ESMTPS id 3vf4lV3tyfz1K2; Thu, 9 Mar 2017 10:26:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= user-agent:message-id:references:in-reply-to:organization :subject:subject:from:from:date:date:content-transfer-encoding :content-type:content-type:mime-version:received:received :received:received; s=jakla4; t=1489051582; x=1491643583; bh=V8U RQTKxhq65IT37FzogpGOVb7Cl4xjoPZ1nRd1rDY4=; b=F3qbLnMQmBD1hSRTpqU 1L9JBLQDDNII3M+X2qnn44ywkoKYmSf7RfJ+2906r93JhJRfSaVz0NeM98HYCOQV BSKZpmI5k6s17qBK5XIE8kAcZVrgCXpNFQuXfce76loEuub5wktdmValIFAyAQqH h+MY+35a+gOsqtmAFlNmekSo= X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([IPv6:::1]) by amavis-ori.ijs.si (mail.ijs.si [IPv6:::1]) (amavisd-new, port 10026) with LMTP id 8u56SahEps53; Thu, 9 Mar 2017 10:26:22 +0100 (CET) Received: from mildred.ijs.si (mailbox.ijs.si [IPv6:2001:1470:ff80::143:1]) by mail.ijs.si (Postfix) with ESMTP id 3vf4lF3jsqz1Jx; Thu, 9 Mar 2017 10:26:17 +0100 (CET) Received: from nabiralnik.ijs.si (nabiralnik.ijs.si [IPv6:2001:1470:ff80::80:16]) by mildred.ijs.si (Postfix) with ESMTP id 3vf4lF2sPCzXM; Thu, 9 Mar 2017 10:26:17 +0100 (CET) Received: from squid2.ijs.si (2001:1470:ff80::3128:2) by webmail.ijs.si with HTTP (HTTP/1.1 POST); Thu, 09 Mar 2017 10:26:17 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Thu, 09 Mar 2017 10:26:17 +0100 From: Mark Martinec To: freebsd-hackers@freebsd.org Cc: Matthias Apitz Subject: Re: Why en_US.UTF-8 locale consider a < A? Organization: Jozef Stefan Institute In-Reply-To: <20170308155947.GA4129@c720-r292778-amd64> References: <062a0098-1975-6d2b-b017-f623e46ca20b@delphij.net> <20170308084047.qc2j3vnrh5hycg32@ivaldir.net> <7ad51573-c575-ad2f-b3bd-b011d15981ed@delphij.net> <20170308155947.GA4129@c720-r292778-amd64> Message-ID: X-Sender: Mark.Martinec+freebsd@ijs.si User-Agent: Roundcube Webmail/1.2.3 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 09:26:44 -0000 2017-03-08 16:59, Matthias Apitz wrote: > I recently came across with a related problem and have two questions > (unresolved until now): > > 1. > Using sort, reading the man page of it, it should be sufficient to > set LC_COLLATE correctly. It seems that setting LANG (or unsetting it) > changes the sort Order, why? The search/priority order is: LC_ALL -> LC_COLLATE -> LANG, so in absence of LC_COLLATE and LC_ALL, the LANG determines the collation. http://pubs.opengroup.org/onlinepubs/7908799/xbd/envvar.html : The values of locale categories are determined by a precedence order; the first condition met below determines the value: If the LC_ALL environment variable is defined and is not null, the value of LC_ALL is used. If the LC_* environment variable ( LC_COLLATE, LC_CTYPE, LC_MESSAGES, LC_MONETARY, LC_NUMERIC, LC_TIME) is defined and is not null, the value of the environment variable is used to initialise the category that corresponds to the environment variable. If the LANG environment variable is defined and is not null, the value of the LANG environment variable is used. If the LANG environment variable is not set or is set to the empty string, the implementation-dependent default locale is used. > 2. > Speaking about German Umlauts, should they be treated as their normal > letters, i.e. 'ä' is like 'a', as one can read in Wiki, or how they are > sorted exactly? Mark From owner-freebsd-hackers@freebsd.org Thu Mar 9 10:03:28 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 42467D03661 for ; Thu, 9 Mar 2017 10:03:28 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1FA8EA9B; Thu, 9 Mar 2017 10:03:28 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1235) id 6740A3ECE; Thu, 9 Mar 2017 10:03:27 +0000 (UTC) Date: Thu, 9 Mar 2017 11:03:27 +0100 From: Baptiste Daroussin To: Matthias Apitz , Xin Li , "freebsd-hackers@freebsd.org" , d@delphij.net, theraven@freebsd.org Subject: Re: Why en_US.UTF-8 locale consider a < A? Message-ID: <20170309100326.h2dwsj43vbmujaeh@ivaldir.net> References: <062a0098-1975-6d2b-b017-f623e46ca20b@delphij.net> <20170308084047.qc2j3vnrh5hycg32@ivaldir.net> <7ad51573-c575-ad2f-b3bd-b011d15981ed@delphij.net> <20170308155947.GA4129@c720-r292778-amd64> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="hxas3do6ihtbhy2s" Content-Disposition: inline In-Reply-To: <20170308155947.GA4129@c720-r292778-amd64> User-Agent: NeoMutt/20170225 (1.8.0) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 10:03:28 -0000 --hxas3do6ihtbhy2s Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 08, 2017 at 04:59:47PM +0100, Matthias Apitz wrote: > El d=EDa Wednesday, March 08, 2017 a las 12:51:11AM -0800, Xin Li escribi= =F3: >=20 > >=20 > >=20 > > On 3/8/17 00:40, Baptiste Daroussin wrote: > > >> Is this result correct? It matches some Debian behavior but not mac= OS > > >> behavior. > > >=20 > > > Yes the result is correct, macOS does not have unicode collation if y= ou want to > > > match the macos behaviour you have to set LC_COLLATE=3DC > >=20 > > Thanks, I also found this https://www.cl.cam.ac.uk/~mgk25/unicode.html > > just for the record if someone else hits the same issue. >=20 > I recently came across with a related problem and have two questions > (unresolved until now): >=20 > 1. > Using sort, reading the man page of it, it should be sufficient to > set LC_COLLATE correctly. It seems that setting LANG (or unsetting it) > changes the sort Order, why? This has been answered by someone else already. >=20 > 2. > Speaking about German Umlauts, should they be treated as their normal > letters, i.e. '=E4' is like 'a', as one can read in Wiki, or how they are > sorted exactly? I don't know the details for this particular case, but we do take the data = =66rom cldr (http://cldr.unicode.org/), so if you check there you will have your a= nswer Best regards, Bapt --hxas3do6ihtbhy2s Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEgOTj3suS2urGXVU3Y4mL3PG3PloFAljBKGoACgkQY4mL3PG3 PlqWXg/+NNwdXb26MIQqcAIaoJblYB4dwz4mItD5FaI2RJ5WyI7CTJq1oI683jNE if8kl8tm61R960iQ9CCUwPMdODpQoWY7mZdr8vR3RYw6XgB/KNH2ajw1O7/Ox8On it8XVYZgJCaoMXzViSDFQDw0fgW75N//C0KEbkxgaT9seEDHlitoouzg+6ejUaPW SBF+izy5zuIXfOqIrzALwrXlvWTfY8j2FGyPewO7CpTLktczShhCWQy0VdxSDn2Q P7xe4v6F+mEz0FsXT8KsH/jhZMbhzx0W1LSRfRrJw0S29v7elRVVgFxwcNNUeEUq 5QVvA8MvynzuV/OWWZ2DsQRQQmafCH6zSYVJAWUnrwlEP0H6XvrUuEjZJ4WHGKUQ 4HkJ3HII2XX9O919j19rgAnDkAqhUq72vGRuOD+7urlu+krK3sLZZrRmAOfKHfLz Cr45Hr/zoFhT3c49Apk+/aC3eYrIl69BS5XKVSxQnMWL5ZcZB/Hs1gjsILBqFDFm 2bz5Ri3eZER0tp0Ks1vTc28eeplW/8mcH6KisWtQw2eGvNKJt3AZdekOUtnKZNsX ZhVJ6zm8+p5Y/6DRBmYw9BZgfAs0W+6hA+4dJBMR5g+9+GC49a2OX7bVEV8qeUqH 9+DdUP87M/sLng9KV6o0sQRRIWZj4cjT9udbxoYXChViAcS+rOM= =GzKr -----END PGP SIGNATURE----- --hxas3do6ihtbhy2s-- From owner-freebsd-hackers@freebsd.org Thu Mar 9 10:49:04 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7E8D5D04668 for ; Thu, 9 Mar 2017 10:49:04 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4A55719C for ; Thu, 9 Mar 2017 10:49:03 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from [89.204.130.133] (helo=[10.181.41.133]) by ms-10.1blu.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1clvcz-0004AW-1W for freebsd-hackers@freebsd.org; Thu, 09 Mar 2017 11:49:01 +0100 From: Matthias Apitz To: Subject: Re: Why =?iso-8859-1?Q?en=5FUS.UTF-8_locale_consider_a_<_A=3F?= Date: Thu, 09 Mar 2017 11:49:00 +0100 User-Agent: Dekko/0.6.20; Qt/5.4.1; ubuntumirclient; Linux; MIME-Version: 1.0 Message-ID: <65d08aac-b84f-4cae-a742-54138da94fbe@unixarea.de> In-Reply-To: <20170309100326.h2dwsj43vbmujaeh@ivaldir.net> References: <062a0098-1975-6d2b-b017-f623e46ca20b@delphij.net> <20170308084047.qc2j3vnrh5hycg32@ivaldir.net> <7ad51573-c575-ad2f-b3bd-b011d15981ed@delphij.net> <20170308155947.GA4129@c720-r292778-amd64> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 89.204.130.133 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 10:49:04 -0000 On Thursday, 9 March 2017 11:03:27 CET, Baptiste Daroussin=20 wrote: >>=20 >> I recently came across with a related problem and have two questions >> (unresolved until now): >>=20 >> 1. >> Using sort, reading the man page of it, it should be sufficient to >> set LC_COLLATE correctly. It seems that setting LANG (or unsetting it) >> changes the sort Order, why? >=20 > This has been answered by someone else already. No. Because my question was not precise enough. When I set in *addition* to=20= LC_COLLATE the LANG even to the same value, this changes the sort order,=20 why? Thx matthias --=20 Sent from my Ubuntu phone http://www.unixarea.de/ From owner-freebsd-hackers@freebsd.org Thu Mar 9 10:38:46 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8D655D042BA; Thu, 9 Mar 2017 10:38:46 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4888D1CB5; Thu, 9 Mar 2017 10:38:46 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: by mail-ua0-x230.google.com with SMTP id u30so75868316uau.0; Thu, 09 Mar 2017 02:38:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=H3ycku3Xlb4JAuzrinsJ6FKhezaV5a30fGV6cFUNo2A=; b=IBX9cYm0EtUmEOj4Iel5sJBcqcpogFC+AYafe9bLkqtGYsaWohRXSmXbB2TFwAG11h aJVZcqmDPR3wx4aeNWg56hpGwg88khdyqy7OerJVjhS2/N1RmMetaAUOw+g+tWEtzWSj HRyu4R7kU7lU2zbxMChE+a76H7xezTexuEbH0tLoY2+iKdmM35RFj3emoNRe51BhnTVj i5ALXtsxqo7WlRcX/32bXrWoUYMY/EulUJXeM/2vpjJu37FvqBznSTkrT/9mnn5VaDD2 MNzxQ9N1CGX6vE7/Z8NrCQkT5+WFv7qD2UGWKw4/bWrPl2lHMTavBzCb5VKhlLXy3dJZ yvUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=H3ycku3Xlb4JAuzrinsJ6FKhezaV5a30fGV6cFUNo2A=; b=nwD8Q/+UpPsDhfoMwzkPuJSRK2kHkbzVB22vaaEzAcdUW0LvgHAdgntgF1zaVrbeqg 6qyzQ79trYoGqabr8bIlqi6BVA7pSkdZFynO24yhTBeUYx8fG53N8DhZagm/Z2fmXHId hqb2M8epSSQKcoGqaPwQaY1JvB0IbWdA8OALfQci8lvSNYh+tO+ZOpBXTH+CbUSZmmPi nkyUdyY9qyWDwZ0adSJM4X6rXZzwmQgmCJyTZq1J6QI5uaQd3OUTy9IrSZtONObyUE4m g4s4jf8wVI510cTmoHiSW9Ct9Apu1ynoGYHNkt3f754mWVyyHa2tEorxkZeivJI5dgpX DXxA== X-Gm-Message-State: AMke39nPVT4Nwiz9/nqS5EmYgo6TwbMYdZuUWY0E/WoOVBtIjgaIMCWP3p6XW8GByjMcI3pHc8W9XOGbzDXpyA== X-Received: by 10.31.137.75 with SMTP id l72mr6722253vkd.138.1489055925238; Thu, 09 Mar 2017 02:38:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.48.143 with HTTP; Thu, 9 Mar 2017 02:38:04 -0800 (PST) In-Reply-To: <86innjojfb.fsf@desk.des.no> References: <86innjojfb.fsf@desk.des.no> From: grarpamp Date: Thu, 9 Mar 2017 05:38:04 -0500 Message-ID: Subject: Re: WikiLeaks CIA Exploits: FreeBSD References Within To: freebsd-security@freebsd.org Cc: freebsd-hackers@freebsd.org, freebsd-questions@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 09 Mar 2017 12:17:21 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 10:38:46 -0000 On Wed, Mar 8, 2017 at 10:52 AM, Dag-Erling Sm=C3=B8rgrav wrot= e: > grarpamp writes: >> https://search.wikileaks.org/?q=3Dfreebsd > That doesn't indicate a vulnerability. Shell code is what you use to Yep, sec folks are aware of the difference between sample and exploit code, and vulnerabilities. https://www.freebsd.org/security/advisories.html http://shell-storm.org/shellcode/ The post wasn't meant to "indicate a vulnerability". But as a heads up that maybe some might end up being published there. On the other hand, there are countless eyes on it, so OS vendors will find out in time, even if they aren't eyeballing it themselves. > legal advice Let us all get legal advice before living, as it might entail risks ;) Lots of sites offer a variety of advice for those facing risks. Here are some related to employers, browsing, and law... https://intelexit.org/ https://www.youtube.com/watch?v=3DfklxuoBXXqw https://www.torproject.org/ https://geti2p.net/ https://www.eff.org/ IANAGPA, but they do exist. (Btw, the pentest turned out to be old Nessus and Metasploit stuff.) From owner-freebsd-hackers@freebsd.org Thu Mar 9 13:13:15 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3649CD0217E for ; Thu, 9 Mar 2017 13:13:15 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5481A648 for ; Thu, 9 Mar 2017 13:13:14 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v29DBbKH014987 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 9 Mar 2017 15:11:37 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v29DBbKH014987 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v29DBa2N014986; Thu, 9 Mar 2017 15:11:36 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 9 Mar 2017 15:11:36 +0200 From: Konstantin Belousov To: "O'Connor, Daniel" Cc: Rozhuk Ivan , freebsd-hackers@freebsd.org Subject: Re: open(): O_EVTONLY and O_NOATIME Message-ID: <20170309131136.GY30979@kib.kiev.ua> References: <20170309022554.18875d07@rimwks> <20170308235016.GT30979@kib.kiev.ua> <20170309031532.0079ab35@rimwks> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.0 (2017-02-23) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 13:13:15 -0000 On Thu, Mar 09, 2017 at 02:50:36PM +1030, O'Connor, Daniel wrote: > > > On 9 Mar 2017, at 10:45, Rozhuk Ivan wrote: > > > >> consider the most often cause for atime update, read(2): VFS > >> translates the syscall through all its layers into VOP_READ() call > >> for fs-specific action, and the signature of the call is > >> VOP_READ(struct vnode *, struct uio *, int ioflag, struct > >> ucred *); As you see, there file is already down-casted to vnode, and > >> of course we do not want the vnode to loose atime updates just > >> because one file is opened which asked for no atime updates. As > >> result, upper VFS layers must pass a flag to VOP_READ(). > >> > >> You are welcome to finish the analysis and to prototype the solution. > > > > ???? > > If file system cant be mount with NOATIME - then it already ready to support O_NOATIME. > > Konstantin means that due to the way the file system driver gets requests there is no information about how they were opened in the first place. > > This means that there is no way it could look at all the FDs which have this file open and see they are all noatime and then disable atime just for that one. Well, I never claimed that the 'look at all the FDs' is needed. I stated that some plumbing to pass O_NOATIME flag from file down to VOPs is needed if this feature is implemented. > > You are right in that if an FS can be mounted noatime it should be able to work but unfortunately there is no plumbing between the open of the file and the file system that supports that. I fail to understand this statement. How somebody's ability to edit /etc/fstab is related to potential unintended or malicious lack of metadata update due to the mis-use of the flags ? From owner-freebsd-hackers@freebsd.org Thu Mar 9 21:48:17 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6038AD05BFE for ; Thu, 9 Mar 2017 21:48:17 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by mx1.freebsd.org (Postfix) with ESMTP id E8DE6D60 for ; Thu, 9 Mar 2017 21:48:15 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from ppp118-210-168-9.bras2.adl6.internode.on.net (HELO midget.dons.net.au) ([118.210.168.9]) by ipmail05.adl6.internode.on.net with ESMTP; 10 Mar 2017 08:13:08 +1030 Received: from midget.dons.net.au (localhost [127.0.0.1]) by midget.dons.net.au (8.15.1/8.14.9) with ESMTPS id v29Lgon4062997 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 10 Mar 2017 08:13:02 +1030 (CST) (envelope-from darius@dons.net.au) Received: (from mailnull@localhost) by midget.dons.net.au (8.15.1/8.14.9/Submit) id v29LU6R7054445 for ; Fri, 10 Mar 2017 08:00:06 +1030 (CST) (envelope-from darius@dons.net.au) X-Authentication-Warning: midget.dons.net.au: mailnull set sender to using -f Received: from [10.0.2.26] ([10.0.2.26]) by ns.dons.net.au (envelope-sender ) (MIMEDefang) with ESMTP id v29LU3fT054082; Fri, 10 Mar 2017 08:00:06 +1030 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: open(): O_EVTONLY and O_NOATIME From: "O'Connor, Daniel" In-Reply-To: <20170309131136.GY30979@kib.kiev.ua> Date: Fri, 10 Mar 2017 08:00:03 +1030 Cc: Rozhuk Ivan , freebsd-hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170309022554.18875d07@rimwks> <20170308235016.GT30979@kib.kiev.ua> <20170309031532.0079ab35@rimwks> <20170309131136.GY30979@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.3259) X-Spam-Score: -1 () No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.0 X-Scanned-By: MIMEDefang 2.75 on 10.0.2.1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 21:48:17 -0000 > On 9 Mar 2017, at 23:41, Konstantin Belousov = wrote: >> This means that there is no way it could look at all the FDs which = have this file open and see they are all noatime and then disable atime = just for that one. >=20 > Well, I never claimed that the 'look at all the FDs' is needed. I = stated > that some plumbing to pass O_NOATIME flag from file down to VOPs is = needed > if this feature is implemented. Sorry, I didn't mean to put words in your mouth. I was just trying to = explain the concept as it seemed OP was having difficulty understanding = and you and he seemed to be talking past each other. >> You are right in that if an FS can be mounted noatime it should be = able to work but unfortunately there is no plumbing between the open of = the file and the file system that supports that. >=20 > I fail to understand this statement. How somebody's ability to edit = /etc/fstab > is related to potential unintended or malicious lack of metadata = update due > to the mis-use of the flags ? That wasn't what I was trying to say. OP said.. > If file system cant be mount with NOATIME - then it already ready to = support O_NOATIME. I took that to mean they thought that if an FS could be mounted noatime = then it should be able to support O_NOATIME. -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-hackers@freebsd.org Sat Mar 11 06:34:41 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 952A5D075FD; Sat, 11 Mar 2017 06:34:41 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 54BC316A9; Sat, 11 Mar 2017 06:34:41 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: by freefall.freebsd.org (Postfix, from userid 1235) id 9CAD81C79; Sat, 11 Mar 2017 06:34:40 +0000 (UTC) Date: Sat, 11 Mar 2017 07:34:40 +0100 From: Baptiste Daroussin To: Steve Kargl Cc: freebsd-doc@freebsd.org, freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: MANPATH not handled correctly Message-ID: <20170311063440.jorxsa3hod2pjuxu@ivaldir.net> References: <20170108192633.GA42537@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="6ih2mue2d5jdfik6" Content-Disposition: inline In-Reply-To: <20170108192633.GA42537@troutmask.apl.washington.edu> User-Agent: NeoMutt/20170225 (1.8.0) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Mar 2017 06:34:41 -0000 --6ih2mue2d5jdfik6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 08, 2017 at 11:26:33AM -0800, Steve Kargl wrote: > MANPATH is not handled correctly. According to the documentation > in apropos(1) and whatis(1): >=20 > MANPATH The standard search path used by man(1) may be changed by > specifying a path in the MANPATH environment variable. Inval= id > paths, or paths without manual databases, are ignored. > Overridden by -M. If MANPATH begins with a colon, it is > appended to the default list; if it ends with a colon, it is > prepended to the default list; or if it contains two adjacent > colons, the standard search path is inserted between the > colons. If none of these conditions are met, it overrides the > standard search path. >=20 > I have a manpage named mkpic in $HOME/man/man1. I also have the FreeBSD > installed manpages, e.g., /usr/share/man/man1/cat.1.gz. If I have > 'setenv MANPATH :$HOME/man' in my .cshrc file, then the following occurs:= =20 >=20 > % setenv | grep MANPATH > MANPATH=3D:/home/kargl/man > % apropos mkpic > (Warning: MANPATH environment variable set) > mkpic(1) - construct a contour image in MIFF image format > % apropos cat > (Warning: MANPATH environment variable set) > matrix(3) - Array and matrix allocation for FFT library >=20 > So, the above description of MANPATH is incorrect as :/home/kargl/man > should have been appended to the default MANPATH. >=20 > Interestingly, manpath(1) seems to described what actually happens > (long lines wrapped): >=20 > % unsetenv MANPATH > % manpath > /home/kargl/man:/usr/local/man:/usr/share/man:/usr/share/openssl/man:\ > /usr/local/lib/perl5/site_perl/man:/usr/local/lib/perl5/5.20/perl/man:\ > /usr/local/share/xpdf/man > % setenv MANPATH :$HOME/sman > % manpath > (Warning: MANPATH environment variable set) > :/home/kargl/man >=20 > The expected result according apropos(1) and whatis(1) for last command is >=20 > % manpath > /home/kargl/man:/usr/local/man:/usr/share/man:/usr/share/openssl/man:\ > /usr/local/lib/perl5/site_perl/man:/usr/local/lib/perl5/5.20/perl/man:\ > /usr/local/share/xpdf/man:/home/kargl/man Sorry it took time, but it is now fixed. the issue was we have kept our man= (1) when importing mandoc and I have not noticed that mandoc had that feature. I implemented it in our man(1) While here I removed the painful warning Best regards, Bapt --6ih2mue2d5jdfik6 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEgOTj3suS2urGXVU3Y4mL3PG3PloFAljDmn0ACgkQY4mL3PG3 PlqIRRAA0GuAKYqCdns5aaXDnYaSlT8sy60sxQVka+MBMn5B22lxpXJwInSg/BqA FZeKXOhiKato4L98FkZwI03mxBZy9ohG/eK3kaBDs3MpD2fLbXl6BSlOvsyOoid6 K1jv/1qGEu1y8H1tCg5Jd2dzr4Do8lhOChMhu16zMpse97aJvJJewv4kMghUnSuu vzmrYH/JtECe2RCBbtbRsNVDlZ1BXDwtVTeEpi3ellGMyiKp4O1W3i6NAeVqv+Fe AYvUUzX2cGU2dvYgm9JEYM4Hk78IBoCutADSb/2bwDqcXSQsZfER4+Z1H7W2f5sL C0rQa1tHTdGMklzV9fgFwz+vuM5QK9XuolQk0sTismPRlTWSx5s2NBPnUT7iAk1Q 8HRkwR40JMT1fs71vV2pSIvDvcJhsclGxzHkYYz8MeciqSbrD8L6hyPq87YFkkgP hQpdH/5VzHLqPqoJtyXusHD42jMX4wtP680PYIj1uEwP3jZBDnXCFVB6AYsDMfLf 0ofSueD2HK+3CciO0oLYhh6GxlH+/6CnZc9S4CjZnpECd+S1LJn9EAqFkQAqEq5U 81kK82jH1YFffpHeKJhZnVh3oj53YRni1dBfI9dAhLRI4/gXrRCcygB6OQjuCpaq x8a3Bwj1Xqb/AcrLjfOSayjMfiQ7O0YMhXfyzygqwVeYHy7E31s= =wBwk -----END PGP SIGNATURE----- --6ih2mue2d5jdfik6-- From owner-freebsd-hackers@freebsd.org Sat Mar 11 06:40:43 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0B3BBD07972; Sat, 11 Mar 2017 06:40:43 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E2CB31A8D; Sat, 11 Mar 2017 06:40:42 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id v2B6eff1056456 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 10 Mar 2017 22:40:41 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id v2B6efIG056455; Fri, 10 Mar 2017 22:40:41 -0800 (PST) (envelope-from sgk) Date: Fri, 10 Mar 2017 22:40:41 -0800 From: Steve Kargl To: Baptiste Daroussin Cc: freebsd-doc@freebsd.org, freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: MANPATH not handled correctly Message-ID: <20170311064041.GA56446@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20170108192633.GA42537@troutmask.apl.washington.edu> <20170311063440.jorxsa3hod2pjuxu@ivaldir.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170311063440.jorxsa3hod2pjuxu@ivaldir.net> User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Mar 2017 06:40:43 -0000 On Sat, Mar 11, 2017 at 07:34:40AM +0100, Baptiste Daroussin wrote: > On Sun, Jan 08, 2017 at 11:26:33AM -0800, Steve Kargl wrote: > > MANPATH is not handled correctly. According to the documentation > > in apropos(1) and whatis(1): > > (snip) > > Sorry it took time, but it is now fixed. the issue was we have kept our man(1) > when importing mandoc and I have not noticed that mandoc had that feature. > > I implemented it in our man(1) > > While here I removed the painful warning > Thank you! Thank you! Thank you! -- Steve 20161221 https://www.youtube.com/watch?v=IbCHE-hONow