From owner-freebsd-hackers@freebsd.org Sun Oct 30 03:30:00 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AB8EFC26CC2 for ; Sun, 30 Oct 2016 03:30:00 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 72B817F1 for ; Sun, 30 Oct 2016 03:30:00 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: by mail-yw0-x236.google.com with SMTP id w3so116319855ywg.1 for ; Sat, 29 Oct 2016 20:30:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=longcount-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SOwZ8tmU7Q5SeTTEdz7NM68EQqHQyo42RWOxmUwhAT8=; b=QJXGS47izuaYAIurnJxlJSXd/n4U9m0zbOwvFubxlOtiCjp1mKcbWNoIewnkACndPv r0XX8q9Nun3XVv5JqKuxMz5HcE2/o0yGbsbZtP9y5GiHJogqQf76VwLCm7A6JyDbMFmq PkPKO50fMf1JIhR+SzMZZyY7oNxoZk9eIqPIvu2eRjHbXtQ/+nCVxjANB76y3XpDcZ+f jp2gweToJHUwvuNSNQ6R/E1FQ5+EQzboK6a/ZnY+hSzzEnarEby4b2ue0/qfSPwWxLrX cKXUrLyV9o7fEriM71jM5GKtBIcW/XvCx1mcp97UVvxkWKgDkcBS19p13FOUqTDeMsLd ixHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SOwZ8tmU7Q5SeTTEdz7NM68EQqHQyo42RWOxmUwhAT8=; b=ZjF+5Bzub66pnHjc8Ll/+BttRFjSS8fr6Qwz+QHxM4JqHkFHcHTlN1R/Yyk7sUu67g veYlVq2e8lJNtJfAwAewCNZTD1PoiSh9QbcfiZfUstPFYOHkBz5KczkXpFcFhDjvPWxK 2bt1jVwEPT7lRWZWVrNfgXcREV7Q+O+YEKfmRLw568h0D+FJZZCVIQjkgVqhEFGtw3Hv I/Gg7W9l3eyby4SyyJeIB4kywDaHyU1WDJ6j0yY+b1ZKCuQt7m0CWRS5wXXWEezcgT64 ko2a392UimvPd9XEIPPBBP6fo8Nlt70bBnSz0L76qtCc+0Vqd1lpoE8LmRJAbQ5N9FiW xsBA== X-Gm-Message-State: ABUngveFLomyZO8c3c+ZaYLxJtS3d1XnMYQw7tg7872yE7a6DdpGNoPZoYA6QF92ZZ+Ze0EDH9VN0bwHzYdxJA== X-Received: by 10.13.194.197 with SMTP id e188mr17275629ywd.133.1477798199163; Sat, 29 Oct 2016 20:29:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.94.215 with HTTP; Sat, 29 Oct 2016 20:29:58 -0700 (PDT) X-Originating-IP: [24.44.110.108] In-Reply-To: <20161028211747.GU57714@zxy.spb.ru> References: <20161028211747.GU57714@zxy.spb.ru> From: Mark Saad Date: Sat, 29 Oct 2016 23:29:58 -0400 Message-ID: Subject: Re: lacp weirdness on 10.3-STABLE To: Slawa Olhovchenkov Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2016 03:30:00 -0000 On Fri, Oct 28, 2016 at 5:17 PM, Slawa Olhovchenkov wrote: > On Fri, Oct 28, 2016 at 05:14:37PM -0400, Mark Saad wrote: > > > Hi everyone > > I wast sure where to start on this one. So let me jump in here. > > I have a box with a dual port solarflare card. Both ports were running in > > lacp > > lagg for a while with out any issues. I took the box down free up some > > space in the rack. I reciently > > booted it back up; using the original network ports and cables from the > > original seutp. However I can not bring up the lagg in lacp mode. > Trussing > > the process is showing this > > > > n01:~ # ifconfig lagg0 up lacp > > ifconfig: lacp: bad value > > > ifconfig lagg0 up laggproto lacp > > This is what happenes when I get overly tired. Thank you for pointing out that I was missing laggproto . All is well again. > > n01:~ # truss ifconfig lagg0 up lacp > > ..... > > read(4,"# $FreeBSD: stable/10/etc/networ"...,4096) = 368 (0x170) > > read(4,0x801c47000,4096) = 0 (0x0) > > close(4) = 0 (0x0) > > ifconfig: write(2,"ifconfig: ",10) = 10 (0xa) > > lacp: bad valuewrite(2,"lacp: bad value",15) = 15 > (0xf) > > .... > > > > I am at a loss. The Switch ports are in the original configs as well. > > Anyone have any ideas ? > > Kernel and Userland are FreeBSD 10.3-STABLE #0: Tue Aug 23 14:48:27 EDT > > 2016 > > > > > > -- > > mark saad | nonesuch@longcount.org > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@ > freebsd.org" > -- mark saad | nonesuch@longcount.org From owner-freebsd-hackers@freebsd.org Mon Oct 31 18:11:00 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 44868C16A98 for ; Mon, 31 Oct 2016 18:11:00 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 107BB1ABD; Mon, 31 Oct 2016 18:11:00 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-pf0-x22e.google.com with SMTP id d2so5337498pfd.0; Mon, 31 Oct 2016 11:11:00 -0700 (PDT) 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-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=4Kkwknp2SqMXfmu0LrLf2PKTkALmF8V20p/8d1fsOPQ=; b=nkr9NQl3jEdkTc6Mbh58Bg686lvI1TANw4OzT8mUXwrgLvHd7JV5hOkNwAouyiq/Fa WETVwFz32B6swLql38xsP+Cd12HAiwMzULYDZQflAHojp0PH8p/NKMp885iwKVHySb/5 /goY43XjWIs/ak5kOIpGN/XkZxgEEQMprRF34Du7wefDZ2428uE0hlsgQkQtIhi56vyA 9zIMG3GVxSfZtG5KCf2+MN06TJI/pL33GLrQQotuWXu6jpawOH4XbF+7jzlYgsu4Nv5D Z01oMkABPh2yIFxxKdec0vj6F8muHVcf3YqdxKTuF1TXNi09uGiZ3LvjJhOGyLRlvgrt 5yGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=4Kkwknp2SqMXfmu0LrLf2PKTkALmF8V20p/8d1fsOPQ=; b=aDRdaQXVLSdo9ivjIEHNs7kzajFI7l1kKZLkkz0/izU5XMgaIpiKPBPhBWJN0VEhBo 9Lzh1npzGhNb+57MHrMHm2pAq1QKX1DBiJvIEHAFb4lCMd3Ejgq0s7SslIdV4hDuZyz6 J2pTSWnCqLEVfzNJb23idKxlYG3kHeVjPMFJlnQB8nJIx9+e7x8S3Pcr37PyshTbzMiA 44UEEZb4IKQ66oLpeV+pRiKbMgjsK1OjBCwCkymRVyWmZ577I4k2K591F4DzgDmqO4m/ lGHKLocjuDD7opwOQs/7dZeIu1vSKJz5gtZUC56knSObqEnwxtZpc/SdxFSLfehJS5ok inaQ== X-Gm-Message-State: ABUngvdf+yVfs7KK8qXgxxxyp1lCxHGv/LcmeHgkzhhThJJgYx2EMYvXoXkQ5PC/ormZkA== X-Received: by 10.98.211.24 with SMTP id q24mr51503524pfg.69.1477937459375; Mon, 31 Oct 2016 11:10:59 -0700 (PDT) Received: from wkstn-mjohnston.west.isilon.com (c-76-104-201-218.hsd1.wa.comcast.net. [76.104.201.218]) by smtp.gmail.com with ESMTPSA id t5sm37006750pfb.58.2016.10.31.11.10.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 31 Oct 2016 11:10:58 -0700 (PDT) Sender: Mark Johnston Date: Mon, 31 Oct 2016 11:16:57 -0700 From: Mark Johnston To: =?iso-8859-1?Q?Jean-S=E9bastien_P=E9dron?= Cc: "freebsd-hackers@freebsd.org" Subject: Re: Linux' struct address_space & FreeBSD's vm_object Message-ID: <20161031181657.GB92661@wkstn-mjohnston.west.isilon.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 18:11:00 -0000 On Sat, Oct 29, 2016 at 11:37:13PM +0200, Jean-Sébastien Pédron wrote: > Hi! > > I'm tracking a memory leak in the drm-next-4.7 branch [1]. I found the > issue, however, I'm unsure of the solution for now. Let me sum up what I > understand (or what I think I understand :): > > In Linux, they use a `struct vm_area_struct` to represent a mapping of > an object. It holds the callback functions (open, close and fault) of > the device driver and the private data to be used with those callbacks. > > All `struct vm_area_struct` are stored in a tree in another structure > called `struct address_space` which belongs to the owner of the resource > (an inode in the case of DRM). This structure holds references to pages > loaded from the inode, so it acts as a page cache. > > So: > struct inode > `-- struct address_space > |-- tree of pages > `-- tree of struct vm_area_struct > > In DRM, there is a `struct vm_area_struct` for each mapping of each > graphics object. But those mapping are all stored in the same `struct > address_space` belonging to an "anonymous inode" attached to the device. > Furthermore, a DRM driver creates three character devices in /dev for > each real device, and all three character devices use this same > anonymous inode. > > Therefore, if I understand correctly, all mappings for all three > character devices use the same list of pages. Thus the memory is shared. > > In DRM, when a mapping must be released, eg. i915_gem_release_mmap() > indirectly calls unmap_mapping_range() with the anonymous inode's > `struct address_space`. This function removes all mappings of a given > graphics object, thus removes all `struct vm_area_struct` from `struct > address` which are covered by the specified range. > > Currently, on FreeBSD, `struct address_space` is replaced by the > vm_object returned by cdev_pager_allocate(). The first issue is that we > never create the equivalent of `struct address_space` for the global > anonymous inode. Therefore the code responsible for removing mappings > does nothing and mappings & pages are leaked. Anyway, the d_mmap_single > implementation doesn't even try to fill the equivalent of `struct > address_space`. > > So that's my understanding of the issue. First, I'm not 100% sure of > what I described and second, I don't see how to implement the same > shared page cache in FreeBSD because a device pager vm_object can't be > shared by multiple mappings (or can it?). I don't see a reason that an OBJT_MGTDEVICE object can't be mapped into multiple address spaces. Am I missing something? I'm wondering if linux_dev_mmap_single() could give individual drivers a chance to return an object via the mmap method in struct file_operations, and only fall back to allocating an OBJT_SG object in the default case. Then the code for the three cdevs could be made to return the same OBJT_MGTDEVICE object, rather than the situation today where linux_dev_mmap_single() itself allocates objects for each cdev. From owner-freebsd-hackers@freebsd.org Mon Oct 31 22:10:12 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 824A0C2899E for ; Mon, 31 Oct 2016 22:10:12 +0000 (UTC) (envelope-from badger@FreeBSD.org) Received: from sasl.smtp.pobox.com (pb-smtp1.pobox.com [64.147.108.70]) (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 535AB175B for ; Mon, 31 Oct 2016 22:10:11 +0000 (UTC) (envelope-from badger@FreeBSD.org) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id E918A4AE05 for ; Mon, 31 Oct 2016 18:07:47 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:subject :to:message-id:date:mime-version:content-type; s=sasl; bh=cRDjPt mrXEAIb3qVkQApRB+HQTg=; b=fydWrCEL3svaaRkIXxBgXcU6ZyssVm8sWgNnIz X3nT74+PkBf/LPunTrhAMHl1pFYuCTaHpCUoWlxM/t/b97efFNPtgoXZd+K2QCio 36Sv/5lE4780foxHQAfhu8Y2UppMlkBvfgJGwCXq0e2Pi+pbTdfQzo6Z1FNTG/2i 9ejVQ= Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id E13314AE04 for ; Mon, 31 Oct 2016 18:07:47 -0400 (EDT) Received: from [172.31.100.239] (unknown [76.164.8.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id 772124AE03 for ; Mon, 31 Oct 2016 18:07:43 -0400 (EDT) From: Eric Badger Subject: Crashes with 'reboot -d' To: freebsd-hackers@freebsd.org Message-ID: Date: Mon, 31 Oct 2016 17:07:25 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Xox9P59LvAhc1C3GBVWmiiPqhNNbAxATi" X-Pobox-Relay-ID: 7281AA46-9FB6-11E6-B7B3-987C12518317-46178211!pb-smtp1.pobox.com X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 22:10:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Xox9P59LvAhc1C3GBVWmiiPqhNNbAxATi Content-Type: multipart/mixed; boundary="WEJPSSThNMXMKeKlUmh1E0a988bRNENDT"; protected-headers="v1" From: Eric Badger To: freebsd-hackers@freebsd.org Message-ID: Subject: Crashes with 'reboot -d' --WEJPSSThNMXMKeKlUmh1E0a988bRNENDT Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I've run into crashes when using 'reboot -d' (or a slightly tweaked version of it in our FreeBSD spin at work). The problem is that dump code is written to run in a panic/crash scenario, when all other CPUs are stopped. In the case of 'reboot -d', all other CPUs are not stopped. The code in xpt_polled_action runs what would normally be done by the interrupt handler, polling start_ccb->ccb_h.status to see when the operation has been completed. If the real interrupt handler is still running, however, polling start_ccb->ccb_h.status is not sufficient; the ccb may be placed in the cam kproc's doneq after start_ccb->ccb_h.status has been updated. The dumper will reuse the ccb's memory, but when the cam kproc processes that item in its doneq, it will twiddle bits and corrupt the now reused ccb memory. I fixed this by shutting off other CPUs when doing a dump during reboot (patch below). This seems fine, but perhaps heavy handed. I also experimented with letting the normal interrupt handler and cam kproc do the work when we're not in a SCHEDULER_STOPPED() scenario. This seemed to reduce dump performance and make performance less consistent, but otherwise worked ok. I'd appreciate any comments on things I may have failed to consider. If no objections are raised, I will proceed with the patch here. Thanks, Eric diff --git a/sys/kern/kern_shutdown.c b/sys/kern/kern_shutdown.c index 79c4c30..bdc0182 100644 --- a/sys/kern/kern_shutdown.c +++ b/sys/kern/kern_shutdown.c @@ -319,8 +319,9 @@ void kern_reboot(int howto) { static int once =3D 0; +#ifdef SMP + cpuset_t other_cpus; -#if defined(SMP) /* * Bind us to CPU 0 so that all shutdown code runs there. Some * systems don't shutdown properly (i.e., ACPI power off) if we @@ -362,8 +363,28 @@ kern_reboot(int howto) */ EVENTHANDLER_INVOKE(shutdown_post_sync, howto); - if ((howto & (RB_HALT|RB_DUMP)) =3D=3D RB_DUMP && !cold && !dumping) + if ((howto & (RB_HALT|RB_DUMP)) =3D=3D RB_DUMP && !cold && !dumping) { +#ifdef SMP + /* + * Dump code assumes that all other CPUs have stopped, and thus + * handles disk interrupts manually. This assumption must be enforced, + * as otherwise the real interrupt handler may race with the dumper. + */ + if (!SCHEDULER_STOPPED()) { + spinlock_enter(); + + other_cpus =3D all_cpus; + CPU_CLR(PCPU_GET(cpuid), &other_cpus); + stop_cpus_hard(other_cpus); + + curthread->td_stopsched =3D 1; + + /* Module shutdown is no longer safe. */ + howto |=3D RB_NOSYNC; + } +#endif doadump(TRUE); + } /* Now that we're going to really halt the system... */ EVENTHANDLER_INVOKE(shutdown_final, howto); --WEJPSSThNMXMKeKlUmh1E0a988bRNENDT-- --Xox9P59LvAhc1C3GBVWmiiPqhNNbAxATi Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQGQBAEBCgB6BQJYF8CmXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzQTlFODAxM0JDQTdDOTQ1ODI1Mzc3NTk2 MkU1MDA5NjVBM0YyNEFDExxiYWRnZXJAZnJlZWJzZC5vcmcACgkQYuUAllo/JKyk fwgA3Bq+vMAeSVV/Wqbw03yWnH0EUJ3uvc9HkrJX9yFiiHtHO0CyLNJZw8+qnyFQ V/IRBePEUebCDAVrCzlp5493ZERdqSkOwLehXeaaLJ2e02Uo5WbQIn5/7+1Lw/u9 1u0iDMPLFVaxWlSXRGNmmg2NHXXfI2lITzNl5xUcu1GwH6cNrIgSNRMGUhrDumlH HJZopA1C6+Durn93Au5jtFd2kKxsEI1wbpKBdK4qpkM34fkMugE6rha8ZcZkX0xF aghiywSvRT4ylPeDh86i8yUkC5rHNfrLAuKNfyQ6OatVDnrXQCApGZ9mz/4JMC+U lYfrdKuQvHIbydvI9j5syQ+rMQ== =Fx5o -----END PGP SIGNATURE----- --Xox9P59LvAhc1C3GBVWmiiPqhNNbAxATi-- From owner-freebsd-hackers@freebsd.org Tue Nov 1 10:53:41 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 690E5C28D32 for ; Tue, 1 Nov 2016 10:53:41 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 300111E51 for ; Tue, 1 Nov 2016 10:53:40 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-232-92.lns20.per1.internode.on.net [121.45.232.92]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id uA1ArUmM045031 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Tue, 1 Nov 2016 03:53:33 -0700 (PDT) (envelope-from julian@freebsd.org) To: freebsd From: Julian Elischer Subject: how to reduce the size of /usr/share/i18n data? Message-ID: <7b036323-aa77-6d41-36b0-439a12a36524@freebsd.org> Date: Tue, 1 Nov 2016 18:53:24 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 10:53:41 -0000 there are a number of packages that want to link with or use that data, and you can't always disable it, but it's very very big (38MB?), especially in the context of an appliance that doesn't really need it at all. If anyone has a procedure to follow to put that onto a diet, maybe just as a stub then I'm all ears. Julian From owner-freebsd-hackers@freebsd.org Tue Nov 1 10:59:09 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8CB45C28E7E for ; Tue, 1 Nov 2016 10:59:09 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1CDD4131E; Tue, 1 Nov 2016 10:59:08 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221]) by hz.grosbein.net (8.14.9/8.14.9) with ESMTP id uA1Ax3QX049994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 1 Nov 2016 11:59:04 +0100 (CET) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: julian@freebsd.org Received: from [10.58.0.10] (dadv@dadvw [10.58.0.10]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id uA1AwxFL006726 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 1 Nov 2016 17:59:00 +0700 (KRAT) (envelope-from eugen@grosbein.net) Subject: Re: how to reduce the size of /usr/share/i18n data? To: Julian Elischer , freebsd References: <7b036323-aa77-6d41-36b0-439a12a36524@freebsd.org> From: Eugene Grosbein Message-ID: <58187573.7020402@grosbein.net> Date: Tue, 1 Nov 2016 17:58:59 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <7b036323-aa77-6d41-36b0-439a12a36524@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM autolearn=no version=3.3.2 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hz.grosbein.net X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 10:59:09 -0000 01.11.2016 17:53, Julian Elischer пишет: > there are a number of packages that want to link with or use that data, and you can't always disable it, but it's very very big (38MB?), especially in the context of an appliance that doesn't really need it at all. > > > If anyone has a procedure to follow to put that onto a diet, maybe just as a stub then I'm all ears. +1 Introduction of such large part of base system is kind of catastrophe for embedded systems that need only ASCII and may be additionally one of "good old" 8-bit locales. FreeBSD 11 got pretty large and embedded-unfriendly without clear way to exclude such unneeded parts. From owner-freebsd-hackers@freebsd.org Tue Nov 1 11:06:43 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 507E7C290D4 for ; Tue, 1 Nov 2016 11:06:43 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2E8D41BE2 for ; Tue, 1 Nov 2016 11:06:42 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-232-92.lns20.per1.internode.on.net [121.45.232.92]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id uA1B6bjv045238 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 1 Nov 2016 04:06:40 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: how to reduce the size of /usr/share/i18n data? To: Eugene Grosbein , freebsd References: <7b036323-aa77-6d41-36b0-439a12a36524@freebsd.org> <58187573.7020402@grosbein.net> From: Julian Elischer Message-ID: Date: Tue, 1 Nov 2016 19:06:32 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <58187573.7020402@grosbein.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 11:06:43 -0000 On 1/11/2016 6:58 PM, Eugene Grosbein wrote: > 01.11.2016 17:53, Julian Elischer пишет: >> there are a number of packages that want to link with or use that >> data, and you can't always disable it, but it's very very big >> (38MB?), especially in the context of an appliance that doesn't >> really need it at all. >> >> >> If anyone has a procedure to follow to put that onto a diet, maybe >> just as a stub then I'm all ears. > > +1 > > Introduction of such large part of base system is kind of > catastrophe for embedded systems > that need only ASCII and may be additionally one of "good old" 8-bit > locales. > > FreeBSD 11 got pretty large and embedded-unfriendly without clear > way to exclude such unneeded parts. > > it's already bloating out 10.3 From owner-freebsd-hackers@freebsd.org Tue Nov 1 12:40:38 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 44747C23641 for ; Tue, 1 Nov 2016 12:40:38 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::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 CA1DB171D; Tue, 1 Nov 2016 12:40:37 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id uA1CeUAD063378 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 1 Nov 2016 14:40:31 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua uA1CeUAD063378 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id uA1CeU7q063376; Tue, 1 Nov 2016 14:40:30 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 1 Nov 2016 14:40:30 +0200 From: Konstantin Belousov To: Eric Badger Cc: freebsd-hackers@freebsd.org Subject: Re: Crashes with 'reboot -d' Message-ID: <20161101124030.GC54029@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 12:40:38 -0000 On Mon, Oct 31, 2016 at 05:07:25PM -0500, Eric Badger wrote: > I've run into crashes when using 'reboot -d' (or a slightly tweaked > version of it in our FreeBSD spin at work). The problem is that dump > code is written to run in a panic/crash scenario, when all other CPUs > are stopped. In the case of 'reboot -d', all other CPUs are not stopped. > The code in xpt_polled_action runs what would normally be done by the > interrupt handler, polling start_ccb->ccb_h.status to see when the > operation has been completed. If the real interrupt handler is still > running, however, polling start_ccb->ccb_h.status is not sufficient; the > ccb may be placed in the cam kproc's doneq after start_ccb->ccb_h.status > has been updated. The dumper will reuse the ccb's memory, but when the > cam kproc processes that item in its doneq, it will twiddle bits and > corrupt the now reused ccb memory. > > I fixed this by shutting off other CPUs when doing a dump during reboot > (patch below). This seems fine, but perhaps heavy handed. I also > experimented with letting the normal interrupt handler and cam kproc do > the work when we're not in a SCHEDULER_STOPPED() scenario. This seemed > to reduce dump performance and make performance less consistent, but > otherwise worked ok. > > I'd appreciate any comments on things I may have failed to consider. If > no objections are raised, I will proceed with the patch here. > > Thanks, > Eric > > diff --git a/sys/kern/kern_shutdown.c b/sys/kern/kern_shutdown.c > index 79c4c30..bdc0182 100644 > --- a/sys/kern/kern_shutdown.c > +++ b/sys/kern/kern_shutdown.c > @@ -319,8 +319,9 @@ void > kern_reboot(int howto) > { > static int once = 0; > +#ifdef SMP > + cpuset_t other_cpus; > > -#if defined(SMP) > /* > * Bind us to CPU 0 so that all shutdown code runs there. Some > * systems don't shutdown properly (i.e., ACPI power off) if we > @@ -362,8 +363,28 @@ kern_reboot(int howto) > */ > EVENTHANDLER_INVOKE(shutdown_post_sync, howto); > > - if ((howto & (RB_HALT|RB_DUMP)) == RB_DUMP && !cold && !dumping) > + if ((howto & (RB_HALT|RB_DUMP)) == RB_DUMP && !cold && !dumping) { > +#ifdef SMP > + /* > + * Dump code assumes that all other CPUs have stopped, and thus > + * handles disk interrupts manually. This assumption must be enforced, > + * as otherwise the real interrupt handler may race with the dumper. > + */ > + if (!SCHEDULER_STOPPED()) { > + spinlock_enter(); > + > + other_cpus = all_cpus; > + CPU_CLR(PCPU_GET(cpuid), &other_cpus); > + stop_cpus_hard(other_cpus); > + > + curthread->td_stopsched = 1; > + > + /* Module shutdown is no longer safe. */ > + howto |= RB_NOSYNC; > + } > +#endif > doadump(TRUE); > + } > > /* Now that we're going to really halt the system... */ > EVENTHANDLER_INVOKE(shutdown_final, howto); > > Such stop heavily relies on the fact that other CPUs do not perform any cam-related activity in parallel. It might be not true, e.g. if some notifications are supplied by an HBA to OS. Also, other CPUs might own some resources which are needed by the io subsystem still, e.g. busdma or vm locks. This would reduce the probability of working dump. Could the dumper ccb marked by some flag to prevent doneq from freeing or modifying the memory and to keep the dumper using it ? From owner-freebsd-hackers@freebsd.org Tue Nov 1 22:49:47 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 89D4DC2AF04 for ; Tue, 1 Nov 2016 22:49:47 +0000 (UTC) (envelope-from badger@FreeBSD.org) Received: from sasl.smtp.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (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 2F4A21DEF for ; Tue, 1 Nov 2016 22:49:46 +0000 (UTC) (envelope-from badger@FreeBSD.org) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 3DC194B0E3; Tue, 1 Nov 2016 18:49:39 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=subject:to :references:cc:from:message-id:date:mime-version:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=Pm8jcaZUVDO/ qOi741DnlfzYWRY=; b=pSBZ+bcdYdZLAiZYHuYgVGk1qVV96kDVdgIPdx9c52/e L+yXJyDR/KDiosKKvLuGKJTuvHkdSZwe4+ePRO0QvNm2MAFw1gbqU1DHbgPcmv74 e6yeugVU4tqRtDAPBIDYUErBJoE+eWoc50J+o3sQn6vzvXx1AHGAp65cy+Ft7x0= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 354454B0E2; Tue, 1 Nov 2016 18:49:39 -0400 (EDT) Received: from [172.31.100.239] (unknown [76.164.8.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id 83A614B0E1; Tue, 1 Nov 2016 18:49:38 -0400 (EDT) Subject: Re: Crashes with 'reboot -d' To: Konstantin Belousov References: <20161101124030.GC54029@kib.kiev.ua> Cc: freebsd-hackers@freebsd.org From: Eric Badger Message-ID: <5580d308-3e10-76b8-c762-63a69ff2eadb@FreeBSD.org> Date: Tue, 1 Nov 2016 17:49:37 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20161101124030.GC54029@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252 X-Pobox-Relay-ID: 7806BFC2-A085-11E6-B860-3AB77A1B28F4-46178211!pb-smtp2.pobox.com Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 22:49:47 -0000 On 11/01/2016 07:40, Konstantin Belousov wrote: > On Mon, Oct 31, 2016 at 05:07:25PM -0500, Eric Badger wrote: >> I've run into crashes when using 'reboot -d' (or a slightly tweaked >> version of it in our FreeBSD spin at work). The problem is that dump >> code is written to run in a panic/crash scenario, when all other CPUs >> are stopped. In the case of 'reboot -d', all other CPUs are not stoppe= d. >> The code in xpt_polled_action runs what would normally be done by the >> interrupt handler, polling start_ccb->ccb_h.status to see when the >> operation has been completed. If the real interrupt handler is still >> running, however, polling start_ccb->ccb_h.status is not sufficient; t= he >> ccb may be placed in the cam kproc's doneq after start_ccb->ccb_h.stat= us >> has been updated. The dumper will reuse the ccb's memory, but when the >> cam kproc processes that item in its doneq, it will twiddle bits and >> corrupt the now reused ccb memory. >> >> I fixed this by shutting off other CPUs when doing a dump during reboo= t >> (patch below). This seems fine, but perhaps heavy handed. I also >> experimented with letting the normal interrupt handler and cam kproc d= o >> the work when we're not in a SCHEDULER_STOPPED() scenario. This seemed >> to reduce dump performance and make performance less consistent, but >> otherwise worked ok. >> >> I'd appreciate any comments on things I may have failed to consider. I= f >> no objections are raised, I will proceed with the patch here. >> >> Thanks, >> Eric >> >> diff --git a/sys/kern/kern_shutdown.c b/sys/kern/kern_shutdown.c >> index 79c4c30..bdc0182 100644 >> --- a/sys/kern/kern_shutdown.c >> +++ b/sys/kern/kern_shutdown.c >> @@ -319,8 +319,9 @@ void >> kern_reboot(int howto) >> { >> static int once =3D 0; >> +#ifdef SMP >> + cpuset_t other_cpus; >> >> -#if defined(SMP) >> /* >> * Bind us to CPU 0 so that all shutdown code runs there. Som= e >> * systems don't shutdown properly (i.e., ACPI power off) if w= e >> @@ -362,8 +363,28 @@ kern_reboot(int howto) >> */ >> EVENTHANDLER_INVOKE(shutdown_post_sync, howto); >> >> - if ((howto & (RB_HALT|RB_DUMP)) =3D=3D RB_DUMP && !cold && !dumpin= g) >> + if ((howto & (RB_HALT|RB_DUMP)) =3D=3D RB_DUMP && !cold && !dumping)= { >> +#ifdef SMP >> + /* >> + * Dump code assumes that all other CPUs have stopped, and thus >> + * handles disk interrupts manually. This assumption must be enforce= d, >> + * as otherwise the real interrupt handler may race with the dumper. >> + */ >> + if (!SCHEDULER_STOPPED()) { >> + spinlock_enter(); >> + >> + other_cpus =3D all_cpus; >> + CPU_CLR(PCPU_GET(cpuid), &other_cpus); >> + stop_cpus_hard(other_cpus); >> + >> + curthread->td_stopsched =3D 1; >> + >> + /* Module shutdown is no longer safe. */ >> + howto |=3D RB_NOSYNC; >> + } >> +#endif >> doadump(TRUE); >> + } >> >> /* Now that we're going to really halt the system... */ >> EVENTHANDLER_INVOKE(shutdown_final, howto); >> >> >=20 > Such stop heavily relies on the fact that other CPUs do not perform any > cam-related activity in parallel. It might be not true, e.g. if some > notifications are supplied by an HBA to OS. Also, other CPUs might > own some resources which are needed by the io subsystem still, e.g. > busdma or vm locks. This would reduce the probability of working dump. My confidence that stopping CPUs was ok was bolstered because this is the same path taken during a panic, when all CPUs have similarly been stopped. In such a case, I would also expect us to bypass locking, and the dump code itself is written to work without interrupts enabled. However, I haven't examined all the various drivers' dump code; there certainly could be some drivers that won't work after CPUs have been stopped but would if they hadn't been stopped. >=20 > Could the dumper ccb marked by some flag to prevent doneq from freeing > or modifying the memory and to keep the dumper using it ? >=20 You could do this. Practically, it avoids my problem on the system where I see it most. However, the other issue is that the 'sim_poll' implementations of some drivers don't appear safe to run when the interrupt handler is also up and running. One or the other would need to be stopped, or the drivers would need to be changed so that both can safely be running at the same time. I experimented a little bit here (stopping sim_poll when SCHEDULER_STOPPED()), but perhaps could find a more correct solution. Thanks, Eric From owner-freebsd-hackers@freebsd.org Wed Nov 2 09:26:44 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 44BD8C2B9FB for ; Wed, 2 Nov 2016 09:26:44 +0000 (UTC) (envelope-from point-of-entry@outlook.com) Received: from SNT004-OMC3S36.hotmail.com (snt004-omc3s36.hotmail.com [65.55.90.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "*.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CE56F171D for ; Wed, 2 Nov 2016 09:26:43 +0000 (UTC) (envelope-from point-of-entry@outlook.com) Received: from EUR01-HE1-obe.outbound.protection.outlook.com ([65.55.90.135]) by SNT004-OMC3S36.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Wed, 2 Nov 2016 02:25:37 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=P8Nzw1mhUSn4ORavr7Ad4W7qranHS15w+SwGRYvQESc=; b=M5YNeZ3j+MIJxqXar5CkhRlEyMzI8GAaox9yFMe241ug7DRTpLIqek3xlEMqB8/JIsDFgLkh/VcQwedkZZoBXWwiVImSe4yprSfY8JjL3mRe0tq6agQrnZF+FpBrF1U58D2n8s8Hem8g/KpNOWzp2PCcwSS2m8eG22lgDdSnemu6DcfeLEVG+TdB69QKme3baQJghiLCQbIzgUt6x9mVl2ivCjkKa2gyACCipLu0ge4WdknpSoKBONDul6VpKATYS5tW53NW0xE03nsfEVyPadwGLQ4+ZM0uT5X1USB1Q3s82CEA01dzohrZVhu/OF+e2Zz2+ILFHk6hFVHFd/rEKQ== Received: from HE1EUR01FT060.eop-EUR01.prod.protection.outlook.com (10.152.0.53) by HE1EUR01HT091.eop-EUR01.prod.protection.outlook.com (10.152.0.213) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.693.6; Wed, 2 Nov 2016 09:25:36 +0000 Received: from DB5PR09MB0216.eurprd09.prod.outlook.com (10.152.0.53) by HE1EUR01FT060.mail.protection.outlook.com (10.152.0.249) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.693.6 via Frontend Transport; Wed, 2 Nov 2016 09:25:36 +0000 Received: from DB5PR09MB0216.eurprd09.prod.outlook.com ([10.161.242.151]) by DB5PR09MB0216.eurprd09.prod.outlook.com ([10.161.242.151]) with mapi id 15.01.0693.009; Wed, 2 Nov 2016 09:25:36 +0000 From: Klaus Kaisersberger To: "freebsd-hackers@freebsd.org" Subject: Odd copyright within /etc/rc.d/hostid in FreeBSD 11.0 Thread-Topic: Odd copyright within /etc/rc.d/hostid in FreeBSD 11.0 Thread-Index: AQHSNOsNbYwekmOzJkGzVQeUKQF+dQ== Date: Wed, 2 Nov 2016 09:25:36 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=none action=none header.from=outlook.com; x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [BLZ86ZBYKAt6l5oizst8cl738YBxrjro] x-eopattributedmessage: 0 x-microsoft-exchange-diagnostics: 1; HE1EUR01HT091; 7:sBUAAaVazWXqgwzpgOwLie4Gdh967xf7F1yNcab43KNmIiPSvYukNRfEeJaTBUSMWZt8jjc1TEAD6h0/dHm9jEo6Ctz4bSSoapQB9qeoDS8yuUpPtlWo4rqf+FtE797i32oFfPBucNkuiF04mrI9ZUeq4SVZYCul7MuI2ztPp2V9smi8NAlIpwwZmX/2e73a+Vqafyk6M6vRsMAvUVWQgndngDDdLW7PJHRSjViWMxDaUiHI6NwAjCdc/UvmE/MXNAZ8sVk0lY2lxFXWK8NFUdWH9YLiQOKM3kurlMT2umbJJaXZDJi6yy+kaMcHGbngRZXyU0a0gDHBSYvgnXR4QptswisZ1rB0C+46QULJNV4= x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(10019020)(98900003); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1EUR01HT091; H:DB5PR09MB0216.eurprd09.prod.outlook.com; FPR:; SPF:None; LANG:en; x-ms-office365-filtering-correlation-id: 8b494454-3aae-45e4-cbea-08d40302344d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(1601124038)(1603103081)(1601125047); SRVR:HE1EUR01HT091; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(432015012)(82015046); SRVR:HE1EUR01HT091; BCL:0; PCL:0; RULEID:; SRVR:HE1EUR01HT091; x-forefront-prvs: 0114FF88F6 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Nov 2016 09:25:36.6834 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1EUR01HT091 X-OriginalArrivalTime: 02 Nov 2016 09:25:37.0824 (UTC) FILETIME=[126CBA00:01D234EB] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 09:26:44 -0000 =20 Is this line supposed to be at the very top of /etc/rc.d/hostid? =A0 # Copyright (c) 2015 Xin LI delphij@FreeBSD.org =A0 It does not match FreeBSD=92s usual means of indicating copyright. =A0 Kind regards -Klaus = From owner-freebsd-hackers@freebsd.org Thu Nov 3 07:48:21 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5FCF5C2D51A; Thu, 3 Nov 2016 07:48:21 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D52D22000; Thu, 3 Nov 2016 07:48:20 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-232-92.lns20.per1.internode.on.net [121.45.232.92]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id uA37mFIr057517 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 3 Nov 2016 00:48:18 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: Fwd: Re: how to reduce the size of /usr/share/i18n data? To: freebsd-current , freebsd References: <58187573.7020402@grosbein.net> From: Julian Elischer Message-ID: Date: Thu, 3 Nov 2016 15:48:09 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 07:48:21 -0000 So I am to take it that no-one has any idea how this stuff works and how to stub it out? On 1/11/2016 7:11 PM, Julian Elischer wrote: > > 01.11.2016 17:53, Julian Elischer пишет: >> there are a number of packages that want to link with or use that >> data, and you can't always disable it, but it's very very big >> (38MB?), especially in the context of an appliance that doesn't >> really need it at all. >> >> >> If anyone has a procedure to follow to put that onto a diet, maybe >> just as a stub then I'm all ears. > > +1 > > Introduction of such large part of base system is kind of > catastrophe for embedded systems > that need only ASCII and may be additionally one of "good old" 8-bit > locales. > > FreeBSD 11 got pretty large and embedded-unfriendly without clear > way to exclude such unneeded parts. > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" > > From owner-freebsd-hackers@freebsd.org Thu Nov 3 10:46:42 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 95759C2D8F8 for ; Thu, 3 Nov 2016 10:46:42 +0000 (UTC) (envelope-from mark@heily.com) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DB31F10B0 for ; Thu, 3 Nov 2016 10:46:41 +0000 (UTC) (envelope-from mark@heily.com) Received: by mail-qt0-x22b.google.com with SMTP id c47so25296015qtc.2 for ; Thu, 03 Nov 2016 03:46:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heily-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hYlmHiW8Mf23w6tJ683fT75hrdHFAma9oRkAvVJ4teg=; b=beiZ+B/I8yrn5GP9C4jBDe5XBvfWMw6f0YI4sbp9E17uY1zZMTAC7wiH6wOvIb14wj eyNkjiv4fgW9AKKgn+MkLFBbx2GZVjshORQIMZ75yK1sO76nmMkSkcN5XGqzYl/pKfnd PjMSZeXK3AhrqSTh1jPTxJonzmv2f3czjB8GvTDnFl/uNdWFUeZOmJjNHYMDnrEHG6oo el7pFDxxTGm2Tb2xrkHK8KZD73QEfUJxr31qqKYfEVgfFZuS7UuXMn3WX3OMf05Q+ww2 n20fyAGPpkj6m3XMR0AwR1ZSB63bDVj3YRv8FJHE+79chZv8F/wWj4qQhLRM/ofWkaa0 M84A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hYlmHiW8Mf23w6tJ683fT75hrdHFAma9oRkAvVJ4teg=; b=IJRGL58mUsXb/+qGlSXuXEiupIzFq2Lh7rwRKQcMzoPE8doFgv7xdOG+Ek/xK5+kOS M8se/gI5mM0QHofBCpQXakuDfaMPoBHKuB5xYTBA9xxjBWbGDwJWveGTLZc/6x5AxqxF 9jRpXe8DbFvTN1jGNZFAhn4LYR3WBASnkmFKyg/WduyqAGQapDfpMrh/fMvlSrk/YIHY +TVB4ZSSLktsajlMIiYc/DIgEMfWWpzY88va8p8DAQRVMo2TCIAduQdEIGZGRaVnP6Kr NZuYMdEp4cLj2y9A3WYtgHoFputODomWxiKlOmrKasNcSSRpdKVUr/HAUz+H+BC4dggG be6Q== X-Gm-Message-State: ABUngvcoqV2lCAsvbkrxb80thHj28dUL0BtSFNYRxFR7c4CvPvGCipE0f0Pth05QtAp/4fvVbr93F9dgQzINpA== X-Received: by 10.237.51.3 with SMTP id u3mr7189854qtd.12.1478170000593; Thu, 03 Nov 2016 03:46:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.150.39 with HTTP; Thu, 3 Nov 2016 03:46:39 -0700 (PDT) X-Originating-IP: [216.4.56.153] Received: by 10.12.150.39 with HTTP; Thu, 3 Nov 2016 03:46:39 -0700 (PDT) In-Reply-To: <20161103092939.GB2648@home.opsec.eu> References: <58187573.7020402@grosbein.net> <20161103092939.GB2648@home.opsec.eu> From: Mark Heily Date: Thu, 3 Nov 2016 06:46:39 -0400 Message-ID: Subject: Re: Fwd: Re: how to reduce the size of /usr/share/i18n data? To: Kurt Jaeger Cc: FreeBSD Hackers , freebsd-current , Julian Elischer Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 10:46:42 -0000 On Nov 3, 2016 5:30 AM, "Kurt Jaeger" wrote: > > Hi! > > > So I am to take it that no-one has any idea how this stuff works and > > how to stub it out? > > Or had time to write about it. > > -- > pi@opsec.eu +49 171 3101372 4 years to go ! > Maybe you could use 'svn blame' to research who has commited those files, and contact them directly? _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-hackers@freebsd.org Thu Nov 3 09:29:41 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7E60FC2B624; Thu, 3 Nov 2016 09:29:41 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C632A1172; Thu, 3 Nov 2016 09:29:40 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from pi by home.opsec.eu with local (Exim 4.87 (FreeBSD)) (envelope-from ) id 1c2EL5-0001qf-Hf; Thu, 03 Nov 2016 10:29:39 +0100 Date: Thu, 3 Nov 2016 10:29:39 +0100 From: Kurt Jaeger To: Julian Elischer Cc: freebsd-current , freebsd Subject: Re: Fwd: Re: how to reduce the size of /usr/share/i18n data? Message-ID: <20161103092939.GB2648@home.opsec.eu> References: <58187573.7020402@grosbein.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Mailman-Approved-At: Thu, 03 Nov 2016 11:10:38 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 09:29:41 -0000 Hi! > So I am to take it that no-one has any idea how this stuff works and > how to stub it out? Or had time to write about it. -- pi@opsec.eu +49 171 3101372 4 years to go ! From owner-freebsd-hackers@freebsd.org Thu Nov 3 11:21:26 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 40766C2D5E2 for ; Thu, 3 Nov 2016 11:21:26 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CDC111786; Thu, 3 Nov 2016 11:21:25 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1c2G56-0009tw-0v; Thu, 03 Nov 2016 14:21:16 +0300 Date: Thu, 3 Nov 2016 14:21:16 +0300 From: Slawa Olhovchenkov To: Julian Elischer Cc: freebsd Subject: Re: how to reduce the size of /usr/share/i18n data? Message-ID: <20161103112115.GL57714@zxy.spb.ru> References: <7b036323-aa77-6d41-36b0-439a12a36524@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7b036323-aa77-6d41-36b0-439a12a36524@freebsd.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 11:21:26 -0000 On Tue, Nov 01, 2016 at 06:53:24PM +0800, Julian Elischer wrote: > there are a number of packages that want to link with or use that > data, and you can't always disable it, but it's very very big (38MB?), > especially in the context of an appliance that doesn't really need it > at all. I am see only 6MB (not 38MB) on disk. This is like some data for iconv. From owner-freebsd-hackers@freebsd.org Thu Nov 3 11:35:49 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B3B0EC2DD4E for ; Thu, 3 Nov 2016 11:35:49 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 326EB168C; Thu, 3 Nov 2016 11:35:49 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by mail-qt0-x22c.google.com with SMTP id w33so25916014qtc.3; Thu, 03 Nov 2016 04:35:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=x5hAXXL5Phk9lFG+B+PNuWnIuUKpRcHy7LqV/pqCSYs=; b=x0N/6XERrZHAHciUj4urSZfdzuzQ0jIjwnPRpZUuyJ4OQPhOz+6FSIQ2kFeAK2c7Kf mzb9DBMlnxo9l6kZ9hhJR2tMiOa4bhphPg3FZZX0cr1Y9ukcnVgUF87M4KzBt3WBm/P1 H5M+53FYcLfz8ulOz0/j+Z6eXxc8+wBT4iW5kFgJZvgJGXMN+E7Qsbq12DYjusOZLCMa TpkZug7Px7TW+8Kc6+RykZFhQ9Uj7k1m7g0mRkTeqaHuc+xan/Gi+7DSJltMSGmNgKd1 VGtZeqMBalAQbc8Kolb6PvRGSmIRPNzbtLpfqrZCoDpo/Uo+Ia5+g58c8ldyXhQzhSyt eNcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=x5hAXXL5Phk9lFG+B+PNuWnIuUKpRcHy7LqV/pqCSYs=; b=IFwGYv0lubrykpjAcEenwfSioACU1GRP/2NXxVwQJ7iiTx7tMgcmIMCdfMrwAyxqL6 fF5N46IUqW+ND2LCFC15+eFnDUVoNQKv34Y3BdutMh/JJRlzGOWzNP1ncvGVcOieZWJk HkYUlGOHs0eWfOx88IdM8uZcK3gRcS4aCCJy9E0MWEdo9b9a+VtMZ0oac5V6hJ9jrLKx YbARmERFDMp3oTe5NfUCdOKnkAqiZqLKH7jwYLVyGZb3EC1/5uI5qqQjG9lqjJRrPGjW 9bcDoHqMWEMYrBcnkxpSg3+wOBJS9l8DVj5wDnpmL/mlf6qH+TzWCLk0nbsvlaAC6k3d gpzw== X-Gm-Message-State: ABUngveC7qAME6F4quj/8vISJgTdOzrcJ0GrvTvVg7vUvWnCMFTPq1kQOBrUrdOtJ2bQQAFAhuYe6Jr0hUn2yw== X-Received: by 10.200.38.102 with SMTP id v35mr7902910qtv.100.1478172948074; Thu, 03 Nov 2016 04:35:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.171.21 with HTTP; Thu, 3 Nov 2016 04:35:47 -0700 (PDT) In-Reply-To: <20161103112115.GL57714@zxy.spb.ru> References: <7b036323-aa77-6d41-36b0-439a12a36524@freebsd.org> <20161103112115.GL57714@zxy.spb.ru> From: Sergey Kandaurov Date: Thu, 3 Nov 2016 14:35:47 +0300 Message-ID: Subject: Re: how to reduce the size of /usr/share/i18n data? To: Julian Elischer Cc: freebsd Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 11:35:49 -0000 Quick source tree analysis suggests me that WITHOUT_ICONV should work. # grep -B1 i18n= head/share/Makefile .if ${MK_ICONV} != "no" _i18n= i18n > especially in the context of an appliance that doesn't really need it at all. -- wbr, pluknet From owner-freebsd-hackers@freebsd.org Thu Nov 3 11:57:38 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AC4B0C2B51F; Thu, 3 Nov 2016 11:57:38 +0000 (UTC) (envelope-from tijl@coosemans.org) Received: from mailrelay109.isp.belgacom.be (mailrelay109.isp.belgacom.be [195.238.20.136]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (Client CN "relay.skynet.be", Issuer "GlobalSign Organization Validation CA - SHA256 - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8595A1894; Thu, 3 Nov 2016 11:57:35 +0000 (UTC) (envelope-from tijl@coosemans.org) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2B9BQBCJRtY/1QiyVBdGwEBAQMBAQEJA?= =?us-ascii?q?QEBgzABAQEBAR+BVKQ2lk+GIgKCI0QQAQIBAQEBAQEBYiiEYgEBBCMzIxAJAhg?= =?us-ascii?q?CAgUhAgIPKh4GE4hakB6dP40DAQEBAQYBAQEBI4EJiguER4MEglwFmiCQMnKPI?= =?us-ascii?q?40dhAQ1IGuFID00h3oBAQE?= Received: from 84.34-201-80.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([80.201.34.84]) by relay.skynet.be with ESMTP; 03 Nov 2016 12:56:22 +0100 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.15.2/8.15.2) with ESMTP id uA3BuKTo060387; Thu, 3 Nov 2016 12:56:21 +0100 (CET) (envelope-from tijl@coosemans.org) Date: Thu, 3 Nov 2016 12:56:18 +0100 From: Tijl Coosemans To: Julian Elischer Cc: freebsd-current , freebsd Subject: Re: how to reduce the size of /usr/share/i18n data? Message-ID: <20161103125618.204ee7d3@kalimero.tijl.coosemans.org> In-Reply-To: References: <58187573.7020402@grosbein.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 11:57:39 -0000 On Thu, 3 Nov 2016 15:48:09 +0800 Julian Elischer wrot= e: > On 1/11/2016 7:11 PM, Julian Elischer wrote: >> 01.11.2016 17:53, Julian Elischer =D0=BF=D0=B8=D1=88=D0=B5=D1=82: =20 >>> there are a number of packages that want to link with or use that=20 >>> data, and you can't always disable it, but it's very very big=20 >>> (38MB?), especially in the context of an appliance that doesn't=20 >>> really need it at all. >>> >>> >>> If anyone has a procedure to follow to put that onto a diet, maybe=20 >>> just as a stub then I'm all ears. =20 > > So I am to take it that no-one has any idea how this stuff works and=20 > how to stub it out? /usr/share/i18n is only used by iconv(3). If you don't need that function just add WITHOUT_ICONV to src.conf. If you do need it then you can remove all the subdirectories of character sets you never convert to/from. The easiest is probably to modify the SUBDIR variable in src/share/i18n/csmapper/Makefile and src/share/i18n/esdb/Makefile. From owner-freebsd-hackers@freebsd.org Thu Nov 3 18:22:43 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8BCB7C2DFCB for ; Thu, 3 Nov 2016 18:22:43 +0000 (UTC) (envelope-from john@kozubik.com) Received: from kozubik.com (kozubik.com [216.218.240.130]) (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 634761344 for ; Thu, 3 Nov 2016 18:22:43 +0000 (UTC) (envelope-from john@kozubik.com) Received: from kozubik.com (localhost [127.0.0.1]) by kozubik.com (8.14.3/8.14.3) with ESMTP id uA3I3H4e086346; Thu, 3 Nov 2016 11:03:17 -0700 (PDT) (envelope-from john@kozubik.com) Received: from localhost (john@localhost) by kozubik.com (8.14.3/8.14.3/Submit) with ESMTP id uA3I3BPA086343; Thu, 3 Nov 2016 11:03:11 -0700 (PDT) (envelope-from john@kozubik.com) Date: Thu, 3 Nov 2016 11:03:11 -0700 (PDT) From: John Kozubik To: =?ISO-8859-15?Q?Jo=E3o_Vieira?= cc: freebsd-hackers@freebsd.org Subject: Re: Who wants to get paid to maintain sshuttle for FreeBSD ? In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 18:22:43 -0000 Hello, On Sun, 30 Oct 2016, Jo?o Vieira wrote: > I am curious to know about the problems you have with sshuttle on FreeBSD. In short, UDP does not go over the tunnel - no matter the configuration or options chosen. Either UDP does not function, or it "leaks", and the UDP traffic goes outside the tunnel. The individual who has taken on this job and is currently working on it has said: "how sshutle handles ipfw rules and the traffic especially related to UDP on FreeBSD needs to be improved" > Support was added in early 2016 for FreeBSD and a bit later also for > OpenBSD. Then IPv6 support was added and while it worked with OSX and > OpenBSD there was a problem with FreeBSD [1] but I wouldn?t say that > there is no FreeBSD specific development, quite the contrary. We're going to immediately contribute whatever work we create back to the mainline sshuttle development - so expect pull requests in the near future :) John Kozubik From owner-freebsd-hackers@freebsd.org Thu Nov 3 19:34:30 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 879A9C2D95A; Thu, 3 Nov 2016 19:34:30 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 424561745; Thu, 3 Nov 2016 19:34:29 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id uA3JYROr008627; Thu, 3 Nov 2016 12:34:27 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id uA3JY7ss008626; Thu, 3 Nov 2016 12:34:07 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201611031934.uA3JY7ss008626@pdx.rh.CN85.dnsmgr.net> Subject: Re: Fwd: Re: how to reduce the size of /usr/share/i18n data? In-Reply-To: To: Julian Elischer Date: Thu, 3 Nov 2016 12:34:07 -0700 (PDT) CC: freebsd-current , freebsd X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Thu, 03 Nov 2016 20:00:06 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 19:34:30 -0000 [ Charset UTF-8 unsupported, converting... ] > > So I am to take it that no-one has any idea how this stuff works and > how to stub it out? I would be rather tempted to rm -r /usr/share/i18n and see what fails. Anything that fails should be patched to deal with the fact locale date is missing. Then the stub out would be a simple mater of making src/share/i18n a SUBDIR += in the src/share Makefile inside an .ifdef WITH_LOCALE or WITH_I18N. Further stubbing out should be pursued if we want to get back some of our embeded-friendly needs by making all of the locale related code conditionally compiled during a make world. Depressing fact: The i18n directory alone is larger than a full 386BSD 0.1+sources+patchkit install. > On 1/11/2016 7:11 PM, Julian Elischer wrote: > > > > 01.11.2016 17:53, Julian Elischer ?????: > >> there are a number of packages that want to link with or use that > >> data, and you can't always disable it, but it's very very big > >> (38MB?), especially in the context of an appliance that doesn't > >> really need it at all. > >> > >> > >> If anyone has a procedure to follow to put that onto a diet, maybe > >> just as a stub then I'm all ears. > > > > +1 > > > > Introduction of such large part of base system is kind of > > catastrophe for embedded systems > > that need only ASCII and may be additionally one of "good old" 8-bit > > locales. > > > > FreeBSD 11 got pretty large and embedded-unfriendly without clear > > way to exclude such unneeded parts. > > -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Thu Nov 3 20:56:17 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 04A01C2E5C5; Thu, 3 Nov 2016 20:56:17 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cloud.theravensnest.org", Issuer "StartCom Class 1 DV Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C56621751; Thu, 3 Nov 2016 20:56:16 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from [192.168.1.65] (host81-157-246-94.range81-157.btcentralplus.com [81.157.246.94]) (authenticated bits=0) by theravensnest.org (8.15.2/8.15.2) with ESMTPSA id uA3KuCuT078325 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Nov 2016 20:56:14 GMT (envelope-from theraven@FreeBSD.org) X-Authentication-Warning: theravensnest.org: Host host81-157-246-94.range81-157.btcentralplus.com [81.157.246.94] claimed to be [192.168.1.65] Content-Type: multipart/signed; boundary="Apple-Mail=_17966B09-C7BB-4516-ABBF-D44376D8A144"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: how to reduce the size of /usr/share/i18n data? From: David Chisnall In-Reply-To: <201611031934.uA3JY7ss008626@pdx.rh.CN85.dnsmgr.net> Date: Thu, 3 Nov 2016 20:56:47 +0000 Cc: Julian Elischer , freebsd-current , freebsd Message-Id: References: <201611031934.uA3JY7ss008626@pdx.rh.CN85.dnsmgr.net> To: "Rodney W. Grimes" X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 20:56:17 -0000 --Apple-Mail=_17966B09-C7BB-4516-ABBF-D44376D8A144 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 3 Nov 2016, at 19:34, Rodney W. Grimes = wrote: >=20 > Depressing fact: The i18n directory alone is larger than > a full 386BSD 0.1+sources+patchkit install. Is the depressing thing here that even something as recent as 386BSD 0.1 = assumed that ASCII was enough for the whole world? David --Apple-Mail=_17966B09-C7BB-4516-ABBF-D44376D8A144 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIK5jCCBPww ggPkoAMCAQICECJrrb9nBol9MHok/UZg/AYwDQYJKoZIhvcNAQELBQAwdTELMAkGA1UEBhMCSUwx FjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTAeFw0xNjA0MTkw OTI3NDJaFw0xNzA0MTkwOTI3NDJaMEQxHTAbBgNVBAMMFHRoZXJhdmVuQGZyZWVic2Qub3JnMSMw IQYJKoZIhvcNAQkBFhR0aGVyYXZlbkBmcmVlYnNkLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALsL5pEhrGjrswHVdMHWhgxb8ARKDYRePSqpDLmjJ40bpx+n1zrvIwjC2Vk2IpoD 04rg5Pog2IrhnX+Qk2NSXzBXWj2JAaTc9OtSeAY0BtgJYXONGONQbRKVy97QBdzd1SbMEzDrOgH5 UDI+5sF1PboOTmLyTAPI9273XdfZ0BnstUXs8NXr/7p9E5CWJOsO1iQcINbm4XiwC1PLNMeWUknE Nji/hFKwcE8IFtaUe1ymbw6yA3rBpDu3KewIRD1T66FPTZJeIzvUoBIqWd+GAOfCBG2QYmbc3y/x K2hCtcXThcB1uVFA2q39koLKA8wHyqv4Jhm3wzhAqKDsWK4bGW0CAwEAAaOCAbcwggGzMA4GA1Ud DwEB/wQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwCQYDVR0TBAIwADAdBgNV HQ4EFgQU5J3Kc8GeW8pEGxBkcMoA7eUOPRwwHwYDVR0jBBgwFoAUJIFsOWG+SQ+PtxtGK8kotSdI bWgwbwYIKwYBBQUHAQEEYzBhMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20w OQYIKwYBBQUHMAKGLWh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3NjYS5jbGllbnQxLmNy dDA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zY2EtY2xpZW50MS5j cmwwHwYDVR0RBBgwFoEUdGhlcmF2ZW5AZnJlZWJzZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgUwLDAqBggrBgEFBQcCARYe aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQBSBDH+kZf5 bZkNFcMSPdfnGC7F8utBIxs2bi3JQjsBoQTm1vnXdwgINSfO9At6iQZHoEyj8ZE6PcMFuEU0+bk0 aE8aYcW59WnxfWx943upZoMhX0YVaJcFK01EHFrddRAP44sh7Eu6JtdFuAG+6btDReMcg35Qm65X 7/280aVm7awadJ+IQs8r9qBVk2NFqkvHCETtJjNWXd7M6mcsfXstvykbubPQH/VNW/zrX6yzIcI4 aoz+Sn8RJmHNkk6cImqe1KvsdDLXmqCoeoMwos62pT18RaI//jwTdmnf5EHFMlevnxOr7rzA++71 OSZfdYf6+nvHOod1F721rNuy6lxFMIIF4jCCA8qgAwIBAgIQa6eKfQrXiNZRCvlZ5Oe04TANBgkq hkiG9w0BAQsFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20g Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTUxMjE2MDEwMDA1WhcNMzAxMjE2MDEwMDA1WjB1 MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20g Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50 IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvX3a98OifYP2W4L921tfrh4bdcC1 Ga+YJKy7V3nYNewJHnzMlBsK0Hb8Dm4Wo3FZpylcYa1MJGT10QMGWaLER3xCIuRR+8eklf/EqeZW RLojJ7zBRtjMywPOCelrOU+DX12dKp+Ez4J6919rz1UudTO1GvZyCYJ/I7062uHsskM8b7gPxmcC oO1UHwwpgkvpCArJWGFoFzjLdsZbErJcS3HtAhlkbE/BKTMrdYg35Uo12SLBO5tbk8h2imbKTC8i Ms+pskrvI/AVlh6QoTTXk6xboVX6zgMgzxSVVLymQiygYYm0y5aMsvi2raFhC643SOGvErWWPPnS EfbeAD1xswIDAQABo4IBZDCCAWAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMC BggrBgEFBQcDBDASBgNVHRMBAf8ECDAGAQH/AgEAMDIGA1UdHwQrMCkwJ6AloCOGIWh0dHA6Ly9j cmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDBmBggrBgEFBQcBAQRaMFgwJAYIKwYBBQUHMAGGGGh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTAwBggrBgEFBQcwAoYkaHR0cDovL2FpYS5zdGFydHNzbC5j b20vY2VydHMvY2EuY3J0MB0GA1UdDgQWBBQkgWw5Yb5JD4+3G0YrySi1J0htaDAfBgNVHSMEGDAW gBROC+8apEBbpRdphzDKNGhD0EGu8jA/BgNVHSAEODA2MDQGBFUdIAAwLDAqBggrBgEFBQcCARYe aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4ICAQCL4/eH7AGL hK0PAQJbnOEjJyMEvTTwcAJuUh/bodjQl06u4putYOxdSyIjSP/sKt+31LmjG8+IO1WqykE4H/Lm 7NKezWVnCHuwb3ptgFmlwbMbGkU2MOZBtwzfKXdYUhFLhaE2uw5jXhXvLYitQay962wP5uPI6eAI hV4L8aaya1u4s7MnrTq0Rz25FuGNO79vTHYWj797tSRC8rM16js4yGKOLFpQvIg0F8IElv57b1st p+C7omqM5Qn15dePbSnqr8Jb65WtmJJbnv6rlqfY/aLuE/zmNAlzLmPgfMDStKIXdg+EoYBZTEo8 wBUaBxihfNbJ069ndQOxMNNqBelEMgpAtmjTbCuXFjqIwWq+XOx6ZV/Wh2FAmaLsSHlNvEjjSQMZ wE4EeHCdo66ZmEs/5JYlCeOkulKVQ6P3m5/XOj2jP17Q2AgmjP+11+sHN7PvrG0OwrQp9QMe3X+r n0G8MjtFfqBWvR9CgLIxzM3MJNxFdgdjS2rYnShP5uxvqwfZvhZVYCIkqdJhpYON0DvSodfiar0w iM79mySZJjzC0CTbiisBzS/BeBhqeo2wFfli/iw3hn1XKvAx0ty6w/scmBF0AYqmRHYj1TjMSw0l Al7AztLglqWjUPI+sukvadMRPxmtKXlS2nVR4an/Z16imsZ69+fFYH68c1CK7zmjozGCA04wggNK AgEBMIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3Mg MSBDbGllbnQgQ0ECECJrrb9nBol9MHok/UZg/AYwCQYFKw4DAhoFAKCCAZkwGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYxMTAzMjA1NjQ4WjAjBgkqhkiG9w0BCQQx FgQUhl3KGop0HahTr7y0dXGpRnfzsU0wgZoGCSsGAQQBgjcQBDGBjDCBiTB1MQswCQYDVQQGEwJJ TDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlv biBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhAia62/ZwaJ fTB6JP1GYPwGMIGcBgsqhkiG9w0BCRACCzGBjKCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMN U3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkx IzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhAia62/ZwaJfTB6JP1GYPwGMA0G CSqGSIb3DQEBAQUABIIBAK/I9VVVnaZ8rtBsbZR0cBR7Pnb3F5dL94nHIsGosh8FKKjYB/hPF7z+ aiLfs3x25dAN6nZ1FSVF5KFWt16boSH5ZF2v/udPjTydHaKPBGQJTd49Snk7l9e9CLfscHDO4ULc 8Y5Yami7D2MLM0QN8m6kAim0QDngfsOQkjCqEBhcFzzdxmWGeXhQOj3gLfEWp4O2K/QuevVjHc7s xyaZecM0Mx0Sj+VJrVWwvzxe+tOAWeE0lipmArQda27G7Varz2ZcrUJt65qiPrjOlYJIaGfs6VHS EF6ClhSGWZU5y+tsiy+7j4OPDFxSDjmRwccp2wCfbJsMwyFC7HzTIfRu1oMAAAAAAAA= --Apple-Mail=_17966B09-C7BB-4516-ABBF-D44376D8A144-- From owner-freebsd-hackers@freebsd.org Thu Nov 3 21:23:34 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D77B1C2EDC7; Thu, 3 Nov 2016 21:23:34 +0000 (UTC) (envelope-from jkh@mail.turbofuzz.com) Received: from zimbra.ixsystems.com (barracuda.ixsystems.com [12.229.62.30]) (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 BFB851609; Thu, 3 Nov 2016 21:23:34 +0000 (UTC) (envelope-from jkh@mail.turbofuzz.com) Received: from localhost (localhost [127.0.0.1]) by zimbra.ixsystems.com (Postfix) with ESMTP id 625409CA980; Thu, 3 Nov 2016 14:23:33 -0700 (PDT) Received: from zimbra.ixsystems.com ([127.0.0.1]) by localhost (zimbra.ixsystems.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id ElsX_xjSSTcX; Thu, 3 Nov 2016 14:23:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.ixsystems.com (Postfix) with ESMTP id 2125B9CA9FE; Thu, 3 Nov 2016 14:23:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at ixsystems.com Received: from zimbra.ixsystems.com ([127.0.0.1]) by localhost (zimbra.ixsystems.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id t_Wklg0nWmK5; Thu, 3 Nov 2016 14:23:31 -0700 (PDT) Received: from [10.250.1.183] (unknown [10.250.1.183]) by zimbra.ixsystems.com (Postfix) with ESMTPSA id C3B0C9C8859; Thu, 3 Nov 2016 14:23:31 -0700 (PDT) From: Jordan Hubbard Message-Id: <1CA916A7-E1AE-4099-BCD2-70EA815A2846@mail.turbofuzz.com> Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: how to reduce the size of /usr/share/i18n data? Date: Thu, 3 Nov 2016 14:23:31 -0700 In-Reply-To: Cc: "Rodney W. Grimes" , freebsd , freebsd-current To: David Chisnall References: <201611031934.uA3JY7ss008626@pdx.rh.CN85.dnsmgr.net> X-Mailer: Apple Mail (2.3251) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 21:23:34 -0000 > On Nov 3, 2016, at 1:56 PM, David Chisnall = wrote: >=20 > Is the depressing thing here that even something as recent as 386BSD = 0.1 assumed that ASCII was enough for the whole world? =E2=80=9CRecent??=E2=80=9D :-D From owner-freebsd-hackers@freebsd.org Thu Nov 3 22:00:44 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 432A5C2E7D4 for ; Thu, 3 Nov 2016 22:00:44 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AEE411472; Thu, 3 Nov 2016 22:00:42 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221]) by hz.grosbein.net (8.14.9/8.14.9) with ESMTP id uA3M0UFC063381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 3 Nov 2016 23:00:31 +0100 (CET) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: theraven@FreeBSD.org Received: from [10.58.0.10] (dadvw [10.58.0.10]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id uA3M0QT3019587 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 4 Nov 2016 05:00:26 +0700 (KRAT) (envelope-from eugen@grosbein.net) Subject: Re: how to reduce the size of /usr/share/i18n data? To: David Chisnall References: <201611031934.uA3JY7ss008626@pdx.rh.CN85.dnsmgr.net> Cc: freebsd From: Eugene Grosbein Message-ID: <581BB376.9080200@grosbein.net> Date: Fri, 4 Nov 2016 05:00:22 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM autolearn=no version=3.3.2 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hz.grosbein.net X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 22:00:44 -0000 04.11.2016 3:56, David Chisnall wrote: > Is the depressing thing here that even something as recent as 386BSD 0.1 assumed that ASCII was enough for the whole world? ... for tasks being solved with. From owner-freebsd-hackers@freebsd.org Sat Nov 5 11:06:38 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DAEE7C2FC14 for ; Sat, 5 Nov 2016 11:06:38 +0000 (UTC) (envelope-from j.deboynepollard-newsgroups@ntlworld.com) Received: from know-smtprelay-omc-8.server.virginmedia.net (know-smtprelay-omc-8.server.virginmedia.net [80.0.253.72]) by mx1.freebsd.org (Postfix) with ESMTP id 52A258D6 for ; Sat, 5 Nov 2016 11:06:37 +0000 (UTC) (envelope-from j.deboynepollard-newsgroups@ntlworld.com) Received: from [192.168.1.100] ([86.10.211.13]) by know-smtprelay-8-imp with bizsmtp id 4B5S1u00R0HtmFq01B5Tw4; Sat, 05 Nov 2016 11:05:27 +0000 X-Originating-IP: [86.10.211.13] X-Spam: 0 X-Authority: v=2.1 cv=OPLapnuB c=1 sm=1 tr=0 a=SB7hr1IvJSWWr45F2gQiKw==:117 a=SB7hr1IvJSWWr45F2gQiKw==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=2rVjqWD_AAAA:8 a=Ye9q-bpsAAAA:8 a=6I5d2MoRAAAA:8 a=ZCrLJ8IgFw6LNsmvUEUA:9 a=QEXdDO2ut3YA:10 a=-FEs8UIgK8oA:10 a=NWVoK91CQyQA:10 a=ULaUcM2Ibn9MdPUUwucP:22 a=q_qy2H7hVTjG6VLSWsna:22 a=IjZwj45LgO3ly-622nXo:22 To: FreeBSD Hackers , NetBSD Users From: Jonathan de Boyne Pollard Subject: Improved manual page for ul(1) Message-ID: Date: Sat, 5 Nov 2016 11:05:07 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2016 11:06:39 -0000 So whither does one submit an improved manual page for ul(1) ? Here's the source: * http://jdebp.eu./Proposals/ul.1 The current FreeBSD/NetBSD manual page really doesn't describe what ul does and is even somewhat misleading. So the aforelinked has some improvements. This came from an answer at Stack Exchange. * http://unix.stackexchange.com/a/320922/5132 The mentioned stack buffer bug in FreeBSD ncal is filed. NetBSD has Kim Letkeman's cal rather than Wolfgang Helbig's ncal, so this does not apply to NetBSD. * https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214237 From owner-freebsd-hackers@freebsd.org Sat Nov 5 14:26:05 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 32D98C315C5 for ; Sat, 5 Nov 2016 14:26:05 +0000 (UTC) (envelope-from vangyzen@FreeBSD.org) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [199.48.133.146]) by mx1.freebsd.org (Postfix) with ESMTP id 1E56B2E0 for ; Sat, 5 Nov 2016 14:26:04 +0000 (UTC) (envelope-from vangyzen@FreeBSD.org) Received: from ford.home.vangyzen.net (unknown [76.164.15.242]) by smtp.vangyzen.net (Postfix) with ESMTPSA id C10A85648E for ; Sat, 5 Nov 2016 09:25:58 -0500 (CDT) Subject: Re: Improved manual page for ul(1) To: freebsd-hackers@freebsd.org References: From: Eric van Gyzen Message-ID: <8532b000-401f-bb20-46a4-135ab2b2aac8@FreeBSD.org> Date: Sat, 5 Nov 2016 09:25:53 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2016 14:26:05 -0000 On 11/05/2016 06:05, Jonathan de Boyne Pollard wrote: > So whither does one submit an improved manual page for ul(1) ? Here's the source: > > * http://jdebp.eu./Proposals/ul.1 > > The current FreeBSD/NetBSD manual page really doesn't describe what ul does and > is even somewhat misleading. So the aforelinked has some improvements. I would commit it if I were qualified to vouch for the content's accuracy (not that I have any reason to /doubt/ it). There are some greybeards[1] here who probably can. > This came from an answer at Stack Exchange. > > * http://unix.stackexchange.com/a/320922/5132 > > The mentioned stack buffer bug in FreeBSD ncal is filed. NetBSD has Kim > Letkeman's cal rather than Wolfgang Helbig's ncal, so this does not apply to > NetBSD. > > * https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214237 Committed. Thanks! Eric [1] I use this term in a most respectful sense.