From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 10 12:58:40 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 07B584BA; Sun, 10 Nov 2013 12:58:40 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-ee0-x22d.google.com (mail-ee0-x22d.google.com [IPv6:2a00:1450:4013:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6AD452912; Sun, 10 Nov 2013 12:58:39 +0000 (UTC) Received: by mail-ee0-f45.google.com with SMTP id c4so384072eek.4 for ; Sun, 10 Nov 2013 04:58:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/foGp47QLegyoImOInki/6yIf+jIASkqdOECKnFx4e8=; b=jd/i7Hm737HVdYeuqGwz5XXwVCYoppZnh0EdS1RGevmLwqkFl1n5eakfkKl5jRwcNM L5WHn+HlmkjjgtF/eJk/YldWHcFCbVjuDWM1lyabiYn8hKBjynACHSOXDOCIYWJOBp9T Ohh14peXpVQ9WZ0fJsw/6vDQtTNaDwRXTZ9rF9HLzsBxhqwLL0iT//QzkdngtbJs5dl3 xzwLBABGOJo1O9QN0HhM6AEiMoPjW8w2T5c9+Pryg8BlhbAZ9UgqfWtOml3F1Q+WtX4C nsB4qVNyUUaJgoZLN0YE0xsfRjkH30EutNwTm+SvkispkAWICBqGtCaAgx/o9MT6bNZd GXLA== X-Received: by 10.14.122.132 with SMTP id t4mr28846112eeh.20.1384088317910; Sun, 10 Nov 2013 04:58:37 -0800 (PST) Received: from [192.168.1.102] (45.81.datacomsa.pl. [195.34.81.45]) by mx.google.com with ESMTPSA id m54sm40760196eex.2.2013.11.10.04.58.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 10 Nov 2013 04:58:37 -0800 (PST) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Subject: Re: Are extended attributes data or meta-data? Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-2 From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= In-Reply-To: <704471213.12196154.1384036087256.JavaMail.root@uoguelph.ca> Date: Sun, 10 Nov 2013 13:58:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <496C049F-22C8-46CF-8405-FAF4EBCD3BB8@freebsd.org> References: <704471213.12196154.1384036087256.JavaMail.root@uoguelph.ca> To: Rick Macklem X-Mailer: Apple Mail (2.1283) Cc: freebsd-hackers Hackers , Tim Kientzle 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, 10 Nov 2013 12:58:40 -0000 Wiadomo=B6=E6 napisana przez Rick Macklem w dniu 9 lis 2013, o godz. = 23:28: > Tim Kientzle wrote: >>=20 >> On Nov 8, 2013, at 3:45 PM, Peter Jeremy wrote: >>=20 >>> I've been getting regular error messages logged by afpd: >>> Nov 9 00:00:19 server afpd[1966]: sys_getextattr_size: error: >>> Permission denied >>> I have spent some time digging into it and it's triggered by >>> extattr_get_link(2) returning EACCESS because a file is not >>> readable, >>> but stat(2) on the file succeeded. >>>=20 >>> According to extattr(2), "[n]amed extended attributes are meta-data >>> associated with vnodes" but the actual code for VOP_GETEXTATTR() >>> (at least >>> for ufs & zfs) checks for VREAD access, whereas the VOP_GETATTR() >>> call >>> (used by stat(2)) doesn't include any access checks (so stat(2) >>> will >>> succeed unless namei() fails). >>>=20 >>> IMHO, this behaviour is inconsistent: The extended attributes are >>> documented as "meta-data" and but the access checks are for "data". >>> Which is correct? >>=20 >> Practically speaking, extended attributes are used both >> for data and metadata. >>=20 >> I would consider the existing behavior (extattr calls fail on >> non-readable files) to be correct in the absence of NFSv4 >> ACLs (which include a specific permission for extattr readability). >>=20 > Actually, NFSv4 doesn't support the notion of extended attributes at > this time. It is being discussed for a future minor version. It does > support the notion of fork files/subfiles, but I think they get their = own > ACLs. >=20 > I believe the Read_attribute and Write_attribute flags in NFSv4 ACLs > refer to the regular attributes and not extended ones. (I've cc'd = trasz, > since he'll know.) Exactly - the read_attributes/write_attributes NFSv4 ACL permissions are for the "normal" file attributes, such as access/change/modify = times. The read_xattr/write_xattr permissions are ignored; access to extended attributes requires the same permissions as for the file contents. > The Fedoro/Linux "man attr" states that extended attributes in their = "user" > name space are access controlled via the normal file mechanisms, so I > believe Linux does check for read/write permissions. Since Linux = distros > are the lion's (not referring to an OS X version;-) share of what's = out > there, I'd say their semantics are defacto standard. > --> I think that checking for read (or write) access for extended = attributes > is correct. Just for the record, on SunOS access to alternate data streams in ZFS (which we use to store extended attributes) doesn't use the read_xattr and write_xattr permisions either. --=20 If you cut off my head, what would I say? Me and my head, or me and my = body? From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 11 14:24:07 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6C180764 for ; Mon, 11 Nov 2013 14:24:07 +0000 (UTC) (envelope-from atte.peltomaki@iki.fi) Received: from filtteri1.pp.htv.fi (filtteri1.pp.htv.fi [213.243.153.184]) by mx1.freebsd.org (Postfix) with ESMTP id 28E182AC3 for ; Mon, 11 Nov 2013 14:24:07 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by filtteri1.pp.htv.fi (Postfix) with ESMTP id EF6F121BAF4; Mon, 11 Nov 2013 16:23:59 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from smtp5.welho.com ([213.243.153.39]) by localhost (filtteri1.pp.htv.fi [213.243.153.184]) (amavisd-new, port 10024) with ESMTP id RnEU7Anissfg; Mon, 11 Nov 2013 16:23:54 +0200 (EET) Received: from kameli.org (cs181030192.pp.htv.fi [82.181.30.192]) by smtp5.welho.com (Postfix) with SMTP id E29375BC039; Mon, 11 Nov 2013 16:23:48 +0200 (EET) Received: by kameli.org (sSMTP sendmail emulation); Mon, 11 Nov 2013 16:23:48 +0200 From: "Atte Peltomaki" Date: Mon, 11 Nov 2013 16:23:48 +0200 To: Kamil Choudhury , "hackers@freebsd.org" Subject: Re: pkgng for configuration management? Message-ID: <20131111142348.GB2584@ass.pp.htv.fi> References: <20131106164807.GW11443@kiwi.coupleofllamas.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20131106164807.GW11443@kiwi.coupleofllamas.com> 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: Mon, 11 Nov 2013 14:24:07 -0000 On Wed, Nov 06, 2013 at 08:48:07AM -0800, R. Tyler Croy wrote: > On Sun, 03 Nov 2013, Kamil Choudhury wrote: > > > I've been setting up a private pkgng repository to push software to > > a family of about 20 different hosts. > > > > One command software deployment is pretty awesome, so I got to > > thinking: why not go one step further and start pushing > > configurations for each of these hosts via pkgng as well (either by > > putting the config files into the initial software pkg, or via a > > separate pkg that installs only the configurations)? > > > > Has anyone else tried going down this rabbit hole? If so, what has > > your experience with the system been? > > I highly recommend going the Puppet route instead of attempting to use the > packaging system for configuration. There's lots of horror stories in the Linux > community of people wrapping everything in the world into debs or rpms, and > regretting it later. I've done this on Linux in the past. It's a handy trick to distribute small configuration pieces for clients which are not under same administration (eg. users workstations). I used it to create meta- packages like 'company-dev-environment' which includes all basic packages for dev workstation, and packages like 'company-krb5-conf' which installs and configures a proper /etc/krb5.conf for accessing intranet services. This hack is certainly not scalable to sanely extend into a real configuration management system. In fact, I see little merit in doing it at all in any environment where I have root on the target system. -- Atte Peltomäki atte.peltomaki@iki.fi <> http://kameli.org "Your effort to remain what you are is what limits you" From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 11 17:38:31 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 28012361 for ; Mon, 11 Nov 2013 17:38:31 +0000 (UTC) (envelope-from Kamil.Choudhury@anserinae.net) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.226]) by mx1.freebsd.org (Postfix) with ESMTP id DE147295E for ; Mon, 11 Nov 2013 17:38:30 +0000 (UTC) Received: from [74.73.121.187] ([74.73.121.187:64520] helo=janus.anserinae.net) by cdptpa-oedge03 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 6E/B5-19454-51611825; Mon, 11 Nov 2013 17:38:30 +0000 Received: from JANUS.anserinae.net ([fe80::192c:4b89:9fe9:dc6d]) by janus.anserinae.net ([fe80::192c:4b89:9fe9:dc6d%11]) with mapi id 14.03.0123.003; Mon, 11 Nov 2013 12:38:29 -0500 From: Kamil Choudhury To: Atte Peltomaki , "hackers@freebsd.org" Subject: RE: pkgng for configuration management? Thread-Topic: pkgng for configuration management? Thread-Index: AQHO2yOq/7mvNW7G5EudJegpEdwvh5ogcM8A//+s2KU= Date: Mon, 11 Nov 2013 17:38:29 +0000 Message-ID: References: <20131106164807.GW11443@kiwi.coupleofllamas.com>, <20131111142348.GB2584@ass.pp.htv.fi> In-Reply-To: <20131111142348.GB2584@ass.pp.htv.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [204.4.182.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RR-Connecting-IP: 107.14.168.142:25 X-Cloudmark-Score: 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: Mon, 11 Nov 2013 17:38:31 -0000 > I've done this on Linux in the past. It's a handy trick to distribute=0A= > small configuration pieces for clients which are not under same=0A= > administration (eg. users workstations). I used it to create meta-=0A= > packages like 'company-dev-environment' which includes all basic=0A= > packages for dev workstation, and packages like 'company-krb5-conf'=0A= > which installs and configures a proper /etc/krb5.conf for accessing=0A= > intranet services.=0A= =0A= This pretty much sums up my experience. =0A= =0A= The initial distribution of configurations goes well, generally speaking, a= nd is=0A= okay for getting hosts up and running upon creation -- but woe betide you = =0A= if two packages alter the same file (necessary for things like rc.conf...).= =0A= =0A= I'm using cfengine instead -- much less finicky. = From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 12 01:11:02 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CF4551FE; Tue, 12 Nov 2013 01:11:02 +0000 (UTC) Received: from land.berklix.org (land.berklix.org [144.76.10.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 561E82FDF; Tue, 12 Nov 2013 01:11:01 +0000 (UTC) Received: from mart.js.berklix.net (p5DCBCA5C.dip0.t-ipconnect.de [93.203.202.92]) (authenticated bits=128) by land.berklix.org (8.14.5/8.14.5) with ESMTP id rAC1B0ew040207; Tue, 12 Nov 2013 01:11:00 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id rAC1AjIw035268; Tue, 12 Nov 2013 02:10:46 +0100 (CET) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost.js.berklix.net [127.0.0.1]) by fire.js.berklix.net (8.14.4/8.14.4) with ESMTP id rAC1A1jc066753; Tue, 12 Nov 2013 02:10:07 +0100 (CET) (envelope-from jhs@fire.js.berklix.net) Message-Id: <201311120110.rAC1A1jc066753@fire.js.berklix.net> To: FreeBSD-gnats-submit@freebsd.org, hackers@freebsd.org Subject: patch for /usr/src/usr.bin/fmt/ (not 8 bit clean) for German & French From: "Julian H. Stacey" In-reply-to: Your message "patch for /usr/src/usr.bin/fmt/ (not 8 bit clean) for German & French" Date: Tue, 12 Nov 2013 02:10:01 +0100 Sender: jhs@berklix.com Cc: "Bernhard Riedel \(Work\)" , Astrid Jekat , Christian Weisgerber X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list Reply-To: "Julian H. Stacey" List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 01:11:03 -0000 X-send-pr-version: 3.113 X-GNATS-Notify: >Submitter-Id: current-users >Originator: Julian H. Stacey >Organization: http://berklix.com BSD Linux Unix Consultancy, Munich/Muenchen. >Confidential: no >Synopsis: patch for /usr/src/usr.bin/fmt/ (not 8 bit clean) for German & French >Severity: non-critical >Priority: low >Category: bin >Class: change-request >Release: FreeBSD 10.0-BETA3 amd64 >Environment: System: FreeBSD fire.js.berklix.net 10.0-BETA3 FreeBSD 10.0-BETA3 #0: Mon Aug 20 18:20:09 CEST 2012 jhs@fire.js.berklix.net:/usr/src/sys/amd64/compile/FIRE64.small amd64 >Description: 2003 I looked at fmt.c to make it 8 bit clean for 4.8-RELEASE, I was conservative & my patches did just a subset, I recall. http://www.berklix.com/~jhs/src/bsd/fixes/FreeBSD/src/gen/usr.bin/fmt/ I maintained patches since. 2010 I posted to hackers@ Tue May 25 11:29:20 UTC 2010 http://lists.freebsd.org/pipermail/freebsd-hackers/2010-May/031901.html & got 1 comment: Christian's from Wed May 26 18:05:53 UTC 2010, http://lists.freebsd.org/pipermail/freebsd-hackers/2010-May/031927.html I'm still using & maintaining patches through to current & 10.0-BETA3, Tonight 2 BSD people (cc'd) asked I'd sent patches, so this also a send-pr. WRT Christian's comment from Wed May 26 18:05:53 UTC 2010, I don't know about ISO 8859-1 and UTF-8, (I dislike & avoid national char set stuff as much as possible), but I want to be able to edit files that simultaneously contain eg all of English German & French etc, so setting some var to eg just German would be inappropriate. 8 bit clean would be ideal, next best would be my patches I suppose. We no longer use 7 bit teletypes, & no longer need parity, so fmt.c could be made pretty much 8 bit clean, (apart from eg Null etc which'd doubtless be too much hastle). - Or it can be tweaked to allow some chars as I recall I did, Options presumably are still the 4 from Tue May 25 11:29:20 UTC 2010 http://lists.freebsd.org/pipermail/freebsd-hackers/2010-May/031901.html I assume either adopting Solution 1 (Discard "& 0x7f" ) or Solution 2 (my patches) would not disrupt locale users, but would stop fmt failing on some 8 bit text. >How-To-Repeat: Read the code >Fix: Look at my posting http://lists.freebsd.org/pipermail/freebsd-hackers/2010-May/031901.html & my patches http://www.berklix.com/~jhs/src/bsd/fixes/FreeBSD/src/gen/usr.bin/fmt/ From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 12 01:15:29 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4D7B45B5; Tue, 12 Nov 2013 01:15:29 +0000 (UTC) Received: from land.berklix.org (land.berklix.org [144.76.10.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CE4BB2EDF; Tue, 12 Nov 2013 01:07:27 +0000 (UTC) Received: from mart.js.berklix.net (p5DCBD0AE.dip0.t-ipconnect.de [93.203.208.174]) (authenticated bits=128) by land.berklix.org (8.14.5/8.14.5) with ESMTP id rAC17HOA040103; Tue, 12 Nov 2013 01:07:18 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id rAC1760Z035250; Tue, 12 Nov 2013 02:07:06 +0100 (CET) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost.js.berklix.net [127.0.0.1]) by fire.js.berklix.net (8.14.4/8.14.4) with ESMTP id rAC16hUx066645; Tue, 12 Nov 2013 02:06:48 +0100 (CET) (envelope-from jhs@fire.js.berklix.net) Received: (from jhs@localhost) by fire.js.berklix.net (8.14.4/8.14.3/Submit) id rAC16BNC066644; Tue, 12 Nov 2013 02:06:11 +0100 (CET) (envelope-from jhs) Date: Tue, 12 Nov 2013 02:06:11 +0100 (CET) Message-Id: <201311120106.rAC16BNC066644@fire.js.berklix.net> To: FreeBSD-gnats-submit@freebsd.org, hackers@freebsd.org Subject: patch for /usr/src/usr.bin/fmt/ (not 8 bit clean) for German & French From: "Julian H. Stacey" In-reply-to: Your message "patch for /usr/src/usr.bin/fmt/ (not 8 bit clean) for German & French" Cc: "Bernhard Riedel \(Work\)" , Astrid Jekat , Christian Weisgerber X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list Reply-To: "Julian H. Stacey" List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 01:15:29 -0000 X-send-pr-version: 3.113 X-GNATS-Notify: >Submitter-Id: current-users >Originator: Julian H. Stacey >Organization: http://berklix.com BSD Linux Unix Consultancy, Munich/Muenchen. >Confidential: no >Synopsis: patch for /usr/src/usr.bin/fmt/ (not 8 bit clean) for German & French >Severity: non-critical >Priority: low >Category: bin >Class: change-request >Release: FreeBSD 10.0-BETA3 amd64 >Environment: System: FreeBSD fire.js.berklix.net 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Mon Aug 20 18:20:09 CEST 2012 jhs@fire.js.berklix.net:/usr/src/sys/amd64/compile/FIRE64.small amd64 >Description: 2003 I looked at fmt.c to make it 8 bit clean for 4.8-RELEASE, I was conservative & my patches did just a subset, I recall. http://www.berklix.com/~jhs/src/bsd/fixes/FreeBSD/src/gen/usr.bin/fmt/ I maintained patches since. 2010 I posted to hackers@ Tue May 25 11:29:20 UTC 2010 http://lists.freebsd.org/pipermail/freebsd-hackers/2010-May/031901.html & got 1 comment: Christian's from Wed May 26 18:05:53 UTC 2010, http://lists.freebsd.org/pipermail/freebsd-hackers/2010-May/031927.html I'm still using & maintaining patches through to current & 10.0-BETA3, Tonight 2 BSD people (cc'd) asked I'd sent patches, so this also a send-pr. WRT Christian's comment from Wed May 26 18:05:53 UTC 2010, I don't know about ISO 8859-1 and UTF-8, (I dislike & avoid national char set stuff as much as possible), but I want to be able to edit files that simultaneously contain eg all of English German & French etc, so setting some var to eg just German would be inappropriate. 8 bit clean would be ideal, next best would be my patches I suppose. We no longer use 7 bit teletypes, & no longer need parity, so fmt.c could be made pretty much 8 bit clean, (apart from eg Null etc which'd doubtless be too much hastle). - Or it can be tweaked to allow some chars as I recall I did, Options presumably are still the 4 from Tue May 25 11:29:20 UTC 2010 http://lists.freebsd.org/pipermail/freebsd-hackers/2010-May/031901.html I assume either adopting Solution 1 (Discard "& 0x7f" ) or Solution 2 (my patches) would not disrupt locale users, but would stop fmt failing on some 8 bit text. >How-To-Repeat: Read the code >Fix: Look at my posting http://lists.freebsd.org/pipermail/freebsd-hackers/2010-May/031901.html & my patches http://www.berklix.com/~jhs/src/bsd/fixes/FreeBSD/src/gen/usr.bin/fmt/ From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 12 02:01:27 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 00CAD36B; Tue, 12 Nov 2013 02:01:26 +0000 (UTC) Received: from mail.crittercasa.com (mail.turbofuzz.com [208.87.221.144]) by mx1.freebsd.org (Postfix) with ESMTP id DED5A3645; Tue, 12 Nov 2013 02:01:25 +0000 (UTC) Received: from kruse-49.3.ixsystems.com (unknown [69.198.165.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.crittercasa.com (Postfix) with ESMTPS id 3CB67164842; Mon, 11 Nov 2013 17:51:56 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Subject: Re: patch for /usr/src/usr.bin/fmt/ (not 8 bit clean) for German & French From: Jordan Hubbard In-Reply-To: <201311120106.rAC16BNC066644@fire.js.berklix.net> Date: Mon, 11 Nov 2013 17:51:56 -0800 Message-Id: <4F82F771-E4D2-400F-B2A4-085595B507DA@turbofuzz.com> References: <201311120106.rAC16BNC066644@fire.js.berklix.net> To: "Julian H. Stacey" X-Mailer: Apple Mail (2.1822) X-Mailman-Approved-At: Tue, 12 Nov 2013 02:08:04 +0000 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.16 Cc: hackers@freebsd.org, FreeBSD-gnats-submit@freebsd.org, "Bernhard Riedel \(Work\)" , Astrid Jekat , Christian Weisgerber X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 02:01:27 -0000 On Nov 11, 2013, at 5:06 PM, Julian H. Stacey wrote: > I don't know about ISO 8859-1 and UTF-8, (I dislike & avoid > national char set stuff as much as possible), but I want Well, nobody can ever accuse you of following the herd! If there ever = was a herd you were a member of, in fact, I=92m sure the species has = long since gone extinct. ;-) Seriously though, this war is over and UTF-8 won. There may be some = small pockets of resistance, but they=92re demographically less than = significant (insert standard analogy here of soldiers still fighting = WWII on isolated islands in the Pacific). The Linux crowd switched as = early as 2002, and OS X has been using UTF-8 on the CLI as the default = for at least 5 years now. Required reading: http://www.cl.cam.ac.uk/~mgk25/unicode.html http://www.madboa.com/geek/utf8/ P.S. UTF-8 is not a =93national character set=94 either. It was = actually invented by Ken Thompson in 1992 and drawn on a placemat = (http://www.cl.cam.ac.uk/~mgk25/ucs/utf-8-history.txt). It has an = excellent pedigree. :) - Jordan From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 12 07:08:17 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 85B8E385; Tue, 12 Nov 2013 07:08:17 +0000 (UTC) Received: from mta.bitpro.no (mta.bitpro.no [92.42.64.202]) by mx1.freebsd.org (Postfix) with ESMTP id 45B892488; Tue, 12 Nov 2013 07:08:17 +0000 (UTC) Received: from mail.lockless.no (mail.lockless.no [46.29.221.38]) by mta.bitpro.no (Postfix) with ESMTP id 616517A10F; Tue, 12 Nov 2013 08:08:16 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.lockless.no (Postfix) with ESMTP id 2E2A78EE54F; Tue, 12 Nov 2013 08:08:48 +0100 (CET) X-Virus-Scanned: by amavisd-new-2.6.4 (20090625) (Debian) at lockless.no Received: from mail.lockless.no ([127.0.0.1]) by localhost (mail.lockless.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lcwndRzOlnym; Tue, 12 Nov 2013 08:08:47 +0100 (CET) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) by mail.lockless.no (Postfix) with ESMTPSA id 4CCE78EB95B; Tue, 12 Nov 2013 08:08:47 +0100 (CET) Message-ID: <5281D42A.6050904@bitfrost.no> Date: Tue, 12 Nov 2013 08:09:30 +0100 From: Hans Petter Selasky Organization: Bitfrost A/S User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Boris Astardzhiev , freebsd-arm@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: ARM kgdb remote debugging over USB serial References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 07:08:17 -0000 On 11/09/13 19:05, Boris Astardzhiev wrote: > Hi, > > I have a question regarding the FreeBSD kernel debugging facilities. > Has anyone succeeded in using kgdb with a target ARM machine over a USB > serial. > I've managed to build kgdb-arm > > http://bsdimp.blogspot.com/2007/10/cross-debugger.html > (This tutorial also applies to building kgdb-arm in binutils) > > So on the arm machine I enter kdb: > db> gdb > db> s > .. > > On the debugging machine I easily get into kgdb: > kgdb-arm ${KERNEL_PATH}/kernel.debug > kgdb> set remotebaud 115200 > kgdb> target remote /dev/cuaU0 (the USB interface) > > So far so good but.. It seems to connect to the ARM device but it stops on > an address kgdb has no > reference about. I thought I was missing some symbols and.. > kgdb> set solib-search-path ${KERNEL_PATH} > > This seems to load lots of symbols but still I can't backtrace or do > anything. Attempting to do a 'bt' it tells me I got a SIGTRAP. I don't seem > to understand. > > Any ideas or materials? > > Greetings, > Boris Hi, Maybe there are some bits missing in the USB serial glue part? You can try making the USB serial port the console by setting the sysctls listed below correctly. Will also work in the panic prompt: hw.usb.ucom.cons_baud: 9600 hw.usb.ucom.cons_subunit: 0 hw.usb.ucom.cons_unit: -1 --HPS From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 12 20:17:52 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CEA521E0; Tue, 12 Nov 2013 20:17:52 +0000 (UTC) Received: from mail-in-04.arcor-online.net (mail-in-04.arcor-online.net [151.189.21.44]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6DDF022D4; Tue, 12 Nov 2013 20:17:52 +0000 (UTC) Received: from mail-in-20-z2.arcor-online.net (mail-in-20-z2.arcor-online.net [151.189.8.85]) by mx.arcor.de (Postfix) with ESMTP id B7E0DAA979; Tue, 12 Nov 2013 21:17:38 +0100 (CET) Received: from mail-in-07.arcor-online.net (mail-in-07.arcor-online.net [151.189.21.47]) by mail-in-20-z2.arcor-online.net (Postfix) with ESMTP id BCC246FAE27; Tue, 12 Nov 2013 21:17:38 +0100 (CET) X-Greylist: Passed host: 188.105.81.237 X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-07.arcor-online.net 5EF6A107AFB X-Greylist: Passed host: 188.105.81.237 X-Greylist: Passed host: 188.105.81.237 X-Greylist: Passed host: 188.105.81.237 X-Greylist: Passed host: 188.105.81.237 Received: from lorvorc.mips.inka.de (dslb-188-105-081-237.pools.arcor-ip.net [188.105.81.237]) by mail-in-07.arcor-online.net (Postfix) with ESMTPS id 5EF6A107AFB; Tue, 12 Nov 2013 21:17:38 +0100 (CET) Received: from lorvorc.mips.inka.de (localhost [127.0.0.1]) by lorvorc.mips.inka.de (8.14.7/8.14.7) with ESMTP id rACKHbeR053605; Tue, 12 Nov 2013 21:17:37 +0100 (CET) (envelope-from naddy@lorvorc.mips.inka.de) Received: (from naddy@localhost) by lorvorc.mips.inka.de (8.14.7/8.14.7/Submit) id rACKHb2P053604; Tue, 12 Nov 2013 21:17:37 +0100 (CET) (envelope-from naddy) Date: Tue, 12 Nov 2013 21:17:37 +0100 From: Christian Weisgerber To: "Julian H. Stacey" Subject: Re: patch for /usr/src/usr.bin/fmt/ (not 8 bit clean) for German & French Message-ID: <20131112201737.GA52200@lorvorc.mips.inka.de> References: <201311120110.rAC1A1jc066753@fire.js.berklix.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201311120110.rAC1A1jc066753@fire.js.berklix.net> User-Agent: Mutt/1.5.22 (2013-10-16) Cc: hackers@freebsd.org, FreeBSD-gnats-submit@freebsd.org, "Bernhard Riedel \(Work\)" , Astrid Jekat X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 20:17:52 -0000 Julian H. Stacey: > I don't know about ISO 8859-1 and UTF-8, (I dislike & avoid > national char set stuff as much as possible), but I want That is your problem right there. > to be able to edit files that simultaneously contain eg all > of English German & French etc, so setting some var to eg > just German would be inappropriate. 8 bit clean would be ideal, > next best would be my patches I suppose. You MUST define a character set for this. "8-bit clean" is meaningless for a tool that deals with runs of characters. Without a defined character set, you have no idea what those bytes mean. Is 0x90 a printable character? Is it a control character? Is it part of a multibyte character? And setting, for example, LC_CTYPE=de_DE.ISO8859-1 does in no way limit you to German. For LC_CTYPE purposes, the language/country part of the locale specification isn't used. This is definitely a PEBKAC. -- Christian "naddy" Weisgerber naddy@mips.inka.de From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 12 22:00: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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 69081736 for ; Tue, 12 Nov 2013 22:00:23 +0000 (UTC) Received: from mail-ee0-x22e.google.com (mail-ee0-x22e.google.com [IPv6:2a00:1450:4013:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F01E32AC4 for ; Tue, 12 Nov 2013 22:00:22 +0000 (UTC) Received: by mail-ee0-f46.google.com with SMTP id b57so3457218eek.5 for ; Tue, 12 Nov 2013 14:00:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:content-type:content-transfer-encoding:subject:date :message-id:to:mime-version; bh=M1SONkPNSXeuMHzHpLyIBaaQqDslzEpMCLLPVOUdxzw=; b=w4IPppU8lHxZK13OGe7Ipn/Md0Vj4Vl/fymWLjVGNvZvU76xGTal0Ury7CdUM6pQNQ RFDYisB+XiftCpzGd8zSS51nTuOFvPvK/sZUSx6lvatsMswjP43rJq6sWM6ih3e1Oy25 S+I8OMKVbivMgOSmVofPeOY4aAs6kIygER6FmYEWERiJJVNjw9ssKMLPWpACunLQ+fBU oFtYrKcgsxiTumHaptEXe2dyKKKDDXMKHAw2OgbYgSCVNufQsDbuxsn7T7ZhZESbldEV Ksp50NkoGzLPlQXxuFIxkmDbRAoidWxti1fq4aE+TpSHszWi5NL9AcCc2/vqReDBoAHh grgQ== X-Received: by 10.14.103.69 with SMTP id e45mr18273674eeg.51.1384293621337; Tue, 12 Nov 2013 14:00:21 -0800 (PST) Received: from [192.168.1.102] (45.81.datacomsa.pl. [195.34.81.45]) by mx.google.com with ESMTPSA id x4sm80538609eef.1.2013.11.12.14.00.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Nov 2013 14:00:20 -0800 (PST) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: syslog(3) and truncated messages. Date: Tue, 12 Nov 2013 23:00:19 +0100 Message-Id: To: freebsd-hackers Hackers Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 22:00:23 -0000 I have a daemon (namely ctld(8)) that, when running with debug enabled, outputs a lot of information to the syslog, using the usual syslog(3) API. Problem is, the output gets truncated: at some point the log messages from all involved processes stop getting logged, even though the processes continue to run, confirmed by subsequent kernel messages, which get logged properly. Any idea what might be going on? -- If you cut off my head, what would I say? Me and my head, or me and my body? From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 12 22:54:47 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BB1F6D55; Tue, 12 Nov 2013 22:54:47 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 92D7E2EB4; Tue, 12 Nov 2013 22:54:47 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VgMr8-0008An-Kl; Tue, 12 Nov 2013 22:54:46 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id rACMsiK1071272; Tue, 12 Nov 2013 15:54:44 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+4w8bTVdYRY7ghXAGB4UM/ Subject: Re: syslog(3) and truncated messages. From: Ian Lepore To: Edward Tomasz =?iso-8859-2?Q?Napiera=B3a?= In-Reply-To: References: Content-Type: text/plain; charset="iso-8859-2" Date: Tue, 12 Nov 2013 15:54:44 -0700 Message-ID: <1384296884.31172.351.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by damnhippie.dyndns.org id rACMsiK1071272 Cc: freebsd-hackers Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 22:54:47 -0000 On Tue, 2013-11-12 at 23:00 +0100, Edward Tomasz Napiera=B3a wrote: > I have a daemon (namely ctld(8)) that, when running with debug enabled, > outputs a lot of information to the syslog, using the usual syslog(3) A= PI. > Problem is, the output gets truncated: at some point the log messages > from all involved processes stop getting logged, even though the proces= ses > continue to run, confirmed by subsequent kernel messages, which get log= ged > properly. >=20 > Any idea what might be going on? >=20 There is a long-standing problem with buffer allocation in syslogd. It allocates tiny socket buffers and burst of high-volume logging often just loses most of the packets. I filed a pr and a patch years ago [1], but it probably won't apply cleanly anymore. Oddly enough I was thinking just a few days ago about getting it cleaned up and committing it myself, I just haven't had time since it occurred to me. We've been using it at $work for years so it's well-tested. [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dbin/160433 -- Ian From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 12 23:28:58 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8BE09713; Tue, 12 Nov 2013 23:28:58 +0000 (UTC) Received: from caravan.chchile.org (caravan.chchile.org [178.32.125.136]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 21D5120FE; Tue, 12 Nov 2013 23:28:58 +0000 (UTC) Received: by caravan.chchile.org (Postfix, from userid 1000) id 6CB4AC25D5; Tue, 12 Nov 2013 23:28:56 +0000 (UTC) Date: Wed, 13 Nov 2013 00:28:56 +0100 From: Jeremie Le Hen To: Julio Merino Subject: Re: Importing netbsd cdb Message-ID: <20131112232856.GJ37879@caravan.chchile.org> Mail-Followup-To: Julio Merino , Baptiste Daroussin , hackers@freebsd.org, Atte Peltomaki References: <20131027232628.GB74512@ithaqua.etoilebsd.net> <20131105220225.GF37879@caravan.chchile.org> <20131106084550.GA21489@ass.pp.htv.fi> <20131106103947.GI56315@ithaqua.etoilebsd.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Baptiste Daroussin , hackers@freebsd.org, Atte Peltomaki X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 23:28:58 -0000 On Wed, Nov 06, 2013 at 10:57:10PM -0500, Julio Merino wrote: > On Wed, Nov 6, 2013 at 5:39 AM, Baptiste Daroussin wrote: > > From the netbsd commit log, it says that in case of services it is at least as > > slow, and at best faster, from my testing it is way faster, (sorry no numbers) > > > > Concerning the migration, the way I did it for now, is that getservent is trying > > to open the cdb database and fallsback on the bdb one, so migrating to > > 11.0-RELEASE should be ootb. > > > > Running: > > services_mkdb > > > > Will generate the cdb version of the db > > Hmm... but who would be in charge of running this conversion process > during an upgrade to 11? The administrator by hand, or would this be > automated in some manner? > > Also, if this is expected to be done by hand: it's possible for > somebody to forget doing the conversion when upgrading to 11. Would > there be any notices announcing that the old format is deprecated and > would go away by 12? I'm having in mind a failure case where you > upgrade from 11 to 12 and things break because you forgot to rebuild > the database with 11 (which is the release that allows you to do the > conversion). We could probably cover that case with the release notes, although it would be preferable to have a technical way to enforce this conversion. Maybe mergemaster(8), although I'm not sure it's part of the official way to upgrade from one release to another. We have to give some thinking as well on people upgrading using freebsd-update(8). -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 13 01:06:19 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 850887B3; Wed, 13 Nov 2013 01:06:19 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5BBAE262D; Wed, 13 Nov 2013 01:06:18 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VgOuP-000B6N-Sm; Wed, 13 Nov 2013 01:06:18 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id rAD16Ftu071406; Tue, 12 Nov 2013 18:06:15 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/0Ir+fbNpowy3Fv2H3Gq85 Subject: Re: syslog(3) and truncated messages. From: Ian Lepore To: Edward Tomasz =?iso-8859-2?Q?Napiera=B3a?= In-Reply-To: References: Content-Type: text/plain; charset="iso-8859-2" Date: Tue, 12 Nov 2013 18:06:15 -0700 Message-ID: <1384304775.31172.356.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by damnhippie.dyndns.org id rAD16Ftu071406 Cc: freebsd-hackers Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 01:06:19 -0000 On Tue, 2013-11-12 at 23:00 +0100, Edward Tomasz Napiera=B3a wrote: > I have a daemon (namely ctld(8)) that, when running with debug enabled, > outputs a lot of information to the syslog, using the usual syslog(3) A= PI. > Problem is, the output gets truncated: at some point the log messages > from all involved processes stop getting logged, even though the proces= ses > continue to run, confirmed by subsequent kernel messages, which get log= ged > properly. >=20 > Any idea what might be going on? >=20 It turns out I had newer patches that did apply cleanly for this, so I committed them as r258076 and r258077 (since they really addressed two completely separate items). Hopefully this will fix the glitches you're seeing. -- Ian From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 13 02:35:29 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AA658F54 for ; Wed, 13 Nov 2013 02:35:29 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 9444F2B73 for ; Wed, 13 Nov 2013 02:35:29 +0000 (UTC) Received: from Alfreds-MacBook-Air.local (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id 0B40D1A3C6D; Tue, 12 Nov 2013 18:35:28 -0800 (PST) Message-ID: <5282E56F.4020307@freebsd.org> Date: Tue, 12 Nov 2013 18:35:27 -0800 From: Alfred Perlstein Organization: FreeBSD User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "Teske, Devin" , FreeBSD Hackers Subject: Loader forth changes for customization Content-Type: multipart/mixed; boundary="------------070004070708090008010005" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 02:35:29 -0000 This is a multi-part message in MIME format. --------------070004070708090008010005 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hey folks, I added some forth using Devin's help to make it easier to customize the FreeBSD boot loader graphics. Diffs are here: https://github.com/alfredperlstein/freebsd/compare/loader_custom_rc -or- https://github.com/alfredperlstein/freebsd/compare/loader_custom_rc.diff Diff attached. Also attached is a custom loader.rc file and loader.conf file that shows how to set the brand/logo. Please review. -Alfred --------------070004070708090008010005 Content-Type: text/plain; charset=UTF-8; x-mac-type="0"; x-mac-creator="0"; name="loader_custom_rc.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="loader_custom_rc.diff" diff --git a/sys/boot/forth/beastie.4th b/sys/boot/forth/beastie.4th index 4a107af..5c5a209 100644 --- a/sys/boot/forth/beastie.4th +++ b/sys/boot/forth/beastie.4th @@ -251,6 +251,15 @@ variable logoY 2drop exit then + \ if it refers to a raw symbol then run that function + sfind if + logoX @ logoY @ + 2 roll + execute + else + drop + then + 2drop ; diff --git a/sys/boot/forth/brand.4th b/sys/boot/forth/brand.4th index b6f22c8..3230953 100644 --- a/sys/boot/forth/brand.4th +++ b/sys/boot/forth/brand.4th @@ -87,5 +87,14 @@ variable brandY 2drop exit then + \ if it refers to a raw symbol then run that function + sfind if + brandX @ brandY @ + 2 roll + execute + else + drop + then + 2drop ; diff --git a/sys/boot/forth/loader.rc b/sys/boot/forth/loader.rc index a84753d..86ad695e 100644 --- a/sys/boot/forth/loader.rc +++ b/sys/boot/forth/loader.rc @@ -8,6 +8,11 @@ include /boot/loader.4th \ NOTE: Change to `initialize' if you enable the below boot menu start +\ Load in any local forth files +only forth also support-functions +s" /boot/loader.rc.local" source-if-exists +only forth also + \ Tests for password -- executes autoboot first if a password was defined check-password diff --git a/sys/boot/forth/support.4th b/sys/boot/forth/support.4th index 645e14d..c4f96b5 100644 --- a/sys/boot/forth/support.4th +++ b/sys/boot/forth/support.4th @@ -861,6 +861,40 @@ only forth also support-functions definitions throw ; +\ Does the file exist? +: file-exists? ( c-addr/u -- bool ) + O_RDONLY fopen \ open file + dup \ save a copy to not leak + -1 <> if + fclose true + else + drop false + then +; + +\ Source file as code if it exists. +: source-if-exists ( c-addr/u -- ) + + 2dup file-exists? if + \ If file exists then prepend "include" to it + + \ first allocate a string, top of stack is strlen of + \ the filename, so just add a comfortable 15 bytes to it. + dup 15 + + allocate if ENOMEM throw then + 0 + + s" include " strcat + \ grab the original string up so we can strcat + 3 roll 3 roll + strcat + + \ evaluate " include file" + 2dup evaluate + drop free + then +; + : print_line line_buffer strtype cr ; : print_syntax_error --------------070004070708090008010005 Content-Type: text/plain; charset=UTF-8; x-mac-type="0"; x-mac-creator="0"; name="loader.rc.local" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="loader.rc.local" : truenas-logo ( x y -- ) \ "TrueNAS" logo in B/W (13 rows x 21 columns) 5 + swap 6 + swap 2dup at-xy ." ______" 1+ 2dup at-xy ." |__ ___| __ _ _ ___ " 1+ 2dup at-xy ." | | | '__|| | |/ _ \" 1+ 2dup at-xy ." | | | | | | | / __/" 1+ 2dup at-xy ." | | | | | |_| | |" 1+ 2dup at-xy ." |_| |_| |_____|\___|" 1+ 2dup at-xy ." _ _ __ _____" 1+ 2dup at-xy ." | \ | | / \ / ___|" 1+ 2dup at-xy ." | \ | |/ /\ \| (__" 1+ 2dup at-xy ." | |\\ | | |__| |\___ \" 1+ 2dup at-xy ." | | \\| | __ |____) |" 1+ 2dup at-xy ." | | \ | | | | |" 1+ at-xy ." |_| \_|_| |_|_____/" \ Put the cursor back at the bottom 0 25 at-xy ; : truenas-brand ( x y -- ) \ "Brand" [wide] logo in B/W (7 rows x 42 columns) 2dup at-xy ." ______ _ _ __ _____ " 1+ 2dup at-xy ." |__ ___| | \ | | / \ / ___|" 1+ 2dup at-xy ." | | ____ _ __ ___| \ | |/ /\ \| (__" 1+ 2dup at-xy ." | || '__|| | |/ _ \ |\\ | | |__| |\___ \" 1+ 2dup at-xy ." | || | | | | / __/ | \\| | __ |____) |" 1+ 2dup at-xy ." | || | | |_| | | | \ | | | | |" 1+ at-xy ." |_||_| |_____|\___|_| \_|_| |_|_____/" \ Put the cursor back at the bottom 0 25 at-xy ; --------------070004070708090008010005 Content-Type: text/plain; charset=UTF-8; x-mac-type="0"; x-mac-creator="0"; name="loader.conf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="loader.conf" loader_logo="truenas-logo" loader_menu_title="Welcome to TrueNAS" loader_brand="truenas-brand" --------------070004070708090008010005-- From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 13 06:45:26 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0325ED0F; Wed, 13 Nov 2013 06:45:26 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id E4A592824; Wed, 13 Nov 2013 06:45:25 +0000 (UTC) Received: from Alfreds-MacBook-Air.local (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id 1F3CE1A3C39; Tue, 12 Nov 2013 22:45:24 -0800 (PST) Message-ID: <52832003.8080406@freebsd.org> Date: Tue, 12 Nov 2013 22:45:23 -0800 From: Alfred Perlstein Organization: FreeBSD User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "Teske, Devin" , FreeBSD Hackers Subject: Re: Loader forth changes for customization References: <5282E56F.4020307@freebsd.org> In-Reply-To: <5282E56F.4020307@freebsd.org> Content-Type: multipart/mixed; boundary="------------010502020707020201000600" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 06:45:26 -0000 This is a multi-part message in MIME format. --------------010502020707020201000600 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit I added some hooks for menu.rc as well, you can see it via the github urls below. I've attached a sample menu.rc.local that provides additional menus. -Alfred On 11/12/13, 6:35 PM, Alfred Perlstein wrote: > Hey folks, > > I added some forth using Devin's help to make it easier to customize > the FreeBSD boot loader graphics. > > Diffs are here: > https://github.com/alfredperlstein/freebsd/compare/loader_custom_rc > -or- > https://github.com/alfredperlstein/freebsd/compare/loader_custom_rc.diff > > > Diff attached. > > Also attached is a custom loader.rc file and loader.conf file that > shows how to set the brand/logo. > > Please review. > > -Alfred --------------010502020707020201000600 Content-Type: text/plain; charset=UTF-8; x-mac-type="0"; x-mac-creator="0"; name="menu.rc.local" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="menu.rc.local" CjogemZzcmVjb3Zlcl9lbmFibGVkPyAoIC0tIGZsYWcgKQogICAgICAgIHMiIHZmcy56ZnMu cmVjb3ZlciIgZ2V0ZW52IC0xIDw+IGR1cCBpZgogICAgICAgICAgICAgICAgc3dhcCBkcm9w ICggYy1hZGRyIGZsYWcgLS0gZmxhZyApCiAgICAgICAgdGhlbgo7Cgo6IHpmc3JlY292ZXJf ZW5hYmxlICggLS0gKQogICAgICAgIHMiIHNldCB2ZnMuemZzLnJlY292ZXI9MSIgZXZhbHVh dGUKOwoKOiB6ZnNyZWNvdmVyX2Rpc2FibGUgKCAtLSApCiAgICAgICAgcyIgdmZzLnpmcy5y ZWNvdmVyIiB1bnNldGVudgo7Cgo6IGluaXRfemZzcmVjb3ZlciAoIE4gLS0gTiApCiAgICAg ICAgemZzcmVjb3Zlcl9lbmFibGVkPyBpZgogICAgICAgICAgICAgICAgdG9nZ2xlX21lbnVp dGVtICggbiAtLSBuICkKICAgICAgICB0aGVuCjsKCjogdG9nZ2xlX3pmc3JlY292ZXIgKCBO IC0tIE4gVFJVRSApCiAgICAgICAgdG9nZ2xlX21lbnVpdGVtCiAgICAgICAgbWVudS1yZWRy YXcKCiAgICAgICAgXCBOb3cgd2UncmUgZ29pbmcgdG8gbWFrZSB0aGUgY2hhbmdlIGVmZmVj dGl2ZQoKICAgICAgICBkdXAgdG9nZ2xlX3N0YXRlTiBAIDA9IGlmCiAgICAgICAgICAgICAg ICB6ZnNyZWNvdmVyX2Rpc2FibGUKICAgICAgICBlbHNlCiAgICAgICAgICAgICAgICB6ZnNy ZWNvdmVyX2VuYWJsZQogICAgICAgIHRoZW4KCiAgICAgICAgVFJVRSBcIGxvb3AgbWVudSBh Z2Fpbgo7CgoKc2V0IG9wdGlvbnNtZW51X2luaXRbN109ImluaXRfemZzcmVjb3ZlciIKc2V0 IG9wdGlvbnNtZW51X2NhcHRpb25bN109IkJvb3QgW1pdRlMgUmVjb3ZlcjogTk8iCnNldCBv cHRpb25zdG9nZ2xlZF90ZXh0WzddPSJCb290IFtaXUZTIFJlY292ZXI6IFlFUyIKc2V0IG9w dGlvbnNtZW51X2NvbW1hbmRbN109InRvZ2dsZV96ZnNyZWNvdmVyIgpzZXQgb3B0aW9uc21l bnVfa2V5Y29kZVs3XT0iMTIyIgpzZXQgb3B0aW9uc2Fuc2lfY2FwdGlvbls3XT0iQm9vdCAb WzFtWhtbMzdtRlMgUmVjb3ZlcjogG1szNDsxbU5PG1szN20iCnNldCBvcHRpb25zdG9nZ2xl ZF9hbnNpWzddPSJCb290IBtbMW1aG1szN21GUyBSZWNvdmVyOiAbWzMyOzdtWUVTG1swOzM3 bSIKCg== --------------010502020707020201000600-- From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 13 08:18:19 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ADC135EC; Wed, 13 Nov 2013 08:18:19 +0000 (UTC) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7B9B12D36; Wed, 13 Nov 2013 08:18:19 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.17]) by ltcfislmsgpa07.fnfis.com (8.14.5/8.14.5) with ESMTP id rAD8IIUF025282 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 13 Nov 2013 02:18:18 -0600 Received: from LTCFISWMSGMB21.FNFIS.com ([169.254.1.152]) by LTCFISWMSGHT06.FNFIS.com ([10.132.206.17]) with mapi id 14.03.0158.001; Wed, 13 Nov 2013 02:18:17 -0600 From: "Teske, Devin" To: Alfred Perlstein Subject: Re: Loader forth changes for customization Thread-Topic: Loader forth changes for customization Thread-Index: AQHO4EjnMi0GIoZQO0eCkJ5RnRP0Cw== Date: Wed, 13 Nov 2013 08:18:16 +0000 Message-ID: <09673101-DB54-4D25-9989-8C80D06E266B@fisglobal.com> References: <5282E56F.4020307@freebsd.org> <52832003.8080406@freebsd.org> In-Reply-To: <52832003.8080406@freebsd.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.120] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.14, 0.0.0000 definitions=2013-11-13_03:2013-11-12,2013-11-13,1970-01-01 signatures=0 Cc: FreeBSD Hackers , Devin Teske , "Teske, Devin" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list Reply-To: Devin Teske List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 08:18:19 -0000 On Nov 12, 2013, at 10:45 PM, Alfred Perlstein wrote: > I added some hooks for menu.rc as well, you can see it via the github url= s below. >=20 > I've attached a sample menu.rc.local that provides additional menus. >=20 > -Alfred >=20 > On 11/12/13, 6:35 PM, Alfred Perlstein wrote: >> Hey folks, >>=20 >> I added some forth using Devin's help to make it easier to customize the= FreeBSD boot loader graphics. >>=20 >> Diffs are here: >> https://github.com/alfredperlstein/freebsd/compare/loader_custom_rc >> -or- >> https://github.com/alfredperlstein/freebsd/compare/loader_custom_rc.diff >>=20 >>=20 >> Diff attached. >>=20 >> Also attached is a custom loader.rc file and loader.conf file that shows= how to set the brand/logo. >>=20 >> Please review. >>=20 I signed up for a github account (thanks), and I started commenting on some= lines. >> -Alfred >=20 > Hmmm, I hadn't realized that you could say: set foo=3Dbar Along-side setting functions in the same file. I don't think you can set functions in an *.rc file, only in a *.4th file? No? Maybe it's a false misconception of mine. I've been keeping them separate for years. (but probably rightfully so, to keep *.rc files clean). --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 13 12:25:33 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 09A5CD56; Wed, 13 Nov 2013 12:25:33 +0000 (UTC) Received: from mail-ee0-x22c.google.com (mail-ee0-x22c.google.com [IPv6:2a00:1450:4013:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6EED22D12; Wed, 13 Nov 2013 12:25:32 +0000 (UTC) Received: by mail-ee0-f44.google.com with SMTP id d51so179651eek.3 for ; Wed, 13 Nov 2013 04:25:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lydcrqUTgt0Q48Uym2bgXa19q/vgMiWqi98+F6q63p4=; b=l90xf8yO3KoZphNMyhf+0j6/nVGxUrlV8KBEgSGYahi5vA2YYKlmHynKsect6LTn4H Pi+4ntT/Y92ax9FP/85Kn83HJruriHo0rUpvILugb3D7YXXJAJcnGZ9DKdgqhrQuJqJT 5CzizrWG+kzThRmFjEBcE5ExX5GUjR/NXiy0v8Xtu91mLWqClKlxNe+uBtzDmrmFyzHe 1XC+pOn1Ymst/sQ1U/RVbwQd3c2zME5BgFLTKuny9vaeZjkhdtTz0ZUS8+dFCA8lNFEk +B8SCrNx99DCqV1Vyge+I48NUnPXnOxX1XKoJiuE4eqUicKNcd5alH93N1cvLkAmZ1Aj nQ5A== X-Received: by 10.14.241.74 with SMTP id f50mr49201409eer.29.1384345530831; Wed, 13 Nov 2013 04:25:30 -0800 (PST) Received: from [192.168.1.102] (45.81.datacomsa.pl. [195.34.81.45]) by mx.google.com with ESMTPSA id a6sm87609025eei.10.2013.11.13.04.25.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Nov 2013 04:25:30 -0800 (PST) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Subject: Re: syslog(3) and truncated messages. Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-2 From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= In-Reply-To: <1384304775.31172.356.camel@revolution.hippie.lan> Date: Wed, 13 Nov 2013 13:25:28 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6B288F99-5AEF-4F63-9ACD-00307A5CA472@FreeBSD.org> References: <1384304775.31172.356.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1283) Cc: freebsd-hackers Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 12:25:33 -0000 Wiadomo=B6=E6 napisana przez Ian Lepore w dniu 13 lis 2013, o godz. = 02:06: > On Tue, 2013-11-12 at 23:00 +0100, Edward Tomasz Napiera=B3a wrote: >> I have a daemon (namely ctld(8)) that, when running with debug = enabled, >> outputs a lot of information to the syslog, using the usual syslog(3) = API. >> Problem is, the output gets truncated: at some point the log messages >> from all involved processes stop getting logged, even though the = processes >> continue to run, confirmed by subsequent kernel messages, which get = logged >> properly. >>=20 >> Any idea what might be going on? >>=20 >=20 > It turns out I had newer patches that did apply cleanly for this, so I > committed them as r258076 and r258077 (since they really addressed two > completely separate items). >=20 > Hopefully this will fix the glitches you're seeing. Yes, the problem seems to be fixed. Thanks! --=20 If you cut off my head, what would I say? Me and my head, or me and my = body? From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 13 14:57:03 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 84C931A7; Wed, 13 Nov 2013 14:57:03 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 734212793; Wed, 13 Nov 2013 14:57:03 +0000 (UTC) Received: from Alfreds-MacBook-Air.local (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id E41381A3C60; Wed, 13 Nov 2013 06:57:02 -0800 (PST) Message-ID: <5283933E.30603@freebsd.org> Date: Wed, 13 Nov 2013 06:57:02 -0800 From: Alfred Perlstein Organization: FreeBSD User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Devin Teske Subject: Re: Loader forth changes for customization References: <5282E56F.4020307@freebsd.org> <52832003.8080406@freebsd.org> <09673101-DB54-4D25-9989-8C80D06E266B@fisglobal.com> In-Reply-To: <09673101-DB54-4D25-9989-8C80D06E266B@fisglobal.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Hackers , "Teske, Devin" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 14:57:03 -0000 On 11/13/13, 12:18 AM, Teske, Devin wrote: > On Nov 12, 2013, at 10:45 PM, Alfred Perlstein wrote: > >> I added some hooks for menu.rc as well, you can see it via the github urls below. >> >> I've attached a sample menu.rc.local that provides additional menus. >> >> -Alfred >> >> On 11/12/13, 6:35 PM, Alfred Perlstein wrote: >>> Hey folks, >>> >>> I added some forth using Devin's help to make it easier to customize the FreeBSD boot loader graphics. >>> >>> Diffs are here: >>> https://github.com/alfredperlstein/freebsd/compare/loader_custom_rc >>> -or- >>> https://github.com/alfredperlstein/freebsd/compare/loader_custom_rc.diff >>> >>> >>> Diff attached. >>> >>> Also attached is a custom loader.rc file and loader.conf file that shows how to set the brand/logo. >>> >>> Please review. >>> > I signed up for a github account (thanks), and I started commenting on some lines. yay! :) > >>> -Alfred >> > Hmmm, I hadn't realized that you could say: > > set foo=bar > > Along-side setting functions in the same file. > > I don't think you can set functions in an *.rc file, only in a *.4th file? > > No? Maybe it's a false misconception of mine. I've been keeping them > separate for years. (but probably rightfully so, to keep *.rc files clean). It seems to work although I will talk to the team about making separate files for the set commands. I've responded to your review comments here: https://github.com/alfredperlstein/freebsd/commit/0ca72dccd78b880b3e3ef4c2bb9ce025950a370b#commitcomment-4584862 The changes I made are now in the branch https://github.com/alfredperlstein/freebsd/tree/loader_custom_rc and you likely should see them in the updated pull request I sent you. -Alfred From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 13 18:01:51 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F2112449; Wed, 13 Nov 2013 18:01:50 +0000 (UTC) Received: from mail.iXsystems.com (newknight.ixsystems.com [206.40.55.70]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4239023FF; Wed, 13 Nov 2013 18:01:50 +0000 (UTC) Received: from localhost (mail.ixsystems.com [10.2.55.1]) by mail.iXsystems.com (Postfix) with ESMTP id 17A0E68670; Wed, 13 Nov 2013 10:01:50 -0800 (PST) Received: from mail.iXsystems.com ([10.2.55.1]) by localhost (mail.ixsystems.com [10.2.55.1]) (maiad, port 10024) with ESMTP id 38107-10; Wed, 13 Nov 2013 10:01:49 -0800 (PST) Received: from [10.20.30.117] (125.sub-70-197-9.myvzw.com [70.197.9.125]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.iXsystems.com (Postfix) with ESMTPSA id 52AF368660; Wed, 13 Nov 2013 10:01:48 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1812\)) Subject: Re: Loader forth changes for customization From: Jordan Hubbard In-Reply-To: <5283933E.30603@freebsd.org> Date: Wed, 13 Nov 2013 10:01:47 -0800 Message-Id: References: <5282E56F.4020307@freebsd.org> <52832003.8080406@freebsd.org> <09673101-DB54-4D25-9989-8C80D06E266B@fisglobal.com> <5283933E.30603@freebsd.org> To: Alfred Perlstein X-Mailer: Apple Mail (2.1812) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.16 Cc: FreeBSD Hackers , Devin Teske , "Teske, Devin" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 18:01:51 -0000 On Nov 13, 2013, at 6:57 AM, Alfred Perlstein = wrote: > It seems to work although I will talk to the team about making = separate files for the set commands. Since we=92re talking about this, there is an old maxim amongst FORTH = programmers that if a single word=92s definition takes more than a page, = it=92s just too dang long. There are some solid reasons for that, = namely the fact that forth is already hard enough to read as it is (and = I=92m speaking as a FAN of the language) and you generally need to keep = the =93internal stack state=94 in your head while writing a word since = the stack contract is only at word boundaries (e.g. word is defined as = tacking stack parameters foo and returning stack parameters bar). = Keeping the definitions short and sweet really helps to aid in = comprehension. The definition for draw-beastie currently violates that maxim, and if = you guys were to refactor it as part of this work, I=92m sure future = generations would not object! :) - Jordan From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 13 18:55:55 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8ED06623; Wed, 13 Nov 2013 18:55:55 +0000 (UTC) Received: from land.berklix.org (land.berklix.org [144.76.10.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1B90C279D; Wed, 13 Nov 2013 18:55:54 +0000 (UTC) Received: from mart.js.berklix.net (pD9FBF93E.dip0.t-ipconnect.de [217.251.249.62]) (authenticated bits=128) by land.berklix.org (8.14.5/8.14.5) with ESMTP id rADHnl65034739; Wed, 13 Nov 2013 17:49:47 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id rADHnYGD046696; Wed, 13 Nov 2013 18:49:34 +0100 (CET) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost.js.berklix.net [127.0.0.1]) by fire.js.berklix.net (8.14.4/8.14.4) with ESMTP id rADHmpxG084992; Wed, 13 Nov 2013 18:48:57 +0100 (CET) (envelope-from jhs@fire.js.berklix.net) Message-Id: <201311131748.rADHmpxG084992@fire.js.berklix.net> to: hackers@freebsd.org Subject: Re: patch for /usr/src/usr.bin/fmt/ (not 8 bit clean) for German & French From: "Julian H. Stacey" Organization: http://berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Tue, 12 Nov 2013 21:17:37 +0100." <20131112201737.GA52200@lorvorc.mips.inka.de> Date: Wed, 13 Nov 2013 18:48:51 +0100 Sender: jhs@berklix.com Cc: Jordan Hubbard , FreeBSD-gnats-submit@freebsd.org, "Bernhard Riedel \(Work\)" , Astrid Jekat , Christian Weisgerber X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 18:55:55 -0000 Christian Weisgerber wrote: > Julian H. Stacey: > > > I don't know about ISO 8859-1 and UTF-8, (I dislike & avoid > > national char set stuff as much as possible), but I want > > That is your problem right there. My perspective & experience or `problem' as you mislabel it, is I was supporting Unix Internationalisation back in 1985, & long since tired of agravating German umlauts issues (Umlauts even back then had AE OE UE [& SS] replacements but few used them). Your problem is being German you had an incentive to attain umlauts, & probably being younger, wasted less time achieving umlauts going straight to the since available UTF; but myopic that others may be averse to waste more time for superflous national oddities that cleaner Roman derivatives like Italian & English etc find superfluous. It seemed best to make fmt.c 8 bit clean[er], to help process arbitrary text, harm no one, & not disturb users of eg UTF. Your problem is you would obstruct a cleaner fmt, so fmt continues to fail until users are forced to waste their time too like you did, reading & configuring internationalisation variables some don't need. ** > > to be able to edit files that simultaneously contain eg all > > of English German & French etc, so setting some var to eg > > just German would be inappropriate. 8 bit clean would be ideal, > > next best would be my patches I suppose. > > You MUST define a character set for this. "8-bit clean" is meaningless > for a tool that deals with runs of characters. Without a defined > character set, you have no idea what those bytes mean. Is 0x90 a Not true. See below. ** > printable character? Is it a control character? Is it part of a > multibyte character? > > And setting, for example, LC_CTYPE=de_DE.ISO8859-1 does in no way > limit you to German. For LC_CTYPE purposes, the language/country > part of the locale specification isn't used. > > This is definitely a PEBKAC. Avoid junk acronyms. Re-Read original post http://lists.freebsd.org/pipermail/freebsd-hackers/2010-May/031901.html Particularly: Example: Pasting notes into an xterm, clauses from http://seafrance.com in English then French original & German, to get the feel of what an unclear English translation **: Sometimes I mouse paste from Firefox in English, French, German & other languages, making notes in a single file with vi in an xterm, all with standard env. no Locale. & it edits OK in vi, & displays with cat in xterm, till !}fmt in vi wraps long lines, when fmt breaks it. So I fixed fmt. It would Not be appropriate to set a German locale, nor a French etc. Other utils might misbehave now or later See eg man sort re LC_ALL. No way I'd keep exiting vi & resetting LC_CTYPE between mouse pastes from different language pages, The default American works fine. I'm not bothered if vi+xterm might mis-display some odd accent, as I can see something is there, so long as fmt does not strip the accent, but FreeBSD fmt.c Does strip the French accents & German umlauts, that's why I fixed fmt.c Summary: Making fmt.c 8 bit cleaner would not break UTF & unicode I believe so no reason to object to removal of fmt.c '& 0x7f' cruft etc. Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultant, Munich http://berklix.com Interleave replies below like a play script. Indent old text with "> ". Send plain text, not quoted-printable, HTML, base64, or multipart/alternative. Extradite NSA spy chief Alexander. http://berklix.eu/jhs/blog/2013_10_30 From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 13 18:58:26 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B5973870; Wed, 13 Nov 2013 18:58:26 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id A171B27DE; Wed, 13 Nov 2013 18:58:26 +0000 (UTC) Received: from Alfreds-MacBook-Air.local (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id C813A1A3C69; Wed, 13 Nov 2013 10:58:25 -0800 (PST) Message-ID: <5283CBD1.9010606@freebsd.org> Date: Wed, 13 Nov 2013 10:58:25 -0800 From: Alfred Perlstein Organization: FreeBSD User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Jordan Hubbard Subject: Re: Loader forth changes for customization References: <5282E56F.4020307@freebsd.org> <52832003.8080406@freebsd.org> <09673101-DB54-4D25-9989-8C80D06E266B@fisglobal.com> <5283933E.30603@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: FreeBSD Hackers , Devin Teske , "Teske, Devin" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 18:58:26 -0000 On 11/13/13, 10:01 AM, Jordan Hubbard wrote: > On Nov 13, 2013, at 6:57 AM, Alfred Perlstein wrote: > >> It seems to work although I will talk to the team about making separate files for the set commands. > Since we’re talking about this, there is an old maxim amongst FORTH programmers that if a single word’s definition takes more than a page, it’s just too dang long. There are some solid reasons for that, namely the fact that forth is already hard enough to read as it is (and I’m speaking as a FAN of the language) and you generally need to keep the “internal stack state” in your head while writing a word since the stack contract is only at word boundaries (e.g. word is defined as tacking stack parameters foo and returning stack parameters bar). Keeping the definitions short and sweet really helps to aid in comprehension. > > The definition for draw-beastie currently violates that maxim, and if you guys were to refactor it as part of this work, I’m sure future generations would not object! :) I'll give that a shot shortly. -Alfred From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 13 20:58:33 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A0B81E1E; Wed, 13 Nov 2013 20:58:33 +0000 (UTC) Received: from mail-ve0-x233.google.com (mail-ve0-x233.google.com [IPv6:2607:f8b0:400c:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 530112EC1; Wed, 13 Nov 2013 20:58:33 +0000 (UTC) Received: by mail-ve0-f179.google.com with SMTP id oz11so790054veb.24 for ; Wed, 13 Nov 2013 12:58:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=deZ16qQlW9G44hotWbDShH5K/JB+iFdxbVUGmnNnfBI=; b=t5rl5YKYg7Tgfh9Gut4Y/83A/y78QPenvuxcR8zc1eht6SIa4BkysS99Rk0nvMb2ij 4xZ5ynL4nPDCNc8pfAdNVSX+vRpkitLPKt++02RI2USyD+Ij0dPkpWMl1Yd5s7/rGRyu 7GY+rmBK8dbWNpcK4D8MfUIv4Y1SIUmx0NFTAo1VO/TD0kFTsWWnh7AF1CvzaOAaqKD/ RLxmA8qoOP8cO4ro2GAzjzDKp+bdBF5ZxR7TIGXUQzv5Qig+xZG2JHej82EHOXIsk/dJ hR3kzpvJZ+j+DI8+LIqsalaPouhSpHpF/Z9Id38BE6VhC4sI/aSVY03BGS1xbEGVx13I A7Xw== MIME-Version: 1.0 X-Received: by 10.58.254.38 with SMTP id af6mr172260ved.85.1384376312230; Wed, 13 Nov 2013 12:58:32 -0800 (PST) Sender: edschouten@gmail.com Received: by 10.220.104.209 with HTTP; Wed, 13 Nov 2013 12:58:32 -0800 (PST) Date: Wed, 13 Nov 2013 21:58:32 +0100 X-Google-Sender-Auth: lg7pgfzFbjnWbezi5qi9dob0LI4 Message-ID: Subject: Re: misc/183495: utx.active not being updated correctly From: Ed Schouten To: bug-followup@FreeBSD.org, rich@enterprisesystems.net Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 20:58:33 -0000 Hi there, [ +freebsd-hackers, to see whether this change would go in the right direction ] It seems that the regression described in misc/183495 is unrelated to utmpx alone. Unlike utmp, utmpx allows multiple entries per TTY. This causes the issue to become actually visible. telnetd uses login(1) to provide a login prompt, interactive shell, etc. Looking at the source code of login(1), it seems that it never attempts to call pam_cleanup() whenever the process terminates with SIGHUP, nor does it protect itself against SIGTERM properly. The following patch should fix this issue partially: http://80386.nl/pub/login-signal-fix.txt Still, one issue that remains is that the parent process can still be killed using SIGKILL, thereby allowing you to circumvent pam_cleanup(). What would be the right approach to fix this? Changing the effective UID would solve this, but I don't feel really comfortable to modify these kind of pieces of software. It's easy to introduce security bugs. Thoughts? -- Ed Schouten From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 13 23:36:12 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A8DD9132; Wed, 13 Nov 2013 23:36:12 +0000 (UTC) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 70AD22A76; Wed, 13 Nov 2013 23:36:12 +0000 (UTC) Received: from turtle.stack.nl (turtle.stack.nl [IPv6:2001:610:1108:5010::132]) by mx1.stack.nl (Postfix) with ESMTP id 713FD3592DD; Thu, 14 Nov 2013 00:36:09 +0100 (CET) Received: by turtle.stack.nl (Postfix, from userid 1677) id 63010CB4E; Thu, 14 Nov 2013 00:36:09 +0100 (CET) Date: Thu, 14 Nov 2013 00:36:09 +0100 From: Jilles Tjoelker To: Ed Schouten Subject: Re: misc/183495: utx.active not being updated correctly Message-ID: <20131113233608.GA8289@stack.nl> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org, rich@enterprisesystems.net, bug-followup@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 23:36:12 -0000 On Wed, Nov 13, 2013 at 09:58:32PM +0100, Ed Schouten wrote: > [ +freebsd-hackers, to see whether this change would go in the right direction ] > It seems that the regression described in misc/183495 is unrelated to > utmpx alone. Unlike utmp, utmpx allows multiple entries per TTY. This > causes the issue to become actually visible. In some sense, having at most one entry per TTY is correct. Multiple entries arise mostly by bugs that do not delete an entry on logout or by (ab)use of /usr/bin/login's setuid bit. Also, it is not possible to isolate two users properly if they are using the same TTY. > telnetd uses login(1) to provide a login prompt, interactive shell, > etc. Looking at the source code of login(1), it seems that it never > attempts to call pam_cleanup() whenever the process terminates with > SIGHUP, nor does it protect itself against SIGTERM properly. The > following patch should fix this issue partially: > http://80386.nl/pub/login-signal-fix.txt > Still, one issue that remains is that the parent process can still be > killed using SIGKILL, thereby allowing you to circumvent > pam_cleanup(). What would be the right approach to fix this? Changing > the effective UID would solve this, but I don't feel really > comfortable to modify these kind of pieces of software. It's easy to > introduce security bugs. At least on stable/9, the login [pam] process has all UIDs equal to 0 and cannot be killed by a normal user. However, it can receive SIGHUP if the connection is closed. This should not lead to immediate termination, so the SIGHUP part of the patch seems correct, although I have not tested it. I am less sure about the SIGTERM part. Killing a login [pam] process may be a "doctor it hurts if I do this" thing. If SIGTERM is not left at its default action, perhaps it should kill process(es) associated with the session somehow (most simply, by cleaning up PAM and audit and exiting, which shuts down the session). The only way to avoid problems with SIGKILL would be to put the PAM and audit cleanup in a constantly running daemon such as init. I don't think this is worth it. Root should not kill -9 login [pam] processes. -- Jilles Tjoelker From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 14 00:58:59 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7507E16F; Thu, 14 Nov 2013 00:58:59 +0000 (UTC) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 40B042F5E; Thu, 14 Nov 2013 00:58:59 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.16]) by ltcfislmsgpa06.fnfis.com (8.14.5/8.14.5) with ESMTP id rAE0wqLZ011027 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 13 Nov 2013 18:58:52 -0600 Received: from LTCFISWMSGMB21.FNFIS.com ([169.254.1.152]) by LTCFISWMSGHT05.FNFIS.com ([10.132.206.16]) with mapi id 14.03.0158.001; Wed, 13 Nov 2013 18:58:51 -0600 From: "Teske, Devin" To: Alfred Perlstein Subject: Re: Loader forth changes for customization Thread-Topic: Loader forth changes for customization Thread-Index: AQHO4EjnMi0GIoZQO0eCkJ5RnRP0Cw== Date: Thu, 14 Nov 2013 00:58:51 +0000 Message-ID: <86F0F59A-2DE0-42A3-9B8B-ADB1F3CA55A1@fisglobal.com> References: <5282E56F.4020307@freebsd.org> <52832003.8080406@freebsd.org> <09673101-DB54-4D25-9989-8C80D06E266B@fisglobal.com> <5283933E.30603@freebsd.org> <5283CBD1.9010606@freebsd.org> In-Reply-To: <5283CBD1.9010606@freebsd.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.120] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.14, 0.0.0000 definitions=2013-11-13_06:2013-11-13,2013-11-13,1970-01-01 signatures=0 Cc: FreeBSD Hackers , Devin Teske , "Teske, Devin" , Jordan Hubbard X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list Reply-To: Devin Teske List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 00:58:59 -0000 On Nov 13, 2013, at 10:58 AM, Alfred Perlstein wrote: >=20 > On 11/13/13, 10:01 AM, Jordan Hubbard wrote: >> On Nov 13, 2013, at 6:57 AM, Alfred Perlstein wrote: >>=20 >>> It seems to work although I will talk to the team about making separate= files for the set commands. >> Since we=92re talking about this, there is an old maxim amongst FORTH pr= ogrammers that if a single word=92s definition takes more than a page, it= =92s just too dang long. There are some solid reasons for that, namely th= e fact that forth is already hard enough to read as it is (and I=92m speaki= ng as a FAN of the language) and you generally need to keep the =93internal= stack state=94 in your head while writing a word since the stack contract = is only at word boundaries (e.g. word is defined as tacking stack parameter= s foo and returning stack parameters bar). Keeping the definitions short = and sweet really helps to aid in comprehension. >>=20 >> The definition for draw-beastie currently violates that maxim, and if yo= u guys were to refactor it as part of this work, I=92m sure future generati= ons would not object! :) > I'll give that a shot shortly. >=20 I've already tossed a few things at Alfred today that can help make things a lot simpler. Specifically, for draw-beastie... I came up with an idea that would whack off that big huge if-then block for the various logos. It would be much more efficient to just assume that the function (word) that draws the logo is actually named the same as the desired setting but with a "-logo" suffix. But I went out of the box today on something new... Yes, Forth is a stack based language. But... It can also take its arguments from something known as the "Text Input Buffer" (or TIB for short). In essence, I whipped up this little diddy for Alfred's work... : try-include ['] include catch if 0 parse 2drop then ; immediate This new word is a lot like the "include" word (and a number of other words) in that it takes no stack arguments. Instead, it takes arguments from the input stream. Example... try-include /boot/loader.rc.local try-include /boot/menu.rc.local I designed the "try-include" function to work this way so that it would be more intuitive and would be more "at-home" inside an *.rc file where all the words (like "set" and "include" etc.) are "clean" (more easily understood by non-Forth programmers). Also, regarding the ol' maxim... Don't you find that use of "( before -- after )" inline comments are helpful in reducing the load on mentally having to tabulate the stack contents for larger words? I've tried to use that style in my coding whenever words appear to be getting unwieldy, and would like to know if perhaps it's not that great in dealing with the maxim of keeping things short. --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 14 07:54:56 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E3C2ED57; Thu, 14 Nov 2013 07:54:56 +0000 (UTC) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AA0A42473; Thu, 14 Nov 2013 07:54:56 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.17]) by ltcfislmsgpa04.fnfis.com (8.14.5/8.14.5) with ESMTP id rAE7st2I013177 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 14 Nov 2013 01:54:55 -0600 Received: from LTCFISWMSGMB21.FNFIS.com ([169.254.1.152]) by LTCFISWMSGHT06.FNFIS.com ([10.132.206.17]) with mapi id 14.03.0158.001; Thu, 14 Nov 2013 01:54:54 -0600 From: "Teske, Devin" To: Alfred Perlstein Subject: Re: Loader forth changes for customization Thread-Topic: Loader forth changes for customization Thread-Index: AQHO4EjnMi0GIoZQO0eCkJ5RnRP0Cw== Date: Thu, 14 Nov 2013 07:54:54 +0000 Message-ID: References: <5282E56F.4020307@freebsd.org> <52832003.8080406@freebsd.org> <09673101-DB54-4D25-9989-8C80D06E266B@fisglobal.com> <5283933E.30603@freebsd.org> In-Reply-To: <5283933E.30603@freebsd.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.120] Content-Type: multipart/mixed; boundary="_002_BCC78B2C66F042C3AD53018637B2C433fisglobalcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.14, 0.0.0000 definitions=2013-11-13_06:2013-11-13,2013-11-13,1970-01-01 signatures=0 Cc: FreeBSD Hackers , Devin Teske , "Teske, Devin" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list Reply-To: Devin Teske List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 07:54:57 -0000 --_002_BCC78B2C66F042C3AD53018637B2C433fisglobalcom_ Content-ID: <0FDD9F0F0DEAAA4BBFDFBC6EF71C7C67@fisglobal.com> Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" On Nov 13, 2013, at 6:57 AM, Alfred Perlstein wrote: >=20 > On 11/13/13, 12:18 AM, Teske, Devin wrote: >> On Nov 12, 2013, at 10:45 PM, Alfred Perlstein wrote: >>=20 >>> I added some hooks for menu.rc as well, you can see it via the github u= rls below. >>>=20 >>> I've attached a sample menu.rc.local that provides additional menus. >>>=20 >>> -Alfred >>>=20 >>> On 11/12/13, 6:35 PM, Alfred Perlstein wrote: >>>> Hey folks, >>>>=20 >>>> I added some forth using Devin's help to make it easier to customize t= he FreeBSD boot loader graphics. >>>>=20 >>>> Diffs are here: >>>> https://github.com/alfredperlstein/freebsd/compare/loader_custom_rc >>>> -or- >>>> https://github.com/alfredperlstein/freebsd/compare/loader_custom_rc.di= ff >>>>=20 >>>>=20 >>>> Diff attached. >>>>=20 >>>> Also attached is a custom loader.rc file and loader.conf file that sho= ws how to set the brand/logo. >>>>=20 >>>> Please review. >>>>=20 >> I signed up for a github account (thanks), and I started commenting on s= ome lines. > yay! :) >>=20 >>>> -Alfred >>> >> Hmmm, I hadn't realized that you could say: >>=20 >> set foo=3Dbar >>=20 >> Along-side setting functions in the same file. >>=20 >> I don't think you can set functions in an *.rc file, only in a *.4th fil= e? >>=20 >> No? Maybe it's a false misconception of mine. I've been keeping them >> separate for years. (but probably rightfully so, to keep *.rc files clea= n). >=20 > It seems to work although I will talk to the team about making separate f= iles for the set commands. >=20 > I've responded to your review comments here: >=20 > https://github.com/alfredperlstein/freebsd/commit/0ca72dccd78b880b3e3ef4c= 2bb9ce025950a370b#commitcomment-4584862 >=20 > The changes I made are now in the branch > https://github.com/alfredperlstein/freebsd/tree/loader_custom_rc and you = likely should see them in the updated pull request I sent you. >=20 I improved on a few things... https://github.com/devinteske/freebsd/compare/freebsd:master...master -or- https://github.com/devinteske/freebsd/compare/freebsd:master...master.diff -or- Attached SVN patch.txt --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. --_002_BCC78B2C66F042C3AD53018637B2C433fisglobalcom_ Content-Type: text/plain; name="patch.txt" Content-Description: patch.txt Content-Disposition: attachment; filename="patch.txt"; size=3113; creation-date="Thu, 14 Nov 2013 07:54:54 GMT"; modification-date="Thu, 14 Nov 2013 07:54:54 GMT" Content-ID: <8FE81C1A7BC5C341B2E678BB7E03A797@fisglobal.com> Content-Transfer-Encoding: base64 SW5kZXg6IHN5cy9ib290L2ZvcnRoL2xvYWRlci40dGgNCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCi0tLSBzeXMvYm9v dC9mb3J0aC9sb2FkZXIuNHRoCShyZXZpc2lvbiAyNTc4MjEpDQorKysgc3lzL2Jvb3QvZm9ydGgv bG9hZGVyLjR0aAkod29ya2luZyBjb3B5KQ0KQEAgLTIzMyw3ICsyMzMsMTYgQEAgaW5jbHVkZSAv Ym9vdC9jaGVjay1wYXNzd29yZC40dGgNCiAgIHMiIGRpc2FibGUtbW9kdWxlIiBzIiBkaXNhYmxl IGxvYWRpbmcgb2YgYSBtb2R1bGUiIC4/DQogICBzIiB0b2dnbGUtbW9kdWxlIiBzIiB0b2dnbGUg bG9hZGluZyBvZiBhIG1vZHVsZSIgLj8NCiAgIHMiIHNob3ctbW9kdWxlIiBzIiBzaG93IG1vZHVs ZSBsb2FkIGRhdGEiIC4/DQorICBzIiB0cnktaW5jbHVkZSIgcyIgdHJ5IHRvIGxvYWQvaW50ZXJw cmV0IGZpbGVzIiAuPw0KIDsNCiANCis6IHRyeS1pbmNsdWRlICggLS0gKSBcIHNlZSBsb2FkZXIu NHRoKDgpDQorICBbJ10gaW5jbHVkZSAoIC0tIHh0ICkgXCBnZXQgdGhlIGV4ZWN1dGlvbiB0b2tl biBvZiBgaW5jbHVkZScNCisgIGNhdGNoICggeHQgLS0gZXhjZXB0aW9uIyB8IDAgKSBpZiBcIGZh aWxlZA0KKyAgICBMRiBwYXJzZSAoIGMgLS0gcy1hZGRyL3UgKSAyZHJvcCBcIGFkdmFuY2UgPmlu IHRvIEVPTCAoZHJvcCBkYXRhKQ0KKyAgICBcIC4uLiBwcmV2ZW50cyB3b3JkcyB1bnVzZWQgYnkg YGluY2x1ZGUnIGZyb20gYmVpbmcgaW50ZXJwcmV0ZWQNCisgIHRoZW4NCis7IGltbWVkaWF0ZSBc IGludGVycHJldCBpbW1lZGlhdGVseSBmb3IgYWNjZXNzIHRvIGBzb3VyY2UnIChha2EgdGliKQ0K Kw0KIG9ubHkgZm9ydGggYWxzbw0KIA0KSW5kZXg6IHN5cy9ib290L2ZvcnRoL2xvYWRlci40dGgu OA0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PQ0KLS0tIHN5cy9ib290L2ZvcnRoL2xvYWRlci40dGguOAkocmV2aXNpb24g MjU3ODIwKQ0KKysrIHN5cy9ib290L2ZvcnRoL2xvYWRlci40dGguOAkod29ya2luZyBjb3B5KQ0K QEAgLTI0LDcgKzI0LDcgQEANCiAuXCINCiAuXCIgJEZyZWVCU0QkDQogLlwiDQotLkRkIE9jdG9i ZXIgMTcsIDIwMTMNCisuRGQgTm92ZW1iZXIgMTMsIDIwMTMNCiAuRHQgTE9BREVSLjRUSCA4DQog Lk9zDQogLlNoIE5BTUUNCkBAIC0xNTgsNiArMTU4LDEzIEBAIGZpbGVzIHRvIHNwZWNpZnkgdGhl IGFjdGlvbiBhZnRlciBhIG1vZHVsZSBsb2FkaW5nDQogVXNlZCBpbnNpZGUNCiAuWHIgbG9hZGVy LmNvbmYgNQ0KIGZpbGVzIHRvIHNwZWNpZnkgdGhlIGFjdGlvbiBhZnRlciBhIG1vZHVsZSBsb2Fk aW5nIGZhaWxzLg0KKy5JdCBJYyB0cnktaW5jbHVkZSBBciBmaWxlIE9wIEFyDQorUHJvY2VzcyBz Y3JpcHQgZmlsZXMgaWYgdGhleSBleGlzdC4NCitFYWNoIGZpbGUsIGluIHR1cm4sIGlzIGNvbXBs ZXRlbHkgcmVhZCBpbnRvIG1lbW9yeSwNCithbmQgdGhlbiBlYWNoIG9mIGl0cyBsaW5lcyBpcyBw YXNzZWQgdG8gdGhlIGNvbW1hbmQgbGluZSBpbnRlcnByZXRlci4NCitJZiBhbnkgZXJyb3IgaXMg cmV0dXJuZWQgYnkgdGhlIGludGVycHJldGVyLCB0aGUgdHJ5LWluY2x1ZGUNCitjb21tYW5kIGFi b3J0cyBpbW1lZGlhdGVseSwgd2l0aG91dCByZWFkaW5nIGFueSBvdGhlciBmaWxlcywgYW5kDQor c2lsZW50bHkgcmV0dXJucyB3aXRob3V0IGVycm9yLg0KIC5FbA0KIC5TaCBGSUxFUw0KIC5CbCAt dGFnIC13aWR0aCAvYm9vdC9sb2FkZXIuNHRoIC1jb21wYWN0DQpJbmRleDogc3lzL2Jvb3QvZm9y dGgvbG9hZGVyLnJjDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09DQotLS0gc3lzL2Jvb3QvZm9ydGgvbG9hZGVyLnJjCShy ZXZpc2lvbiAyNTc4MjApDQorKysgc3lzL2Jvb3QvZm9ydGgvbG9hZGVyLnJjCSh3b3JraW5nIGNv cHkpDQpAQCAtMyw2ICszLDcgQEANCiBcDQogXCBJbmNsdWRlcyBhZGRpdGlvbmFsIGNvbW1hbmRz DQogaW5jbHVkZSAvYm9vdC9sb2FkZXIuNHRoDQordHJ5LWluY2x1ZGUgL2Jvb3QvbG9hZGVyLnJj LmxvY2FsDQogDQogXCBSZWFkcyBhbmQgcHJvY2Vzc2VzIGxvYWRlci5jb25mIHZhcmlhYmxlcw0K IFwgTk9URTogQ2hhbmdlIHRvIGBpbml0aWFsaXplJyBpZiB5b3UgZW5hYmxlIHRoZSBiZWxvdyBi b290IG1lbnUNCkluZGV4OiBzeXMvYm9vdC9mb3J0aC9tZW51LnJjDQo9PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQotLS0g c3lzL2Jvb3QvZm9ydGgvbWVudS5yYwkocmV2aXNpb24gMjU3ODIwKQ0KKysrIHN5cy9ib290L2Zv cnRoL21lbnUucmMJKHdvcmtpbmcgY29weSkNCkBAIC0xMjAsNiArMTIwLDEwIEBAIHNldCBvcHRp b25zdG9nZ2xlZF9hbnNpWzZdPSIbWzFtVhtbMzdtZXJib3NlLi4uLi4NCiBcIA0KIHNldCBtZW51 X3RpbWVvdXRfY29tbWFuZD0iYm9vdCINCiANCitcIEluY2x1ZGUgb3B0aW9uYWwgZWxlbWVudHMg ZGVmaW5lZCBpbiBhIGxvY2FsIGZpbGUNCitcIA0KK3RyeS1pbmNsdWRlIC9ib290L21lbnUucmMu bG9jYWwNCisNCiBcIERpc3BsYXkgdGhlIG1haW4gbWVudSAoc2VlIGBtZW51LjR0aCcpDQogc2V0 IG1lbnVzZXRfaW5pdGlhbD0xDQogbWVudXNldC1sb2FkaW5pdGlhbA0KSW5kZXg6IHN5cy9ib290 L2kzODYvbG9hZGVyL2xvYWRlci5yYw0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KLS0tIHN5cy9ib290L2kzODYvbG9h ZGVyL2xvYWRlci5yYwkocmV2aXNpb24gMjU3NjUwKQ0KKysrIHN5cy9ib290L2kzODYvbG9hZGVy L2xvYWRlci5yYwkod29ya2luZyBjb3B5KQ0KQEAgLTMsNiArMyw3IEBADQogXA0KIFwgSW5jbHVk ZXMgYWRkaXRpb25hbCBjb21tYW5kcw0KIGluY2x1ZGUgL2Jvb3QvbG9hZGVyLjR0aA0KK3RyeS1p bmNsdWRlIC9ib290L2xvYWRlci5yYy5sb2NhbA0KIA0KIFwgUmVhZHMgYW5kIHByb2Nlc3NlcyBs b2FkZXIuY29uZiB2YXJpYWJsZXMNCiBpbml0aWFsaXplDQo= --_002_BCC78B2C66F042C3AD53018637B2C433fisglobalcom_-- From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 14 08:06:11 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2BA0CF2E; Thu, 14 Nov 2013 08:06:11 +0000 (UTC) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 975C824FE; Thu, 14 Nov 2013 08:06:10 +0000 (UTC) Received: by mail-we0-f182.google.com with SMTP id x55so1489764wes.41 for ; Thu, 14 Nov 2013 00:06:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:subject:date:content-type :content-transfer-encoding:in-reply-to:references; bh=GtONdrESdFSBnrX/hq4ofEZyfLA3n5lJ3mr5le23MJQ=; b=X5FOvW5ep5fgoap2UqCOOupW8ZfdTtF0nkqpkm2aHHPgOYqF+QpUWdHWHHYgS1zQt9 Z5SyjzWLHoBFG221OYOM/a+Jo2I2T7Bn9fAv/TKPcrv9Y/mTePBQTvqr+vMexjuQ7Wxm iEZa3uBluuHs3ytWOQOBYODPFM6Tr5z3toQXOXgomfuCEjnNcKGBunKEYgaeX1mqK0DR clXb+FopUwINQqKlmj/qmeXoxqQTHc4eZVMospiJvEWy5qol35ylQOQM+BIopjoLk9vR yvSnvEeEiI5aTYJXDPPaPrwJ+ck/JAjDHFniESGPbS2MUUW57Nhm2sfk8TedrEKxeh3L prQA== X-Received: by 10.194.237.99 with SMTP id vb3mr216694wjc.28.1384416368744; Thu, 14 Nov 2013 00:06:08 -0800 (PST) Received: from DOMYPC ([82.193.208.225]) by mx.google.com with ESMTPSA id dn2sm63017049wid.1.2013.11.14.00.06.07 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 14 Nov 2013 00:06:07 -0800 (PST) Message-ID: <20131114.080608.007.1@DOMY-PC> From: rank1seeker@gmail.com To: "Devin Teske" Subject: Re: Loader forth changes for customization Date: Thu, 14 Nov 2013 09:06:08 +0100 Content-Type: text/plain; charset="Windows-1250" Content-Transfer-Encoding: quoted-printable In-Reply-To: <86F0F59A-2DE0-42A3-9B8B-ADB1F3CA55A1@fisglobal.com> References: <5282E56F.4020307@freebsd.org> <52832003.8080406@freebsd.org> <09673101-DB54-4D25-9989-8C80D06E266B@fisglobal.com> <5283933E.30603@freebsd.org> <5283CBD1.9010606@freebsd.org> <86F0F59A-2DE0-42A3-9B8B-ADB1F3CA55A1@fisglobal.com> X-Mailer: POP Peeper (3.8.1.0) Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 08:06:11 -0000 Um,=0D=0A=0D=0ALittle of thread, but could you rewrite loader in just 1 = task?=0D=0AThat is, once it has been pulled by STAGE 2 boot, ALL loader's = path should be RELATIVE to loader itself, instead currently using full = path approach (/boot/...)=0D=0A=0D=0AI.e;=0D=0ALine: (from: = '/sys/boot/common/interp.c')=0D=0A = include("/boot/boot.conf");=0D=0Ainto:=0D=0A = include("boot.conf");=0D=0Aand so on = ...=0D=0A=0D=0AThanks.=0D=0A=0D=0A=0D=0ADomagoj Smol=E8i=E6 From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 14 08:17:12 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0AD8637A; Thu, 14 Nov 2013 08:17:12 +0000 (UTC) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CB308258C; Thu, 14 Nov 2013 08:17:11 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.15]) by ltcfislmsgpa02.fnfis.com (8.14.5/8.14.5) with ESMTP id rAE8HAlX004730 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 14 Nov 2013 02:17:10 -0600 Received: from LTCFISWMSGMB21.FNFIS.com ([169.254.1.152]) by LTCFISWMSGHT04.FNFIS.com ([10.132.206.15]) with mapi id 14.03.0158.001; Thu, 14 Nov 2013 02:17:09 -0600 From: "Teske, Devin" To: "" Subject: Re: Loader forth changes for customization Thread-Topic: Loader forth changes for customization Thread-Index: AQHO4EjnMi0GIoZQO0eCkJ5RnRP0Cw== Date: Thu, 14 Nov 2013 08:17:08 +0000 Message-ID: <18E6668A-3837-40D1-BCA0-9D68DCCD70AD@fisglobal.com> References: <5282E56F.4020307@freebsd.org> <52832003.8080406@freebsd.org> <09673101-DB54-4D25-9989-8C80D06E266B@fisglobal.com> <5283933E.30603@freebsd.org> <5283CBD1.9010606@freebsd.org> <86F0F59A-2DE0-42A3-9B8B-ADB1F3CA55A1@fisglobal.com> <20131114.080608.007.1@DOMY-PC> In-Reply-To: <20131114.080608.007.1@DOMY-PC> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.120] Content-Type: text/plain; charset="windows-1250" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.14, 0.0.0000 definitions=2013-11-13_06:2013-11-13,2013-11-13,1970-01-01 signatures=0 Cc: FreeBSD Hackers , Devin Teske , "Teske, Devin" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list Reply-To: Devin Teske List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 08:17:12 -0000 On Nov 14, 2013, at 12:06 AM, wrote: > Um, >=20 > Little of thread, but could you rewrite loader in just 1 task? > That is, once it has been pulled by STAGE 2 boot, ALL loader's path shoul= d be RELATIVE to loader itself, instead currently using full path approach = (/boot/...) >=20 > I.e; > Line: (from: '/sys/boot/common/interp.c') > include("/boot/boot.conf"); > into: > include("boot.conf"); > and so on ... >=20 > Thanks. >=20 Is that true for the Forth layer? I didn't think there was a relative path. Just tested on 9.2-R loader(8): Contents of /boot/loader.rc.local: echo "Hello, World!" At loader(8) prompt: OK include /boot/loader.rc.local Hello, World! OK include loader.rc.local can't open 'loader.rc.local': no such file or directory --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 14 08:36:53 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4CF307CF; Thu, 14 Nov 2013 08:36:53 +0000 (UTC) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BA9AD26C0; Thu, 14 Nov 2013 08:36:52 +0000 (UTC) Received: by mail-wg0-f41.google.com with SMTP id n12so361458wgh.2 for ; Thu, 14 Nov 2013 00:36:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:subject:date:in-reply-to:references; bh=fmHLLDgtLA7577Q4hkoOzuCvpLrJavH49tSGGDW6qHU=; b=RG2peVvO+mTmfBD02AKBM6DgHaqsuPNu0Q+qMr58IXKrLm9bTcxLypwhmuMNX7g18r s3O2aPSCG4TxZRWHFJVvcEWv0a0qMLQF5/zzpcdyK6Rjc/cnshGIgi6LUemH/BURkQV/ lmHU1/pK4o5eZsFWa1BQfq+XCcgLuVBn888W05Krwu4y6p2dyUOWF0mQr5VrqCmNKCgt +YMZoqLd4BpL9xdOKlA6KnCoR7P4uJ2zzf4nSu/NpOxug8VYFJ+WsmTf3Ej8i6DmNv0M O2R3Yl27lmNURvGPDSvIJhTHSjDoxtvPwAokmik1PW4xyFpplyozHmUQUuifL6EcACif Fe1A== X-Received: by 10.180.187.41 with SMTP id fp9mr1158237wic.33.1384418211267; Thu, 14 Nov 2013 00:36:51 -0800 (PST) Received: from DOMYPC ([82.193.208.225]) by mx.google.com with ESMTPSA id uc12sm11371561wib.3.2013.11.14.00.36.49 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 14 Nov 2013 00:36:50 -0800 (PST) Message-ID: <20131114.083650.674.2@DOMY-PC> From: rank1seeker@gmail.com To: "Devin Teske" Subject: Re: Loader forth changes for customization Date: Thu, 14 Nov 2013 09:36:50 +0100 In-Reply-To: <18E6668A-3837-40D1-BCA0-9D68DCCD70AD@fisglobal.com> References: <5282E56F.4020307@freebsd.org> <52832003.8080406@freebsd.org> <09673101-DB54-4D25-9989-8C80D06E266B@fisglobal.com> <5283933E.30603@freebsd.org> <5283CBD1.9010606@freebsd.org> <86F0F59A-2DE0-42A3-9B8B-ADB1F3CA55A1@fisglobal.com> <20131114.080608.007.1@DOMY-PC> <18E6668A-3837-40D1-BCA0-9D68DCCD70AD@fisglobal.com> X-Mailer: POP Peeper (3.8.1.0) Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 08:36:53 -0000 > > Um, > > > > Little of thread, but could you rewrite loader in just 1 task? > > That is, once it has been pulled by STAGE 2 boot, ALL loader's path should be RELATIVE to loader itself, instead currently using full path approach (/boot/...) > > > > I.e; > > Line: (from: '/sys/boot/common/interp.c') > > include("/boot/boot.conf"); > > into: > > include("boot.conf"); > > and so on ... > > > > Thanks. > > > > Is that true for the Forth layer? I didn't think there was a relative path. > Just tested on 9.2-R loader(8): > > Contents of /boot/loader.rc.local: > echo "Hello, World!" > > At loader(8) prompt: > OK include /boot/loader.rc.local > Hello, World! > OK include loader.rc.local > can't open 'loader.rc.local': no such file or directory > > -- > Devin No no. Loader's prompt, where you type CMD's ... is out of context. Normal loader's boot sequence should work with paths relative to loader binary itself. I.e; Upon boot it would pull 'defaults/loader.conf' as it is relative to it, instead via current full path '/boot/defaults/loader.conf' This isn't a current behaviour, but something that should be done. Domagoj From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 14 11:34:09 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 836F18BF; Thu, 14 Nov 2013 11:34:09 +0000 (UTC) Received: from mail-ve0-x236.google.com (mail-ve0-x236.google.com [IPv6:2607:f8b0:400c:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3391A2280; Thu, 14 Nov 2013 11:34:09 +0000 (UTC) Received: by mail-ve0-f182.google.com with SMTP id pa12so1722011veb.13 for ; Thu, 14 Nov 2013 03:34:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=CzthCXx/jdIOgJ1rpigDrsfnHfUfIXqjybQBZOMF+uo=; b=XYUIxg8EAc20+rPPXNV0PGo8K9GldHK7JZ/rr+mvtaH3a7NtnDtXHbI25kqw6HtWRT DyAFcXLSGBG5JnFPD0XXFDC0rU/WUyTF5zJCJDBCFZUvnqBFZinVRrSxIMrH6FbZrk4G rjeIZPinHt7iGePauU+7VZghR54aoFSpg7lLYsxue6csUOtSnplxm8z9NBk+0XqLHon6 poRZ4ttB/m8Lf7cQxBx/gxdaAPk5tFQ8AFBC9T0IA61sxD/CwlDxup+7+nTrFOUPA7MP XnWjAQrpLsQI9L5Qsw3GnFP0lnY6Po7pv+Tm8T2R9w8ZhqXas9fPrDk8k6yQxj4WE63F vVzw== MIME-Version: 1.0 X-Received: by 10.52.177.166 with SMTP id cr6mr339685vdc.26.1384428848367; Thu, 14 Nov 2013 03:34:08 -0800 (PST) Received: by 10.220.1.17 with HTTP; Thu, 14 Nov 2013 03:34:08 -0800 (PST) In-Reply-To: References: Date: Thu, 14 Nov 2013 12:34:08 +0100 Message-ID: Subject: Re: Automated submission of kernel panic reports: sysutils/panicmail From: Carlos Jacobo Puga Medina To: freebsd-hackers@freebsd.org, cperciva@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.16 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 11:34:09 -0000 Well, I realized that savecore(8) doesn't work as it should. It's clear that after apply the patch, it changes adequately the order of scripts as follow: % rcorder /etc/rc.d/* | less /etc/rc.d/sysctl /etc/rc.d/hostid /etc/rc.d/zvol /etc/rc.d/dumpon /etc/rc.d/ddb /etc/rc.d/initrandom /etc/rc.d/geli /etc/rc.d/gbde /etc/rc.d/ccd /etc/rc.d/savecore /etc/rc.d/encswap /etc/rc.d/swap1 % swapinfo Device 1K-blocks Used Avail Capacity /dev/ada0p3.eli 3907584 0 3907584 0% Also, /dev/dumpdev is pointing to /dev/ada0p3 % ll /dev/dumpdev lrwxr-xr-x 1 root wheel 11 13 nov 23:51 /dev/dumpdev@ -> /dev/ada0p3 I created a crash dump using "reboot -d" but I see these messages related to savecore at boot stage: savecore: reboot savecore: unable to write to bounds file: Read-only file system savecore: info.0: Read-only file system savecore: unsaved dumps found but not saved No crash dumps in /var/crash. Any suggestions? --CJPM 2013/11/7 Carlos Jacobo Puga Medina > At last, I realized how to solved this inconvenient. Digging a bit I found > what I needed. All is summarized in the pr124747 which describes perfectly > this problem and attached a patch to fix it. > > I add the modified patch according to current rc.d scripts included. > > diff -ur encswap.orig encswap > --- encswap.orig 2013-11-06 23:31:43.000000000 +0100 > +++ encswap 2013-11-07 00:14:03.000000000 +0100 > @@ -3,8 +3,8 @@ > # $FreeBSD: release/9.2.0/etc/rc.d/encswap 180563 2008-07-16 19:22:48Z > dougb $ > # > > -# PROVIDE: disks > -# REQUIRE: initrandom > +# PROVIDE: encswap > +# REQUIRE: initrandom disks > # KEYWORD: nojail > > . /etc/rc.subr > diff -ur savecore.orig savecore > --- savecore.orig 2013-11-06 23:32:21.000000000 +0100 > +++ savecore 2013-11-07 00:14:18.000000000 +0100 > @@ -4,7 +4,7 @@ > # > > # PROVIDE: savecore > -# REQUIRE: dumpon ddb syslogd > +# BEFORE: encswap > # KEYWORD: nojail > > . /etc/rc.subr > diff -ur swap1.orig swap1 > --- swap1.orig 2013-11-06 23:32:28.000000000 +0100 > +++ swap1 2013-11-07 00:14:29.000000000 +0100 > @@ -4,7 +4,7 @@ > # > > # PROVIDE: localswap > -# REQUIRE: disks > +# REQUIRE: encswap disks > # KEYWORD: nojail shutdown > > . /etc/rc.subr > > I tested it and now it works like a charm. > > > 2013/11/5 Carlos Jacobo Puga Medina > >> Add missing thread related to Pawel's proposal [1] >> >> [1] >> http://lists.freebsd.org/pipermail/freebsd-fs/2010-September/009256.html >> >> >> 2013/11/5 Carlos Jacobo Puga Medina >> >>> Seems that rc.d scripts order doesn't allow geli-encrypted swap and >>> dumpdev to cooperate together. For this reason, I wonder what happens in >>> such cases, is not possible to use panicmail unless Pawel's proposal [1] >>> which argued to obtain and save crash info in memory somewhere before we >>> configure swap and copy it to /var/crash/ once we mount it. >>> >>> Is sustainable this proposal or is there yet another alternative to >>> consider for those who use an encrypted GELI swap? >>> >>> --CJPM >>> >> >> > From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 14 16:08:57 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B80D61A2; Thu, 14 Nov 2013 16:08:57 +0000 (UTC) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 104D82725; Thu, 14 Nov 2013 16:08:56 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.31]) by ltcfislmsgpa06.fnfis.com (8.14.5/8.14.5) with ESMTP id rAEG8tnK021553 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 14 Nov 2013 10:08:55 -0600 Received: from LTCFISWMSGMB21.FNFIS.com ([169.254.1.152]) by LTCFISWMSGHT03.FNFIS.com ([10.132.206.31]) with mapi id 14.03.0158.001; Thu, 14 Nov 2013 10:08:53 -0600 From: "Teske, Devin" To: "" Subject: Re: Loader forth changes for customization Thread-Topic: Loader forth changes for customization Thread-Index: AQHO4EjnMi0GIoZQO0eCkJ5RnRP0Cw== Date: Thu, 14 Nov 2013 16:08:53 +0000 Message-ID: <9DEB3851-653A-46EF-ACE2-03EF1978831F@fisglobal.com> References: <5282E56F.4020307@freebsd.org> <52832003.8080406@freebsd.org> <09673101-DB54-4D25-9989-8C80D06E266B@fisglobal.com> <5283933E.30603@freebsd.org> <5283CBD1.9010606@freebsd.org> <86F0F59A-2DE0-42A3-9B8B-ADB1F3CA55A1@fisglobal.com> <20131114.080608.007.1@DOMY-PC> <18E6668A-3837-40D1-BCA0-9D68DCCD70AD@fisglobal.com> <20131114.083650.674.2@DOMY-PC> In-Reply-To: <20131114.083650.674.2@DOMY-PC> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.120] Content-Type: text/plain; charset="us-ascii" Content-ID: <2D9D67D612A0DD44A4D64163A068A142@fisglobal.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.14, 0.0.0000 definitions=2013-11-14_03:2013-11-13,2013-11-14,1970-01-01 signatures=0 Cc: FreeBSD Hackers , Devin Teske , "Teske, Devin" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list Reply-To: Devin Teske List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 16:08:57 -0000 On Nov 14, 2013, at 12:36 AM, wrote: >>> Um, >>>=20 >>> Little of thread, but could you rewrite loader in just 1 task? >>> That is, once it has been pulled by STAGE 2 boot, ALL loader's path=20 > should be RELATIVE to loader itself, instead currently using full path=20 > approach (/boot/...) >>>=20 >>> I.e; >>> Line: (from: '/sys/boot/common/interp.c') >>> include("/boot/boot.conf"); >>> into: >>> include("boot.conf"); >>> and so on ... >>>=20 >>> Thanks. >>>=20 >>=20 >> Is that true for the Forth layer? I didn't think there was a relative=20 > path. >> Just tested on 9.2-R loader(8): >>=20 >> Contents of /boot/loader.rc.local: >> echo "Hello, World!" >>=20 >> At loader(8) prompt: >> OK include /boot/loader.rc.local >> Hello, World! >> OK include loader.rc.local >> can't open 'loader.rc.local': no such file or directory >>=20 >> --=20 >> Devin >=20 >=20 > No no. Loader's prompt, where you type CMD's ... is out of context. > Normal loader's boot sequence should work with paths relative to loader=20 > binary itself. > I.e; Upon boot it would pull 'defaults/loader.conf' as it is relative to= =20 > it, instead via current full path '/boot/defaults/loader.conf' >=20 So I tried... changing a path in /boot/loader.rc E.g., in my patchset, I changed... try-include /boot/loader.rc.local To instead: try-incude loader.rc.local The result is that the file is no longer included. > This isn't a current behaviour, but something that should be done. >=20 I'm finding that currently all paths in the Forth layer must be absolute paths. I just don't see how relative paths could work in Forth. There's no "cd" command, to start with (what would dictate the current working directory?? -- but more importantly, would "include" actually adhere to it?) --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 14 16:21:07 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8D6F3862; Thu, 14 Nov 2013 16:21:07 +0000 (UTC) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 52BAE2853; Thu, 14 Nov 2013 16:21:07 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.15]) by ltcfislmsgpa03.fnfis.com (8.14.5/8.14.5) with ESMTP id rAEGL6k0018358 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 14 Nov 2013 10:21:06 -0600 Received: from LTCFISWMSGMB21.FNFIS.com ([169.254.1.152]) by LTCFISWMSGHT04.FNFIS.com ([10.132.206.15]) with mapi id 14.03.0158.001; Thu, 14 Nov 2013 10:21:04 -0600 From: "Teske, Devin" To: Jordan Hubbard Subject: Re: Loader forth changes for customization Thread-Topic: Loader forth changes for customization Thread-Index: AQHO4EjnMi0GIoZQO0eCkJ5RnRP0C5olTwmA Date: Thu, 14 Nov 2013 16:21:04 +0000 Message-ID: <7DD09B24-F4D7-4ED4-83E2-E9D72C157020@fisglobal.com> References: <5282E56F.4020307@freebsd.org> <52832003.8080406@freebsd.org> <09673101-DB54-4D25-9989-8C80D06E266B@fisglobal.com> <5283933E.30603@freebsd.org> <5283CBD1.9010606@freebsd.org> <86F0F59A-2DE0-42A3-9B8B-ADB1F3CA55A1@fisglobal.com> In-Reply-To: <86F0F59A-2DE0-42A3-9B8B-ADB1F3CA55A1@fisglobal.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.120] Content-Type: multipart/mixed; boundary="_002_7DD09B24F4D74ED483E2E9D72C157020fisglobalcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.14, 0.0.0000 definitions=2013-11-14_03:2013-11-13,2013-11-14,1970-01-01 signatures=0 Cc: Devin Teske , FreeBSD Hackers , Alfred Perlstein , "Teske, Devin" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list Reply-To: Devin Teske List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 16:21:07 -0000 --_002_7DD09B24F4D74ED483E2E9D72C157020fisglobalcom_ Content-ID: Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="Windows-1252" On Nov 13, 2013, at 4:58 PM, Teske, Devin wrote: >=20 > On Nov 13, 2013, at 10:58 AM, Alfred Perlstein wrote: >>=20 >> On 11/13/13, 10:01 AM, Jordan Hubbard wrote: >>>=20 >>> On Nov 13, 2013, at 6:57 AM, Alfred Perlstein wrot= e: >>>=20 >>>> It seems to work although I will talk to the team about making separat= e files for the set commands. >>>=20 >>> Since we=92re talking about this, there is an old maxim amongst FORTH p= rogrammers that if a single word=92s=20 >>> definition takes more than a page, it=92s just too dang long. There a= re some solid reasons for that, namely the fact that forth is already hard = enough to read as it is (and I=92m speaking as a FAN of the language) and y= ou generally need to keep the =93internal stack state=94 in your head while= writing a word since the stack contract is only at word boundaries (e.g. w= ord is defined as tacking stack parameters foo and returning stack paramete= rs bar). Keeping the definitions short and sweet really helps to aid in c= omprehension. >>>=20 >>> The definition for draw-beastie currently violates that maxim, and if y= ou guys were to refactor it as part of this work, I=92m sure future generat= ions would not object! :) >>=20 >> I'll give that a shot shortly. >>=20 >=20 Here's a patch to address that specifically... https://github.com/devinteske/freebsd/commit/c07adb2a17140d52a996ea6b8ddd94= 9b3c08be1b -or- https://github.com/devinteske/freebsd/commit/c07adb2a17140d52a996ea6b8ddd94= 9b3c08be1b.diff -or- See attached SVN patch.txt --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. --_002_7DD09B24F4D74ED483E2E9D72C157020fisglobalcom_ Content-Type: text/plain; name="patch.txt" Content-Description: patch.txt Content-Disposition: attachment; filename="patch.txt"; size=1841; creation-date="Thu, 14 Nov 2013 16:21:04 GMT"; modification-date="Thu, 14 Nov 2013 16:21:04 GMT" Content-ID: <76936954384AA24B9D4CAE8E7FCDB0EA@fisglobal.com> Content-Transfer-Encoding: base64 SW5kZXg6IHN5cy9ib290L2ZvcnRoL2JlYXN0aWUuNHRoDQo9PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQotLS0gc3lzL2Jv b3QvZm9ydGgvYmVhc3RpZS40dGgJKHJldmlzaW9uIDI1NzgyMSkNCisrKyBzeXMvYm9vdC9mb3J0 aC9iZWFzdGllLjR0aAkod29ya2luZyBjb3B5KQ0KQEAgLTIwMiw1NiArMjAyLDI2IEBAIHZhcmlh YmxlIGxvZ29ZDQogCQlkcm9wDQogCXRoZW4NCiANCi0JcyIgbG9hZGVyX2xvZ28iIGdldGVudiBk dXAgLTEgPSBpZg0KLQkJbG9nb1ggQCBsb2dvWSBADQorCXMiIGxvYWRlcl9sb2dvIiBnZXRlbnYg ZHVwIC0xIDw+IGlmDQorCQlkdXAgNSArIGFsbG9jYXRlIGlmIEVOT01FTSB0aHJvdyB0aGVuDQor CQkwIDJzd2FwIHN0cmNhdCBzIiAtbG9nbyIgc3RyY2F0DQorCQlvdmVyIC1yb3QgKCBhLWFkZHIv dSAtLSBhLWFkZHIgYS1hZGRyL3UgKQ0KKwkJc2ZpbmQgICAgICggYS1hZGRyIGEtYWRkci91IC0t IGEtYWRkciB4dCBib29sICkNCisJCXJvdCAgICAgICAoIGEtYWRkciB4dCBib29sIC0tIHh0IGJv b2wgYS1hZGRyICkNCisJCWZyZWUgICAgICAoIHh0IGJvb2wgYS1hZGRyIC0tIHh0IGJvb2wgaW9y ICkNCisJCWlmIEVGUkVFIHRocm93IHRoZW4NCisJZWxzZQ0KKwkJMCAoIGNydWZ0IC0tIGNydWZ0 IGJvb2wgKSBcIGxvYWQgdGhlIGRlZmF1bHQgYmVsb3cNCisJdGhlbg0KKwkwPSBpZg0KKwkJZHJv cCAoIGNydWZ0IC0tICkNCiAJCWxvYWRlcl9jb2xvcj8gaWYNCi0JCQlvcmItbG9nbw0KKwkJCVsn XSBvcmItbG9nbw0KIAkJZWxzZQ0KLQkJCW9yYmJ3LWxvZ28NCisJCQlbJ10gb3JiYnctbG9nbw0K IAkJdGhlbg0KLQkJZHJvcCBleGl0DQogCXRoZW4NCi0NCi0JMmR1cCBzIiBiZWFzdGllIiBjb21w YXJlLWluc2Vuc2l0aXZlIDA9IGlmDQotCQlsb2dvWCBAIGxvZ29ZIEAgYmVhc3RpZS1sb2dvDQot CQkyZHJvcCBleGl0DQotCXRoZW4NCi0JMmR1cCBzIiBiZWFzdGllYnciIGNvbXBhcmUtaW5zZW5z aXRpdmUgMD0gaWYNCi0JCWxvZ29YIEAgbG9nb1kgQCBiZWFzdGllYnctbG9nbw0KLQkJMmRyb3Ag ZXhpdA0KLQl0aGVuDQotCTJkdXAgcyIgZmJzZGJ3IiBjb21wYXJlLWluc2Vuc2l0aXZlIDA9IGlm DQotCQlsb2dvWCBAIGxvZ29ZIEAgZmJzZGJ3LWxvZ28NCi0JCTJkcm9wIGV4aXQNCi0JdGhlbg0K LQkyZHVwIHMiIG9yYiIgY29tcGFyZS1pbnNlbnNpdGl2ZSAwPSBpZg0KLQkJbG9nb1ggQCBsb2dv WSBAIG9yYi1sb2dvDQotCQkyZHJvcCBleGl0DQotCXRoZW4NCi0JMmR1cCBzIiBvcmJidyIgY29t cGFyZS1pbnNlbnNpdGl2ZSAwPSBpZg0KLQkJbG9nb1ggQCBsb2dvWSBAIG9yYmJ3LWxvZ28NCi0J CTJkcm9wIGV4aXQNCi0JdGhlbg0KLQkyZHVwIHMiIHRyaWJ1dGUiIGNvbXBhcmUtaW5zZW5zaXRp dmUgMD0gaWYNCi0JCWxvZ29YIEAgbG9nb1kgQA0KLQkJcyIgdHJpYnV0ZS1sb2dvIiBzZmluZCBp Zg0KLQkJCWV4ZWN1dGUNCi0JCWVsc2UNCi0JCQlkcm9wIG9yYi1sb2dvDQotCQl0aGVuDQotCQky ZHJvcCBleGl0DQotCXRoZW4NCi0JMmR1cCBzIiB0cmlidXRlYnciIGNvbXBhcmUtaW5zZW5zaXRp dmUgMD0gaWYNCi0JCWxvZ29YIEAgbG9nb1kgQA0KLQkJcyIgdHJpYnV0ZWJ3LWxvZ28iIHNmaW5k IGlmDQotCQkJZXhlY3V0ZQ0KLQkJZWxzZQ0KLQkJCWRyb3Agb3JiYnctbG9nbw0KLQkJdGhlbg0K LQkJMmRyb3AgZXhpdA0KLQl0aGVuDQotDQotCTJkcm9wDQorCWxvZ29YIEAgbG9nb1kgQCByb3Qg ZXhlY3V0ZQ0KIDsNCiANCiA6IGNsZWFyLWJlYXN0aWUgKCAtLSApIFwgY2xlYXJzIGJlYXN0aWUg ZnJvbSB0aGUgc2NyZWVuDQo= --_002_7DD09B24F4D74ED483E2E9D72C157020fisglobalcom_-- From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 14 17:31:09 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4A96F8CF; Thu, 14 Nov 2013 17:31:09 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 345032DD7; Thu, 14 Nov 2013 17:31:09 +0000 (UTC) Received: from Alfreds-MacBook-Air.local (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id 565651A3C2C; Thu, 14 Nov 2013 09:31:03 -0800 (PST) Message-ID: <528508D6.7000508@freebsd.org> Date: Thu, 14 Nov 2013 09:31:02 -0800 From: Alfred Perlstein Organization: FreeBSD User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Devin Teske Subject: Re: Loader forth changes for customization References: <5282E56F.4020307@freebsd.org> <52832003.8080406@freebsd.org> <09673101-DB54-4D25-9989-8C80D06E266B@fisglobal.com> <5283933E.30603@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.16 Cc: FreeBSD Hackers , "Teske, Devin" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 17:31:09 -0000 On 11/13/13, 11:54 PM, Teske, Devin wrote: > On Nov 13, 2013, at 6:57 AM, Alfred Perlstein wrote: > >> On 11/13/13, 12:18 AM, Teske, Devin wrote: >>> On Nov 12, 2013, at 10:45 PM, Alfred Perlstein wrote: >>> >>>> I added some hooks for menu.rc as well, you can see it via the github urls below. >>>> >>>> I've attached a sample menu.rc.local that provides additional menus. >>>> >>>> -Alfred >>>> >>>> On 11/12/13, 6:35 PM, Alfred Perlstein wrote: >>>>> Hey folks, >>>>> >>>>> I added some forth using Devin's help to make it easier to customize the FreeBSD boot loader graphics. >>>>> >>>>> Diffs are here: >>>>> https://github.com/alfredperlstein/freebsd/compare/loader_custom_rc >>>>> -or- >>>>> https://github.com/alfredperlstein/freebsd/compare/loader_custom_rc.diff >>>>> >>>>> >>>>> Diff attached. >>>>> >>>>> Also attached is a custom loader.rc file and loader.conf file that shows how to set the brand/logo. >>>>> >>>>> Please review. >>>>> >>> I signed up for a github account (thanks), and I started commenting on some lines. >> yay! :) >>>>> -Alfred >>>> >>> Hmmm, I hadn't realized that you could say: >>> >>> set foo=bar >>> >>> Along-side setting functions in the same file. >>> >>> I don't think you can set functions in an *.rc file, only in a *.4th file? >>> >>> No? Maybe it's a false misconception of mine. I've been keeping them >>> separate for years. (but probably rightfully so, to keep *.rc files clean). >> It seems to work although I will talk to the team about making separate files for the set commands. >> >> I've responded to your review comments here: >> >> https://github.com/alfredperlstein/freebsd/commit/0ca72dccd78b880b3e3ef4c2bb9ce025950a370b#commitcomment-4584862 >> >> The changes I made are now in the branch >> https://github.com/alfredperlstein/freebsd/tree/loader_custom_rc and you likely should see them in the updated pull request I sent you. >> > I improved on a few things... > > https://github.com/devinteske/freebsd/compare/freebsd:master...master > -or- > https://github.com/devinteske/freebsd/compare/freebsd:master...master.diff > -or- > Attached SVN patch.txt Hey this is really awesome. I'll try to spin it up today and hopefully get it into FreeNAS/TrueOS today! I really like the level of comments here! Having both the micro and macro explanation of what is going on is very helpful. +: try-include ( -- ) \ see loader.4th(8) + ['] include ( -- xt ) \ get the execution token of `include' + catch ( xt -- exception# | 0 ) if \ failed + LF parse ( c -- s-addr/u ) 2drop \ advance >in to EOL (drop data) + \ ... prevents words unused by `include' from being interpreted + then +; immediate \ interpret immediately for access to `source' (aka tib) + So a few questions here: If so when why are we clearing to EOL? Is "include" supposed to be alone on a line by itself? You can't do this: include file_that_exists.rc 5 6 + . and likewise you can't do: try-include file_that_exists.rc 5 6 + . try-include file_that_does_NOT_exists.rc 5 6 + . It's not that important, just interesting. I'm wondering though, with the exception of actually including the file or not, will both of these: try-include file_that_exists.rc 5 6 + . try-include file_that_does_NOT_exists.rc 5 6 + . print '11'? Or not? Also, are there certain errors we want to report like "EISDIR" ? I'm not concerned for my application, but it's an just academic question I have. Finally thank you so much for the tutoring in forth, it's very cool and thanks for putting up with my obvious frustration at learning a new lang! -Alfred From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 14 18:03:15 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 545FFB9F; Thu, 14 Nov 2013 18:03:15 +0000 (UTC) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A2CC82090; Thu, 14 Nov 2013 18:03:14 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.16]) by ltcfislmsgpa07.fnfis.com (8.14.5/8.14.5) with ESMTP id rAEI3BQU006012 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 14 Nov 2013 12:03:11 -0600 Received: from LTCFISWMSGMB21.FNFIS.com ([169.254.1.152]) by LTCFISWMSGHT05.FNFIS.com ([10.132.206.16]) with mapi id 14.03.0158.001; Thu, 14 Nov 2013 12:03:10 -0600 From: "Teske, Devin" To: Alfred Perlstein Subject: Re: Loader forth changes for customization Thread-Topic: Loader forth changes for customization Thread-Index: AQHO4EjnMi0GIoZQO0eCkJ5RnRP0Cw== Date: Thu, 14 Nov 2013 18:03:09 +0000 Message-ID: <447D6972-CBA7-4446-9224-60E17F4843C1@fisglobal.com> References: <5282E56F.4020307@freebsd.org> <52832003.8080406@freebsd.org> <09673101-DB54-4D25-9989-8C80D06E266B@fisglobal.com> <5283933E.30603@freebsd.org> <528508D6.7000508@freebsd.org> In-Reply-To: <528508D6.7000508@freebsd.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.120] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.14, 0.0.0000 definitions=2013-11-14_07:2013-11-13,2013-11-14,1970-01-01 signatures=0 Cc: FreeBSD Hackers , Devin Teske , "Teske, Devin" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list Reply-To: Devin Teske List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 18:03:15 -0000 On Nov 14, 2013, at 9:31 AM, Alfred Perlstein wrote: >=20 > On 11/13/13, 11:54 PM, Teske, Devin wrote: >> On Nov 13, 2013, at 6:57 AM, Alfred Perlstein wrote: >>=20 >>=20 >>> On 11/13/13, 12:18 AM, Teske, Devin wrote: >>>=20 >>>> On Nov 12, 2013, at 10:45 PM, Alfred Perlstein wrote: >>>>=20 >>>>=20 >>>>> I added some hooks for menu.rc as well, you can see it via the github= urls below. >>>>>=20 >>>>> I've attached a sample menu.rc.local that provides additional menus. >>>>>=20 >>>>> -Alfred >>>>>=20 >>>>> On 11/12/13, 6:35 PM, Alfred Perlstein wrote: >>>>>=20 >>>>>> Hey folks, >>>>>>=20 >>>>>> I added some forth using Devin's help to make it easier to customize= the FreeBSD boot loader graphics. >>>>>>=20 >>>>>> Diffs are here: >>>>>>=20 >>>>>> https://github.com/alfredperlstein/freebsd/compare/loader_custom_rc >>>>>>=20 >>>>>> -or- >>>>>>=20 >>>>>> https://github.com/alfredperlstein/freebsd/compare/loader_custom_rc.= diff >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Diff attached. >>>>>>=20 >>>>>> Also attached is a custom loader.rc file and loader.conf file that s= hows how to set the brand/logo. >>>>>>=20 >>>>>> Please review. >>>>>>=20 >>>>>>=20 >>>> I signed up for a github account (thanks), and I started commenting on= some lines. >>>>=20 >>> yay! :) >>>=20 >>>>>> -Alfred >>>>>>=20 >>>>> >>>>>=20 >>>> Hmmm, I hadn't realized that you could say: >>>>=20 >>>> set foo=3Dbar >>>>=20 >>>> Along-side setting functions in the same file. >>>>=20 >>>> I don't think you can set functions in an *.rc file, only in a *.4th f= ile? >>>>=20 >>>> No? Maybe it's a false misconception of mine. I've been keeping them >>>> separate for years. (but probably rightfully so, to keep *.rc files cl= ean). >>>>=20 >>> It seems to work although I will talk to the team about making separate= files for the set commands. >>>=20 >>> I've responded to your review comments here: >>>=20 >>>=20 >>> https://github.com/alfredperlstein/freebsd/commit/0ca72dccd78b880b3e3ef= 4c2bb9ce025950a370b#commitcomment-4584862 >>>=20 >>>=20 >>> The changes I made are now in the branch >>>=20 >>> https://github.com/alfredperlstein/freebsd/tree/loader_custom_rc >>> and you likely should see them in the updated pull request I sent you. >>>=20 >>>=20 >> I improved on a few things... >>=20 >>=20 >> https://github.com/devinteske/freebsd/compare/freebsd:master...master >>=20 >> -or- >>=20 >> https://github.com/devinteske/freebsd/compare/freebsd:master...master.di= ff >>=20 >> -or- >> Attached SVN patch.txt >>=20 > Hey this is really awesome. I'll try to spin it up today and hopefully g= et it into FreeNAS/TrueOS today!=20 >=20 > I really like the level of comments here! Having both the micro and macr= o explanation of what is going on is very helpful. >=20 > +: try-include ( -- ) \ see loader.4th(8) > + ['] include ( -- xt ) \ get the execution token of `include' > + catch ( xt -- exception# | 0 ) if \ failed > + LF parse ( c -- s-addr/u ) 2drop \ advance >in to EOL (drop data) > + \ ... prevents words unused by `include' from being interpreted > + then > +; immediate \ interpret immediately for access to `source' (aka tib) > + >=20 >=20 > So a few questions here: > If so when why are we clearing to EOL? Technical aside (for later): ">in" represents the offset within the "sourcc= e" buffer. When "include" aborts on error, the offset within the read buffer (>in) is = not advanced. Technical aside #2: This is important because the interpreter picks up where we left off (>in @ within source). So, what's really going on is... "include" aborts and there's no expectation that it will be caught and thus no guard against the interpreter picking up where the [caught] abort left o= ff. In other words, "include" does not advance the text input buffer because it aborts and thinks it has successfully "quit" the interpreter. But then we g= o and catch it, so we need to advance the input stream ourselves. In even more in-depth look... if you drop that code, here's what happens... NB: In other words, simply : try-include ['] include catch drop ; immediate NB: Don't use that implementation for the below reason. try-include /boot/loader.rc.local \ NB: All good if the file exists and "include" does not abort try-include /does/not/exist /does/not/exist: not found In the above example, we see that the interpreter picked up at "/does/not/e= xist" and tried to execute it as a Forth dictionary word. Now... why clear all the way to the end of the line? Because include takes multiple arguments... include file1 file2 file3 ... Terminated by a newline. It parses using C so is more sophisticated than we could do in a few lines of Forth... include /boot/loader".rc."local NB: That works. And because we've chain-loaded to "include" from try-includ= e, that works with "try-include" as well. > Is "include" supposed to be alone on a line by itself? You can't do thi= s: > include file_that_exists.rc 5 6 + . > and likewise you can't do: > try-include file_that_exists.rc 5 6 + . > try-include file_that_does_NOT_exists.rc 5 6 + . >=20 Correct... we've come across a limitation in the chain-loading of "include". We have no way of knowing -- after "include" aborts -- how many words it parsed. But it's far worse than that. We could make the assumption that it was parsing the last word... and in the Forth support-functions (iirc) we have "parse-word", and even lower in the built-in dictionary we have "word". But here's the nasty edge-case. Remember that "include" uses C to parse and is more sophisticated than we can do easily in Forth. So the following syntax would break that assumption: try-include "/foo /bar" The executed "include" would abort, leaving >in @ on the first double-quote of "/foo /bar", and if we assumed that it was parsing the last word, we w= ould call "parse-word" which would _only_ advance >in to the "/" in "/bar". Hence why we read to the EOL -- for edge-cases like that where "include" would have properly eaten the word (but does not advance >in prior to the abort). So I guess you could say that this is a work-around for the real solution w= hich would be to modify the FICL definition of "include" (which iirc should be i= n ficl.c) to advance the offset to the end of the failed argument before calling abor= t... But ... (geez, all these edge-cases) ... here's the final kicker. Even if we modified "include" to advance to the end of the argument... it h= as another bad habit. It aborts on the first bad file. So let's say you have: try-include /good/file /bad/file /good/file NOTE: /good/file exists and /bad/file does not. When "include" gets to the /bad/file argument, it will abort, and let's say= that it did advance the input stream to (at the very least) the whitespace betwe= en "/bad/file" and the last "/good/file". At that point, the interpreter picks up at said whitespace and now you get: /good/file: not found Because the interpreter will try to execute /good/file as a Forth word whic= h is naturally not in the dictionary. If one wants to fix "include", what I surmise would need to be done is to rewrite it to parse to EOL, advancing the input buffer prior to processing any stored arguments. Then when we abort on the first error, if the abort is caught the input stream is sufficiently advanced-in-offset that the interpreter can pick up on the next line. NB: So hence why try-include does this. It would be the same change for include, but rather than changing the C code, I just made it in Forth (as a single "LF parse 2drop" call to drain the input stream up to the EOL. > It's not that important, just interesting. I'm wondering though, with th= e exception of actually including the file or not, will both of these: > try-include file_that_exists.rc 5 6 + . That would not print 11 because "include" would try to read "5" and get an error. Then we (try-include) would return and drain the line. > try-include file_that_does_NOT_exists.rc 5 6 + . This similarly would not print 11 because "include" would abort on the file that doesn't exist, and "try-include" would drain the line. > print '11'? Or not? >=20 Neither would print 11, but ... You wouldn't want to do this with "include" either. For the very reason that "include" takes multiple arguments from the input stream and would interpret your "5" as a file name. If "5" is not a file, then it aborts and your code *seems* to work... but... If "5" is a file and exists and does not cause an abort due to syntax... NB: Assuming you catch the abort The interpreter will pick up on "6" and you'll then execute "+" and get a stack underflow. You really do, whether using "include" or "try-include" want to break your Forth code out onto a separate line. Recap: + Forth on the same line as "include" will be tried as a filename first + Forth on the same line as "try-include" will be ignored (see previous technical reasons above) > Also, are there certain errors we want to report like "EISDIR" ? I'm not= concerned for my application, but it's an just academic question I have. >=20 Quite possibly. I think there's something in support.4th that will print an error -- if not, we'll have to write it from scratch (and keeping to the ma= xim, spin that out into something in support.4th where the IOR codes are cleanly defined as constants). > Finally thank you so much for the tutoring in forth, it's very cool and t= hanks for putting up with my obvious frustration at learning a new lang! >=20 No worries... it's fun isn't it? ;D --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 14 21:32: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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D70E7541; Thu, 14 Nov 2013 21:32:37 +0000 (UTC) Received: from smtp.btshosting.co.uk (mx-2.btshosting.co.uk [IPv6:2a01:4f8:121:2403:2::]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 64E752FC7; Thu, 14 Nov 2013 21:32:37 +0000 (UTC) Received: from [192.168.1.65] (unknown [94.12.20.243]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by svr06-mx.btshosting.co.uk (Postfix) with ESMTPSA id DCA614325B; Thu, 14 Nov 2013 21:32:27 +0000 (UTC) Message-ID: <52854161.6080104@FreeBSD.org> Date: Thu, 14 Nov 2013 21:32:17 +0000 From: Jase Thew Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: John Baldwin , freebsd-hackers@freebsd.org Subject: Re: Re: Fix MNAMELEN or reimplement struct statfs References: <51B3B59B.8050903@erdgeist.org> <201306101152.17966.jhb@freebsd.org> In-Reply-To: <201306101152.17966.jhb@freebsd.org> X-Enigmail-Version: 1.6 OpenPGP: id=3F9B9617; url=pool.sks-keyservers.net Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="WndSvNix6WnTdCfV7fNso5ASebNPhDBXN" Cc: mdf@freebsd.org, Dirk Engling X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 21:32:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --WndSvNix6WnTdCfV7fNso5ASebNPhDBXN Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 10/06/2013 16:52, John Baldwin wrote: > On Saturday, June 08, 2013 9:36:27 pm mdf@freebsd.org wrote: >> On Sat, Jun 8, 2013 at 3:52 PM, Dirk Engling w= rote: >> >>> 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 she= d. >>> >> >> Gleb Kurtsou did this along with the ino64 GSoC project. Unfortunatel= y, >> 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 h= e'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. >=20 > 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=20 > that can be updated and a new patch generated? >=20 Hi folks, Has there been any progress on addressing this issue? With the advent of pkgng / poudriere, this limitation is really becoming a frustrating probl= em. --=20 Jase Thew jase@FreeBSD.org FreeBSD Ports Committer --WndSvNix6WnTdCfV7fNso5ASebNPhDBXN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQJ8BAEBCgBmBQJShUFrXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGNzY3ODIxQkE1MTQ4MjNFQ0RGNUM3QkRE NEU2NUM4QkZGMUMzODI5AAoJENTmXIv/HDgp/4QP/RyhATKVUf7H6jyrZhb+tCeV Li1rJ4w8Z5fK7C9vjqfl06sLezm/fvZb7Sk5GViP/LcvqKYjjCdheq+bdFikpQkT DbTNZEZAW8qDvEG/wpiShim+xahOhn6wJwC24ctrMw+ICvMbsUiol0rXu+NNEejA uA38yJ+J6MrrJklSSj+bVXcTSWrsSXFZCDalV6aF+nTdH4ImV4vsO3liSQvEIU8s OteJgpSVgruJrPY/7Pxe9t943KAbuWNG1guH0dD+mxH/9cgEDzttrvGXVBhYMDbH 9gy2KV4mr5RK8cCsDjwXgkXjPn51y63W6X6vVTo25WDIwQhDKMM4YE57LUOFG+s0 ykjh2fWgWJrtVyKpBVx+ikDOnPS6S6lKS3ucKQJHfRuN2SXyUVGudMbAcMUuTsz/ Hoy3IIQW2o1rDMtmrSx4beXCV9cd/BCNM0Q2ESIQcQQXD76Bp4qEXns+tNhSR3SS KtF7hGWWjxAicUzm8mc1UyL6IQgW0TIVvbEbGRkiNqdL5mNj4laaWE720kFB7BDl kK7reJ0500YKOjgAdZK7ZgcSlMRZU42eh09YkYZxdIzREFPAz86CNu76hFa7b6gX sAf/VRC0aeF1sjCpvD9VnOECTs5KbTOOfWeLsLwnhqj0xfSnEHoka2ssYmVBBvyP /qehrfqbOCKrGOfwzYU7 =78eZ -----END PGP SIGNATURE----- --WndSvNix6WnTdCfV7fNso5ASebNPhDBXN-- From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 15 01:08:56 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 86477AC6; Fri, 15 Nov 2013 01:08:56 +0000 (UTC) Received: from mail.ambrisko.com (mail.ambrisko.com [70.91.206.90]) by mx1.freebsd.org (Postfix) with ESMTP id 353952C90; Fri, 15 Nov 2013 01:08:56 +0000 (UTC) X-Ambrisko-Me: Yes Received: from server2.ambrisko.com (HELO internal.ambrisko.com) ([192.168.1.2]) by ironport.ambrisko.com with ESMTP; 14 Nov 2013 17:12:46 -0800 Received: from ambrisko.com (localhost [127.0.0.1]) by internal.ambrisko.com (8.14.4/8.14.4) with ESMTP id rAF18tDx081323; Thu, 14 Nov 2013 17:08:55 -0800 (PST) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.4/8.14.4/Submit) id rAF18sM4081322; Thu, 14 Nov 2013 17:08:54 -0800 (PST) (envelope-from ambrisko) Date: Thu, 14 Nov 2013 17:08:54 -0800 From: Doug Ambrisko To: Jase Thew Subject: Re: Re: Fix MNAMELEN or reimplement struct statfs Message-ID: <20131115010854.GA76106@ambrisko.com> References: <51B3B59B.8050903@erdgeist.org> <201306101152.17966.jhb@freebsd.org> <52854161.6080104@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52854161.6080104@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-hackers@freebsd.org, Dirk Engling , mdf@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 01:08:56 -0000 On Thu, Nov 14, 2013 at 09:32:17PM +0000, Jase Thew wrote: | On 10/06/2013 16:52, John Baldwin wrote: | > 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? | > | | Hi folks, | | Has there been any progress on addressing this issue? With the advent of | pkgng / poudriere, this limitation is really becoming a frustrating problem. I looked at NetBSD and what they did with statvfs. The mount paths lengths are bigger in NetBSD defines so that helps. However, when testing it out via a script that keep on doing a nullfs mount in every increasing directory depth I found that NetBSD would allow the mount to exceed the value in statvfs. When NetBSD populates the path in statvfs they truncate it to what fits in statvfs. So I looked at what that might be like in FreeBSD. So I came up with this simple patch: --- /sys/kern/vfs_mount.c 2013-10-01 14:27:35.000000000 -0700 +++ vfs_mount.c 2013-10-21 14:20:19.000000000 -0700 @@ -656,7 +656,7 @@ vfs_donmount(struct thread *td, uint64_t * variables will fit in our mp buffers, including the * terminating NUL. */ - if (fstypelen >= MFSNAMELEN - 1 || fspathlen >= MNAMELEN - 1) { + if (fstypelen >= MFSNAMELEN - 1 || fspathlen >= MAXPATHLEN - 1) { error = ENAMETOOLONG; goto bail; } @@ -748,8 +748,8 @@ sys_mount(td, uap) return (EOPNOTSUPP); } - ma = mount_argsu(ma, "fstype", uap->type, MNAMELEN); - ma = mount_argsu(ma, "fspath", uap->path, MNAMELEN); + ma = mount_argsu(ma, "fstype", uap->type, MFSNAMELEN); + ma = mount_argsu(ma, "fspath", uap->path, MAXPATHLEN); ma = mount_argb(ma, flags & MNT_RDONLY, "noro"); ma = mount_argb(ma, !(flags & MNT_NOSUID), "nosuid"); ma = mount_argb(ma, !(flags & MNT_NOEXEC), "noexec"); @@ -1039,7 +1039,7 @@ vfs_domount( * variables will fit in our mp buffers, including the * terminating NUL. */ - if (strlen(fstype) >= MFSNAMELEN || strlen(fspath) >= MNAMELEN) + if (strlen(fstype) >= MFSNAMELEN || strlen(fspath) >= MAXPATHLEN) return (ENAMETOOLONG); if (jailed(td->td_ucred) || usermount == 0) { @@ -1095,9 +1095,9 @@ vfs_domount( NDFREE(&nd, NDF_ONLY_PNBUF); vp = nd.ni_vp; if ((fsflags & MNT_UPDATE) == 0) { - pathbuf = malloc(MNAMELEN, M_TEMP, M_WAITOK); + pathbuf = malloc(MAXPATHLEN, M_TEMP, M_WAITOK); strcpy(pathbuf, fspath); - error = vn_path_to_global_path(td, vp, pathbuf, MNAMELEN); + error = vn_path_to_global_path(td, vp, pathbuf, MAXPATHLEN); /* debug.disablefullpath == 1 results in ENODEV */ if (error == 0 || error == ENODEV) { error = vfs_domount_first(td, vfsp, pathbuf, vp, @@ -1147,8 +1147,8 @@ sys_unmount(td, uap) return (error); } - pathbuf = malloc(MNAMELEN, M_TEMP, M_WAITOK); - error = copyinstr(uap->path, pathbuf, MNAMELEN, NULL); + pathbuf = malloc(MAXPATHLEN, M_TEMP, M_WAITOK); + error = copyinstr(uap->path, pathbuf, MAXPATHLEN, NULL); if (error) { free(pathbuf, M_TEMP); return (error); @@ -1181,7 +1181,7 @@ sys_unmount(td, uap) vfslocked = NDHASGIANT(&nd); NDFREE(&nd, NDF_ONLY_PNBUF); error = vn_path_to_global_path(td, nd.ni_vp, pathbuf, - MNAMELEN); + MAXPATHLEN); if (error == 0 || error == ENODEV) vput(nd.ni_vp); VFS_UNLOCK_GIANT(vfslocked); I seemed to have found a typo bug in an instance in which MFSNAMELEN wasn't used in the fstype when I did this change. With this patch things in general seem to work. You can do a mount and umount of a long path. The umount of the long path works by failing on the exact match but then passing when via the FSID. df/mount looks a little strange since it shows a truncated path but has valid contents (FS type, space etc.). umount via the truncated path works if there is only one truncated path that matches. If there are multiple then it fails. This doesn't change and kernel ABI's so then it is safe to apply to the kernel without rebuilding user-land. Future work could be to implement statvfs to return a longer path but only do it for df/umount etc. The rest of the system could continue with the existing statfs. mount works because it passed a string into the kernel so it can be long. I'd propose this as a current solution to this problem. It appears to work well and shouldn't drastically break things. Doing df via the full path, stat etc. work since the associated path access the vnode. So things that do a mount, df of the mount point etc. should continue to work. Scripts that try to figure out the mount points vi df and mount displaying all mount points would fail. That is probably good enough for now. Comments welcomed. Thanks, Doug A. From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 15 08:30: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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0D782352 for ; Fri, 15 Nov 2013 08:30:52 +0000 (UTC) Received: from mail-ee0-x234.google.com (mail-ee0-x234.google.com [IPv6:2a00:1450:4013:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A135C271C for ; Fri, 15 Nov 2013 08:30:51 +0000 (UTC) Received: by mail-ee0-f52.google.com with SMTP id l10so893519eei.39 for ; Fri, 15 Nov 2013 00:30:50 -0800 (PST) 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=qDNRU8klCXXe8j4ltY0PqMa84AxcFJUJ5earZ8qFgxs=; b=ylkiobPKpjQiNl8EUTvZxpmFjJbCAga9EGrqjqzwe8uRj+jLB/8UhWAf4b4Bb4nuni rDURaWAuMoJy+qBFDlw8UzmGciiUA7zgF1otcd3xBrtHIrJPc0jUZWjDwjr7sNO2EQzv V3WNijqKxo/M5q8cbnhLWpFN0f2ekL25ilIvYwh3fOI07vStJqieOXlxVrFUoHrB5enj 4VJPwANnu7TyO8DCdvGdOah6MLT7UWyKJi7DPCk9Tdh0vOOz8+gp3KrOx4h7ygG8uFYv uvkID0uAQBB3Ebmas9loQnJYUmj7urX4UvV2vON5c4ED8Wwxpg7qFRm2VOMPzxmOzWIR OYDA== MIME-Version: 1.0 X-Received: by 10.14.203.70 with SMTP id e46mr1656824eeo.33.1384504250037; Fri, 15 Nov 2013 00:30:50 -0800 (PST) Received: by 10.14.127.195 with HTTP; Fri, 15 Nov 2013 00:30:49 -0800 (PST) Date: Fri, 15 Nov 2013 00:30:49 -0800 Message-ID: Subject: ULE thread scheduling in -head From: hiren panchasara To: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 08:30:52 -0000 I want to understand how thread affinity works and for that I need to understand how scheduling works. I am reading things and trying to map them to the code in FreeBSD-head (in and around sys/kern/sched_ule.c) In terms of scheduler queues, I found 2 different things: 1) "ULE: A Modern Scheduler For FreeBSD" paper from jeffr mentions following in 3.1 Queue Mechanisms: Fairness is implemented by keeping two queues; current and next. Each thread that is granted a slice is assigned to either the current queue or the next queue. 2) I found another interesting struct in there: struct tdq - per processor runqs and statistics which has 3 queues: realtime, timeshare and idle. I could not find 1) in source code. Can someone throw some light on how a thread gets scheduled? Do 1) and 2) both exist and work together currently in -head FreeBSD? Trying to follow the code, sched_setup() calls sched_setup_smp() where for each cpu we call tdq_setup() where we initialize 3 queues mentioned in 2) -- But it seems this is all one time setup on boot. What happens when a new thread is spawned? Any good pointer/reference for further reading would be great. cheers, Hiren From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 16 18:31:42 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B23F594F; Sat, 16 Nov 2013 18:31:42 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 247792E42; Sat, 16 Nov 2013 18:31:41 +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 rAGIVVZ4055440; Sat, 16 Nov 2013 20:31:31 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua rAGIVVZ4055440 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id rAGIVTKO055439; Sat, 16 Nov 2013 20:31:29 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 16 Nov 2013 20:31:29 +0200 From: Konstantin Belousov To: Doug Ambrisko Subject: Re: Re: Fix MNAMELEN or reimplement struct statfs Message-ID: <20131116183129.GD59496@kib.kiev.ua> References: <51B3B59B.8050903@erdgeist.org> <201306101152.17966.jhb@freebsd.org> <52854161.6080104@FreeBSD.org> <20131115010854.GA76106@ambrisko.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0vFzRikYu/73UBJt" Content-Disposition: inline In-Reply-To: <20131115010854.GA76106@ambrisko.com> User-Agent: Mutt/1.5.22 (2013-10-16) 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 Cc: freebsd-hackers@freebsd.org, Dirk Engling , Jase Thew , mdf@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Nov 2013 18:31:42 -0000 --0vFzRikYu/73UBJt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 14, 2013 at 05:08:54PM -0800, Doug Ambrisko wrote: > On Thu, Nov 14, 2013 at 09:32:17PM +0000, Jase Thew wrote: > | On 10/06/2013 16:52, John Baldwin wrote: > | > 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 buf= s */ > | >>> > | >>> struct statfs { > | >>> [...] > | >>> char f_mntfromname[MNAMELEN];/* mounted filesystem */ > | >>> char f_mntonname[MNAMELEN]; /* directory on which mount= ed */ > | >>> }; > | >>> > | >>> 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_mntfromna= me a > | >>> dynamic allocation or just increase MNAMELEN, using 10.0 as water s= hed. > | >>> > | >> > | >> Gleb Kurtsou did this along with the ino64 GSoC project. Unfortunat= ely, > | >> 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. > | >=20 > | > He also fixed a few other things since changing this ABI is so invasi= ve > | > IIRC. This really is the right fix for this. Is it in an svn branch= =20 > | > that can be updated and a new patch generated? > | >=20 > |=20 > | Hi folks, > |=20 > | Has there been any progress on addressing this issue? With the advent of > | pkgng / poudriere, this limitation is really becoming a frustrating pro= blem. >=20 > I looked at NetBSD and what they did with statvfs. The mount paths > lengths are bigger in NetBSD defines so that helps. However, when > testing it out via a script that keep on doing a nullfs mount in=20 > every increasing directory depth I found that NetBSD would allow the > mount to exceed the value in statvfs. When NetBSD populates the path > in statvfs they truncate it to what fits in statvfs. So I looked at > what that might be like in FreeBSD. So I came up with this simple patch: >=20 > --- /sys/kern/vfs_mount.c 2013-10-01 14:27:35.000000000 -0700 > +++ vfs_mount.c 2013-10-21 14:20:19.000000000 -0700 > @@ -656,7 +656,7 @@ vfs_donmount(struct thread *td, uint64_t > * variables will fit in our mp buffers, including the > * terminating NUL. > */ > - if (fstypelen >=3D MFSNAMELEN - 1 || fspathlen >=3D MNAMELEN - 1) { > + if (fstypelen >=3D MFSNAMELEN - 1 || fspathlen >=3D MAXPATHLEN - 1) { > error =3D ENAMETOOLONG; > goto bail; > } > @@ -748,8 +748,8 @@ sys_mount(td, uap) > return (EOPNOTSUPP); > } > =20 > - ma =3D mount_argsu(ma, "fstype", uap->type, MNAMELEN); > - ma =3D mount_argsu(ma, "fspath", uap->path, MNAMELEN); > + ma =3D mount_argsu(ma, "fstype", uap->type, MFSNAMELEN); > + ma =3D mount_argsu(ma, "fspath", uap->path, MAXPATHLEN); > ma =3D mount_argb(ma, flags & MNT_RDONLY, "noro"); > ma =3D mount_argb(ma, !(flags & MNT_NOSUID), "nosuid"); > ma =3D mount_argb(ma, !(flags & MNT_NOEXEC), "noexec"); > @@ -1039,7 +1039,7 @@ vfs_domount( > * variables will fit in our mp buffers, including the > * terminating NUL. > */ > - if (strlen(fstype) >=3D MFSNAMELEN || strlen(fspath) >=3D MNAMELEN) > + if (strlen(fstype) >=3D MFSNAMELEN || strlen(fspath) >=3D MAXPATHLEN) > return (ENAMETOOLONG); > =20 > if (jailed(td->td_ucred) || usermount =3D=3D 0) { > @@ -1095,9 +1095,9 @@ vfs_domount( > NDFREE(&nd, NDF_ONLY_PNBUF); > vp =3D nd.ni_vp; > if ((fsflags & MNT_UPDATE) =3D=3D 0) { > - pathbuf =3D malloc(MNAMELEN, M_TEMP, M_WAITOK); > + pathbuf =3D malloc(MAXPATHLEN, M_TEMP, M_WAITOK); > strcpy(pathbuf, fspath); > - error =3D vn_path_to_global_path(td, vp, pathbuf, MNAMELEN); > + error =3D vn_path_to_global_path(td, vp, pathbuf, MAXPATHLEN); > /* debug.disablefullpath =3D=3D 1 results in ENODEV */ > if (error =3D=3D 0 || error =3D=3D ENODEV) { > error =3D vfs_domount_first(td, vfsp, pathbuf, vp, > @@ -1147,8 +1147,8 @@ sys_unmount(td, uap) > return (error); > } > =20 > - pathbuf =3D malloc(MNAMELEN, M_TEMP, M_WAITOK); > - error =3D copyinstr(uap->path, pathbuf, MNAMELEN, NULL); > + pathbuf =3D malloc(MAXPATHLEN, M_TEMP, M_WAITOK); > + error =3D copyinstr(uap->path, pathbuf, MAXPATHLEN, NULL); > if (error) { > free(pathbuf, M_TEMP); > return (error); > @@ -1181,7 +1181,7 @@ sys_unmount(td, uap) > vfslocked =3D NDHASGIANT(&nd); > NDFREE(&nd, NDF_ONLY_PNBUF); > error =3D vn_path_to_global_path(td, nd.ni_vp, pathbuf, > - MNAMELEN); > + MAXPATHLEN); > if (error =3D=3D 0 || error =3D=3D ENODEV) > vput(nd.ni_vp); > VFS_UNLOCK_GIANT(vfslocked); >=20 > I seemed to have found a typo bug in an instance in which MFSNAMELEN > wasn't used in the fstype when I did this change. >=20 > With this patch things in general seem to work. You can do a > mount and umount of a long path. The umount of the long path works > by failing on the exact match but then passing when via the FSID. > df/mount looks a little strange since it shows a truncated path=20 > but has valid contents (FS type, space etc.). umount via the truncated > path works if there is only one truncated path that matches. If there > are multiple then it fails. >=20 > This doesn't change and kernel ABI's so then it is safe to apply to the > kernel without rebuilding user-land. >=20 > Future work could be to implement statvfs to return a longer path but > only do it for df/umount etc. The rest of the system could continue > with the existing statfs. mount works because it passed a string into > the kernel so it can be long. >=20 > I'd propose this as a current solution to this problem. It appears to > work well and shouldn't drastically break things. Doing df via the > full path, stat etc. work since the associated path access the vnode. > So things that do a mount, df of the mount point etc. should continue > to work. Scripts that try to figure out the mount points vi df and mount > displaying all mount points would fail. That is probably good enough for > now. >=20 > Comments welcomed. Generally, I agree with the approach, but what is done seems to be too simple to be usable. One obvious and important thing which is broken with the patch is the unmounts from jails. In other words, now it is possible to mount something from jail with appropriate privileges set up, and after that corresponding mount cannot be unmounted, since vfs_mount_alloc() copies trimmed path into f_mntonname, and sys_unmount() matches full path with pathbuf. Hmm, this should be broken in the same way for non-jailed mounts with pathes which do not fit into f_mntonname. I think that struct mount should have a const char * field where the non-trimmed path is stored and used for match at unmount. f_mntonname truncation would be only unfortunate user interface glitch. --0vFzRikYu/73UBJt Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJSh7oAAAoJEJDCuSvBvK1B/8QP/izzxCeGUxj94MJEfRZhG08X xNy2X5ZxLNO9m2iCa72648bzJxpnJvKiLijj4ZsVTC/vX5O3vOCtP1B6Kve86Xpe 6QqXLLQfSRQFVeAVBA2caH+eGveBbr/71ED1AnVgqY2a69FNhSVPj5YgHOjVcplr o17tv2/f4pUaKVTCH5Qlkypbcrz6CmlTjwj7Z/qRFddf9tObl75JGGfptaHg+Uhy ur/R+6vFVF+iKpjMTZmtMQT4pA8FqwfbCicgz+baIO19ie0h0eWZOLqe9rL4nK4/ 3B9Ux2PBd0y+CxbHg+TbEJfuWKish6FWJrT47Nzk4Wufs8y7R58Rm5EvGGRKokzZ P+HUUTWox1HayOpE4glQYhy1B2J/ABVmVD2iscFmyZHxFFzKNem1Q2PpZkpj4EaH yuj0B4RNqm/p9N0AKnyIzzd92Ouhf8Kx+k9HIbIpjBgQ1fGwk+ANnuBtIA65e/Af l1R4DtbglqNipcXxT49ahaI71uAQZCwgkoDSyyOXYWJHpqhRxblQsRdD4rYVreIb VQxATOJDAWvxZ8+ariz8vc9Tf+AFhsjGexvtC6bgVoKZqrh9WgbEjIo3zf1UuM6Q ynQGThMhDyTTXdxpXq1C6rvDSRzvflUMHQJn3ByjpWZlndki8nFX95R9CzzP21Vt /jfbVyPcUIWrkrNZ/aeA =FE3x -----END PGP SIGNATURE----- --0vFzRikYu/73UBJt--