From owner-freebsd-arch@FreeBSD.ORG Sun Feb 10 12:08:07 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 127CF457 for ; Sun, 10 Feb 2013 12:08:07 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id 87BEA96F for ; Sun, 10 Feb 2013 12:08:05 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.5/8.14.5) with ESMTP id r1AC82OO036048; Sun, 10 Feb 2013 06:08:02 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.5/8.14.5/Submit) id r1AC82L3036047; Sun, 10 Feb 2013 06:08:02 -0600 (CST) (envelope-from brooks) Date: Sun, 10 Feb 2013 06:08:02 -0600 From: Brooks Davis To: Diane Bruce Subject: Re: group(5) Group Passwords do not work Message-ID: <20130210120802.GD80454@lor.one-eyed-alien.net> References: <20130207232352.GA51387@night.db.net> <13CA24D6AB415D428143D44749F57D7201EA6244@ltcfiswmsgmb21> <20130208134718.GB62849@night.db.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="W5WqUoFLvi1M7tJE" Content-Disposition: inline In-Reply-To: <20130208134718.GB62849@night.db.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Teske, Devin" , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Feb 2013 12:08:07 -0000 --W5WqUoFLvi1M7tJE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 08, 2013 at 08:47:18AM -0500, Diane Bruce wrote: > On Fri, Feb 08, 2013 at 09:47:04AM +0000, Teske, Devin wrote: > > On Thu, 7 Feb 2013, Diane Bruce wrote: > >=20 > ... > >=20 > > It secretly does work -- but only for those willing to take the plunge = and: > >=20 > > WARNING: Not recommended unless you *must* have this functionality... > >=20 > > sudo chmod u+s /usr/bin/newgrp > >=20 > > NOTE: Assuming /usr/bin/newgrp is already owned by root > >=20 > > See newgrp(8) for additional details. >=20 > Indeed it will work if it is properly setuid root. The question was > whether we should further deprecate it or document it. ;) We should document the requirement to add u+s in older branches and deprecate it with the aim of removing it. It's only usable on single systems unless you are willing to put the hashes in NIS since there isn't the possibility of a group password in LDAP. Worse yet, it's probably only portable in practice with DES hashes which must be exposed to the user. Finally, even without the problem of the exposed hashes, any user (even nobody or www) can become a member of the group just by knowing the shared secret. Users who want this functionality are probably better served with sudo and a well designed sudoers configuration. It won't have exactly the same affordances, but the affordances of newgrp are terrible. -- Brooks --W5WqUoFLvi1M7tJE Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD8DBQFRF42hXY6L6fI4GtQRAqh3AKDh69pbch0NrSp1t/KQEHykwc+VPwCgj1P6 fRG3Oer+feQOCRlXAzsbH6U= =BY8R -----END PGP SIGNATURE----- --W5WqUoFLvi1M7tJE-- From owner-freebsd-arch@FreeBSD.ORG Mon Feb 11 09:50:12 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 36670ACA for ; Mon, 11 Feb 2013 09:50:12 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by mx1.freebsd.org (Postfix) with ESMTP id C93EC1781 for ; Mon, 11 Feb 2013 09:50:11 +0000 (UTC) Received: from mailout-de.gmx.net ([10.1.76.17]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0Lkmp0-1Uezea33My-00aWIP for ; Mon, 11 Feb 2013 10:50:04 +0100 Received: (qmail invoked by alias); 11 Feb 2013 09:50:04 -0000 Received: from p5B1326F3.dip.t-dialin.net (EHLO rotluchs.lokal) [91.19.38.243] by mail.gmx.net (mp017) with SMTP; 11 Feb 2013 10:50:04 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX188hzt3G948U/lJO1agqforfrE4JWWM5G2cbFXSoy i9EYD6wb+LRe/G Message-ID: <5118BEC9.1090708@gmx.de> Date: Mon, 11 Feb 2013 10:50:01 +0100 From: Christoph Mallon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130129 Thunderbird/17.0.2 MIME-Version: 1.0 To: Alfred Perlstein Subject: Re: Proposal: Unify printing the function name in panic messages() References: <51141E33.4080103@gmx.de> <511426B8.2070800@FreeBSD.org> <51160E06.1070404@gmx.de> <20130209195417.C1753@besplex.bde.org> <51161C10.9070002@gmx.de> <5116504A.7010409@mu.org> In-Reply-To: <5116504A.7010409@mu.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Kirk McKusick , freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 09:50:12 -0000 (Alfred accidently only replied to me.) On 09.02.2013 14:34, Alfred Perlstein wrote: > On 2/9/13 1:51 AM, Christoph Mallon wrote: >> As bde points out, optimisations interfere with location information gathered at runtime. >> Having the right name of the function in the panic, ensures that at least the starting point is right. >> My PANIC() macro guarantees exactly this. > > I like this fix, my only nit is asthetics. > > Would we just turn panic() into a macro instead of making PANIC() everywhere in the kernel? > > Too many uppercase macros are hard on the eyes. This is a good point. I will adjust the patches accordingly. Christoph From owner-freebsd-arch@FreeBSD.ORG Mon Feb 11 10:01:37 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 92B7ED99 for ; Mon, 11 Feb 2013 10:01:37 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by mx1.freebsd.org (Postfix) with ESMTP id 1B9BA1813 for ; Mon, 11 Feb 2013 10:01:36 +0000 (UTC) Received: from mailout-de.gmx.net ([10.1.76.10]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0M0NrX-1UucNZ0WLt-00uWGr for ; Mon, 11 Feb 2013 11:01:36 +0100 Received: (qmail invoked by alias); 11 Feb 2013 10:01:35 -0000 Received: from p5B1326F3.dip.t-dialin.net (EHLO rotluchs.lokal) [91.19.38.243] by mail.gmx.net (mp010) with SMTP; 11 Feb 2013 11:01:35 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX1+hHp8bqjqhJp57ZRetDSdvNnTRct5B/tN6gZMU3K ymp9NJuEKsVBGb Message-ID: <5118C17F.9020706@gmx.de> Date: Mon, 11 Feb 2013 11:01:35 +0100 From: Christoph Mallon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130129 Thunderbird/17.0.2 MIME-Version: 1.0 To: Andriy Gapon Subject: Re: Proposal: Unify printing the function name in panic messages() References: <51141E33.4080103@gmx.de> <511426B8.2070800@FreeBSD.org> <51160E06.1070404@gmx.de> <5116121E.1010601@FreeBSD.org> <511616AC.8080306@gmx.de> <511622A2.2090601@FreeBSD.org> <51166AD5.4090707@FreeBSD.org> In-Reply-To: <51166AD5.4090707@FreeBSD.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Chris Rees , freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 10:01:37 -0000 On 09.02.2013 16:27, Andriy Gapon wrote: > on 09/02/2013 12:46 Chris Rees said the following: >> OK, which tool can one find a panic message split across lines in source code? >> I would find this very useful. > > http://grok.x12.su/source/search?q=%22offset+below+first+LBA%22&project=freebsd > > Generally, I like opengrok very much. Pity that we don't have an official > server. fxr.watson.org is great, but opengrok is superior to glimpse. > E.g. try the same kind of search here: http://fxr.watson.org/fxr/search > > BTW, a local version (slower because no index is used): > $ pcregrep -r -M 'offset\W*below\W*first\W*LBA' sys/ > sys/geom/part/g_part.c: DPRINTF("partition %d has start offset > below first " > "LBA: %jd < %jd\n", e1->gpe_index, > pcregrep comes from devel/pcre. > > P.S. my first instinct was to try git grep first, git grep seems to support perl > regular expressions in general, but it looks like the port doesn't include the > necessary support: > fatal: cannot use Perl-compatible regexes when not compiled with USE_LIBPCRE > > P.P.S. I must say that I use textproc/glimpse (with index weekly updated via > cron) and in 99% of cases glimpse 'something' immediately returns useful > results. It's quite rare that I have to use other tools for searching the code. > I use vim + ctags too :-) Your suggestion is to replace a simple, automatic mechanism by several different tools, which require quite some manual fiddling. When showing the function name, your simple suggestion for using git grep works fine: [0] $EDITOR `git grep -Il "^$NAME("` Christoph [0] I use the following script for the general case "edit all files containing a pattern". I named it git-ed and git-ew, placed it in $PATH, so it can be used conveniently as git ed $PATTERN and git ew $PATTERN. It edits all files containing the given pattern, searches for the pattern und binds \ to find the pattern. #! /bin/sh set -eu PATTERN="$1" shift NAME="${0##*/}" case "$NAME" in git-ed) ;; git-ew) PATTERN="[[:<:]]$PATTERN[[:>:]]";; *) echo "$NAME: who am I?" >&2; exit 1;; esac VIPATTERN=$(echo "$PATTERN" | sed -e 's#\[\[:<:\]\]#\\<#g' -e 's#\[\[:>:\]\]#\\>#g') "$EDITOR" -c "map \\ /$VIPATTERN^M" -c "/$VIPATTERN" $(git grep -Il -e "$PATTERN" "$@") From owner-freebsd-arch@FreeBSD.ORG Mon Feb 11 10:16:08 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3403429C for ; Mon, 11 Feb 2013 10:16:08 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by mx1.freebsd.org (Postfix) with ESMTP id C638618C9 for ; Mon, 11 Feb 2013 10:16:07 +0000 (UTC) Received: from mailout-de.gmx.net ([10.1.76.10]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0M1Tap-1UtWF52JhZ-00tPWX for ; Mon, 11 Feb 2013 11:16:06 +0100 Received: (qmail invoked by alias); 11 Feb 2013 10:16:06 -0000 Received: from p5B1326F3.dip.t-dialin.net (EHLO rotluchs.lokal) [91.19.38.243] by mail.gmx.net (mp010) with SMTP; 11 Feb 2013 11:16:06 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX19uDuw2fUZuUhRPS/80VfqOpYxfwRsYf8zpJL2e+I PGt2XCprr/342k Message-ID: <5118C4E4.6020706@gmx.de> Date: Mon, 11 Feb 2013 11:16:04 +0100 From: Christoph Mallon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130129 Thunderbird/17.0.2 MIME-Version: 1.0 To: Andriy Gapon Subject: Re: Proposal: Unify printing the function name in panic messages() References: <51141E33.4080103@gmx.de> <511426B8.2070800@FreeBSD.org> <51160E06.1070404@gmx.de> <5116121E.1010601@FreeBSD.org> <511616AC.8080306@gmx.de> <511622A2.2090601@FreeBSD.org> In-Reply-To: <511622A2.2090601@FreeBSD.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Kirk McKusick , freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 10:16:08 -0000 On 09.02.2013 11:19, Andriy Gapon wrote: > on 09/02/2013 11:28 Christoph Mallon said the following: >> I do not understand, what the problem is. >> There are bugs and cumbersome code. >> This simple changes solves it. > > You conveniently omitted some questions of mine. > I'll reproduce them: > Well, have you experienced any problems with debugging due to those > (absent/misleading) function names? Or do you see many reports about such problems? I have dropped them, because they are not relevant. Though, I have answered them, but I'll rephrase it. There are many easily -- i.e., not needing any manual intervention -- avoidable bugs and inconsistencies in the code, which can be remedied by a simple change. Further, the change simplifies the user side of panic() a bit. Does bad code require a bug report to be fixed? If you think so, then just read "Proposal" in the topic as "Bug report and patch". > So I conclude that this is indeed a solution in search of a problem. > And that's exactly why i don't like it: > - a lot of lines changed for no good reason Incorrect information is corrected. Needlessly different ways to achieve the same thing are unified. panic calls are simplified a bit. > - code looks uglier / more obfuscated due to macro(s) As Alfred pointed out, we can just name it panic. Also the macro is quite similar to the typical assert macro in the way it automatically aggregates additional information. This does not obfuscate the code. > - no clear benefit, because there is no clear problem that needs solving See above. Christoph From owner-freebsd-arch@FreeBSD.ORG Mon Feb 11 16:06:07 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 72822D8E; Mon, 11 Feb 2013 16:06:07 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 49A8CB2C; Mon, 11 Feb 2013 16:06:07 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 1E28CB924; Mon, 11 Feb 2013 11:06:06 -0500 (EST) From: John Baldwin To: freebsd-arch@freebsd.org Subject: Re: Proposal: Unify printing the function name in panic messages() Date: Mon, 11 Feb 2013 11:05:57 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: <51141E33.4080103@gmx.de> <511622A2.2090601@FreeBSD.org> <5118C4E4.6020706@gmx.de> In-Reply-To: <5118C4E4.6020706@gmx.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201302111105.58186.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 11 Feb 2013 11:06:06 -0500 (EST) Cc: Kirk McKusick , Christoph Mallon , Andriy Gapon X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 16:06:07 -0000 On Monday, February 11, 2013 5:16:04 am Christoph Mallon wrote: > On 09.02.2013 11:19, Andriy Gapon wrote: > > on 09/02/2013 11:28 Christoph Mallon said the following: > >> I do not understand, what the problem is. > >> There are bugs and cumbersome code. > >> This simple changes solves it. > > > > You conveniently omitted some questions of mine. > > I'll reproduce them: > > Well, have you experienced any problems with debugging due to those > > (absent/misleading) function names? Or do you see many reports about such problems? > > I have dropped them, because they are not relevant. Eh, showing that there is an actual problem being solved rather than making a change gratuitously is highly relevant. You are the one arguing for a change so you have to make the case for why it is a good one. I for one would _really_ not like it if you are magically changing the format string for panics. I am in the process of writing in-kernel regression tests that rely on being able to "catch" panics via a modified try-catch model where the catches do simple string compares on the panic message. Adding a silent ("not visible in the code") prefix to each panic message makes this process more error prone. A sample test to show what I mean: /* Tests for spin mutexes. */ static int spin_recurse(void) { struct mtx m; bzero(&m, sizeof(m)); mtx_init(&m, "test spin", NULL, MTX_SPIN | MTX_RECURSE); mtx_lock_spin(&m); mtx_lock_spin(&m); mtx_unlock_spin(&m); mtx_unlock_spin(&m); mtx_destroy(&m); mtx_init(&m, "test spin", NULL, MTX_SPIN); mtx_lock_spin(&m); PANIC_TRY { mtx_lock_spin(&m); } PANIC_CATCH { IGNORE_PANIC_STARTS_WITH( "mtx_lock_spin: recursed on non-recursive mutex"); } PANIC_END; mtx_unlock_spin(&m); mtx_destroy(&m); return (TEST_OK); } UNIT_TEST("spin lock recurse", spin_recurse); Also, this is a case where your script will claim that the KASSERT() is "wrong" but in actual fact it is correct. The programmer is using mtx_lock_spin() and expects to see that in a panic message not __mtx_lock_spin_flags(). Only someone working with the implementation of spin locks should have to know about __mtx_lock_spin_flags(). For someone working on a device driver or other code, using "mtx_lock_spin" is more correct and far more useful. IOW, your changes will break just about every panic that is part of a macro where the macro is the public API and __func__ is not relevant. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Mon Feb 11 16:39:39 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2EFB7806 for ; Mon, 11 Feb 2013 16:39:39 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by mx1.freebsd.org (Postfix) with ESMTP id C8BD2DB7 for ; Mon, 11 Feb 2013 16:39:38 +0000 (UTC) Received: from mailout-de.gmx.net ([10.1.76.1]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MXkSn-1USOYt0G0t-00WmKw for ; Mon, 11 Feb 2013 17:39:32 +0100 Received: (qmail invoked by alias); 11 Feb 2013 16:39:31 -0000 Received: from p5B1326F3.dip.t-dialin.net (EHLO rotluchs.lokal) [91.19.38.243] by mail.gmx.net (mp001) with SMTP; 11 Feb 2013 17:39:31 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX1+VRTROvhuV9XQxsrIqt2WXzKyx+4BwQca3OhgcCp vSW7iCDZjClOTE Message-ID: <51191EC1.9000303@gmx.de> Date: Mon, 11 Feb 2013 17:39:29 +0100 From: Christoph Mallon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130129 Thunderbird/17.0.2 MIME-Version: 1.0 To: John Baldwin Subject: Re: Proposal: Unify printing the function name in panic messages() References: <51141E33.4080103@gmx.de> <511622A2.2090601@FreeBSD.org> <5118C4E4.6020706@gmx.de> <201302111105.58186.jhb@freebsd.org> In-Reply-To: <201302111105.58186.jhb@freebsd.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Kirk McKusick , Andriy Gapon , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 16:39:39 -0000 On 11.02.2013 17:05, John Baldwin wrote: > On Monday, February 11, 2013 5:16:04 am Christoph Mallon wrote: >> On 09.02.2013 11:19, Andriy Gapon wrote: >>> on 09/02/2013 11:28 Christoph Mallon said the following: >>>> I do not understand, what the problem is. >>>> There are bugs and cumbersome code. >>>> This simple changes solves it. >>> >>> You conveniently omitted some questions of mine. >>> I'll reproduce them: >>> Well, have you experienced any problems with debugging due to those >>> (absent/misleading) function names? Or do you see many reports about such problems? >> >> I have dropped them, because they are not relevant. > > Eh, showing that there is an actual problem being solved rather than making a > change gratuitously is highly relevant. You are the one arguing for a change > so you have to make the case for why it is a good one. I for one would _really_ I explained the reasons already multiple times. For example directly below the line the only line of my text, which you cited. > not like it if you are magically changing the format string for panics. I am > in the process of writing in-kernel regression tests that rely on being able to > "catch" panics via a modified try-catch model where the catches do simple > string compares on the panic message. Adding a silent ("not visible in the > code") prefix to each panic message makes this process more error prone. This was already handled: Just do not set NAMED_PANIC. > A sample test to show what I mean: > > /* Tests for spin mutexes. */ > > static int > spin_recurse(void) > { > struct mtx m; > > bzero(&m, sizeof(m)); > mtx_init(&m, "test spin", NULL, MTX_SPIN | MTX_RECURSE); > mtx_lock_spin(&m); > mtx_lock_spin(&m); > mtx_unlock_spin(&m); > mtx_unlock_spin(&m); > mtx_destroy(&m); > > mtx_init(&m, "test spin", NULL, MTX_SPIN); > mtx_lock_spin(&m); > PANIC_TRY { > mtx_lock_spin(&m); > } PANIC_CATCH { > IGNORE_PANIC_STARTS_WITH( > "mtx_lock_spin: recursed on non-recursive mutex"); > } PANIC_END; > mtx_unlock_spin(&m); > mtx_destroy(&m); > return (TEST_OK); > } > UNIT_TEST("spin lock recurse", spin_recurse); > > Also, this is a case where your script will claim that the KASSERT() is > "wrong" but in actual fact it is correct. The programmer is using KASSERT? My script? I never did a script for KASSERT. > mtx_lock_spin() and expects to see that in a panic message not > __mtx_lock_spin_flags(). Only someone working with the implementation of > spin locks should have to know about __mtx_lock_spin_flags(). For someone > working on a device driver or other code, using "mtx_lock_spin" is more > correct and far more useful. IOW, your changes will break just about For these extremely rare cases, you can still directly call panic(). The vast majority simply wants the name of the current function. Also, for the mutex stuff a lot of pointless indirection seems to be going on: E.g. the macro _mtx_unlock_flags and several of its brothers only have a single user each. > every panic that is part of a macro where the macro is the public API and > __func__ is not relevant. Macros using panic already use __func__ (or worse: __FUNCTION__) or do not print a name currently. Christoph From owner-freebsd-arch@FreeBSD.ORG Mon Feb 11 20:26:11 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B39C783E; Mon, 11 Feb 2013 20:26:11 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-vb0-f49.google.com (mail-vb0-f49.google.com [209.85.212.49]) by mx1.freebsd.org (Postfix) with ESMTP id 270CCB91; Mon, 11 Feb 2013 20:26:10 +0000 (UTC) Received: by mail-vb0-f49.google.com with SMTP id s24so3994100vbi.8 for ; Mon, 11 Feb 2013 12:26:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=WE+FRVRzDHJQQCsKL+WNEIvwSv54sw7mP4rLVolaOoc=; b=ZytKT04MsRwG+0hP404mddf9j4o36rLIFhDwanBZzx7L76yM6TnjvUyxmI+Bn0R6CA LauDUVAd8RYrQA2I0tzFIiHk2XAr+nutM7tx1dOZvrXcBWuslK50z7XHopx7k8hsDaAT TS4CPy42H7t4CjoWLlX1zzrQRwPFOFEkpUkjdhGPnswe/jjfK2EJ8ckSCMRuOR49d27E PoISuCUoGBiuBdGJCaPW/gin5WAZag/jaDzBanExzxjMhtTyuCSTkW6HsJxchm3qhXl3 4wTUEbU2ne9mRGv3dI7mezCryOll5KNYxJbJDz/8ggaOCknp2J+HNDI9iyHHitMaKxCF R5xw== MIME-Version: 1.0 X-Received: by 10.52.177.103 with SMTP id cp7mr17781704vdc.113.1360614369927; Mon, 11 Feb 2013 12:26:09 -0800 (PST) Sender: davide.italiano@gmail.com Received: by 10.220.114.134 with HTTP; Mon, 11 Feb 2013 12:26:09 -0800 (PST) In-Reply-To: <20130121095457.GL85306@alchemy.franken.de> References: <50CCAB99.4040308@FreeBSD.org> <50CE5B54.3050905@FreeBSD.org> <50D03173.9080904@FreeBSD.org> <20121225232126.GA47692@alchemy.franken.de> <50DB4EFE.2020600@FreeBSD.org> <20130106152313.GD26039@alchemy.franken.de> <50EBF921.2000304@FreeBSD.org> <20130113180940.GM26039@alchemy.franken.de> <50F30CAB.3000001@FreeBSD.org> <20130121095457.GL85306@alchemy.franken.de> Date: Mon, 11 Feb 2013 21:26:09 +0100 X-Google-Sender-Auth: Ht3NmV0IG4QOr9i4yloaFI5f1mY Message-ID: Subject: Re: [RFC/RFT] calloutng From: Davide Italiano To: Marius Strobl Content-Type: text/plain; charset=ISO-8859-1 Cc: Alexander Motin , FreeBSD Current , Poul-Henning Kamp , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 20:26:11 -0000 [trimmed old mails] Here's a new version of the patch: http://people.freebsd.org/~davide/patches/calloutng-11022012.diff Significant bits changed (after wider discussion and suggestion by phk@): - Introduction of the new sbintime_t type (32.32 fixed point) with the respective conversion (sbintime2bintime, sbintime2timeval etc...) - switch from 64.64 (struct bintime) format to measure time to sbintime_t - Use sbintime_t to represent expected sleep time instead of measuring it in microseconds (cpu_idle_acpi(), cpu_idle_spin() ...). Thanks, Davide From owner-freebsd-arch@FreeBSD.ORG Mon Feb 11 21:09:45 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 89AF952C for ; Mon, 11 Feb 2013 21:09:45 +0000 (UTC) (envelope-from gad@FreeBSD.org) Received: from smtp7.server.rpi.edu (smtp7.server.rpi.edu [128.113.2.227]) by mx1.freebsd.org (Postfix) with ESMTP id 4E222E2F for ; Mon, 11 Feb 2013 21:09:45 +0000 (UTC) Received: from gilead.netel.rpi.edu (gilead.netel.rpi.edu [128.113.124.121]) by smtp7.server.rpi.edu (8.13.1/8.13.1) with ESMTP id r1BJwhSU025621; Mon, 11 Feb 2013 14:58:43 -0500 Message-ID: <51194D73.2010804@FreeBSD.org> Date: Mon, 11 Feb 2013 14:58:43 -0500 From: Garance A Drosehn User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Christoph Mallon Subject: Re: Proposal: Unify printing the function name in panic messages() References: <51141E33.4080103@gmx.de> In-Reply-To: <51141E33.4080103@gmx.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0) X-RPI-SA-Score: 0.10 () [Hold at 11.00] COMBINED_FROM X-CanItPRO-Stream: outgoing X-Canit-Stats-ID: 57036054 - 00adcdc2efb1 X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.113.2.227 Cc: Kirk McKusick , freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 21:09:45 -0000 On 2/7/13 4:35 PM, Christoph Mallon wrote: > > currently the style for printing panic messages varies greatly. > Here are some examples of the most common styles: > panic("just a message"); > panic("function_name: message"); > panic("wrong_function_name: message"); > panic("%s: message", __func__); > Especially the third -- a wrong function name being shown -- is annoying > and quite common. I propose a simple macro, which wraps panic() and > ensures that the right name is shown always by using __func__. > Do you have suggestions to improve this proposal? > > Chrsopth While I'm replying to the first message in the thread, I've read most of the messages up to this point. I do very little development in the kernel, but as it happens I've spent the last three weeks untangling a somewhat large C-based project which has similar messages, and due to the nature of the project it's nearly impossible to run debuggers on it. So I can't just pop into the debugger and get some kind of stack trace. That project uses __func__ on some printf()s, and __FILE__ on others. I found it quite useful there. When tracking down a few specific bugs there were multiple places which could generate the error message I was looking for, so I added __LINE__ to those printf()s. This was helpful, particularly in one case where the entire message was specified as a constant string in one place, but the same error *could* be printed out by a different printf which built the message via format specifiers. So scanning for the message would pick up the first case as an obvious hit, and never notice the second case. And, of course, it turned out that the message in my log file was coming from that second case. So maybe it'd be good to have two panic options. One with the __LINE__ number, and one without. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-arch@FreeBSD.ORG Mon Feb 11 21:12:09 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D243A8F2; Mon, 11 Feb 2013 21:12:09 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 7C259E63; Mon, 11 Feb 2013 21:12:09 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 79576B9A6; Mon, 11 Feb 2013 16:12:08 -0500 (EST) From: John Baldwin To: Christoph Mallon Subject: Re: Proposal: Unify printing the function name in panic messages() Date: Mon, 11 Feb 2013 12:03:19 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: <51141E33.4080103@gmx.de> <201302111105.58186.jhb@freebsd.org> <51191EC1.9000303@gmx.de> In-Reply-To: <51191EC1.9000303@gmx.de> MIME-Version: 1.0 Message-Id: <201302111203.19422.jhb@freebsd.org> Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 11 Feb 2013 16:12:08 -0500 (EST) Cc: Kirk McKusick , Andriy Gapon , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 21:12:09 -0000 On Monday, February 11, 2013 11:39:29 am Christoph Mallon wrote: > On 11.02.2013 17:05, John Baldwin wrote: > > On Monday, February 11, 2013 5:16:04 am Christoph Mallon wrote: > >> On 09.02.2013 11:19, Andriy Gapon wrote: > >>> on 09/02/2013 11:28 Christoph Mallon said the following: > >>>> I do not understand, what the problem is. > >>>> There are bugs and cumbersome code. > >>>> This simple changes solves it. > >>> > >>> You conveniently omitted some questions of mine. > >>> I'll reproduce them: > >>> Well, have you experienced any problems with debugging due to those > >>> (absent/misleading) function names? Or do you see many reports about such problems? > >> > >> I have dropped them, because they are not relevant. > > > > Eh, showing that there is an actual problem being solved rather than making a > > change gratuitously is highly relevant. You are the one arguing for a change > > so you have to make the case for why it is a good one. I for one would _really_ > > I explained the reasons already multiple times. > For example directly below the line the only line of my text, which you cited. I have yet to see a single specific instance where _you_ have been unable to debug a panic due to the function name not being present or not matching. It is all hypothetical so far. > > not like it if you are magically changing the format string for panics. I am > > in the process of writing in-kernel regression tests that rely on being able to > > "catch" panics via a modified try-catch model where the catches do simple > > string compares on the panic message. Adding a silent ("not visible in the > > code") prefix to each panic message makes this process more error prone. > > This was already handled: > Just do not set NAMED_PANIC. Then it cannot be set by default (regression tests should work out of the box), so it won't make any difference for users reporting bugs, so why have it? > > A sample test to show what I mean: > > > > /* Tests for spin mutexes. */ > > > > static int > > spin_recurse(void) > > { > > struct mtx m; > > > > bzero(&m, sizeof(m)); > > mtx_init(&m, "test spin", NULL, MTX_SPIN | MTX_RECURSE); > > mtx_lock_spin(&m); > > mtx_lock_spin(&m); > > mtx_unlock_spin(&m); > > mtx_unlock_spin(&m); > > mtx_destroy(&m); > > > > mtx_init(&m, "test spin", NULL, MTX_SPIN); > > mtx_lock_spin(&m); > > PANIC_TRY { > > mtx_lock_spin(&m); > > } PANIC_CATCH { > > IGNORE_PANIC_STARTS_WITH( > > "mtx_lock_spin: recursed on non-recursive mutex"); > > } PANIC_END; > > mtx_unlock_spin(&m); > > mtx_destroy(&m); > > return (TEST_OK); > > } > > UNIT_TEST("spin lock recurse", spin_recurse); > > > > Also, this is a case where your script will claim that the KASSERT() is > > "wrong" but in actual fact it is correct. The programmer is using > > KASSERT? My script? I never did a script for KASSERT. Then it's a broken script as that is a large number of panic invocations. :) If you haven't even looked at the KASSERT()'s in the tree then you haven't really looked at the range of panic messages used. > > mtx_lock_spin() and expects to see that in a panic message not > > __mtx_lock_spin_flags(). Only someone working with the implementation of > > spin locks should have to know about __mtx_lock_spin_flags(). For someone > > working on a device driver or other code, using "mtx_lock_spin" is more > > correct and far more useful. IOW, your changes will break just about > > For these extremely rare cases, you can still directly call panic(). Not if you redefine 'panic()' to always include the prefix as your most recent e-mails suggest you will do based on feedback from Alfred. > The vast majority simply wants the name of the current function. > Also, for the mutex stuff a lot of pointless indirection seems to be going on: > E.g. the macro _mtx_unlock_flags and several of its brothers only have a single user each. They are not pointless. It is a matter of providing a stable ABI for modules while still inlining in the kernel (in the non-debug case). > > every panic that is part of a macro where the macro is the public API and > > __func__ is not relevant. > > Macros using panic already use __func__ (or worse: __FUNCTION__) or do not print a name currently. Not if they use an explicit function name that you deem to be a "wrong" function name. That is the case you will break. That is, if your script were fixed to handle KASSERT, would it not "fix" the above panic to use the internal function name thus making it less useful for developers as I asserted? Can't you see that this is a flaw in your reasoning where you assume the raw function name is always the correct prefix, but in fact it may not be? -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Mon Feb 11 21:20:02 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 264D8CA2; Mon, 11 Feb 2013 21:20:02 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by mx1.freebsd.org (Postfix) with ESMTP id 726D2EDB; Mon, 11 Feb 2013 21:20:01 +0000 (UTC) Received: by mail-we0-f172.google.com with SMTP id x10so5331575wey.3 for ; Mon, 11 Feb 2013 13:20:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=S5opBg+X2FXm6wLdS0+cded06RCC9N5JJ2QjwsEHs+4=; b=JEGWsFaccDrQTIG3i+qOri3u7K1M3fbWQm2jjZ46z/T1/JdjYymrXyj4LYUoJPKjUd z4TZ9X9Qqs+ym3crxkBFyMy9V7YWx/+ktpLcAm447E9Lam9i+u6v4rvrXuOC5JE+L9lL FJyOh4jkXQogH/HFNovraDyg0p8D6aQGwzFP1Xks31Vhy3KAlA9Wr3KBBEmKSGUCXaQU kLJWJaGYq2RoeZI46JrOoaIdmWXXdNvEqmkHJwRdhkP9P6XLXCJL1tzvDF4wYDGPfdgW JfXgL3uQ2f+W0NTvg1ynCeRcgVCf8qSW5sW/km36ge47rZrVAAU84FETLs/3uIFeqSUO FBFQ== MIME-Version: 1.0 X-Received: by 10.181.12.103 with SMTP id ep7mr18561029wid.12.1360617600614; Mon, 11 Feb 2013 13:20:00 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.236.88 with HTTP; Mon, 11 Feb 2013 13:20:00 -0800 (PST) In-Reply-To: <201302111203.19422.jhb@freebsd.org> References: <51141E33.4080103@gmx.de> <201302111105.58186.jhb@freebsd.org> <51191EC1.9000303@gmx.de> <201302111203.19422.jhb@freebsd.org> Date: Mon, 11 Feb 2013 13:20:00 -0800 X-Google-Sender-Auth: XPYbVAyqHtXGhOcwlNj-V62T1Qg Message-ID: Subject: Re: Proposal: Unify printing the function name in panic messages() From: Adrian Chadd To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: Kirk McKusick , Christoph Mallon , Andriy Gapon , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 21:20:02 -0000 Whoa, whoa. Are you seriously trying to argue that having a consistent file:line isn't a really helpful addition to panic messages? Yes, you can get it via the crash IP and use of binutils on the kernel image. But with modules? You have to fire up kgdb, and that requires a dump _and_ a kgdb that matches the kernel image in question. Even if you don't add it to the panic message, having that information passed into panic() so it can print out a file:line would be great. Adrian From owner-freebsd-arch@FreeBSD.ORG Tue Feb 12 00:27:08 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B3C03E5A; Tue, 12 Feb 2013 00:27:08 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 4B8D38F9; Tue, 12 Feb 2013 00:27:07 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.5/8.14.5/ALCHEMY.FRANKEN.DE) with ESMTP id r1C0Qxj1022864; Tue, 12 Feb 2013 01:27:00 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.5/8.14.5/Submit) id r1C0QxHi022863; Tue, 12 Feb 2013 01:26:59 +0100 (CET) (envelope-from marius) Date: Tue, 12 Feb 2013 01:26:59 +0100 From: Marius Strobl To: Konstantin Belousov Subject: Re: Physbio changes final call for tests and reviews Message-ID: <20130212002659.GA22851@alchemy.franken.de> References: <20130202163322.GA2522@kib.kiev.ua> <20130202214709.GA99418@alchemy.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130202214709.GA99418@alchemy.franken.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: powerpc@freebsd.org, mips@freebsd.org, current@freebsd.org, jeff@freebsd.org, ia64@freebsd.org, arch@freebsd.org, sparc64@freebsd.org, arm@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 00:27:08 -0000 On Sat, Feb 02, 2013 at 10:47:09PM +0100, Marius Strobl wrote: > On Sat, Feb 02, 2013 at 06:33:22PM +0200, Konstantin Belousov wrote: > > Hi, > > I finished the last (insignificant) missed bits in the Jeff' physbio > > work. Now I am asking for the last round of testing and review, esp. for > > the !x86 architectures. Another testing focus are the SCSI HBAs and RAID > > controllers which drivers are changed by the patchset. Please do test > > this before the patchset is committed into HEAD ! > > > > The plan is to commit the patch somewhere in two weeks from this moment. > > The patch is required for the finalizing of the unmapped I/O work for UFS > > I did in parallel, which I hope to finish shortly after the commit. > > > > Patch is available at http://people.freebsd.org/~kib/misc/physbio.5.diff > > > > First tests on sparc64 with ata(4), mpt(4) and sym(4) look good (to > be sure I still need to test with a machine using a streaming buffer > in addition to the IOMMU, though). FYI, the latter case is also fine. Marius From owner-freebsd-arch@FreeBSD.ORG Tue Feb 12 01:34:43 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 45DFDA73; Tue, 12 Feb 2013 01:34:43 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (chez.mckusick.com [IPv6:2001:5a8:4:7e72:4a5b:39ff:fe12:452]) by mx1.freebsd.org (Postfix) with ESMTP id 1EB7EB27; Tue, 12 Feb 2013 01:34:43 +0000 (UTC) Received: from chez.mckusick.com (localhost [127.0.0.1]) by chez.mckusick.com (8.14.3/8.14.3) with ESMTP id r1C1Ycfh026347; Mon, 11 Feb 2013 17:34:39 -0800 (PST) (envelope-from mckusick@chez.mckusick.com) Message-Id: <201302120134.r1C1Ycfh026347@chez.mckusick.com> To: John Baldwin Subject: Re: Proposal: Unify printing the function name in panic messages() In-reply-to: Date: Mon, 11 Feb 2013 17:34:38 -0800 From: Kirk McKusick X-Spam-Status: No, score=0.0 required=5.0 tests=MISSING_MID, UNPARSEABLE_RELAY autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on chez.mckusick.com Cc: Adrian Chadd , Christoph Mallon , Andriy Gapon , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 01:34:43 -0000 I have recently gone down several ratholes trying to understand a panic message which had the wrong function name (prefix ufs1_ instead of ufs2_). I can definitely say that it matters to me. And I think that fixing the problem as Christoph has outlined will be a big step in the right direction. John, in your code you cannot expect to match the entire panic string if it has any % formats in it. So to be useful, you must be able to work with a constant subset of the string. The addition of other information such as a function name at the start should not affect that constant part that you are trying to match. Though a bit ugly, I do think that the change should use "PANIC" rather than overloading "panic". First, it lets the feature be introduced over time rather than requiring that every panic be changed at once. And, it allows historic panic's to work as expected. Finally, having it as a macro means that folks can readily and consistently add file and/or line numbers to panic messages if they wish to do so. Summary: I think that this is an excellent idea that will both help in finding the location of panic errors and also will allow folks trying to minimize kernel size to do so by cutting out the overhead. Kirk McKusick From owner-freebsd-arch@FreeBSD.ORG Tue Feb 12 03:56:52 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 116A3CE4; Tue, 12 Feb 2013 03:56:52 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail.karels.net (mail.karels.net [IPv6:2001:470:c004::5]) by mx1.freebsd.org (Postfix) with ESMTP id C3240B8; Tue, 12 Feb 2013 03:56:51 +0000 (UTC) Received: from mail.karels.net (localhost [127.0.0.1]) by mail.karels.net (8.14.5/8.14.5) with ESMTP id r1C3W9i3005646; Mon, 11 Feb 2013 21:32:09 -0600 (CST) (envelope-from mike@karels.net) Message-Id: <201302120332.r1C3W9i3005646@mail.karels.net> To: Kirk McKusick From: Mike Karels Subject: Re: Proposal: Unify printing the function name in panic messages() In-reply-to: Your message of Mon, 11 Feb 2013 17:34:38 -0800. <201302120134.r1C1Ycfh026347@chez.mckusick.com> Date: Mon, 11 Feb 2013 21:32:09 -0600 Cc: Adrian Chadd , Christoph Mallon , Andriy Gapon , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: mike@karels.net List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 03:56:52 -0000 > I have recently gone down several ratholes trying to understand a > panic message which had the wrong function name (prefix ufs1_ instead > of ufs2_). I can definitely say that it matters to me. And I think > that fixing the problem as Christoph has outlined will be a big > step in the right direction. > John, in your code you cannot expect to match the entire panic > string if it has any % formats in it. So to be useful, you must be > able to work with a constant subset of the string. The addition of > other information such as a function name at the start should not > affect that constant part that you are trying to match. > Though a bit ugly, I do think that the change should use "PANIC" > rather than overloading "panic". First, it lets the feature be > introduced over time rather than requiring that every panic be > changed at once. And, it allows historic panic's to work as expected. > Finally, having it as a macro means that folks can readily and > consistently add file and/or line numbers to panic messages if they > wish to do so. > Summary: I think that this is an excellent idea that will both help > in finding the location of panic errors and also will allow folks > trying to minimize kernel size to do so by cutting out the overhead. I don't think that the proposal is to introduce this feature over time, but instead to mechanically change as many instances as possible. However, if I understand correctly, that would include primarily the instances now using the function name "correctly", not those using the wrong function name. I really don't want to see the kernel half-converted from panic() to PANIC(). I'd rather see lower-case panic as an available macro depending on a kernel option. However, as John notes, this option is of reduced utility if it isn't on by default, and I don't see sufficient reason to turn it on by default. Perhaps I haven't spent as much time looking at the wrong function for panics that have been cloned badly, but I tend to use glimpse if I don't know where the panic is coming from. It seems to me that a script looking for duplicate panic strings would solve the real problem much more quickly. Mike From owner-freebsd-arch@FreeBSD.ORG Tue Feb 12 04:33:36 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2E2DC3CF; Tue, 12 Feb 2013 04:33:36 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (chez.mckusick.com [IPv6:2001:5a8:4:7e72:4a5b:39ff:fe12:452]) by mx1.freebsd.org (Postfix) with ESMTP id 057871D4; Tue, 12 Feb 2013 04:33:35 +0000 (UTC) Received: from chez.mckusick.com (localhost [127.0.0.1]) by chez.mckusick.com (8.14.3/8.14.3) with ESMTP id r1C4XXrx064843; Mon, 11 Feb 2013 20:33:33 -0800 (PST) (envelope-from mckusick@chez.mckusick.com) Message-Id: <201302120433.r1C4XXrx064843@chez.mckusick.com> To: mike@karels.net Subject: Re: Proposal: Unify printing the function name in panic messages() In-reply-to: <201302120332.r1C3W9i3005646@mail.karels.net> Date: Mon, 11 Feb 2013 20:33:33 -0800 From: Kirk McKusick X-Spam-Status: No, score=0.0 required=5.0 tests=MISSING_MID, UNPARSEABLE_RELAY autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on chez.mckusick.com Cc: Adrian Chadd , Christoph Mallon , Andriy Gapon , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 04:33:36 -0000 I have having difficulty understanding the resistance to bringing consistency to something that badly lacks it now. Along with the ability to get rid of the extra space when needed or to add to it when desired. The arguement that it is crap, but who cares because we can work around it when we have someone offering to do the not insignificant work to clean it up seems out of character with our vision of a clean code base. Kirk McKusick From owner-freebsd-arch@FreeBSD.ORG Tue Feb 12 06:10:16 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B1EE5259; Tue, 12 Feb 2013 06:10:16 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail.karels.net (mail.karels.net [IPv6:2001:470:c004::5]) by mx1.freebsd.org (Postfix) with ESMTP id 7AEE1691; Tue, 12 Feb 2013 06:10:16 +0000 (UTC) Received: from mail.karels.net (localhost [127.0.0.1]) by mail.karels.net (8.14.5/8.14.5) with ESMTP id r1C617Q9006038; Tue, 12 Feb 2013 00:01:07 -0600 (CST) (envelope-from mike@karels.net) Message-Id: <201302120601.r1C617Q9006038@mail.karels.net> To: Kirk McKusick From: Mike Karels Subject: Re: Proposal: Unify printing the function name in panic messages() In-reply-to: Your message of Mon, 11 Feb 2013 20:33:33 -0800. <201302120433.r1C4XXrx064843@chez.mckusick.com> Date: Tue, 12 Feb 2013 00:01:07 -0600 Cc: Adrian Chadd , Christoph Mallon , Andriy Gapon , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: mike@karels.net List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 06:10:16 -0000 > I have having difficulty understanding the resistance to bringing > consistency to something that badly lacks it now. Along with the > ability to get rid of the extra space when needed or to add to it > when desired. The arguement that it is crap, but who cares because > we can work around it when we have someone offering to do the not > insignificant work to clean it up seems out of character with our > vision of a clean code base. I'm not arguing against consistency, nor even agaist the proposal itself (as modified for a lower-case panic macro). However, I don't think the lack of consistency is the real problem. "panic: watchdog timeout" tells me what I need to know, whether or not it includes "watchdog_fire" or the line number. The only problem that has been pointed out is lack of uniqueness. That is a simpler problem to handle, and isn't handled by the current proposal as I understand it. Mike From owner-freebsd-arch@FreeBSD.ORG Tue Feb 12 06:15:55 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 738AD333; Tue, 12 Feb 2013 06:15:55 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (chez.mckusick.com [IPv6:2001:5a8:4:7e72:4a5b:39ff:fe12:452]) by mx1.freebsd.org (Postfix) with ESMTP id 4DE366B1; Tue, 12 Feb 2013 06:15:55 +0000 (UTC) Received: from chez.mckusick.com (localhost [127.0.0.1]) by chez.mckusick.com (8.14.3/8.14.3) with ESMTP id r1C6FpP8086860; Mon, 11 Feb 2013 22:15:52 -0800 (PST) (envelope-from mckusick@chez.mckusick.com) Message-Id: <201302120615.r1C6FpP8086860@chez.mckusick.com> To: mike@karels.net Subject: Re: Proposal: Unify printing the function name in panic messages() In-reply-to: <201302120601.r1C617Q9006038@mail.karels.net> Date: Mon, 11 Feb 2013 22:15:51 -0800 From: Kirk McKusick X-Spam-Status: No, score=0.0 required=5.0 tests=MISSING_MID, UNPARSEABLE_RELAY autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on chez.mckusick.com Cc: Adrian Chadd , Christoph Mallon , Andriy Gapon , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 06:15:55 -0000 > To: Kirk McKusick > cc: John Baldwin , Adrian Chadd , > Christoph Mallon , > Andriy Gapon , freebsd-arch@freebsd.org > From: Mike Karels > Subject: Re: Proposal: Unify printing the function name in panic messages() > Date: Tue, 12 Feb 2013 00:01:07 -0600 > > I'm not arguing against consistency, nor even agaist the proposal itself > (as modified for a lower-case panic macro). However, I don't think the > lack of consistency is the real problem. "panic: watchdog timeout" tells > me what I need to know, whether or not it includes "watchdog_fire" or the > line number. The only problem that has been pointed out is lack of > uniqueness. That is a simpler problem to handle, and isn't handled by > the current proposal as I understand it. > > Mike Though the default for the current proposal gives just the function name, in its verbose mode it give file, function, and line number. And in its lean and mean mode, just the error string. This replacing the hodge-podge that we have now. My main point is that it is a significant improvement over what we have now. Kirk From owner-freebsd-arch@FreeBSD.ORG Tue Feb 12 06:32:53 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 16BC0516 for ; Tue, 12 Feb 2013 06:32:53 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by mx1.freebsd.org (Postfix) with ESMTP id 85080729 for ; Tue, 12 Feb 2013 06:32:52 +0000 (UTC) Received: from mailout-de.gmx.net ([10.1.76.34]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0Mb5SX-1UKlQm1mIt-00KdaS for ; Tue, 12 Feb 2013 07:32:51 +0100 Received: (qmail invoked by alias); 12 Feb 2013 06:32:50 -0000 Received: from p5B13243E.dip.t-dialin.net (EHLO rotluchs.lokal) [91.19.36.62] by mail.gmx.net (mp034) with SMTP; 12 Feb 2013 07:32:50 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX18gcyNtmTYgY45IfZ9hIlEdN+VdVZ1OeDOnDSxs6z yXiim2JpRjbOcI Message-ID: <5119E20A.4010902@gmx.de> Date: Tue, 12 Feb 2013 07:32:42 +0100 From: Christoph Mallon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130129 Thunderbird/17.0.2 MIME-Version: 1.0 To: mike@karels.net Subject: Re: Proposal: Unify printing the function name in panic messages() References: <201302120601.r1C617Q9006038@mail.karels.net> In-Reply-To: <201302120601.r1C617Q9006038@mail.karels.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Kirk McKusick , Adrian Chadd , Andriy Gapon , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 06:32:53 -0000 On 12.02.2013 07:01, Mike Karels wrote: >> I have having difficulty understanding the resistance to bringing >> consistency to something that badly lacks it now. Along with the >> ability to get rid of the extra space when needed or to add to it >> when desired. The arguement that it is crap, but who cares because >> we can work around it when we have someone offering to do the not >> insignificant work to clean it up seems out of character with our >> vision of a clean code base. > > I'm not arguing against consistency, nor even agaist the proposal itself > (as modified for a lower-case panic macro). However, I don't think the > lack of consistency is the real problem. "panic: watchdog timeout" tells > me what I need to know, whether or not it includes "watchdog_fire" or the > line number. The only problem that has been pointed out is lack of > uniqueness. The only problem? Wrong information is no problem? > That is a simpler problem to handle, and isn't handled by > the current proposal as I understand it. How does adding the function name (or by extension the file name and line number) not make it unique (almost unique for the function name)? Also, this seems to be a case of scope creep: I want to make the use of panic - simpler, by not having to manually maintain the function name, which the compiler can do better and you do not have to type anything at all - consistent, whereas currently there are about a dozen styles how to cram location info into panic messages - and remove some existing bugs As nice bonus, the change also provides a base for further improvements by using a macro PANIC instead of a plain function. But this is not the main goal, the points before are. I went for the plain function name, instead of file+line, because this is, what the majority of panic calls do. Christoph From owner-freebsd-arch@FreeBSD.ORG Tue Feb 12 09:11:04 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0D3A89B4; Tue, 12 Feb 2013 09:11:04 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id C9175EC5; Tue, 12 Feb 2013 09:11:03 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 999718A525; Tue, 12 Feb 2013 09:10:56 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id r1C9AsK7020904; Tue, 12 Feb 2013 09:10:55 GMT (envelope-from phk@phk.freebsd.dk) To: Kirk McKusick Subject: Re: Proposal: Unify printing the function name in panic messages() In-reply-to: <201302120433.r1C4XXrx064843@chez.mckusick.com> From: "Poul-Henning Kamp" References: <201302120433.r1C4XXrx064843@chez.mckusick.com> Date: Tue, 12 Feb 2013 09:10:54 +0000 Message-ID: <20903.1360660254@critter.freebsd.dk> Cc: Adrian Chadd , Christoph Mallon , Andriy Gapon , mike@karels.net, freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 09:11:04 -0000 Content-Type: text/plain; charset=ISO-8859-1 -------- In message <201302120433.r1C4XXrx064843@chez.mckusick.com>, Kirk McKusick write s: >I have having difficulty understanding the resistance to bringing >consistency to something that badly lacks it now. I have no such difficulty: http://bikeshed.org -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Tue Feb 12 09:23:49 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8A0FFB6B; Tue, 12 Feb 2013 09:23:49 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 36AA2F2B; Tue, 12 Feb 2013 09:23:48 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 37C0E655B; Tue, 12 Feb 2013 09:23:42 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 035F1A272; Tue, 12 Feb 2013 10:23:41 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Mehmet Erol Sanliturk Subject: Re: Proposal: Unify printing the function name in panic messages() References: <51141E33.4080103@gmx.de> <511426B8.2070800@FreeBSD.org> <51160E06.1070404@gmx.de> <5116121E.1010601@FreeBSD.org> Date: Tue, 12 Feb 2013 10:23:41 +0100 In-Reply-To: (Mehmet Erol Sanliturk's message of "Sat, 9 Feb 2013 01:38:20 -0800") Message-ID: <86fw11homa.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Kirk McKusick , Christoph Mallon , Andriy Gapon , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 09:23:49 -0000 Mehmet Erol Sanliturk writes: > During 1980 years we were using a Burroughs 6700 main frame. Its > Fortran compiler produced code was generating a call stack trace on > run time errors [...] A similar structure may be used for FreeBSD > parts generated during compilation when a compiler switch is set. You mean like we've been doing the last 20 years? DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Tue Feb 12 09:28:38 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D7986D73 for ; Tue, 12 Feb 2013 09:28:38 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 9BA38F7D for ; Tue, 12 Feb 2013 09:28:38 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id C369C6568; Tue, 12 Feb 2013 09:28:37 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 8D259A274; Tue, 12 Feb 2013 10:28:37 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Christoph Mallon Subject: Re: Proposal: Unify printing the function name in panic messages() References: <51141E33.4080103@gmx.de> <511426B8.2070800@FreeBSD.org> <51160E06.1070404@gmx.de> <20130209195417.C1753@besplex.bde.org> <51161C10.9070002@gmx.de> <5116504A.7010409@mu.org> <5118BEC9.1090708@gmx.de> Date: Tue, 12 Feb 2013 10:28:37 +0100 In-Reply-To: <5118BEC9.1090708@gmx.de> (Christoph Mallon's message of "Mon, 11 Feb 2013 10:50:01 +0100") Message-ID: <86bobphoe2.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Kirk McKusick , Alfred Perlstein , freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 09:28:38 -0000 Christoph Mallon writes: > Alfred Perlstein writes: > > Would we just turn panic() into a macro instead of making PANIC() > > everywhere in the kernel? Too many uppercase macros are hard on the > > eyes. > This is a good point. I will adjust the patches accordingly. Please don't. Macros need to be easily recognizable as such, since macro parameters are evaluated differently from function parameters. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Tue Feb 12 11:24:21 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1EB5CF9; Tue, 12 Feb 2013 11:24:21 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-vb0-f51.google.com (mail-vb0-f51.google.com [209.85.212.51]) by mx1.freebsd.org (Postfix) with ESMTP id BD769826; Tue, 12 Feb 2013 11:24:20 +0000 (UTC) Received: by mail-vb0-f51.google.com with SMTP id fq11so102086vbb.38 for ; Tue, 12 Feb 2013 03:24:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=cSBPOyFZm9TuvTxVrAKxW8nEXeQkexy6i69WcD+adI8=; b=Uz48YcQxMyXCQsIf7+JwanKzzDo2kRDYFhsT4EEn5P+l29NPjIC2MWXHV//zlajLFC omL9Jlq/gIoB3jieNhH+wZK6Ui2td89jtOXGA0gz4+PFA4iFo0c86+ZBX4HsS12Tq9pz 9jmAhtCh8y/FjJdob0hkm/u2LYR3uFXzRAnloFo8IRL4F+jLRJHCxhz3yDzMncRq3fCW 999kmPryTPnP9w3EsKAqFDwPTAPfHdEExp7rS6MYj7gMRjuMTe4SW9rpIDVOmboF8e11 FM4PBrA1d6nE/4rrD3aFLMWG1/eCKtU8OFtpOwRSnLq0gyKvkx/SPK7a7OXDmSZ1pTg8 w84w== MIME-Version: 1.0 X-Received: by 10.220.154.148 with SMTP id o20mr23616846vcw.54.1360668253781; Tue, 12 Feb 2013 03:24:13 -0800 (PST) Received: by 10.58.170.36 with HTTP; Tue, 12 Feb 2013 03:24:13 -0800 (PST) In-Reply-To: <86fw11homa.fsf@ds4.des.no> References: <51141E33.4080103@gmx.de> <511426B8.2070800@FreeBSD.org> <51160E06.1070404@gmx.de> <5116121E.1010601@FreeBSD.org> <86fw11homa.fsf@ds4.des.no> Date: Tue, 12 Feb 2013 03:24:13 -0800 Message-ID: Subject: Re: Proposal: Unify printing the function name in panic messages() From: Mehmet Erol Sanliturk To: =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Kirk McKusick , Christoph Mallon , Andriy Gapon , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 11:24:21 -0000 On Tue, Feb 12, 2013 at 1:23 AM, Dag-Erling Sm=C3=B8rgrav wrot= e: > Mehmet Erol Sanliturk writes: > > During 1980 years we were using a Burroughs 6700 main frame. Its > > Fortran compiler produced code was generating a call stack trace on > > run time errors [...] A similar structure may be used for FreeBSD > > parts generated during compilation when a compiler switch is set. > > You mean like we've been doing the last 20 years? > > DES > -- > Dag-Erling Sm=C3=B8rgrav - des@des.no > My intention was to say a message like the following : In line < number > in routine < name > the error < name of error > has occurred called from line < number > of routine < name > , . . . called from line < number > of routine < name > . where lines "called from line < number > of routine < name >" may be in any convenient format ( not in hexadecimal addresses ) . I am not seeing any such messages when an error occurs . In "Witness" mode , a list is displayed by hexadecimal addresses . If you mean this feature , I am not intending this feature . My intention was to mean in "Default" mode , not in "Debug" mode , to generate such messages irrespective of debug mode is specified or not . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-arch@FreeBSD.ORG Tue Feb 12 16:41:42 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E80AD260 for ; Tue, 12 Feb 2013 16:41:42 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ob0-f170.google.com (mail-ob0-f170.google.com [209.85.214.170]) by mx1.freebsd.org (Postfix) with ESMTP id B1B18105 for ; Tue, 12 Feb 2013 16:41:42 +0000 (UTC) Received: by mail-ob0-f170.google.com with SMTP id wc20so277740obb.29 for ; Tue, 12 Feb 2013 08:41:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=XhyvYGIouVRBoBmeTlTZ0Cu5lPE6BuWFLiTaM2VZpBQ=; b=L+ZsClKnL3UV5fMtY8ZKcOiLdeVaMKa7niZhvWMzZt6d2SXJF5hZo4iWxowQpXKLz4 EmQfClbanOlQAl1jUfee6Mk/UhJdWmAo+KGrKx0Mu7Y9sPmWMYrNEZg6xZtDoOl2LvxZ OQMmJBf1JPKzmO3fDJFIeWy7axBZDROrcoJgFNiPbtNWbG3CA1VHzc15YuTlIld5GTbN Vqj8UtZoeEKnKryG/xIUPu0inCKnHAIz5lxxR2poNYw3LmQFAuA56qdQLEO4SEI0N1Dr yVekzrnJ4kxBShxG08uVBvr3/7UPpRJLxnwawg9KqDlahVgHc7jF9bRzNZaEBvPew9As FIDA== X-Received: by 10.182.113.40 with SMTP id iv8mr13749528obb.12.1360686876415; Tue, 12 Feb 2013 08:34:36 -0800 (PST) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id ka6sm44185406obb.3.2013.02.12.08.34.33 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Feb 2013 08:34:34 -0800 (PST) Sender: Warner Losh Subject: Re: Proposal: Unify printing the function name in panic messages() Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <201302120615.r1C6FpP8086860@chez.mckusick.com> Date: Tue, 12 Feb 2013 09:34:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5DCB8A72-ABD8-4E8B-8595-EDEBEE70C6AB@bsdimp.com> References: <201302120615.r1C6FpP8086860@chez.mckusick.com> To: Kirk McKusick X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQnVb9g+085/bZgU/LNKMTMEnNBXVFcVIGwD4ABAT1lZ+2yhQt4jUZlJtRSIXNTnVO6R8j3x Cc: Adrian Chadd , Christoph Mallon , Andriy Gapon , mike@karels.net, freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 16:41:43 -0000 On Feb 11, 2013, at 11:15 PM, Kirk McKusick wrote: >> To: Kirk McKusick >> cc: John Baldwin , Adrian Chadd = , >> Christoph Mallon , >> Andriy Gapon , freebsd-arch@freebsd.org >> From: Mike Karels >> Subject: Re: Proposal: Unify printing the function name in panic = messages()=20 >> Date: Tue, 12 Feb 2013 00:01:07 -0600 >>=20 >> I'm not arguing against consistency, nor even agaist the proposal = itself >> (as modified for a lower-case panic macro). However, I don't think = the >> lack of consistency is the real problem. "panic: watchdog timeout" = tells >> me what I need to know, whether or not it includes "watchdog_fire" or = the >> line number. The only problem that has been pointed out is lack of >> uniqueness. That is a simpler problem to handle, and isn't handled = by >> the current proposal as I understand it. >>=20 >> Mike >=20 > Though the default for the current proposal gives just the function = name, > in its verbose mode it give file, function, and line number. And in = its > lean and mean mode, just the error string. This replacing the = hodge-podge > that we have now. My main point is that it is a significant = improvement > over what we have now. I'm all for consistency, and I'm also all for having knobs that let = people limit what is printed. In some environments, I'd love to have the = file/line number. Why? Because I'm lazy and it saves me a grep: I'd be = trading space for convenience. In others, where I'm more space = constrained, I'd love to just have the raw message and suffer the = ambiguity we have today (or fix things so they aren't ambiguous). I too am having difficulty understanding the resistance to the basic = proposal: (1) Make panic messages suck less by removing bogus function names. (2) Hack the panic() to make it a macro so you can add function name or = file + line or the MJD of the last leap second to the panic messages. (1) is like no-brainer yes. (2) is infinite bike-shed land, but if we = have the basic macro there, maybe with a simple/gaudy kernel config then = people that want a different kind of gaudy have an easy hack. I'm still having trouble seeing the down side, except maybe your brand = of gaudy is considered too passe' to be allowed in :) Warner= From owner-freebsd-arch@FreeBSD.ORG Wed Feb 13 01:18:04 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 277B0271 for ; Wed, 13 Feb 2013 01:18:04 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 0FB37AC for ; Wed, 13 Feb 2013 01:18:03 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (c-67-180-208-218.hsd1.ca.comcast.net [67.180.208.218]) by elvis.mu.org (Postfix) with ESMTPSA id 37C3D1A3C1D; Tue, 12 Feb 2013 17:17:57 -0800 (PST) Message-ID: <511AE9C4.4030301@mu.org> Date: Tue, 12 Feb 2013 17:17:56 -0800 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "arch@freebsd.org" , Poul-Henning Kamp Subject: request for preliminary review, enhanced watchdog. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 01:18:04 -0000 At work we've had some issues with superfluous watchdog timeouts firing. Since we use an ipmi/external watchdog the system is completely reset and we are unable to gather metrics. I investigated the issue and then compared to what is offered by Linux and decided to crib from their API such that we can benefit from an enhanced watchdog. I have a WIP at this time in a branch that I would hope people could weigh in on and review as well as make technical suggestions. The branch is located here: svn+ssh://svn.freebsd.org/base/user/alfred/ewatchdog The easy way to get changes: svn log --stop-on-copy svn+ssh://svn.freebsd.org/base/user/alfred/ewatchdog 1) Support for pre-watchdog timeout. This means that so long as the kernel is somewhat functional (callouts are working) we can trigger a configurable action (panic,ddb,log) if the watchdog program is otherwise hung. 2) Support for built-in software watchdog that has the same options (panic,ddb,log) if the watchdog times out. This is useful for prototyping and was done instead of using the SW_WATCHDOG in kern_clock.c because of the ease of working the code into watchdog.c versus communication via the EVENTHANDLER api. 3) Support for Linux-like API. (WDIOC_GETTIMELEFT, WDIOC_SETTIMEOUT,WDIOC_GETTIMEOUT, etc) 4) Modifications to watchdogd(8): - Warn if the watchdog program takes too long. - Disable activation of the system watchdog so that one can test the watchdogd script without potentially rebooting the system. - Ability to log to syslog when scripts begin to timeout. - When told to measure time, do not unconditionally nap for 'sleep' seconds, instead adjust the naptime by the elapsed time so as not to trigger the watchdog. I've not yet hooked in the optional pre-timeout code into watchdogd(8) but plan on doing so later in the week. It would be really helpful if we could decide on a way of selecting which watchdogs to arm/fire and how to query them. I may adopt the Linux API unless someone has alternative suggestions that make a strong enough case to forge our own API. thank you, -Alfred From owner-freebsd-arch@FreeBSD.ORG Wed Feb 13 01:22:41 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B2E86650; Wed, 13 Feb 2013 01:22:41 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 51CEAD8; Wed, 13 Feb 2013 01:22:41 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 2FFCF64F5; Wed, 13 Feb 2013 01:22:40 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id F15DFA2FC; Wed, 13 Feb 2013 02:22:39 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Mehmet Erol Sanliturk Subject: Re: Proposal: Unify printing the function name in panic messages() References: <51141E33.4080103@gmx.de> <511426B8.2070800@FreeBSD.org> <51160E06.1070404@gmx.de> <5116121E.1010601@FreeBSD.org> <86fw11homa.fsf@ds4.des.no> Date: Wed, 13 Feb 2013 02:22:39 +0100 In-Reply-To: (Mehmet Erol Sanliturk's message of "Tue, 12 Feb 2013 03:24:13 -0800") Message-ID: <86vc9xf1nk.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Kirk McKusick , Christoph Mallon , Andriy Gapon , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 01:22:41 -0000 Mehmet Erol Sanliturk writes: > My intention was to say a message like the following : > > In line < number > in routine < name > the error < name of error > has > occurred > called from line < number > of routine < name > , > . > . > . > called from line < number > of routine < name > . Keeping track of file names and line numbers for the entire kernel require huge amounts of space, both on disk and in memory. For 9.1 amd64, GENERIC + all modules weigh in at 62 MB, while the debugging symbols (file names, line numbers and variable names) add 267 MB. Even counting only what's actually in use on a typical machine, like the one I'm typing on right now, we get 18 MB of code + 80 MB of symbols. Don't forget that we need debugging symbols for every single line of code, not just those that call panic(), because a) we want to unwind the stack from the point where panic() was called and b) pretty much any non-trivial C statement can potentially trigger a panic due to a bad pointer or array index, a smashed stack, or any number of reasons. > In "Witness" mode , a list is displayed by hexadecimal addresses . and that's all you're going to get... although when an actual panic occurs, you get a core dump which you can later examine with a debugger, which will give you far more information than a simple stack trace. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Wed Feb 13 01:57:09 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9C7CDF4E; Wed, 13 Feb 2013 01:57:09 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-vb0-f45.google.com (mail-vb0-f45.google.com [209.85.212.45]) by mx1.freebsd.org (Postfix) with ESMTP id 4AE7C20F; Wed, 13 Feb 2013 01:57:08 +0000 (UTC) Received: by mail-vb0-f45.google.com with SMTP id p1so477951vbi.32 for ; Tue, 12 Feb 2013 17:57:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=YWy3n6Rtq5h0YhvfcAiksCdtqvSwgZAJkvlPgpMhAIs=; b=0AJUFhWfAMXwvo9JFBVhgf+lYMcqPjSZRZo5NoDglgrdLG9VSfeMaQC5Av/NX/sNkf xi3O7Bc2EQAngEvK4eascbjTZQJUm4u9eNlAxhqt+BfhihpF2d4whYV6xh7dRTB8Yy2N r7ea1LTeDo6Gj7IIKXJZb/+5dTPaWZPhgXQa4jADhHc3PTFIt8B37SCYh5CwMxBCpYtJ t6pvxhk7Y2Jj1+XYP56GFKUfch+ZjpJ3fu7tLMscdHS87wmeYm3VOu0Cmi0RtQBPi19r 2AjMSFy/4xCTy3QLsPD5CLrbhZTOObFyf+B/aINtmLunVEvzdNXZhSKdqKtrhpoJQ/PE 2eFw== MIME-Version: 1.0 X-Received: by 10.220.154.148 with SMTP id o20mr27371134vcw.54.1360720617439; Tue, 12 Feb 2013 17:56:57 -0800 (PST) Received: by 10.58.170.36 with HTTP; Tue, 12 Feb 2013 17:56:57 -0800 (PST) In-Reply-To: <86vc9xf1nk.fsf@ds4.des.no> References: <51141E33.4080103@gmx.de> <511426B8.2070800@FreeBSD.org> <51160E06.1070404@gmx.de> <5116121E.1010601@FreeBSD.org> <86fw11homa.fsf@ds4.des.no> <86vc9xf1nk.fsf@ds4.des.no> Date: Tue, 12 Feb 2013 17:56:57 -0800 Message-ID: Subject: Re: Proposal: Unify printing the function name in panic messages() From: Mehmet Erol Sanliturk To: =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Kirk McKusick , Christoph Mallon , Andriy Gapon , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 01:57:09 -0000 On Tue, Feb 12, 2013 at 5:22 PM, Dag-Erling Sm=C3=B8rgrav wrot= e: > Mehmet Erol Sanliturk writes: > > My intention was to say a message like the following : > > > > In line < number > in routine < name > the error < name of error > has > > occurred > > called from line < number > of routine < name > , > > . > > . > > . > > called from line < number > of routine < name > . > > Keeping track of file names and line numbers for the entire kernel > require huge amounts of space, both on disk and in memory. For 9.1 > amd64, GENERIC + all modules weigh in at 62 MB, while the debugging > symbols (file names, line numbers and variable names) add 267 MB. > > Even counting only what's actually in use on a typical machine, like the > one I'm typing on right now, we get 18 MB of code + 80 MB of symbols. > > Don't forget that we need debugging symbols for every single line of > code, not just those that call panic(), because a) we want to unwind the > stack from the point where panic() was called and b) pretty much any > non-trivial C statement can potentially trigger a panic due to a bad > pointer or array index, a smashed stack, or any number of reasons. > > > In "Witness" mode , a list is displayed by hexadecimal addresses . > > and that's all you're going to get... > > although when an actual panic occurs, you get a core dump which you can > later examine with a debugger, which will give you far more information > than a simple stack trace. > > DES > -- > Dag-Erling Sm=C3=B8rgrav - des@des.no > My suggestion is ONLY to maintain a CALL stack , not any more . I think , only call stack maintenance will not require a large code size : Before call : push line number and routine name to call stack . Inside routine : On error call a routine to display call stack . After call : pop line number and routine name from call stack . When code size is critical , during compilation , even this feature may be disabled . Especially for server usage and desktop usage , memory is not very critical , but program quality maintenance is much more important . Such a feature will eliminate debug runs for all errors which can be trapped during run time . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-arch@FreeBSD.ORG Wed Feb 13 03:59:57 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 332C4F51 for ; Wed, 13 Feb 2013 03:59:57 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-oa0-f42.google.com (mail-oa0-f42.google.com [209.85.219.42]) by mx1.freebsd.org (Postfix) with ESMTP id F001090E for ; Wed, 13 Feb 2013 03:59:56 +0000 (UTC) Received: by mail-oa0-f42.google.com with SMTP id i18so883154oag.1 for ; Tue, 12 Feb 2013 19:59:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=gB8AHNJ8m1HK0jglhuaY8G7fPmNks7M3494Rs9qEt5Y=; b=lUwrLxs+v8OmU/hd9mSr7JAnz5et/XoHeUrkJvQr/1aENLWr8CvIAUrS02G54GrCfU rSGMsOxpqFvQE1IqV75HJydcjL9qV8xMkcc8NDhBeMF3gzp7pC4V3BPfSHCQ9Asvr5cK Mf96uq0r9CmlkteuPNtyM+2kbSWTDNXFf53E1t2vJ4XSQ2A+gPvtLR8EYAb0UavamR5g iwkTJQ620Sp/WRt59xLZecnzkaqHK2YkiX/rIA5gnJCN3mFTxu2In9q0EbVZs/S+Ppsz KCSwLaMnsZyamKOP5yQ+o6sGtbOPegyBn7iokVFMF18NIgYKxkv7r3JA6yQZaHFYUC5/ ccwQ== X-Received: by 10.182.144.40 with SMTP id sj8mr15213949obb.82.1360727990240; Tue, 12 Feb 2013 19:59:50 -0800 (PST) Received: from 53.imp.bsdimp.com ([209.117.142.2]) by mx.google.com with ESMTPS id w10sm57100439oeg.2.2013.02.12.19.59.44 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Feb 2013 19:59:49 -0800 (PST) Sender: Warner Losh Subject: Re: Proposal: Unify printing the function name in panic messages() Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: Warner Losh In-Reply-To: Date: Tue, 12 Feb 2013 20:59:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51141E33.4080103@gmx.de> <511426B8.2070800@FreeBSD.org> <51160E06.1070404@gmx.de> <5116121E.1010601@FreeBSD.org> <86fw11homa.fsf@ds4.des.no> <86vc9xf1nk.fsf@ds4.des.no> To: Mehmet Erol Sanliturk X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQnfUpoWpX8LcCJ4dNiibEwNfuurb0445uaUPTQwXwZxg6USpjO9/k6N9+Mz9Xe8QvyyAtZw Cc: Kirk McKusick , =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , Christoph Mallon , Andriy Gapon , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 03:59:57 -0000 On Feb 12, 2013, at 6:56 PM, Mehmet Erol Sanliturk wrote: > On Tue, Feb 12, 2013 at 5:22 PM, Dag-Erling Sm=F8rgrav = wrote: >=20 >> Mehmet Erol Sanliturk writes: >>> My intention was to say a message like the following : >>>=20 >>> In line < number > in routine < name > the error < name of error > = has >>> occurred >>> called from line < number > of routine < name > , >>> . >>> . >>> . >>> called from line < number > of routine < name > . >>=20 >> Keeping track of file names and line numbers for the entire kernel >> require huge amounts of space, both on disk and in memory. For 9.1 >> amd64, GENERIC + all modules weigh in at 62 MB, while the debugging >> symbols (file names, line numbers and variable names) add 267 MB. >>=20 >> Even counting only what's actually in use on a typical machine, like = the >> one I'm typing on right now, we get 18 MB of code + 80 MB of symbols. >>=20 >> Don't forget that we need debugging symbols for every single line of >> code, not just those that call panic(), because a) we want to unwind = the >> stack from the point where panic() was called and b) pretty much any >> non-trivial C statement can potentially trigger a panic due to a bad >> pointer or array index, a smashed stack, or any number of reasons. >>=20 >>> In "Witness" mode , a list is displayed by hexadecimal addresses . >>=20 >> and that's all you're going to get... >>=20 >> although when an actual panic occurs, you get a core dump which you = can >> later examine with a debugger, which will give you far more = information >> than a simple stack trace. >>=20 >> DES >> -- >> Dag-Erling Sm=F8rgrav - des@des.no >>=20 >=20 >=20 > My suggestion is ONLY to maintain a CALL stack , not any more . I = think , > only call stack maintenance will not require a large code size : You are wrong. > Before call : push line number and routine name to call stack . > Inside routine : On error call a routine to display call stack . > After call : pop line number and routine name from call stack . Uberslow. The normal way of just keeping tables of mappings from PC to = line number doesn't slow things down at all. This would bloat the code = and slow things down. > When code size is critical , during compilation , even this feature = may be > disabled . >=20 > Especially for server usage and desktop usage , memory is not very = critical > , but program quality maintenance is much more important . >=20 > Such a feature will eliminate debug runs for all errors which can be > trapped during run time . It is easier to just do minidumps... Warner >=20 > Thank you very much . >=20 > Mehmet Erol Sanliturk > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to = "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Wed Feb 13 04:22:53 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E5453426; Wed, 13 Feb 2013 04:22:53 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-ve0-f173.google.com (mail-ve0-f173.google.com [209.85.128.173]) by mx1.freebsd.org (Postfix) with ESMTP id 5E6C79C1; Wed, 13 Feb 2013 04:22:52 +0000 (UTC) Received: by mail-ve0-f173.google.com with SMTP id oz10so748660veb.4 for ; Tue, 12 Feb 2013 20:22:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=eMa7lG+UlfGAkr5UOIBeq2D7qCtfo+8MXrY3vqftV9Y=; b=KKgw1o0ZA1dAZv/efA61qqwFCsIXOIu87Tv7FQJrghdtwG7aRxcHcr3o395AMOomJa +GDlxrvQ6iSPVAiZ1SFrFp+qw5+n5+YK+3rM/7PQowRjunBod7vNutL8LWlgPgeJI5ox D7PiZYuLodUvT1Va3nPDmlpP3Z3vprfWdgCMOhJXq+eQkhwxvmdKNGmSuz0z3Btuy8xM UMWqvYIN8rkYIVDSACLIYytfLVthL8TI5iEMitq3j7tiSvXrWUKEj8yP4F8WeZzyqrvw PrN2Xqc5mNij/I2ROQAYJXcERze4/k3Zrl0ufcYiht237C8W2mNcLOq6AHgEbrQcLmhK zvSg== MIME-Version: 1.0 X-Received: by 10.52.98.196 with SMTP id ek4mr24398497vdb.16.1360729372184; Tue, 12 Feb 2013 20:22:52 -0800 (PST) Received: by 10.58.170.36 with HTTP; Tue, 12 Feb 2013 20:22:52 -0800 (PST) In-Reply-To: References: <51141E33.4080103@gmx.de> <511426B8.2070800@FreeBSD.org> <51160E06.1070404@gmx.de> <5116121E.1010601@FreeBSD.org> <86fw11homa.fsf@ds4.des.no> <86vc9xf1nk.fsf@ds4.des.no> Date: Tue, 12 Feb 2013 20:22:52 -0800 Message-ID: Subject: Re: Proposal: Unify printing the function name in panic messages() From: Mehmet Erol Sanliturk To: Warner Losh Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Kirk McKusick , =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= , Christoph Mallon , Andriy Gapon , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 04:22:54 -0000 On Tue, Feb 12, 2013 at 7:59 PM, Warner Losh wrote: > > On Feb 12, 2013, at 6:56 PM, Mehmet Erol Sanliturk wrote: > > > On Tue, Feb 12, 2013 at 5:22 PM, Dag-Erling Sm=C3=B8rgrav = wrote: > > > >> Mehmet Erol Sanliturk writes: > >>> My intention was to say a message like the following : > >>> > >>> In line < number > in routine < name > the error < name of error > ha= s > >>> occurred > >>> called from line < number > of routine < name > , > >>> . > >>> . > >>> . > >>> called from line < number > of routine < name > . > >> > >> Keeping track of file names and line numbers for the entire kernel > >> require huge amounts of space, both on disk and in memory. For 9.1 > >> amd64, GENERIC + all modules weigh in at 62 MB, while the debugging > >> symbols (file names, line numbers and variable names) add 267 MB. > >> > >> Even counting only what's actually in use on a typical machine, like t= he > >> one I'm typing on right now, we get 18 MB of code + 80 MB of symbols. > >> > >> Don't forget that we need debugging symbols for every single line of > >> code, not just those that call panic(), because a) we want to unwind t= he > >> stack from the point where panic() was called and b) pretty much any > >> non-trivial C statement can potentially trigger a panic due to a bad > >> pointer or array index, a smashed stack, or any number of reasons. > >> > >>> In "Witness" mode , a list is displayed by hexadecimal addresses . > >> > >> and that's all you're going to get... > >> > >> although when an actual panic occurs, you get a core dump which you ca= n > >> later examine with a debugger, which will give you far more informatio= n > >> than a simple stack trace. > >> > >> DES > >> -- > >> Dag-Erling Sm=C3=B8rgrav - des@des.no > >> > > > > > > My suggestion is ONLY to maintain a CALL stack , not any more . I think= , > > only call stack maintenance will not require a large code size : > > You are wrong. > Program development and maintenance costs ( programmer life and cost , debugging times , etc. ) , are much higher than importance of code size . In the present servers and desktops , nearly it is not possible to have memory sizes measured by less than 1000 mega bytes . For the rare cases , disabling the feature may be used . > > > Before call : push line number and routine name to call stack . > > Inside routine : On error call a routine to display call stack . > > After call : pop line number and routine name from call stack . > The above steps will be generated by the compiler . They will not be existent in written source code . Machine code bloating is not visible to the user . > > Uberslow. The normal way of just keeping tables of mappings from PC to > line number doesn't slow things down at all. This would bloat the code an= d > slow things down. > Since compilation of such statements will be generated based on a given flag , for critical programs it may be disabled ( not generated ) or such programs may be compiled as this feature enabled and executed for testing . > > > When code size is critical , during compilation , even this feature may > be > > disabled . > > > > Especially for server usage and desktop usage , memory is not very > critical > > , but program quality maintenance is much more important . > > > > Such a feature will eliminate debug runs for all errors which can be > > trapped during run time . > > It is easier to just do minidumps... > > Warner > > > > > Thank you very much . > > > > Mehmet Erol Sanliturk > > > From owner-freebsd-arch@FreeBSD.ORG Wed Feb 13 15:31:16 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DCC7FD2F; Wed, 13 Feb 2013 15:31:16 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id B8F009CA; Wed, 13 Feb 2013 15:31:16 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 6BD1DB924; Wed, 13 Feb 2013 10:31:15 -0500 (EST) From: John Baldwin To: Adrian Chadd Subject: Re: Proposal: Unify printing the function name in panic messages() Date: Mon, 11 Feb 2013 17:05:08 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: <51141E33.4080103@gmx.de> <201302111203.19422.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201302111705.08350.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 13 Feb 2013 10:31:15 -0500 (EST) Cc: Kirk McKusick , Christoph Mallon , Andriy Gapon , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 15:31:16 -0000 On Monday, February 11, 2013 4:20:00 pm Adrian Chadd wrote: > Whoa, whoa. > > Are you seriously trying to argue that having a consistent file:line > isn't a really helpful addition to panic messages? > > Yes, you can get it via the crash IP and use of binutils on the kernel > image. But with modules? You have to fire up kgdb, and that requires a > dump _and_ a kgdb that matches the kernel image in question. > > Even if you don't add it to the panic message, having that information > passed into panic() so it can print out a file:line would be great. He isn't adding that, he's adding __func__, and it isn't a fool proof replacement. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Feb 13 15:31:18 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5B0C8D32; Wed, 13 Feb 2013 15:31:18 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 377FB9CB; Wed, 13 Feb 2013 15:31:18 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 9C734B95E; Wed, 13 Feb 2013 10:31:17 -0500 (EST) From: John Baldwin To: freebsd-arch@freebsd.org Subject: Re: Proposal: Unify printing the function name in panic messages() Date: Wed, 13 Feb 2013 10:28:29 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <201302120615.r1C6FpP8086860@chez.mckusick.com> <5DCB8A72-ABD8-4E8B-8595-EDEBEE70C6AB@bsdimp.com> In-Reply-To: <5DCB8A72-ABD8-4E8B-8595-EDEBEE70C6AB@bsdimp.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201302131028.30010.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 13 Feb 2013 10:31:17 -0500 (EST) Cc: Adrian Chadd , mike@karels.net, Andriy Gapon , Kirk McKusick , Christoph Mallon X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 15:31:18 -0000 On Tuesday, February 12, 2013 11:34:33 am Warner Losh wrote: > > On Feb 11, 2013, at 11:15 PM, Kirk McKusick wrote: > > >> To: Kirk McKusick > >> cc: John Baldwin , Adrian Chadd , > >> Christoph Mallon , > >> Andriy Gapon , freebsd-arch@freebsd.org > >> From: Mike Karels > >> Subject: Re: Proposal: Unify printing the function name in panic messages() > >> Date: Tue, 12 Feb 2013 00:01:07 -0600 > >> > >> I'm not arguing against consistency, nor even agaist the proposal itself > >> (as modified for a lower-case panic macro). However, I don't think the > >> lack of consistency is the real problem. "panic: watchdog timeout" tells > >> me what I need to know, whether or not it includes "watchdog_fire" or the > >> line number. The only problem that has been pointed out is lack of > >> uniqueness. That is a simpler problem to handle, and isn't handled by > >> the current proposal as I understand it. > >> > >> Mike > > > > Though the default for the current proposal gives just the function name, > > in its verbose mode it give file, function, and line number. And in its > > lean and mean mode, just the error string. This replacing the hodge-podge > > that we have now. My main point is that it is a significant improvement > > over what we have now. > > I'm all for consistency, and I'm also all for having knobs that let people limit what is printed. In some environments, I'd love to have the file/line number. Why? Because I'm lazy and it saves me a grep: I'd be trading space for convenience. In others, where I'm more space constrained, I'd love to just have the raw message and suffer the ambiguity we have today (or fix things so they aren't ambiguous). > > I too am having difficulty understanding the resistance to the basic proposal: > (1) Make panic messages suck less by removing bogus function names. > (2) Hack the panic() to make it a macro so you can add function name or file + line or the MJD of the last leap second to the panic messages. > > (1) is like no-brainer yes. I think (1) is fine if it fixes truly bogus ones. However, there are some cases (like the one I cited earlier) where the mismatch is _intentional_, so you can't do automated fixes. I also want the string that shows up in the code to match what is output for my project of writing unit/regression tests. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Feb 13 16:00:02 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 815A1E05; Wed, 13 Feb 2013 16:00:02 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 59A77C04; Wed, 13 Feb 2013 16:00:02 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id CD55DB96E; Wed, 13 Feb 2013 11:00:01 -0500 (EST) From: John Baldwin To: Kirk McKusick Subject: Re: Proposal: Unify printing the function name in panic messages() Date: Wed, 13 Feb 2013 10:38:56 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <201302120134.r1C1Ycfh026347@chez.mckusick.com> In-Reply-To: <201302120134.r1C1Ycfh026347@chez.mckusick.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201302131038.57250.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 13 Feb 2013 11:00:01 -0500 (EST) Cc: Adrian Chadd , Christoph Mallon , Andriy Gapon , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 16:00:02 -0000 On Monday, February 11, 2013 8:34:38 pm Kirk McKusick wrote: > I have recently gone down several ratholes trying to understand a > panic message which had the wrong function name (prefix ufs1_ instead > of ufs2_). I can definitely say that it matters to me. And I think > that fixing the problem as Christoph has outlined will be a big > step in the right direction. > > John, in your code you cannot expect to match the entire panic > string if it has any % formats in it. So to be useful, you must be > able to work with a constant subset of the string. The addition of > other information such as a function name at the start should not > affect that constant part that you are trying to match. Actually, that's not quite true. I store both the "raw" format string and a generated string in an on-stack buffer in the PANIC_TRY macro that is compared against. Some more examples: static int test_no_sleeping_recursion(void) { struct timespec before, after; int error; /* These tests will DROP_GIANT before panic'ing. */ DROP_GIANT(); THREAD_NO_SLEEPING(); PANIC_TRY { tsleep(&test_wchan, 0, "sleep", 1); } PANIC_CATCH { sleepq_release(&test_wchan); IGNORE_PANIC("%s: td %p to sleep on wchan %p with sleeping prohibited"); } PANIC_END; THREAD_NO_SLEEPING(); PANIC_TRY { tsleep(&test_wchan, 0, "sleep", 1); } PANIC_CATCH { sleepq_release(&test_wchan); IGNORE_PANIC("%s: td %p to sleep on wchan %p with sleeping prohibited"); } PANIC_END; THREAD_SLEEPING_OK(); PANIC_TRY { tsleep(&test_wchan, 0, "sleep", 1); } PANIC_CATCH { sleepq_release(&test_wchan); IGNORE_PANIC("%s: td %p to sleep on wchan %p with sleeping prohibited"); } PANIC_END; THREAD_SLEEPING_OK(); nanouptime(&before); error = tsleep(&test_wchan, 0, "sleep", hz); nanouptime(&after); KASSERT(error == EWOULDBLOCK, ("tsleep did not timeout: %d", error)); PICKUP_GIANT(); return (TEST_OK); } UNIT_TEST("sleeping disabled recursion", test_no_sleeping_recursion); (This panic already use __func__ explicitly) And my unit tests for PANIC_TRY itself: static int catch_panics(void) { PANIC_TRY { panic("test"); } PANIC_CATCH { IGNORE_PANIC("test"); } PANIC_END; PANIC_TRY { panic("test longer message"); } PANIC_CATCH { IGNORE_PANIC_STARTS_WITH("test"); } PANIC_END; PANIC_TRY { panic("test %s", "raw message"); } PANIC_CATCH { IGNORE_PANIC("test %s"); } PANIC_END; PANIC_TRY { panic("test %s", "formatted message"); } PANIC_CATCH { IGNORE_PANIC("test formatted message"); } PANIC_END; return (TEST_OK); } UNIT_TEST("catching panics", catch_panics); static int unexpected_panics(void) { PANIC_TRY { PANIC_TRY { panic("test"); } PANIC_CATCH { } PANIC_END; } PANIC_CATCH { IGNORE_PANIC_STARTS_WITH("Unexpected panic"); } PANIC_END; PANIC_TRY { PANIC_TRY { panic("foo"); } PANIC_CATCH { IGNORE_PANIC("bar"); IGNORE_PANIC_STARTS_WITH("b"); } PANIC_END; } PANIC_CATCH { IGNORE_PANIC_STARTS_WITH("Unexpected panic"); } PANIC_END; return (TEST_OK); } UNIT_TEST("unexpected panics", unexpected_panics); TESTER_MODULE(panic); If every panic has a slightly '%s:' at the front that is perhaps less painful to deal with in the unformatted case. In the case that you want a test to catch a formatted message then it's a bit less obvious you need to prepend the relevant function name. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Feb 13 19:23:08 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D1224198; Wed, 13 Feb 2013 19:23:08 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by mx1.freebsd.org (Postfix) with ESMTP id 1E438A7E; Wed, 13 Feb 2013 19:23:07 +0000 (UTC) Received: by mail-we0-f178.google.com with SMTP id x48so1299434wey.37 for ; Wed, 13 Feb 2013 11:23:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=jxLiSAcUoWuguSqRipZzyPZu5s5+nlbGKUG0AqX4wRQ=; b=EdZmBF/YrLwQLSE9lcPlcKzNB2mr6t4bHeQ+I4l8vDpBEQhf3KV36gc1ZlskH5oX4J 9mW/OR8+CBRBSpQGDyELNyfQZgFZmau/jdJa9X4ThArA1zLzafS8I+4dF+hbz520QemK urTgHNlBDpg9XIz+aPqRtoDIbXsiVc2YsNPU+rO+e/il3A6tnEdwixZvXqKdZfsi17bY MswfeKlTWDQRjYCjsxGHmvLdUFFV85DI9eA1jim8OxpuJ2vl2t9qWgj87Ov274ajGMx0 LxJ9D0PbNjGdleQV9sLieh6VpUlQzHa+vj7kz6VXKzM99EM9m7DwoSYX+lmFMc+Vaeem bsyw== MIME-Version: 1.0 X-Received: by 10.194.108.101 with SMTP id hj5mr40379962wjb.6.1360783387206; Wed, 13 Feb 2013 11:23:07 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.236.88 with HTTP; Wed, 13 Feb 2013 11:23:06 -0800 (PST) In-Reply-To: <201302131038.57250.jhb@freebsd.org> References: <201302120134.r1C1Ycfh026347@chez.mckusick.com> <201302131038.57250.jhb@freebsd.org> Date: Wed, 13 Feb 2013 11:23:06 -0800 X-Google-Sender-Auth: wVWnIARJg_dT9bHHv2m6nuuGH1g Message-ID: Subject: Re: Proposal: Unify printing the function name in panic messages() From: Adrian Chadd To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: Kirk McKusick , Christoph Mallon , Andriy Gapon , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 19:23:08 -0000 ... I hate to be a jerk, but something tells me that relying on the output of text strings as to the panic cause and then parsing those is maybe not the right thing to do. If it were me, I'd do something like the gettext string API - ie, panic wouldn't take a string, but a panic string ID, which would translate to an enum as well as map to a string.. then you could pull that off. Adrian From owner-freebsd-arch@FreeBSD.ORG Wed Feb 13 20:04:30 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2B66BABE; Wed, 13 Feb 2013 20:04:30 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0862BCC5; Wed, 13 Feb 2013 20:04:30 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 802C0B9B0; Wed, 13 Feb 2013 15:04:29 -0500 (EST) From: John Baldwin To: Adrian Chadd Subject: Re: Proposal: Unify printing the function name in panic messages() Date: Wed, 13 Feb 2013 15:04:18 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <201302120134.r1C1Ycfh026347@chez.mckusick.com> <201302131038.57250.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Message-Id: <201302131504.19142.jhb@freebsd.org> Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 13 Feb 2013 15:04:29 -0500 (EST) Cc: Kirk McKusick , Christoph Mallon , Andriy Gapon , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 20:04:30 -0000 On Wednesday, February 13, 2013 2:23:06 pm Adrian Chadd wrote: > ... I hate to be a jerk, but something tells me that relying on the > output of text strings as to the panic cause and then parsing those is > maybe not the right thing to do. > > If it were me, I'd do something like the gettext string API - ie, > panic wouldn't take a string, but a panic string ID, which would > translate to an enum as well as map to a string.. then you could pull > that off. Look, I've had these tests private for years and have used them when working on locking primitives. If you don't want them in the tree I can save myself a whole lot of work and not try to clean them up and update them for rmlocks (where I'm attempting to expand my tests to test some fixes I have to rmlocks because I prefer to thoroughly test the changes I make to locking primitives before I commit them). -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Feb 13 20:11:15 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D9FC5D9E; Wed, 13 Feb 2013 20:11:15 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id B0103D2B; Wed, 13 Feb 2013 20:11:15 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 23484B922; Wed, 13 Feb 2013 15:11:15 -0500 (EST) From: John Baldwin To: freebsd-arch@freebsd.org Subject: Re: Proposal: Unify printing the function name in panic messages() Date: Wed, 13 Feb 2013 15:11:13 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <201302120134.r1C1Ycfh026347@chez.mckusick.com> <201302131504.19142.jhb@freebsd.org> In-Reply-To: <201302131504.19142.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201302131511.14019.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 13 Feb 2013 15:11:15 -0500 (EST) Cc: Kirk McKusick , Adrian Chadd , Christoph Mallon , Andriy Gapon X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 20:11:15 -0000 On Wednesday, February 13, 2013 3:04:18 pm John Baldwin wrote: > On Wednesday, February 13, 2013 2:23:06 pm Adrian Chadd wrote: > > ... I hate to be a jerk, but something tells me that relying on the > > output of text strings as to the panic cause and then parsing those is > > maybe not the right thing to do. > > > > If it were me, I'd do something like the gettext string API - ie, > > panic wouldn't take a string, but a panic string ID, which would > > translate to an enum as well as map to a string.. then you could pull > > that off. > > Look, I've had these tests private for years and have used them when working > on locking primitives. If you don't want them in the tree I can save myself a > whole lot of work and not try to clean them up and update them for rmlocks > (where I'm attempting to expand my tests to test some fixes I have to rmlocks > because I prefer to thoroughly test the changes I make to locking primitives > before I commit them). *sigh* This is too snarky, and I apologize. Futz with panic messages all you want. I strongly doubt it will make one iota of difference in debugging non-developer issues since 99.9% of all panics reported by users are page faults and having a "trap_fatal:" prefix to the panic string just doesn't add any useful contents. I'll just update my tests to cope. I'm not i18n'ing panic messages. I'll still work on my unit tests for at least my own use as I can't bear commits to primitives that aren't well tested. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Feb 13 20:56:50 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 109DE506 for ; Wed, 13 Feb 2013 20:56:50 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id EAFE8EC1 for ; Wed, 13 Feb 2013 20:56:49 +0000 (UTC) Received: from lrust-sslvpn-nc.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mail.xcllnt.net (8.14.6/8.14.6) with ESMTP id r1DKulLI064354 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 13 Feb 2013 12:56:48 -0800 (PST) (envelope-from marcel@xcllnt.net) From: Marcel Moolenaar Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: FDT on x86 and for non-fdtbus devices. Message-Id: <03A622DA-EFD4-4984-8FC3-CD8B4832C32E@xcllnt.net> Date: Wed, 13 Feb 2013 12:56:42 -0800 To: "freebsd-arch@FreeBSD.org Arch" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 20:56:50 -0000 All, Here at Juniper we added support for FDT to x86 (we'll contribute that shortly). However, it's applicability is rather limited right now by virtue of needing the devices to be attached to fdtbus (directly or indirectly). This so that we can map from device_t to pnode_t. However, there's great value in being able to use the FDT to tweak the behaviour of any device in the system, and in particular when we don't need nor use FDT to enumerate them. What we like to do is to use the FDT to define properties for pretty much any kind of device. Examples are: 1. Allow the FDT to define the name by which an interface is to be created. 2. Enumerate smb devices so that we can attach drivers for them under smbus when we don't need FDT to find ichsmb itself. I think one way to state the problem in a generic way is: How can we obtain the FDT pnode_t given an arbitrary device_t and use the pnode_t to query for properties, etc. Are people already doing things like this? Is there an interest in being able to do things like this? Are changes to drivers to have them query FDT contributable at all or do people think such would be "pollution"? Thoughts? Ideas? -- Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-arch@FreeBSD.ORG Wed Feb 13 20:57:32 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id F30685EF; Wed, 13 Feb 2013 20:57:31 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) by mx1.freebsd.org (Postfix) with ESMTP id 3DDE0EDC; Wed, 13 Feb 2013 20:57:30 +0000 (UTC) Received: by mail-wi0-f171.google.com with SMTP id hn17so6262742wib.10 for ; Wed, 13 Feb 2013 12:57:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=4OtzxElIVa+qK6w3GazDLEIVk3rzhB0pwu2IX2sO3mI=; b=u1N2wWktQhaSAOmbQuk1OGGEzPFBrbArzflDUAKgAPKC5ul4IloAQVzAVSsnjHC/fT R8EQZFSusboEprVeNPDSTC3mnTgf7zCOxVpuC21l37X7GBP/UYichxFEOye2pQuQoAii +jEQIhG9onMO9DXGAf+DnAVVjzIJn/c73VhckzMdIeBC84pqtfOezD4FFuUBvwpf9wtE lBVr8jwtTFb0RzCSDIjpNA9iAc3P5WdNAkON2CduebEQqltaVRw9NgvUAtkUI7R687nM JZ32sh3+ZRzAcJIEa9zBw6L5wD8FnccwNrbIDGHfbE67TWDRgFQ4qo29soN5C79qCrY8 jXSw== MIME-Version: 1.0 X-Received: by 10.194.108.101 with SMTP id hj5mr40827795wjb.6.1360789043918; Wed, 13 Feb 2013 12:57:23 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.236.88 with HTTP; Wed, 13 Feb 2013 12:57:23 -0800 (PST) In-Reply-To: <201302131511.14019.jhb@freebsd.org> References: <201302120134.r1C1Ycfh026347@chez.mckusick.com> <201302131504.19142.jhb@freebsd.org> <201302131511.14019.jhb@freebsd.org> Date: Wed, 13 Feb 2013 12:57:23 -0800 X-Google-Sender-Auth: k1TN6os6HVwD-Vx-5_NADdlgF4g Message-ID: Subject: Re: Proposal: Unify printing the function name in panic messages() From: Adrian Chadd To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: Kirk McKusick , Christoph Mallon , Andriy Gapon , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 20:57:32 -0000 Oh I'm not offended, feel free to be a bit of a jerk back to me. I'm just thinking of the longer term benefit here. If we _did_ tag panic() messages with a globally unique panic string identifier we'd make your job easier. But yes, it's a longer term project.. Adrian From owner-freebsd-arch@FreeBSD.ORG Wed Feb 13 21:05:53 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 96EFF99A; Wed, 13 Feb 2013 21:05:53 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 77742F45; Wed, 13 Feb 2013 21:05:52 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA12073; Wed, 13 Feb 2013 23:05:50 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1U5jWY-0000e8-FP; Wed, 13 Feb 2013 23:05:50 +0200 Message-ID: <511C002C.8090801@FreeBSD.org> Date: Wed, 13 Feb 2013 23:05:48 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130121 Thunderbird/17.0.2 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: Proposal: Unify printing the function name in panic messages() References: <201302120134.r1C1Ycfh026347@chez.mckusick.com> <201302131504.19142.jhb@freebsd.org> <201302131511.14019.jhb@freebsd.org> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 21:05:53 -0000 on 13/02/2013 22:57 Adrian Chadd said the following: > Oh I'm not offended, feel free to be a bit of a jerk back to me. > > I'm just thinking of the longer term benefit here. If we _did_ tag > panic() messages with a globally unique panic string identifier we'd > make your job easier. > But yes, it's a longer term project.. Something of tangential relevance. In Linux they have some special trace code to debug ACPI resume issues that stores some IDs/hashes of trace statements (perhaps somewhat akin to our ktr) to RTC time-of-day registers. I guess that that was a smart choice because you can count on presence of those registers and they can be written with simple outb instructions. -- Andriy Gapon From owner-freebsd-arch@FreeBSD.ORG Wed Feb 13 23:01:23 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0E431EF4 for ; Wed, 13 Feb 2013 23:01:23 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id 7A1BB640 for ; Wed, 13 Feb 2013 23:01:21 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 36FB7440 for ; Wed, 13 Feb 2013 23:58:31 +0100 (CET) Date: Thu, 14 Feb 2013 00:02:22 +0100 From: Pawel Jakub Dawidek To: freebsd-arch@FreeBSD.org Subject: Large Capsicum patch for review. Message-ID: <20130213230221.GB1375@garage.freebsd.pl> References: <20130213025547.GA2025@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nVMJ2NtxeReIH9PS" Content-Disposition: inline In-Reply-To: <20130213025547.GA2025@garage.freebsd.pl> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 23:01:23 -0000 --nVMJ2NtxeReIH9PS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi. I'd like to commit this patch: http://people.freebsd.org/~pjd/patches/capkern.diff The major changes are: - Capability is no longer separate descriptor type. Now every descriptor has set of its own capability rights. - The cap_new(2) system call is left, but it is no longer documented and should not be used in new code. - The new syscall cap_rights_limit(2) should be used instead of cap_new(2), which limits capability rights of the given descriptor without creating a new one. - The cap_getrights(2) syscall is renamed to cap_rights_get(2). - If CAP_IOCTL capability right is present we can further reduce allowed ioctls list with the new cap_ioctls_limit(2) syscall. List of allowed ioctls can be retrived with cap_ioctls_get(2) syscall. - If CAP_FCNTL capability right is present we can further reduce fcntls that can be used with the new cap_fcntls_limit(2) syscall and retrive them with cap_fcntls_get(2). - To support ioctl and fcntl white-listing the filedesc structure was heavly modified. - libc wrapper cap_sandboxed(3) around cap_getmode(2) syscall is implemented which always succeeds and return boolean (true is in capability sandbox and false if not in capability sandbox because either cap_enter(2) was not called or CAPABILITY_MODE is not compiled into the kernel). - The audit subsystem, kdump and procstat tools were updated to recognize new syscalls. - Capability rights were revised and eventhough I tried hard to provide backward API and ABI compatibility there are some incompatible changes that are described in detail below: CAP_CREATE old behaviour: - Allow for openat(2)+O_CREAT. - Allow for linkat(2). - Allow for symlinkat(2). CAP_CREATE new behaviour: - Allow for openat(2)+O_CREAT. Added CAP_LINKAT: - Allow for linkat(2). ABI: Reuses CAP_RMDIR bit. - Allow to be target for renameat(2). Added CAP_SYMLINKAT: - Allow for symlinkat(2). Removed CAP_DELETE. Old behaviour: - Allow for unlinkat(2) when removing non-directory object. - Allow to be source for renameat(2). Removed CAP_RMDIR. Old behaviour: - Allow for unlinkat(2) when removing directory. Added CAP_UNLINKAT (effectively it replaces CAP_DELETE and CAP_RMDIR): - Allow for unlinkat(2) on any object. - Allow to be source for renameat(2). Removed CAP_MAPEXEC. CAP_MMAP old behaviour: - Allow for mmap(2) with any combination of PROT_NONE, PROT_READ and PROT_WRITE. CAP_MMAP new behaviour: - Allow for mmap(2)+PROT_NONE. Added CAP_MMAP_R: - Allow for mmap(PROT_READ). Added CAP_MMAP_W: - Allow for mmap(PROT_WRITE). Added CAP_MMAP_X: - Allow for mmap(PROT_EXEC). Added CAP_MMAP_RW: - Allow for mmap(PROT_READ | PROT_WRITE). Added CAP_MMAP_RX: - Allow for mmap(PROT_READ | PROT_EXEC). Added CAP_MMAP_WX: - Allow for mmap(PROT_WRITE | PROT_EXEC). Added CAP_MMAP_RWX: - Allow for mmap(PROT_READ | PROT_WRITE | PROT_EXEC). Renamed CAP_MKDIR to CAP_MKDIRAT. Renamed CAP_MKFIFO to CAP_MKFIFOAT. Renamed CAP_MKNODE to CAP_MKNODEAT. CAP_READ old behaviour: - Allow pread(2). - Disallow read(2), readv(2) (if there is no CAP_SEEK). CAP_READ new behaviour: - Allow read(2), readv(2). - Disallow pread(2) (CAP_SEEK was also required). CAP_WRITE old behaviour: - Allow pwrite(2). - Disallow write(2), writev(2) (if there is no CAP_SEEK). CAP_WRITE new behaviour: - Allow write(2), writev(2). - Disallow pwrite(2) (CAP_SEEK was also required). Added convinient defines: #define CAP_PREAD (CAP_SEEK | CAP_READ) #define CAP_PWRITE (CAP_SEEK | CAP_WRITE) #define CAP_MMAP_R (CAP_MMAP | CAP_SEEK | CAP_READ) #define CAP_MMAP_W (CAP_MMAP | CAP_SEEK | CAP_WRITE) #define CAP_MMAP_X (CAP_MMAP | CAP_SEEK | 0x0000000000000008ULL) #define CAP_MMAP_RW (CAP_MMAP_R | CAP_MMAP_W) #define CAP_MMAP_RX (CAP_MMAP_R | CAP_MMAP_X) #define CAP_MMAP_WX (CAP_MMAP_W | CAP_MMAP_X) #define CAP_MMAP_RWX (CAP_MMAP_R | CAP_MMAP_W | CAP_MMAP_X) #define CAP_RECV CAP_READ #define CAP_SEND CAP_WRITE #define CAP_SOCK_CLIENT \ (CAP_CONNECT | CAP_GETPEERNAME | CAP_GETSOCKNAME | CAP_GETSOCKOPT | \ CAP_PEELOFF | CAP_RECV | CAP_SEND | CAP_SETSOCKOPT | CAP_SHUTDOWN) #define CAP_SOCK_SERVER \ (CAP_ACCEPT | CAP_BIND | CAP_GETPEERNAME | CAP_GETSOCKNAME | \ CAP_GETSOCKOPT | CAP_LISTEN | CAP_PEELOFF | CAP_RECV | CAP_SEND | \ CAP_SETSOCKOPT | CAP_SHUTDOWN) Added defines for backward API compatibility: #define CAP_MAPEXEC CAP_MMAP_X #define CAP_DELETE CAP_UNLINKAT #define CAP_MKDIR CAP_MKDIRAT #define CAP_RMDIR CAP_UNLINKAT #define CAP_MKFIFO CAP_MKFIFOAT #define CAP_MKNOD CAP_MKNODAT #define CAP_SOCK_ALL (CAP_SOCK_CLIENT | CAP_SOCK_SERVER) --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --nVMJ2NtxeReIH9PS Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlEcG30ACgkQForvXbEpPzQ90QCg4YwruUN+spAKRYsm9xLRlpRZ X1gAmgKdFGRcW0a/Ub9CJEu/PG3fs5AD =AgVf -----END PGP SIGNATURE----- --nVMJ2NtxeReIH9PS-- From owner-freebsd-arch@FreeBSD.ORG Wed Feb 13 23:02:54 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5EDA7FBB for ; Wed, 13 Feb 2013 23:02:54 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id 22402660 for ; Wed, 13 Feb 2013 23:02:53 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 2F8AC444 for ; Thu, 14 Feb 2013 00:00:03 +0100 (CET) Date: Thu, 14 Feb 2013 00:03:54 +0100 From: Pawel Jakub Dawidek To: freebsd-arch@FreeBSD.org Subject: bindat(2) and connectat(2) syscalls for review. Message-ID: <20130213230354.GC1375@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="f0KYrhQ4vYSV2aJu" Content-Disposition: inline X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 23:02:54 -0000 --f0KYrhQ4vYSV2aJu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi. I'd like to commit the following patch: http://people.freebsd.org/~pjd/patches/bindconnectat.patch It implements bindat(2) and connectat(2) syscalls that will allow to manage UNIX domain sockets from within capability mode sandbox. They work just like any other *at(2) syscall and their prototypes look like this: int bindat(int fd, int s, const struct sockaddr *addr, socklen_t addrlen); int connectat(int fd, int s, const struct sockaddr *addr, socklen_t addrle= n); Where 'fd' is directory descriptor. The only supported socket domain is PF_LOCAL. The audit subsystem was updated to audit the new syscalls properly. Comments and reviews are welcome. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --f0KYrhQ4vYSV2aJu Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlEcG9oACgkQForvXbEpPzSafwCeJt4l+7hgI+/vcOVGHc+IcFLK 0+UAniSVf8RM8oduMjxkhLiUy+A48/4U =D1Fx -----END PGP SIGNATURE----- --f0KYrhQ4vYSV2aJu-- From owner-freebsd-arch@FreeBSD.ORG Wed Feb 13 23:19:46 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 61E28852; Wed, 13 Feb 2013 23:19:46 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) by mx1.freebsd.org (Postfix) with ESMTP id 158F5730; Wed, 13 Feb 2013 23:19:46 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 2B938358C5A; Thu, 14 Feb 2013 00:19:43 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id 0905B2848C; Thu, 14 Feb 2013 00:19:43 +0100 (CET) Date: Thu, 14 Feb 2013 00:19:42 +0100 From: Jilles Tjoelker To: Pawel Jakub Dawidek Subject: Re: bindat(2) and connectat(2) syscalls for review. Message-ID: <20130213231942.GA94000@stack.nl> References: <20130213230354.GC1375@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130213230354.GC1375@garage.freebsd.pl> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 23:19:46 -0000 On Thu, Feb 14, 2013 at 12:03:54AM +0100, Pawel Jakub Dawidek wrote: > I'd like to commit the following patch: > http://people.freebsd.org/~pjd/patches/bindconnectat.patch > It implements bindat(2) and connectat(2) syscalls that will allow to > manage UNIX domain sockets from within capability mode sandbox. > They work just like any other *at(2) syscall and their prototypes look > like this: > int bindat(int fd, int s, const struct sockaddr *addr, socklen_t addrlen); > int connectat(int fd, int s, const struct sockaddr *addr, socklen_t addrlen); > Where 'fd' is directory descriptor. The only supported socket domain is > PF_LOCAL. > The audit subsystem was updated to audit the new syscalls properly. These calls are inherently limited to PF_LOCAL anyway, so why not go a bit further and accept a pathname instead of a struct sockaddr_un that has an arbitrary limit of 104 bytes? This appears possible because new usrreqs were created. Can the "XXXRW: Revisit this" comments before #bind and #connect in sys/kern/capabilities.conf go away now? -- Jilles Tjoelker From owner-freebsd-arch@FreeBSD.ORG Wed Feb 13 23:20:11 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EF4ED8F6; Wed, 13 Feb 2013 23:20:11 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 619B1736; Wed, 13 Feb 2013 23:20:11 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r1DNK4wn073237; Thu, 14 Feb 2013 01:20:04 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r1DNK4wn073237 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r1DNK4L3073236; Thu, 14 Feb 2013 01:20:04 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 14 Feb 2013 01:20:04 +0200 From: Konstantin Belousov To: Pawel Jakub Dawidek Subject: Re: bindat(2) and connectat(2) syscalls for review. Message-ID: <20130213232004.GA2522@kib.kiev.ua> References: <20130213230354.GC1375@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XVQUzBCFV/dfPXE3" Content-Disposition: inline In-Reply-To: <20130213230354.GC1375@garage.freebsd.pl> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 23:20:12 -0000 --XVQUzBCFV/dfPXE3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 14, 2013 at 12:03:54AM +0100, Pawel Jakub Dawidek wrote: > Hi. >=20 > I'd like to commit the following patch: >=20 > http://people.freebsd.org/~pjd/patches/bindconnectat.patch >=20 > It implements bindat(2) and connectat(2) syscalls that will allow to > manage UNIX domain sockets from within capability mode sandbox. >=20 > They work just like any other *at(2) syscall and their prototypes look > like this: >=20 > int bindat(int fd, int s, const struct sockaddr *addr, socklen_t addrlen= ); > int connectat(int fd, int s, const struct sockaddr *addr, socklen_t addr= len); >=20 > Where 'fd' is directory descriptor. The only supported socket domain is > PF_LOCAL. >=20 > The audit subsystem was updated to audit the new syscalls properly. >=20 > Comments and reviews are welcome. Looking only at prototypes, I think it is useful to add at last the flags argument. The first application of it is for O_CLOEXEC-like flag. --XVQUzBCFV/dfPXE3 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRHB+jAAoJEJDCuSvBvK1BcoAQAIIajsLWmMt+dD0kHPmLTvXe 8euo1+OlmQmcoIZL0INU8AShNJ4nVvMiWBithE0W3FRy+Ne/4vVaRwDaTJjev9wi upoZhZ9vAbDR1uddHcCRy4LWX2+FWUJyJsItFVds5Fnu25civc4sivag5S9GGkXe yTQ8bFCqq+UO2idjCQgrN++8xyqb8y/b/Sal7PD3hEgnCjb+GGBvUYsTTVfNaFUQ CZhluaKUGejxRrQ3Ng11EY7XREQo+hX7BBWSzr+b6elqs5UJznCi59n5gCd2Sx1g kEN+HxzofSUAxO37ZsH51pE8dB0B0hyNLj+UM4AYqJwAZ6FZfiUL36GUXAXkBi6D KtEnjg61qxczYuoElXqqTXPinnb+nVP/Ewo5aYyWBXI+WWiJTTFKsxjIuepriwtS 3dD46Gugp5c3Tw6z8XowGApYVGuJNcmM1kG6o77iXQ90xKzI4d4gYxx0lq+xskL/ hPdDwa9CGbrI6aB7VWqkNZOqtHrA4vIhgSknSUdaQbwwHU7dioabGolX4WaLgf2k QXucDs65LDD2VrFrZo1prtbIwKk0DV36KsAmgzRE3pI44M767WFDCSj4/Sli5+Y1 TtDhx43x5trcaITsT3n0UJiNMSbjgLPHT8x2kifoPPatJpwO7gz8XkiZFmW/369G YXnF987N8psOt18V5Xnj =HHhn -----END PGP SIGNATURE----- --XVQUzBCFV/dfPXE3-- From owner-freebsd-arch@FreeBSD.ORG Wed Feb 13 23:21:56 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 285999AA for ; Wed, 13 Feb 2013 23:21:56 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ob0-f179.google.com (mail-ob0-f179.google.com [209.85.214.179]) by mx1.freebsd.org (Postfix) with ESMTP id E9F7C746 for ; Wed, 13 Feb 2013 23:21:55 +0000 (UTC) Received: by mail-ob0-f179.google.com with SMTP id un3so1829283obb.24 for ; Wed, 13 Feb 2013 15:21:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=PVi/Y7bwLnzgcewsAwx8EtiGw3+Z+/ni6r48NlgJ3QA=; b=O9nJUtIDMQAGIXGedY44rLP9rOMS5Ukr47Si5JelNUWT7hMc320ZXOWcAV5xfIZl/l kA7EIUu0Mjc85G4YiMYi5cWC1EG6DyvVKBOb5xzW6PwJU7dsIPhsMc04KKr5DBKXrsw3 EvnJz9JplEBNnryXQ5/KYXMOt/+jgy4ieoEVIXV9NDCINBF7RnZpBLEqqZraqxRO4kZe 3OlZLSKdZ26WLuSf8Fe93n/ee9HoKf5i5PVdnJwfMDT8TxN2+GqulHTQ5ZySiYsLpai4 qftVuTb10PkbxVQYNfVE4+odrC6RWxRaUy32Yu17vAcNlZtYuc9Dsb8sbxVgzl7QRXZ3 Jkrg== X-Received: by 10.60.7.129 with SMTP id j1mr17858120oea.54.1360797713018; Wed, 13 Feb 2013 15:21:53 -0800 (PST) Received: from fusionlt2834a.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id t9sm3178240obk.13.2013.02.13.15.21.51 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Feb 2013 15:21:52 -0800 (PST) Sender: Warner Losh Subject: Re: FDT on x86 and for non-fdtbus devices. Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <03A622DA-EFD4-4984-8FC3-CD8B4832C32E@xcllnt.net> Date: Wed, 13 Feb 2013 16:21:49 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <77486082-2D96-49CC-9841-2D1572F86DEE@bsdimp.com> References: <03A622DA-EFD4-4984-8FC3-CD8B4832C32E@xcllnt.net> To: Marcel Moolenaar X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQmtF40V7Q4fktNX3UYOBXkuzIFfpLSuxDsERoMdiQMIZjatDeQLa/DRKgC27za84154ropK Cc: "freebsd-arch@FreeBSD.org Arch" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 23:21:56 -0000 On Feb 13, 2013, at 1:56 PM, Marcel Moolenaar wrote: > All, >=20 > Here at Juniper we added support for FDT to x86 (we'll contribute > that shortly). However, it's applicability is rather limited right > now by virtue of needing the devices to be attached to fdtbus > (directly or indirectly). That's cool... > This so that we can map from device_t > to pnode_t. However, there's great value in being able to use the > FDT to tweak the behaviour of any device in the system, and in > particular when we don't need nor use FDT to enumerate them. Yes, I can see that for many possible cases... However, you'll have to = solve the namespace boundary problems inherent in such an undertaking... > What we like to do is to use the FDT to define properties for > pretty much any kind of device. Examples are: > 1. Allow the FDT to define the name by which an interface is > to be created. This might be hard... Perhaps you could flesh out a bit how you'd = propose to do this. > 2. Enumerate smb devices so that we can attach drivers for them > under smbus when we don't need FDT to find ichsmb itself. If there's a 1-1 correspondence in the the FDT between the smb bridge = driver (ichsmb) and the sub devices, this could work. > I think one way to state the problem in a generic way is: How > can we obtain the FDT pnode_t given an arbitrary device_t and > use the pnode_t to query for properties, etc. Yes. What's the naming conventions we need to use here, especially since = names in the FDT don't necessarily match our driver names. Crazy idea: = define freebsd,driver-name properlty to make this association explicit. > Are people already doing things like this? only a little. > Is there an interest in being able to do things like this? Yes. > Are changes to drivers to have them query FDT contributable at > all or do people think such would be "pollution"? I like this idea, but others may not be so open to it. > Thoughts? > Ideas? "Go speed racer! Go!" Warner= From owner-freebsd-arch@FreeBSD.ORG Wed Feb 13 23:39:32 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 045FAFE6 for ; Wed, 13 Feb 2013 23:39:32 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id A81C27EC for ; Wed, 13 Feb 2013 23:39:31 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 32CB1465; Thu, 14 Feb 2013 00:36:40 +0100 (CET) Date: Thu, 14 Feb 2013 00:40:31 +0100 From: Pawel Jakub Dawidek To: Konstantin Belousov Subject: Re: bindat(2) and connectat(2) syscalls for review. Message-ID: <20130213234030.GD1375@garage.freebsd.pl> References: <20130213230354.GC1375@garage.freebsd.pl> <20130213232004.GA2522@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/3yNEOqWowh/8j+e" Content-Disposition: inline In-Reply-To: <20130213232004.GA2522@kib.kiev.ua> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 23:39:32 -0000 --/3yNEOqWowh/8j+e Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 14, 2013 at 01:20:04AM +0200, Konstantin Belousov wrote: > On Thu, Feb 14, 2013 at 12:03:54AM +0100, Pawel Jakub Dawidek wrote: > > Hi. > >=20 > > I'd like to commit the following patch: > >=20 > > http://people.freebsd.org/~pjd/patches/bindconnectat.patch > >=20 > > It implements bindat(2) and connectat(2) syscalls that will allow to > > manage UNIX domain sockets from within capability mode sandbox. > >=20 > > They work just like any other *at(2) syscall and their prototypes look > > like this: > >=20 > > int bindat(int fd, int s, const struct sockaddr *addr, socklen_t addrl= en); > > int connectat(int fd, int s, const struct sockaddr *addr, socklen_t ad= drlen); > >=20 > > Where 'fd' is directory descriptor. The only supported socket domain is > > PF_LOCAL. > >=20 > > The audit subsystem was updated to audit the new syscalls properly. > >=20 > > Comments and reviews are welcome. >=20 > Looking only at prototypes, I think it is useful to add at last the flags > argument. The first application of it is for O_CLOEXEC-like flag. And this flag should be applied to? Note that those syscalls don't create new descriptors, they operate on existing descriptors (directory descriptor and socket descriptor) that should eventually have close-on-exec flag set if required. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --/3yNEOqWowh/8j+e Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlEcJG4ACgkQForvXbEpPzQyfgCeIsO0CRxOQlzOOdpTDzqSjAoS gRkAoMSqLiVrRHpFHmcGLbYq46MSBi01 =XHDm -----END PGP SIGNATURE----- --/3yNEOqWowh/8j+e-- From owner-freebsd-arch@FreeBSD.ORG Wed Feb 13 23:48:31 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9EED645B for ; Wed, 13 Feb 2013 23:48:31 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id 6744186D for ; Wed, 13 Feb 2013 23:48:30 +0000 (UTC) Received: from lrust-sslvpn-nc.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mail.xcllnt.net (8.14.6/8.14.6) with ESMTP id r1DNmRf3065999 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 13 Feb 2013 15:48:28 -0800 (PST) (envelope-from marcel@xcllnt.net) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: FDT on x86 and for non-fdtbus devices. From: Marcel Moolenaar In-Reply-To: <77486082-2D96-49CC-9841-2D1572F86DEE@bsdimp.com> Date: Wed, 13 Feb 2013 15:48:21 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <03A622DA-EFD4-4984-8FC3-CD8B4832C32E@xcllnt.net> <77486082-2D96-49CC-9841-2D1572F86DEE@bsdimp.com> To: Warner Losh X-Mailer: Apple Mail (2.1499) Cc: "freebsd-arch@FreeBSD.org Arch" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 23:48:31 -0000 On Feb 13, 2013, at 3:21 PM, Warner Losh wrote: >> What we like to do is to use the FDT to define properties for >> pretty much any kind of device. Examples are: >> 1. Allow the FDT to define the name by which an interface is >> to be created. >=20 > This might be hard... Perhaps you could flesh out a bit how you'd = propose to do this. The thought so far is to use an "interface-name" property in FDT node that provides the name to give to if_initname(). With a single function like if_initname(), you can actually put the logic there, provided we then also pass the device_t (or something similar) to if_initname(). >> 2. Enumerate smb devices so that we can attach drivers for them >> under smbus when we don't need FDT to find ichsmb itself. >=20 > If there's a 1-1 correspondence in the the FDT between the smb bridge = driver (ichsmb) and the sub devices, this could work. Exactly: I'd like this to work for iicbus as well so that we can actually describe the whole i2c bus hierarchy/hierarchies. Using indirect I/O (i.e. always pass requests to the parent), you can have drivers in arbitrarily complex hierarchies (i.e. with i2c muxes) do I/O, and as such provide whatever interface is beneficial, without having to expose H/W details to the consumers. >=20 >> I think one way to state the problem in a generic way is: How >> can we obtain the FDT pnode_t given an arbitrary device_t and >> use the pnode_t to query for properties, etc. >=20 > Yes. What's the naming conventions we need to use here, especially = since names in the FDT don't necessarily match our driver names. Crazy = idea: define freebsd,driver-name properlty to make this association = explicit. >=20 >> Are people already doing things like this? >=20 > only a little. >=20 >> Is there an interest in being able to do things like this? >=20 > Yes. >=20 >> Are changes to drivers to have them query FDT contributable at >> all or do people think such would be "pollution"? >=20 > I like this idea, but others may not be so open to it. While our aim is to build JUNOS on a pristine FreeBSD, we will always have local changes. As long as the changes are contained we're fine. So if we can't change a driver, but we can contribute the infrastructure, we're very happy. >> Thoughts? >> Ideas? >=20 > "Go speed racer! Go!" Roger that :-) --=20 Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-arch@FreeBSD.ORG Thu Feb 14 08:47:27 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 18274600 for ; Thu, 14 Feb 2013 08:47:27 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by mx1.freebsd.org (Postfix) with ESMTP id AC01BE76 for ; Thu, 14 Feb 2013 08:47:25 +0000 (UTC) Received: from mailout-de.gmx.net ([10.1.76.35]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0Lqod2-1Ub8gW3PkY-00ePF8 for ; Thu, 14 Feb 2013 09:47:18 +0100 Received: (qmail invoked by alias); 14 Feb 2013 08:47:12 -0000 Received: from p5B1328E8.dip.t-dialin.net (EHLO rotluchs.lokal) [91.19.40.232] by mail.gmx.net (mp035) with SMTP; 14 Feb 2013 09:47:12 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX19u62orr0FuY3IKKTAiyff4MP4ukpjejqyRNAhqbh sm+ewTVcOwJ29a Message-ID: <511CA463.6070407@gmx.de> Date: Thu, 14 Feb 2013 09:46:27 +0100 From: Christoph Mallon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130129 Thunderbird/17.0.2 MIME-Version: 1.0 To: John Baldwin Subject: Re: Proposal: Unify printing the function name in panic messages() References: <51141E33.4080103@gmx.de> <201302111203.19422.jhb@freebsd.org> <201302111705.08350.jhb@freebsd.org> In-Reply-To: <201302111705.08350.jhb@freebsd.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Kirk McKusick , Adrian Chadd , Andriy Gapon , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 08:47:27 -0000 On 11.02.2013 23:05, John Baldwin wrote: > On Monday, February 11, 2013 4:20:00 pm Adrian Chadd wrote: >> Whoa, whoa. >> >> Are you seriously trying to argue that having a consistent file:line >> isn't a really helpful addition to panic messages? >> >> Yes, you can get it via the crash IP and use of binutils on the kernel >> image. But with modules? You have to fire up kgdb, and that requires a >> dump _and_ a kgdb that matches the kernel image in question. >> >> Even if you don't add it to the panic message, having that information >> passed into panic() so it can print out a file:line would be great. > > He isn't adding that, he's adding __func__, and it isn't a fool proof > replacement. I simply chose __func__, because this is what the majority of panic() calls does (or at least tries to do). One big benefit of the PANIC() macros is, that now there is one central place to define what location info is printed. file and line: #define PANIC(fmt, ...) panic("%s:%d: " fmt, __FILE__, __LINE__, ##__VA_ARGS__) or we can go the full assert(3) way: #define PANIC(fmt, ...) panic(fmt ", function %s, file %s, line %d.", ##__VA_ARGS__, __func__, __FILE__, __LINE__) we can even paint it TARDIS blue: #define PANIC(fmt, ...) panic("\33[34m" fmt "\33[0m", ##__VA_ARGS__) but considering the length of the thread, we are way past this point. Christoph From owner-freebsd-arch@FreeBSD.ORG Thu Feb 14 10:33:58 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E0F21DFB for ; Thu, 14 Feb 2013 10:33:58 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id C1255337 for ; Thu, 14 Feb 2013 10:33:58 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 70D6346B3F; Thu, 14 Feb 2013 05:33:58 -0500 (EST) Date: Thu, 14 Feb 2013 10:33:58 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Marcel Moolenaar Subject: Re: FDT on x86 and for non-fdtbus devices. In-Reply-To: <03A622DA-EFD4-4984-8FC3-CD8B4832C32E@xcllnt.net> Message-ID: References: <03A622DA-EFD4-4984-8FC3-CD8B4832C32E@xcllnt.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "freebsd-arch@FreeBSD.org Arch" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 10:33:58 -0000 On Wed, 13 Feb 2013, Marcel Moolenaar wrote: > I think one way to state the problem in a generic way is: How can we obtain > the FDT pnode_t given an arbitrary device_t and use the pnode_t to query for > properties, etc. > > Are people already doing things like this? Is there an interest in being > able to do things like this? Are changes to drivers to have them query FDT > contributable at all or do people think such would be "pollution"? Only loosely related, but another thing we'd like to be able to do at SRI/Cambridge is merge ROM-discovered FDT configuration data with kernel-linked configuration data. For example, we'd like to rely on the device's ROM for a list of physical device layouts and so on, but embed our description of flash layout, additional device driver configuration information (e.g., /dev node information for avgen, which exports devices unsupported by specific device drivers using a generic memory-mapped interface), etc, in the compiled kernel for the device. I'm not sure if that's something that's of interest in this context as well? Robert From owner-freebsd-arch@FreeBSD.ORG Thu Feb 14 14:03:56 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 52204F25; Thu, 14 Feb 2013 14:03:56 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id EB606692; Thu, 14 Feb 2013 14:03:55 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id F42116EF7; Thu, 14 Feb 2013 14:03:48 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id C6F53A478; Thu, 14 Feb 2013 15:03:48 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Andriy Gapon Subject: Re: Proposal: Unify printing the function name in panic messages() References: <201302120134.r1C1Ycfh026347@chez.mckusick.com> <201302131504.19142.jhb@freebsd.org> <201302131511.14019.jhb@freebsd.org> <511C002C.8090801@FreeBSD.org> Date: Thu, 14 Feb 2013 15:03:48 +0100 In-Reply-To: <511C002C.8090801@FreeBSD.org> (Andriy Gapon's message of "Wed, 13 Feb 2013 23:05:48 +0200") Message-ID: <86mwv7q9ff.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Adrian Chadd , freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 14:03:56 -0000 Andriy Gapon writes: > Something of tangential relevance. In Linux they have some special > trace code to debug ACPI resume issues that stores some IDs/hashes of > trace statements (perhaps somewhat akin to our ktr) to RTC time-of-day > registers. I guess that that was a smart choice because you can count > on presence of those registers and they can be written with simple > outb instructions. They're not really registers, just unused space in non-volatile memory. To the computer, a DS1307-compatible RTC looks like a 64-byte flash chip connected by I2C. IIRC, the RTC stores the date and time in BCD in the lower bytes and the rest is unused, unless you have a high-end chip that uses a few extra bytes to store calibration parameters etc. Storing data there is not *quite* "simple outb instructions" since I2C is an adressable serial bus, but it's not insurmountable, and the type of machines that matter to people working on suspend / resume are pretty much guaranteed to have a DS1307-compatible RTC. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Thu Feb 14 14:40:35 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 731A873 for ; Thu, 14 Feb 2013 14:40:35 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ia0-x22a.google.com (mail-ia0-x22a.google.com [IPv6:2607:f8b0:4001:c02::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 41C5B8AE for ; Thu, 14 Feb 2013 14:40:35 +0000 (UTC) Received: by mail-ia0-f170.google.com with SMTP id k20so2362062iak.29 for ; Thu, 14 Feb 2013 06:40:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=6sryvn5U5P/Z53+7+9T7fp3Bp1v+it0/1GyT0gVPvqM=; b=ibyAxxb3ah4WdCQgMSUOSG/QzPRDNlsZPvmAgdgS1d552n3Bc/KZm3BtgiDSeN6nZC yvrXhnMnw7BIb/PbaoHqzhSShwgNzdLpAKY4T2GmDtv59+1yV073gQ2s/G4dkkJAkjIR miaVmM1tttL1fIQmzFeSBt4sAWr1cktUg3RmGmrQd/4sCvCNDqq4nHngfYMd6pPKS35y oKddKyo/ynGejZWGJeiJhFVD32keMv0BQD2WywimH3IXT68CHspEwBn5xsmV76zQecLX Dg0imgIlo9IhLgrdyUSMaf5/fck6AxU6k1i6dWSTMXPZw9npjrZg/3jvf4Q8HG1Uxu0l 9+yg== X-Received: by 10.42.92.72 with SMTP id s8mr35130908icm.0.1360852834886; Thu, 14 Feb 2013 06:40:34 -0800 (PST) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id qn10sm17532290igc.6.2013.02.14.06.40.32 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Feb 2013 06:40:33 -0800 (PST) Sender: Warner Losh Subject: Re: FDT on x86 and for non-fdtbus devices. Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Thu, 14 Feb 2013 07:40:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8606E19D-98A2-4E2C-A9E3-5056C1BAC34E@bsdimp.com> References: <03A622DA-EFD4-4984-8FC3-CD8B4832C32E@xcllnt.net> To: Robert Watson X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQnjPW3fZPjn+0CBV1RZNfpqz4UpINfJTksaWPMOGkS1KPmsofzbEPRnOqyEexofyvHZ19j0 Cc: "freebsd-arch@FreeBSD.org Arch" , Marcel Moolenaar X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 14:40:35 -0000 On Feb 14, 2013, at 3:33 AM, Robert Watson wrote: >=20 > On Wed, 13 Feb 2013, Marcel Moolenaar wrote: >=20 >> I think one way to state the problem in a generic way is: How can we = obtain the FDT pnode_t given an arbitrary device_t and use the pnode_t = to query for properties, etc. >>=20 >> Are people already doing things like this? Is there an interest in = being able to do things like this? Are changes to drivers to have them = query FDT contributable at all or do people think such would be = "pollution"? >=20 > Only loosely related, but another thing we'd like to be able to do at = SRI/Cambridge is merge ROM-discovered FDT configuration data with = kernel-linked configuration data. For example, we'd like to rely on the = device's ROM for a list of physical device layouts and so on, but embed = our description of flash layout, additional device driver configuration = information (e.g., /dev node information for avgen, which exports = devices unsupported by specific device drivers using a generic = memory-mapped interface), etc, in the compiled kernel for the device. = I'm not sure if that's something that's of interest in this context as = well? IF you want to just add nodes to the FDT, I think that having a merge = function in ubldr and such wouldn't be too horribly hard. If you wanted = to change leaf nodes already in the tree, that would be quite a bit = harder, but might be doable in the kernel context.... But I'm curious why your specific example wouldn't already live in the = FDT for your board.... Warner From owner-freebsd-arch@FreeBSD.ORG Thu Feb 14 14:45:36 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 89D194F0 for ; Thu, 14 Feb 2013 14:45:36 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4B277910 for ; Thu, 14 Feb 2013 14:45:36 +0000 (UTC) Received: from c0157.aw.cl.cam.ac.uk (c0157.aw.cl.cam.ac.uk [128.232.100.157]) by cyrus.watson.org (Postfix) with ESMTPSA id 7A00A46B3F; Thu, 14 Feb 2013 09:45:35 -0500 (EST) Subject: Re: FDT on x86 and for non-fdtbus devices. Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: "Robert N. M. Watson" In-Reply-To: <8606E19D-98A2-4E2C-A9E3-5056C1BAC34E@bsdimp.com> Date: Thu, 14 Feb 2013 14:45:23 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <03A622DA-EFD4-4984-8FC3-CD8B4832C32E@xcllnt.net> <8606E19D-98A2-4E2C-A9E3-5056C1BAC34E@bsdimp.com> To: Warner Losh X-Mailer: Apple Mail (2.1283) Cc: "freebsd-arch@FreeBSD.org Arch" , Marcel Moolenaar X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 14:45:36 -0000 On 14 Feb 2013, at 14:40, Warner Losh wrote: >>> I think one way to state the problem in a generic way is: How can we = obtain the FDT pnode_t given an arbitrary device_t and use the pnode_t = to query for properties, etc. >>>=20 >>> Are people already doing things like this? Is there an interest in = being able to do things like this? Are changes to drivers to have them = query FDT contributable at all or do people think such would be = "pollution"? >>=20 >> Only loosely related, but another thing we'd like to be able to do at = SRI/Cambridge is merge ROM-discovered FDT configuration data with = kernel-linked configuration data. For example, we'd like to rely on the = device's ROM for a list of physical device layouts and so on, but embed = our description of flash layout, additional device driver configuration = information (e.g., /dev node information for avgen, which exports = devices unsupported by specific device drivers using a generic = memory-mapped interface), etc, in the compiled kernel for the device. = I'm not sure if that's something that's of interest in this context as = well? >=20 > IF you want to just add nodes to the FDT, I think that having a merge = function in ubldr and such wouldn't be too horribly hard. If you wanted = to change leaf nodes already in the tree, that would be quite a bit = harder, but might be doable in the kernel context.... >=20 > But I'm curious why your specific example wouldn't already live in the = FDT for your board.... We want to put hardware configuration parameters in the on-board FDT. We want to put software configuration parameters in the kernel targeted = for the board. For example -- avgen(4) allows us to export specific pieces of I/O = memory to userspace via named device nodes -- e.g., /dev/touchscreen. = The hardware-side configuration is the description of the device in I/O = memory; the software-side configuration is the name of the device node = and its default permissions. Likewise, some properties of flash layout = have to do with our hardware -- e.g., the locations of the primary and = backup FPGA bitfiles loaded by the hardware on power-on; other parts = have to do with software -- e.g., placement of /dev/map entries in that = flash (since we can't put a GPT on the front since it's reserved space = for board initialisation/boot vector); these also go into device.hints. = We'd much rather use more FDT to describe these parameters rather than = device.hints -- in particular, we might flash that software-specific FDT = data into flash as well, but it's not the same as the ROM-embedded bus = description. Robert= From owner-freebsd-arch@FreeBSD.ORG Thu Feb 14 16:53:31 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A1CEE6E1; Thu, 14 Feb 2013 16:53:31 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id 5365EF21; Thu, 14 Feb 2013 16:53:28 +0000 (UTC) Received: from lrust-sslvpn-nc.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mail.xcllnt.net (8.14.6/8.14.6) with ESMTP id r1EGrLOA071926 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 14 Feb 2013 08:53:22 -0800 (PST) (envelope-from marcel@xcllnt.net) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: FDT on x86 and for non-fdtbus devices. From: Marcel Moolenaar In-Reply-To: Date: Thu, 14 Feb 2013 08:53:19 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <129FAAB3-469A-47D5-AA46-1806665ED357@xcllnt.net> References: <03A622DA-EFD4-4984-8FC3-CD8B4832C32E@xcllnt.net> To: Robert Watson X-Mailer: Apple Mail (2.1499) Cc: "freebsd-arch@FreeBSD.org Arch" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 16:53:31 -0000 On Feb 14, 2013, at 2:33 AM, Robert Watson wrote: >=20 > On Wed, 13 Feb 2013, Marcel Moolenaar wrote: >=20 >> I think one way to state the problem in a generic way is: How can we = obtain the FDT pnode_t given an arbitrary device_t and use the pnode_t = to query for properties, etc. >>=20 >> Are people already doing things like this? Is there an interest in = being able to do things like this? Are changes to drivers to have them = query FDT contributable at all or do people think such would be = "pollution"? >=20 > Only loosely related, but another thing we'd like to be able to do at = SRI/Cambridge is merge ROM-discovered FDT configuration data with = kernel-linked configuration data. Not necessarily that loosely related. Both our needs can be addressed if we always construct a "global" FDT by merging different sources, like firmware, compiled-in and generated by enumerating PCI, ISA PnP, et al. My want of using the FDT to fine-tune the behaviour of PCI devices or describing iic/smb hierarchies when the host controller isn't rooted in FDT is addressed by virtue of everything now being rooted in the FDT. Your need is addressed intrinsically. The immediate questions that arise from this approach are: 1. How does such a scheme affect boot time? 2. What does it take to change the ACPI interface or the core PCI code to construct a FDT? 3. When merging, conflicts are to be expected. Is there a simple answer (discovered has least precedence)? 4. If we nest devices under proximity domains in the FDT, can we then also solve NUMA related problems generically? On the one hand it comes across as fairly complex to have the kernel generate FDT fragments as part of bus enumeration, then merge all the fragments and finally construct the in- kernel device driver tree from the merged FDT. On the other hand, it also "feels" very liberating. We can put everything we need in the FDT, including how to name an interface so that it matches the name on the front-panel. We can override firmware by disabling BARs of PCI devices in a way to preserve device I/O space. And... Hot-plug PCI and everything else hot-plug could potentially be abstracted as "merely" being a matter of adding (merging) and removing FDT fragments "on the fly". Again a generic problem that may help us build generic solutions... Thoughts? --=20 Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-arch@FreeBSD.ORG Thu Feb 14 17:00:31 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4B9A3841; Thu, 14 Feb 2013 17:00:31 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id 282B8F7A; Thu, 14 Feb 2013 17:00:30 +0000 (UTC) Received: from lrust-sslvpn-nc.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mail.xcllnt.net (8.14.6/8.14.6) with ESMTP id r1EH0RIp071985 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 14 Feb 2013 09:00:28 -0800 (PST) (envelope-from marcel@xcllnt.net) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: FDT on x86 and for non-fdtbus devices. From: Marcel Moolenaar In-Reply-To: Date: Thu, 14 Feb 2013 09:00:25 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <03A622DA-EFD4-4984-8FC3-CD8B4832C32E@xcllnt.net> <8606E19D-98A2-4E2C-A9E3-5056C1BAC34E@bsdimp.com> To: "Robert N. M. Watson" X-Mailer: Apple Mail (2.1499) Cc: "freebsd-arch@FreeBSD.org Arch" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 17:00:31 -0000 On Feb 14, 2013, at 6:45 AM, Robert N. M. Watson = wrote: >> But I'm curious why your specific example wouldn't already live in = the FDT for your board.... >=20 >=20 > We want to put hardware configuration parameters in the on-board FDT. >=20 > We want to put software configuration parameters in the kernel = targeted for the board. /nod I think it's a feature to instantiate GEOMs from the FDT. Creating a mirrored disk configuration when the disks are already in use cannot in general be done using tasting. The assumption that the last sector is free is invalid with GPT and it has created conformance problems for us already. Being able to construct the gmirror GEOM from the FDT eliminates the need to scribble meta-data on the disk and as such allows us to mirror 2 GPT disks at the disk level without instantaneously becoming non-conformant. --=20 Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-arch@FreeBSD.ORG Thu Feb 14 17:08:29 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C3C86ABB for ; Thu, 14 Feb 2013 17:08:29 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id A032EFD7 for ; Thu, 14 Feb 2013 17:08:29 +0000 (UTC) Received: from c0157.aw.cl.cam.ac.uk (c0157.aw.cl.cam.ac.uk [128.232.100.157]) by cyrus.watson.org (Postfix) with ESMTPSA id 9F58B46B3C; Thu, 14 Feb 2013 12:08:28 -0500 (EST) Subject: Re: FDT on x86 and for non-fdtbus devices. Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: "Robert N. M. Watson" In-Reply-To: Date: Thu, 14 Feb 2013 17:08:27 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <9E6F6629-BB8B-4DE9-8348-56516D9D4E97@FreeBSD.org> References: <03A622DA-EFD4-4984-8FC3-CD8B4832C32E@xcllnt.net> <8606E19D-98A2-4E2C-A9E3-5056C1BAC34E@bsdimp.com> To: Marcel Moolenaar X-Mailer: Apple Mail (2.1283) Cc: "freebsd-arch@FreeBSD.org Arch" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 17:08:29 -0000 On 14 Feb 2013, at 17:00, Marcel Moolenaar wrote: > I think it's a feature to instantiate GEOMs from the FDT. > Creating a mirrored disk configuration when the disks are > already in use cannot in general be done using tasting. > The assumption that the last sector is free is invalid > with GPT and it has created conformance problems for us > already. Being able to construct the gmirror GEOM from the > FDT eliminates the need to scribble meta-data on the disk > and as such allows us to mirror 2 GPT disks at the disk > level without instantaneously becoming non-conformant. Especially in our case, where the first block of the flash is definitely = reserved for things other than partition table data structures. :-) Robert= From owner-freebsd-arch@FreeBSD.ORG Thu Feb 14 18:55:51 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5A5051BA; Thu, 14 Feb 2013 18:55:51 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) by mx1.freebsd.org (Postfix) with ESMTP id 21DB7739; Thu, 14 Feb 2013 18:55:51 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id AE7D5358C68; Thu, 14 Feb 2013 19:55:49 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id 916312848C; Thu, 14 Feb 2013 19:55:49 +0100 (CET) Date: Thu, 14 Feb 2013 19:55:49 +0100 From: Jilles Tjoelker To: Pawel Jakub Dawidek Subject: Re: bindat(2) and connectat(2) syscalls for review. Message-ID: <20130214185549.GA36288@stack.nl> References: <20130213230354.GC1375@garage.freebsd.pl> <20130213232004.GA2522@kib.kiev.ua> <20130213234030.GD1375@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130213234030.GD1375@garage.freebsd.pl> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Konstantin Belousov , freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 18:55:51 -0000 On Thu, Feb 14, 2013 at 12:40:31AM +0100, Pawel Jakub Dawidek wrote: > On Thu, Feb 14, 2013 at 01:20:04AM +0200, Konstantin Belousov wrote: > > On Thu, Feb 14, 2013 at 12:03:54AM +0100, Pawel Jakub Dawidek wrote: > > > http://people.freebsd.org/~pjd/patches/bindconnectat.patch > > > It implements bindat(2) and connectat(2) syscalls that will allow to > > > manage UNIX domain sockets from within capability mode sandbox. > > > They work just like any other *at(2) syscall and their prototypes look > > > like this: > > > int bindat(int fd, int s, const struct sockaddr *addr, socklen_t addrlen); > > > int connectat(int fd, int s, const struct sockaddr *addr, socklen_t addrlen); > > > Where 'fd' is directory descriptor. The only supported socket domain is > > > PF_LOCAL. > > > The audit subsystem was updated to audit the new syscalls properly. > > > Comments and reviews are welcome. > > Looking only at prototypes, I think it is useful to add at last the flags > > argument. The first application of it is for O_CLOEXEC-like flag. > And this flag should be applied to? > Note that those syscalls don't create new descriptors, they operate on > existing descriptors (directory descriptor and socket descriptor) that > should eventually have close-on-exec flag set if required. A flag parameter is a good thing; you may not know yet what you will need it for. Looking through some of the other *at calls, AT_SYMLINK_NOFOLLOW might be interesting. -- Jilles Tjoelker From owner-freebsd-arch@FreeBSD.ORG Thu Feb 14 19:47:37 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D29AF49D for ; Thu, 14 Feb 2013 19:47:37 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 55A2E9A6 for ; Thu, 14 Feb 2013 19:47:37 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r1EJlVD9013561 for ; Thu, 14 Feb 2013 21:47:31 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r1EJlVD9013561 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r1EJlVDp013560 for arch@freebsd.org; Thu, 14 Feb 2013 21:47:31 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 14 Feb 2013 21:47:31 +0200 From: Konstantin Belousov To: arch@freebsd.org Subject: Re: Unmapped I/O Message-ID: <20130214194731.GK2522@kib.kiev.ua> References: <20121219135451.GU71906@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XnmMk6h6iXODEPbR" Content-Disposition: inline In-Reply-To: <20121219135451.GU71906@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 19:47:37 -0000 --XnmMk6h6iXODEPbR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline This is an update on the message http://lists.freebsd.org/pipermail/freebsd-arch/2012-December/013672.html The work implements the unmapped kernel I/O buffers, eliminating the overhead of the mapping and IPIs, for most of i/o paths on the UFS volumes. In particular, read(2)/write(2) initiated i/o, including clustered operations and page-ins are unmapped. Also the physio is unmapped if the geom/drivers support it. Only ahci(4) is adopted to provide required support. Most other HBAs which properly use bus_dmamap_load_ccb() can be trivially converted in a way similar to ahci(4), see the changes in the patch. I did not the conversion because I cannot test. I consider the current patch ready to be committed into the HEAD. Some elements of the design were discussed with Jeff Roberson. The patch was tested by Peter Holm, a backport to stable/9 got load testing by Scott Long. I see an ~30% reduction in the system time on reading large files over UFS/ahci on the 4-core HTT machine. The only big stop there is the lack of testing on non-x86 platforms. Marius Strobl pointed out that pmap_copy_pages() for sparc64 is incorrect. For the final commit, I will disable the unmapped buffers on any architecture which was not tested at the time of commit. The patch is available at http://people.freebsd.org/~kib/misc/unmapped.13.patch --XnmMk6h6iXODEPbR Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRHT9TAAoJEJDCuSvBvK1BoP4P/jeOppSvMxn3oUX9/3zLphJw Ho82hRCKt3QBTq9LDRB4h0kMpLZQw5W/l4vqXHcJMSpQ1qJkJQN9K4Wcpc4hs8Sv qgrQfd+CvMukGLUUFFtEJLRkIwxA0wMAI/5U8LFwTjYZ8+OR5Lk2OUVw2m4LvGnn 9fHvqrSnRAIAiDuPYnWklR5uEy0YOmfkq5/vl/kXKWTShE/MBmpfrT2IvpfaIoJR czpfgFkpzqNlIfJEiHhfgQ0Q3P9sTtmdVE7H7F7hvV8F2QNkVySRKy78mcqViGYP kchcIpJQryquZtyEMXT5e1LacediwIR1OUC9jL8kPnCTXGIt9uryQJEFPqGSo4CT h9vsaKG8s+a+yUbPusinXfOj5huCk4V5npygRtPoKhTAqQxgB0W97B+anOsX2PFW PDwz/7mYSuNKc/14v0rdvhqOXOvsSn+RS1AFtds1Kjrt1yHEbocHfoxSYp3/zhtt Xr0itgDorQXZHmQfjrhkbvAL+0c3Z17kpuhROjku4/swVUSDSd0HibkqpBOPOEFQ LXBZfTxQ9LXlfPh8JGwa36/SWqywPVIwqXRJtGRX9TSx64lWWJPGDnlpwTT/ZnPp 6mgk2FbO/s3L7OW4RYudT3Do3ylfUmVZ/LMcjgCstY4yXmMS3uv5qD2FHoKmRuiR YiqwiL3fXZrG1BrJRMz1 =E2h0 -----END PGP SIGNATURE----- --XnmMk6h6iXODEPbR-- From owner-freebsd-arch@FreeBSD.ORG Thu Feb 14 22:04:36 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D3A84982 for ; Thu, 14 Feb 2013 22:04:36 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id 90E43A7 for ; Thu, 14 Feb 2013 22:04:35 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 26F827FD; Thu, 14 Feb 2013 23:01:44 +0100 (CET) Date: Thu, 14 Feb 2013 23:05:36 +0100 From: Pawel Jakub Dawidek To: Jilles Tjoelker Subject: Re: bindat(2) and connectat(2) syscalls for review. Message-ID: <20130214220536.GA1407@garage.freebsd.pl> References: <20130213230354.GC1375@garage.freebsd.pl> <20130213231942.GA94000@stack.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="J2SCkAp4GZ/dPZZf" Content-Disposition: inline In-Reply-To: <20130213231942.GA94000@stack.nl> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 22:04:36 -0000 --J2SCkAp4GZ/dPZZf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 14, 2013 at 12:19:42AM +0100, Jilles Tjoelker wrote: > On Thu, Feb 14, 2013 at 12:03:54AM +0100, Pawel Jakub Dawidek wrote: > > I'd like to commit the following patch: >=20 > > http://people.freebsd.org/~pjd/patches/bindconnectat.patch >=20 > > It implements bindat(2) and connectat(2) syscalls that will allow to > > manage UNIX domain sockets from within capability mode sandbox. >=20 > > They work just like any other *at(2) syscall and their prototypes look > > like this: >=20 > > int bindat(int fd, int s, const struct sockaddr *addr, socklen_t addrl= en); > > int connectat(int fd, int s, const struct sockaddr *addr, socklen_t ad= drlen); >=20 > > Where 'fd' is directory descriptor. The only supported socket domain is > > PF_LOCAL. >=20 > > The audit subsystem was updated to audit the new syscalls properly. >=20 > These calls are inherently limited to PF_LOCAL anyway, so why not go a > bit further and accept a pathname instead of a struct sockaddr_un that > has an arbitrary limit of 104 bytes? This appears possible because new > usrreqs were created. This is an interesting idea, which we discussed with Robert and the conclusion is that struct sockaddr will stay. Moving to pathname is a one-way street and we could imagine some, maybe odd, but possible scenarious where 'fd' doesn't represent directory, but something else, eg. a vimage-based network stack where other domains might be useful. Capabilities in FreeBSD are very young and it seems better not to close too many doors just yet. As for the 104 bytes limit, this is of course not my intention to fix the limit with those syscalls. While it would be a nice side-effect it can't be a reason to select one approach over the other. Also using directory descriptor as a starting point should help to use shorter paths. > Can the "XXXRW: Revisit this" comments before #bind and #connect in > sys/kern/capabilities.conf go away now? This is under discussion:) --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --J2SCkAp4GZ/dPZZf Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlEdX7AACgkQForvXbEpPzSqswCfcBTvtiQU2hZPwOKu/bRqceOI 4TMAn28Tn32PGMyMxJrgRW4n8PMgBQkv =wU8Z -----END PGP SIGNATURE----- --J2SCkAp4GZ/dPZZf-- From owner-freebsd-arch@FreeBSD.ORG Thu Feb 14 22:07:52 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CDC15CF1 for ; Thu, 14 Feb 2013 22:07:52 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id 7A71FD8 for ; Thu, 14 Feb 2013 22:07:52 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id F147C804; Thu, 14 Feb 2013 23:05:00 +0100 (CET) Date: Thu, 14 Feb 2013 23:08:53 +0100 From: Pawel Jakub Dawidek To: Jilles Tjoelker Subject: Re: bindat(2) and connectat(2) syscalls for review. Message-ID: <20130214220853.GB1407@garage.freebsd.pl> References: <20130213230354.GC1375@garage.freebsd.pl> <20130213232004.GA2522@kib.kiev.ua> <20130213234030.GD1375@garage.freebsd.pl> <20130214185549.GA36288@stack.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/WwmFnJnmDyWGHa4" Content-Disposition: inline In-Reply-To: <20130214185549.GA36288@stack.nl> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Konstantin Belousov , freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 22:07:52 -0000 --/WwmFnJnmDyWGHa4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 14, 2013 at 07:55:49PM +0100, Jilles Tjoelker wrote: > On Thu, Feb 14, 2013 at 12:40:31AM +0100, Pawel Jakub Dawidek wrote: > > On Thu, Feb 14, 2013 at 01:20:04AM +0200, Konstantin Belousov wrote: > > > On Thu, Feb 14, 2013 at 12:03:54AM +0100, Pawel Jakub Dawidek wrote: >=20 > > > > http://people.freebsd.org/~pjd/patches/bindconnectat.patch >=20 > > > > It implements bindat(2) and connectat(2) syscalls that will allow to > > > > manage UNIX domain sockets from within capability mode sandbox. >=20 > > > > They work just like any other *at(2) syscall and their prototypes l= ook > > > > like this: >=20 > > > > int bindat(int fd, int s, const struct sockaddr *addr, socklen_t a= ddrlen); > > > > int connectat(int fd, int s, const struct sockaddr *addr, socklen_= t addrlen); >=20 > > > > Where 'fd' is directory descriptor. The only supported socket domai= n is > > > > PF_LOCAL. >=20 > > > > The audit subsystem was updated to audit the new syscalls properly. >=20 > > > > Comments and reviews are welcome. >=20 > > > Looking only at prototypes, I think it is useful to add at last the f= lags > > > argument. The first application of it is for O_CLOEXEC-like flag. >=20 > > And this flag should be applied to? >=20 > > Note that those syscalls don't create new descriptors, they operate on > > existing descriptors (directory descriptor and socket descriptor) that > > should eventually have close-on-exec flag set if required. >=20 > A flag parameter is a good thing; you may not know yet what you will > need it for. >=20 > Looking through some of the other *at calls, AT_SYMLINK_NOFOLLOW might > be interesting. bind(2) and connect(2) are used just fine currently without any flags. I'd like to see good example before I decide to add such argument. The AT_SYMLINK_NOFOLLOW flag is of no use here, it is used for syscalls that can operate on symlinks (you can chmod, chown or stat a symlink, so it does make sense there). --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --/WwmFnJnmDyWGHa4 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlEdYHUACgkQForvXbEpPzShjgCfSTxr5EFKhV5OdLMiG5UzWT7t IHUAnRX+Bod+gyrmsTocpZZr29jSavLY =X6mU -----END PGP SIGNATURE----- --/WwmFnJnmDyWGHa4-- From owner-freebsd-arch@FreeBSD.ORG Fri Feb 15 07:56:59 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9641B242; Fri, 15 Feb 2013 07:56:59 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 5C73393C; Fri, 15 Feb 2013 07:56:59 +0000 (UTC) Received: from kruse-124.4.ixsystems.com (drawbridge.ixsystems.com [206.40.55.65]) by elvis.mu.org (Postfix) with ESMTPSA id 538E01A3C1A; Thu, 14 Feb 2013 23:56:49 -0800 (PST) Message-ID: <511DEA46.5010509@mu.org> Date: Thu, 14 Feb 2013 23:56:54 -0800 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Davide Italiano Subject: Re: [RFC/RFT] calloutng References: <50CCAB99.4040308@FreeBSD.org> <50CE5B54.3050905@FreeBSD.org> <50D03173.9080904@FreeBSD.org> <20121225232126.GA47692@alchemy.franken.de> <50DB4EFE.2020600@FreeBSD.org> <20130106152313.GD26039@alchemy.franken.de> <50EBF921.2000304@FreeBSD.org> <20130113180940.GM26039@alchemy.franken.de> <50F30CAB.3000001@FreeBSD.org> <20130121095457.GL85306@alchemy.franken.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Motin , Marius Strobl , Poul-Henning Kamp , FreeBSD Current , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 07:56:59 -0000 [ added Luigi Rizzo to thread ] On 2/11/13 12:26 PM, Davide Italiano wrote: > [trimmed old mails] > > Here's a new version of the patch: > http://people.freebsd.org/~davide/patches/calloutng-11022012.diff > > Significant bits changed (after wider discussion and suggestion by phk@): > - Introduction of the new sbintime_t type (32.32 fixed point) with the > respective conversion (sbintime2bintime, sbintime2timeval etc...) > - switch from 64.64 (struct bintime) format to measure time to sbintime_t > - Use sbintime_t to represent expected sleep time instead of measuring > it in microseconds (cpu_idle_acpi(), cpu_idle_spin() ...). Luigi and I discussed this at BAFUG tonight and he expressed an interest in shepherding the code in at this point. Luigi, can you reiterate any points that still remain before we integrate this code? thank you, -Alfred From owner-freebsd-arch@FreeBSD.ORG Fri Feb 15 12:32:13 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C284629A for ; Fri, 15 Feb 2013 12:32:13 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 7E23A8D1 for ; Fri, 15 Feb 2013 12:32:13 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 4B18C6229; Fri, 15 Feb 2013 12:32:12 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 0B621A535; Fri, 15 Feb 2013 13:32:11 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Konstantin Belousov Subject: Re: Unmapped I/O References: <20121219135451.GU71906@kib.kiev.ua> <20130214194731.GK2522@kib.kiev.ua> Date: Fri, 15 Feb 2013 13:32:11 +0100 In-Reply-To: <20130214194731.GK2522@kib.kiev.ua> (Konstantin Belousov's message of "Thu, 14 Feb 2013 21:47:31 +0200") Message-ID: <86621trc50.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 12:32:13 -0000 Konstantin Belousov writes: > I consider the current patch ready to be committed into the HEAD. > Some elements of the design were discussed with Jeff Roberson. The > patch was tested by Peter Holm, a backport to stable/9 got load > testing by Scott Long. I see an ~30% reduction in the system time on > reading large files over UFS/ahci on the 4-core HTT machine. That sounds very nice indeed. Have you observed a similar reduction in buildworld times? DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Fri Feb 15 14:11:09 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0739B808 for ; Fri, 15 Feb 2013 14:11:09 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 9F5ECE9A for ; Fri, 15 Feb 2013 14:11:08 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r1FEAxwO039650; Fri, 15 Feb 2013 16:10:59 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r1FEAxwO039650 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r1FEAxSH039649; Fri, 15 Feb 2013 16:10:59 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 15 Feb 2013 16:10:59 +0200 From: Konstantin Belousov To: Dag-Erling Sm??rgrav Subject: Re: Unmapped I/O Message-ID: <20130215141059.GO2522@kib.kiev.ua> References: <20121219135451.GU71906@kib.kiev.ua> <20130214194731.GK2522@kib.kiev.ua> <86621trc50.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fEHni0rYmTqv5Hb6" Content-Disposition: inline In-Reply-To: <86621trc50.fsf@ds4.des.no> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 14:11:09 -0000 --fEHni0rYmTqv5Hb6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 15, 2013 at 01:32:11PM +0100, Dag-Erling Sm??rgrav wrote: > Konstantin Belousov writes: > > I consider the current patch ready to be committed into the HEAD. > > Some elements of the design were discussed with Jeff Roberson. The > > patch was tested by Peter Holm, a backport to stable/9 got load > > testing by Scott Long. I see an ~30% reduction in the system time on > > reading large files over UFS/ahci on the 4-core HTT machine. >=20 > That sounds very nice indeed. Have you observed a similar reduction in > buildworld times? I measured the buildworld times with the version of the patch I had a month ago. That time, I did not see any statistically significant difference in either times (user, system, total). On the other hand, the machine I used to measure is netbooted, and despite both src/ and obj/ being on UFS over ahci, I still see a steady and significant amount of the NFS RPC going out, in particular, getattr RPC. From what I saw, this is due to execing /bin/sh and several other utilities from the base system over NFS. I believe that it induces the latency that hides any speed up. =46rom that moment, there were some bug-fixes related to speed, in particul= ar, sometimes clustered reads forced the mapping for the cluster buffer, even if not needed, which could also increase the gain. I probably do not have time to spend to reevaluate the buildworld timings, and definitely I do not see much reason to do it on my hardware. If somebody wants to do the benchmarking, please. --fEHni0rYmTqv5Hb6 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRHkHyAAoJEJDCuSvBvK1BXmYP/jn/iQ3E0tjSWaZytiCUFACw rVgc/SqBYIkQRfLQHA4ZCF8tDnkQc921INUwxSarU1joOFVroWxo9YN+zT5ONEne 0RvqoeKf5PgWneW9Me3QJV984k9Bmnx0sYkReh0CDA39GyEQPF2D5iPNHMstKCrv ZtlWEmSjEJAwlYNwtU3LepF0FmKt6xmrZohrV4pQdFKSAoKoxGZ4zIQEf0tswzrh GNm310XOXfCgiE/DyRqQlhVG8NIU7MJFcb78gMe6ozrqfFKgOtgFZYVYAQa6kVo9 eBSBxEB93cG2jC+s+T8hdj7DZdQwjWlJgaOJMzLpBtaLuJatklQjDYl8myvpZ8I/ ZxLVE2W17h5YRC5MXk0SNH1+HDwyu94eMrEvVzYXYLUbQYj6R7XdvnYqPGBEhZVB SgVwCrwRWEKHiG5sIIoRbslxUTljSscDI9QvUhs2thOpfrkgKNtvoNHy4dzMXT/w h8u134hCj7Sig4mPL1UOe3BYKS8jZvg7ohFuVJCZOW7bMJ+Krb+XbON/On2dykb0 t533zczS9eimqnpgGr7gp/WkIbjXUXoM/S5inr43FHHWtwlxbJCr/wrskWNORpgH xyzohWjB8Fm0yx9DCSbIi0Hc7KXM6GbIf+E9kGAQYhtlIEjq6hsNyFqCyPYQuDf8 +JIfY9wENg87tEHLLqQ4 =gO0q -----END PGP SIGNATURE----- --fEHni0rYmTqv5Hb6-- From owner-freebsd-arch@FreeBSD.ORG Fri Feb 15 14:12:11 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3B7918AB for ; Fri, 15 Feb 2013 14:12:11 +0000 (UTC) (envelope-from gljennjohn@googlemail.com) Received: from mail-bk0-f42.google.com (mail-bk0-f42.google.com [209.85.214.42]) by mx1.freebsd.org (Postfix) with ESMTP id BCCD7E9E for ; Fri, 15 Feb 2013 14:12:10 +0000 (UTC) Received: by mail-bk0-f42.google.com with SMTP id jk7so1581294bkc.1 for ; Fri, 15 Feb 2013 06:12:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:date:from:to:cc:subject:message-id:in-reply-to :references:reply-to:x-mailer:mime-version:content-type :content-transfer-encoding; bh=/kaT7r9kaAKt7li9URvL2b8JZ94k8YoaiKIi4R7tAOA=; b=MCEfm3lC43znxeRRyAeNTpuibvxTNt+alE753nWn21eqF0jHST0eke0OJoGUi0fQ65 WhTSUZ0NHs0/01sg4v+tdr8KfpV3yEOadggvu+sxy2F8o7j5h3JD1krb52h+IveAjCKE Od5kJepjIbqk5FCT2MTv71XjIedm4IVbejV2xP0D63cXP+Xw9d2FscMcy2f1pQmgYac7 i6DfZJkj8DS1jpVJGbF9LhU2cmpEYSzE0a8P1BlxdNRUyD/nOawayUMmdSdiO2L7a2KT Gv6UGpSWS/Y8Z3OgEkf7sn9bjZbA7qN4Pwe3VCMdiW+StcDfi19kp0kFWyoF9j1CYT1E eBbQ== X-Received: by 10.204.6.82 with SMTP id 18mr903166bky.24.1360937524485; Fri, 15 Feb 2013 06:12:04 -0800 (PST) Received: from ernst.jennejohn.org (p4FC0F310.dip.t-dialin.net. [79.192.243.16]) by mx.google.com with ESMTPS id hc16sm17788394bkc.2.2013.02.15.06.12.02 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 15 Feb 2013 06:12:03 -0800 (PST) Date: Fri, 15 Feb 2013 15:12:00 +0100 From: Gary Jennejohn To: Dag-Erling =?ISO-8859-1?Q?Sm=F8rgrav?= Subject: Re: Unmapped I/O Message-ID: <20130215151200.69cc8554@ernst.jennejohn.org> In-Reply-To: <86621trc50.fsf@ds4.des.no> References: <20121219135451.GU71906@kib.kiev.ua> <20130214194731.GK2522@kib.kiev.ua> <86621trc50.fsf@ds4.des.no> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: Konstantin Belousov , arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: gljennjohn@googlemail.com List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 14:12:11 -0000 On Fri, 15 Feb 2013 13:32:11 +0100 Dag-Erling Smørgrav wrote: > Konstantin Belousov writes: > > I consider the current patch ready to be committed into the HEAD. > > Some elements of the design were discussed with Jeff Roberson. The > > patch was tested by Peter Holm, a backport to stable/9 got load > > testing by Scott Long. I see an ~30% reduction in the system time on > > reading large files over UFS/ahci on the 4-core HTT machine. > > That sounds very nice indeed. Have you observed a similar reduction in > buildworld times? > I applied the patch and am currently running with it. Had to fix a fatal error in subr_bus_dma.c - "error may be used unitialized" or something to that effect. I don't have the patched source any longer, but I think it was at line 131. I started a build world with -j6 but unfortunately it broke off with an error which is no longer visible in the output. -- Gary Jennejohn From owner-freebsd-arch@FreeBSD.ORG Sat Feb 16 21:44:01 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 98651AB2; Sat, 16 Feb 2013 21:44:01 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 5A425D75; Sat, 16 Feb 2013 21:44:00 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 42C4B6736; Sat, 16 Feb 2013 21:38:02 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 13666908D; Sat, 16 Feb 2013 22:38:02 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Jilles Tjoelker Subject: Re: bindat(2) and connectat(2) syscalls for review. References: <20130213230354.GC1375@garage.freebsd.pl> <20130213232004.GA2522@kib.kiev.ua> <20130213234030.GD1375@garage.freebsd.pl> <20130214185549.GA36288@stack.nl> Date: Sat, 16 Feb 2013 22:38:01 +0100 In-Reply-To: <20130214185549.GA36288@stack.nl> (Jilles Tjoelker's message of "Thu, 14 Feb 2013 19:55:49 +0100") Message-ID: <86ip5saqiu.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Konstantin Belousov , freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 21:44:01 -0000 Jilles Tjoelker writes: > A flag parameter is a good thing; you may not know yet what you will > need it for. int bind(int s, const struct sockaddr *addr, socklen_t addrlen); int connect(int s, const struct sockaddr *name, socklen_t namelen); Where's the flag argument? DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Sat Feb 16 23:16:26 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id ADCB4FA8; Sat, 16 Feb 2013 23:16:26 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id 68681F4A; Sat, 16 Feb 2013 23:16:25 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 18152E63; Sun, 17 Feb 2013 00:13:33 +0100 (CET) Date: Sun, 17 Feb 2013 00:17:28 +0100 From: Pawel Jakub Dawidek To: Marcel Moolenaar Subject: Re: FDT on x86 and for non-fdtbus devices. Message-ID: <20130216231728.GC2023@garage.freebsd.pl> References: <03A622DA-EFD4-4984-8FC3-CD8B4832C32E@xcllnt.net> <8606E19D-98A2-4E2C-A9E3-5056C1BAC34E@bsdimp.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="QRj9sO5tAVLaXnSD" Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Robert N. M. Watson" , "freebsd-arch@FreeBSD.org Arch" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 23:16:26 -0000 --QRj9sO5tAVLaXnSD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 14, 2013 at 09:00:25AM -0800, Marcel Moolenaar wrote: >=20 > On Feb 14, 2013, at 6:45 AM, Robert N. M. Watson wr= ote: >=20 > >> But I'm curious why your specific example wouldn't already live in the= FDT for your board.... > >=20 > >=20 > > We want to put hardware configuration parameters in the on-board FDT. > >=20 > > We want to put software configuration parameters in the kernel targeted= for the board. >=20 > /nod >=20 > I think it's a feature to instantiate GEOMs from the FDT. > Creating a mirrored disk configuration when the disks are > already in use cannot in general be done using tasting. > The assumption that the last sector is free is invalid > with GPT and it has created conformance problems for us > already. Being able to construct the gmirror GEOM from the > FDT eliminates the need to scribble meta-data on the disk > and as such allows us to mirror 2 GPT disks at the disk > level without instantaneously becoming non-conformant. Gmirror is not the best example, but gstripe or gconcat could be configured this way. I know gmirror is not the subject here, but for those interested explanation of why gmirror is not the best example is below. The metadata is needed not only for tasting and configuring two disks as a one gmirror provider, but also for other stuff, like: - tracking synchronization progress, - being able to tell which provider is out-of-date (on first write after one of the disks break we bump a counter in other disks metadata, so we can tell when the system is rebooted and disk is available again that it needs synchronization), - being able to tell that system crashed/failed when gmirror was writing and components can be out of sync, - being able to tell which mirror component was offlined by the administrator. etc. Ideally we would also support dirty bitmap that could speed up synchronization and also needs some space (much more than single sector). --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --QRj9sO5tAVLaXnSD Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlEgE4cACgkQForvXbEpPzRaMACgvMrF3BLehHv0UQs83jU8fZ8h TzsAoIhMSUN3GmjFij8bcL0awaHln9Eu =zsmm -----END PGP SIGNATURE----- --QRj9sO5tAVLaXnSD-- From owner-freebsd-arch@FreeBSD.ORG Sat Feb 16 23:19:37 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B97F0DA for ; Sat, 16 Feb 2013 23:19:37 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id 65A36F52 for ; Sat, 16 Feb 2013 23:19:37 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 29F33E65; Sun, 17 Feb 2013 00:16:44 +0100 (CET) Date: Sun, 17 Feb 2013 00:20:39 +0100 From: Pawel Jakub Dawidek To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= Subject: Re: bindat(2) and connectat(2) syscalls for review. Message-ID: <20130216232039.GD2023@garage.freebsd.pl> References: <20130213230354.GC1375@garage.freebsd.pl> <20130213232004.GA2522@kib.kiev.ua> <20130213234030.GD1375@garage.freebsd.pl> <20130214185549.GA36288@stack.nl> <86ip5saqiu.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wULyF7TL5taEdwHz" Content-Disposition: inline In-Reply-To: <86ip5saqiu.fsf@ds4.des.no> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Konstantin Belousov , Jilles Tjoelker , freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 23:19:37 -0000 --wULyF7TL5taEdwHz Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Feb 16, 2013 at 10:38:01PM +0100, Dag-Erling Sm=F8rgrav wrote: > Jilles Tjoelker writes: > > A flag parameter is a good thing; you may not know yet what you will > > need it for. >=20 > int > bind(int s, const struct sockaddr *addr, socklen_t addrlen); >=20 > int > connect(int s, const struct sockaddr *name, socklen_t namelen); >=20 > Where's the flag argument? The is no flag argument in my patch, but it was proposed by Kostik in the e-mail Jilles replied to. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --wULyF7TL5taEdwHz Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlEgFEcACgkQForvXbEpPzSgVwCgvP/oRwciVvZcImpuyLtT0wHi V7sAn2uP47w7Ng4PsY/spO9P3WfwebTE =pcvB -----END PGP SIGNATURE----- --wULyF7TL5taEdwHz--