From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 9 01:36:27 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B22FA955 for ; Sun, 9 Jun 2013 01:36:27 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) by mx1.freebsd.org (Postfix) with ESMTP id 818F01366 for ; Sun, 9 Jun 2013 01:36:27 +0000 (UTC) Received: by mail-ob0-f173.google.com with SMTP id wc20so8540837obb.32 for ; Sat, 08 Jun 2013 18:36:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ZJ20lXH3E0dABAFb2pDgncSdPPH/ShKIZcRGU9VyJqs=; b=CihDuuIndCRBbQD38OA8PiIPz46YnhUUXhCifwPPFByXbYsQzMMqNMaNB+VFAnXLdk HEMEBk/fV7HzkjMTUMQvZFbJTNRS5HkabqBQXwdlbNXLikwTt5QYvyZAq1NcQluwy9lk C5759XRkwfZ+WDEQOwtFcJHAXDVqNoj5+PBkoU4AegZ35Cgk5ByohL3hnhWAY2TqrnBP I7W56cK/s9L5cytiP6hIksWWsQHDzdIkk9KP58TBTZy18xKtjXJdbK6noiiAcp4Cps+h XHuiCh45n1R/2t0W+dxXGuagRpSox0s9a4Uf3JwptZbQHAROWbx92vjX8DvoFPP0Zg+5 xgEQ== MIME-Version: 1.0 X-Received: by 10.60.174.111 with SMTP id br15mr3508491oec.130.1370741787087; Sat, 08 Jun 2013 18:36:27 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.182.237.100 with HTTP; Sat, 8 Jun 2013 18:36:27 -0700 (PDT) In-Reply-To: <51B3B59B.8050903@erdgeist.org> References: <51B3B59B.8050903@erdgeist.org> Date: Sat, 8 Jun 2013 18:36:27 -0700 X-Google-Sender-Auth: k_4I3ooPAUOOp_KcVnt3FXwnNz0 Message-ID: Subject: Re: Fix MNAMELEN or reimplement struct statfs From: mdf@FreeBSD.org To: Dirk Engling Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jun 2013 01:36:27 -0000 On Sat, Jun 8, 2013 at 3:52 PM, Dirk Engling wrote: > The arbitrary value > > #define MNAMELEN 88 /* size of on/from name bufs */ > > struct statfs { > [...] > char f_mntfromname[MNAMELEN];/* mounted filesystem */ > char f_mntonname[MNAMELEN]; /* directory on which mounted */ > }; > > currently bites us when trying to use poudriere with errors like > > 'mount: tmpfs: File name too long' > > > /poudriere/data/build/91_RELEASE_amd64-REALLY-REALLY-LONG-JAILNAME/ref/wrkdirs > > The topic has been discussed several times since 2004 and has been > postponed each time, the last time when it hit zfs users: > > http://lists.freebsd.org/pipermail/freebsd-fs/2010-March/007974.html > > So I'd like to point to the calendar, it's 2013 already and there's > still a static arbitrary (and way too low) limit in one of the core > areas of the vfs code. > > So I'd like to bump the issue and propose either making f_mntfromname a > dynamic allocation or just increase MNAMELEN, using 10.0 as water shed. > Gleb Kurtsou did this along with the ino64 GSoC project. Unfortunately, both he and I hit ENOTIME due to the job that pays the bills and it's never made it back to the main repository. IIRC, though, the only reason for doing it with 64-bit ino_t is that he'd already finished changing the stat/dirent ABI so what was one more. I think he went with 1024 bytes, which also necessitated not allocating statfs on the stack for the kernel. Cheers, matthew From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 9 21:02:18 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EC574E10; Sun, 9 Jun 2013 21:02:18 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) by mx1.freebsd.org (Postfix) with ESMTP id B4AA71206; Sun, 9 Jun 2013 21:02:18 +0000 (UTC) Received: from pool-108-21-117-224.nycmny.east.verizon.net ([108.21.117.224]:50461 helo=[192.168.0.177]) by vps.hungerhost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1Ulmkj-0000y9-Vr; Sun, 09 Jun 2013 17:02:18 -0400 From: George Neville-Neil Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Beyond Buildworld Dev Summit Working Group Report Date: Sun, 9 Jun 2013 17:02:22 -0400 Message-Id: To: hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com X-Get-Message-Sender-Via: vps.hungerhost.com: authenticated_id: gnn@neville-neil.com X-Mailman-Approved-At: Mon, 10 Jun 2013 00:08:45 +0000 Cc: "devsummit@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jun 2013 21:02:19 -0000 Howdy, The Beyond Buildworld working group discussed many subjects around our = build system, including upcoming changes to do a better job of addressing embedded systems, the = integration of bmake, and the need for better incremental build support. The full notes are = on the wiki and=20 also pasted at the bottom of this email. Best, George https://wiki.freebsd.org/201305DevSummit/Buildworld This section includes volunteers or contact points as links. =95 uboot ports [DianeBruce] =95 compiler patches vs. gccc on Linux [TimKeintzle] =95 ubloader not on ELF [Ian] =95 uboot API [GeorgeNevilleNeil] =95 FDT for MIPS and ARM 4/5 [RobertWatson] =95 Unify Loaders [RobertWatson] =95 Parallel Build Enhanced [SimonGarrety] =95 projects/bmake =95 switch date? =95 review [WarnerLosh], [BrooksDavis], [GarretCooper] =95 Cross Build [BrooksDavis] =95 Depends on bmake =95 toochains.mk [SimonGarrety] =95 LLVM binutils [DavidChisnal] =95 Kerberos build issue [GlenBarber] =95 Crochet with VM images [TimKeintzle], [GlenBarber], = [ColinPercival] =95 Integrate make.conf into source tree [SimonGarrety] =95 Dump src.conf and make.conf during buildworld = [GeorgeNevilleNeil] =95 Build config files not in the tree [GeorgeNevilleNeil] =95 Kernel build issues [GarretCooper] =95 modules =95 options =95 Packages built from the source tree [BaptisteDaroussin] =95 clang/LLVM test suite [DavidChisnall] =95 Tinderbox Test Cluster [GeorgeNevilleNeil] =95 Source Tinderbox Redport [GlenBarber], [BernhardFroehlich], = [GarretCooper] =95 Anyone can revert any change to deal with build breakage, = and this needs to be better socialized by core@ =95 Build Bot [MarcelMoolenaar] =95 Cross build subset of user land [AdrianChadd] =95 Build from hosts that are not FreeBSD, aka MacOS etc. = [MarcelMoolenaar] From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 9 21:04:47 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F338DF0D; Sun, 9 Jun 2013 21:04:46 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) by mx1.freebsd.org (Postfix) with ESMTP id CE1311212; Sun, 9 Jun 2013 21:04:46 +0000 (UTC) Received: from pool-108-21-117-224.nycmny.east.verizon.net ([108.21.117.224]:50488 helo=[192.168.0.177]) by vps.hungerhost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1Ulmn7-00021z-TV; Sun, 09 Jun 2013 17:04:46 -0400 From: George Neville-Neil Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Network Recieve Performance Working Group Date: Sun, 9 Jun 2013 17:04:49 -0400 Message-Id: <8537DE82-46F4-4E11-AECA-42F118AB179F@neville-neil.com> To: "hackers@freebsd.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com X-Get-Message-Sender-Via: vps.hungerhost.com: authenticated_id: gnn@neville-neil.com X-Mailman-Approved-At: Mon, 10 Jun 2013 00:09:00 +0000 Cc: "devsummit@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jun 2013 21:04:47 -0000 Howdy, At the Network Receive Performance working group at BSDCan we covered a = narrower set of topics than we normally do, which seems to have resulted in a reasonably sized = work list for improving our systems in this area. The main issues relate to getting a good API = that addresses multi-queue NICs. The notes are on the WIki page as well as reproduced here. Best, George https://wiki.freebsd.org/201305DevSummit/NetworkReceivePerformance The discussion opened with an attempt to constrain the problem we were = trying to solve, including pointing out that any KPI/API suggested = needed to be achievable in the next six months. Some of the existing solutions to the problem of talking to hardware = with multiple queues, which all high end NICs currently have, were: =95 Connection Groups =95 Not really a KPI =95 RSS vs. Flow Table is an issue to solve, we have = things for the former, but little for the latter =95 Socket affinity is also an issue =95 NAPI =95 This is an APi in Linux. It uses upcalls. =95 Flow table mapping. Chelsio may have some of this. =95 SRIO =95 VLL Cloner There are several ways to map flows, including: 4 tuple, MAC filter, = arbitrary offset. An API that only handles offset, length, value is too = simple from the standpoint of getting the right data into the hardware. = We need something more rich on the kernel side of the API to that driver = writers don't have to figure out our intentions. Some methods that a good KPI/API ought to have include: =95 Query Device for information about its queues, including how = many exist, and how they are mapped to other resources, including CPU = and memory =95 Map CPUID to a Flow =95 Setup RSS =95 Request RxRing local memory =95 Solaris Mapping API might be a way to go = (http://www.oracle.com/technetwork/articles/servers-storage-admin/crossbow= setup-191326.pdf) =95 Some consumers of such an API include: Performance, affinity, = virtualization, policy, kernel bypass, QoS, and VIMAGE. We have two patches, for different bits, to start from including Vijay's = [RobertWatson] and Randall's [RandallStewart], [GeorgeNevilleNeil] We need quite a few things, including: =95 Per connection flow table =95 Describing queues in the stack such that we can expose = interesting parts via netstat. =95 Packet Batching. This was not overwhelmingly popular. A straw person API includes: =95 MBUF Flag =95 Hash Value =95 The whole thing may be used as opaque =95 Used by the stack for inpcb =95 Get number of buckets =95 Map bucket to RSS =95 Map queue/ithread to CPU =95 Get width of the hash =95 RSS get CPU =95 RSS get hash algo =95 Pick hash inputs =95 Get and set key =95 Rebalance =95 Software hash table =95 Query queue length =95 Get queue affinity =95 Set mask (CPUSET) on socket =95 Set policy on CPU/socket =95 Queue event reporting =95 Load distrubtion stats From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 10 00:18:14 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1793CE2B; Mon, 10 Jun 2013 00:18:14 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [199.48.134.227]) by mx1.freebsd.org (Postfix) with ESMTP id EC0D810B0; Mon, 10 Jun 2013 00:18:13 +0000 (UTC) Received: from glenbarber.us (kaos.glenbarber.us [71.224.221.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id 0EE3423F848; Sun, 9 Jun 2013 20:18:12 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.8.3 onyx.glenbarber.us 0EE3423F848 Authentication-Results: onyx.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Sun, 9 Jun 2013 20:18:10 -0400 From: Glen Barber To: George Neville-Neil Subject: Re: Beyond Buildworld Dev Summit Working Group Report Message-ID: <20130610001810.GR13292@glenbarber.us> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="VjP/dwTbBl6I9PQk" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: hackers@freebsd.org, "devsummit@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 00:18:14 -0000 --VjP/dwTbBl6I9PQk Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Just to give status update: On Sun, Jun 09, 2013 at 05:02:22PM -0400, George Neville-Neil wrote: > =E2=80=A2 Kerberos build issue [GlenBarber] Work in progress, but the upshot is that if you build/install userland with WITHOUT_KERBEROS set, you cannot easily get back. > =E2=80=A2 Crochet with VM images [TimKeintzle], [GlenBarber], [ColinPerc= ival] Tim gave me a few pointers to how he is generating VM images. In the meantime, I am using qemu-img (from emulators/qemu-devel) thanks to Sean Bruno pointing me in the right direction, to generate preinstalled VM images. http://lists.freebsd.org/pipermail/freebsd-announce/2013-May/001478.html Glen --VjP/dwTbBl6I9PQk Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQEcBAEBCAAGBQJRtRtCAAoJEFJPDDeguUajuZ0H/Rv7YhFmswak9SpEwlB+G5MW s/nnfdcLkZQYZjRYIpg4RPpFOCBKkcTwq63iOtfqR6UxBomHBJ/0r+aBN7yABQKk w+xirJV0a3eaSjMy6aiI5JxsblEpvew8aN/3OddB7Pph9uXPV9ftr3GdJeYxpEut 0nN1+qqh9Qh+d1RiW0uHgHDskAvWkJm2vB4U8lwzQUT0nbF6rCBuPeL4s5Rwk+av +l+0BbLjqWgK05hV0xJMap45Hu9+xgWHwrHNgsIpqR2QUwe47kFPtRuhj/a+Q6VH Pc43GjDlBqc5x3WhmMloc8sRc2boEG3p6wX3Hu1aezdOHlC8Td6IwonRe8aRWqA= =x0fz -----END PGP SIGNATURE----- --VjP/dwTbBl6I9PQk-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 10 08:22:05 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F07775F9 for ; Mon, 10 Jun 2013 08:22:05 +0000 (UTC) (envelope-from florent@peterschmitt.fr) Received: from peterschmitt.fr (peterschmitt.fr [5.135.177.31]) by mx1.freebsd.org (Postfix) with ESMTP id BB497124C for ; Mon, 10 Jun 2013 08:22:05 +0000 (UTC) Received: from [172.29.180.39] (unknown [194.214.114.46]) by peterschmitt.fr (Postfix) with ESMTPSA id 716B1A716 for ; Mon, 10 Jun 2013 10:22:01 +0200 (CEST) Message-ID: <51B58CFC.9060300@peterschmitt.fr> Date: Mon, 10 Jun 2013 10:23:24 +0200 From: Florent Peterschmitt User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130518 Icedove/17.0.5 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: A way to switch off nVidia discrete cards ? References: <51B2735A.4030201@peterschmitt.fr> In-Reply-To: <51B2735A.4030201@peterschmitt.fr> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2MXCRBPXHBOBARDHKPFWD" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 08:22:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2MXCRBPXHBOBARDHKPFWD Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello guys, I just found how to disable (my) nVidia Optimus card. With the help of: https://github.com/mkottman/acpi_call/ Peter Wu from bbswitch sysutils/acpi_calls cd /usr/ports/sysutils/acpi_calls && make install clean kldload acpi_call acpi_call -d /dev/acpi -p "\_SB.PCI0.PEG0.PEGP._OFF" nVidia card is on 1:0:0 port. It's just fine now, I can use FreeBSD on my desktop without the need of a nuclear power plant ! PS: I've also installed nvidia kernel module and loaded it, I don't know if it works without. If you know someone using this crappy hardware, try an acpi call ;) --=20 Florent Peterschmitt | Please: florent@peterschmitt.fr | * Avoid HTML/RTF in E-mail +33 (0)6 64 33 97 92 | * PDF for documents http://florent.peterschmitt.fr | Thank you :) ------enig2MXCRBPXHBOBARDHKPFWD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQEcBAEBAgAGBQJRtYz8AAoJEMtO2Sol0IImK7gH/0yYsRnIffKoojWzrut6Hd4H c9PzsKttcDZPpaT1XdIjQI7ryy6JKZX21zdqqrzIT85hrQgUonSGCaj8Do7954ra IngE29u3LQ4pYWcvcqYwNAzPs7uA0jxp4bzNh3I1+DqE1Wza0KqT2kaiaKEFgphk 0WspxhdtULGmEP1AThXT6eSCVEBMbFz0IAYwtpW8GHOVIpUT//hXu47O9Inm7n4q 35UFaNx0CQg2DtoBhBHEgITHd+bt/yrbHbpgsBJcbx4sIRISeNkfmZBAyBEA3FOq 6QGiTYq2zk/csp83UwGfZj64ZSdJMqc4BMX0xEyAuSu7SeKn8EN4y6KmBvc2I/0= =CoYK -----END PGP SIGNATURE----- ------enig2MXCRBPXHBOBARDHKPFWD-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 10 13:31:05 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D16CDD17; Mon, 10 Jun 2013 13:31:05 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-qe0-f50.google.com (mail-qe0-f50.google.com [209.85.128.50]) by mx1.freebsd.org (Postfix) with ESMTP id 7309B183A; Mon, 10 Jun 2013 13:31:05 +0000 (UTC) Received: by mail-qe0-f50.google.com with SMTP id f6so4013271qej.37 for ; Mon, 10 Jun 2013 06:30:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=/oJm3gqQ/csgqtJU5eaTMX0digT6R92GAdV1pWDVQLA=; b=xX/9KLP4LFmCdTMoJZbxpgrzXSQmpRC4ZsEnMfGsAR6r669TSczBOKbZ4Ay78zE1fi UzEonVP3UPhOgY94RjET45NYxE5vQgtRaSnbN9zlKKi0L6E0oMlsbnyVi7gUJFfiaKs7 8A32Vk9DA5Hamqok9eFJjRVJ0pQCD19M9q/HkbTzY8rNXpoQS/zsvxoU8NuBe+K83uEA oRKd/UtK9gAaJHK7zfg+tZ+AMiGXF3iyAn4OZ33FrVEK2N2aIxgLu5UxV9VlfExk0pvu FNkUgdgrXR9r+6r9re2SeKIMSLt3atIGBrMfQXjwh3dU6C+EI62t5qWG+6qB2WQeG93J OClw== MIME-Version: 1.0 X-Received: by 10.229.234.136 with SMTP id kc8mr4011063qcb.44.1370871059276; Mon, 10 Jun 2013 06:30:59 -0700 (PDT) Sender: ermal.luci@gmail.com Received: by 10.49.51.8 with HTTP; Mon, 10 Jun 2013 06:30:59 -0700 (PDT) In-Reply-To: <4F344CE4.301@freebsd.org> References: <20120131110204.GA95472@onelab2.iet.unipi.it> <20120208133559.GK13554@FreeBSD.org> <20120208140921.GM13554@glebius.int.ru> <4F344CE4.301@freebsd.org> Date: Mon, 10 Jun 2013 15:30:59 +0200 X-Google-Sender-Auth: 9291DsBy8Kt-LWuiE0SBVyN47Pg Message-ID: Subject: Re: [PATCH] multiple instances of ipfw(4) From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 13:31:06 -0000 Hello, reviving this old thread since i had time to bring the patch to FreeBSD 10 and unified the whole controlling under ipfw(8) binary. For reminder, the patch located at [1] provides multiple instances for ipfw(4). Basically you can control which interfaces belong to which context/ruleset to make maintaining easier. Also it gives more flexibility in general to ipfw(4) for various scenarios. It works by initializing a context of ipfw(4) and assigning specific interfaces explicitly by administrator to each instance. The context is not lost even on interface destruction and recreation, based on interface name match. Upon entering ipfw(4) processing the configured context/instance for that interface is selected if none no filtering is done. Most of the patch is rather straight forward and only some intrusive changes to ipfw NAT KPI, in kernel implementation is done to remove a global variable referring to the active instance and passing it explicitly. You can create a instance of ipfw by running: ipfw zone 1 create Add a member with ipfw zone 1 madd em0 ipfw zone 1 madd vlan0 Remove members with ipfw zone 1 mdel em0 Also destroy an instance by: ipfw zone 1 destroy All the other operations on ipfw(4) will be the same as before just require the -x $context argument added for each of them. The patch uses all the IP_FW3 option commands to avoid changes in other areas apart ipfw(4) related sources. Any objections on pushing this into FreeBSD? [1] https://github.com/pfsense/pfsense-tools/blob/master/patches/RELENG_10_0/CP_multi_instance_ipfw.diff -- Ermal From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 10 15:01:36 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E105CEA9; Mon, 10 Jun 2013 15:01:36 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) by mx1.freebsd.org (Postfix) with ESMTP id CDC671D57; Mon, 10 Jun 2013 15:01:35 +0000 (UTC) Received: by mail-lb0-f171.google.com with SMTP id 13so3175036lba.16 for ; Mon, 10 Jun 2013 08:01:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=TkAzaGnQ6XPK2bhrnUGfI2WXJV2/Uyin4bnJH/ffcH4=; b=0mJu5c0VnApIAPm3CE10laTnHQ4dgW7HTaU+bcWKTT4gatKYYezR7W2bQIpFi97T90 uZJZuGm+Ar0Wo3UzJcfs46YenWD3DzEYqONLnCJKEItHc8YRrovJg+YrXPTxBbZ1ced+ fZ84Gm1lnh6pbgSjgaAnN129fNBwkUHpsOFB4H9TdQsqbVLAL/3Q8qhc1bjkkhE347f4 HsJqs7mNSvpj8mIweIPP8w3mP2UdNsPLLV49zVNLwvFwRB6gOby7HizlHCmyWqpu1U3y WqTTu73gpal5T+Pisz/+frrwO2QzHtamA1mNfmTli/FF2vdrU/9cEnX7YvDBgubEVLiq Y0Gw== MIME-Version: 1.0 X-Received: by 10.152.4.101 with SMTP id j5mr5177446laj.67.1370876488944; Mon, 10 Jun 2013 08:01:28 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.174.227 with HTTP; Mon, 10 Jun 2013 08:01:28 -0700 (PDT) In-Reply-To: References: <20120131110204.GA95472@onelab2.iet.unipi.it> <20120208133559.GK13554@FreeBSD.org> <20120208140921.GM13554@glebius.int.ru> <4F344CE4.301@freebsd.org> Date: Mon, 10 Jun 2013 17:01:28 +0200 X-Google-Sender-Auth: UynPmGxCz0DkLZtzZyOr0Rx40Po Message-ID: Subject: Re: [PATCH] multiple instances of ipfw(4) From: Luigi Rizzo To: =?ISO-8859-1?Q?Ermal_Lu=E7i?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 15:01:37 -0000 On Mon, Jun 10, 2013 at 3:30 PM, Ermal Lu=E7i wrote: > Hello, > > reviving this old thread since i had time to bring the patch to FreeBSD 1= 0 > and unified the whole controlling under ipfw(8) binary. > > For reminder, the patch located at [1] provides multiple instances for > ipfw(4). > Basically you can control which interfaces belong to which context/rulese= t > to make maintaining easier. > > ... > Any objections on pushing this into FreeBSD? > > > [1] > > https://github.com/pfsense/pfsense-tools/blob/master/patches/RELENG_10_0/= CP_multi_instance_ipfw.diff > > > if i understand well, this has no runtime overhead as the ifp has the index of the context it refers to ? Or you need an additional IPFW_CTX_RLOCK() ? Comments on the control/config path: - in ipfw_ctl(), handling IP_FW_CTX_GET i am worried that you might overflow the temporary buffer when building the list. You compute the length under rlock, release the lock, malloc(), then fill the list without checking if the total size is still correct. This kind of code is terribly boring to write, but essentially you need a bound check in the second loop and possibly retry if you notice that you need more memory. "ipfw show" addresses the problem by failing and requesting the user application to pass a larger buffer. - similarly, how do you guarantee that deleting a context while a packet is under processing does not cause dereferencing a NULL pointer ? cheers luigi while=20 > -- > Ermal > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > --=20 -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+------------------------------- From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 10 15:58:45 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 869BC455; Mon, 10 Jun 2013 15:58:43 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id A3B081041; Mon, 10 Jun 2013 15:58:43 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id F26DAB9B8; Mon, 10 Jun 2013 11:58:42 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Subject: Re: Fix MNAMELEN or reimplement struct statfs Date: Mon, 10 Jun 2013 11:52:17 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <51B3B59B.8050903@erdgeist.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201306101152.17966.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 10 Jun 2013 11:58:43 -0400 (EDT) Cc: mdf@freebsd.org, Dirk Engling X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 15:58:45 -0000 On Saturday, June 08, 2013 9:36:27 pm mdf@freebsd.org wrote: > On Sat, Jun 8, 2013 at 3:52 PM, Dirk Engling wrote: > > > The arbitrary value > > > > #define MNAMELEN 88 /* size of on/from name bufs */ > > > > struct statfs { > > [...] > > char f_mntfromname[MNAMELEN];/* mounted filesystem */ > > char f_mntonname[MNAMELEN]; /* directory on which mounted */ > > }; > > > > currently bites us when trying to use poudriere with errors like > > > > 'mount: tmpfs: File name too long' > > > > > > /poudriere/data/build/91_RELEASE_amd64-REALLY-REALLY-LONG- JAILNAME/ref/wrkdirs > > > > The topic has been discussed several times since 2004 and has been > > postponed each time, the last time when it hit zfs users: > > > > http://lists.freebsd.org/pipermail/freebsd-fs/2010-March/007974.html > > > > So I'd like to point to the calendar, it's 2013 already and there's > > still a static arbitrary (and way too low) limit in one of the core > > areas of the vfs code. > > > > So I'd like to bump the issue and propose either making f_mntfromname a > > dynamic allocation or just increase MNAMELEN, using 10.0 as water shed. > > > > Gleb Kurtsou did this along with the ino64 GSoC project. Unfortunately, > both he and I hit ENOTIME due to the job that pays the bills and it's > never made it back to the main repository. > > IIRC, though, the only reason for doing it with 64-bit ino_t is that he'd > already finished changing the stat/dirent ABI so what was one more. I > think he went with 1024 bytes, which also necessitated not allocating > statfs on the stack for the kernel. He also fixed a few other things since changing this ABI is so invasive IIRC. This really is the right fix for this. Is it in an svn branch that can be updated and a new patch generated? -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 10 16:44:35 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5F48A4C6 for ; Mon, 10 Jun 2013 16:44:35 +0000 (UTC) (envelope-from vagner@bsdway.ru) Received: from bsdway.ru (bsdway.ru [62.109.17.46]) by mx1.freebsd.org (Postfix) with ESMTP id C5636131E for ; Mon, 10 Jun 2013 16:44:34 +0000 (UTC) Received: from localhost ([188.134.95.3]) (authenticated bits=0) by bsdway.ru (8.14.4/8.14.5) with ESMTP id r5AGiWw2085786 for ; Mon, 10 Jun 2013 20:44:32 +0400 (MSD) (envelope-from vagner@bsdway.ru) Date: Mon, 10 Jun 2013 20:44:25 +0400 From: Vagner To: FreeBSD hackers Mail List Subject: Where is stack of program? Message-ID: <20130610164425.GA2966@vagner-wrk.bsdway.ru> Mail-Followup-To: FreeBSD hackers Mail List MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bsdway.ru [62.109.17.46]); Mon, 10 Jun 2013 20:44:32 +0400 (MSD) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 16:44:35 -0000 Hi! I need method of finding in struct vm_map or vm_object segments of memory which is situated in the stack. Can you help me please? -- Respectfully, Stanislav Putrya System administrator FotoStrana.Ru Ltd. ICQ IM: 328585847 Jabber-GoogleTalk: root.vagner mob.phone SPB: +79215788755 mob.phone RND: +79525600664 email: vagner[at]bsdway.ru email: putrya[at]playform.ru email: root.vagner[at]gmail.com site: bsdway.ru site: fotostrana.ru ---------------------------------------- ( ) ASCII ribbon campaign X - against HTML, vCards and / \ - proprietary attachments in e-mail From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 10 16:52:03 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 21FEB632; Mon, 10 Jun 2013 16:52:03 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-qe0-f48.google.com (mail-qe0-f48.google.com [209.85.128.48]) by mx1.freebsd.org (Postfix) with ESMTP id B35071368; Mon, 10 Jun 2013 16:52:02 +0000 (UTC) Received: by mail-qe0-f48.google.com with SMTP id 2so4185020qea.35 for ; Mon, 10 Jun 2013 09:52:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=26YHp/W4zVGAu7j5J7AtFMQcl2Lzstj0rFpC2qovtjI=; b=Kg29vaHviMWw3DncQHdTHjO4QVCg1Z0LOIYLc9bvsxp95464cSVkHCy7o49KioYmR7 qrPigr5iqAx8+5kd/KS7h8HSibUfGzdl4i46g4aev16zZt4Tm6YYc+1nv/YpkCe+scNh eZs42IhXWi0PTUf+Z4Q7XU6rjUXAUCa45gAj/eQFr9NqwV3FYk35cA5cmkjJAooJ4nFM lR3tl53TfEUMssY23+PCQts53ge8oEYSutRU5u2ajUb69FPB1zM12UMAu5ZvWDwEOy1I x0HdvSHYrOpMaug/JAtv34ZmxKGxwpj/+/yLmFgC9a+vo41YzAPXM92tBISKKuZMZNS1 RZ3Q== MIME-Version: 1.0 X-Received: by 10.229.144.14 with SMTP id x14mr4085767qcu.36.1370883121423; Mon, 10 Jun 2013 09:52:01 -0700 (PDT) Sender: ermal.luci@gmail.com Received: by 10.49.51.8 with HTTP; Mon, 10 Jun 2013 09:52:01 -0700 (PDT) In-Reply-To: References: <20120131110204.GA95472@onelab2.iet.unipi.it> <20120208133559.GK13554@FreeBSD.org> <20120208140921.GM13554@glebius.int.ru> <4F344CE4.301@freebsd.org> Date: Mon, 10 Jun 2013 18:52:01 +0200 X-Google-Sender-Auth: J4_vl2pAQ2S3gdwxfsAffdz3t-c Message-ID: Subject: Re: [PATCH] multiple instances of ipfw(4) From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 16:52:03 -0000 On Mon, Jun 10, 2013 at 5:01 PM, Luigi Rizzo wrote: > > > > On Mon, Jun 10, 2013 at 3:30 PM, Ermal Lu=E7i wrote: > >> Hello, >> >> reviving this old thread since i had time to bring the patch to FreeBSD = 10 >> and unified the whole controlling under ipfw(8) binary. >> >> For reminder, the patch located at [1] provides multiple instances for >> ipfw(4). >> Basically you can control which interfaces belong to which context/rules= et >> to make maintaining easier. >> >> > ... > > > >> Any objections on pushing this into FreeBSD? >> >> >> [1] >> >> https://github.com/pfsense/pfsense-tools/blob/master/patches/RELENG_10_0= /CP_multi_instance_ipfw.diff >> >> >> > > if i understand well, this has no runtime overhead as the ifp has > the index of the context it refers to ? > Or you need an additional IPFW_CTX_RLOCK() ? > Theoretically you would need for correctness the read lock. It has never been hit in pfSense hence no further investigation on it has been done. It can be made even a read mostly lock or to prevent the race the write lock of the pfil hooks so no packets are passed through?! > > Comments on the control/config path: > - in ipfw_ctl(), handling IP_FW_CTX_GET i am worried that you might > overflow the temporary buffer when building the list. You compute > the length under rlock, release the lock, malloc(), then fill the > list without checking if the total size is still correct. > This kind of code is terribly boring to write, but essentially > you need a bound check in the second loop and possibly > retry if you notice that you need more memory. > "ipfw show" addresses the problem by failing and requesting the > user application to pass a larger buffer. > Yeah that probably can be fixed. During implementation it was considered enough rare operation to not justify further thought. > > - similarly, how do you guarantee that deleting a context while > a packet is under processing does not cause dereferencing a > NULL pointer ? > Presently, none, but as i said during instance/context operation a write lock on the pfil hook can be taken? That should prevent the issue altogether and remove the requirement of having to read lock the fast path. If you agree with the above i can redo the patch again with the above changes for review? > cheers > luigi > > while >> -- >> Ermal >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > > > > -- > -----------------------------------------+------------------------------- > Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione > http://www.iet.unipi.it/~luigi/ . Universita` di Pisa > TEL +39-050-2211611 . via Diotisalvi 2 > Mobile +39-338-6809875 . 56122 PISA (Italy) > -----------------------------------------+------------------------------- > --=20 Ermal From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 10 17:27:34 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 984419FC; Mon, 10 Jun 2013 17:27:34 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 555E9173F; Mon, 10 Jun 2013 17:27:34 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id B21167300B; Mon, 10 Jun 2013 19:30:36 +0200 (CEST) Date: Mon, 10 Jun 2013 19:30:36 +0200 From: Luigi Rizzo To: Ermal Lu?i Subject: Re: [PATCH] multiple instances of ipfw(4) Message-ID: <20130610173036.GA916@onelab2.iet.unipi.it> References: <20120131110204.GA95472@onelab2.iet.unipi.it> <20120208133559.GK13554@FreeBSD.org> <20120208140921.GM13554@glebius.int.ru> <4F344CE4.301@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-net , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 17:27:34 -0000 On Mon, Jun 10, 2013 at 06:52:01PM +0200, Ermal Lu?i wrote: > On Mon, Jun 10, 2013 at 5:01 PM, Luigi Rizzo wrote: ... > > if i understand well, this has no runtime overhead as the ifp has > > the index of the context it refers to ? > > Or you need an additional IPFW_CTX_RLOCK() ? > > > > Theoretically you would need for correctness the read lock. > It has never been hit in pfSense hence no further investigation on it has > been done. > It can be made even a read mostly lock or to prevent the race the write > lock > of the pfil hooks so no packets are passed through?! adding another lock (even just a read lock) around invocations is undesirable in my opinion. I'd rather check if there is already some other lock which is already held so we can use it to protect the list of contexts. > > Comments on the control/config path: > > - in ipfw_ctl(), handling IP_FW_CTX_GET i am worried that you might > > overflow the temporary buffer when building the list. You compute > > the length under rlock, release the lock, malloc(), then fill the > > list without checking if the total size is still correct. > > This kind of code is terribly boring to write, but essentially > > you need a bound check in the second loop and possibly > > retry if you notice that you need more memory. > > "ipfw show" addresses the problem by failing and requesting the > > user application to pass a larger buffer. > > > > Yeah that probably can be fixed. > During implementation it was considered enough rare operation to not > justify further thought. well, unlike the previous problem (locking), this has a very simple fix and no performance implications so there are really no excuses... > If you agree with the above i can redo the patch again with the above > changes for review? i would just be happy with the fix to IP_FW_CTX_GET and a big red flashing comment in the place where the context is being accessed. Or if you can find another lock to recycle, fine. cheers luigi From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 11 04:25:51 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EAE3B9A5; Tue, 11 Jun 2013 04:25:51 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id B296419C2; Tue, 11 Jun 2013 04:25:50 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r5B4Piea022926; Tue, 11 Jun 2013 04:25:44 GMT (envelope-from kientzle@freebsd.org) Received: from [192.168.2.123] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id v49iv8fhrn6y7ni2c96h6i6sdi; Tue, 11 Jun 2013 04:25:44 +0000 (UTC) (envelope-from kientzle@freebsd.org) Subject: Re: Beyond Buildworld Dev Summit Working Group Report Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Tim Kientzle In-Reply-To: Date: Mon, 10 Jun 2013 21:25:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8FC4A83C-0C91-471A-9962-1A67FE115A67@freebsd.org> References: To: George Neville-Neil X-Mailer: Apple Mail (2.1283) Cc: hackers@freebsd.org, "devsummit@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 04:25:52 -0000 On Jun 9, 2013, at 2:02 PM, George Neville-Neil wrote: > Howdy, >=20 > The Beyond Buildworld working group discussed many subjects around our = build system, including > upcoming changes to do a better job of addressing embedded systems, = the integration of bmake, > and the need for better incremental build support. The full notes are = on the wiki and=20 > also pasted at the bottom of this email. >=20 > Best, > George >=20 > https://wiki.freebsd.org/201305DevSummit/Buildworld >=20 > This section includes volunteers or contact points as links. >=20 > =95 uboot ports [DianeBruce] > =95 compiler patches vs. gccc on Linux [TimKeintzle] Diane helped me put together a first port for U-Boot (BeagleBone with EABI). Still need to get it committed, then use it as a template for other U-Boot ports. (E.g., RPi, ZedBoard, etc.) If other folks are working on U-Boot patches to boot FreeBSD on other hardware, it would be nice to get those into ports as well. > =95 ubloader not on ELF [Ian] I looked into making ubldr self-relocating (so that it could just be loaded at an arbitrary address and run without modification). Enabling PIC in the compiler goes a long ways, but the loader libraries rely heavily on static data references to code. These would have to either be rewritten or generated at run-time to make the whole loader able to run at an arbitrary address. > =95 Crochet with VM images [TimKeintzle], [GlenBarber], = [ColinPercival] Per Colin, there's no way for "mere mortals" to upload machine images to Amazon, so there's little point in pursuing that. I did recently add support to Crochet for building VMWare VM images directly. Works pretty well; I've been using it to build throw-away images for testing. This goes a step further than what Glen has recently announced; so far, he's just building the VMDK disk image, Crochet fills in the rest of the VM configuration files. It should be routine to duplicate the approach to support other VM environments (e.g., Parallels, VirtualBox, OFA). My time is limited but I'm happy to assist if someone else wants to work on it. Tim From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 11 05:02:41 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BD135F9B; Tue, 11 Jun 2013 05:02:41 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [IPv6:2607:fc50:1000:c200::face]) by mx1.freebsd.org (Postfix) with ESMTP id 9344E1B71; Tue, 11 Jun 2013 05:02:41 +0000 (UTC) Received: from glenbarber.us (70.15.88.86.res-cmts.sewb.ptd.net [70.15.88.86]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id 988ED23F848; Tue, 11 Jun 2013 01:02:36 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.8.3 onyx.glenbarber.us 988ED23F848 Authentication-Results: onyx.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Tue, 11 Jun 2013 01:02:34 -0400 From: Glen Barber To: Tim Kientzle Subject: Re: Beyond Buildworld Dev Summit Working Group Report Message-ID: <20130611050234.GB1627@glenbarber.us> References: <8FC4A83C-0C91-471A-9962-1A67FE115A67@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="24zk1gE8NUlDmwG9" Content-Disposition: inline In-Reply-To: <8FC4A83C-0C91-471A-9962-1A67FE115A67@freebsd.org> X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: George Neville-Neil , hackers@freebsd.org, "devsummit@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 05:02:41 -0000 --24zk1gE8NUlDmwG9 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 10, 2013 at 09:25:39PM -0700, Tim Kientzle wrote: > > =E2=80=A2 Crochet with VM images [TimKeintzle], [GlenBarber], [ColinPe= rcival] >=20 > Per Colin, there's no way for "mere mortals" to upload machine > images to Amazon, so there's little point in pursuing that. >=20 > I did recently add support to Crochet for building VMWare VM images > directly. Works pretty well; I've been using it to build throw-away > images for testing. This goes a step further than what Glen > has recently announced; so far, he's just building the VMDK disk > image, Crochet fills in the rest of the VM configuration files. >=20 > It should be routine to duplicate the approach to support other > VM environments (e.g., Parallels, VirtualBox, OFA). My time is > limited but I'm happy to assist if someone else wants to work on it. >=20 I do intend to look at how Crochet does this, because I think your implementation is far more user friendly and cross-application compatible. I'll certainly pick your brain on it, if you don't mind. Unfortunately, time has been the big issue for me lately, in addition to some unexpected out-of-town-ness this week. Glen --24zk1gE8NUlDmwG9 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQEcBAEBCAAGBQJRtq9qAAoJEFJPDDeguUajwtMH/0B9aE37gTFx7kEMkDPOAFOJ 6noiXtGvRSLRLJXHFQ2Ps09yLVkKd+rX8+2QAxwbhO5AA/Z7sfTAKGzZQlJVfuv6 aGurgnBsnHzADsCKamw0V/11sBq2K85xjMvAF1wz4MZ1LOcYX0oSY2fM40N6ptST mvDfGBFSVoDESobYDOS153lKPVji6YtgJRZO5kqsmkpFMn9NFz/bx/d/zW8W0TSC K33Uxwt8cvk/PUoCndMZ82dBiqLsbok4SNSoupQvIPyNCV2FtoBivTSSX40h5tC7 v+BC5j2EFFQPmXR+Lla1wOBYL3I0+eUeAXDS8uZzYp8IZ/IOxk777RII16ge2bM= =E/UX -----END PGP SIGNATURE----- --24zk1gE8NUlDmwG9-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 11 05:45:52 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 245A84FE for ; Tue, 11 Jun 2013 05:45:52 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 909C91CA1 for ; Tue, 11 Jun 2013 05:45:51 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r5B5jiZe094767 for ; Tue, 11 Jun 2013 08:45:44 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r5B5jiZe094767 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r5B5jiPc094765 for freebsd-hackers@freebsd.org; Tue, 11 Jun 2013 08:45:44 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 11 Jun 2013 08:45:44 +0300 From: Konstantin Belousov To: FreeBSD hackers Mail List Subject: Re: Where is stack of program? Message-ID: <20130611054544.GI3047@kib.kiev.ua> References: <20130610164425.GA2966@vagner-wrk.bsdway.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Hb99djDM/33ECHXq" Content-Disposition: inline In-Reply-To: <20130610164425.GA2966@vagner-wrk.bsdway.ru> User-Agent: Mutt/1.5.21 (2010-09-15) 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 version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 05:45:52 -0000 --Hb99djDM/33ECHXq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Jun 10, 2013 at 08:44:25PM +0400, Vagner wrote: > Hi! > I need method of finding in struct vm_map or vm_object segments of > memory which is situated in the stack. > Can you help me please? Note that the stack is per-thread. The concept is somewhat machine-specific, some architectures utilize two stacks, on some the stack is purely software convention. You did not specified what context your code is to be run, e.g. is it kernel or user space ? Assuming it is kernel since you mentioned vm_something. The least error prone route is the thread context (frame) -> tf_esp on i386 (or tf_rsp on amd64) -> lookup of the map entry in the process p_vmspace. In reality, the stack is often fragmented, since the stack grow code does not coalesce the adjacent grow-down map entries. --Hb99djDM/33ECHXq Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJRtrmHAAoJEJDCuSvBvK1Bp2MP/RU9H5Tk8jOV7O7duw2OEVxV 9X2Hvt7KyhO0oqnbXEtjUhLIuhr6DnXNn8rG9amtW5asflPxKpGfm6SAJigMHJ6m e0u+vxoywiswcoDW9s01z3DWjdcLaHN70juYPYgO2RLNB2tni7S3rWxd4c3aJXbk o2Q4Mh8Pfiqu+Lql42MFUO8wxd2I1vmdMgceaP3+W6ydobcDjdtH/xIqjs745EI2 3DJQ8F1Nf9x8+42D0jkMZ9kfCxmI2fg7XLZmod2l6jUTvET6WivA08RDMPgjG3AT aj6TmgYELA+N78p3AYiuw+J/E7+RXfMN2myxRnLVytiWO2RKc8TxE48O+tOpre7H iWLhoTBZX8TKsbHpldV4DcVpedISBd0B3dadEhdUig4aaBIXaihrDaaM63nDGaho zjQMLkXWJf3nQ/H07hQlMq5YckNGTWzcmN/UwR+Z1o8dC7nID+S1y6iqRbk0imga WP7lYzhfXesEPpX53JcfYPrAmsTYu7/IxyMivo+xlJ5w28+FejoIk605hx2tORuR uIBSKONb5VwIcQr4m4aZ8GcrFxNdlDBUpaS4ow6qaMap9s6DRBItHjmiN80/n3be 7LQRuQscOE7mo03X8FAW6jmqES9wK9XVe6yvpCWU8ixmC+PfI78IqZxZzMUG37f7 RFAzyVQPUWFN5Kwhlnba =WvAu -----END PGP SIGNATURE----- --Hb99djDM/33ECHXq-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 11 08:05:48 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C11F1410 for ; Tue, 11 Jun 2013 08:05:48 +0000 (UTC) (envelope-from vagner@bsdway.ru) Received: from bsdway.ru (bsdway.ru [62.109.17.46]) by mx1.freebsd.org (Postfix) with ESMTP id 32C2D126A for ; Tue, 11 Jun 2013 08:05:45 +0000 (UTC) Received: from localhost (off-180.addr.fotocdn.net [193.105.179.180]) (authenticated bits=0) by bsdway.ru (8.14.4/8.14.5) with ESMTP id r5B85ckH051129; Tue, 11 Jun 2013 12:05:39 +0400 (MSD) (envelope-from vagner@bsdway.ru) Date: Tue, 11 Jun 2013 12:05:38 +0400 From: Vagner To: Konstantin Belousov Subject: Re: Where is stack of program? Message-ID: <20130611080538.GA2645@vagner-wrk.bsdway.ru> Mail-Followup-To: Konstantin Belousov , FreeBSD hackers Mail List References: <20130610164425.GA2966@vagner-wrk.bsdway.ru> <20130611054544.GI3047@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130611054544.GI3047@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bsdway.ru [62.109.17.46]); Tue, 11 Jun 2013 12:05:39 +0400 (MSD) Cc: FreeBSD hackers Mail List X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 08:05:48 -0000 On 08:45 Tue 11 Jun , Konstantin Belousov wrote: > On Mon, Jun 10, 2013 at 08:44:25PM +0400, Vagner wrote: > > Hi! > > I need method of finding in struct vm_map or vm_object segments of > > memory which is situated in the stack. > > Can you help me please? > > Note that the stack is per-thread. The concept is somewhat machine-specific, > some architectures utilize two stacks, on some the stack is purely software > convention. > > You did not specified what context your code is to be run, e.g. is > it kernel or user space ? Assuming it is kernel since you mentioned > vm_something. The least error prone route is the thread context (frame) > -> tf_esp on i386 (or tf_rsp on amd64) -> lookup of the map entry in the > process p_vmspace. > > In reality, the stack is often fragmented, since the stack grow code > does not coalesce the adjacent grow-down map entries. I asket the question because in my servers run very large daemons (writed their own). Then daemons get signal for create coredump, downtime approximately 1h. This is very long for daemons in production. Often in coredump for debug need only stack and current frame of code, but in function, which initialise for create dump of memory haven't this possibility. Linux have /proc/self/coredump_filter for settings what segments included in core file, but in our FreeBSD I don't find this:( Help me for find solution please -- Respectfully, Stanislav Putrya System administrator FotoStrana.Ru Ltd. ICQ IM: 328585847 Jabber-GoogleTalk: root.vagner mob.phone SPB: +79215788755 mob.phone RND: +79525600664 email: vagner[at]bsdway.ru email: putrya[at]playform.ru email: root.vagner[at]gmail.com site: bsdway.ru site: fotostrana.ru ---------------------------------------- ( ) ASCII ribbon campaign X - against HTML, vCards and / \ - proprietary attachments in e-mail From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 11 11:57:35 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8FADFC38; Tue, 11 Jun 2013 11:57:35 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-qa0-x232.google.com (mail-qa0-x232.google.com [IPv6:2607:f8b0:400d:c00::232]) by mx1.freebsd.org (Postfix) with ESMTP id 2DBD51E6A; Tue, 11 Jun 2013 11:57:35 +0000 (UTC) Received: by mail-qa0-f50.google.com with SMTP id l18so2912082qak.9 for ; Tue, 11 Jun 2013 04:57:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=kyAft7s/XLwkghxceoOMrG/LivZ91Ijy0yTzIz2gevE=; b=n2/I4dU2N5EHC892PqN3pS90otNwWcem7BeZc8lxjajgiEEvk1ZyRXZsAnR/scPqLw 3Mxl8qCXjWsb+qKbMSB6+lWou8ccWZjBaJ1VgDDkAh9WXw782Z64aAPAWqb0WaKxiUdW lW/6t31LaBUMqmR9MVbjzDfj7MC5WuJzfl57AKipTzjcqYMAE1arg1eix2mAQn7IknyU MsXgv8RVZbfGe7FnxRe5S4hoR4vnrb+Vp/dNo7iFljoS/P1S0pkRxoryU3JRntrqcJ44 /dMEma++XlwKtp/RBBlct6Br6nIEpVZuz/zPAybPbv/2xLSWeotZ49MNiSIud2OvkyW8 DB8g== MIME-Version: 1.0 X-Received: by 10.229.152.4 with SMTP id e4mr5571136qcw.109.1370951854249; Tue, 11 Jun 2013 04:57:34 -0700 (PDT) Sender: ermal.luci@gmail.com Received: by 10.49.51.8 with HTTP; Tue, 11 Jun 2013 04:57:34 -0700 (PDT) In-Reply-To: <20130610173036.GA916@onelab2.iet.unipi.it> References: <20120131110204.GA95472@onelab2.iet.unipi.it> <20120208133559.GK13554@FreeBSD.org> <20120208140921.GM13554@glebius.int.ru> <4F344CE4.301@freebsd.org> <20130610173036.GA916@onelab2.iet.unipi.it> Date: Tue, 11 Jun 2013 13:57:34 +0200 X-Google-Sender-Auth: ZASgw6JHD5aEzelV4cNDSXhKTVI Message-ID: Subject: Re: [PATCH] multiple instances of ipfw(4) From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 11:57:35 -0000 Hello Luigi, On Mon, Jun 10, 2013 at 7:30 PM, Luigi Rizzo wrote: > On Mon, Jun 10, 2013 at 06:52:01PM +0200, Ermal Lu?i wrote: > > On Mon, Jun 10, 2013 at 5:01 PM, Luigi Rizzo wrote: > ... > > > if i understand well, this has no runtime overhead as the ifp has > > > the index of the context it refers to ? > > > Or you need an additional IPFW_CTX_RLOCK() ? > > > > > > > Theoretically you would need for correctness the read lock. > > It has never been hit in pfSense hence no further investigation on it has > > been done. > > It can be made even a read mostly lock or to prevent the race the write > > lock > > of the pfil hooks so no packets are passed through?! > > adding another lock (even just a read lock) around invocations is > undesirable in my opinion. I'd rather check if there is already > some other lock which is already held so we can use it to protect > the list of contexts. > > > > Comments on the control/config path: > > > - in ipfw_ctl(), handling IP_FW_CTX_GET i am worried that you might > > > overflow the temporary buffer when building the list. You compute > > > the length under rlock, release the lock, malloc(), then fill the > > > list without checking if the total size is still correct. > > > This kind of code is terribly boring to write, but essentially > > > you need a bound check in the second loop and possibly > > > retry if you notice that you need more memory. > > > "ipfw show" addresses the problem by failing and requesting the > > > user application to pass a larger buffer. > > > > > > > Yeah that probably can be fixed. > > During implementation it was considered enough rare operation to not > > justify further thought. > > well, unlike the previous problem (locking), this has a very simple fix > and no performance implications so there are really no excuses... > > > If you agree with the above i can redo the patch again with the above > > changes for review? > > i would just be happy with the fix to IP_FW_CTX_GET and a big red flashing > comment in the place where the context is being accessed. > Or if you can find another lock to recycle, fine. > > cheers > luigi > regenerated patch at the same location https://github.com/pfsense/pfsense-tools/blob/master/patches/RELENG_10_0/CP_multi_instance_ipfw.diff I actually changed some more things to provide a more correct implementation. The only thing about this is that manual page and rc scripts need to be changed for this as well. How you propose to handle this? -- Ermal From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 11 14:54:32 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D2CF3445; Tue, 11 Jun 2013 14:54:32 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id A324218D9; Tue, 11 Jun 2013 14:54:32 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r5BEsVSd025953; Tue, 11 Jun 2013 14:54:31 GMT (envelope-from kientzle@freebsd.org) Received: from [192.168.2.123] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id 7g77xdnp8vct8u55fg4axect7i; Tue, 11 Jun 2013 14:54:31 +0000 (UTC) (envelope-from kientzle@freebsd.org) Subject: Re: Beyond Buildworld Dev Summit Working Group Report Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/signed; boundary="Apple-Mail=_2242A02B-12A6-48B3-B145-7A455009F833"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: Tim Kientzle In-Reply-To: <20130611050234.GB1627@glenbarber.us> Date: Tue, 11 Jun 2013 07:54:29 -0700 Message-Id: References: <8FC4A83C-0C91-471A-9962-1A67FE115A67@freebsd.org> <20130611050234.GB1627@glenbarber.us> To: Glen Barber X-Mailer: Apple Mail (2.1283) Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 14:54:33 -0000 --Apple-Mail=_2242A02B-12A6-48B3-B145-7A455009F833 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jun 10, 2013, at 10:02 PM, Glen Barber wrote: > On Mon, Jun 10, 2013 at 09:25:39PM -0700, Tim Kientzle wrote: >>> =95 Crochet with VM images [TimKeintzle], [GlenBarber], = [ColinPercival] >>=20 >> Per Colin, there's no way for "mere mortals" to upload machine >> images to Amazon, so there's little point in pursuing that. >>=20 >> I did recently add support to Crochet for building VMWare VM images >> directly. Works pretty well; I've been using it to build throw-away >> images for testing. This goes a step further than what Glen >> has recently announced; so far, he's just building the VMDK disk >> image, Crochet fills in the rest of the VM configuration files. >>=20 >> It should be routine to duplicate the approach to support other >> VM environments (e.g., Parallels, VirtualBox, OFA). My time is >> limited but I'm happy to assist if someone else wants to work on it. >>=20 >=20 > I do intend to look at how Crochet does this, because I think your > implementation is far more user friendly and cross-application > compatible. >=20 > I'll certainly pick your brain on it, if you don't mind.=20 Key point: VM images are directories which contain a number of different files. The disk image is just one of those. For VMWare (and others I've looked at), the VM directory contains: * Disk image - this can be a straight disk image (which is what Crochet currently uses) or a structured/sparse/compressed "virtual disk" =20 * Disk descriptor -- this specifies the format of the disk image and the parameters of the virtual disk drive. * VM descriptor -- this describes the rest of the virtual hardware. VMWare seems to be the simplest of the ones I've looked at: the descriptor files are lists of key/value pairs and the VMWare software can boot a VM even from a pretty skeletal definition. It didn't take me very many tries to get Crochet to build a VMWare image that VMWare Fusion was comfortable booting. It helps that the VMWare file formats are pretty well documented: In particular: http://sanbarrow.com Parallels and OFA both use more complex XML configuration files -- everything has an ID and there are lots of cross-references. I've toyed with building Parallels VMs but haven't gotten very far yet. qemu-img seems like a nice tool for generating a virtual disk image, but it doesn't currently know how to create compressed VMWare disks. I've skimmed VMWare's documentation and it doesn't look too hard to build a compressed VMWare disk if someone would like to tackle that. ;-) Tim --Apple-Mail=_2242A02B-12A6-48B3-B145-7A455009F833 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----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) iQEcBAEBAgAGBQJRtzomAAoJEGMNyGo0rfFBq68H/iWlwnyjZtxDAwOOrNOrf5+C 4nx5yGRUXm5uZPqAecQvNs6C8ENZXmDS93woKfsrUcFdYeFJXr+XNCMGaRUFUm/W OuH5ls+aKuM4gWCdSiPiiTgIeeGEvtDoMBj2tNB/1Neq43b4gBS7DA1IeEcbLdoF E1z5uZ3DAtUN+ZjPMtxkONzDum6shtDODNtIlX+uNeKKCMSP0Yxw/8gv9hWOG6j7 E40SX65uhEUyYqsrrlIXlJSO3K4wrB7k/eOAOflKcQz8FYfs2r211ouN0H58E5Ey hnpC5FKdjhCMFK2MIwfqDs9ki8p5J38P3dOik5vkuICYbDH5OmQ3aa3XDZE390s= =v8Zi -----END PGP SIGNATURE----- --Apple-Mail=_2242A02B-12A6-48B3-B145-7A455009F833-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 11 20:21:36 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B587BEDD for ; Tue, 11 Jun 2013 20:21:36 +0000 (UTC) (envelope-from vagner@bsdway.ru) Received: from bsdway.ru (bsdway.ru [62.109.17.46]) by mx1.freebsd.org (Postfix) with ESMTP id 4E6181AB8 for ; Tue, 11 Jun 2013 20:21:35 +0000 (UTC) Received: from localhost ([188.134.95.3]) (authenticated bits=0) by bsdway.ru (8.14.4/8.14.5) with ESMTP id r5BKLR42010823; Wed, 12 Jun 2013 00:21:28 +0400 (MSD) (envelope-from vagner@bsdway.ru) Date: Wed, 12 Jun 2013 00:21:22 +0400 From: Vagner To: Konstantin Belousov , FreeBSD hackers Mail List Subject: Re: Where is stack of program? Message-ID: <20130611202122.GA3348@vagner-wrk.bsdway.ru> Mail-Followup-To: Konstantin Belousov , FreeBSD hackers Mail List References: <20130610164425.GA2966@vagner-wrk.bsdway.ru> <20130611054544.GI3047@kib.kiev.ua> <20130611080538.GA2645@vagner-wrk.bsdway.ru> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="SUOF0GtieIMvvwua" Content-Disposition: inline In-Reply-To: <20130611080538.GA2645@vagner-wrk.bsdway.ru> User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bsdway.ru [62.109.17.46]); Wed, 12 Jun 2013 00:21:28 +0400 (MSD) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 20:21:36 -0000 --SUOF0GtieIMvvwua Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On 12:05 Tue 11 Jun , Vagner wrote: > On 08:45 Tue 11 Jun , Konstantin Belousov wrote: > > On Mon, Jun 10, 2013 at 08:44:25PM +0400, Vagner wrote: > > > Hi! > > > I need method of finding in struct vm_map or vm_object segments of > > > memory which is situated in the stack. > > > Can you help me please? > > > > Note that the stack is per-thread. The concept is somewhat machine-specific, > > some architectures utilize two stacks, on some the stack is purely software > > convention. > > > > You did not specified what context your code is to be run, e.g. is > > it kernel or user space ? Assuming it is kernel since you mentioned > > vm_something. The least error prone route is the thread context (frame) > > -> tf_esp on i386 (or tf_rsp on amd64) -> lookup of the map entry in the > > process p_vmspace. > > > > In reality, the stack is often fragmented, since the stack grow code > > does not coalesce the adjacent grow-down map entries. > > I asket the question because in my servers run very large daemons (writed their own). Then daemons get > signal for create coredump, downtime approximately 1h. This is very long for daemons in > production. Often in coredump for debug need only stack and current > frame of code, but in function, which initialise for create dump of > memory haven't this possibility. Linux have /proc/self/coredump_filter > for settings what segments included in core file, but in our FreeBSD I > don't find this:( Help me for find solution please > My solution. I added new option MALLOC_OPTIONS ("S") in environment variable for malloc(3). Also I added new `if' in function pages_map at libc/stdlib. In this `if' I added option MAP_NOCORE (mmap(2)) for segments allocated with MAP_PRIVATE | MAP_ANON. Patch file attached. As a result: I have a corefile with stack and text of program ~ 2Mb (above - 2Gb). Thanks to all -- Respectfully, Stanislav Putrya System administrator FotoStrana.Ru Ltd. ICQ IM: 328585847 Jabber-GoogleTalk: root.vagner mob.phone SPB: +79215788755 mob.phone RND: +79525600664 email: vagner[at]bsdway.ru email: putrya[at]playform.ru email: root.vagner[at]gmail.com site: bsdway.ru site: fotostrana.ru ---------------------------------------- ( ) ASCII ribbon campaign X - against HTML, vCards and / \ - proprietary attachments in e-mail --SUOF0GtieIMvvwua Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="core_only_stack.patch" Index: lib/libc/stdlib/malloc.c =================================================================== --- lib/libc/stdlib/malloc.c (revision 249257) +++ lib/libc/stdlib/malloc.c (working copy) @@ -1155,9 +1155,11 @@ #ifndef MALLOC_PRODUCTION static bool opt_abort = true; static bool opt_junk = true; +static bool opt_stackcore = false; #else static bool opt_abort = false; static bool opt_junk = false; +static bool opt_stackcore = false; #endif #ifdef MALLOC_TCACHE static size_t opt_lg_tcache_nslots = LG_TCACHE_NSLOTS_DEFAULT; @@ -1797,8 +1799,12 @@ * We don't use MAP_FIXED here, because it can cause the *replacement* * of existing mappings, and we only want to create new mappings. */ - ret = mmap(addr, size, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON, + if (opt_stackcore) + ret = mmap(addr, size, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON | MAP_NOCORE, -1, 0); + else + ret = mmap(addr, size, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON, + -1, 0); assert(ret != NULL); if (ret == MAP_FAILED) @@ -5623,6 +5629,9 @@ case 'P': opt_stats_print = true; break; + case 'S': + opt_stackcore = true; + break; case 'q': if (opt_lg_qspace_max > LG_QUANTUM) opt_lg_qspace_max--; --SUOF0GtieIMvvwua-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 11 22:11:28 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C7679F10 for ; Tue, 11 Jun 2013 22:11:28 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by mx1.freebsd.org (Postfix) with ESMTP id 61C761045 for ; Tue, 11 Jun 2013 22:11:28 +0000 (UTC) Received: by mail-wg0-f48.google.com with SMTP id f12so6266891wgh.3 for ; Tue, 11 Jun 2013 15:11:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent; bh=o+J1YxHv34J91ZxhMkans/eKtXmKZZ/JAFiHTl+Pgi4=; b=MAt5Agoq/7GfumviCMY/kVYxKc6U+M6EAcTAsDckao2KkA+o/rQjKqf5bB5O7KE2NR qlxGFWF0pkSu10tfw4UavxM+aTB142PsIXnrgoQenIDrunQk0688H9oiJ1caU41iu53W FMZ/BfLdlTJCsH5C/LkDsrbpy5Cd2I24klmAkJbR6OUOO2CbivVRCVSAXLFQ6LBW3PDN L5pzypE/hdAvsM/sHsL3LTY7tP8GPUBo1gmk55UFKwnaE1u/yrTSYM4SF8Fj2UxmAzwV G7dOmxKFn3nPHE4HiXqf7zV/KV8XwaaTh0kKADflpmuAYt7FetYFIZk5Z8LNEAgVcEvS J5eg== X-Received: by 10.180.83.9 with SMTP id m9mr1531624wiy.4.1370988687557; Tue, 11 Jun 2013 15:11:27 -0700 (PDT) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPSA id f8sm20146971wiv.0.2013.06.11.15.11.26 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 11 Jun 2013 15:11:26 -0700 (PDT) Sender: Baptiste Daroussin Date: Wed, 12 Jun 2013 00:11:24 +0200 From: Baptiste Daroussin To: freebsd-hackers@FreeBSD.org Subject: Importing tradcpp (traditional (K&R-style) C macro preprocessor) into base? Message-ID: <20130611221124.GC84600@ithaqua.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WfZ7S8PLGjBY9Voh" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 22:11:28 -0000 --WfZ7S8PLGjBY9Voh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, I have been working in importing tradcpp (developped by David A. Holland from NetBSD) into the ports tree, it is a traditional (K&R-style) C macro preprocessor BSD licensed. I first worked on it so that imake can work properly without gcc. I discovered that some part of the base system still needs a traditional preprocessor, like (calendar), what I propose it to import tradcpp into the base system (not the version in port right now but what will become version 0.2). It mostly behave like gcpp, and I'm able to properly use calendar along with tradcpp with this small patch: http://people.freebsd.org/~bapt/tradcpp.diff Any objections against me importing it? regards, Bapt --WfZ7S8PLGjBY9Voh Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlG3oIwACgkQ8kTtMUmk6EzV2gCfVsn44pjO+FQg0+Yjaklj9t+I LTYAnA3ol/EEwmGvT+leNLKOK7YP9fsp =MzFx -----END PGP SIGNATURE----- --WfZ7S8PLGjBY9Voh-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 11 22:23:47 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4E704315 for ; Tue, 11 Jun 2013 22:23:47 +0000 (UTC) (envelope-from matthias.andree@gmx.de) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by mx1.freebsd.org (Postfix) with ESMTP id E00F410F4 for ; Tue, 11 Jun 2013 22:23:46 +0000 (UTC) Received: from mailout-de.gmx.net ([10.1.76.2]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0LpRRz-1U7RSe47q1-00fAyt for ; Wed, 12 Jun 2013 00:23:46 +0200 Received: (qmail invoked by alias); 11 Jun 2013 22:23:45 -0000 Received: from f048228195.adsl.alicedsl.de (EHLO mandree.no-ip.org) [78.48.228.195] by mail.gmx.net (mp002) with SMTP; 12 Jun 2013 00:23:45 +0200 X-Authenticated: #428038 X-Provags-ID: V01U2FsdGVkX18OCDAWxLIOmAlCqLj7+7ZVHxcJFyPNrgH0f1CS/7 WOzoIThNnYWT9A Received: from [IPv6:::1] (localhost6.localdomain6 [IPv6:::1]) by apollo.emma.line.org (Postfix) with ESMTP id AE3A823CEB7 for ; Wed, 12 Jun 2013 00:23:44 +0200 (CEST) Message-ID: <51B7A370.3010307@gmx.de> Date: Wed, 12 Jun 2013 00:23:44 +0200 From: Matthias Andree User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: Importing tradcpp (traditional (K&R-style) C macro preprocessor) into base? References: <20130611221124.GC84600@ithaqua.etoilebsd.net> In-Reply-To: <20130611221124.GC84600@ithaqua.etoilebsd.net> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 22:23:47 -0000 Am 12.06.2013 00:11, schrieb Baptiste Daroussin: > Hi, > > I have been working in importing tradcpp (developped by David A. Holland from > NetBSD) into the ports tree, it is a traditional (K&R-style) C macro > preprocessor BSD licensed. I first worked on it so that imake can work properly > without gcc. > > I discovered that some part of the base system still needs a traditional > preprocessor, like (calendar), what I propose it to import tradcpp into the base > system (not the version in port right now but what will become version 0.2). > > It mostly behave like gcpp, and I'm able to properly use calendar along with > tradcpp with this small patch: http://people.freebsd.org/~bapt/tradcpp.diff > > Any objections against me importing it? Shouldn't we fix calendar and imake so that they can use a modern cpp, instead of going back 25 years? Or am I missing the point here? From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 11 22:28:37 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 25B27547; Tue, 11 Jun 2013 22:28:37 +0000 (UTC) (envelope-from db@db.net) Received: from diana.db.net (diana.db.net [66.113.102.10]) by mx1.freebsd.org (Postfix) with ESMTP id D9D881130; Tue, 11 Jun 2013 22:28:36 +0000 (UTC) Received: from night.db.net (localhost [127.0.0.1]) by diana.db.net (Postfix) with ESMTP id E2DA22AA362; Tue, 11 Jun 2013 16:28:35 -0600 (MDT) Received: by night.db.net (Postfix, from userid 1000) id 18CBF1CC0E; Tue, 11 Jun 2013 17:28:32 -0500 (EST) Date: Tue, 11 Jun 2013 17:28:32 -0500 From: Diane Bruce To: Baptiste Daroussin Subject: Re: Importing tradcpp (traditional (K&R-style) C macro preprocessor) into base? Message-ID: <20130611222832.GA27293@night.db.net> References: <20130611221124.GC84600@ithaqua.etoilebsd.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130611221124.GC84600@ithaqua.etoilebsd.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 22:28:37 -0000 On Wed, Jun 12, 2013 at 12:11:24AM +0200, Baptiste Daroussin wrote: > Hi, > > I have been working in importing tradcpp (developped by David A. Holland from > NetBSD) into the ports tree, it is a traditional (K&R-style) C macro > preprocessor BSD licensed. I first worked on it so that imake can work properly > without gcc. > > I discovered that some part of the base system still needs a traditional > preprocessor, like (calendar), what I propose it to import tradcpp into the base > system (not the version in port right now but what will become version 0.2). > > It mostly behave like gcpp, and I'm able to properly use calendar along with > tradcpp with this small patch: http://people.freebsd.org/~bapt/tradcpp.diff > > Any objections against me importing it? > > regards, > Bapt I rewrote calendar already to not use cpp at all. There is an open PR on it. - Diane -- - db@FreeBSD.org db@db.net http://www.db.net/~db From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 11 22:35:55 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7F0626BD; Tue, 11 Jun 2013 22:35:55 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) by mx1.freebsd.org (Postfix) with ESMTP id 198211179; Tue, 11 Jun 2013 22:35:55 +0000 (UTC) Received: from zeta.ixsystems.com (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id DB8411B83E; Tue, 11 Jun 2013 15:35:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1370990155; bh=7v0TtEsCrDU8qbRRjrt7p0kHk3i7MkOlUBbtHeYp7ZM=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=SZIGwlTWUOngj0WgUal4aj3aPZzYQUqps6ide1EdocGAiWw2MtjjS+8u4I8Wslhk2 GCzjE7owaWE8Rh4lw+ekzWcdpRMNCtfZDwsFz8G1DrEful+uAiOVKn0RNkWw8y0dPA HnXsPDuRddguFbKjQdCIw1gSBNyV78t6IGwU3TNI= Message-ID: <51B7A64A.5070108@delphij.net> Date: Tue, 11 Jun 2013 15:35:54 -0700 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Baptiste Daroussin Subject: Re: Importing tradcpp (traditional (K&R-style) C macro preprocessor) into base? References: <20130611221124.GC84600@ithaqua.etoilebsd.net> In-Reply-To: <20130611221124.GC84600@ithaqua.etoilebsd.net> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: d@delphij.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 22:35:55 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 06/11/13 15:11, Baptiste Daroussin wrote: > Hi, > > I have been working in importing tradcpp (developped by David A. > Holland from NetBSD) into the ports tree, it is a traditional > (K&R-style) C macro preprocessor BSD licensed. I first worked on it > so that imake can work properly without gcc. > > I discovered that some part of the base system still needs a > traditional preprocessor, like (calendar), what I propose it to > import tradcpp into the base system (not the version in port right > now but what will become version 0.2). > > It mostly behave like gcpp, and I'm able to properly use calendar > along with tradcpp with this small patch: > http://people.freebsd.org/~bapt/tradcpp.diff > > Any objections against me importing it? Looking at the manual page, it looks like that the only reason is to support #include's? I think it would be better to just fix it than importing a new (old) preprocessor... Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJRt6ZKAAoJEG80Jeu8UPuzrX4IAJj1hg/+Vh8oGuc2vVeuAU0W 6brYFkZFlgIicyC2k6BFuVU6jTyn3KelFyMxVgzk2S/5fI6lHh6YCHB/XRCDEzHg GG1TELsFKOgAUsA1xp/uDIKTJKqR2Wef2J3oaCl2L5FL0z/cySopPMLOcd08MiCA wOgr3qcPAfaxROOQJaZTs6lbUOs1zKB7RrtuCaYUB5fEwJ4uZwyKmkZtqEAK7WGT 8gDA78nfKxOLHE4XOBE1McO3sFrCQQoj+uAKS0tbRt4+qAD8rRq4T8H5BEk+eNqF NSPjFRKFrTXKSTnK4U+MBOcw7DhlOcabAz9Lpl6nD5hOzz2mUk4YG3pH/jY9zhg= =dsBw -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 11 22:38:30 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C81447BF for ; Tue, 11 Jun 2013 22:38:30 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) by mx1.freebsd.org (Postfix) with ESMTP id 5F504118E for ; Tue, 11 Jun 2013 22:38:30 +0000 (UTC) Received: by mail-wg0-f46.google.com with SMTP id c11so2866699wgh.13 for ; Tue, 11 Jun 2013 15:38:29 -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-type:content-disposition:in-reply-to:user-agent; bh=Y1vtTaLgHtboghCh1AKMbLd+LyUttDoyVE5a8iz6Clw=; b=cCQAneh09tso84kJBAYQ63YCz++SgikimFCz8NMOrfqo7q22mnSitG4v0oDeOhES1c B+E8hDqIRBH1BKM6/eOUQCr+2MxEijgip0EKC1SWLMpk63+BoNS7AfA96CnLf+oMZUOJ tgVDtfRF7HyqQQH0NcpHEhsBiZYXlMOSVTTSr4lMkz7ZuqIxYnz3heJiXZawyKxMH2xl 2tWykBqVWaaY0CNOPpBGlmrJv6sj/IsKZ7E8ARkZPhJ7U+Nd4sLCP80VEIXONs0UeXci 2p6ZZyZgZ5oB2Ab8LeBJNetSoOCP73ZOVLsSRfTt1em/SQz29A0lsSTA7j1jZYJrN8Wv qhAQ== X-Received: by 10.180.79.229 with SMTP id m5mr2709930wix.39.1370990309532; Tue, 11 Jun 2013 15:38:29 -0700 (PDT) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPSA id b19sm20808210wik.10.2013.06.11.15.38.28 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 11 Jun 2013 15:38:28 -0700 (PDT) Sender: Baptiste Daroussin Date: Wed, 12 Jun 2013 00:38:26 +0200 From: Baptiste Daroussin To: Matthias Andree Subject: Re: Importing tradcpp (traditional (K&R-style) C macro preprocessor) into base? Message-ID: <20130611223826.GE84600@ithaqua.etoilebsd.net> References: <20130611221124.GC84600@ithaqua.etoilebsd.net> <51B7A370.3010307@gmx.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lteA1dqeVaWQ9QQl" Content-Disposition: inline In-Reply-To: <51B7A370.3010307@gmx.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 22:38:30 -0000 --lteA1dqeVaWQ9QQl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 12, 2013 at 12:23:44AM +0200, Matthias Andree wrote: > Am 12.06.2013 00:11, schrieb Baptiste Daroussin: > > Hi, > >=20 > > I have been working in importing tradcpp (developped by David A. Hollan= d from > > NetBSD) into the ports tree, it is a traditional (K&R-style) C macro > > preprocessor BSD licensed. I first worked on it so that imake can work = properly > > without gcc. > >=20 > > I discovered that some part of the base system still needs a traditional > > preprocessor, like (calendar), what I propose it to import tradcpp into= the base > > system (not the version in port right now but what will become version = 0.2). > >=20 > > It mostly behave like gcpp, and I'm able to properly use calendar along= with > > tradcpp with this small patch: http://people.freebsd.org/~bapt/tradcpp.= diff > >=20 > > Any objections against me importing it? >=20 > Shouldn't we fix calendar and imake so that they can use a modern cpp, > instead of going back 25 years? Or am I missing the point here? >=20 To be more specific, some people have express some concern about the lack of support for traditional cpp in base, that's why I'm proposing this, now personnaly I don't care if tradcpp remains in ports (for imake, imake is no= t a matter of fixing imake, but rather all the users of imake). If we think it is not worth having a traditional cpp, I won't import it. cpp has not be design at first for this kind of usage, but someone of our vendors rely on a traditional cpp anyway. Just it exists, it is rather small, it is BSDL and actively maintainer, so = :) concerning calendar(1) another approach is available here: bin/178463 regards, Bapt --lteA1dqeVaWQ9QQl Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlG3puIACgkQ8kTtMUmk6EzdYgCgtqNOfveEm9viF2H0XI3U246d 9BEAoL+jWdnFQJ3KhFwjs7F6cwTbGBRg =DM1l -----END PGP SIGNATURE----- --lteA1dqeVaWQ9QQl-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 11 22:42:36 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E483F97F for ; Tue, 11 Jun 2013 22:42:36 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 7BA8911BC for ; Tue, 11 Jun 2013 22:42:36 +0000 (UTC) Received: by mail-wg0-f42.google.com with SMTP id x12so1021952wgg.5 for ; Tue, 11 Jun 2013 15:42:35 -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-type:content-disposition:in-reply-to:user-agent; bh=gL5nfEi3j3aRHtiPt+xtsR7vv6B5bGL2uKF9ij+0hes=; b=ivbbw+BLdVuQSG73oth2SzymHBcEBnlCtBCrKTLWub+fHUek9T8WG6pJi2v/tGHhnA GSR2A7ZjGlYq92Z38ec5exONAfmwV3pV77VSILAfMqT1v7WvTxxk69kjGcwR1ZRAC0QZ DyQHYz/QlVz2KwWIe2HmYPoZ3Q/+ZdxGgBASHXErwDLozA8YWz504Lx6ZeYgZ/kokP9M JheY2DkdNZtZxxwjJnrnK6FbHvSO8zlYV40lNfAC5s5UdignrJCB4WXruhI4pt8kix2P hEr3rOHaebP3/AsJmCHC8DGICZeDzaKSAbmlatfkinHa4jzmP8fiGnlrI4WVA35gAmGV MEgw== X-Received: by 10.194.157.2 with SMTP id wi2mr10027960wjb.77.1370990555592; Tue, 11 Jun 2013 15:42:35 -0700 (PDT) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPSA id ay7sm20951254wib.9.2013.06.11.15.42.34 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 11 Jun 2013 15:42:34 -0700 (PDT) Sender: Baptiste Daroussin Date: Wed, 12 Jun 2013 00:42:32 +0200 From: Baptiste Daroussin To: d@delphij.net Subject: Re: Importing tradcpp (traditional (K&R-style) C macro preprocessor) into base? Message-ID: <20130611224232.GF84600@ithaqua.etoilebsd.net> References: <20130611221124.GC84600@ithaqua.etoilebsd.net> <51B7A64A.5070108@delphij.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oFbHfjnMgUMsrGjO" Content-Disposition: inline In-Reply-To: <51B7A64A.5070108@delphij.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 22:42:37 -0000 --oFbHfjnMgUMsrGjO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 11, 2013 at 03:35:54PM -0700, Xin Li wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 >=20 > On 06/11/13 15:11, Baptiste Daroussin wrote: > > Hi, > >=20 > > I have been working in importing tradcpp (developped by David A. > > Holland from NetBSD) into the ports tree, it is a traditional > > (K&R-style) C macro preprocessor BSD licensed. I first worked on it > > so that imake can work properly without gcc. > >=20 > > I discovered that some part of the base system still needs a > > traditional preprocessor, like (calendar), what I propose it to > > import tradcpp into the base system (not the version in port right > > now but what will become version 0.2). > >=20 > > It mostly behave like gcpp, and I'm able to properly use calendar > > along with tradcpp with this small patch: > > http://people.freebsd.org/~bapt/tradcpp.diff > >=20 > > Any objections against me importing it? >=20 > Looking at the manual page, it looks like that the only reason is to > support #include's? I think it would be better to just fix it than > importing a new (old) preprocessor... Diane has proposed a patch to go that way: http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dbin%2F178463&cat=3D If one wants to review Bapt --oFbHfjnMgUMsrGjO Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlG3p9gACgkQ8kTtMUmk6EyU9QCeJTva5tp6S9mEYrYLOuEITHlS 3WAAn3qVXcJfht93h8LyAs78a+PUH/NE =A44m -----END PGP SIGNATURE----- --oFbHfjnMgUMsrGjO-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 11 22:42:47 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8E722A56; Tue, 11 Jun 2013 22:42:47 +0000 (UTC) (envelope-from db@db.net) Received: from diana.db.net (diana.db.net [66.113.102.10]) by mx1.freebsd.org (Postfix) with ESMTP id 28ED811BE; Tue, 11 Jun 2013 22:42:47 +0000 (UTC) Received: from night.db.net (localhost [127.0.0.1]) by diana.db.net (Postfix) with ESMTP id 5CBE92AA362; Tue, 11 Jun 2013 16:42:41 -0600 (MDT) Received: by night.db.net (Postfix, from userid 1000) id 8C87B1CC0E; Tue, 11 Jun 2013 17:42:37 -0500 (EST) Date: Tue, 11 Jun 2013 17:42:37 -0500 From: Diane Bruce To: d@delphij.net Subject: Re: Importing tradcpp (traditional (K&R-style) C macro preprocessor) into base? Message-ID: <20130611224237.GA33828@night.db.net> References: <20130611221124.GC84600@ithaqua.etoilebsd.net> <51B7A64A.5070108@delphij.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51B7A64A.5070108@delphij.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@FreeBSD.org, Baptiste Daroussin X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 22:42:47 -0000 On Tue, Jun 11, 2013 at 03:35:54PM -0700, Xin Li wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 06/11/13 15:11, Baptiste Daroussin wrote: > > Hi, > > > > I have been working in importing tradcpp (developped by David A. > > Holland from NetBSD) into the ports tree, it is a traditional > > (K&R-style) C macro preprocessor BSD licensed. I first worked on it > > so that imake can work properly without gcc. > > > > I discovered that some part of the base system still needs a > > traditional preprocessor, like (calendar), what I propose it to > > import tradcpp into the base system (not the version in port right > > now but what will become version 0.2). > > > > It mostly behave like gcpp, and I'm able to properly use calendar > > along with tradcpp with this small patch: > > http://people.freebsd.org/~bapt/tradcpp.diff > > > > Any objections against me importing it? > > Looking at the manual page, it looks like that the only reason is to > support #include's? I think it would be better to just fix it than > importing a new (old) preprocessor... > > Cheers, > - -- > Xin LI https://www.delphij.net/ > FreeBSD - The Power to Serve! Live free or die > -----BEGIN PGP SIGNATURE----- > > iQEcBAEBCgAGBQJRt6ZKAAoJEG80Jeu8UPuzrX4IAJj1hg/+Vh8oGuc2vVeuAU0W > 6brYFkZFlgIicyC2k6BFuVU6jTyn3KelFyMxVgzk2S/5fI6lHh6YCHB/XRCDEzHg > GG1TELsFKOgAUsA1xp/uDIKTJKqR2Wef2J3oaCl2L5FL0z/cySopPMLOcd08MiCA > wOgr3qcPAfaxROOQJaZTs6lbUOs1zKB7RrtuCaYUB5fEwJ4uZwyKmkZtqEAK7WGT > 8gDA78nfKxOLHE4XOBE1McO3sFrCQQoj+uAKS0tbRt4+qAD8rRq4T8H5BEk+eNqF > NSPjFRKFrTXKSTnK4U+MBOcw7DhlOcabAz9Lpl6nD5hOzz2mUk4YG3pH/jY9zhg= > =dsBw > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" http://people.FreeBSD.org/~db/calendar.diff removes cpp from calendar. There is also an open PR 178463 - Diane -- - db@FreeBSD.org db@db.net http://www.db.net/~db From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 11 22:50:32 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D36DFE37 for ; Tue, 11 Jun 2013 22:50:32 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-pb0-x22f.google.com (mail-pb0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) by mx1.freebsd.org (Postfix) with ESMTP id AEBF71225 for ; Tue, 11 Jun 2013 22:50:32 +0000 (UTC) Received: by mail-pb0-f47.google.com with SMTP id rr13so6361637pbb.20 for ; Tue, 11 Jun 2013 15:50:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=U331lO6SCzz0LfN82UNMSzWU1M5k+OAyxHanPu984/w=; b=D5sAFKoKglDJnx95KFqYp2vVEElsxcbfWng+9GOpXmotv9KW1E/eqUyhtiq0stZi+J 0ESRnKzDv/CtOjIZxCWzdMZNpVX9ioD2nqNyzZkezGHCWac3IiRyDASl8hlHYJ1mQevF d5zOcwPxuMgfq4DL8BmFde/0IK378SO62SU3U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=U331lO6SCzz0LfN82UNMSzWU1M5k+OAyxHanPu984/w=; b=Ysij7akCXON6Butgpm+W1CHiNrOVRebZ7vqj3jE47rf98+6OqWJ+z4hJQLU9D6L1X6 6NHde+0qO90pNqVUwZw2G2JgPQ4d3sDHJNqEOORyOnZ7PkIWTpoP7wN172Z8aMj3uS3h 002L8HKLZu6udCucntjvoKn4UEXEeevIQxNPVhHZFTBsWorOtDysr5OfPiyrDKgx7FYN ZLGAePKTOWevJaOM+p9Xiwy69yiu0MozBUvo5QzFY3Xq4on+O1WGPMYTh1EJ1Fx0axdN hbRqTimqXm/2ShcYuQDuR0RgAgMjjsArNgtHo2ag4MBt/U0J+2xqAg3tqgbK3Xg0P000 PjTA== X-Received: by 10.68.236.42 with SMTP id ur10mr3796207pbc.206.1370991032098; Tue, 11 Jun 2013 15:50:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.70.45.33 with HTTP; Tue, 11 Jun 2013 15:50:01 -0700 (PDT) In-Reply-To: <20130611224237.GA33828@night.db.net> References: <20130611221124.GC84600@ithaqua.etoilebsd.net> <51B7A64A.5070108@delphij.net> <20130611224237.GA33828@night.db.net> From: Eitan Adler Date: Wed, 12 Jun 2013 00:50:01 +0200 Message-ID: Subject: Re: Importing tradcpp (traditional (K&R-style) C macro preprocessor) into base? To: Diane Bruce Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmW7hHrD5jrqJZU2wrCI4OoFs7MROH6FkXuc97iCxjV0TS9mCpr0VVcMh9MpUppKw3ixtWG Cc: freebsd-hackers@freebsd.org, Baptiste Daroussin , d@delphij.net X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 22:50:32 -0000 On Wed, Jun 12, 2013 at 12:11 AM, Baptiste Daroussin wrote: ... Regarding tradcpp: I would rather see us try to fix the applications in base instead of import a new cpp. If this proves too difficult I have no objections to this particular implementation, On Wed, Jun 12, 2013 at 12:42 AM, Diane Bruce wrote: > removes cpp from calendar. > > There is also an open PR 178463 I already had a few comments about this diff: - " limited subset " in the man page does not explain what limit. - It doesn't seem to support #ifdef at all -- Eitan Adler From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 11 22:57:12 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 96A22F7A for ; Tue, 11 Jun 2013 22:57:12 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (unknown [IPv6:2001:610:1108:5012::107]) by mx1.freebsd.org (Postfix) with ESMTP id 60AD4125C for ; Tue, 11 Jun 2013 22:57:12 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 4136F12013D; Wed, 12 Jun 2013 00:56:57 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id 1626A28493; Wed, 12 Jun 2013 00:56:54 +0200 (CEST) Date: Wed, 12 Jun 2013 00:56:54 +0200 From: Jilles Tjoelker To: Matthias Andree Subject: Re: Importing tradcpp (traditional (K&R-style) C macro preprocessor) into base? Message-ID: <20130611225653.GB82810@stack.nl> References: <20130611221124.GC84600@ithaqua.etoilebsd.net> <51B7A370.3010307@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51B7A370.3010307@gmx.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 22:57:12 -0000 On Wed, Jun 12, 2013 at 12:23:44AM +0200, Matthias Andree wrote: > Am 12.06.2013 00:11, schrieb Baptiste Daroussin: > > I have been working in importing tradcpp (developped by David A. > > Holland from NetBSD) into the ports tree, it is a traditional > > (K&R-style) C macro preprocessor BSD licensed. I first worked on it > > so that imake can work properly without gcc. > > I discovered that some part of the base system still needs a > > traditional preprocessor, like (calendar), what I propose it to > > import tradcpp into the base system (not the version in port right > > now but what will become version 0.2). > > It mostly behave like gcpp, and I'm able to properly use calendar > > along with tradcpp with this small patch: > > http://people.freebsd.org/~bapt/tradcpp.diff > > Any objections against me importing it? > Shouldn't we fix calendar and imake so that they can use a modern cpp, > instead of going back 25 years? Or am I missing the point here? A modern cpp is only suitable for preprocessing C code. It makes various assumptions about syntax that make it work better for preprocessing actual C code but worse for text that is not C. Calendar and imake use the traditional cpp for preprocessing non-C text. There is already a patch for removing the dependency on cpp in calendar. I think that makes more sense than importing a traditional cpp (assuming there are no other users in base that cannot be fixed). The "fix" for imake is probably not to use it. Ports that need imake can continue to use it if it depends on a traditional cpp port. A further point of confusion is that things that want a "traditional cpp" in fact want an equivalent of "gcpp -traditional". This is in fact the point of tradcpp and why the old preprocessors do not work. -- Jilles Tjoelker From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 11 22:59:58 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 73B972F1; Tue, 11 Jun 2013 22:59:58 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) by mx1.freebsd.org (Postfix) with ESMTP id 013E91287; Tue, 11 Jun 2013 22:59:58 +0000 (UTC) Received: from zeta.ixsystems.com (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 922481B9B1; Tue, 11 Jun 2013 15:59:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1370991597; bh=Munw1pm7HXBaJjTSx1HO/DLvYA/jgJ8y0wm34mJg5HU=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=cXSrTYOJa6EQXXJLT+C62bQj8ZvTnrLV+WTrl5vhHlke1w9UFIM2EnEpsVn5KK2RY wmXkEhZmNgT1/eiY62+o5lkPscvs9d+zH/YjnGBlEIwdz8Ym9EDXSxoxi99ciHdgZx jdHoRe0y2pC+Zu/mvpDOE0LLS1QR13iF/73VnysA= Message-ID: <51B7ABEC.9000000@delphij.net> Date: Tue, 11 Jun 2013 15:59:56 -0700 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Eitan Adler Subject: Re: Importing tradcpp (traditional (K&R-style) C macro preprocessor) into base? References: <20130611221124.GC84600@ithaqua.etoilebsd.net> <51B7A64A.5070108@delphij.net> <20130611224237.GA33828@night.db.net> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Diane Bruce , d@delphij.net, Baptiste Daroussin X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: d@delphij.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 22:59:58 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 06/11/13 15:50, Eitan Adler wrote: [...] > - " limited subset " in the man page does not explain what limit. - > It doesn't seem to support #ifdef at all Why ifdef is needed? (ifndef is here to avoid duplicated inclusion, I don't think there is valid usage for ifdef). Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJRt6vsAAoJEG80Jeu8UPuz/EkH/jY8jLItQ6ESfeujLw+72mQ3 Hmitiotg7UHj4ltUs1gazrc5/OGqxZaIOSiAM4aeNa1QDh4WVKaRgFrNg1R1QQCX VLZAzDa9lmSCL9P2RIy7zLgsmY8WsPNKzS051mOEpVDTB56MmXedmllZF//qMaXa S6oMi+nXZXcOlmhyAKRc8J3SAdT40OQDniX2MasE5KnjNL0wE7sZgVK2i4mkT7Tp KTOg0zu0Ezv7kxny/Kbh3curllKyKb+9ca5C4rfmcK41M4GXhQRMqrm3of1uS+3Z 8mSb57cqK3xBJO2JATt46chUlXfT2lxG8/ByiJs8zziT2+G++jEFGTnyzH5DTKY= =vL2S -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 11 23:04:45 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3495346A; Tue, 11 Jun 2013 23:04:45 +0000 (UTC) (envelope-from db@db.net) Received: from diana.db.net (unknown [IPv6:2620:64:0:1:223:7dff:fea2:c8f2]) by mx1.freebsd.org (Postfix) with ESMTP id 1E83412D4; Tue, 11 Jun 2013 23:04:45 +0000 (UTC) Received: from night.db.net (localhost [127.0.0.1]) by diana.db.net (Postfix) with ESMTP id 11B4C2AA380; Tue, 11 Jun 2013 17:04:43 -0600 (MDT) Received: by night.db.net (Postfix, from userid 1000) id 3C85F1CC0E; Tue, 11 Jun 2013 18:04:39 -0500 (EST) Date: Tue, 11 Jun 2013 18:04:39 -0500 From: Diane Bruce To: d@delphij.net Subject: Re: Importing tradcpp (traditional (K&R-style) C macro preprocessor) into base? Message-ID: <20130611230439.GA48697@night.db.net> References: <20130611221124.GC84600@ithaqua.etoilebsd.net> <51B7A64A.5070108@delphij.net> <20130611224237.GA33828@night.db.net> <51B7ABEC.9000000@delphij.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51B7ABEC.9000000@delphij.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Eitan Adler , Diane Bruce , Baptiste Daroussin , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 23:04:45 -0000 On Tue, Jun 11, 2013 at 03:59:56PM -0700, Xin Li wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 06/11/13 15:50, Eitan Adler wrote: > [...] > > - " limited subset " in the man page does not explain what limit. - > > It doesn't seem to support #ifdef at all > > Why ifdef is needed? (ifndef is here to avoid duplicated inclusion, I > don't think there is valid usage for ifdef). I accidentally left it in is the short answer and I never got around to removing it. ;) It's easy enough to remove, I can re-roll a diff removing #ifdef since it isn't really needed. > > Cheers, > - -- > Xin LI https://www.delphij.net/ > FreeBSD - The Power to Serve! Live free or die > -----BEGIN PGP SIGNATURE----- > > iQEcBAEBCgAGBQJRt6vsAAoJEG80Jeu8UPuz/EkH/jY8jLItQ6ESfeujLw+72mQ3 > Hmitiotg7UHj4ltUs1gazrc5/OGqxZaIOSiAM4aeNa1QDh4WVKaRgFrNg1R1QQCX > VLZAzDa9lmSCL9P2RIy7zLgsmY8WsPNKzS051mOEpVDTB56MmXedmllZF//qMaXa > S6oMi+nXZXcOlmhyAKRc8J3SAdT40OQDniX2MasE5KnjNL0wE7sZgVK2i4mkT7Tp > KTOg0zu0Ezv7kxny/Kbh3curllKyKb+9ca5C4rfmcK41M4GXhQRMqrm3of1uS+3Z > 8mSb57cqK3xBJO2JATt46chUlXfT2lxG8/ByiJs8zziT2+G++jEFGTnyzH5DTKY= > =vL2S > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" - Diane -- - db@FreeBSD.org db@db.net http://www.db.net/~db From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 11 23:14:08 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0927970F; Tue, 11 Jun 2013 23:14:08 +0000 (UTC) (envelope-from db@db.net) Received: from diana.db.net (unknown [IPv6:2620:64:0:1:223:7dff:fea2:c8f2]) by mx1.freebsd.org (Postfix) with ESMTP id E6F8A133E; Tue, 11 Jun 2013 23:14:07 +0000 (UTC) Received: from night.db.net (localhost [127.0.0.1]) by diana.db.net (Postfix) with ESMTP id 603702AA42F; Tue, 11 Jun 2013 17:14:07 -0600 (MDT) Received: by night.db.net (Postfix, from userid 1000) id 8EA631CC0E; Tue, 11 Jun 2013 18:14:03 -0500 (EST) Date: Tue, 11 Jun 2013 18:14:03 -0500 From: Diane Bruce To: Diane Bruce Subject: Re: Importing tradcpp (traditional (K&R-style) C macro preprocessor) into base? Message-ID: <20130611231403.GA55267@night.db.net> References: <20130611221124.GC84600@ithaqua.etoilebsd.net> <51B7A64A.5070108@delphij.net> <20130611224237.GA33828@night.db.net> <51B7ABEC.9000000@delphij.net> <20130611230439.GA48697@night.db.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130611230439.GA48697@night.db.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Eitan Adler , Baptiste Daroussin , d@delphij.net, freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 23:14:08 -0000 On Tue, Jun 11, 2013 at 06:04:39PM -0500, Diane Bruce wrote: > On Tue, Jun 11, 2013 at 03:59:56PM -0700, Xin Li wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA512 > > > > On 06/11/13 15:50, Eitan Adler wrote: > > [...] > > > - " limited subset " in the man page does not explain what limit. - > > > It doesn't seem to support #ifdef at all > > > > Why ifdef is needed? (ifndef is here to avoid duplicated inclusion, I > > don't think there is valid usage for ifdef). > > I accidentally left it in is the short answer and I never got around > to removing it. ;) It's easy enough to remove, I can re-roll a diff > removing #ifdef since it isn't really needed. Which I just did. > > > > > Cheers, - Diane -- - db@FreeBSD.org db@db.net http://www.db.net/~db From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 12 09:07:30 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EDB06202; Wed, 12 Jun 2013 09:07:30 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 8E68E1AFE; Wed, 12 Jun 2013 09:07:30 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 7A71B3EB61; Wed, 12 Jun 2013 09:07:29 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.6/8.14.6) with ESMTP id r5C97TTW014321; Wed, 12 Jun 2013 09:07:29 GMT (envelope-from phk@phk.freebsd.dk) To: Baptiste Daroussin Subject: Re: Importing tradcpp (traditional (K&R-style) C macro preprocessor) into base? In-reply-to: <20130611221124.GC84600@ithaqua.etoilebsd.net> From: "Poul-Henning Kamp" References: <20130611221124.GC84600@ithaqua.etoilebsd.net> Content-Type: text/plain; charset=ISO-8859-1 Date: Wed, 12 Jun 2013 09:07:29 +0000 Message-ID: <14320.1371028049@critter.freebsd.dk> X-Mailman-Approved-At: Wed, 12 Jun 2013 11:52:32 +0000 Cc: freebsd-hackers@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 09:07:31 -0000 In message <20130611221124.GC84600@ithaqua.etoilebsd.net>, Baptiste Daroussin w rites: >I have been working in importing tradcpp (developped by David A. Holland from >NetBSD) into the ports tree, it is a traditional (K&R-style) C macro >preprocessor BSD licensed. I first worked on it so that imake can work properly >without gcc. As a user of certain antique X11 apps, I applaud this effort. >I discovered that some part of the base system still needs a traditional >preprocessor, like (calendar), what I propose it to import tradcpp into the base >system (not the version in port right now but what will become version 0.2). However, I think these programs should be fixed, rather than put tradcpp in the src tree. -- 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-hackers@FreeBSD.ORG Thu Jun 13 03:36:05 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E9C85123 for ; Thu, 13 Jun 2013 03:36:05 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-oa0-x22e.google.com (mail-oa0-x22e.google.com [IPv6:2607:f8b0:4003:c02::22e]) by mx1.freebsd.org (Postfix) with ESMTP id BC74E15DB for ; Thu, 13 Jun 2013 03:36:05 +0000 (UTC) Received: by mail-oa0-f46.google.com with SMTP id h1so2809047oag.19 for ; Wed, 12 Jun 2013 20:36:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=qyO7fXPznlS4kFPhJneOCsc5I41qJbxbFyijacLamRk=; b=ecLJeZvWeXxFUEfnaoatfutE34VnCDztFooYWNIoTdSXiHJFBcyD/ZNyxYQhHdGPjy n6po5X7vd/+TH+KnSUKBNrvymOofq/thTNjNJ2Kr1V/4iel5HfAOzTV9aztD7nqUGrAr HpFH/1BBcpMjUUrL6hoDkF6gs4ECIyZKfC69EKKd9qt087uJulwHhxjuvtqJE5KjR1R6 Ed3aNy6ZgETT3EmKN4pGDlkQIryAa5vG26HqhNqF98DVjh40a5WsAydIVJcWpFQfNuNe 7afoFMlx7TWG8nmkspGDdsaEyJt2ejoXa5E9PpJNVik48T4NRGvgCKkLhqP0D0lL3CF0 rQMw== MIME-Version: 1.0 X-Received: by 10.182.74.131 with SMTP id t3mr17525900obv.87.1371094565323; Wed, 12 Jun 2013 20:36:05 -0700 (PDT) Received: by 10.76.91.163 with HTTP; Wed, 12 Jun 2013 20:36:04 -0700 (PDT) Date: Wed, 12 Jun 2013 23:36:04 -0400 Message-ID: Subject: Exposing driver's GPIOs through gpiobus From: Ryan Stone To: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 03:36:06 -0000 At $WORK we have some custom boards with multi-port uarts managed by puc. The uart devices happen to provide some GPIOs, and our hardware designers have appropriated those GPIOs for various purposes entirely unrelated to the uart. I'm looking for a clean way to provide access to the GPIOs. It occurred to me that this was a problem that should be solved through newbus, and lo and behold I have discovered that FreeBSD provides a gpiobus driver that seems suitable. I've been playing around with this for a couple of days and I have a solutions that is working, but there are aspects that I am unhappy with. I also quite unfamiliar with newbus, so there easily could be better ways to approach the problem that I haven't thought of. What I ended up doing was making gpiobus and gpioc children of the puc bus. In puc_bfe_attach() I create two new child devices of the puc device with device_add_child(), one with the gpioc devclass and one with the gpiobus devclass. I then attach both children with device_probe_and_attach(). I make the puc_pci driver itself provide implementations of the various gpio methods (like gpio_pin_get) so they can be inherited by the child devices. Things start to get somewhat messy in the gpio client code. I have the same image running on many different hardware types, so I can't use device hints to create a child device of the gpiobus. Instead my kernel module tracks down the device_t for the puc, finds the gpiobus child, and uses BUS_ADD_CHILD to create a child of the gpiobus. I had to add a new gpiobus method to allocate GPIO pins to my driver instance. Once that's done, I can toggle GPIOs and whatnot using methods on my driver instance. The things that I'm most unhappy with (newbus-wise, anyway) are: 1) By default the gpioc and gpiobus drivers were claiming the uart children of the puc. I had to decrease their priority in bus_probe to BUS_PROBE_LOW_PRIORITY to work around the problem. I really don't think that was the right solution. I guess I could introduce a new device that is a child of the puc, make sure that it will not claim the uarts, and then make the gpioc and gpiobus children of this device. 2) I'm not sure how to clean up my child device when my module is unloaded. Currently I am checking if it already exists on load and reusing it if so. I may be missing something obvious here. 3) I really don't like the way that I am adding my child to gpiobus. Upon writing this it occurs to me that device_identify would be the canonical way to do this. Previously it wasn't clear to me how to fit device_identify into the current architecture of the gpio client but I see how it can be done now. From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 13 06:20:57 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B117CBB8; Thu, 13 Jun 2013 06:20:57 +0000 (UTC) (envelope-from hps@bitfrost.no) Received: from mta.bitpro.no (mta.bitpro.no [92.42.64.202]) by mx1.freebsd.org (Postfix) with ESMTP id 7001E1A6A; Thu, 13 Jun 2013 06:20:54 +0000 (UTC) Received: from mail.bitfrost.no (mail.bitfrost.no [46.29.221.36]) by mta.bitpro.no (Postfix) with ESMTP id 7FD177A346; Thu, 13 Jun 2013 08:20:46 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at bitfrost.no Received: from laptop015.hselasky.homeunix.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: hanspetter) by mail.bitfrost.no (Postfix) with ESMTPSA id A170E20685; Thu, 13 Jun 2013 08:20:42 +0200 (CEST) Message-ID: <51B9650D.1050601@bitfrost.no> Date: Thu, 13 Jun 2013 08:22:05 +0200 From: Hans Petter Selasky Organization: Bitfrost A/S MIME-Version: 1.0 To: Alexander Leidinger Subject: Re: priv_check/make_dev/devfs.rules: What is preventing a device to show up in a jail? References: <20130509110718.0000528e@unknown> <518C060E.8040301@gmail.com> <20130510121133.00001e2a@unknown> <518CDD73.9090405@uffe.org> <20130510213303.00005078@unknown> In-Reply-To: <20130510213303.00005078@unknown> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: usb@FreeBSD.org, freebsd-hackers@freebsd.org, Uffe Jakobsen X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 06:20:57 -0000 On 05/10/13 21:33, Alexander Leidinger wrote: > On Fri, 10 May 2013 13:43:47 +0200 > Uffe Jakobsen wrote: > >> On 2013-05-10 12:11, Alexander Leidinger wrote: >>> >>> I worry about what is going on. We have something which is supposed >>> to provide security as required, but is does not seem to work as >>> described. We either need to fix the documentation, or a bug in the >>> code. To do the later it needs to be debugged. >>> >> >> It seems to me that you are struggeling with this - or a related - >> problem: >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/122838 > > Indeed, this is the problem. I have all entries visible now. Anyone > interested to have this changed (as suggested by Andriy in the PR) > should voice his opinion. I voiced mine already. > > Bye, > Alexander. > Hi, Can we introduce a new syntax while keeping the old behaviour? path zvol/* hide-r path zvol/* unhide-r I think this will be more accepted than changing existing behaviour! Is this stack element really needed? + char specname[SPECNAMELEN + 1]; --HPS From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 13 12:08:10 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 97C236B7; Thu, 13 Jun 2013 12:08:10 +0000 (UTC) (envelope-from jh@FreeBSD.org) Received: from jenni1.inet.fi (mta-out.inet.fi [195.156.147.13]) by mx1.freebsd.org (Postfix) with ESMTP id 5ABEC1977; Thu, 13 Jun 2013 12:08:09 +0000 (UTC) Received: from dsl-tkubrasgw1-54fa22-153.dhcp.inet.fi (84.250.34.153) by jenni1.inet.fi (8.5.140.03) id 5163EC560460B28D; Thu, 13 Jun 2013 15:06:53 +0300 Date: Thu, 13 Jun 2013 15:06:54 +0300 From: Jaakko Heinonen To: Hans Petter Selasky Subject: Re: priv_check/make_dev/devfs.rules: What is preventing a device to show up in a jail? Message-ID: <20130613120653.GA1467@dsl-tkubrasgw1-54fa22-153.dhcp.inet.fi> References: <20130509110718.0000528e@unknown> <518C060E.8040301@gmail.com> <20130510121133.00001e2a@unknown> <518CDD73.9090405@uffe.org> <20130510213303.00005078@unknown> <51B9650D.1050601@bitfrost.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51B9650D.1050601@bitfrost.no> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: usb@freebsd.org, Alexander Leidinger , Uffe Jakobsen , avg@FreeBSD.org, freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 12:08:10 -0000 On 2013-06-13, Hans Petter Selasky wrote: > Can we introduce a new syntax while keeping the old behaviour? > > path zvol/* hide-r > path zvol/* unhide-r > > I think this will be more accepted than changing existing behaviour! IMHO, the old behavior is so confusing and unintuitive that we should not maintain it. Can you clarify how "hide-r" and "unhide-r" would differ from plain "hide" and "unhide". The current syntax already uses pattern matching via fnmatch(9). > Is this stack element really needed? > > + char specname[SPECNAMELEN + 1]; Need to check if M_WAITOK malloc is possible here. -- Jaakko From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 13 18:33:23 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D532534A for ; Thu, 13 Jun 2013 18:33:23 +0000 (UTC) (envelope-from rank1seeker@gmail.com) Received: from mail-ea0-x232.google.com (mail-ea0-x232.google.com [IPv6:2a00:1450:4013:c01::232]) by mx1.freebsd.org (Postfix) with ESMTP id 6E15A1CFC for ; Thu, 13 Jun 2013 18:33:23 +0000 (UTC) Received: by mail-ea0-f178.google.com with SMTP id l15so5730372eak.37 for ; Thu, 13 Jun 2013 11:33:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:subject:date:x-mailer; bh=EbXCjzY3wOYjdk/qQHrYLrv5ssVtvBe86mLT+OUu7ns=; b=oezTWSzlaxBj14hZbrKu9oAdhgVXO7dIuwn0WdgskQYHluRsXb2KK3EwbzU4iUfF9Y ZpCvdqSkJL+48ShWR+VMrq6WHVm+h4ptbrk4Sc9crQBlOb7hZCOjb0G9EW5uMCZIc1A2 o9X8DEEwTPso7/UFHQh6oJ8xtlNJwFL83IC8byp13gvGETau0NEDsYnw/QoyVnatP9HG hb6Hkn38n3ua72tBl0DHoDr6Ee/rCbquEUWfqSBKioYYLg0bxk5gHA0f1yDVdR+EfXzL ZR9eOESL+y1Mq9bk6ofmBKKjpBfXkw5Qx7xhWqApQQDdoaQ2d7UVWdnbfZ07O+0i/JcM u/Ig== X-Received: by 10.15.31.198 with SMTP id y46mr2552066eeu.135.1371148402542; Thu, 13 Jun 2013 11:33:22 -0700 (PDT) Received: from DOMYPC ([82.193.208.225]) by mx.google.com with ESMTPSA id u11sm45486813eev.12.2013.06.13.11.33.20 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 13 Jun 2013 11:33:21 -0700 (PDT) Message-ID: <20130613.183320.794.1@DOMY-PC> From: rank1seeker@gmail.com To: freebsd-hackers@freebsd.org Subject: panic: vfs_mount_destroy: nonzero activevnodelistsize Date: Thu, 13 Jun 2013 20:33:20 +0200 X-Mailer: POP Peeper (3.8.1.0) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 18:33:23 -0000 http://forums.freebsd.org/showthread.php?p=223457 From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 14 20:16:21 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 45FCFF42 for ; Fri, 14 Jun 2013 20:16:21 +0000 (UTC) (envelope-from white.heron@yAhoo.com) Received: from nm29-vm7.bullet.mail.sg3.yahoo.com (nm29-vm7.bullet.mail.sg3.yahoo.com [106.10.151.166]) by mx1.freebsd.org (Postfix) with ESMTP id 8E83E16FF for ; Fri, 14 Jun 2013 20:16:20 +0000 (UTC) Received: from [106.10.166.118] by nm29.bullet.mail.sg3.yahoo.com with NNFMP; 14 Jun 2013 20:16:19 -0000 Received: from [106.10.167.178] by tm7.bullet.mail.sg3.yahoo.com with NNFMP; 14 Jun 2013 20:16:19 -0000 Received: from [127.0.0.1] by smtp151.mail.sg3.yahoo.com with NNFMP; 14 Jun 2013 20:16:19 -0000 X-Yahoo-Newman-Id: 912.54315.bm@smtp151.mail.sg3.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: IJQ3qtAVM1kVzgVWyXccB4Q3ydaJTwe4F7qqrpYxdHtJqs7 A99CmY38T4QdPobePPZ.pAq40O3VU7LfIuZUcIdANUwwbqRq4dHOgNkE.w9x 4TY8XmvSqiTZ6CvX44ll0eB42ekIqgQzd1liTvum0HGnct6tXw2DHNn0r8c2 EGHnfQzkKDAIG4am_B2WjzTKRDir9DqYRWli22wdhRQIfjQN.jwGqReGM8km RgHZtbaSM3tDN0zKj_a5.wY.._Z3j55wYGd8bgBGUrPjP541bPbeg1sZZgdx e57PkT7sc25zJGcWSyNcXKNrfVA762hVF.NMCHmz.v3lI8sdSD2tNsUBC08q Vb2ejPShvCuM4VwQYiObTcon9RlbIDuf7Y_UopcwF1Sf_9vlwouDeFADLVnK AodOeqFoKzG01rJygB9I8kPpzCd_WHFlpmDpbmb.2RtFre1KVh.xTMvAGf1J 96HohjV8EVbjbb2DCd12oMwEfuhRu9E0q0ft8LPCpzzgGCibXXCz_G8AOabs TK5YTe3hau6_4lh6zYCsGLqLVmMvBDoeBFaFk1wYwRZs3Xebmx2pBYGsNrsi feMpwSwl622WXIfShl2Wtry11bHos0bUnbqdT9hMy8puXA_xT4ajDdw4Nnyb 0g7GQr84wQN4_sE8JNdwQvToLEDJNU22LW1uLGXkWl9VWC8I- X-Yahoo-SMTP: s0XQitCswBA_807w2EH692Ks_DzvPrkF X-Rocket-Received: from [192.168.0.181] (white.heron@175.136.224.242 with ) by smtp151.mail.sg3.yahoo.com with SMTP; 14 Jun 2013 13:16:18 -0700 PDT Subject: WhatsApp Messenger: iPhone + Android + Nokia + BlackBerry + Windows Phone From: white.heron@yAhoo.com Message-Id: <5882A08C-E4B8-48EA-8B0F-C79268F5DEB1@yAhoo.com> Date: Sat, 15 Jun 2013 04:16:18 +0800 To: "freebsd-hackers@freebsd.org" Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (10B350) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 20:16:21 -0000 Hey, I just downloaded WhatsApp Messenger on my iPhone. It is a Smartphone Messenger that replaces SMS. This app even lets me send p= ictures, video and other multimedia! WhatsApp Messenger is available for iPhone, Android, Nokia, BlackBerry and W= indows Phone. There's no PIN or username to remember - it works just like SM= S but uses your Internet data plan. Get it now from http://www.whatsapp.com/download/ and say good-bye to SMS. my.linkedin.com/pub/yb-tan-sri-dato-ir-adli-a-k-a-dell/44/64b/464/ Sent from my iPhone= From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 15 18:58:45 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CAC44A4D for ; Sat, 15 Jun 2013 18:58:45 +0000 (UTC) (envelope-from rank1seeker@gmail.com) Received: from mail-ee0-x236.google.com (mail-ee0-x236.google.com [IPv6:2a00:1450:4013:c00::236]) by mx1.freebsd.org (Postfix) with ESMTP id 655E015DB for ; Sat, 15 Jun 2013 18:58:45 +0000 (UTC) Received: by mail-ee0-f54.google.com with SMTP id t10so975846eei.13 for ; Sat, 15 Jun 2013 11:58:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:subject:date:content-type :content-transfer-encoding:x-mailer; bh=VX+R3tKCA2CYhdJo+39d3TfjRDKY7zZaWSASDDxadDk=; b=IgjmAlEUYRBVRhAUfKZKgJThnS+ZKYtUbjp0+ANEy2Jco/xn6d97TX8Ld9sUFcD15H LtWgxzMHtpTz2US0vOCGytN9+F2IlTFVB9EEuOwvnEt1H5+8Jgo694ZEaa476nb2k/Z1 MrdnAE6ed/4Q33FEJozPiLye/MrJFlFHw6Y5Tm1XS+8i4JXo3EvURhhodcyQ7tQ2oQJT LFlLmEWFoNmsG/HbprSUM//ZzFbZiZEIfvmQVd+Nb8f47cHRnwS7qGKPKqNtjdNwKnPq mGBn5ldNO9CDTPs1frY6zmSzys9reytROMRfn0ZVSHnntuJv7F1bdHiVCPiIA7Dm/PAf 2MOg== X-Received: by 10.15.34.77 with SMTP id d53mr8994436eev.95.1371322724527; Sat, 15 Jun 2013 11:58:44 -0700 (PDT) Received: from DOMYPC ([82.193.208.225]) by mx.google.com with ESMTPSA id m1sm11738990eex.17.2013.06.15.11.58.42 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 15 Jun 2013 11:58:43 -0700 (PDT) Message-ID: <20130615.185842.816.1@DOMY-PC> From: rank1seeker@gmail.com To: hackers@freebsd.org Subject: 9.1 stage 2 boot Date: Sat, 15 Jun 2013 20:58:42 +0200 Content-Type: text/plain; charset="Windows-1250" Content-Transfer-Encoding: quoted-printable X-Mailer: POP Peeper (3.8.1.0) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jun 2013 18:58:45 -0000 The FreeBSD boot(8) block now supports /boot/config in addition to = /boot.config as the boot block parameter file.=0D=0AWhen both of them = exist, the former will be used.[r231287]=0D=0A=0D=0AJust to test it = I've:=0D=0A# echo '-s' > /boot.config=0D=0A=0D=0AThen=0D=0A# mv -v = /boot/config /boot.config=0D=0A=0D=0AWhichever is used, stage 2 boot, = always claims it is /boot/config file and prints it's contest.=0D=0AThis = is a tiny bug.=0D=0A=0D=0AJust asking, what is the main benefit of = additional /boot/config file?=0D=0A=0D=0A=0D=0ADomagoj Smol=E8i=E6