From owner-freebsd-arch@FreeBSD.ORG Sun Jan 25 07:38:28 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2E6A8CB7; Sun, 25 Jan 2015 07:38:28 +0000 (UTC) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AFFCEF95; Sun, 25 Jan 2015 07:38:27 +0000 (UTC) Received: by mail-we0-f175.google.com with SMTP id p10so4184099wes.6; Sat, 24 Jan 2015 23:38:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-type:content-transfer-encoding; bh=2gVajXbLBO09gX2LTOrv18pS5H/WYhIlwMKm0TuUEto=; b=BNRXzP5u7UHsYTvp2xBpwpwkqYqCklW90LNK+KjCOKsxLX7WFX/0FdMBhmZvhSW6nB VRXrUz64ZyAIcKKlkWvXaIqJ2PgtQAXGhV9JVppco6nSG/8XVlM7aZpEqadBF2+IgPXX C84qUGg9aLbClGAOXBWCtjuWfnTkc1EqkH3JtzrTd/74X46iISJnkPsHfK3yNXg47m86 WBDZTnv6yyxE0P1dHYri/rXaZtgiNmIXzmPBvof5fVyPaLeYezX0vHQa+Yw/Sq3LJ42z wg/Gi/QpriA3RgG4HPMaD4LoTEdJubUwjeRTFLAJrIOgqNqvGry4HYalM6vQ+xfGGx8x qkOg== X-Received: by 10.180.87.42 with SMTP id u10mr14235078wiz.51.1422171506123; Sat, 24 Jan 2015 23:38:26 -0800 (PST) Received: from ernst.home (p578E2152.dip0.t-ipconnect.de. [87.142.33.82]) by mx.google.com with ESMTPSA id i13sm9122600wjr.7.2015.01.24.23.38.24 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 24 Jan 2015 23:38:25 -0800 (PST) Date: Sun, 25 Jan 2015 08:38:23 +0100 From: Gary Jennejohn To: Baptiste Daroussin Subject: Re: [RFC] Set the default locale to en_US.UTF-8 Message-ID: <20150125083823.0625eb7d@ernst.home> In-Reply-To: <20150124181016.GK81001@ivaldir.etoilebsd.net> References: <20150124143357.GI81001@ivaldir.etoilebsd.net> <20150124181016.GK81001@ivaldir.etoilebsd.net> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2015 07:38:28 -0000 On Sat, 24 Jan 2015 19:10:16 +0100 Baptiste Daroussin wrote: > On Sat, Jan 24, 2015 at 10:52:01AM -0700, Warner Losh wrote: > > > > > On Jan 24, 2015, at 7:33 AM, Baptiste Daroussin wrote: > > > > > > Hi, > > > > > > After a bit of hacking on libedit it is now able to handle unicode inputs in a > > > better way. At least good enough for /bin/sh to work normally in unicode > > > environements. > > > > > > Given that vt handles properly unicode inputs. I would like to propose that now > > > we set the defaults locales on HEAD to en_US.UTF-8. > > > > > > https://reviews.freebsd.org/D1467 > > > > Do recent vintage Terms and its decedents handle UTF-8? If so, then that?s likely > > a reasonable default change. > > From what I'm aware of all modern (including the good old xterm) do support > UTF-8 correctly. > > What about sc? I don't use vt myself because the font is fugly. > > Then again, I speak English, and the change does now explicitly specify a language > > which before defaulted to English. > > Maybe the bsdconfig can be tweak to allow the user to chose the default > language? > -- Gary Jennejohn From owner-freebsd-arch@FreeBSD.ORG Sun Jan 25 09:34:09 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CE53C717; Sun, 25 Jan 2015 09:34:09 +0000 (UTC) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9C62BD9D; Sun, 25 Jan 2015 09:34:09 +0000 (UTC) Received: by mail-pa0-f45.google.com with SMTP id et14so6031647pad.4; Sun, 25 Jan 2015 01:34:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/sDlgflt8+1vnUF7y5EYwSwTbf89cwaUW9VM85BnxHI=; b=JjLg1ahLDsjcx0WgqpKMN0RD4DA/0CFhjLaT3UG3KRIqUjZae6JxHyxE/t3vJ7KBt+ o9i/TUmgakXN7WspVNySVAp72jQlbrU4KHT0W1MwyCwLzHulX/h9cDy0gTyzw/ihUzgt fPZ/nAlmVfrs5roLBGqjf+qXyt4HCPDGW1cbyVAU4wjcJ5l871/TEUn0LZsmA9u/bEUI zK3DhDiS6Pa90a0247247XI31xsbRdHoL7Z1INQjXvv7ZOjN7vehY1pYHxLjFQv7Y6xu b9PuAbbbWtDrO9Efwc2RiG4XaiWxsDGwS+YsHn5LlXQYN8vgp24jUTWxV60jyL9+JnpJ HsBA== MIME-Version: 1.0 X-Received: by 10.68.135.226 with SMTP id pv2mr25809922pbb.48.1422178449029; Sun, 25 Jan 2015 01:34:09 -0800 (PST) Received: by 10.70.101.133 with HTTP; Sun, 25 Jan 2015 01:34:08 -0800 (PST) In-Reply-To: <20150125083823.0625eb7d@ernst.home> References: <20150124143357.GI81001@ivaldir.etoilebsd.net> <20150124181016.GK81001@ivaldir.etoilebsd.net> <20150125083823.0625eb7d@ernst.home> Date: Sun, 25 Jan 2015 03:34:08 -0600 Message-ID: Subject: Re: [RFC] Set the default locale to en_US.UTF-8 From: Adam Vande More To: gljennjohn@gmail.com Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: arch@freebsd.org, Baptiste Daroussin X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2015 09:34:09 -0000 On Sun, Jan 25, 2015 at 1:38 AM, Gary Jennejohn wrote: > What about sc? I don't use vt myself because the font is fugly. > No. That was one of the main driving forces in the creation of VT as well as other sc uglies. You can change your font. -- Adam From owner-freebsd-arch@FreeBSD.ORG Sun Jan 25 14:32:48 2015 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EDC02645; Sun, 25 Jan 2015 14:32:48 +0000 (UTC) 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 81445C17; Sun, 25 Jan 2015 14:32:45 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1YFOF1-000KRJ-Ky; Sun, 25 Jan 2015 17:32:43 +0300 Date: Sun, 25 Jan 2015 17:32:43 +0300 From: Slawa Olhovchenkov To: Baptiste Daroussin Subject: Re: [RFC] Set the default locale to en_US.UTF-8 Message-ID: <20150125143243.GB76051@zxy.spb.ru> References: <20150124143357.GI81001@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150124143357.GI81001@ivaldir.etoilebsd.net> User-Agent: Mutt/1.5.23 (2014-03-12) 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 Cc: arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2015 14:32:49 -0000 On Sat, Jan 24, 2015 at 03:33:57PM +0100, Baptiste Daroussin wrote: > Hi, > > After a bit of hacking on libedit it is now able to handle unicode inputs in a > better way. At least good enough for /bin/sh to work normally in unicode > environements. > > Given that vt handles properly unicode inputs. I would like to propose that now > we set the defaults locales on HEAD to en_US.UTF-8. > > https://reviews.freebsd.org/D1467 > > Best regards, > Bapt NO! Please, NOT! Not all bytestring allowed in UTF-8, as result -- unpedicable failed execution of sed, grep, vi, ed and etc. From owner-freebsd-arch@FreeBSD.ORG Sun Jan 25 14:58:18 2015 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 31AC9CB9 for ; Sun, 25 Jan 2015 14:58:18 +0000 (UTC) Received: from barracuda.ixsystems.com (mail.ixsystems.com [69.198.165.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.ixsystems.com", Issuer "Go Daddy Secure Certification Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 09B1BDC1 for ; Sun, 25 Jan 2015 14:58:17 +0000 (UTC) X-ASG-Debug-ID: 1422197896-08ca0411ac168f0001-z6yBwP Received: from mail.iXsystems.com ([10.2.55.1]) by barracuda.ixsystems.com with ESMTP id wWtmbY2YAgUBGAY7 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 25 Jan 2015 06:58:16 -0800 (PST) X-Barracuda-Envelope-From: jkh@ixsystems.com X-Barracuda-RBL-Trusted-Forwarder: 10.2.55.1 X-ASG-Whitelist: Client Received: from [10.8.0.34] (unknown [10.8.0.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.iXsystems.com (Postfix) with ESMTPSA id 0A17D88F41; Sun, 25 Jan 2015 06:58:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ixsystems.com; s=newknight0; t=1422197896; bh=IGaVMTZ/va55bICvAUMAEYlqrVCIxEiT6ZT0Y4dz8O0=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=bJL+nWRLcCzrgOVS21NgPpNaOcmiT2zf9zTWWnr0W1XUfgQzWkBbDQeYiUkVa3eON Qe25yV5GyGp3xWlyNvtt98yy2a7x1KeqyKBXTBv/Q/PIOB6Dyhvk7nrdUkAlKQz7Lj XFLZWhHKt0hwgYTqWQtJ9i31+OaCYuK8SSw0oIs4= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.4\)) Subject: Re: [RFC] Set the default locale to en_US.UTF-8 From: Jordan Hubbard X-ASG-Orig-Subj: Re: [RFC] Set the default locale to en_US.UTF-8 In-Reply-To: <20150125143243.GB76051@zxy.spb.ru> Date: Sun, 25 Jan 2015 06:58:13 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7B1D8345-248B-4C44-9568-079BA29614C2@ixsystems.com> References: <20150124143357.GI81001@ivaldir.etoilebsd.net> <20150125143243.GB76051@zxy.spb.ru> To: Slawa Olhovchenkov X-Mailer: Apple Mail (2.2070.4) X-Barracuda-Connect: UNKNOWN[10.2.55.1] X-Barracuda-Start-Time: 1422197896 X-Barracuda-Encrypted: DHE-RSA-CAMELLIA256-SHA X-Barracuda-URL: https://10.2.0.41:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at ixsystems.com X-Barracuda-BRTS-Status: 1 Cc: arch@FreeBSD.org, Baptiste Daroussin X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2015 14:58:18 -0000 > On Jan 25, 2015, at 6:32 AM, Slawa Olhovchenkov = wrote: >=20 > NO! Please, NOT! > Not all bytestring allowed in UTF-8, as result -- unpedicable failed > execution of sed, grep, vi, ed and etc. Huh. Someone should warn Apple then, since $LANG has been set to = en_US.UTF-8 by default in OS X for years now. I just checked, and = sed/grep/vi/ed/etc all still work. :) It=E2=80=99s a good idea to change it. We have outgrown ISO-Latin1, and = UTF-8 solves a host of ugly I18N interoperability problems when used = consistently. - Jordan From owner-freebsd-arch@FreeBSD.ORG Sun Jan 25 15:50:03 2015 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A6DAF978; Sun, 25 Jan 2015 15:50:03 +0000 (UTC) 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 60C4C23D; Sun, 25 Jan 2015 15:50:03 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1YFPRo-000Lac-UO; Sun, 25 Jan 2015 18:50:00 +0300 Date: Sun, 25 Jan 2015 18:50:00 +0300 From: Slawa Olhovchenkov To: Jordan Hubbard Subject: Re: [RFC] Set the default locale to en_US.UTF-8 Message-ID: <20150125155000.GD76051@zxy.spb.ru> References: <20150124143357.GI81001@ivaldir.etoilebsd.net> <20150125143243.GB76051@zxy.spb.ru> <7B1D8345-248B-4C44-9568-079BA29614C2@ixsystems.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <7B1D8345-248B-4C44-9568-079BA29614C2@ixsystems.com> User-Agent: Mutt/1.5.23 (2014-03-12) 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 Cc: arch@FreeBSD.org, Baptiste Daroussin X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2015 15:50:03 -0000 On Sun, Jan 25, 2015 at 06:58:13AM -0800, Jordan Hubbard wrote: > > > On Jan 25, 2015, at 6:32 AM, Slawa Olhovchenkov wrote: > > > > NO! Please, NOT! > > Not all bytestring allowed in UTF-8, as result -- unpedicable failed > > execution of sed, grep, vi, ed and etc. > > Huh. Someone should warn Apple then, since $LANG has been set to en_US.UTF-8 by default in OS X for years now. I just checked, and sed/grep/vi/ed/etc all still work. :) > > It's a good idea to change it. We have outgrown ISO-Latin1, and UTF-8 solves a host of ugly I18N interoperability problems when used consistently. I am years use ru_RU.KOI8-R. Now I try use ru_RU.UTF8 and got some issuse (on 10-STABLE). 9.x and OS may have dufferent version of software and don't touch this. vi ~/tips.work /home/slw/tips.work: unmodified: line 1; Conversion error on line 3 This is koi8 file in utf8 locale. Other case -- file names in koi8 locale -- this is invalid in utf-8. Change locale from C to utf8 may cause trouble. This is (change from one-byte tu multi-bytes locale) may be do individualy, after inspecting systems. This is may be OK for new install, but not [automatic] for update/upgrade. From owner-freebsd-arch@FreeBSD.ORG Sun Jan 25 16:11:10 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 96835C2D; Sun, 25 Jan 2015 16:11:10 +0000 (UTC) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5B8FD617; Sun, 25 Jan 2015 16:11:10 +0000 (UTC) Received: by mail-ig0-f179.google.com with SMTP id l13so4815038iga.0; Sun, 25 Jan 2015 08:11:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=qOStGsSx6GFxP0b4m9WgSsHD9j/HGk9Q3Yf2QmOSZiE=; b=v1xeXe7NB4kJuvvFSDQNa5oVFNwzq9+etyaLy7r4vipj5A8MyLcBJ0/0z+ZSPxnCJy eSRh0cVi7sl99H1KxjU53BoTYH4z0dvq0vXtdNg5OAo9FnNtogjd90CJ7U0PkD8Prtj6 3CXZDFCvR6zBdOFNsTLidL/1jWy6NlP6zHjNdxleHEXBnz6YcSKBeUMHbJH5F8G5YFS6 JMBc6tb3Tz8PPFXleOtR6rBwz7rsMohk+UC5xx+kPyl0rIfhieKb6b5lvMyx90Fqp65h req5VbDUwltifw82fRyq5b1wuUy2MXXmbJzU8mPnRZozIubO9jVWodDL3wTE8hzQjaM+ qxwA== MIME-Version: 1.0 X-Received: by 10.107.155.197 with SMTP id d188mr9589522ioe.29.1422202269660; Sun, 25 Jan 2015 08:11:09 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.36.78.14 with HTTP; Sun, 25 Jan 2015 08:11:09 -0800 (PST) In-Reply-To: <20150125155000.GD76051@zxy.spb.ru> References: <20150124143357.GI81001@ivaldir.etoilebsd.net> <20150125143243.GB76051@zxy.spb.ru> <7B1D8345-248B-4C44-9568-079BA29614C2@ixsystems.com> <20150125155000.GD76051@zxy.spb.ru> Date: Sun, 25 Jan 2015 08:11:09 -0800 X-Google-Sender-Auth: yW7vAPHcfQRtIoXoUx7VL3ykpTo Message-ID: Subject: Re: [RFC] Set the default locale to en_US.UTF-8 From: Adrian Chadd To: Slawa Olhovchenkov Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-arch@freebsd.org" , Baptiste Daroussin , Jordan Hubbard X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2015 16:11:10 -0000 File bugs file bugs file bug file bugs *sings* Yes, file bugs when you come across these issues. -adrian On 25 January 2015 at 07:50, Slawa Olhovchenkov wrote: > On Sun, Jan 25, 2015 at 06:58:13AM -0800, Jordan Hubbard wrote: > >> >> > On Jan 25, 2015, at 6:32 AM, Slawa Olhovchenkov wrote: >> > >> > NO! Please, NOT! >> > Not all bytestring allowed in UTF-8, as result -- unpedicable failed >> > execution of sed, grep, vi, ed and etc. >> >> Huh. Someone should warn Apple then, since $LANG has been set to en_US.UTF-8 by default in OS X for years now. I just checked, and sed/grep/vi/ed/etc all still work. :) >> >> It's a good idea to change it. We have outgrown ISO-Latin1, and UTF-8 solves a host of ugly I18N interoperability problems when used consistently. > > I am years use ru_RU.KOI8-R. Now I try use ru_RU.UTF8 and got some > issuse (on 10-STABLE). 9.x and OS may have dufferent version of > software and don't touch this. > > vi ~/tips.work > /home/slw/tips.work: unmodified: line 1; Conversion error on line 3 > > This is koi8 file in utf8 locale. > > Other case -- file names in koi8 locale -- this is invalid in utf-8. > Change locale from C to utf8 may cause trouble. > This is (change from one-byte tu multi-bytes locale) may be do > individualy, after inspecting systems. This is may be OK for new > install, but not [automatic] for update/upgrade. > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Sun Jan 25 16:23:09 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7215DEE7; Sun, 25 Jan 2015 16:23:09 +0000 (UTC) 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 2A4497F8; Sun, 25 Jan 2015 16:23:09 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1YFPxq-000M5s-9I; Sun, 25 Jan 2015 19:23:06 +0300 Date: Sun, 25 Jan 2015 19:23:06 +0300 From: Slawa Olhovchenkov To: Adrian Chadd Subject: Re: [RFC] Set the default locale to en_US.UTF-8 Message-ID: <20150125162306.GP3698@zxy.spb.ru> References: <20150124143357.GI81001@ivaldir.etoilebsd.net> <20150125143243.GB76051@zxy.spb.ru> <7B1D8345-248B-4C44-9568-079BA29614C2@ixsystems.com> <20150125155000.GD76051@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) 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 Cc: "freebsd-arch@freebsd.org" , Baptiste Daroussin , Jordan Hubbard X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2015 16:23:09 -0000 On Sun, Jan 25, 2015 at 08:11:09AM -0800, Adrian Chadd wrote: > File bugs file bugs file bug file bugs *sings* > > Yes, file bugs when you come across these issues. You offer me to submit PR? I think this is not fixable: locale is UTF-8, historical content is not valid UTF-8, software wait text in current locale and got crap. No way. I see only two choise: 1. use locale that accept any byte string 2. strict convert all content to utf-8 and use utf-8. strict convert is required. And this is can't be done in general case (text string may be any any places). > On 25 January 2015 at 07:50, Slawa Olhovchenkov wrote: > > On Sun, Jan 25, 2015 at 06:58:13AM -0800, Jordan Hubbard wrote: > > > >> > >> > On Jan 25, 2015, at 6:32 AM, Slawa Olhovchenkov wrote: > >> > > >> > NO! Please, NOT! > >> > Not all bytestring allowed in UTF-8, as result -- unpedicable failed > >> > execution of sed, grep, vi, ed and etc. > >> > >> Huh. Someone should warn Apple then, since $LANG has been set to en_US.UTF-8 by default in OS X for years now. I just checked, and sed/grep/vi/ed/etc all still work. :) > >> > >> It's a good idea to change it. We have outgrown ISO-Latin1, and UTF-8 solves a host of ugly I18N interoperability problems when used consistently. > > > > I am years use ru_RU.KOI8-R. Now I try use ru_RU.UTF8 and got some > > issuse (on 10-STABLE). 9.x and OS may have dufferent version of > > software and don't touch this. > > > > vi ~/tips.work > > /home/slw/tips.work: unmodified: line 1; Conversion error on line 3 > > > > This is koi8 file in utf8 locale. > > > > Other case -- file names in koi8 locale -- this is invalid in utf-8. > > Change locale from C to utf8 may cause trouble. > > This is (change from one-byte tu multi-bytes locale) may be do > > individualy, after inspecting systems. This is may be OK for new > > install, but not [automatic] for update/upgrade. > > _______________________________________________ > > freebsd-arch@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Sun Jan 25 16:50:22 2015 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 859B325D; Sun, 25 Jan 2015 16:50:22 +0000 (UTC) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 450DCA3C; Sun, 25 Jan 2015 16:50:21 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.60.3]) by phk.freebsd.dk (Postfix) with ESMTP id CB5D03B8B7; Sun, 25 Jan 2015 16:50:13 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.9/8.14.9) with ESMTP id t0PGoCYr023507; Sun, 25 Jan 2015 16:50:13 GMT (envelope-from phk@phk.freebsd.dk) To: Jordan Hubbard Subject: Re: [RFC] Set the default locale to en_US.UTF-8 In-reply-to: <7B1D8345-248B-4C44-9568-079BA29614C2@ixsystems.com> From: "Poul-Henning Kamp" References: <20150124143357.GI81001@ivaldir.etoilebsd.net> <20150125143243.GB76051@zxy.spb.ru> <7B1D8345-248B-4C44-9568-079BA29614C2@ixsystems.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <23505.1422204612.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Sun, 25 Jan 2015 16:50:12 +0000 Message-ID: <23506.1422204612@critter.freebsd.dk> Cc: arch@FreeBSD.org, Baptiste Daroussin , Slawa Olhovchenkov X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2015 16:50:22 -0000 -------- In message <7B1D8345-248B-4C44-9568-079BA29614C2@ixsystems.com>, Jordan Hu= bbard writes: The point about vi(1) is that if you happen to open an ISO-8859 file while in UTF-8 mode, change something on the first line, it will happily and almost imperceptively truncate your file at the first non-UTF byte sequence. Needless to say, that is *not* the expected behaviour. -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From owner-freebsd-arch@FreeBSD.ORG Sun Jan 25 17:10:47 2015 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A61715E6; Sun, 25 Jan 2015 17:10:47 +0000 (UTC) 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 5E77BB80; Sun, 25 Jan 2015 17:10:47 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1YFQhu-000MlR-Lv; Sun, 25 Jan 2015 20:10:42 +0300 Date: Sun, 25 Jan 2015 20:10:42 +0300 From: Slawa Olhovchenkov To: Poul-Henning Kamp Subject: Re: [RFC] Set the default locale to en_US.UTF-8 Message-ID: <20150125171042.GQ3698@zxy.spb.ru> References: <20150124143357.GI81001@ivaldir.etoilebsd.net> <20150125143243.GB76051@zxy.spb.ru> <7B1D8345-248B-4C44-9568-079BA29614C2@ixsystems.com> <23506.1422204612@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <23506.1422204612@critter.freebsd.dk> User-Agent: Mutt/1.5.23 (2014-03-12) 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 Cc: arch@FreeBSD.org, Baptiste Daroussin , Jordan Hubbard X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2015 17:10:47 -0000 On Sun, Jan 25, 2015 at 04:50:12PM +0000, Poul-Henning Kamp wrote: > -------- > In message <7B1D8345-248B-4C44-9568-079BA29614C2@ixsystems.com>, Jordan Hubbard > writes: > > The point about vi(1) is that if you happen to open an ISO-8859 file > while in UTF-8 mode, change something on the first line, it will > happily and almost imperceptively truncate your file at the first > non-UTF byte sequence. > > Needless to say, that is *not* the expected behaviour. I can't remember other cases, but vi(1) is not exclusion. Similar cases will be with some like sed/grep. I think this behaviour must be stopper to _upgrade_ locale on existing installations. System software (from FreeBSD base) not exclusive for this behaviour (dangerous dependens from current locale). This is may be third-party sofware or software writen by customer. Unexpected setting locale to UTF-8 may be broken this software. For new install setting locale to UTF-8 will be ok. From owner-freebsd-arch@FreeBSD.ORG Sun Jan 25 17:36:55 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1A2F9CD3; Sun, 25 Jan 2015 17:36:55 +0000 (UTC) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0112.outbound.protection.outlook.com [65.55.169.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DFA8CDEC; Sun, 25 Jan 2015 17:36:53 +0000 (UTC) Received: from BY2PR05CA028.namprd05.prod.outlook.com (10.141.250.18) by BN1PR05MB437.namprd05.prod.outlook.com (10.141.58.11) with Microsoft SMTP Server (TLS) id 15.1.65.19; Sun, 25 Jan 2015 17:36:51 +0000 Received: from BN1BFFO11FD001.protection.gbl (2a01:111:f400:7c10::1:126) by BY2PR05CA028.outlook.office365.com (2a01:111:e400:2c5f::18) with Microsoft SMTP Server (TLS) id 15.1.65.19 via Frontend Transport; Sun, 25 Jan 2015 17:36:50 +0000 Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by BN1BFFO11FD001.mail.protection.outlook.com (10.58.144.64) with Microsoft SMTP Server (TLS) id 15.1.75.11 via Frontend Transport; Sun, 25 Jan 2015 17:36:50 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sun, 25 Jan 2015 09:36:49 -0800 Received: from chaos.jnpr.net (chaos.jnpr.net [172.21.16.28]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t0PHamW06222; Sun, 25 Jan 2015 09:36:48 -0800 (PST) (envelope-from sjg@juniper.net) Received: from chaos (localhost [127.0.0.1]) by chaos.jnpr.net (Postfix) with ESMTP id 6EBCF580A3; Sun, 25 Jan 2015 09:36:48 -0800 (PST) To: Baptiste Daroussin Subject: Re: [RFC] Set the default locale to en_US.UTF-8 In-Reply-To: <20150124143357.GI81001@ivaldir.etoilebsd.net> References: <20150124143357.GI81001@ivaldir.etoilebsd.net> Comments: In-reply-to: Baptiste Daroussin message dated "Sat, 24 Jan 2015 15:33:57 +0100." From: "Simon J. Gerraty" X-Mailer: MH-E 8.0.3; nmh 1.3; GNU Emacs 22.3.1 Date: Sun, 25 Jan 2015 09:36:48 -0800 Message-ID: <21829.1422207408@chaos> MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.16 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.16) smtp.mailfrom=sjg@juniper.net; freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=permerror action=none header.from=juniper.net; X-Forefront-Antispam-Report: CIP:66.129.239.16; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(24454002)(50986999)(106466001)(76176999)(117636001)(62966003)(77156002)(450100001)(50466002)(46102003)(105596002)(50226001)(110136001)(92566002)(77096005)(33716001)(2950100001)(76506005)(48376002)(86362001)(87936001)(57986006)(19580395003)(19580405001)(6806004)(62816006)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB437; H:P-EMF02-SAC.jnpr.net; FPR:; SPF:None; MLV:sfv; LANG:en; X-DmarcAction-Test: None X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:BN1PR05MB437; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:BN1PR05MB437; X-Forefront-PRVS: 046753C63C X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB437; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Jan 2015 17:36:50.2014 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.16] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB437 Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2015 17:36:55 -0000 Baptiste Daroussin wrote: > Given that vt handles properly unicode inputs. I would like to propose that now > we set the defaults locales on HEAD to en_US.UTF-8. We've recently been inflicted with more Linux machines at work and these have en_US.UTF-8 as default locale. I run emacs -nw inside screen inside xterm (so I can easily re-attach from anywhere). I traced the fact that meta key didn't work to the locale setting. Forcing it to 'C' made everything work as it should. In the past I've found (on some systems at least) that locale's other than 'C' break shell scripts - because character classes no longer match. I assume this is due to different collating rules. Thus my FAQ entry on how to survive with these machines mentions that Setting ``LANG=C`` and ``LC_ALL=C`` fixes lots of problems. So my vote would be "no" ;-) From owner-freebsd-arch@FreeBSD.ORG Sun Jan 25 18:04:36 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A16F78CD; Sun, 25 Jan 2015 18:04:36 +0000 (UTC) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0142.outbound.protection.outlook.com [65.55.169.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9F760151; Sun, 25 Jan 2015 18:04:35 +0000 (UTC) Received: from BLUPR05CA0070.namprd05.prod.outlook.com (10.141.20.40) by BN1PR05MB440.namprd05.prod.outlook.com (10.141.58.26) with Microsoft SMTP Server (TLS) id 15.1.65.19; Sun, 25 Jan 2015 17:49:33 +0000 Received: from BL2FFO11FD049.protection.gbl (2a01:111:f400:7c09::183) by BLUPR05CA0070.outlook.office365.com (2a01:111:e400:855::40) with Microsoft SMTP Server (TLS) id 15.1.65.19 via Frontend Transport; Sun, 25 Jan 2015 17:49:33 +0000 Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by BL2FFO11FD049.mail.protection.outlook.com (10.173.161.211) with Microsoft SMTP Server (TLS) id 15.1.75.11 via Frontend Transport; Sun, 25 Jan 2015 17:49:33 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sun, 25 Jan 2015 09:49:31 -0800 Received: from chaos.jnpr.net (chaos.jnpr.net [172.21.16.28]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t0PHnUW11644; Sun, 25 Jan 2015 09:49:30 -0800 (PST) (envelope-from sjg@juniper.net) Received: from chaos (localhost [127.0.0.1]) by chaos.jnpr.net (Postfix) with ESMTP id 9B881580A3; Sun, 25 Jan 2015 09:49:30 -0800 (PST) To: Slawa Olhovchenkov Subject: Re: [RFC] Set the default locale to en_US.UTF-8 In-Reply-To: <20150125171042.GQ3698@zxy.spb.ru> References: <20150124143357.GI81001@ivaldir.etoilebsd.net> <20150125143243.GB76051@zxy.spb.ru> <7B1D8345-248B-4C44-9568-079BA29614C2@ixsystems.com> <23506.1422204612@critter.freebsd.dk> <20150125171042.GQ3698@zxy.spb.ru> Comments: In-reply-to: Slawa Olhovchenkov message dated "Sun, 25 Jan 2015 20:10:42 +0300." From: "Simon J. Gerraty" X-Mailer: MH-E 8.0.3; nmh 1.3; GNU Emacs 22.3.1 Date: Sun, 25 Jan 2015 09:49:30 -0800 Message-ID: <23185.1422208170@chaos> MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.16 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.16) smtp.mailfrom=sjg@juniper.net; freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=permerror action=none header.from=juniper.net; X-Forefront-Antispam-Report: CIP:66.129.239.16; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(24454002)(87936001)(6806004)(50226001)(110136001)(92566002)(77096005)(4477795004)(50986999)(76176999)(2950100001)(117636001)(86362001)(93886004)(57986006)(105596002)(46102003)(19580405001)(106466001)(50466002)(19580395003)(33716001)(48376002)(62966003)(76506005)(77156002)(62816006)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB440; H:P-EMF02-SAC.jnpr.net; FPR:; SPF:None; MLV:sfv; LANG:en; X-DmarcAction-Test: None X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:BN1PR05MB440; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:BN1PR05MB440; X-Forefront-PRVS: 046753C63C X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB440; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Jan 2015 17:49:33.2960 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.16] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB440 Cc: arch@freebsd.org, Poul-Henning Kamp , Jordan Hubbard , Baptiste Daroussin X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2015 18:04:36 -0000 Slawa Olhovchenkov wrote: > System software (from FreeBSD base) not exclusive for this behaviour > (dangerous dependens from current locale). This is may be third-party > sofware or software writen by customer. Unexpected setting locale to > UTF-8 may be broken this software. Yes, svn client fails on checkout if file contains UTF-8 and client's local is not compatible, error is to the effect of "cannot translate". Only fix is to change loacle to UTF-8 then remove the offending chars if possible. UTF-8 is a bit like GPL - forces everyone to follow suit. From owner-freebsd-arch@FreeBSD.ORG Sun Jan 25 18:44:27 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7AC503FE for ; Sun, 25 Jan 2015 18:44:27 +0000 (UTC) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0854A839 for ; Sun, 25 Jan 2015 18:44:27 +0000 (UTC) Received: by mail-wg0-f49.google.com with SMTP id k14so5633937wgh.8 for ; Sun, 25 Jan 2015 10:44:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=DPMsY55CFYyJDJTR2fiQYy/Qd4eNSV+zdlU2wQY0l1Y=; b=oaIm2nsOAuV1FJeAtegwlG9ZHeXBAXBZNgId3l5ntKR/Gr6i14nDI49vKQshLry/w2 z3g83IVxYWtjfhlYZPL8C+DGwQFy6ntNIlc8+cBfq5I8iCIR58CT2srY9ydMhfXgmgza nGmKoxBBEYkWWCv8qNZvv+w/fqa4iOyR0FFlSxK3HWjhw6bZqyy7XUZhLLFxgI6TCUQp f73AVlj4bIQiKC6cqshpzDXz+W0KMjtQrX4/zfDyT6qPO/lIr2l078sy3FcTB6VKfyeV riQHik0eKAmP4PXjyePVLBp7xEVnFmIkiY+ee/vC4BWhmrVXWmMVkIWQUne03Ft/6g67 f45A== X-Received: by 10.194.172.35 with SMTP id az3mr19792569wjc.43.1422211465459; Sun, 25 Jan 2015 10:44:25 -0800 (PST) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id fo15sm10762082wic.19.2015.01.25.10.44.23 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 25 Jan 2015 10:44:24 -0800 (PST) Sender: Baptiste Daroussin Date: Sun, 25 Jan 2015 19:44:22 +0100 From: Baptiste Daroussin To: "Simon J. Gerraty" Subject: Re: [RFC] Set the default locale to en_US.UTF-8 Message-ID: <20150125184422.GN81001@ivaldir.etoilebsd.net> References: <20150124143357.GI81001@ivaldir.etoilebsd.net> <21829.1422207408@chaos> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6yHiY5vv/BiPjcMt" Content-Disposition: inline In-Reply-To: <21829.1422207408@chaos> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2015 18:44:27 -0000 --6yHiY5vv/BiPjcMt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 25, 2015 at 09:36:48AM -0800, Simon J. Gerraty wrote: > Baptiste Daroussin wrote: > > Given that vt handles properly unicode inputs. I would like to propose = that now > > we set the defaults locales on HEAD to en_US.UTF-8. >=20 > We've recently been inflicted with more Linux machines at work > and these have en_US.UTF-8 as default locale. >=20 > I run emacs -nw inside screen inside xterm (so I can easily re-attach > from anywhere). I traced the fact that meta key didn't work to the > locale setting. Forcing it to 'C' made everything work as it should. >=20 > In the past I've found (on some systems at least) that locale's other > than 'C' break shell scripts - because character classes no longer > match. I assume this is due to different collating rules. >=20 > Thus my FAQ entry on how to survive with these machines mentions that > Setting ``LANG=3DC`` and ``LC_ALL=3DC`` fixes lots of problems. >=20 > So my vote would be "no" ;-) >=20 The collation change is fixed by my proposal: collation remain set to C Concerning vi in head it does support correctly unicode. Concerning sed/grep I'm not aware of any problem. There were to my knowledge 2 issues: - libedit which is now fixed. - console which is fixed by the switch to vt Bapt --6yHiY5vv/BiPjcMt Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlTFOYYACgkQ8kTtMUmk6ExmtQCfcgd8qwPoLvUD8SDuy/mlgeNd vPQAoLbLUXzrzUeA1cApsczjb5v7PY+J =KjbZ -----END PGP SIGNATURE----- --6yHiY5vv/BiPjcMt-- From owner-freebsd-arch@FreeBSD.ORG Sun Jan 25 18:46:13 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AEAEB4F5 for ; Sun, 25 Jan 2015 18:46:13 +0000 (UTC) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3AA4A85B for ; Sun, 25 Jan 2015 18:46:13 +0000 (UTC) Received: by mail-wg0-f48.google.com with SMTP id x12so5629069wgg.7 for ; Sun, 25 Jan 2015 10:46:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=6SQHYG+SpZcCFBbmcEUrAdWovqpDSnCndCrtQkQyM1Q=; b=n2wm1/IL6I3Qw9V7Lzl6zrGlvDLgXEojw3cfZYCPqL/Myr7vzZtL2P8kJkqSetX2ah Ohkc5/Xoc5ZG3cZXmER0XjQQRumeHbt55d2n/MrXM5/9nCSstaLerMEuE4cfP4mwQKmb bwly8an5X90MigJ+dsK6py8gjijIOIBgIskQMorQJylihtAyyUdjhQm/S4LI7pHDWZn9 TgPcaJRU0IeO4H3Kbi1L1MpQFuLJHRczj68BKZ+LM9Ulc3xBMuKY5+1oqeLm5fMwb8oo OfT8Pm1oqRJCtlW1tump1VepiY8N4EhNZPR2Jfu9z/e2iQqR7OX96loWjnPN7hLoTS2f tQKQ== X-Received: by 10.180.90.74 with SMTP id bu10mr18806093wib.52.1422211571693; Sun, 25 Jan 2015 10:46:11 -0800 (PST) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id i13sm11172767wjr.7.2015.01.25.10.46.10 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 25 Jan 2015 10:46:10 -0800 (PST) Sender: Baptiste Daroussin Date: Sun, 25 Jan 2015 19:46:08 +0100 From: Baptiste Daroussin To: Poul-Henning Kamp Subject: Re: [RFC] Set the default locale to en_US.UTF-8 Message-ID: <20150125184608.GO81001@ivaldir.etoilebsd.net> References: <20150124143357.GI81001@ivaldir.etoilebsd.net> <20150125143243.GB76051@zxy.spb.ru> <7B1D8345-248B-4C44-9568-079BA29614C2@ixsystems.com> <23506.1422204612@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="iEWWOZ/QYGWEaBRW" Content-Disposition: inline In-Reply-To: <23506.1422204612@critter.freebsd.dk> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: arch@FreeBSD.org, Jordan Hubbard , Slawa Olhovchenkov X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2015 18:46:13 -0000 --iEWWOZ/QYGWEaBRW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 25, 2015 at 04:50:12PM +0000, Poul-Henning Kamp wrote: > -------- > In message <7B1D8345-248B-4C44-9568-079BA29614C2@ixsystems.com>, Jordan H= ubbard > writes: >=20 > The point about vi(1) is that if you happen to open an ISO-8859 file > while in UTF-8 mode, change something on the first line, it will > happily and almost imperceptively truncate your file at the first > non-UTF byte sequence. >=20 > Needless to say, that is *not* the expected behaviour. >=20 That was the case with old vi not with the vi we have in head at least I'm = not able to truncate files with actual vi Bapt --iEWWOZ/QYGWEaBRW Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlTFOfAACgkQ8kTtMUmk6Ez5SACglNhZOF2KE3RgWhvMxFhhpu2j YYoAoK3q0rxnutz0HD47FKPP2TUxlFip =4R13 -----END PGP SIGNATURE----- --iEWWOZ/QYGWEaBRW-- From owner-freebsd-arch@FreeBSD.ORG Sun Jan 25 18:49:20 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 353475EB for ; Sun, 25 Jan 2015 18:49:20 +0000 (UTC) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B4F50886 for ; Sun, 25 Jan 2015 18:49:19 +0000 (UTC) Received: by mail-we0-f179.google.com with SMTP id q59so5651507wes.10 for ; Sun, 25 Jan 2015 10:49:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=RIH3P0JRIkevz8itGRv6crLNJ9hiaIQtbA1B9Wa6Ajw=; b=FYHbMb1hIKKutYGyn8ARQDDvUarF8pBdFBup2vwoLlm4brVsOioqNqa3le+uvS1q3F 25E8OEkF+b13DkW0/n8j4Dh3jRlO7R7Sf2/nEyNThf+ZzZwc0JQpFz/2qOOwu3W1nilC ePKx8O1ysWSekfeFdQ0QXebwS+GFtWqjVe2YQvCoH1jj+lmcGRLz3XNa2QOAVQLSr2yF tdqlBt9rYcwHPvQNTzqrGZ8K0Wi129b8ANomrTPTO7y9DnFC2zrgIpoxQr2QbFK2MQpH 1s6K0RkKnz/8HMU2TNVMU3i+lEmYJ87rxea/+Wi7MZL5bWMTAkOAu7X7FLdeDCBONsnm qjAA== X-Received: by 10.194.85.17 with SMTP id d17mr35616883wjz.61.1422211757513; Sun, 25 Jan 2015 10:49:17 -0800 (PST) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id mz10sm2976055wic.9.2015.01.25.10.49.16 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 25 Jan 2015 10:49:16 -0800 (PST) Sender: Baptiste Daroussin Date: Sun, 25 Jan 2015 19:49:14 +0100 From: Baptiste Daroussin To: "Simon J. Gerraty" Subject: Re: [RFC] Set the default locale to en_US.UTF-8 Message-ID: <20150125184914.GP81001@ivaldir.etoilebsd.net> References: <20150124143357.GI81001@ivaldir.etoilebsd.net> <20150125143243.GB76051@zxy.spb.ru> <7B1D8345-248B-4C44-9568-079BA29614C2@ixsystems.com> <23506.1422204612@critter.freebsd.dk> <20150125171042.GQ3698@zxy.spb.ru> <23185.1422208170@chaos> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AwNVUpjOmSj7UnwZ" Content-Disposition: inline In-Reply-To: <23185.1422208170@chaos> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: arch@freebsd.org, Poul-Henning Kamp , Jordan Hubbard , Slawa Olhovchenkov X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2015 18:49:20 -0000 --AwNVUpjOmSj7UnwZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 25, 2015 at 09:49:30AM -0800, Simon J. Gerraty wrote: > Slawa Olhovchenkov wrote: > > System software (from FreeBSD base) not exclusive for this behaviour > > (dangerous dependens from current locale). This is may be third-party > > sofware or software writen by customer. Unexpected setting locale to > > UTF-8 may be broken this software. >=20 > Yes, svn client fails on checkout if file contains UTF-8 and client's > local is not compatible, error is to the effect of "cannot translate". > Only fix is to change loacle to UTF-8 then remove the offending chars if > possible.=20 >=20 > UTF-8 is a bit like GPL - forces everyone to follow suit. I can checkout FreeBSD's sources which contains UTF-8 files on a vanilla freebsd aka locale being 'C'. Bapt --AwNVUpjOmSj7UnwZ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlTFOqoACgkQ8kTtMUmk6EyDmQCgvex0XNVi25DXYd1xoxXNPUuB ASkAn1jI1HF39s+e2bStMlxMU2YJ/GE6 =yeL/ -----END PGP SIGNATURE----- --AwNVUpjOmSj7UnwZ-- From owner-freebsd-arch@FreeBSD.ORG Sun Jan 25 18:54:40 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 660E57AF for ; Sun, 25 Jan 2015 18:54:40 +0000 (UTC) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E689796C for ; Sun, 25 Jan 2015 18:54:39 +0000 (UTC) Received: by mail-wi0-f180.google.com with SMTP id h11so5992500wiw.1 for ; Sun, 25 Jan 2015 10:54:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=atDxgeIF9gcni3PXN5tG4wXpdqWjfEqsfAIQo2plITA=; b=yOD64WCmNTpRb8DPRX3rJrzoEEkoUIhnU4SDke6JwmG8tudt7AZYZiTc3bKIdn7rTb bQTwXHi76aj4BQFLbtYFJpAo0sVFdDyoAlIshcrIpenUtLmWXiObwyHm6oVOzWV6LUHh Ylm9PDRwMz+Xttn5UE5jzcy42i8tOicRMohMVB+PdIw9DGmpyFeHJff/3Qmp+RIKyL/l sz2Pao6Bej0hYzVt/m0ls74ZRoD9KjumJIMEqbqnmCd+b0QwXGHTjah56BM26aC6lHp9 wDWiPW1ckZ5d1b7TVvv7/EYcxrMBjwgotiLFKzaS/ofEUPyQgSWc1mHwPQH/WfSPgmBL Lb7w== X-Received: by 10.180.107.195 with SMTP id he3mr25295580wib.44.1422212078424; Sun, 25 Jan 2015 10:54:38 -0800 (PST) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id hz9sm11189544wjb.17.2015.01.25.10.54.37 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 25 Jan 2015 10:54:37 -0800 (PST) Sender: Baptiste Daroussin Date: Sun, 25 Jan 2015 19:54:35 +0100 From: Baptiste Daroussin To: Poul-Henning Kamp Subject: Re: [RFC] Set the default locale to en_US.UTF-8 Message-ID: <20150125185434.GQ81001@ivaldir.etoilebsd.net> References: <20150124143357.GI81001@ivaldir.etoilebsd.net> <20150125143243.GB76051@zxy.spb.ru> <7B1D8345-248B-4C44-9568-079BA29614C2@ixsystems.com> <23506.1422204612@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7a4X6VOqfbl9xMrG" Content-Disposition: inline In-Reply-To: <23506.1422204612@critter.freebsd.dk> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: arch@FreeBSD.org, Jordan Hubbard , Slawa Olhovchenkov X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2015 18:54:40 -0000 --7a4X6VOqfbl9xMrG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 25, 2015 at 04:50:12PM +0000, Poul-Henning Kamp wrote: > -------- > In message <7B1D8345-248B-4C44-9568-079BA29614C2@ixsystems.com>, Jordan H= ubbard > writes: >=20 > The point about vi(1) is that if you happen to open an ISO-8859 file > while in UTF-8 mode, change something on the first line, it will > happily and almost imperceptively truncate your file at the first > non-UTF byte sequence. >=20 > Needless to say, that is *not* the expected behaviour. Right I misunderstood your mail first, rereading this is true. So for sure = this needs to be fixed before switching the locale. Bapt --7a4X6VOqfbl9xMrG Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlTFO+oACgkQ8kTtMUmk6EzqmACfSPgg1KPqhm9Cs6Lh5P6M5DCB SXMAnilKU9DrUHDNpAqPpIOSkIiUfHqY =nMU+ -----END PGP SIGNATURE----- --7a4X6VOqfbl9xMrG-- From owner-freebsd-arch@FreeBSD.ORG Sun Jan 25 19:00:11 2015 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A6F7B957; Sun, 25 Jan 2015 19:00:11 +0000 (UTC) Received: from vps.rulingia.com (vps.rulingia.com [103.243.244.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps.rulingia.com", Issuer "CAcert Class 3 Root" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6615A9E1; Sun, 25 Jan 2015 19:00:10 +0000 (UTC) Received: from server.rulingia.com (c220-239-242-83.belrs5.nsw.optusnet.com.au [220.239.242.83]) by vps.rulingia.com (8.14.9/8.14.9) with ESMTP id t0PIxxdS052107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 26 Jan 2015 06:00:05 +1100 (AEDT) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.9/8.14.9) with ESMTP id t0PIxqaD011075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 26 Jan 2015 05:59:52 +1100 (AEDT) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.9/8.14.9/Submit) id t0PIxpio011074; Mon, 26 Jan 2015 05:59:51 +1100 (AEDT) (envelope-from peter) Date: Mon, 26 Jan 2015 05:59:51 +1100 From: Peter Jeremy To: Slawa Olhovchenkov Subject: Re: [RFC] Set the default locale to en_US.UTF-8 Message-ID: <20150125185951.GC23253@server.rulingia.com> References: <20150124143357.GI81001@ivaldir.etoilebsd.net> <20150125143243.GB76051@zxy.spb.ru> <7B1D8345-248B-4C44-9568-079BA29614C2@ixsystems.com> <20150125155000.GD76051@zxy.spb.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="z4+8/lEcDcG5Ke9S" Content-Disposition: inline In-Reply-To: <20150125155000.GD76051@zxy.spb.ru> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.23 (2014-03-12) Cc: arch@FreeBSD.org, Baptiste Daroussin , Jordan Hubbard X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2015 19:00:11 -0000 --z4+8/lEcDcG5Ke9S Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2015-Jan-25 18:50:00 +0300, Slawa Olhovchenkov wrote: >On Sun, Jan 25, 2015 at 06:58:13AM -0800, Jordan Hubbard wrote: >> > On Jan 25, 2015, at 6:32 AM, Slawa Olhovchenkov wrote: >> >=20 >> > NO! Please, NOT! >> > Not all bytestring allowed in UTF-8, as result -- unpedicable failed >> > execution of sed, grep, vi, ed and etc. I switched to en_AU.UTF-8 about 5 years ago with relatively little pain (though I had very little non-ASCII text). The downside of UTF-8 in that random non-ASCII bytestrings are unlikely to be valid UTF-8 and will therefore get rejected. About the only time I get bitten by this is that my random password generator: dd if=3D/dev/random bs=3D32 count=3D1 | tr -cd '!-~' will die with an "tr: Illegal byte sequence" and needs a "LC_ALL=3DC" to placate it. At least with emacs (and I think vi), you can override the default locale on a file-by-file basis - and emacs is very good at coping with non-UTF-8 files in a UTF-8 locale, as well as translating between locales. >> It's a good idea to change it. We have outgrown ISO-Latin1, and UTF-8 s= olves a host of ugly I18N interoperability problems when used consistently. Agreed. IMHO, this is long overdue. >I am years use ru_RU.KOI8-R. Now I try use ru_RU.UTF8 and got some >issuse (on 10-STABLE). 9.x and OS may have dufferent version of >software and don't touch this. Once you've started using any 8-bit locale, switching to UTF-8 (or any other 8-bit locale) will be a PITA because you need to re-encode everything. And, since it's very difficult to run with multiple locales, you need to do a complete sweep when you change locales. If you are running into specific issues with incorrect handling of ru_RU.UTF8, that is a bug and you need to report it. Note that we're talking about changing the default - you already override the default so it won't affect you. >This is (change from one-byte tu multi-bytes locale) may be do >individualy, after inspecting systems. This is may be OK for new >install, but not [automatic] for update/upgrade. Either an existing system has already overridden the default locale, so changing the default will have no impact, or the treatment of non-ASCII data is currently undefined so changing the default is changing undefined behaviour to explicitly warning the the user that they have problems with their data. --=20 Peter Jeremy --z4+8/lEcDcG5Ke9S Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJUxT0nXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFRUIyOTg2QzMwNjcxRTc0RTY1QzIyN0Ux NkE1OTdBMEU0QTIwQjM0AAoJEBall6Dkogs0gV4P/2usHL4uwjoIvhELGQkT5ZcV +tuSvoQDlhWKUz6/3ThnBlGsHTZ5vCBTqWLtJ2twsC9C8u3EQBjN4YaFbT8NQ8aa AilFc/MH5/Lu7D9hDh6mv8PxOx9/P4cC3uH6GVElzLgYfQXSWYx3vuw1MH90b1QS JHF+a/PJCUCDaAtqLv2lejHBLqKSNJdchMbhiLH0XVrurWRLxb1uSaMAKTbNcp6v XIQqhP6uENJhc/pHEK7yOwpAsuv/MdLGa1sUhIrbFow8yYeR7bA58/VpA/V6nVi1 NU0g8WL4VQJr/dt7xOqjWZ2kdl5ML7qj/8VpoxEjSCmkO4IRa05mAZhiD74RSsF9 pOGxqyahhWhBRhrSu6EU1JPS3aMwGFuQybBPVfYRn3mpqigMRDKE/5yP0y3qa5t/ AinsLLzm9+Ti6Ht0lsDYkx/Ys1J8tRZQiwY6EJe9PM+qR1P1ry2VOfl/+jT+SHIB uGxNSFrNeI11EX62AUvx5oh7fTU5cMmOpJP+xvO2IHduzkegEt526K4g9yzRB2zR hfa0sTHgj06V5PIq1q1x7rMwpDzhEqdEfhtKsyXfkpwiYeuisJYfqUaoLMLtpvNE zo7UGLmF1LKydHBQAaYQBEwpqWbjoBQSVUTUORBdcaeXnrccvx1EXnIQ8ShF0HDj DQvTf8YfLONDZRFw1/cy =mtMF -----END PGP SIGNATURE----- --z4+8/lEcDcG5Ke9S-- From owner-freebsd-arch@FreeBSD.ORG Sun Jan 25 19:06:17 2015 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 94049A88; Sun, 25 Jan 2015 19:06:17 +0000 (UTC) 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 5005FAAE; Sun, 25 Jan 2015 19:06:17 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1YFSVg-000Ofg-TV; Sun, 25 Jan 2015 22:06:12 +0300 Date: Sun, 25 Jan 2015 22:06:12 +0300 From: Slawa Olhovchenkov To: Baptiste Daroussin Subject: Re: [RFC] Set the default locale to en_US.UTF-8 Message-ID: <20150125190612.GR3698@zxy.spb.ru> References: <20150124143357.GI81001@ivaldir.etoilebsd.net> <20150125143243.GB76051@zxy.spb.ru> <7B1D8345-248B-4C44-9568-079BA29614C2@ixsystems.com> <23506.1422204612@critter.freebsd.dk> <20150125184608.GO81001@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150125184608.GO81001@ivaldir.etoilebsd.net> User-Agent: Mutt/1.5.23 (2014-03-12) 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 Cc: arch@FreeBSD.org, Poul-Henning Kamp , Jordan Hubbard X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2015 19:06:17 -0000 On Sun, Jan 25, 2015 at 07:46:08PM +0100, Baptiste Daroussin wrote: > On Sun, Jan 25, 2015 at 04:50:12PM +0000, Poul-Henning Kamp wrote: > > -------- > > In message <7B1D8345-248B-4C44-9568-079BA29614C2@ixsystems.com>, Jordan Hubbard > > writes: > > > > The point about vi(1) is that if you happen to open an ISO-8859 file > > while in UTF-8 mode, change something on the first line, it will > > happily and almost imperceptively truncate your file at the first > > non-UTF byte sequence. > > > > Needless to say, that is *not* the expected behaviour. > > > > That was the case with old vi not with the vi we have in head at least I'm not > able to truncate files with actual vi This is vi from 10. vi from 9 just ignore utf-8 setting and don't truncate files. From owner-freebsd-arch@FreeBSD.ORG Sun Jan 25 19:17:40 2015 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1C9F5D74; Sun, 25 Jan 2015 19:17:40 +0000 (UTC) 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 CBF29BC6; Sun, 25 Jan 2015 19:17:39 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1YFSgf-000Ov8-6V; Sun, 25 Jan 2015 22:17:33 +0300 Date: Sun, 25 Jan 2015 22:17:33 +0300 From: Slawa Olhovchenkov To: Peter Jeremy Subject: Re: [RFC] Set the default locale to en_US.UTF-8 Message-ID: <20150125191733.GS3698@zxy.spb.ru> References: <20150124143357.GI81001@ivaldir.etoilebsd.net> <20150125143243.GB76051@zxy.spb.ru> <7B1D8345-248B-4C44-9568-079BA29614C2@ixsystems.com> <20150125155000.GD76051@zxy.spb.ru> <20150125185951.GC23253@server.rulingia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150125185951.GC23253@server.rulingia.com> User-Agent: Mutt/1.5.23 (2014-03-12) 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 Cc: arch@FreeBSD.org, Baptiste Daroussin , Jordan Hubbard X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2015 19:17:40 -0000 On Mon, Jan 26, 2015 at 05:59:51AM +1100, Peter Jeremy wrote: > On 2015-Jan-25 18:50:00 +0300, Slawa Olhovchenkov wrote: > >On Sun, Jan 25, 2015 at 06:58:13AM -0800, Jordan Hubbard wrote: > >> > On Jan 25, 2015, at 6:32 AM, Slawa Olhovchenkov wrote: > >> > > >> > NO! Please, NOT! > >> > Not all bytestring allowed in UTF-8, as result -- unpedicable failed > >> > execution of sed, grep, vi, ed and etc. > > I switched to en_AU.UTF-8 about 5 years ago with relatively little pain > (though I had very little non-ASCII text). > > The downside of UTF-8 in that random non-ASCII bytestrings are unlikely to > be valid UTF-8 and will therefore get rejected. About the only time I get > bitten by this is that my random password generator: > dd if=/dev/random bs=32 count=1 | tr -cd '!-~' > will die with an "tr: Illegal byte sequence" and needs a "LC_ALL=C" to > placate it. Yes, I now remeber -- other case will be tr. > >I am years use ru_RU.KOI8-R. Now I try use ru_RU.UTF8 and got some > >issuse (on 10-STABLE). 9.x and OS may have dufferent version of > >software and don't touch this. > > Once you've started using any 8-bit locale, switching to UTF-8 (or any > other 8-bit locale) will be a PITA because you need to re-encode everything. > And, since it's very difficult to run with multiple locales, you need to > do a complete sweep when you change locales. If you are running into > specific issues with incorrect handling of ru_RU.UTF8, that is a bug and > you need to report it. No, I don't have incorrect handling of ru_RU.UTF8 (for correct UTF8 files), I have trouble with processing non-utf files (like example with tr) > Note that we're talking about changing the default - you already override > the default so it won't affect you. This is dangerous change -- you can lost data, incorrectly proccess previosly correctly processed files (script with tr and etc.). And this may be surprised for you. > >This is (change from one-byte tu multi-bytes locale) may be do > >individualy, after inspecting systems. This is may be OK for new > >install, but not [automatic] for update/upgrade. > > Either an existing system has already overridden the default locale, so > changing the default will have no impact, or the treatment of non-ASCII > data is currently undefined so changing the default is changing undefined > behaviour to explicitly warning the the user that they have problems with > their data. Currently defaul locale is C. This locale accept any byte string. UTF8 locale may be more strict. This is may be break existing systems. From owner-freebsd-arch@FreeBSD.ORG Sun Jan 25 19:21:49 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 75DE3121 for ; Sun, 25 Jan 2015 19:21:49 +0000 (UTC) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1237FC7E for ; Sun, 25 Jan 2015 19:21:49 +0000 (UTC) Received: by mail-we0-f176.google.com with SMTP id w62so5755938wes.7 for ; Sun, 25 Jan 2015 11:21:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=Npl4warEXx4ViYUM56PEND/FNmDM55BEpcklcwyUU14=; b=OPnxv22A6UmrU4f3qCfaUT4NJSs3Up0cPi/OX3alD4hDHHzibt24py0G0FjfMPC54l ELGTSEKLZ3QLau7SYF68joWCZK4UPbaET1puMvfSMkFydHz1gViMhL1r97fypFjCFiFb WX0P9qy5uUWT+/O4aQTPpRuiibwOjBetaFwU5w5zxw/HjlmsMwc9IdKAc4wD+hmRZh7N xDWjXA+f/eJHv4BW9WM2E0IYhJsoTOnSBVHr12VpITZMsxOhGrWA+0X6r3E6IkzXPh1I Du4Yg6s3ITce4MMgE3/RAOSuddiEZT2R3Sm02WdaqymqPn55XkR+uEqZQHx+Ck63Pu3U M0FQ== X-Received: by 10.194.175.202 with SMTP id cc10mr37415476wjc.27.1422213707111; Sun, 25 Jan 2015 11:21:47 -0800 (PST) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id bb2sm11243502wjc.43.2015.01.25.11.21.45 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 25 Jan 2015 11:21:45 -0800 (PST) Sender: Baptiste Daroussin Date: Sun, 25 Jan 2015 20:21:43 +0100 From: Baptiste Daroussin To: Slawa Olhovchenkov Subject: Re: [RFC] Set the default locale to en_US.UTF-8 Message-ID: <20150125192143.GR81001@ivaldir.etoilebsd.net> References: <20150124143357.GI81001@ivaldir.etoilebsd.net> <20150125143243.GB76051@zxy.spb.ru> <7B1D8345-248B-4C44-9568-079BA29614C2@ixsystems.com> <20150125155000.GD76051@zxy.spb.ru> <20150125185951.GC23253@server.rulingia.com> <20150125191733.GS3698@zxy.spb.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="aH/0uqREc1VzwMkO" Content-Disposition: inline In-Reply-To: <20150125191733.GS3698@zxy.spb.ru> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: arch@FreeBSD.org, Jordan Hubbard X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2015 19:21:49 -0000 --aH/0uqREc1VzwMkO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 25, 2015 at 10:17:33PM +0300, Slawa Olhovchenkov wrote: > On Mon, Jan 26, 2015 at 05:59:51AM +1100, Peter Jeremy wrote: >=20 > > On 2015-Jan-25 18:50:00 +0300, Slawa Olhovchenkov wrot= e: > > >On Sun, Jan 25, 2015 at 06:58:13AM -0800, Jordan Hubbard wrote: > > >> > On Jan 25, 2015, at 6:32 AM, Slawa Olhovchenkov w= rote: > > >> >=20 > > >> > NO! Please, NOT! > > >> > Not all bytestring allowed in UTF-8, as result -- unpedicable fail= ed > > >> > execution of sed, grep, vi, ed and etc. > >=20 > > I switched to en_AU.UTF-8 about 5 years ago with relatively little pain > > (though I had very little non-ASCII text). > >=20 > > The downside of UTF-8 in that random non-ASCII bytestrings are unlikely= to > > be valid UTF-8 and will therefore get rejected. About the only time I = get > > bitten by this is that my random password generator: > > dd if=3D/dev/random bs=3D32 count=3D1 | tr -cd '!-~' > > will die with an "tr: Illegal byte sequence" and needs a "LC_ALL=3DC" to > > placate it. >=20 > Yes, I now remeber -- other case will be tr. >=20 > > >I am years use ru_RU.KOI8-R. Now I try use ru_RU.UTF8 and got some > > >issuse (on 10-STABLE). 9.x and OS may have dufferent version of > > >software and don't touch this. > >=20 > > Once you've started using any 8-bit locale, switching to UTF-8 (or any > > other 8-bit locale) will be a PITA because you need to re-encode everyt= hing. > > And, since it's very difficult to run with multiple locales, you need to > > do a complete sweep when you change locales. If you are running into > > specific issues with incorrect handling of ru_RU.UTF8, that is a bug and > > you need to report it. >=20 > No, I don't have incorrect handling of ru_RU.UTF8 (for correct UTF8 > files), I have trouble with processing non-utf files (like example > with tr) That is why on my proposal also set LC_COLLATE=3DC which fixed the tr case = for example Bapt --aH/0uqREc1VzwMkO Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlTFQkcACgkQ8kTtMUmk6EyACACfYTfoqsPveXf5HTMufTrcKn+A tQsAmgLq+aCEuBC99fIIj+2/aryBITrZ =ymg1 -----END PGP SIGNATURE----- --aH/0uqREc1VzwMkO-- From owner-freebsd-arch@FreeBSD.ORG Sun Jan 25 19:38:44 2015 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 729CA4F9; Sun, 25 Jan 2015 19:38:44 +0000 (UTC) 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 29742DE2; Sun, 25 Jan 2015 19:38:44 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1YFT16-000PKM-1u; Sun, 25 Jan 2015 22:38:40 +0300 Date: Sun, 25 Jan 2015 22:38:39 +0300 From: Slawa Olhovchenkov To: Baptiste Daroussin Subject: Re: [RFC] Set the default locale to en_US.UTF-8 Message-ID: <20150125193839.GU3698@zxy.spb.ru> References: <20150124143357.GI81001@ivaldir.etoilebsd.net> <20150125143243.GB76051@zxy.spb.ru> <7B1D8345-248B-4C44-9568-079BA29614C2@ixsystems.com> <20150125155000.GD76051@zxy.spb.ru> <20150125185951.GC23253@server.rulingia.com> <20150125191733.GS3698@zxy.spb.ru> <20150125192143.GR81001@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150125192143.GR81001@ivaldir.etoilebsd.net> User-Agent: Mutt/1.5.23 (2014-03-12) 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 Cc: arch@FreeBSD.org, Jordan Hubbard X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2015 19:38:44 -0000 On Sun, Jan 25, 2015 at 08:21:43PM +0100, Baptiste Daroussin wrote: > On Sun, Jan 25, 2015 at 10:17:33PM +0300, Slawa Olhovchenkov wrote: > > On Mon, Jan 26, 2015 at 05:59:51AM +1100, Peter Jeremy wrote: > > > > > On 2015-Jan-25 18:50:00 +0300, Slawa Olhovchenkov wrote: > > > >On Sun, Jan 25, 2015 at 06:58:13AM -0800, Jordan Hubbard wrote: > > > >> > On Jan 25, 2015, at 6:32 AM, Slawa Olhovchenkov wrote: > > > >> > > > > >> > NO! Please, NOT! > > > >> > Not all bytestring allowed in UTF-8, as result -- unpedicable failed > > > >> > execution of sed, grep, vi, ed and etc. > > > > > > I switched to en_AU.UTF-8 about 5 years ago with relatively little pain > > > (though I had very little non-ASCII text). > > > > > > The downside of UTF-8 in that random non-ASCII bytestrings are unlikely to > > > be valid UTF-8 and will therefore get rejected. About the only time I get > > > bitten by this is that my random password generator: > > > dd if=/dev/random bs=32 count=1 | tr -cd '!-~' > > > will die with an "tr: Illegal byte sequence" and needs a "LC_ALL=C" to > > > placate it. > > > > Yes, I now remeber -- other case will be tr. > > > > > >I am years use ru_RU.KOI8-R. Now I try use ru_RU.UTF8 and got some > > > >issuse (on 10-STABLE). 9.x and OS may have dufferent version of > > > >software and don't touch this. > > > > > > Once you've started using any 8-bit locale, switching to UTF-8 (or any > > > other 8-bit locale) will be a PITA because you need to re-encode everything. > > > And, since it's very difficult to run with multiple locales, you need to > > > do a complete sweep when you change locales. If you are running into > > > specific issues with incorrect handling of ru_RU.UTF8, that is a bug and > > > you need to report it. > > > > No, I don't have incorrect handling of ru_RU.UTF8 (for correct UTF8 > > files), I have trouble with processing non-utf files (like example > > with tr) > > That is why on my proposal also set LC_COLLATE=C which fixed the tr case for > example How customer can prdeict this? Before this all work fine. After locale change somethink can be broken. I am don't predict 'tr' failure. What broken next? What broken in third-party? On already installed system, of couse. Running in prodution many years. From owner-freebsd-arch@FreeBSD.ORG Sun Jan 25 22:58:25 2015 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 487E7B6E; Sun, 25 Jan 2015 22:58:25 +0000 (UTC) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 0663A289; Sun, 25 Jan 2015 22:58:24 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.60.3]) by phk.freebsd.dk (Postfix) with ESMTP id 0432F3B8B7; Sun, 25 Jan 2015 22:58:21 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.9/8.14.9) with ESMTP id t0PMwKWe024714; Sun, 25 Jan 2015 22:58:20 GMT (envelope-from phk@phk.freebsd.dk) To: Baptiste Daroussin Subject: Re: [RFC] Set the default locale to en_US.UTF-8 In-reply-to: <20150125184608.GO81001@ivaldir.etoilebsd.net> From: "Poul-Henning Kamp" References: <20150124143357.GI81001@ivaldir.etoilebsd.net> <20150125143243.GB76051@zxy.spb.ru> <7B1D8345-248B-4C44-9568-079BA29614C2@ixsystems.com> <23506.1422204612@critter.freebsd.dk> <20150125184608.GO81001@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <24712.1422226700.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Sun, 25 Jan 2015 22:58:20 +0000 Message-ID: <24713.1422226700@critter.freebsd.dk> Cc: arch@FreeBSD.org, Jordan Hubbard , Slawa Olhovchenkov X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2015 22:58:25 -0000 -------- In message <20150125184608.GO81001@ivaldir.etoilebsd.net>, Baptiste Darous= sin w rites: >> The point about vi(1) is that if you happen to open an ISO-8859 file >> while in UTF-8 mode, change something on the first line, it will >> happily and almost imperceptively truncate your file at the first >> non-UTF byte sequence. >> = >> Needless to say, that is *not* the expected behaviour. > >That was the case with old vi not with the vi we have in head at least I'= m = >not able to truncate files with actual vi critter phk> env | grep -i utf XTERM_LOCALE=3Den_US.UTF-8 LC_CTYPE=3Den_US.UTF-8 critter phk> uname -a FreeBSD critter.freebsd.dk 11.0-CURRENT FreeBSD 11.0-CURRENT #12 r275575: = Sun Dec 7 11:08:11 UTC 2014 root@critter.freebsd.dk:/freebsd/obj/free= bsd/svn_src/head/sys/GENERIC amd64 critter phk> ascii > /tmp/_ critter phk> ls -l /tmp/_ -rw-rw-r-- 1 phk wheel 882 Jan 25 22:54 /tmp/_ critter phk> vi /tmp/_ (Shows first two lines) :w! :q critter phk> ls -l /tmp/_ -rw-rw-r-- 1 phk wheel 98 Jan 25 22:56 /tmp/_ The sourcecode for the ascii programs is: #include int main(int argc __unused, char **argv __unused) { int x, y, z; for (x =3D 0 ; x < 16; x++) printf("%02x ", x * 16); printf("\n"); for (x =3D 0 ; x < 16; x++) printf("---"); printf("\n"); for (y =3D 0; y < 16; y++) { for (x =3D 0 ; x < 16; x++) { z =3D y + x * 16; if ((x & 7) >=3D 2 && z !=3D 0x7f) printf("%c ", z); else printf("%02x ", z); } putchar('\n'); } } -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From owner-freebsd-arch@FreeBSD.ORG Tue Jan 27 05:59:34 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 14EDDE78 for ; Tue, 27 Jan 2015 05:59:34 +0000 (UTC) Received: from mail-out.m-online.net (mail-out.m-online.net [IPv6:2001:a60:0:28:0:1:25:1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C3B93142 for ; Tue, 27 Jan 2015 05:59:33 +0000 (UTC) Received: from frontend01.mail.m-online.net (unknown [192.168.8.182]) by mail-out.m-online.net (Postfix) with ESMTP id 3kWchz0Zhzz3hjRl; Tue, 27 Jan 2015 06:59:30 +0100 (CET) Received: from mail.embedded-brains.de (host-82-135-62-35.customer.m-online.net [82.135.62.35]) by mail.mnet-online.de (Postfix) with ESMTP id 3kWchy46rBzvh2H; Tue, 27 Jan 2015 06:59:30 +0100 (CET) Received: by mail.embedded-brains.de (Postfix, from userid 65534) id 9E263652CFD; Tue, 27 Jan 2015 06:59:28 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on fidibusdmz X-Spam-Level: X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 Received: from [192.168.100.11] (unknown [192.168.100.11]) by mail.embedded-brains.de (Postfix) with ESMTP id 1D90A65253A; Tue, 27 Jan 2015 06:59:16 +0100 (CET) Message-ID: <54C72933.9020409@embedded-brains.de> Date: Tue, 27 Jan 2015 06:59:15 +0100 From: Sebastian Huber User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: [PATCH v2] sys/tree.h: Add prototype and generate macros References: <1422022288-17630-1-git-send-email-sebastian.huber@embedded-brains.de> <20150124124356.GT42409@kib.kiev.ua> In-Reply-To: <20150124124356.GT42409@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 05:59:34 -0000 On 24/01/15 13:43, Konstantin Belousov wrote: > On Fri, Jan 23, 2015 at 03:11:28PM +0100, Sebastian Huber wrote: >> Provide individual prototype and generate macros for the red-black tree. >> This helps to reduce code size in statically linked applications. > Committed as r277642. Thank you. Thanks, is this somehow automatically synchronized with other BSD variants or do I have to submit the patch for each project? -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.huber@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. From owner-freebsd-arch@FreeBSD.ORG Tue Jan 27 06:23:15 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 70BED5E7 for ; Tue, 27 Jan 2015 06:23:15 +0000 (UTC) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3D4A85E9 for ; Tue, 27 Jan 2015 06:23:15 +0000 (UTC) Received: by mail-pa0-f41.google.com with SMTP id kq14so16515813pab.0 for ; Mon, 26 Jan 2015 22:23:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=7p+nrQAcSnLn6OvE25YyvMvwwZ7MgCihTrWo32W8k8k=; b=ZpM941yuY7TIjSWw26N4x74pGYM3D5wxD+b6IY5oBZbSL8bm+WY/ARrO/WvSlkwaBn 1PJZtnVTa3KNs50JjHFt64bSQ2wHj7/+npL4l93jFk5Hi1yf/yD7a4LhyTqlAvfdYxby XosuqeobdzLf3F6oLz9Xj2Bn+oCFl6l7aznQJ+jaqTOX7+rlTev7W3fGFiTMVJvW19uV pZQrDYfB3a8MO9wyCsdg3ZdLVOdTzluKnD/09GROQ0nGaxUwnxkysU8L+rJBwHyVzHCL Yvq6tWmnq1G4FIGJl5JfjFmzvIlPYrthZFwurb/rbUr/VJC6gbfBh+dQaWWdsbA5gSc6 qWbg== X-Received: by 10.68.100.33 with SMTP id ev1mr40329061pbb.77.1422339794782; Mon, 26 Jan 2015 22:23:14 -0800 (PST) Received: from ?IPv6:2601:8:ab80:7d6:bc82:b31b:4ccc:789f? ([2601:8:ab80:7d6:bc82:b31b:4ccc:789f]) by mx.google.com with ESMTPSA id ug6sm440946pab.7.2015.01.26.22.23.13 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 26 Jan 2015 22:23:14 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_FA00146C-81B7-4600-A6DA-609932D45AAB"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [PATCH v2] sys/tree.h: Add prototype and generate macros From: Garrett Cooper In-Reply-To: <54C72933.9020409@embedded-brains.de> Date: Mon, 26 Jan 2015 22:23:13 -0800 Message-Id: <992709EC-5A85-4186-AB04-53D9C7B23180@gmail.com> References: <1422022288-17630-1-git-send-email-sebastian.huber@embedded-brains.de> <20150124124356.GT42409@kib.kiev.ua> <54C72933.9020409@embedded-brains.de> To: Sebastian Huber X-Mailer: Apple Mail (2.1878.6) Cc: Konstantin Belousov , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 06:23:15 -0000 --Apple-Mail=_FA00146C-81B7-4600-A6DA-609932D45AAB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jan 26, 2015, at 21:59, Sebastian Huber = wrote: > On 24/01/15 13:43, Konstantin Belousov wrote: >> On Fri, Jan 23, 2015 at 03:11:28PM +0100, Sebastian Huber wrote: >>> Provide individual prototype and generate macros for the red-black = tree. >>> This helps to reduce code size in statically linked applications. >> Committed as r277642. Thank you. >=20 > Thanks, is this somehow automatically synchronized with other BSD = variants or do I have to submit the patch for each project? You=92ll have to submit a patch with the other projects. Thank you for = the submission BTW! --Apple-Mail=_FA00146C-81B7-4600-A6DA-609932D45AAB 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 iQEcBAEBCgAGBQJUxy7RAAoJEMZr5QU6S73ePnsH/2QCgbnpeN7b0aJxvb0BFVuG Y486IOtG9ZBobbOi5amvQyOjU4vYnNt4v7VynLe5nreKpAlos6IvaGvPfleXsQa0 w9DeG3WqwNYp1PDBWIqC+sT45kyKvNH4/DX4P799FY9z9Dbk0BPKFMFBG4bNXq+M h5EUPPdwVG6bBGl2WEOWJ8+zW8Rpxmzr6ZWMBep73k4JRAS7VadXLhF7mU/gHIo2 febbqCLhLWG1QfQ3xr9vj2hpG4dY3HFg6oPKM4OBjZphPICAL5mQq2udvqrZKxM2 wPOxT4ZsbQsjT8zWtlZYghfcKTvS5zusRYLTCYxEXPoknpRdfW+/spZfayt0jm8= =aaJl -----END PGP SIGNATURE----- --Apple-Mail=_FA00146C-81B7-4600-A6DA-609932D45AAB-- From owner-freebsd-arch@FreeBSD.ORG Tue Jan 27 21:04:42 2015 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 628AC69E for ; Tue, 27 Jan 2015 21:04:42 +0000 (UTC) Received: from maila-ca.linkedin.com (maila-ca.linkedin.com [108.174.6.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.linkedin.com", Issuer "DigiCert Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 23C89A94 for ; Tue, 27 Jan 2015 21:04:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; s=proddkim1024; t=1422392674; bh=3ulVqcUdyerSmzHj6ojQK9jNPdakT76KC/mEXbS9IaI=; h=From:Subject:MIME-Version:Content-Type:To:Date:X-LinkedIn-Class: X-LinkedIn-Template:X-LinkedIn-fbl; b=fieBC3if4b/VwU7y2Sy5ZdZ4yyuA2sQJ/umDGsDJ42YgNftw2iZNb63k5TJsOKG7C NvH2lP56GY9X0j2Zwn1oZwQuuT8R+6xUNqPlQkJL3XMGKy87LPKUQDkFEHf2Wutctm Rzn0SrNYPDRSbO0ZH3F4pHzE6Rsw+wFr0MixipbI= From: LinkedIn Security Message-ID: <1748019091.10903717.1422392674491.JavaMail.app@lva1-app8991.prod> Subject: Sairam, your password was successfully reset MIME-Version: 1.0 To: Sairam Chengala Date: Tue, 27 Jan 2015 21:04:34 +0000 (UTC) X-LinkedIn-Class: ACCT-ADMIN X-LinkedIn-Template: security_reset_password_notification X-LinkedIn-fbl: s-2nymzewhsrn5s9qoleiprkdpiizoqlh9ibeeirur6llv0searwt14to0 X-LinkedIn-Id: i9hmy-i5frvfnl-4h Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 21:04:42 -0000 Hi Sairam, You've successfully changed your LinkedIn password. Thanks for using LinkedIn! The LinkedIn Team When and where this happened: Date:January 27, 2015 4:04 PM Browser:Chrome Operating System:OS X IP Address:96.240.100.124 Approximate Location:Hoboken, New Jersey, United States Didn't do this? Be sure to change your password right away: https://www.lin= kedin.com/e/v2?e=3Di9hmy-i5frvfnl-4h&a=3Duas-request-password-reset&midToke= n=3DAQFN2Z6JzeYPdA&ek=3Dsecurity_reset_password_notification From owner-freebsd-arch@FreeBSD.ORG Wed Jan 28 22:46:03 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BEF6428A for ; Wed, 28 Jan 2015 22:46:03 +0000 (UTC) Received: from bigwig.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 7BDB2DEC for ; Wed, 28 Jan 2015 22:46:03 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 694FDB926; Wed, 28 Jan 2015 17:46:01 -0500 (EST) From: John Baldwin To: Warner Losh Subject: Re: devctl(8): A device control utility Date: Wed, 28 Jan 2015 17:45:25 -0500 Message-ID: <17592052.bbsckK6u9F@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-STABLE; KDE/4.14.2; amd64; ; ) In-Reply-To: References: <3200196.9ZgXApgRdA@ralph.baldwin.cx> <54B44448.1090901@FreeBSD.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 28 Jan 2015 17:46:01 -0500 (EST) Cc: Hans Petter Selasky , arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 22:46:03 -0000 On Wednesday, January 14, 2015 04:56:18 PM Warner Losh wrote: > > On Jan 12, 2015, at 3:01 PM, John Baldwin wrote: > >=20 > > On 1/12/15 12:01 PM, Warner Losh wrote: > >>> On Jan 12, 2015, at 9:16 AM, John Baldwin wrote= : > >>>=20 > >>> On 1/5/15 4:18 PM, John Baldwin wrote: > >>>> On Monday, January 05, 2015 09:58:19 PM Hans Petter Selasky wrot= e: > >>>>> On 01/05/15 21:37, John Baldwin wrote: > >>>>>> On 1/5/15 3:13 PM, Hans Petter Selasky wrote: > >>>>>>> On 01/05/15 21:01, John Baldwin wrote: > >>>>>>>> The devctl(8) utility is then a thin wrapper around libdevct= l (and > >>>>>>>> does not > >>>>>>>> yet have a manpage). > >>>>>>>>=20 > >>>>>>>> Do folks have any feedback? > >>>>>>>=20 > >>>>>>> Hi, > >>>>>>>=20 > >>>>>>> In the USB area attach and detach must be synchronized to the= USB > >>>>>>> stack > >>>>>>> and "usbconfig -d X.Y set_config Z" or "usbconfig -d X.Y rese= t" > >>>>>>> should > >>>>>>> be used to avoid races attaching and detaching drivers! > >>>>>>=20 > >>>>>> I think this points to one or more missing bus methods so that= the > >>>>>> bus > >>>>>> can hook into device_probe_and_attach() to reset a device as n= eeded. > >>>>>> (e.g. if you had bus_probe_started / bus_probe_finished and po= ssibly > >>>>>> similar methods for attach. PCI could use a bus_attach_finish= ed() > >>>>>> callback so that it could clean up any dangling resources and > >>>>>> possibly > >>>>>> power down on a failed attach the way it does in bus_child_det= ached > >>>>>> as > >>>>>> well). > >>>>>=20 > >>>>> Hi, > >>>>>=20 > >>>>> USB has its own threads to allocate/free devices. Another probl= em is > >>>>> how > >>>>> to atomically get a reference count across multiple layers like= PCI > >>>>> and > >>>>> USB. It doesn't allow probe/attach when called from outside the= se > >>>>> threads. > >>>>=20 > >>>> That just means you need to use some locks. :) Cardbus also use= s an > >>>> event > >>>> thread to handle auto-attach of devices when it detected a card = change > >>>> event, but that doesn't prevent it from servicing an ioctl reque= st. > >>>=20 > >>> Another option btw would be to add bus methods that wrap probe an= d > >>> attach (rather than pre and post event hooks). I wish bus_add_ch= ild() > >>> were done this way such that device_add_child_ordered() were rena= med to > >>> bus_generic_add_child() (and was the default add_child method) an= d that > >>> device_add_child_ordered() called 'BUS_ADD_CHILD()' so that > >>> 'device_add_child()' was the proper public API (instead of exposi= ng > >>> BUS_ADD_CHILD()). Similarly, I think that 'device_attach()' and > >>> 'device_probe_and_attach()' should be the public API and that one= way or > >>> another we should add hooks to allow bus drivers to modify their > >>> behavior if needed. However, they should be fine for devctl ioct= ls to > >>> invoke as well as other kernel bits. > >>=20 > >> When I was doing CardBus and PC Card I wished for similar things. = Then > >> I realized I didn=E2=80=99t need them because as the bus author, I= know when > >> these > >> events happened and could take appropriate actions for the bus. I = didn=E2=80=99t > >> have that atomic access issues though, since as the bus author I a= lso > >> controlled how and when mutexes were taken out and when I allowed = access > >> to the bus. I only used mutexes in CardBus and PC Card because mos= t of > >> the sleeps were short, but other ways to do locking are quite > >> possible... > >=20 > > I think the problem here is that devctl introduces events that happ= en > > without the bus's knowledge. >=20 > When we did the kludge sysctl power stuff for cardbus (which was neve= r > committed), we sent a message to the bus to tell it to do the power o= ff and > cope with whatever else was needed. There were times that it couldn=E2= =80=99t > comply, iirc, so this =E2=80=98command=E2=80=99 allowed errors to be = returned for things > that were forbidden / not allowed for some reason at the time rather = than > getting a message that this thing happened and we had to mop up now. devctl requests would always be ones that you can gracefully fail (they= are administrative requests, not a surprise hardware removal). I think we = should able to make that work just fine either by wrapping device_attach, etc.= in new bus methods, or adding hooks into those as bus methods. To that end, I= 'd like to move forward with this current version in HEAD. At some point we ca= n=20 decide which way we want to allow bus drivers to hook into these reques= ts. I=20 don't think that will affect the API exposed to userland at all however= , only=20 the in-kernel implementation. --=20 John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Jan 28 23:38:54 2015 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4ABBD616 for ; Wed, 28 Jan 2015 23:38:54 +0000 (UTC) Received: from mail.wilcox-tech.com (mail.foxkit.us [192.99.209.192]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.wilcox-tech.com", Issuer "mail.wilcox-tech.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E0ECE3DC for ; Wed, 28 Jan 2015 23:38:52 +0000 (UTC) Received: (qmail 5422 invoked from network); 28 Jan 2015 23:39:59 -0000 Received: from c-71-57-141-247.hsd1.fl.comcast.net (HELO Todd) (AWilcox@Wilcox-Tech.com@71.57.141.247) by mail.foxkit.us with ESMTPA; 28 Jan 2015 23:39:59 -0000 From: "Andrew Wilcox" To: Subject: Current status of utimensat(2) Date: Wed, 28 Jan 2015 17:38:50 -0600 Message-ID: <005701d03b53$92796ce0$b76c46a0$@Wilcox-Tech.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AdA7U487dA/i6+vwQiyY46tJZIbAnw== X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 23:38:54 -0000 Hello, I am wondering about the current status of the utimensat(2) and = futimens(2) patch set. I saw some posts from early 2013 but nothing = more recent. In addition to improving POSIX 2008 compliance, this will = additionally enable me to continue my work on the Linuxulator. As it = stands, most Gentoo and Ubuntu binaries do not work in the Linuxulator = because of the missing utimensat syscall. Is anyone currently working on this? I'd be happy to help out. Thanks, Andrew -- Andrew Wilcox, C/C++/Python developer, kernel hacker Blog: http://blog.foxkit.us/ WWW: http://foxkit.us/ GitHub: https://github.com/awilfox From owner-freebsd-arch@FreeBSD.ORG Wed Jan 28 23:52:33 2015 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:1900:2254:206a::19:2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7AC318F5 for ; Wed, 28 Jan 2015 23:52:33 +0000 (UTC) Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx2.freebsd.org (Postfix) with ESMTP id 386432A5A; Wed, 28 Jan 2015 23:52:33 +0000 (UTC) Message-ID: <54C97640.1080203@FreeBSD.org> Date: Wed, 28 Jan 2015 18:52:32 -0500 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Andrew Wilcox , freebsd-arch@FreeBSD.org Subject: Re: Current status of utimensat(2) References: <005701d03b53$92796ce0$b76c46a0$@Wilcox-Tech.com> In-Reply-To: <005701d03b53$92796ce0$b76c46a0$@Wilcox-Tech.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 23:52:33 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 01/28/2015 18:38, Andrew Wilcox wrote: > Hello, > > I am wondering about the current status of the utimensat(2) and > futimens(2) patch set. I saw some posts from early 2013 but > nothing more recent. In addition to improving POSIX 2008 > compliance, this will additionally enable me to continue my work on > the Linuxulator. As it stands, most Gentoo and Ubuntu binaries do > not work in the Linuxulator because of the missing utimensat > syscall. > > Is anyone currently working on this? I'd be happy to help out. AFAICT, the patch was improved and committed to head: https://svnweb.freebsd.org/changeset/base/277610 Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJUyXZAAAoJEHyflib82/FGUHcH/2QAH1hqLkB6dmbGcQmVR8cm tprNVhqJkmetNYr5YyomtrIRUe1OzqO66cUSgMrsraRhkni8ZhIt40GhjKI16l2G ci6z25+TkigPwGzVaKie9exhduVMFCHOdnFntv841logaUWSgZY5LcrCSl6RZJrG T3kA4s2V45geVRLkRx4tNJM97b4mC4TSOdoB4UYn64BDCHING/o/P6YJwXkRd0Cs QmAQTaLtwHXJLWLmFEsv5OzrUJ8JzqLuPAMnuvRL9b1w9quuh7I6wK64A65sF4uI l1U4Pli1TWk4NINYwoJthOdnfLFDmVdSC5Jn/8y29OchdJ6yOkm3XyDvr0bn2uY= =ksFx -----END PGP SIGNATURE----- From owner-freebsd-arch@FreeBSD.ORG Thu Jan 29 02:05:47 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 14E1D54D for ; Thu, 29 Jan 2015 02:05:47 +0000 (UTC) Received: from mail-oi0-f46.google.com (mail-oi0-f46.google.com [209.85.218.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CEEFD86A for ; Thu, 29 Jan 2015 02:05:46 +0000 (UTC) Received: by mail-oi0-f46.google.com with SMTP id a141so22391425oig.5 for ; Wed, 28 Jan 2015 18:05:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=IWffjGuP27fWIJoEOQuxGMneQNOrzqdl38/+PySjUsE=; b=XbzTGXLEGN2dQFj9sFMuTZwvWkMVZ4VaH4/boYsKVTpyPOuTCQWMg0VPUVhkSi9ei6 PwMo1Ypwhw81IaCtWHGhPyyLhD6OcxMoLy1OThJPPsLEfFjdWkjPe9bcAuRaxs1Vz7T4 I5oq1YhAzLOxVVowt4DqIIT1I9S83rRKSSf1T1uGvuEsEdr0XVdzBxKfdkhy+OvV/+L0 zlG7YXVA/GZ3JsoaeR7rNWpFIFpIPi7jbg+DPe5RnH7K75ix4a/FIZtx5ofOnmfTvb6q dfh9Zu3Cm4g0RJpRMFTtyuuII9kzcF3IMs5fBtvA22s1Z05gmkvj9Zavt034wNzegnsb IjzQ== X-Gm-Message-State: ALoCoQn436wd8t86v/+bwqyNX4HV+GIAtEs13KO1tI7b/fFjjoHurmZ7PPbOF6JKI4ygZCtpwjEw X-Received: by 10.202.219.215 with SMTP id s206mr3833709oig.114.1422496749926; Wed, 28 Jan 2015 17:59:09 -0800 (PST) Received: from [172.16.173.216] ([12.196.110.43]) by mx.google.com with ESMTPSA id d198sm3122050oih.12.2015.01.28.17.59.09 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 28 Jan 2015 17:59:09 -0800 (PST) Sender: Warner Losh Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Subject: Re: devctl(8): A device control utility From: Warner Losh In-Reply-To: <17592052.bbsckK6u9F@ralph.baldwin.cx> Date: Wed, 28 Jan 2015 18:59:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0EB7A69C-8623-49B8-96DC-AB7A84124D8A@bsdimp.com> References: <3200196.9ZgXApgRdA@ralph.baldwin.cx> <54B44448.1090901@FreeBSD.org> <17592052.bbsckK6u9F@ralph.baldwin.cx> To: John Baldwin X-Mailer: Apple Mail (2.1993) Cc: Hans Petter Selasky , arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 02:05:47 -0000 > On Jan 28, 2015, at 3:45 PM, John Baldwin wrote: >=20 > On Wednesday, January 14, 2015 04:56:18 PM Warner Losh wrote: >>> On Jan 12, 2015, at 3:01 PM, John Baldwin wrote: >>>=20 >>> On 1/12/15 12:01 PM, Warner Losh wrote: >>>>> On Jan 12, 2015, at 9:16 AM, John Baldwin wrote: >>>>>=20 >>>>> On 1/5/15 4:18 PM, John Baldwin wrote: >>>>>> On Monday, January 05, 2015 09:58:19 PM Hans Petter Selasky = wrote: >>>>>>> On 01/05/15 21:37, John Baldwin wrote: >>>>>>>> On 1/5/15 3:13 PM, Hans Petter Selasky wrote: >>>>>>>>> On 01/05/15 21:01, John Baldwin wrote: >>>>>>>>>> The devctl(8) utility is then a thin wrapper around libdevctl = (and >>>>>>>>>> does not >>>>>>>>>> yet have a manpage). >>>>>>>>>>=20 >>>>>>>>>> Do folks have any feedback? >>>>>>>>>=20 >>>>>>>>> Hi, >>>>>>>>>=20 >>>>>>>>> In the USB area attach and detach must be synchronized to the = USB >>>>>>>>> stack >>>>>>>>> and "usbconfig -d X.Y set_config Z" or "usbconfig -d X.Y = reset" >>>>>>>>> should >>>>>>>>> be used to avoid races attaching and detaching drivers! >>>>>>>>=20 >>>>>>>> I think this points to one or more missing bus methods so that = the >>>>>>>> bus >>>>>>>> can hook into device_probe_and_attach() to reset a device as = needed. >>>>>>>> (e.g. if you had bus_probe_started / bus_probe_finished and = possibly >>>>>>>> similar methods for attach. PCI could use a = bus_attach_finished() >>>>>>>> callback so that it could clean up any dangling resources and >>>>>>>> possibly >>>>>>>> power down on a failed attach the way it does in = bus_child_detached >>>>>>>> as >>>>>>>> well). >>>>>>>=20 >>>>>>> Hi, >>>>>>>=20 >>>>>>> USB has its own threads to allocate/free devices. Another = problem is >>>>>>> how >>>>>>> to atomically get a reference count across multiple layers like = PCI >>>>>>> and >>>>>>> USB. It doesn't allow probe/attach when called from outside = these >>>>>>> threads. >>>>>>=20 >>>>>> That just means you need to use some locks. :) Cardbus also uses = an >>>>>> event >>>>>> thread to handle auto-attach of devices when it detected a card = change >>>>>> event, but that doesn't prevent it from servicing an ioctl = request. >>>>>=20 >>>>> Another option btw would be to add bus methods that wrap probe and >>>>> attach (rather than pre and post event hooks). I wish = bus_add_child() >>>>> were done this way such that device_add_child_ordered() were = renamed to >>>>> bus_generic_add_child() (and was the default add_child method) and = that >>>>> device_add_child_ordered() called 'BUS_ADD_CHILD()' so that >>>>> 'device_add_child()' was the proper public API (instead of = exposing >>>>> BUS_ADD_CHILD()). Similarly, I think that 'device_attach()' and >>>>> 'device_probe_and_attach()' should be the public API and that one = way or >>>>> another we should add hooks to allow bus drivers to modify their >>>>> behavior if needed. However, they should be fine for devctl = ioctls to >>>>> invoke as well as other kernel bits. >>>>=20 >>>> When I was doing CardBus and PC Card I wished for similar things. = Then >>>> I realized I didn=E2=80=99t need them because as the bus author, I = know when >>>> these >>>> events happened and could take appropriate actions for the bus. I = didn=E2=80=99t >>>> have that atomic access issues though, since as the bus author I = also >>>> controlled how and when mutexes were taken out and when I allowed = access >>>> to the bus. I only used mutexes in CardBus and PC Card because most = of >>>> the sleeps were short, but other ways to do locking are quite >>>> possible... >>>=20 >>> I think the problem here is that devctl introduces events that = happen >>> without the bus's knowledge. >>=20 >> When we did the kludge sysctl power stuff for cardbus (which was = never >> committed), we sent a message to the bus to tell it to do the power = off and >> cope with whatever else was needed. There were times that it = couldn=E2=80=99t >> comply, iirc, so this =E2=80=98command=E2=80=99 allowed errors to be = returned for things >> that were forbidden / not allowed for some reason at the time rather = than >> getting a message that this thing happened and we had to mop up now. >=20 > devctl requests would always be ones that you can gracefully fail = (they are > administrative requests, not a surprise hardware removal). I think we = should > able to make that work just fine either by wrapping device_attach, = etc. in new > bus methods, or adding hooks into those as bus methods. To that end, = I'd like > to move forward with this current version in HEAD. At some point we = can=20 > decide which way we want to allow bus drivers to hook into these = requests. I=20 > don't think that will affect the API exposed to userland at all = however, only=20 > the in-kernel implementation. Yes. The only caveat in that would be if we wanted to have a force flag = passed down that the bus wouldn=E2=80=99t be allowed to reject. But that=E2=80=99= s a minor caveat, so I=E2=80=99m good moving forward with this model. Warner= From owner-freebsd-arch@FreeBSD.ORG Thu Jan 29 20:50:22 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 92E77255 for ; Thu, 29 Jan 2015 20:50:22 +0000 (UTC) Received: from mail54.atl51.rsgsv.net (mail54.atl51.rsgsv.net [205.201.135.54]) (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 106DD7F5 for ; Thu, 29 Jan 2015 20:50:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=k1; d=mail54.atl51.rsgsv.net; h=Subject:From:Reply-To:To:Date:Message-ID:List-ID:List-Unsubscribe:Sender:Content-Type:MIME-Version; i=info=3Dsalvagedrive.com@mail54.atl51.rsgsv.net; bh=N2C6CETrBq+P5bW+e94R6DIKEpY=; b=Bb+/9C7eapivBVljAq5RFtYq68xHp9zyGBRANE41DRqo/xRg2Htv8uN2A4/T+eyCk/FHccJrfGto QTko42INSBr2nB40LJ+QwC2ZXc2G0LGoTr6GyCCRcu+EbrReAm8X0PdCFyFvXpNmPKZLyvQ5jj77 4IfBghEJNtWCN7CcrQI= DomainKey-Signature: a=rsa-sha1; c=nofws; q=dns; s=k1; d=mail54.atl51.rsgsv.net; b=saJjvXlLdAMaOdF4a36rqLC5oTzXspBJuwAE5YEMu/QMsEL7/R26a52uOgy6pjWUnS9CQ7pMUoz4 aXULssPtEX+n7Z9z/xshD5pvc78cGgYeLIQ2RYXxAV6emtKuZTadRhRB3t3tS90RSGhdsFlmYK1O cDx4ehC2/fouQai0aUo=; Received: from (127.0.0.1) by mail54.atl51.rsgsv.net id hpaegs1mr1ol for ; Thu, 29 Jan 2015 20:35:09 +0000 (envelope-from ) Subject: =?utf-8?Q?Cars=20Cars=20Cars?= From: =?utf-8?Q?SalvageDrive.com?= Reply-To: =?utf-8?Q?SalvageDrive.com?= To: =?utf-8?Q??= Date: Thu, 29 Jan 2015 20:35:09 +0000 Message-ID: <38668d8a390eaafe346aac8d5c538f13530.20150129203500@mail54.atl51.rsgsv.net> X-Mailer: MailChimp Mailer - **CIDb20b661509c538f13530** X-Campaign: mailchimp38668d8a390eaafe346aac8d5.b20b661509 X-campaignid: mailchimp38668d8a390eaafe346aac8d5.b20b661509 X-Report-Abuse: Please report abuse for this campaign here: http://www.mailchimp.com/abuse/abuse.phtml?u=38668d8a390eaafe346aac8d5&id=b20b661509&e=c538f13530 X-MC-User: 38668d8a390eaafe346aac8d5 X-Feedback-ID: 30493583:30493583.920321:us8:mc X-Accounttype: pd Sender: "SalvageDrive.com" x-mcda: FALSE MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format="fixed" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 20:50:22 -0000 https://www.salvagedrive.com ** Special Deals from Salvage Drive ------------------------------------------------------------ TOP 5 REASONS TO BUY FROM SALVAGE DRIVE: 1. Free and Easy Registration 2. Best Customer Service in the industry 3. Lowest fees on the market 4. We Ship Worldwide 5. Free Storage for International Shipping NO AUCTION FEE DEALS!!! (https://www.salvagedrive.com) ** 2004 LEXUS RX 330 ------------------------------------------------------------ Clean Title 170=2C451 miles $7=2C400 https://www.salvagedrive.com/Cars/Category?SysId=3D901024315 CLICK FOR MORE INFO (https://www.salvagedrive.com/Cars/Category?SysId=3D90= 1024315) ** 2005 TOYOTA COROLLA ------------------------------------------------------------ Clean Title 131=2C459 miles $3=2C800 https://www.salvagedrive.com/Cars/Category?SysId=3D900002667 CLICK FOR MORE INFO (https://www.salvagedrive.com/Cars/Category?SysId=3D90= 0002667) ** 2005 TOYOTA CAMRY ------------------------------------------------------------ Clean Title 184=2C864 miles $4=2C255 https://www.salvagedrive.com/Cars/Category?SysId=3D901020825 CLICK FOR MORE INFO (https://www.salvagedrive.com/Cars/Category?SysId=3D90= 1020825) ** 2012 Honda Accord ------------------------------------------------------------ Rebuilt Title 25=2C500 miles $9=2C900 https://www.salvagedrive.com/Cars/Category?SysId=3D901024320 CLICK FOR MORE INFO (https://www.salvagedrive.com/Cars/Category?SysId=3D90= 1024320) ** 2005 LEXUS RX 330 ------------------------------------------------------------ Clean Title 98=2C145 miles $8=2C700 https://www.salvagedrive.com/Cars/Category?SysId=3D901024316 CLICK FOR MORE INFO (https://www.salvagedrive.com/Cars/Category?SysId=3D90= 1024316) ** 2006 TOYOTA COROLLA ------------------------------------------------------------ Clean Title 93=2C752 miles $4=2C150 https://www.salvagedrive.com/Cars/Category?SysId=3D900002690 CLICK FOR MORE INFO (https://www.salvagedrive.com/Cars/Category?SysId=3D90= 0002690) ** 2006 TOYOTA CAMRY ------------------------------------------------------------ Clean Title 237=2C267 miles $3=2C795 https://www.salvagedrive.com/Cars/Category?SysId=3D901020293 CLICK FOR MORE INFO (https://www.salvagedrive.com/Cars/Category?SysId=3D90= 1020293) ** 2006 NISSAN MURANO ------------------------------------------------------------ Clean Title 122=2C700 miles $4=2C999 https://www.salvagedrive.com/Cars/Category?SysId=3D901024319 CLICK FOR MORE INFO (https://www.salvagedrive.com/Cars/Category?SysId=3D90= 1024319) ** 2006 LEXUS RX 330 ------------------------------------------------------------ Clean Title 184=2C841 miles $9=2C800 https://www.salvagedrive.com/Cars/Category?SysId=3D901024317 CLICK FOR MORE INFO (https://www.salvagedrive.com/Cars/Category?SysId=3D90= 1024317) ** 2007 TOYOTA COROLLA ------------------------------------------------------------ Clean Title 107=2C474 miles $6=2C380 https://www.salvagedrive.com/Cars/Category?SysId=3D901019125 CLICK FOR MORE INFO (https://www.salvagedrive.com/Cars/Category?SysId=3D90= 1019125) ** 2007 TOYOTA CAMRY ------------------------------------------------------------ Clean Title 124=2C800 miles $7=2C800 https://www.salvagedrive.com/Cars/Category?SysId=3D900002666 CLICK FOR MORE INFO (https://www.salvagedrive.com/Cars/Category?SysId=3D90= 0002666) ** 2008 TOYOTA TACOMA ------------------------------------------------------------ Clean Title 189=2C341 miles $7=2C950 https://www.salvagedrive.com/Cars/Category?SysId=3D901024318 CLICK FOR MORE INFO (https://www.salvagedrive.com/Cars/Category?SysId=3D90= 1024318) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ** LET US SEARCH FOR YOU! TELL US WHAT YOU ARE LOOKING FOR AND OUR EXPERTS= WILL SEARCH FOR YOU BASED ON YOUR SPECIFIC BUDGET AND REQUIREMENTS. (http= s://www.salvagedrive.com) ** (https://www.salvagedrive.com) ** SalvageDrive.com (https://www.salvagedrive.com) 1-844-227-7411 Toll Free 1-347-492-1727 Tel. Skype: salvagedrive ** info@SalvageDrive.com (mailto:info@SalvageDrive.com) Don't forget to add info@salvagedrive.com to your Address Book to keep it= from skipping your inbox or getting caught in spam filters. We want your experience with the Salvage Drive to be as smooth and reassur= ing as possible. Accordingly=2C we diligently safeguard your privacy. If y= ou wish to review our Privacy Policy at any time=2C please click on the li= nk below=2C or copy and paste it into your web browser's location window ** Salvage Drive Privacy Policy (http://sdimages.salvagedrive.com/salvaged= rive/PrivacyPolicy.pdf) __________________________________________________________________________= __________________________________________________________________________= __________________________________________________________________________= __________________________________________________________________________= __________________________________________________________________________= __________________________________________________________________________= __________________________________________________________________________= __________________________________________________________________________= __________________________________________________________________________= __________________________________________________________________________= __________________________________________________________________________= __________________________________________________________________________= __________________________________________________________________________= _______________________ You can choose to unsubscribe from our Email Newsletters service by replyi= ng to this email with the word "STOP" and we will remove you from any futu= re mailings. __________________________________________________________________________= __________________________________________________________________________= __________________________________________________________________________= __________________________________________________________________________= __________________________________________________________________________= __________________________________________________________________________= __________________________________________________________________________= __________________________________________________________________________= __________________________________________________________________________= __________________________________________________________________________= __________________________________________________________________________= __________________________________________________________________________= __________________________________________________________________________= _______________________ =C2=A9 2014 SalvageDrive=2C Inc. | All rights reserved Salvage Drive=2C Inc. | 217 Broadway | Suite 505 | New York | NY | 10007 This email was sent to arch@freebsd.org (mailto:arch@freebsd.org) why did I get this? (http://salvagedrive.us8.list-manage.com/about?u=3D386= 68d8a390eaafe346aac8d5&id=3Db173b821c7&e=3Dc538f13530&c=3Db20b661509) un= subscribe from this list (http://salvagedrive.us8.list-manage.com/unsubscr= ibe?u=3D38668d8a390eaafe346aac8d5&id=3Db173b821c7&e=3Dc538f13530&c=3Db20b661= 509) update subscription preferences (http://salvagedrive.us8.list-man= age.com/profile?u=3D38668d8a390eaafe346aac8d5&id=3Db173b821c7&e=3Dc538f13530= ) Salvage Drive=2C Inc. =C2=B7 217 Broadway =C2=B7 Suite 505 =C2=B7 New York= =2C NY 10007 =C2=B7 USA From owner-freebsd-arch@FreeBSD.ORG Thu Jan 29 21:04:23 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2480B514 for ; Thu, 29 Jan 2015 21:04:23 +0000 (UTC) Received: from bigwig.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 D69869C8 for ; Thu, 29 Jan 2015 21:04:22 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id AD060B96C for ; Thu, 29 Jan 2015 16:04:21 -0500 (EST) From: John Baldwin To: 'freebsd-arch' Subject: Wrapper API for static bus_dma allocations Date: Thu, 29 Jan 2015 15:37:19 -0500 Message-ID: <2800970.jY4xzTy9Hz@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-STABLE; KDE/4.14.2; amd64; ; ) 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.2.7 (bigwig.baldwin.cx); Thu, 29 Jan 2015 16:04:21 -0500 (EST) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 21:04:23 -0000 The bus_dma API to allocate a chunk of static DMA'able memory (e.g. for descriptor rings) can be a bit obtuse to use in that it require a bit of boilerplate to create a tag, allocate memory for the tag, then load it to get the bus address. Similarly, freeing it also requires several steps. In addition, some of the steps are a bit subtle (e.g. the need to check for an error in the bus_dma callback instead of from bus_dmamap_load()) and not all drivers get those correct. To try to make this simpler I've written a little wrapper API that tries to provide a single call to allocate a buffer and a single call to free a buffer. Each buffer is described by a structure defined by the API, and if the call to allocate a buffer succeeds, the structure contains both a pointer to the buffer in the kernel's address space as well as a bus address of the buffer. In the interests of simplicity, this API does not allow the buffer to be quite as fully configured as the underlying bus_dma API, instead it aims to handle the most common cases that are used in most drivers. As such, it assumes that the buffer must be one contiguous range of DMA address space, and the only parameters that can be specified are the parent tag, the alignment of the buffer, the lowaddr parameter, the size of the buffer to allocate, and the flags parameter that is normally passed to bus_dmamem_alloc(). I believe that this should be sufficient to cover the vast majority of the drivers in our tree. I've included below a patch that contains the wrapper API along with a sample conversion of the ndis driver (chosen at random). If folks like this idea I will update the patch to include manpage changes as well. --- //depot/vendor/freebsd/src/sys/compat/ndis/subr_ndis.c +++ //depot/user/jhb/cleanup/sys/compat/ndis/subr_ndis.c @@ -186,7 +186,6 @@ static ndis_status NdisMAllocateMapRegisters(ndis_handle, uint32_t, uint8_t, uint32_t, uint32_t); static void NdisMFreeMapRegisters(ndis_handle); -static void ndis_mapshared_cb(void *, bus_dma_segment_t *, int, int); static void NdisMAllocateSharedMemory(ndis_handle, uint32_t, uint8_t, void **, ndis_physaddr *); static void ndis_asyncmem_complete(device_object *, void *); @@ -1387,23 +1386,6 @@ bus_dma_tag_destroy(sc->ndis_mtag); } -static void -ndis_mapshared_cb(arg, segs, nseg, error) - void *arg; - bus_dma_segment_t *segs; - int nseg; - int error; -{ - ndis_physaddr *p; - - if (error || nseg > 1) - return; - - p = arg; - - p->np_quad = segs[0].ds_addr; -} - /* * This maps to bus_dmamem_alloc(). */ @@ -1443,35 +1425,17 @@ * than 1GB of physical memory. */ - error = bus_dma_tag_create(sc->ndis_parent_tag, 64, - 0, NDIS_BUS_SPACE_SHARED_MAXADDR, BUS_SPACE_MAXADDR, NULL, - NULL, len, 1, len, BUS_DMA_ALLOCNOW, NULL, NULL, - &sh->ndis_stag); + error = bus_dma_mem_create(&sh->ndis_mem, sc->ndis_parent_tag, 64, + NDIS_BUS_SPACE_SHARED_MAXADDR, len, BUS_DMA_NOWAIT | BUS_DMA_ZERO); if (error) { free(sh, M_DEVBUF); return; } - error = bus_dmamem_alloc(sh->ndis_stag, vaddr, - BUS_DMA_NOWAIT | BUS_DMA_ZERO, &sh->ndis_smap); - - if (error) { - bus_dma_tag_destroy(sh->ndis_stag); - free(sh, M_DEVBUF); - return; - } + *vaddr = sh->ndis_mem.dma_vaddr; + paddr->np_quad = sh->ndis_mem.dma_baddr; - error = bus_dmamap_load(sh->ndis_stag, sh->ndis_smap, *vaddr, - len, ndis_mapshared_cb, (void *)paddr, BUS_DMA_NOWAIT); - - if (error) { - bus_dmamem_free(sh->ndis_stag, *vaddr, sh->ndis_smap); - bus_dma_tag_destroy(sh->ndis_stag); - free(sh, M_DEVBUF); - return; - } - /* * Save the physical address along with the source address. * The AirGo MIMO driver will call NdisMFreeSharedMemory() @@ -1482,8 +1446,6 @@ */ NDIS_LOCK(sc); - sh->ndis_paddr.np_quad = paddr->np_quad; - sh->ndis_saddr = *vaddr; InsertHeadList((&sc->ndis_shlist), (&sh->ndis_list)); NDIS_UNLOCK(sc); } @@ -1581,13 +1543,13 @@ l = sc->ndis_shlist.nle_flink; while (l != &sc->ndis_shlist) { sh = CONTAINING_RECORD(l, struct ndis_shmem, ndis_list); - if (sh->ndis_saddr == vaddr) + if (sh->ndis_mem.dma_vaddr == vaddr) break; /* * Check the physaddr too, just in case the driver lied * about the virtual address. */ - if (sh->ndis_paddr.np_quad == paddr.np_quad) + if (sh->ndis_mem.dma_baddr == paddr.np_quad) break; l = l->nle_flink; } @@ -1604,9 +1566,7 @@ NDIS_UNLOCK(sc); - bus_dmamap_unload(sh->ndis_stag, sh->ndis_smap); - bus_dmamem_free(sh->ndis_stag, sh->ndis_saddr, sh->ndis_smap); - bus_dma_tag_destroy(sh->ndis_stag); + bus_dma_mem_free(&sh->ndis_mem); free(sh, M_DEVBUF); } --- //depot/vendor/freebsd/src/sys/dev/if_ndis/if_ndisvar.h +++ //depot/user/jhb/cleanup/sys/dev/if_ndis/if_ndisvar.h @@ -66,10 +66,7 @@ struct ndis_shmem { list_entry ndis_list; - bus_dma_tag_t ndis_stag; - bus_dmamap_t ndis_smap; - void *ndis_saddr; - ndis_physaddr ndis_paddr; + struct bus_dmamem ndis_mem; }; struct ndis_cfglist { --- //depot/vendor/freebsd/src/sys/kern/subr_bus_dma.c +++ //depot/user/jhb/cleanup/sys/kern/subr_bus_dma.c @@ -540,3 +540,66 @@ return (0); } + +struct bus_dma_mem_cb_data { + struct bus_dmamem *mem; + int error; +}; + +static void +bus_dma_mem_cb(void *arg, bus_dma_segment_t *segs, int nseg, int error) +{ + struct bus_dma_mem_cb_data *d; + + d = arg; + d->error = error; + if (error) + return; + d->mem->dma_baddr = segs[0].ds_addr; +} + +int +bus_dma_mem_create(struct bus_dmamem *mem, bus_dma_tag_t parent, + bus_size_t alignment, bus_addr_t lowaddr, bus_size_t len, int flags) +{ + struct bus_dma_mem_cb_data d; + int error; + + bzero(mem, sizeof(*mem)); + error = bus_dma_tag_create(parent, alignment, 0, lowaddr, + BUS_SPACE_MAXADDR, NULL, NULL, len, 1, len, 0, NULL, NULL, + &mem->dma_tag); + if (error) { + bus_dma_mem_free(mem); + return (error); + } + error = bus_dmamem_alloc(mem->dma_tag, &mem->dma_vaddr, flags, + &mem->dma_map); + if (error) { + bus_dma_mem_free(mem); + return (error); + } + d.mem = mem; + error = bus_dmamap_load(mem->dma_tag, mem->dma_map, mem->dma_vaddr, len, + bus_dma_mem_cb, &d, BUS_DMA_NOWAIT); + if (error == 0) + error = d.error; + if (error) { + bus_dma_mem_free(mem); + return (error); + } + return (0); +} + +void +bus_dma_mem_free(struct bus_dmamem *mem) +{ + + if (mem->dma_baddr != 0) + bus_dmamap_unload(mem->dma_tag, mem->dma_map); + if (mem->dma_vaddr != NULL) + bus_dmamem_free(mem->dma_tag, mem->dma_vaddr, mem->dma_map); + if (mem->dma_tag != NULL) + bus_dma_tag_destroy(mem->dma_tag); + bzero(mem, sizeof(*mem)); +} --- //depot/vendor/freebsd/src/sys/sys/bus_dma.h +++ //depot/user/jhb/cleanup/sys/sys/bus_dma.h @@ -337,4 +337,29 @@ #endif /* __sparc64__ */ +/* + * A wrapper API to simplify management of static mappings. + */ + +struct bus_dmamem { + bus_dma_tag_t dma_tag; + bus_dmamap_t dma_map; + void *dma_vaddr; + bus_addr_t dma_baddr; +}; + +/* + * Allocate a mapping. On success, zero is returned and the 'dma_vaddr' + * and 'dma_baddr' fields are populated with the virtual and bus addresses, + * respectively, of the mapping. + */ +int bus_dma_mem_create(struct bus_dmamem *mem, bus_dma_tag_t parent, + bus_size_t alignment, bus_addr_t lowaddr, + bus_size_t len, int flags); + +/* + * Release a mapping created by bus_dma_mem_create(). + */ +void bus_dma_mem_free(struct bus_dmamem *mem); + #endif /* _BUS_DMA_H_ */ -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Thu Jan 29 22:11:00 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 695E57FE; Thu, 29 Jan 2015 22:11:00 +0000 (UTC) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 2C90FFCB; Thu, 29 Jan 2015 22:10:59 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id B4E8A3BD57; Thu, 29 Jan 2015 22:10:52 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.9/8.14.9) with ESMTP id t0TLssrf067605; Thu, 29 Jan 2015 21:54:54 GMT (envelope-from phk@phk.freebsd.dk) To: John Baldwin Subject: Re: Wrapper API for static bus_dma allocations In-reply-to: <2800970.jY4xzTy9Hz@ralph.baldwin.cx> From: "Poul-Henning Kamp" References: <2800970.jY4xzTy9Hz@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <67603.1422568494.1@critter.freebsd.dk> Date: Thu, 29 Jan 2015 21:54:54 +0000 Message-ID: <67604.1422568494@critter.freebsd.dk> Cc: 'freebsd-arch' X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 22:11:00 -0000 -------- In message <2800970.jY4xzTy9Hz@ralph.baldwin.cx>, John Baldwin writes: >The bus_dma API to allocate a chunk of static DMA'able memory (e.g. for >descriptor rings) can be a bit obtuse [...] Isn't it time we take a good hard stare at all of the bus_dma API, and refactor it into something a lot more compact ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Thu Jan 29 23:06:30 2015 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4B1FA258 for ; Thu, 29 Jan 2015 23:06:30 +0000 (UTC) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailhost.stack.nl", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id EBED385E for ; Thu, 29 Jan 2015 23:06:29 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 421B8B842B; Fri, 30 Jan 2015 00:06:26 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id 2BA0D28494; Fri, 30 Jan 2015 00:06:26 +0100 (CET) Date: Fri, 30 Jan 2015 00:06:26 +0100 From: Jilles Tjoelker To: Andrew Wilcox Subject: Re: Current status of utimensat(2) Message-ID: <20150129230625.GA26181@stack.nl> References: <005701d03b53$92796ce0$b76c46a0$@Wilcox-Tech.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="k+w/mQv8wyuph6w0" Content-Disposition: inline In-Reply-To: <005701d03b53$92796ce0$b76c46a0$@Wilcox-Tech.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 23:06:30 -0000 --k+w/mQv8wyuph6w0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Jan 28, 2015 at 05:38:50PM -0600, Andrew Wilcox wrote: > I am wondering about the current status of the utimensat(2) and > futimens(2) patch set. I saw some posts from early 2013 but nothing > more recent. In addition to improving POSIX 2008 compliance, this > will additionally enable me to continue my work on the Linuxulator. > As it stands, most Gentoo and Ubuntu binaries do not work in the > Linuxulator because of the missing utimensat syscall. > Is anyone currently working on this? I'd be happy to help out. I committed utimensat/futimens to head. I also made a start at Linuxulator utimensat, see attached patch. Please complete it and test it. -- Jilles Tjoelker --k+w/mQv8wyuph6w0 Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="linuxulator-utimensat.patch" commit 579d4ad12989f5ab88983d461156d16bb5bcdec1 Author: Jilles Tjoelker Date: Sun Jan 25 01:09:37 2015 +0100 Add Linux utimensat() syscall. Conflicts: sys/compat/linux/linux_file.h diff --git a/sys/compat/linux/linux_file.h b/sys/compat/linux/linux_file.h index 2d3106f..58e80f1 100644 --- a/sys/compat/linux/linux_file.h +++ b/sys/compat/linux/linux_file.h @@ -54,4 +54,7 @@ #define LINUX_MS_NOEXEC 0x0008 #define LINUX_MS_REMOUNT 0x0020 +#define LINUX_UTIME_NOW 0x3fffffff +#define LINUX_UTIME_OMIT 0x3ffffffe + #endif /* !_LINUX_FILE_H_ */ diff --git a/sys/compat/linux/linux_misc.c b/sys/compat/linux/linux_misc.c index 93dd80d..262ada9 100644 --- a/sys/compat/linux/linux_misc.c +++ b/sys/compat/linux/linux_misc.c @@ -851,6 +851,66 @@ linux_futimesat(struct thread *td, struct linux_futimesat_args *args) #endif /* __i386__ || (__amd64__ && COMPAT_LINUX32) */ int +linux_utimensat(struct thread *td, struct linux_utimensat_args *args) +{ + struct l_timespec lts[2]; + struct timespec ts[2], *tsp = NULL; + char *fname; + int error, fd, flag; + + if (args->utimes != NULL) { + if ((error = copyin(args->utimes, lts, sizeof lts))) + return (error); + ts[0].tv_sec = lts[0].tv_sec; + if (lts[0].tv_nsec >= 0 && lts[0].tv_nsec < 1000000000) + ts[0].tv_nsec = lts[0].tv_nsec; + else if (lts[0].tv_nsec == LINUX_UTIME_NOW) + ts[0].tv_nsec = UTIME_NOW; + else if (lts[0].tv_nsec == LINUX_UTIME_OMIT) + ts[0].tv_nsec = UTIME_OMIT; + else + return (EINVAL); + ts[1].tv_sec = lts[1].tv_sec; + if (lts[1].tv_nsec >= 0 && lts[1].tv_nsec < 1000000000) + ts[1].tv_nsec = lts[1].tv_nsec; + else if (lts[1].tv_nsec == LINUX_UTIME_NOW) + ts[1].tv_nsec = UTIME_NOW; + else if (lts[1].tv_nsec == LINUX_UTIME_OMIT) + ts[1].tv_nsec = UTIME_OMIT; + else + return (EINVAL); + tsp = ts; + } + + if (args->pathname == NULL) { + if (args->flag != 0) + return (EINVAL); + fname = NULL; + flag = 0; + } else { + if (args->flag & ~LINUX_AT_SYMLINK_NOFOLLOW) + return (EINVAL); + fd = (args->fd == LINUX_AT_FDCWD) ? AT_FDCWD : args->fd; + LCONVPATHEXIST_AT(td, args->pathname, &fname, fd); + flag = args->flag & LINUX_AT_SYMLINK_NOFOLLOW ? + AT_SYMLINK_NOFOLLOW : 0; + } + +#ifdef DEBUG + if (ldebug(utimensat)) + printf(ARGS(utimensat, "%s, *"), fname); +#endif + + if (fname == NULL) + error = kern_futimens(td, fd, tsp, UIO_SYSSPACE); + else + error = kern_utimensat(td, fd, fname, UIO_SYSSPACE, tsp, + UIO_SYSSPACE, flag); + LFREEPATH(fname); + return (error); +} + +int linux_common_wait(struct thread *td, int pid, int *status, int options, struct rusage *ru) { diff --git a/sys/i386/linux/linux_dummy.c b/sys/i386/linux/linux_dummy.c index 85d40f0..4a63994 100644 --- a/sys/i386/linux/linux_dummy.c +++ b/sys/i386/linux/linux_dummy.c @@ -107,7 +107,6 @@ DUMMY(move_pages); DUMMY(getcpu); DUMMY(epoll_pwait); /* linux 2.6.22: */ -DUMMY(utimensat); DUMMY(signalfd); DUMMY(timerfd_create); DUMMY(eventfd); diff --git a/sys/i386/linux/syscalls.master b/sys/i386/linux/syscalls.master index 5b4f3a6..516980a 100644 --- a/sys/i386/linux/syscalls.master +++ b/sys/i386/linux/syscalls.master @@ -532,7 +532,7 @@ 318 AUE_NULL STD { int linux_getcpu(void); } 319 AUE_NULL STD { int linux_epoll_pwait(void); } ; linux 2.6.22: -320 AUE_NULL STD { int linux_utimensat(void); } +320 AUE_FUTIMESAT STD { int linux_utimensat(l_int fd, const char *pathname, const struct l_timespec *utimes, l_int flag); } 321 AUE_NULL STD { int linux_signalfd(void); } 322 AUE_NULL STD { int linux_timerfd_create(void); } 323 AUE_NULL STD { int linux_eventfd(void); } --k+w/mQv8wyuph6w0-- From owner-freebsd-arch@FreeBSD.ORG Fri Jan 30 14:56:28 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B9053790 for ; Fri, 30 Jan 2015 14:56:28 +0000 (UTC) Received: from bigwig.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 71EDA6AB for ; Fri, 30 Jan 2015 14:56:28 +0000 (UTC) Received: from new-host-3.home (pool-173-54-116-245.nwrknj.fios.verizon.net [173.54.116.245]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 6710CB913; Fri, 30 Jan 2015 09:56:27 -0500 (EST) Message-ID: <54CB9B9F.50905@FreeBSD.org> Date: Fri, 30 Jan 2015 09:56:31 -0500 From: John Baldwin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Poul-Henning Kamp Subject: Re: Wrapper API for static bus_dma allocations References: <2800970.jY4xzTy9Hz@ralph.baldwin.cx> <67604.1422568494@critter.freebsd.dk> In-Reply-To: <67604.1422568494@critter.freebsd.dk> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 30 Jan 2015 09:56:27 -0500 (EST) Cc: 'freebsd-arch' X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jan 2015 14:56:28 -0000 On 1/29/15 4:54 PM, Poul-Henning Kamp wrote: > -------- > In message <2800970.jY4xzTy9Hz@ralph.baldwin.cx>, John Baldwin writes: > >> The bus_dma API to allocate a chunk of static DMA'able memory (e.g. for >> descriptor rings) can be a bit obtuse [...] > > Isn't it time we take a good hard stare at all of the bus_dma API, > and refactor it into something a lot more compact ? Given the amount of oddball hardware out there I don't think there is a lot you can cut out. The filter function might be something we can lose (and losing it would simplify the implementation), but all the other weird constraints are actually used by something AFAIK. I do think we can provide some simpler wrappers for some of the more common cases, but there will be some hardware for which those wrappers do not work. One suggestion Scott has had is to at least make it easier to extend the API by using getter/setter routines on the tag to work with tag attributes instead of passing them all in bus_dma_tag_create(). -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Fri Jan 30 15:21:57 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 06DC164F; Fri, 30 Jan 2015 15:21:57 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 693DEA52; Fri, 30 Jan 2015 15:21:56 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t0UFLoVq000588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2015 17:21:50 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t0UFLoVq000588 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t0UFLodb000587; Fri, 30 Jan 2015 17:21:50 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 30 Jan 2015 17:21:50 +0200 From: Konstantin Belousov To: John Baldwin Subject: Re: Wrapper API for static bus_dma allocations Message-ID: <20150130152150.GX42409@kib.kiev.ua> References: <2800970.jY4xzTy9Hz@ralph.baldwin.cx> <67604.1422568494@critter.freebsd.dk> <54CB9B9F.50905@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54CB9B9F.50905@FreeBSD.org> User-Agent: Mutt/1.5.23 (2014-03-12) 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.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: Poul-Henning Kamp , 'freebsd-arch' X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jan 2015 15:21:57 -0000 On Fri, Jan 30, 2015 at 09:56:31AM -0500, John Baldwin wrote: > On 1/29/15 4:54 PM, Poul-Henning Kamp wrote: > > -------- > > In message <2800970.jY4xzTy9Hz@ralph.baldwin.cx>, John Baldwin writes: > > > >> The bus_dma API to allocate a chunk of static DMA'able memory (e.g. for > >> descriptor rings) can be a bit obtuse [...] > > > > Isn't it time we take a good hard stare at all of the bus_dma API, > > and refactor it into something a lot more compact ? > > Given the amount of oddball hardware out there I don't think there is a > lot you can cut out. The filter function might be something we can lose > (and losing it would simplify the implementation), but all the other > weird constraints are actually used by something AFAIK. I do think we > can provide some simpler wrappers for some of the more common cases, but > there will be some hardware for which those wrappers do not work. > > One suggestion Scott has had is to at least make it easier to extend the > API by using getter/setter routines on the tag to work with tag > attributes instead of passing them all in bus_dma_tag_create(). BTW, filter function is useless. It can deny specific bus address from being used, but it does not provide the busdma implementation even a hint what other address should be (tried to) used. In dmar busdma, I simply ignored it. And there is no real users of filter in the tree. From owner-freebsd-arch@FreeBSD.ORG Fri Jan 30 20:31:45 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AC15F461 for ; Fri, 30 Jan 2015 20:31:45 +0000 (UTC) Received: from bigwig.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 845E933F for ; Fri, 30 Jan 2015 20:31:45 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-54-116-245.nwrknj.fios.verizon.net [173.54.116.245]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A0E5CB913; Fri, 30 Jan 2015 15:31:44 -0500 (EST) From: John Baldwin To: Konstantin Belousov Subject: Re: Wrapper API for static bus_dma allocations Date: Fri, 30 Jan 2015 15:31:23 -0500 Message-ID: <1440008.gcoNUU8dV6@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-STABLE; KDE/4.14.2; amd64; ; ) In-Reply-To: <20150130152150.GX42409@kib.kiev.ua> References: <2800970.jY4xzTy9Hz@ralph.baldwin.cx> <54CB9B9F.50905@FreeBSD.org> <20150130152150.GX42409@kib.kiev.ua> 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.2.7 (bigwig.baldwin.cx); Fri, 30 Jan 2015 15:31:44 -0500 (EST) Cc: Poul-Henning Kamp , 'freebsd-arch' X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jan 2015 20:31:45 -0000 On Friday, January 30, 2015 05:21:50 PM Konstantin Belousov wrote: > On Fri, Jan 30, 2015 at 09:56:31AM -0500, John Baldwin wrote: > > On 1/29/15 4:54 PM, Poul-Henning Kamp wrote: > > > -------- > > > > > > In message <2800970.jY4xzTy9Hz@ralph.baldwin.cx>, John Baldwin writes: > > >> The bus_dma API to allocate a chunk of static DMA'able memory (e.g. for > > >> descriptor rings) can be a bit obtuse [...] > > > > > > Isn't it time we take a good hard stare at all of the bus_dma API, > > > and refactor it into something a lot more compact ? > > > > Given the amount of oddball hardware out there I don't think there is a > > lot you can cut out. The filter function might be something we can lose > > (and losing it would simplify the implementation), but all the other > > weird constraints are actually used by something AFAIK. I do think we > > can provide some simpler wrappers for some of the more common cases, but > > there will be some hardware for which those wrappers do not work. > > > > One suggestion Scott has had is to at least make it easier to extend the > > API by using getter/setter routines on the tag to work with tag > > attributes instead of passing them all in bus_dma_tag_create(). > > BTW, filter function is useless. It can deny specific bus address from > being used, but it does not provide the busdma implementation even a hint > what other address should be (tried to) used. In dmar busdma, I simply > ignored it. And there is no real users of filter in the tree. Yes, it is very annoying. I think some old ISA SCSI HBA driver might have used it to skip over some low-memory hole (i.e. there were two valid DMA ranges and this was the kludge instead of having two sets of lowaddr/highaddr exclusions). (That is one part of the API we could rototill is to just remove the highaddr arg just use a single arg which is effectively lowaddr. I think all drivers always set highaddr to BUS_SPACE_MAXADDR.) -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Sat Jan 31 03:08:02 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 69919E8D for ; Sat, 31 Jan 2015 03:08:02 +0000 (UTC) Received: from mail-oi0-f52.google.com (mail-oi0-f52.google.com [209.85.218.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2DF33EC7 for ; Sat, 31 Jan 2015 03:08:01 +0000 (UTC) Received: by mail-oi0-f52.google.com with SMTP id h136so37566877oig.11 for ; Fri, 30 Jan 2015 19:07:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=vwzMtvsayHAZcfz2TRpm2Hnsq9p9qfdIXpsCndgMEWw=; b=Imof5IVsa9S2aMAjRsCq1y2hY4Nmjn/7SQW9MaFqbwPxzgsSu20gfQ1JHaKjy2U+lV XZFVB04YSIbu7vOJLjJO1FA+X+959aH2ut5rG+KE6+eMw0Lqdy2gFD8Lh9a+9hcsvHmY goC6Vvh0I+7XSLYCrvve8Qo8o1t8zepEnbgWBj7zxuRm1r/OBR70t/KpNLucatDKP5h5 08Bhj0Mq+4or2vzjfpfcOyj6RzwLwMALMpubjCUDtmQslm2JZSQ546TTdASoNfm2OYDp sndWDFjDC19T40u8Rwq2o0V5arTYY9wfAi83SWtudkx3MAhz5Ae7OlPJDq6ZgQdZwTAx ea/w== X-Gm-Message-State: ALoCoQl7MY5OIZeSk4uv2DyAiYbjyY+LdaN8QJskOtuh1nxeGLvc8XLPdsPBvkp4MqZViDejHc9O X-Received: by 10.202.67.132 with SMTP id q126mr2812850oia.15.1422673675593; Fri, 30 Jan 2015 19:07:55 -0800 (PST) Received: from [172.16.173.216] ([12.196.110.43]) by mx.google.com with ESMTPSA id dd3sm6260141obb.23.2015.01.30.19.07.53 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 30 Jan 2015 19:07:55 -0800 (PST) Sender: Warner Losh Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: Wrapper API for static bus_dma allocations From: Warner Losh In-Reply-To: <1440008.gcoNUU8dV6@ralph.baldwin.cx> Date: Fri, 30 Jan 2015 21:07:52 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <21F3F28E-DAB8-4809-A9ED-1095F6BECCFC@bsdimp.com> References: <2800970.jY4xzTy9Hz@ralph.baldwin.cx> <54CB9B9F.50905@FreeBSD.org> <20150130152150.GX42409@kib.kiev.ua> <1440008.gcoNUU8dV6@ralph.baldwin.cx> To: John Baldwin X-Mailer: Apple Mail (2.2070.6) Cc: Konstantin Belousov , Poul-Henning Kamp , freebsd-arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jan 2015 03:08:02 -0000 > On Jan 30, 2015, at 2:31 PM, John Baldwin wrote: >=20 > On Friday, January 30, 2015 05:21:50 PM Konstantin Belousov wrote: >> On Fri, Jan 30, 2015 at 09:56:31AM -0500, John Baldwin wrote: >>> On 1/29/15 4:54 PM, Poul-Henning Kamp wrote: >>>> -------- >>>>=20 >>>> In message <2800970.jY4xzTy9Hz@ralph.baldwin.cx>, John Baldwin = writes: >>>>> The bus_dma API to allocate a chunk of static DMA'able memory = (e.g. for >>>>> descriptor rings) can be a bit obtuse [...] >>>>=20 >>>> Isn't it time we take a good hard stare at all of the bus_dma API, >>>> and refactor it into something a lot more compact ? >>>=20 >>> Given the amount of oddball hardware out there I don't think there = is a >>> lot you can cut out. The filter function might be something we can = lose >>> (and losing it would simplify the implementation), but all the other >>> weird constraints are actually used by something AFAIK. I do think = we >>> can provide some simpler wrappers for some of the more common cases, = but >>> there will be some hardware for which those wrappers do not work. >>>=20 >>> One suggestion Scott has had is to at least make it easier to extend = the >>> API by using getter/setter routines on the tag to work with tag >>> attributes instead of passing them all in bus_dma_tag_create(). >>=20 >> BTW, filter function is useless. It can deny specific bus address = from >> being used, but it does not provide the busdma implementation even a = hint >> what other address should be (tried to) used. In dmar busdma, I = simply >> ignored it. And there is no real users of filter in the tree. >=20 > Yes, it is very annoying. I think some old ISA SCSI HBA driver might = have=20 > used it to skip over some low-memory hole (i.e. there were two valid = DMA=20 > ranges and this was the kludge instead of having two sets of = lowaddr/highaddr=20 > exclusions). (That is one part of the API we could rototill is to = just remove=20 > the highaddr arg just use a single arg which is effectively lowaddr. = I think=20 > all drivers always set highaddr to BUS_SPACE_MAXADDR.) Not all. There=E2=80=99s some PCI cards that can=E2=80=99t do 64-bit = cycles that pass in the 32-bit value on 64-bit systems. There=E2=80=99s 386 instances of this in the = tree. But that may be lowaddr only. It=E2=80=99s hard to grep for this to be sure. Wanrer= From owner-freebsd-arch@FreeBSD.ORG Sat Jan 31 08:59:36 2015 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 69707157 for ; Sat, 31 Jan 2015 08:59:36 +0000 (UTC) Received: from mail.wilcox-tech.com (mail.foxkit.us [192.99.209.192]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.wilcox-tech.com", Issuer "mail.wilcox-tech.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 22EEF98 for ; Sat, 31 Jan 2015 08:59:35 +0000 (UTC) Received: (qmail 1668 invoked from network); 31 Jan 2015 09:00:53 -0000 Received: from c-71-57-141-247.hsd1.fl.comcast.net (HELO Todd) (AWilcox@Wilcox-Tech.com@71.57.141.247) by mail.foxkit.us with ESMTPA; 31 Jan 2015 09:00:53 -0000 From: "Andrew Wilcox" To: "'Jilles Tjoelker'" , Subject: RFC: Added utimensat(2) to Linuxulator (was RE: Current status of utimensat(2)) Date: Sat, 31 Jan 2015 02:59:34 -0600 Message-ID: <004f01d03d34$3caed970$b60c8c50$@Wilcox-Tech.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0050_01D03D01.F2161720" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdA9NDMD3eIcqEVmTYu/sdpXkGqLDA== Content-Language: en-gb X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jan 2015 08:59:36 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0050_01D03D01.F2161720 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Jilles Tjoelker sent 29 January 2015 17:06: > I committed utimensat/futimens to head. I also made a start at = Linuxulator > utimensat, see attached patch. Please complete it and test it. >=20 > -- > Jilles Tjoelker I have merged some of the things Jilles' patch does into the patch I was = already working on. I have tested a number of corner cases with it, and = compared the results to a running Linux system. I have also run = software which all use utimensat(2) on Linux, such as recent tar(1), = touch(1), and Python 3.3's shutil library, inside the Linuxulator with = this patch applied. I have found this patch's behaviour to be correct = in these tests. Please let me know of any comments or issues. I will be additionally trying to merge this into dchagin's lemul branch, = but that discussion will take place on Phabricator (and will involve = testing on amd64-native Linuxulator, which I have not yet done).=20 Regards, Andrew -- Andrew Wilcox, C/C++/Python developer, kernel hacker Blog: http://blog.foxkit.us/ WWW: http://foxkit.us/ GitHub: https://github.com/awilfox ------=_NextPart_000_0050_01D03D01.F2161720 Content-Type: application/octet-stream; name="linux_utimensat.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="linux_utimensat.diff" Index: sys/amd64/linux32/linux32_dummy.c=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= --- sys/amd64/linux32/linux32_dummy.c (revision 277871)=0A= +++ sys/amd64/linux32/linux32_dummy.c (working copy)=0A= @@ -111,7 +111,6 @@=0A= DUMMY(getcpu);=0A= DUMMY(epoll_pwait);=0A= /* linux 2.6.22: */=0A= -DUMMY(utimensat);=0A= DUMMY(signalfd);=0A= DUMMY(timerfd_create);=0A= DUMMY(eventfd);=0A= Index: sys/amd64/linux32/linux32_proto.h=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= --- sys/amd64/linux32/linux32_proto.h (revision 277871)=0A= +++ sys/amd64/linux32/linux32_proto.h (working copy)=0A= @@ -1017,7 +1017,10 @@=0A= register_t dummy;=0A= };=0A= struct linux_utimensat_args {=0A= - register_t dummy;=0A= + char dfd_l_[PADL_(l_int)]; l_int dfd; char dfd_r_[PADR_(l_int)];=0A= + char pathname_l_[PADL_(const char *)]; const char * pathname; char = pathname_r_[PADR_(const char *)];=0A= + char times_l_[PADL_(const struct l_timespec *)]; const struct = l_timespec * times; char times_r_[PADR_(const struct l_timespec *)];=0A= + char flags_l_[PADL_(l_int)]; l_int flags; char flags_r_[PADR_(l_int)];=0A= };=0A= struct linux_signalfd_args {=0A= register_t dummy;=0A= @@ -1652,7 +1655,7 @@=0A= #define LINUX_SYS_AUE_linux_move_pages AUE_NULL=0A= #define LINUX_SYS_AUE_linux_getcpu AUE_NULL=0A= #define LINUX_SYS_AUE_linux_epoll_pwait AUE_NULL=0A= -#define LINUX_SYS_AUE_linux_utimensat AUE_NULL=0A= +#define LINUX_SYS_AUE_linux_utimensat AUE_FUTIMESAT=0A= #define LINUX_SYS_AUE_linux_signalfd AUE_NULL=0A= #define LINUX_SYS_AUE_linux_timerfd_create AUE_NULL=0A= #define LINUX_SYS_AUE_linux_eventfd AUE_NULL=0A= Index: sys/amd64/linux32/linux32_sysent.c=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= --- sys/amd64/linux32/linux32_sysent.c (revision 277871)=0A= +++ sys/amd64/linux32/linux32_sysent.c (working copy)=0A= @@ -339,7 +339,7 @@=0A= { 0, (sy_call_t *)linux_move_pages, AUE_NULL, NULL, 0, 0, 0, = SY_THR_STATIC }, /* 317 =3D linux_move_pages */=0A= { 0, (sy_call_t *)linux_getcpu, AUE_NULL, NULL, 0, 0, 0, SY_THR_STATIC = }, /* 318 =3D linux_getcpu */=0A= { 0, (sy_call_t *)linux_epoll_pwait, AUE_NULL, NULL, 0, 0, 0, = SY_THR_STATIC }, /* 319 =3D linux_epoll_pwait */=0A= - { 0, (sy_call_t *)linux_utimensat, AUE_NULL, NULL, 0, 0, 0, = SY_THR_STATIC }, /* 320 =3D linux_utimensat */=0A= + { AS(linux_utimensat_args), (sy_call_t *)linux_utimensat, = AUE_FUTIMESAT, NULL, 0, 0, 0, SY_THR_STATIC }, /* 320 =3D = linux_utimensat */=0A= { 0, (sy_call_t *)linux_signalfd, AUE_NULL, NULL, 0, 0, 0, = SY_THR_STATIC }, /* 321 =3D linux_signalfd */=0A= { 0, (sy_call_t *)linux_timerfd_create, AUE_NULL, NULL, 0, 0, 0, = SY_THR_STATIC }, /* 322 =3D linux_timerfd_create */=0A= { 0, (sy_call_t *)linux_eventfd, AUE_NULL, NULL, 0, 0, 0, = SY_THR_STATIC }, /* 323 =3D linux_eventfd */=0A= Index: sys/amd64/linux32/linux32_systrace_args.c=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= --- sys/amd64/linux32/linux32_systrace_args.c (revision 277871)=0A= +++ sys/amd64/linux32/linux32_systrace_args.c (working copy)=0A= @@ -2130,7 +2130,12 @@=0A= }=0A= /* linux_utimensat */=0A= case 320: {=0A= - *n_args =3D 0;=0A= + struct linux_utimensat_args *p =3D params;=0A= + iarg[0] =3D p->dfd; /* l_int */=0A= + uarg[1] =3D (intptr_t) p->pathname; /* const char * */=0A= + uarg[2] =3D (intptr_t) p->times; /* const struct l_timespec * */=0A= + iarg[3] =3D p->flags; /* l_int */=0A= + *n_args =3D 4;=0A= break;=0A= }=0A= /* linux_signalfd */=0A= @@ -5395,6 +5400,22 @@=0A= break;=0A= /* linux_utimensat */=0A= case 320:=0A= + switch(ndx) {=0A= + case 0:=0A= + p =3D "l_int";=0A= + break;=0A= + case 1:=0A= + p =3D "const char *";=0A= + break;=0A= + case 2:=0A= + p =3D "const struct l_timespec *";=0A= + break;=0A= + case 3:=0A= + p =3D "l_int";=0A= + break;=0A= + default:=0A= + break;=0A= + };=0A= break;=0A= /* linux_signalfd */=0A= case 321:=0A= @@ -6684,6 +6705,9 @@=0A= case 319:=0A= /* linux_utimensat */=0A= case 320:=0A= + if (ndx =3D=3D 0 || ndx =3D=3D 1)=0A= + p =3D "int";=0A= + break;=0A= /* linux_signalfd */=0A= case 321:=0A= /* linux_timerfd_create */=0A= Index: sys/amd64/linux32/syscalls.master=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= --- sys/amd64/linux32/syscalls.master (revision 277871)=0A= +++ sys/amd64/linux32/syscalls.master (working copy)=0A= @@ -524,7 +524,8 @@=0A= 318 AUE_NULL STD { int linux_getcpu(void); }=0A= 319 AUE_NULL STD { int linux_epoll_pwait(void); }=0A= ; linux 2.6.22:=0A= -320 AUE_NULL STD { int linux_utimensat(void); }=0A= +320 AUE_FUTIMESAT STD { int linux_utimensat(l_int dfd, const char = *pathname, \=0A= + const struct l_timespec *times, l_int flags); }=0A= 321 AUE_NULL STD { int linux_signalfd(void); }=0A= 322 AUE_NULL STD { int linux_timerfd_create(void); }=0A= 323 AUE_NULL STD { int linux_eventfd(void); }=0A= Index: sys/compat/linux/linux_misc.c=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= --- sys/compat/linux/linux_misc.c (revision 277871)=0A= +++ sys/compat/linux/linux_misc.c (working copy)=0A= @@ -816,6 +816,89 @@=0A= return (error);=0A= }=0A= =0A= +int =0A= +linux_utimensat(struct thread *td, struct linux_utimensat_args *args)=0A= +{=0A= + struct l_timespec l_times[2];=0A= + struct timespec times[2], *timesp =3D NULL;=0A= + char *path =3D NULL;=0A= + int error, dfd, flags =3D 0;=0A= +=0A= + dfd =3D (args->dfd =3D=3D LINUX_AT_FDCWD) ? AT_FDCWD : args->dfd;=0A= +=0A= +#ifdef DEBUG=0A= + if (ldebug(utimensat))=0A= + printf(ARGS(utimensat, "%d, *"), dfd);=0A= +#endif=0A= +=0A= + if (args->flags & ~LINUX_AT_SYMLINK_NOFOLLOW)=0A= + return (EINVAL);=0A= +=0A= + if (args->times !=3D NULL) {=0A= + if ((error =3D copyin(args->times, l_times, sizeof l_times)))=0A= + return (error);=0A= +=0A= + if (l_times[0].tv_nsec > 999999999 ||=0A= + l_times[1].tv_nsec > 999999999)=0A= + return (EINVAL);=0A= +=0A= + times[0].tv_sec =3D l_times[0].tv_sec;=0A= + switch (l_times[0].tv_nsec)=0A= + {=0A= + case LINUX_UTIME_OMIT:=0A= + times[0].tv_nsec =3D UTIME_OMIT;=0A= + break;=0A= + case LINUX_UTIME_NOW:=0A= + times[0].tv_nsec =3D UTIME_NOW;=0A= + break;=0A= + default:=0A= + times[0].tv_nsec =3D l_times[0].tv_nsec;=0A= + }=0A= +=0A= + times[1].tv_sec =3D l_times[1].tv_sec;=0A= + switch (l_times[1].tv_nsec)=0A= + {=0A= + case LINUX_UTIME_OMIT:=0A= + times[1].tv_nsec =3D UTIME_OMIT;=0A= + break;=0A= + case LINUX_UTIME_NOW:=0A= + times[1].tv_nsec =3D UTIME_NOW;=0A= + break;=0A= + default:=0A= + times[1].tv_nsec =3D l_times[1].tv_nsec;=0A= + }=0A= + timesp =3D times;=0A= + }=0A= +=0A= + if (times[0].tv_nsec =3D=3D UTIME_OMIT && times[1].tv_nsec =3D=3D = UTIME_OMIT) {=0A= + /* This breaks POSIX, but is what the Linux kernel does=0A= + * _on purpose_ (documented in the man page for utimensat(2)),=0A= + * so we must follow that behaviour. */=0A= + return (0);=0A= + }=0A= +=0A= + if (args->pathname !=3D NULL)=0A= + LCONVPATHEXIST_AT(td, args->pathname, &path, dfd);=0A= + else {=0A= + if (args->flags !=3D 0)=0A= + return (EINVAL);=0A= + }=0A= +=0A= + if (args->flags & LINUX_AT_SYMLINK_NOFOLLOW)=0A= + flags |=3D AT_SYMLINK_NOFOLLOW;=0A= +=0A= + if (path =3D=3D NULL)=0A= + error =3D kern_futimens(td, dfd, timesp, UIO_SYSSPACE);=0A= + else=0A= + {=0A= + error =3D kern_utimensat(td, dfd, path, UIO_SYSSPACE, timesp,=0A= + UIO_SYSSPACE, flags);=0A= + LFREEPATH(path);=0A= + }=0A= +=0A= + return (error);=0A= +}=0A= +=0A= int=0A= linux_futimesat(struct thread *td, struct linux_futimesat_args *args)=0A= {=0A= Index: sys/compat/linux/linux_misc.h=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= --- sys/compat/linux/linux_misc.h (revision 277871)=0A= +++ sys/compat/linux/linux_misc.h (working copy)=0A= @@ -113,6 +113,9 @@=0A= #define LINUX_CLOCK_REALTIME_HR 4=0A= #define LINUX_CLOCK_MONOTONIC_HR 5=0A= =0A= +#define LINUX_UTIME_NOW 0x3FFFFFFF=0A= +#define LINUX_UTIME_OMIT 0x3FFFFFFE=0A= +=0A= extern int stclohz;=0A= =0A= #define __WCLONE 0x80000000=0A= Index: sys/i386/linux/linux_dummy.c=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= --- sys/i386/linux/linux_dummy.c (revision 277871)=0A= +++ sys/i386/linux/linux_dummy.c (working copy)=0A= @@ -107,7 +107,6 @@=0A= DUMMY(getcpu);=0A= DUMMY(epoll_pwait);=0A= /* linux 2.6.22: */=0A= -DUMMY(utimensat);=0A= DUMMY(signalfd);=0A= DUMMY(timerfd_create);=0A= DUMMY(eventfd);=0A= Index: sys/i386/linux/linux_proto.h=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= --- sys/i386/linux/linux_proto.h (revision 277871)=0A= +++ sys/i386/linux/linux_proto.h (working copy)=0A= @@ -1031,7 +1031,10 @@=0A= register_t dummy;=0A= };=0A= struct linux_utimensat_args {=0A= - register_t dummy;=0A= + char dfd_l_[PADL_(l_int)]; l_int dfd; char dfd_r_[PADR_(l_int)];=0A= + char pathname_l_[PADL_(const char *)]; const char * pathname; char = pathname_r_[PADR_(const char *)];=0A= + char times_l_[PADL_(const struct l_timespec *)]; const struct = l_timespec * times; char times_r_[PADR_(const struct l_timespec *)];=0A= + char flags_l_[PADL_(l_int)]; l_int flags; char flags_r_[PADR_(l_int)];=0A= };=0A= struct linux_signalfd_args {=0A= register_t dummy;=0A= @@ -1668,7 +1671,7 @@=0A= #define LINUX_SYS_AUE_linux_move_pages AUE_NULL=0A= #define LINUX_SYS_AUE_linux_getcpu AUE_NULL=0A= #define LINUX_SYS_AUE_linux_epoll_pwait AUE_NULL=0A= -#define LINUX_SYS_AUE_linux_utimensat AUE_NULL=0A= +#define LINUX_SYS_AUE_linux_utimensat AUE_FUTIMESAT=0A= #define LINUX_SYS_AUE_linux_signalfd AUE_NULL=0A= #define LINUX_SYS_AUE_linux_timerfd_create AUE_NULL=0A= #define LINUX_SYS_AUE_linux_eventfd AUE_NULL=0A= Index: sys/i386/linux/linux_sysent.c=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= --- sys/i386/linux/linux_sysent.c (revision 277871)=0A= +++ sys/i386/linux/linux_sysent.c (working copy)=0A= @@ -338,7 +338,7 @@=0A= { 0, (sy_call_t *)linux_move_pages, AUE_NULL, NULL, 0, 0, 0, = SY_THR_STATIC }, /* 317 =3D linux_move_pages */=0A= { 0, (sy_call_t *)linux_getcpu, AUE_NULL, NULL, 0, 0, 0, SY_THR_STATIC = }, /* 318 =3D linux_getcpu */=0A= { 0, (sy_call_t *)linux_epoll_pwait, AUE_NULL, NULL, 0, 0, 0, = SY_THR_STATIC }, /* 319 =3D linux_epoll_pwait */=0A= - { 0, (sy_call_t *)linux_utimensat, AUE_NULL, NULL, 0, 0, 0, = SY_THR_STATIC }, /* 320 =3D linux_utimensat */=0A= + { AS(linux_utimensat_args), (sy_call_t *)linux_utimensat, = AUE_FUTIMESAT, NULL, 0, 0, 0, SY_THR_STATIC }, /* 320 =3D = linux_utimensat */=0A= { 0, (sy_call_t *)linux_signalfd, AUE_NULL, NULL, 0, 0, 0, = SY_THR_STATIC }, /* 321 =3D linux_signalfd */=0A= { 0, (sy_call_t *)linux_timerfd_create, AUE_NULL, NULL, 0, 0, 0, = SY_THR_STATIC }, /* 322 =3D linux_timerfd_create */=0A= { 0, (sy_call_t *)linux_eventfd, AUE_NULL, NULL, 0, 0, 0, = SY_THR_STATIC }, /* 323 =3D linux_eventfd */=0A= Index: sys/i386/linux/linux_systrace_args.c=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= --- sys/i386/linux/linux_systrace_args.c (revision 277871)=0A= +++ sys/i386/linux/linux_systrace_args.c (working copy)=0A= @@ -2206,7 +2206,12 @@=0A= }=0A= /* linux_utimensat */=0A= case 320: {=0A= - *n_args =3D 0;=0A= + struct linux_utimensat_args *p =3D params;=0A= + iarg[0] =3D p->dfd; /* l_int */=0A= + uarg[1] =3D (intptr_t) p->pathname; /* const char * */=0A= + uarg[2] =3D (intptr_t) p->times; /* const struct l_timespec * */=0A= + iarg[3] =3D p->flags; /* l_int */=0A= + *n_args =3D 4;=0A= break;=0A= }=0A= /* linux_signalfd */=0A= @@ -5626,6 +5631,22 @@=0A= break;=0A= /* linux_utimensat */=0A= case 320:=0A= + switch(ndx) {=0A= + case 0:=0A= + p =3D "l_int";=0A= + break;=0A= + case 1:=0A= + p =3D "const char *";=0A= + break;=0A= + case 2:=0A= + p =3D "const struct l_timespec *";=0A= + break;=0A= + case 3:=0A= + p =3D "l_int";=0A= + break;=0A= + default:=0A= + break;=0A= + };=0A= break;=0A= /* linux_signalfd */=0A= case 321:=0A= @@ -6962,6 +6983,9 @@=0A= case 319:=0A= /* linux_utimensat */=0A= case 320:=0A= + if (ndx =3D=3D 0 || ndx =3D=3D 1)=0A= + p =3D "int";=0A= + break;=0A= /* linux_signalfd */=0A= case 321:=0A= /* linux_timerfd_create */=0A= Index: sys/i386/linux/syscalls.master=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= --- sys/i386/linux/syscalls.master (revision 277871)=0A= +++ sys/i386/linux/syscalls.master (working copy)=0A= @@ -532,7 +532,8 @@=0A= 318 AUE_NULL STD { int linux_getcpu(void); }=0A= 319 AUE_NULL STD { int linux_epoll_pwait(void); }=0A= ; linux 2.6.22:=0A= -320 AUE_NULL STD { int linux_utimensat(void); }=0A= +320 AUE_FUTIMESAT STD { int linux_utimensat(l_int dfd, const char = *pathname, \=0A= + const struct l_timespec *times, l_int flags); }=0A= 321 AUE_NULL STD { int linux_signalfd(void); }=0A= 322 AUE_NULL STD { int linux_timerfd_create(void); }=0A= 323 AUE_NULL STD { int linux_eventfd(void); }=0A= ------=_NextPart_000_0050_01D03D01.F2161720-- From owner-freebsd-arch@FreeBSD.ORG Sat Jan 31 12:58:36 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1FAFDD35 for ; Sat, 31 Jan 2015 12:58:36 +0000 (UTC) Received: from bigwig.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 EAFE298A for ; Sat, 31 Jan 2015 12:58:35 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-54-116-245.nwrknj.fios.verizon.net [173.54.116.245]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 6361AB94B; Sat, 31 Jan 2015 07:58:34 -0500 (EST) From: John Baldwin To: Warner Losh Subject: Re: Wrapper API for static bus_dma allocations Date: Sat, 31 Jan 2015 07:57:35 -0500 Message-ID: <1740117.2W2DTbza1h@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-STABLE; KDE/4.14.2; amd64; ; ) In-Reply-To: <21F3F28E-DAB8-4809-A9ED-1095F6BECCFC@bsdimp.com> References: <2800970.jY4xzTy9Hz@ralph.baldwin.cx> <1440008.gcoNUU8dV6@ralph.baldwin.cx> <21F3F28E-DAB8-4809-A9ED-1095F6BECCFC@bsdimp.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Sat, 31 Jan 2015 07:58:34 -0500 (EST) Cc: Konstantin Belousov , Poul-Henning Kamp , freebsd-arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jan 2015 12:58:36 -0000 On Friday, January 30, 2015 09:07:52 PM Warner Losh wrote: > > On Jan 30, 2015, at 2:31 PM, John Baldwin wrote: > >=20 > > On Friday, January 30, 2015 05:21:50 PM Konstantin Belousov wrote: > >> On Fri, Jan 30, 2015 at 09:56:31AM -0500, John Baldwin wrote: > >>> On 1/29/15 4:54 PM, Poul-Henning Kamp wrote: > >>>> -------- > >>>>=20 > >>>> In message <2800970.jY4xzTy9Hz@ralph.baldwin.cx>, John Baldwin w= rites: > >>>>> The bus_dma API to allocate a chunk of static DMA'able memory (= e.g. > >>>>> for > >>>>> descriptor rings) can be a bit obtuse [...] > >>>>=20 > >>>> Isn't it time we take a good hard stare at all of the bus_dma AP= I, > >>>> and refactor it into something a lot more compact ? > >>>=20 > >>> Given the amount of oddball hardware out there I don't think ther= e is a > >>> lot you can cut out. The filter function might be something we c= an lose > >>> (and losing it would simplify the implementation), but all the ot= her > >>> weird constraints are actually used by something AFAIK. I do thi= nk we > >>> can provide some simpler wrappers for some of the more common cas= es, but > >>> there will be some hardware for which those wrappers do not work.= > >>>=20 > >>> One suggestion Scott has had is to at least make it easier to ext= end the > >>> API by using getter/setter routines on the tag to work with tag > >>> attributes instead of passing them all in bus_dma_tag_create(). > >>=20 > >> BTW, filter function is useless. It can deny specific bus address= from > >> being used, but it does not provide the busdma implementation even= a hint > >> what other address should be (tried to) used. In dmar busdma, I s= imply > >> ignored it. And there is no real users of filter in the tree. > >=20 > > Yes, it is very annoying. I think some old ISA SCSI HBA driver mig= ht have > > used it to skip over some low-memory hole (i.e. there were two vali= d DMA > > ranges and this was the kludge instead of having two sets of > > lowaddr/highaddr exclusions). (That is one part of the API we coul= d > > rototill is to just remove the highaddr arg just use a single arg w= hich > > is effectively lowaddr. I think all drivers always set highaddr to= > > BUS_SPACE_MAXADDR.) >=20 > Not all. There=E2=80=99s some PCI cards that can=E2=80=99t do 64-bit = cycles that pass in the > 32-bit value on 64-bit systems. There=E2=80=99s 386 instances of this= in the tree. > But that may be lowaddr only. It=E2=80=99s hard to grep for this to b= e sure. That is lowaddr only, not the filter callback. However, even if we remove the filter and highaddr arguments from tags,= you=20 are still stuck with creating a tag, allocating memory, and loading it = to get=20 a bus address (and tracking the associated pointers, etc.). I still th= ink a=20 wrapper API for the common case (static DMA allocations) would be usefu= l. Orthogonally I can explore removing the filter along with highaddr (it = is=20 always BUS_SPACE_MAXADDR). --=20 John Baldwin From owner-freebsd-arch@FreeBSD.ORG Sat Jan 31 17:27:33 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5AD35683; Sat, 31 Jan 2015 17:27:33 +0000 (UTC) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0111.outbound.protection.outlook.com [157.56.110.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 476C7649; Sat, 31 Jan 2015 17:27:32 +0000 (UTC) Received: from BL2PR05CA0016.namprd05.prod.outlook.com (10.255.226.16) by BN1PR05MB440.namprd05.prod.outlook.com (10.141.58.26) with Microsoft SMTP Server (TLS) id 15.1.65.19; Sat, 31 Jan 2015 17:11:17 +0000 Received: from BY2FFO11FD041.protection.gbl (2a01:111:f400:7c0c::126) by BL2PR05CA0016.outlook.office365.com (2a01:111:e400:c04::16) with Microsoft SMTP Server (TLS) id 15.1.75.20 via Frontend Transport; Sat, 31 Jan 2015 17:11:17 +0000 Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by BY2FFO11FD041.mail.protection.outlook.com (10.1.14.226) with Microsoft SMTP Server (TLS) id 15.1.75.11 via Frontend Transport; Sat, 31 Jan 2015 17:11:17 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sat, 31 Jan 2015 09:11:17 -0800 Received: from chaos.jnpr.net (chaos.jnpr.net [172.21.16.28]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t0VHB4W37215; Sat, 31 Jan 2015 09:11:12 -0800 (PST) (envelope-from sjg@juniper.net) Received: from chaos (localhost [127.0.0.1]) by chaos.jnpr.net (Postfix) with ESMTP id 995CF580A3; Sat, 31 Jan 2015 09:11:04 -0800 (PST) To: Baptiste Daroussin Subject: Re: [RFC] Set the default locale to en_US.UTF-8 In-Reply-To: <20150125184914.GP81001@ivaldir.etoilebsd.net> References: <20150124143357.GI81001@ivaldir.etoilebsd.net> <20150125143243.GB76051@zxy.spb.ru> <7B1D8345-248B-4C44-9568-079BA29614C2@ixsystems.com> <23506.1422204612@critter.freebsd.dk> <20150125171042.GQ3698@zxy.spb.ru> <23185.1422208170@chaos> <20150125184914.GP81001@ivaldir.etoilebsd.net> Comments: In-reply-to: Baptiste Daroussin message dated "Sun, 25 Jan 2015 19:49:14 +0100." From: "Simon J. Gerraty" X-Mailer: MH-E 8.0.3; nmh 1.3; GNU Emacs 22.3.1 Date: Sat, 31 Jan 2015 09:11:04 -0800 Message-ID: <18360.1422724264@chaos> MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.16 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.16) smtp.mailfrom=sjg@juniper.net; freebsd.org; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:66.129.239.16; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(24454002)(33716001)(19580395003)(19580405001)(50986999)(6806004)(86362001)(62966003)(77156002)(87936001)(76176999)(57986006)(105596002)(117636001)(110136001)(106466001)(47776003)(92566002)(46102003)(93886004)(50466002)(77096005)(48376002)(76506005)(558084003)(50226001)(2950100001)(42262002)(62816006); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB440; H:P-EMF02-SAC.jnpr.net; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB440; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:BN1PR05MB440; X-Forefront-PRVS: 0473A03F3F X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB440; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Jan 2015 17:11:17.4008 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.16] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB440 Cc: arch@freebsd.org, Poul-Henning Kamp , Jordan Hubbard , Slawa Olhovchenkov X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jan 2015 17:27:33 -0000 Baptiste Daroussin wrote: > I can checkout FreeBSD's sources which contains UTF-8 files on a vanilla > freebsd aka locale being 'C'. Me too, I was refering to a different repo where we've seen the issue of checkouts failing due to UTF-8 as described.