From owner-freebsd-arch@FreeBSD.ORG Mon Jul 22 16:04:05 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 69F1EF7E; Mon, 22 Jul 2013 16:04:05 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 464C1262B; Mon, 22 Jul 2013 16:04:05 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D5C4AB926; Mon, 22 Jul 2013 12:04:02 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Subject: Re: VOP_MKDIR/VOP_CREATE and namecache Date: Mon, 22 Jul 2013 11:10:31 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <51E968FC.20905@FreeBSD.org> In-Reply-To: <51E968FC.20905@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201307221110.32011.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 22 Jul 2013 12:04:03 -0400 (EDT) Cc: freebsd-fs@freebsd.org, 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, 22 Jul 2013 16:04:05 -0000 On Friday, July 19, 2013 12:27:40 pm Andriy Gapon wrote: > > Should VOP_MKDIR and VOP_CREATE immediately insert newly created vnodes into the > namecache? If yes, where would it be done best? FS code, VFS code, VOP > post-hooks, something else? Hmm, I'm not sure. However, if it is done, I think it needs to be done in the FS code (e.g., NFS needs to be able to add it's special timestamps). In UFS you could do this by just adding a cache_enter() call to ufs_direnter(). For NFS you would want the post-op attrs from the RPC reply (assuming it includes attrs for the parent directory). -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Jul 24 10:06:57 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 BF98F4FD for ; Wed, 24 Jul 2013 10:06:57 +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 F2FF02714 for ; Wed, 24 Jul 2013 10:06:56 +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 NAA18470 for ; Wed, 24 Jul 2013 13:06:55 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1V1vyA-00083i-V7 for freebsd-arch@FreeBSD.org; Wed, 24 Jul 2013 13:06:55 +0300 Message-ID: <51EFA71B.1070601@FreeBSD.org> Date: Wed, 24 Jul 2013 13:06:19 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130708 Thunderbird/17.0.7 MIME-Version: 1.0 To: freebsd-arch@FreeBSD.org Subject: mount(1) without /etc/fstab X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=X-VIET-VPS 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, 24 Jul 2013 10:06:57 -0000 I found behavior of mount(1) rather annoying when there is no /etc/fstab. Some systems legitimately do not need (anything in) /etc/fstab, so all of that complaining is in vain. Should mount(1) be silenced in this case? Or should we have and install an empty etc/fstab just to please mount(1)? -- Andriy Gapon From owner-freebsd-arch@FreeBSD.ORG Wed Jul 24 10:48:58 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 0AE2D974; Wed, 24 Jul 2013 10:48:58 +0000 (UTC) (envelope-from crees@bayofrum.net) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by mx1.freebsd.org (Postfix) with ESMTP id 753B8291A; Wed, 24 Jul 2013 10:48:57 +0000 (UTC) X-Trace: 576280/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$ON_NET_AUTH_ACCEPTED/Talk_Talk_Customer/2.102.104.150/None/crees@bayofrum.net X-SBRS: None X-RemoteIP: 2.102.104.150 X-IP-MAIL-FROM: crees@bayofrum.net X-SMTP-AUTH: bayofrum@uwclub.net X-MUA: Apple Mail (2.1085) X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuYJAMCv71ECZmiW/2dsb2JhbABbgwZFwUAKgQsXdIIkAQEEATocIxALDjg5HgaIHQq5G49HMwcugmRuA51viz2DFTs X-IronPort-AV: E=Sophos;i="4.89,734,1367967600"; d="scan'208";a="576280" X-IP-Direction: OUT Received: from host-2-102-104-150.as13285.net (HELO pegasus.bayofrum.net) ([2.102.104.150]) by smtp.pipex.tiscali.co.uk with ESMTP; 24 Jul 2013 11:47:47 +0100 Received: from zeus.bayofrum.net (zeus.bayofrum.net [192.168.1.151]) by pegasus.bayofrum.net (Postfix) with ESMTPA id B4D4530C2B; Wed, 24 Jul 2013 11:46:21 +0100 (BST) References: <51EFA71B.1070601@FreeBSD.org> In-Reply-To: <51EFA71B.1070601@FreeBSD.org> Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii Message-Id: <2CACBF9B-AA7F-456B-AC39-038812DA016E@bayofrum.net> Content-Transfer-Encoding: quoted-printable From: Chris Rees Subject: Re: mount(1) without /etc/fstab Date: Wed, 24 Jul 2013 11:46:20 +0100 To: Andriy Gapon X-Mailer: Apple Mail (2.1085) X-bayofrum-MailScanner-Information: Please contact the ISP for more information X-bayofrum-MailScanner-ID: B4D4530C2B.AAD27 X-bayofrum-MailScanner: Found to be clean X-bayofrum-MailScanner-From: crees@bayofrum.net X-Spam-Status: No 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, 24 Jul 2013 10:48:58 -0000 On 24 Jul 2013, at 11:06, Andriy Gapon wrote: >=20 > I found behavior of mount(1) rather annoying when there is no /etc/fstab. > Some systems legitimately do not need (anything in) /etc/fstab, so all of= that > complaining is in vain. >=20 > Should mount(1) be silenced in this case? > Or should we have and install an empty etc/fstab just to please mount(1)? I think mount should be silenced. This is a problem that has come up in a = couple of ports that complain-- the package building jails don't have fstab= s, and we have to work around that. Chris --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From owner-freebsd-arch@FreeBSD.ORG Wed Jul 24 12:29:03 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 C9D142CE; Wed, 24 Jul 2013 12:29:03 +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 B25492D23; Wed, 24 Jul 2013 12:29:02 +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 PAA20838; Wed, 24 Jul 2013 15:29:01 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1V1yBg-0008Gv-Nz; Wed, 24 Jul 2013 15:29:00 +0300 Message-ID: <51EFC854.3090908@FreeBSD.org> Date: Wed, 24 Jul 2013 15:28:04 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130708 Thunderbird/17.0.7 MIME-Version: 1.0 To: John Baldwin Subject: Re: VOP_MKDIR/VOP_CREATE and namecache References: <51E968FC.20905@FreeBSD.org> <201307221110.32011.jhb@freebsd.org> In-Reply-To: <201307221110.32011.jhb@freebsd.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, 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, 24 Jul 2013 12:29:03 -0000 on 22/07/2013 18:10 John Baldwin said the following: > On Friday, July 19, 2013 12:27:40 pm Andriy Gapon wrote: >> >> Should VOP_MKDIR and VOP_CREATE immediately insert newly created vnodes into the >> namecache? If yes, where would it be done best? FS code, VFS code, VOP >> post-hooks, something else? > > Hmm, I'm not sure. However, if it is done, I think it needs to be done in the > FS code (e.g., NFS needs to be able to add it's special timestamps). > > In UFS you could do this by just adding a cache_enter() call to ufs_direnter(). > For NFS you would want the post-op attrs from the RPC reply (assuming it includes > attrs for the parent directory). > I've read this as "don't bother" :-) Thank you for the feedback! -- Andriy Gapon From owner-freebsd-arch@FreeBSD.ORG Wed Jul 24 13:00:22 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 85AC4C39 for ; Wed, 24 Jul 2013 13:00:22 +0000 (UTC) (envelope-from bounces+612829-ba58-arch=freebsd.org@sendgrid.info) Received: from o2.bn.sendgrid.net (o2.bn.sendgrid.net [208.115.214.177]) by mx1.freebsd.org (Postfix) with SMTP id 589F42E6D for ; Wed, 24 Jul 2013 13:00:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sendgrid.me; h=from:to :subject:mime-version:content-type; s=smtpapi; bh=Mxh/9DtQj7loVq my2T8Ej7dnoOI=; b=TuIj6C3a4jADiUHWC4NRmyKN7Ei8k06U/G8q/QO+HAjhwz IE4NhBjucTZJlUiXrZYl8TT4GLtWu4dGs9rUnYaJDThxf+oWI4UbiNbeWfV4FPRF zlT4ukkfjSssZnsDRmPr8tN3S7cs4rsItEGTUGj6M23rALbdswZ6hiyfQWIFM= Received: by 10.4.35.200 with SMTP id mf33.8564.51EFCFE55 Wed, 24 Jul 2013 13:00:21 +0000 (UTC) Received: from (ool-18e496ee.dyn.optonline.net [24.228.150.238]) by mi19 (SG) with ESMTP id 14010c416a4.1f4f.51585e for ; Wed, 24 Jul 2013 13:00:21 +0000 (UTC) From: TheUrbanShopper To: Date: Wed, 24 Jul 2013 09:00:19 -0400 Subject: In This Issue: Asthma? Allergies? Here's Why, Recipes for Gut Bustin' Salads, Fit Club blog, Urban Fashion Blog X-Mailer: TOL Mailer MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=_0_.__.__TOL__Mailer__Part_Boundary_ Message-ID: <1374670821.24735745014579@mf33.sendgrid.net> X-SG-EID: PYCKI43QWrQUfl7nqliIpR4qzPlu41Kt+60rv5InnxEdhsRsSPydCWobYL9AOhVixm7CW3AoS0BexQLo1TUCFHXkYl8mBVypbR8uZwrA79duWzOBOCB/eqAP2vVuioPF X-Content-Filtered-By: Mailman/MimeDel 2.1.14 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, 24 Jul 2013 13:00:22 -0000 This is a multi-part message in MIME format. --_0_.__.__TOL__Mailer__Part_Boundary_ Content-Type: multipart/related; boundary=_1_.__.__TOL__Mailer__Part_Boundary_ --_1_.__.__TOL__Mailer__Part_Boundary_ Content-Type: text/plain Content-Transfer-Encoding: 7Bit Untitled Document
Having trouble reading this email? Click Here to go direct to TheUrbanShopper.com.
To ensure delivery, please add us@theurbanshopper.com to your Safe Sender List or Address Book.
You have received this update as a subscriber to TheUrbanShopper.com. Ensure inbox delivery by adding us@theurbanshopper.com to your SAFE SENDER or email CONTACTS list. If you'd like to unsubscribe . For more information, please read our Privacy Policy . ©2013 All Rights Reserved
--_1_.__.__TOL__Mailer__Part_Boundary_-- --_0_.__.__TOL__Mailer__Part_Boundary_-- From owner-freebsd-arch@FreeBSD.ORG Thu Jul 25 16:04:39 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 302CF8B8; Thu, 25 Jul 2013 16:04:39 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 080712118; Thu, 25 Jul 2013 16:04:39 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id ED311B926; Thu, 25 Jul 2013 12:04:37 -0400 (EDT) From: John Baldwin To: Andriy Gapon Subject: Re: VOP_MKDIR/VOP_CREATE and namecache Date: Wed, 24 Jul 2013 15:52:09 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <51E968FC.20905@FreeBSD.org> <201307221110.32011.jhb@freebsd.org> <51EFC854.3090908@FreeBSD.org> In-Reply-To: <51EFC854.3090908@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201307241552.09988.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 25 Jul 2013 12:04:38 -0400 (EDT) Cc: freebsd-fs@freebsd.org, 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, 25 Jul 2013 16:04:39 -0000 On Wednesday, July 24, 2013 8:28:04 am Andriy Gapon wrote: > on 22/07/2013 18:10 John Baldwin said the following: > > On Friday, July 19, 2013 12:27:40 pm Andriy Gapon wrote: > >> > >> Should VOP_MKDIR and VOP_CREATE immediately insert newly created vnodes into the > >> namecache? If yes, where would it be done best? FS code, VFS code, VOP > >> post-hooks, something else? > > > > Hmm, I'm not sure. However, if it is done, I think it needs to be done in the > > FS code (e.g., NFS needs to be able to add it's special timestamps). > > > > In UFS you could do this by just adding a cache_enter() call to ufs_direnter(). > > For NFS you would want the post-op attrs from the RPC reply (assuming it includes > > attrs for the parent directory). > > > > I've read this as "don't bother" :-) > Thank you for the feedback! Well, for UFS it would be a one-line change. If there is a common workload where this would help it might be interesting to benchmark. Note that UFS is careful to prime new directory entries into the existing dirhash for example (which may make priming the namecache less of a win for UFS). -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Thu Jul 25 19:37:12 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id CDFF7707 for ; Thu, 25 Jul 2013 19:37:12 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A7E892BC0 for ; Thu, 25 Jul 2013 19:37:12 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 5B21BB926 for ; Thu, 25 Jul 2013 15:37:11 -0400 (EDT) From: John Baldwin To: arch@freebsd.org Subject: EVFILT_PROC always returns an EV_EOF event Date: Thu, 25 Jul 2013 15:37:04 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201307251537.04491.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 25 Jul 2013 15:37:11 -0400 (EDT) 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, 25 Jul 2013 19:37:13 -0000 A co-worker ran into this undocumented behavior today. If you register an EVFILT_PROC event but do not set NOTE_EXIT, you can still get an event with fflags set to 0 but EV_EOF set. This is not documented in the manpage, and it seems inconsistent to me. If the caller hasn't set NOTE_EXIT, then presumably they do not wish to know about NOTE_EXIT events. I have a specific test case below (watch for NOTE_EXEC on a process that only exits). Is this behavior desired or should this be fixed? If we want it fixed I have a possible fix (tested with this test case) at http://people.freebsd.org/~jhb/patches/kevent_proc_eof.patch #include #include #include #include #include #include #include #include static pid_t master; static int kq; static void watch(uintptr_t ident, short filter, u_short flags, u_int fflags, intptr_t data, void *udata) { struct kevent ev; EV_SET(&ev, ident, filter, flags, fflags, data, udata); if (kevent(kq, &ev, 1, NULL, 0, NULL) < 0) err(1, "kevent"); } static void dump_fflags(u_int fflags) { int pipe; assert(fflags != 0); pipe = 0; #define DUMP_FLAG(FLAG) do { \ if (fflags & FLAG) { \ printf("%s" #FLAG, pipe ? " | " : ""); \ pipe = 1; \ } \ } while (0) DUMP_FLAG(NOTE_EXIT); DUMP_FLAG(NOTE_FORK); DUMP_FLAG(NOTE_EXEC); DUMP_FLAG(NOTE_TRACK); DUMP_FLAG(NOTE_TRACKERR); DUMP_FLAG(NOTE_CHILD); fflags &= ~(NOTE_EXIT | NOTE_FORK | NOTE_EXEC | NOTE_TRACK | NOTE_TRACKERR | NOTE_CHILD); if (fflags != 0) printf("%s%u", pipe ? " | " : "", fflags); } static void dump_event(struct kevent *ev) { assert(ev->filter == EVFILT_PROC); printf("pid: %5d%s flags: ", (int)ev->ident, ev->flags & EV_EOF ? " EV_EOF" : ""); dump_fflags(ev->fflags); if (ev->data != 0) printf(" data: %jd", (uintmax_t)ev->data); printf("\n"); } static void child(int fd) { pid_t pid; char c; if (fd > 0) (void)read(fd, &c, sizeof(c)); pid = fork(); if (pid == -1) err(1, "fork"); usleep(5000); exit(1); } static void waitfor(int count, const char *msg) { struct timespec ts; struct kevent ev; int rv; printf("%s:\n", msg); /* Wait up to 250 ms before timing out. */ ts.tv_sec = 0; ts.tv_nsec = 250 * 1000 * 1000; for (;;) { rv = kevent(kq, NULL, 0, &ev, 1, &ts); if (rv < 0) err(1, "kevent"); if (rv == 0) break; dump_event(&ev); --count; } if (count > 0) warnx("%d events missing for %s", count, msg); else if (count < 0) warnx("%d extra events for %s", -count, msg); } int main(int ac, char **av) { pid_t pid; int fds[2]; char c; kq = kqueue(); if (kq < 0) err(1, "kqueue"); if (pipe(fds) < 0) err(1, "pipe"); master = getpid(); printf("master: %d\n", (int)master); /* Test for a dummy EV_EOF event. */ pid = fork(); if (pid == -1) err(1, "fork"); if (pid == 0) child(fds[1]); watch(pid, EVFILT_PROC, EV_ADD, NOTE_EXEC, 0, 0); write(fds[0], &c, sizeof(c)); /* Should not get any events at all. */ waitfor(0, "dummy EV_EOF"); return (0); } -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Thu Jul 25 20:27:49 2013 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 11A1D5E5 for ; Thu, 25 Jul 2013 20:27:49 +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 CA5A92E2B for ; Thu, 25 Jul 2013 20:27:48 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id AD7D11FE; Thu, 25 Jul 2013 22:22:50 +0200 (CEST) Date: Thu, 25 Jul 2013 22:28:32 +0200 From: Pawel Jakub Dawidek To: "Jordan K. Hubbard" Subject: Re: General purpose library for name/value pairs. Message-ID: <20130725202832.GD1400@garage.freebsd.pl> References: <20130704215329.GG1402@garage.freebsd.pl> <4818.1373008073@critter.freebsd.dk> <20130705195255.GB25842@garage.freebsd.pl> <60317.1373055040@critter.freebsd.dk> <20130708150308.GE1383@garage.freebsd.pl> <717D098F-D07E-45B0-B9F0-8D8BCEF06923@mail.turbofuzz.com> <20130708213351.GB1405@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kvUQC+jR9YzypDnK" Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) 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: Thu, 25 Jul 2013 20:27:49 -0000 --kvUQC+jR9YzypDnK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Returning to this thread after a short break. I removed all {,u}int{8,16.32.64} types and implemented only 'number' type which is uint64_t. Looks much nicer now. On Mon, Jul 08, 2013 at 03:09:40PM -0700, Jordan K. Hubbard wrote: > On Jul 8, 2013, at 2:33 PM, Pawel Jakub Dawidek wrote: > >> String, Number, Boolean, Data, Date, Array and Dictionary are all plis= ts support, and Apple developers have gotten along pretty well for many yea= rs with that set (not supporting Dictionaries, btw, is a pretty fundamental= loss IMHO - it means you have to always iterate through lists to find your= stuff, which is meh!). > >=20 > > I do support nested nvlists. Doesn't that fill the gap? >=20 > Not really, no. In fact, once you support dictionaries, you'll find that= most people prefer them to lists since data can now be passed in order-ind= ependent fashion and evolved over time without breaking older code. Arrays= /lists are far less general purpose and used much less often (when I checke= d through a bunch of preference plists on one of my OS X boxes, I found arr= ays of types to be the most common). Nested dictionaries are even f= ar more common in general practice. Not sure if you looked at the API, but with nvlist you can lookup element by name: const char *nvlist_get_string(const nvlist_t *nvl, const char *name); Or do you mean that internally it is slow as it iterates the list when looking up an element? This can be easly changed to speed up the lookups, but I don't consider it a pressing problem. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com --kvUQC+jR9YzypDnK Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iEYEARECAAYFAlHxinAACgkQForvXbEpPzSiygCgien2+QdxSyOJI6Ynnr2Eh4dQ DC8An0P1/5TI2ljExCjk1hdVijWGOUWb =7Fkn -----END PGP SIGNATURE----- --kvUQC+jR9YzypDnK-- From owner-freebsd-arch@FreeBSD.ORG Thu Jul 25 22:28:47 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id F178864F for ; Thu, 25 Jul 2013 22:28:46 +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 85D9F240A for ; Thu, 25 Jul 2013 22:28:46 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 11134241; Fri, 26 Jul 2013 00:09:36 +0200 (CEST) Date: Fri, 26 Jul 2013 00:15:17 +0200 From: Pawel Jakub Dawidek To: Steve Kiernan Subject: Re: General purpose library for name/value pairs. Message-ID: <20130725221517.GH1400@garage.freebsd.pl> References: <20130704215329.GG1402@garage.freebsd.pl> <4818.1373008073@critter.freebsd.dk> <20130705195255.GB25842@garage.freebsd.pl> <60317.1373055040@critter.freebsd.dk> <20130708150308.GE1383@garage.freebsd.pl> <717D098F-D07E-45B0-B9F0-8D8BCEF06923@mail.turbofuzz.com> <20130716180606.55ec081c@stevek-ubuntu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZYOWEO2dMm2Af3e3" Content-Disposition: inline In-Reply-To: <20130716180606.55ec081c@stevek-ubuntu> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: arch@freebsd.org, Jordan Hubbard 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, 25 Jul 2013 22:28:47 -0000 --ZYOWEO2dMm2Af3e3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 16, 2013 at 06:06:06PM -0400, Steve Kiernan wrote: > On Mon, 8 Jul 2013 10:57:17 -0700 > Jordan Hubbard wrote: >=20 > >=20 > > On Jul 8, 2013, at 8:03 AM, Pawel Jakub Dawidek wrote: > >=20 > > > How about instead of supporting int8, uint8, int16, uint16, int32, > > > uint32, int64 and uint64 I'd just support 'number' type, which would = be > > > uint64_t. This shouldn't break transporting signed values and because= I > > > don't support basic types like int, long, etc. casting or conversion = has > > > to be done anyway. This would reduce number of supported types to: > >=20 > > That's a good idea. Since you're re-inventing Apple's XML property lis= t API (but without serialization and quite a few other things), keeping the= number of supported types down is much better than the converse - exposing= the details of 16/32/64 bit numbers and their signedness will hang you ove= r the long term, and you can always provide explicit conversion functions t= o/from Number for those who actually care. > >=20 > > String, Number, Boolean, Data, Date, Array and Dictionary are all plist= s support, and Apple developers have gotten along pretty well for many year= s with that set (not supporting Dictionaries, btw, is a pretty fundamental = loss IMHO - it means you have to always iterate through lists to find your = stuff, which is meh!). > >=20 > > When Apple extended the Plist metaphor for IPC (to create XPC), they al= so added out-of-band types like file and shared memory descriptors. You ha= ve file descriptors, but not shared memory. The latter is kind of importan= t if you want to do larger IPCs with this mechanism someday and want to sup= port "big payloads" transparently without passing the burden of the data ma= nagement to the application programmer. > >=20 > > Before you also come back with "but but this is a kernel API! For just= one purpose!" let me just say that it's absolutely achievable to have ONE = API for talking userland<->kernel and userland<->userland with the same typ= es and the transport mechanism(s) largely abstracted away. You don't need = two - it's already been done with one, just look next door. :) > >=20 > > If you add file serialization of this format to your picture (and add t= he dictionary type) , bingo, now you have a preferences API that FreeBSD ha= s lacked from day one ("just roll your own format and stick the file in /et= c" being the canonical response to that need). >=20 > What about looking at NetBSD's libprop? Someone already suggested that, but libprop is much much more complex than libnv. I really want something extremely easy to use, so it can be adopted quickly. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com --ZYOWEO2dMm2Af3e3 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iEYEARECAAYFAlHxo3UACgkQForvXbEpPzT6cQCfVNm1+zYwgeZRETQqvZgBHgrC +gAAmwdX6e7K/l3AfSaYUXtFUqT27+KR =6OOn -----END PGP SIGNATURE----- --ZYOWEO2dMm2Af3e3-- From owner-freebsd-arch@FreeBSD.ORG Fri Jul 26 07:15: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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 149BA828; Fri, 26 Jul 2013 07:15:07 +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 157FC28E2; Fri, 26 Jul 2013 07:15:05 +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 KAA22186; Fri, 26 Jul 2013 10:15:04 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1V2cEy-000HYR-BA; Fri, 26 Jul 2013 10:15:04 +0300 Message-ID: <51F221D4.8040308@FreeBSD.org> Date: Fri, 26 Jul 2013 10:14:28 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130708 Thunderbird/17.0.7 MIME-Version: 1.0 To: freebsd-arch@FreeBSD.org Subject: amd64: -O2 even with DEBUG X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=X-VIET-VPS 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: Fri, 26 Jul 2013 07:15:07 -0000 I wonder why amd64 is distinguished to have -O2 in COPTFLAGS even when DEBUG is defined. For all other archs it's -O for that case. Perhaps, this was discussed / explained in the past, but I would appreciate it being said again (or even written as a comment in kern.pre.mk). Thank you! -- Andriy Gapon From owner-freebsd-arch@FreeBSD.ORG Fri Jul 26 07:26:20 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3D9DE99D; Fri, 26 Jul 2013 07:26:20 +0000 (UTC) (envelope-from jordan.hubbard@gmail.com) Received: from mail-pb0-x236.google.com (mail-pb0-x236.google.com [IPv6:2607:f8b0:400e:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0D547294D; Fri, 26 Jul 2013 07:26:20 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id ro12so1591843pbb.13 for ; Fri, 26 Jul 2013 00:26:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=XH2oYOJu+JTfaBJll2RyU3wVsS68+0qDkx/3Qx3nU5c=; b=cDgk7WxuahvexZU9e7qGJzv9fju3fdo0KTECLgawGCuji6+lr7tgHSvepdhmLkCejb wK8SMwTjgkbtXVPlLmD9kOpK2L9tsxNK/nFNYrMd946gI2RgcLidHP5rxcTHFFfQxxKe yPAJkItseywbMrhdkqbTc9h7Y5r5DmM6N08TfXPeAdy6BlEnh4BZ9fVxSPjbY9kKy834 zbgttML4quQQQAZYuXS8Xp6pE/WFwLadaCPhznAi4MAuo7Jn6EmwvVm1kb5xiuirZnge I/ZT6zmCfUN042e6GSuaMqSptBmYMAMYklgEJSMUCwCxClm4wMM5MqkS4l+kfqIfVyMk EePw== X-Received: by 10.68.172.34 with SMTP id az2mr51653210pbc.201.1374823579581; Fri, 26 Jul 2013 00:26:19 -0700 (PDT) Received: from [10.20.30.11] (106.sub-70-197-1.myvzw.com. [70.197.1.106]) by mx.google.com with ESMTPSA id s5sm58417404pbo.38.2013.07.26.00.26.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 26 Jul 2013 00:26:18 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1786.1\)) Subject: Re: General purpose library for name/value pairs. From: Jordan Hubbard In-Reply-To: <20130725202832.GD1400@garage.freebsd.pl> Date: Fri, 26 Jul 2013 00:26:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <818200C6-2AF2-465D-873B-CA610A9C763A@gmail.com> References: <20130704215329.GG1402@garage.freebsd.pl> <4818.1373008073@critter.freebsd.dk> <20130705195255.GB25842@garage.freebsd.pl> <60317.1373055040@critter.freebsd.dk> <20130708150308.GE1383@garage.freebsd.pl> <717D098F-D07E-45B0-B9F0-8D8BCEF06923@mail.turbofuzz.com> <20130708213351.GB1405@garage.freebsd.pl> <20130725202832.GD1400@garage.freebsd.pl> To: Pawel Jakub Dawidek X-Mailer: Apple Mail (2.1786.1) 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, 26 Jul 2013 07:26:20 -0000 On Jul 25, 2013, at 1:28 PM, Pawel Jakub Dawidek = wrote: > Returning to this thread after a short break. I removed all > {,u}int{8,16.32.64} types and implemented only 'number' type which is > uint64_t. Looks much nicer now. Indeed! > Not sure if you looked at the API, but with nvlist you can lookup > element by name: >=20 > const char *nvlist_get_string(const nvlist_t *nvl, const char = *name); Sorry, I must have misunderstood that function since I thought it would = just get you a named string - you can also do something like this? { { "name", "Pawel Jakub Dawidek" }, { "age", 37 }, { = "favorite-float-num", 1.E027 }, { "likes", { "cats", "ZFS", "fashion = models" } }, { "company", "wheel systems" } } And then look up "name" and get a string, "age" and get a number, = "favorite-float-num" for a float, "likes" for an array of strings, etc? Thanks, - Jordan From owner-freebsd-arch@FreeBSD.ORG Fri Jul 26 07:33:25 2013 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4461ABBB for ; Fri, 26 Jul 2013 07:33:25 +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 084D929C3 for ; Fri, 26 Jul 2013 07:33:24 +0000 (UTC) Received: from localhost (58.wheelsystems.com [83.12.187.58]) by mail.dawidek.net (Postfix) with ESMTPSA id 37E6D33F; Fri, 26 Jul 2013 09:28:26 +0200 (CEST) Date: Fri, 26 Jul 2013 09:34:08 +0200 From: Pawel Jakub Dawidek To: Jordan Hubbard Subject: Re: General purpose library for name/value pairs. Message-ID: <20130726073408.GA1383@garage.freebsd.pl> References: <20130704215329.GG1402@garage.freebsd.pl> <4818.1373008073@critter.freebsd.dk> <20130705195255.GB25842@garage.freebsd.pl> <60317.1373055040@critter.freebsd.dk> <20130708150308.GE1383@garage.freebsd.pl> <717D098F-D07E-45B0-B9F0-8D8BCEF06923@mail.turbofuzz.com> <20130708213351.GB1405@garage.freebsd.pl> <20130725202832.GD1400@garage.freebsd.pl> <818200C6-2AF2-465D-873B-CA610A9C763A@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="liOOAslEiF7prFVr" Content-Disposition: inline In-Reply-To: <818200C6-2AF2-465D-873B-CA610A9C763A@gmail.com> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) 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, 26 Jul 2013 07:33:25 -0000 --liOOAslEiF7prFVr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 26, 2013 at 12:26:15AM -0700, Jordan Hubbard wrote: >=20 > On Jul 25, 2013, at 1:28 PM, Pawel Jakub Dawidek wrote: >=20 > > Returning to this thread after a short break. I removed all > > {,u}int{8,16.32.64} types and implemented only 'number' type which is > > uint64_t. Looks much nicer now. >=20 > Indeed! >=20 > > Not sure if you looked at the API, but with nvlist you can lookup > > element by name: > >=20 > > const char *nvlist_get_string(const nvlist_t *nvl, const char *name); >=20 > Sorry, I must have misunderstood that function since I thought it would j= ust get you a named string - you can also do something like this? >=20 > { { "name", "Pawel Jakub Dawidek" }, { "age", 37 }, { "favorite-float-nu= m", 1.E027 }, { "likes", { "cats", "ZFS", "fashion models" } }, { "company"= , "wheel systems" } } >=20 > And then look up "name" and get a string, "age" and get a number, "favori= te-float-num" for a float, "likes" for an array of strings, etc? Exactly. The code would look like this: static const char * const *likes =3D { "cats", "ZFS", "fashion models" }; nvlist_t *nvl; nvl =3D nvlist_create(0); nvlist_add_string(nvl, "name", "Pawel Jakub Dawidek"); nvlist_add_number(nvl, "age", 37); /* XXX: Not my age, yet:) */ /* No floats. */ nvlist_add_array_string(nvl, "likes", likes, 3); nvlist_add_string(nvl, "company", "Wheel Systems"); if (nvlist_error(nvl) !=3D 0) errx(1, "Unable to create nvlist."); Then: printf("Name: %s\nAge: %d\nCompany %s\n", nvlist_get_string(nvl, "name"), (int)nvlist_get_number(nvl, "age"), nvlist_get_string(nvl, "company")); --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com --liOOAslEiF7prFVr Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iEYEARECAAYFAlHyJnAACgkQForvXbEpPzTIMgCg5DbrGXJTWqIyjaZrJWrnGOvT VkEAoK+HWaWyl8E2OXHyxVwop8ciSXvq =j0XC -----END PGP SIGNATURE----- --liOOAslEiF7prFVr-- From owner-freebsd-arch@FreeBSD.ORG Fri Jul 26 07:51:28 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9E1C7D6 for ; Fri, 26 Jul 2013 07:51:28 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 75C662A9E for ; Fri, 26 Jul 2013 07:51:28 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id ro12so1618203pbb.41 for ; Fri, 26 Jul 2013 00:51:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=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=FtWM4z044vQCgKVM6Fn5wdDufyqK8tX7a8ZhCDMtw8o=; b=TtMaUjilwuP8ZXWyaa7/3tg+pcVbNMpWMGOluQdp7gAe/XxpGYp5K/uHgGMo/A+MOU +JvvVlA1vZis3xyjnQUyOgs6T4Dnai5tbb/kqm5jkVzKUqNh0WHZkse9BghE8y4HcSX+ 4/grcyCCLsltoGvjDbG6NXzJ40jR1EYJqKRd7xYUJvyTFPubx3JYI6d8E38e+5ng7A5P 8mZx2HDlenzQ957qlBKHyXZoFPaBBlW4aLPPl4d82OUaJP8MmslzGYpXnsKk4GueJdAz QCymDJbaW+0G8cfEk8nA9cAHbXzE3HC++8AudGx5SVI1TBFrc1takTV+a4F6Mms8u9yF KxPA== X-Received: by 10.66.155.102 with SMTP id vv6mr17925652pab.89.1374825082435; Fri, 26 Jul 2013 00:51:22 -0700 (PDT) Received: from [10.0.0.214] ([65.50.222.210]) by mx.google.com with ESMTPSA id sp4sm58519414pbc.45.2013.07.26.00.51.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 26 Jul 2013 00:51:21 -0700 (PDT) Sender: Warner Losh Subject: Re: amd64: -O2 even with DEBUG Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <51F221D4.8040308@FreeBSD.org> Date: Fri, 26 Jul 2013 00:51:19 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51F221D4.8040308@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQknFNhPuzSMMrS5lgVaESeY6iFoHgKzJONXaoExlP2Lx7ztVsvYVotkGcGCezLyZZsGrWnd 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: Fri, 26 Jul 2013 07:51:28 -0000 On Jul 26, 2013, at 12:14 AM, Andriy Gapon wrote: > I wonder why amd64 is distinguished to have -O2 in COPTFLAGS even when = DEBUG is > defined. For all other archs it's -O for that case. >=20 > Perhaps, this was discussed / explained in the past, but I would = appreciate it > being said again (or even written as a comment in kern.pre.mk). I think you may have it wrong. Everybody gets -O2, except arm and mips = which get -O for dodgy historical reasons... At least for userland... = But I don't think that's what you are talking about. For the kernel, we get everybody having -O2, except powerpc (and except = DEBUG). Looking at the code for the latter, it sure looks to me to be a mistake. = We should be setting _MINUS_O ala the powerpc case. And the = -frename-registers looks misplaced to me as well... Warner From owner-freebsd-arch@FreeBSD.ORG Fri Jul 26 08:04:27 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 68DA44A9; Fri, 26 Jul 2013 08:04:27 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail104.syd.optusnet.com.au (mail104.syd.optusnet.com.au [211.29.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id F053C2B31; Fri, 26 Jul 2013 08:04:26 +0000 (UTC) Received: from c122-106-156-23.carlnfd1.nsw.optusnet.com.au (c122-106-156-23.carlnfd1.nsw.optusnet.com.au [122.106.156.23]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id D8324421CE8; Fri, 26 Jul 2013 18:04:16 +1000 (EST) Date: Fri, 26 Jul 2013 18:04:15 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Pawel Jakub Dawidek Subject: Re: General purpose library for name/value pairs. In-Reply-To: <20130725202832.GD1400@garage.freebsd.pl> Message-ID: <20130726175858.Y1061@besplex.bde.org> References: <20130704215329.GG1402@garage.freebsd.pl> <4818.1373008073@critter.freebsd.dk> <20130705195255.GB25842@garage.freebsd.pl> <60317.1373055040@critter.freebsd.dk> <20130708150308.GE1383@garage.freebsd.pl> <717D098F-D07E-45B0-B9F0-8D8BCEF06923@mail.turbofuzz.com> <20130708213351.GB1405@garage.freebsd.pl> <20130725202832.GD1400@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=Yos2GeoX c=1 sm=1 tr=0 a=ebeQFi2P/qHVC0Yw9JDJ4g==:117 a=PO7r1zJSAAAA:8 a=kxgCfahG5_wA:10 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=_Sy8tSWxdDoA:10 a=ikobWQWbF5fDs0AyT1kA:9 a=CjuIK1q_8ugA:10 a=pvCz57ccC64A:10 a=R1H_hwPTxAgA:10 Cc: arch@freebsd.org, "Jordan K. Hubbard" 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, 26 Jul 2013 08:04:27 -0000 On Thu, 25 Jul 2013, Pawel Jakub Dawidek wrote: > Returning to this thread after a short break. I removed all > {,u}int{8,16.32.64} types and implemented only 'number' type which is > uint64_t. Looks much nicer now. The numeric type should be floating point. Or better yet, bignum. Or more practically, uintmax_t. Bruce From owner-freebsd-arch@FreeBSD.ORG Fri Jul 26 08:28:35 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 03D8D812 for ; Fri, 26 Jul 2013 08:28:35 +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 4B1A42C14 for ; Fri, 26 Jul 2013 08:28:33 +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 LAA22689; Fri, 26 Jul 2013 11:28:31 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1V2dO3-000HeM-6w; Fri, 26 Jul 2013 11:28:31 +0300 Message-ID: <51F232DE.5090707@FreeBSD.org> Date: Fri, 26 Jul 2013 11:27:10 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130708 Thunderbird/17.0.7 MIME-Version: 1.0 To: Warner Losh Subject: Re: amd64: -O2 even with DEBUG References: <51F221D4.8040308@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.5.1 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: Fri, 26 Jul 2013 08:28:35 -0000 on 26/07/2013 10:51 Warner Losh said the following: > > On Jul 26, 2013, at 12:14 AM, Andriy Gapon wrote: >> I wonder why amd64 is distinguished to have -O2 in COPTFLAGS even when DEBUG is >> defined. For all other archs it's -O for that case. >> >> Perhaps, this was discussed / explained in the past, but I would appreciate it >> being said again (or even written as a comment in kern.pre.mk). > > I think you may have it wrong. Everybody gets -O2, except arm and mips which get -O for dodgy historical reasons... At least for userland... But I don't think that's what you are talking about. Yes, I was talking about the kernel build. > For the kernel, we get everybody having -O2, except powerpc (and except DEBUG). I was talking about the DEBUG case specifically. > Looking at the code for the latter, it sure looks to me to be a mistake. We should be setting _MINUS_O ala the powerpc case. And the -frename-registers looks misplaced to me as well... Yes, that is exactly what concerned me. -- Andriy Gapon From owner-freebsd-arch@FreeBSD.ORG Fri Jul 26 12:24:26 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B7447D4E for ; Fri, 26 Jul 2013 12:24:26 +0000 (UTC) (envelope-from nbounce-653-48846-53449962-db525-58c652a7@kiccall.eu) Received: from m3.kiccall.eu (m3.kiccall.eu [88.198.82.167]) by mx1.freebsd.org (Postfix) with ESMTP id 586F92616 for ; Fri, 26 Jul 2013 12:24:26 +0000 (UTC) Received: from list653 (m3.kiccall.eu [88.198.82.167]) by m3.kiccall.eu (Postfix) with ESMTP id 7ACE321C346A for ; Fri, 26 Jul 2013 14:19:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=kiccall.eu; s=default; t=1374841173; bh=ZqPm4BHHx/hN1NoTeuiLsjk9dsc=; h=Content-Type:MIME-Version:From:Sender:Message-Id:List-Unsubscribe: Subject:To:Date; b=j+JXcqeaWh0dFEmFkDRqY3R1FM1Ib+dFUPQQiiNyEhar1t2sHDuxG183lIA8FjSaw F7xOJsmUwwyjqKHgmzwPjMRdd4wOY4YQt4xzNiJ+UPG0PqBcviMr29YQ2shhDBSpTb yrQf+x/ybUuWuYrGJbGwygApkin667eM2c+2AJ9Q= MIME-Version: 1.0 From: SWISS-CORNER.RO Sender: SWISS-CORNER.RO Precedence: bulk Message-Id: <20130726121933.82907.653.48846.53449962.nl@kiccall.ro> Subject: Mari reduceri!!!! To: Arch Freebsd Date: Fri, 26 Jul 2013 12:19:33 -0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Reply-To: "SWISS-CORNER.RO" List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 12:24:26 -0000 Pentru a vedea _[online][1]_ acest mesaj personalizat [click aici][2] Va rugam sa adaugati adresa de mail **office@swiss-corner.ro** in Address Book pentru a va asigura ca primiti mesajele noastre in **Inbox**. [1]: # [2]: # [3]: http://nl.kiccall.eu/v/48846/53449962/db5257709145293735ab87e738884c9a= ?like=3Dfacebook [4]: http://nl.kiccall.eu/v/48846/53449962/db5257709145293735ab87e738884c9a= ?share=3Dtwitter [5]: http://nl.kiccall.eu/v/48846/53449962/db5257709145293735ab87e738884c9a= ?share=3Dlinkedin [6]: http://nl.kiccall.eu/v/48846/53449962/db5257709145293735ab87e738884c9a= ?like=3Dplusone [7]: http://nl.kiccall.eu/v/48846/53449962/db5257709145293735ab87e738884c9a= ?share=3Dpinterest Reduceri estivale in limita stocului disponibil! [8]: http://nl.kiccall.eu/clk/48846/53449962/996954/97770cc4d78543b26eb2a4c= 3a11a72fa Blanc D`or Bracelet [9]: http://nl.kiccall.eu/clk/48846/53449962/996960/a974451001eb8c9d290a587= 242fdd52c Orange ## [10]: http://nl.kiccall.eu/clk/48846/53449962/996956/f7faeb6731078e51d40e68= 399e94a903 red [11]: http://nl.kiccall.eu/clk/48846/53449962/996953/ca1dd2170f241af20a7e62= c97d0f1266 Rosie Mumu Cow ## **[http://nl.kiccall.eu/clk/48846/53449962/996958/b6ea6308ce2999151a5635526= 22c7c80][12]** **[office@swiss-corner.ro][13]** [12]: http://nl.kiccall.eu/clk/48846/53449962/996952/474884b0d94192d4de71b7= 61d4e6c7f4 [13]: mailto:office@swiss-corner.ro **0256/220 823** **0728/692 891** Pentru a vedea [online][14] acest mesaj personalizat [click aici][15] Pentru dezabonare instant [click aici][16]. [14]: http://nl.kiccall.eu/v/48846/53449962/db5257709145293735ab87e738884c9a [15]: http://nl.kiccall.eu/v/48846/53449962/db5257709145293735ab87e738884c9a [16]: http://nl.kiccall.eu/unsubscribe/653/48846/53449962/db525770914529373= 5ab87e738884c9a From owner-freebsd-arch@FreeBSD.ORG Fri Jul 26 18:10:25 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4CBA79C3 for ; Fri, 26 Jul 2013 18:10:25 +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 11E792992 for ; Fri, 26 Jul 2013 18:10:24 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id C94A7501; Fri, 26 Jul 2013 20:05:25 +0200 (CEST) Date: Fri, 26 Jul 2013 20:11:08 +0200 From: Pawel Jakub Dawidek To: Bruce Evans Subject: Re: General purpose library for name/value pairs. Message-ID: <20130726181108.GA1811@garage.freebsd.pl> References: <20130704215329.GG1402@garage.freebsd.pl> <4818.1373008073@critter.freebsd.dk> <20130705195255.GB25842@garage.freebsd.pl> <60317.1373055040@critter.freebsd.dk> <20130708150308.GE1383@garage.freebsd.pl> <717D098F-D07E-45B0-B9F0-8D8BCEF06923@mail.turbofuzz.com> <20130708213351.GB1405@garage.freebsd.pl> <20130725202832.GD1400@garage.freebsd.pl> <20130726175858.Y1061@besplex.bde.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Nq2Wo0NMKNjxTN9z" Content-Disposition: inline In-Reply-To: <20130726175858.Y1061@besplex.bde.org> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: arch@freebsd.org, "Jordan K. Hubbard" 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, 26 Jul 2013 18:10:25 -0000 --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 26, 2013 at 06:04:15PM +1000, Bruce Evans wrote: > On Thu, 25 Jul 2013, Pawel Jakub Dawidek wrote: >=20 > > Returning to this thread after a short break. I removed all > > {,u}int{8,16.32.64} types and implemented only 'number' type which is > > uint64_t. Looks much nicer now. >=20 > The numeric type should be floating point. Or better yet, bignum. Or > more practically, uintmax_t. The uintmax_t in theory can change in the future, which would make sending numeric type from system with larger uintmax_t to system with smaller uintmax_t problematic. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com --Nq2Wo0NMKNjxTN9z Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iEYEARECAAYFAlHyu7wACgkQForvXbEpPzShrwCfdIZdmnVXi4gCs0aaE6c2hJck F/MAoPa+oiODDerChFk9dcJRy2PUhdsy =kqRi -----END PGP SIGNATURE----- --Nq2Wo0NMKNjxTN9z-- From owner-freebsd-arch@FreeBSD.ORG Fri Jul 26 18:52:34 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 536E4A4E; Fri, 26 Jul 2013 18:52:34 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 089E32B52; Fri, 26 Jul 2013 18:52:33 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r6QIqWjK079192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Jul 2013 11:52:33 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r6QIqWEu079191; Fri, 26 Jul 2013 11:52:32 -0700 (PDT) (envelope-from jmg) Date: Fri, 26 Jul 2013 11:52:32 -0700 From: John-Mark Gurney To: John Baldwin Subject: Re: EVFILT_PROC always returns an EV_EOF event Message-ID: <20130726185232.GR26412@funkthat.com> Mail-Followup-To: John Baldwin , arch@freebsd.org References: <201307251537.04491.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201307251537.04491.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Fri, 26 Jul 2013 11:52:33 -0700 (PDT) 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, 26 Jul 2013 18:52:34 -0000 John Baldwin wrote this message on Thu, Jul 25, 2013 at 15:37 -0400: > A co-worker ran into this undocumented behavior today. If you register an > EVFILT_PROC event but do not set NOTE_EXIT, you can still get an event with > fflags set to 0 but EV_EOF set. This is not documented in the manpage, and > it seems inconsistent to me. If the caller hasn't set NOTE_EXIT, then > presumably they do not wish to know about NOTE_EXIT events. This is probably to let the consumer know that the process no longer exists and that there will be no more events delivered for this process.. This allows the process to clean up in this case.. If you look at the code in filt_proc in kern_event.c, you'll also see that is forces _ONESHOT to be set, meaning that the knote will be deleted... It is someone documented: EV_EOF Filters may set this flag to indicate filter-specific EOF condition. But I do agree that the documentation could be better... I don't have a strong opinion on which behavior is best. I do think that delivering the EOF is best, since on an fd, you get _EOF when the socket closes, even though you didn't ask for it.. it's implicit.. > I have a specific test case below (watch for NOTE_EXEC on a process that only > exits). Is this behavior desired or should this be fixed? If we want it > fixed I have a possible fix (tested with this test case) at > http://people.freebsd.org/~jhb/patches/kevent_proc_eof.patch Nice addition of drop... The patch looks good if we decide to go this route... > #include > #include > #include > #include > #include > #include > #include > #include > > static pid_t master; > static int kq; > > static void > watch(uintptr_t ident, short filter, u_short flags, u_int fflags, > intptr_t data, void *udata) > { > struct kevent ev; > > EV_SET(&ev, ident, filter, flags, fflags, data, udata); > if (kevent(kq, &ev, 1, NULL, 0, NULL) < 0) > err(1, "kevent"); > } > > static void > dump_fflags(u_int fflags) > { > int pipe; > > assert(fflags != 0); > pipe = 0; > #define DUMP_FLAG(FLAG) do { \ > if (fflags & FLAG) { \ > printf("%s" #FLAG, pipe ? " | " : ""); \ > pipe = 1; \ > } \ > } while (0) > > DUMP_FLAG(NOTE_EXIT); > DUMP_FLAG(NOTE_FORK); > DUMP_FLAG(NOTE_EXEC); > DUMP_FLAG(NOTE_TRACK); > DUMP_FLAG(NOTE_TRACKERR); > DUMP_FLAG(NOTE_CHILD); > > fflags &= ~(NOTE_EXIT | NOTE_FORK | NOTE_EXEC | NOTE_TRACK | > NOTE_TRACKERR | NOTE_CHILD); > if (fflags != 0) > printf("%s%u", pipe ? " | " : "", fflags); > } > > static void > dump_event(struct kevent *ev) > { > > assert(ev->filter == EVFILT_PROC); > printf("pid: %5d%s flags: ", (int)ev->ident, > ev->flags & EV_EOF ? " EV_EOF" : ""); > dump_fflags(ev->fflags); > if (ev->data != 0) > printf(" data: %jd", (uintmax_t)ev->data); > printf("\n"); > } > > static void > child(int fd) > { > pid_t pid; > char c; > > if (fd > 0) > (void)read(fd, &c, sizeof(c)); > pid = fork(); > if (pid == -1) > err(1, "fork"); > usleep(5000); > exit(1); > } > > static void > waitfor(int count, const char *msg) > { > struct timespec ts; > struct kevent ev; > int rv; > > printf("%s:\n", msg); > > /* Wait up to 250 ms before timing out. */ > ts.tv_sec = 0; > ts.tv_nsec = 250 * 1000 * 1000; > for (;;) { > rv = kevent(kq, NULL, 0, &ev, 1, &ts); > if (rv < 0) > err(1, "kevent"); > if (rv == 0) > break; > dump_event(&ev); > --count; > } > > if (count > 0) > warnx("%d events missing for %s", count, msg); > else if (count < 0) > warnx("%d extra events for %s", -count, msg); > } > > int > main(int ac, char **av) > { > pid_t pid; > int fds[2]; > char c; > > kq = kqueue(); > if (kq < 0) > err(1, "kqueue"); > if (pipe(fds) < 0) > err(1, "pipe"); > master = getpid(); > printf("master: %d\n", (int)master); > > /* Test for a dummy EV_EOF event. */ > pid = fork(); > if (pid == -1) > err(1, "fork"); > if (pid == 0) > child(fds[1]); > watch(pid, EVFILT_PROC, EV_ADD, NOTE_EXEC, 0, 0); > write(fds[0], &c, sizeof(c)); > > /* Should not get any events at all. */ > waitfor(0, "dummy EV_EOF"); > > return (0); > } > > -- > John Baldwin > _______________________________________________ > 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" -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@FreeBSD.ORG Fri Jul 26 18:54:26 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7D7A4B1E; Fri, 26 Jul 2013 18:54:26 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4F47C2B62; Fri, 26 Jul 2013 18:54:25 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r6QIsP9r079223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Jul 2013 11:54:25 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r6QIsPrE079222; Fri, 26 Jul 2013 11:54:25 -0700 (PDT) (envelope-from jmg) Date: Fri, 26 Jul 2013 11:54:25 -0700 From: John-Mark Gurney To: Andriy Gapon Subject: Re: amd64: -O2 even with DEBUG Message-ID: <20130726185425.GS26412@funkthat.com> Mail-Followup-To: Andriy Gapon , freebsd-arch@freebsd.org References: <51F221D4.8040308@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51F221D4.8040308@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Fri, 26 Jul 2013 11:54:25 -0700 (PDT) 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: Fri, 26 Jul 2013 18:54:26 -0000 Andriy Gapon wrote this message on Fri, Jul 26, 2013 at 10:14 +0300: > I wonder why amd64 is distinguished to have -O2 in COPTFLAGS even when DEBUG is > defined. For all other archs it's -O for that case. > > Perhaps, this was discussed / explained in the past, but I would appreciate it > being said again (or even written as a comment in kern.pre.mk). It's probably because at least gcc produces terrible amd64 code w/o it... It will constantly reload the register it uses to do relative loads w/ the same value even though nothing changed... makes performance suck... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@FreeBSD.ORG Fri Jul 26 19:01:11 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 41AE7E39; Fri, 26 Jul 2013 19:01:11 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 159F82BC8; Fri, 26 Jul 2013 19:01:10 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r6QJ1A04079384 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Jul 2013 12:01:10 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r6QJ1A2K079383; Fri, 26 Jul 2013 12:01:10 -0700 (PDT) (envelope-from jmg) Date: Fri, 26 Jul 2013 12:01:10 -0700 From: John-Mark Gurney To: Pawel Jakub Dawidek Subject: Re: General purpose library for name/value pairs. Message-ID: <20130726190110.GT26412@funkthat.com> Mail-Followup-To: Pawel Jakub Dawidek , arch@freebsd.org References: <20130704215329.GG1402@garage.freebsd.pl> <4818.1373008073@critter.freebsd.dk> <20130705195255.GB25842@garage.freebsd.pl> <60317.1373055040@critter.freebsd.dk> <20130708150308.GE1383@garage.freebsd.pl> <717D098F-D07E-45B0-B9F0-8D8BCEF06923@mail.turbofuzz.com> <20130708213351.GB1405@garage.freebsd.pl> <20130725202832.GD1400@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130725202832.GD1400@garage.freebsd.pl> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Fri, 26 Jul 2013 12:01:10 -0700 (PDT) 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, 26 Jul 2013 19:01:11 -0000 Pawel Jakub Dawidek wrote this message on Thu, Jul 25, 2013 at 22:28 +0200: > Returning to this thread after a short break. I removed all > {,u}int{8,16.32.64} types and implemented only 'number' type which is > uint64_t. Looks much nicer now. I didn't check the new version, but maybe a function that allows you to specify the min/max values allows... This would let the user not have to write their own range checking code... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@FreeBSD.ORG Fri Jul 26 20:20:35 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2C785409 for ; Fri, 26 Jul 2013 20:20:35 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 06C6C2E80 for ; Fri, 26 Jul 2013 20:20:35 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id EEA37B97A; Fri, 26 Jul 2013 16:20:33 -0400 (EDT) From: John Baldwin To: "John-Mark Gurney" Subject: Re: EVFILT_PROC always returns an EV_EOF event Date: Fri, 26 Jul 2013 16:18:19 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <201307251537.04491.jhb@freebsd.org> <20130726185232.GR26412@funkthat.com> In-Reply-To: <20130726185232.GR26412@funkthat.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201307261618.19408.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 26 Jul 2013 16:20:34 -0400 (EDT) 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, 26 Jul 2013 20:20:35 -0000 On Friday, July 26, 2013 2:52:32 pm John-Mark Gurney wrote: > John Baldwin wrote this message on Thu, Jul 25, 2013 at 15:37 -0400: > > A co-worker ran into this undocumented behavior today. If you register an > > EVFILT_PROC event but do not set NOTE_EXIT, you can still get an event with > > fflags set to 0 but EV_EOF set. This is not documented in the manpage, and > > it seems inconsistent to me. If the caller hasn't set NOTE_EXIT, then > > presumably they do not wish to know about NOTE_EXIT events. > > This is probably to let the consumer know that the process no longer > exists and that there will be no more events delivered for this process.. > This allows the process to clean up in this case.. If you look at the > code in filt_proc in kern_event.c, you'll also see that is forces > _ONESHOT to be set, meaning that the knote will be deleted... > > It is someone documented: > EV_EOF Filters may set this flag to indicate filter-specific EOF > condition. > > But I do agree that the documentation could be better... > > I don't have a strong opinion on which behavior is best. I do think > that delivering the EOF is best, since on an fd, you get _EOF when the > socket closes, even though you didn't ask for it.. it's implicit.. Well, processes aren't fd's. Also, why have both NOTE_EXIT and EV_EOF for the same thing? Also, the doc says "may" for EV_EOF, meaning it's not guaranteed (and can not be there if there isn't a filter-specific EOF condition). It seems to me that the code used EV_ONESHOT as a workaround to cleanup the knote since it couldn't do it safely in filt_proc(), but I'm curious what other folks think? I tried my test on OS X and it does not return the spurious EV_EOF event if you don't register for NOTE_EXIT. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Fri Jul 26 20:41:57 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7251772B; Fri, 26 Jul 2013 20:41:57 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 35BDB2F29; Fri, 26 Jul 2013 20:41:56 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::49d1:fcb1:811a:f805] (unknown [IPv6:2001:7b8:3a7:0:49d1:fcb1:811a:f805]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id E01E95C5A; Fri, 26 Jul 2013 22:41:48 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: amd64: -O2 even with DEBUG From: Dimitry Andric In-Reply-To: <51F221D4.8040308@FreeBSD.org> Date: Fri, 26 Jul 2013 22:41:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <77E59DA2-2110-4FB0-A8E3-0995E98E1DAA@FreeBSD.org> References: <51F221D4.8040308@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1508) 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: Fri, 26 Jul 2013 20:41:57 -0000 On Jul 26, 2013, at 09:14, Andriy Gapon wrote: > I wonder why amd64 is distinguished to have -O2 in COPTFLAGS even when = DEBUG is > defined. For all other archs it's -O for that case. >=20 > Perhaps, this was discussed / explained in the past, but I would = appreciate it > being said again (or even written as a comment in kern.pre.mk). Yes please, I already suggested this some time ago, here: = http://lists.freebsd.org/pipermail/freebsd-current/2011-December/030631.ht= ml though the first part of the patch I posted (making sure -frename-registers is only used for gcc) is already implemented. The only other part was to make amd64 use ${_MINUS_O} just like the other arches. -Dimitry From owner-freebsd-arch@FreeBSD.ORG Fri Jul 26 21:14:03 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7039BB0; Fri, 26 Jul 2013 21:14:03 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail110.syd.optusnet.com.au (mail110.syd.optusnet.com.au [211.29.132.97]) by mx1.freebsd.org (Postfix) with ESMTP id 2FAAE207B; Fri, 26 Jul 2013 21:14:02 +0000 (UTC) Received: from c122-106-156-23.carlnfd1.nsw.optusnet.com.au (c122-106-156-23.carlnfd1.nsw.optusnet.com.au [122.106.156.23]) by mail110.syd.optusnet.com.au (Postfix) with ESMTPS id EE2797806EF; Sat, 27 Jul 2013 07:13:52 +1000 (EST) Date: Sat, 27 Jul 2013 07:13:51 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Pawel Jakub Dawidek Subject: Re: General purpose library for name/value pairs. In-Reply-To: <20130726181108.GA1811@garage.freebsd.pl> Message-ID: <20130727070531.D4895@besplex.bde.org> References: <20130704215329.GG1402@garage.freebsd.pl> <4818.1373008073@critter.freebsd.dk> <20130705195255.GB25842@garage.freebsd.pl> <60317.1373055040@critter.freebsd.dk> <20130708150308.GE1383@garage.freebsd.pl> <717D098F-D07E-45B0-B9F0-8D8BCEF06923@mail.turbofuzz.com> <20130708213351.GB1405@garage.freebsd.pl> <20130725202832.GD1400@garage.freebsd.pl> <20130726175858.Y1061@besplex.bde.org> <20130726181108.GA1811@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=Yos2GeoX c=1 sm=1 tr=0 a=ebeQFi2P/qHVC0Yw9JDJ4g==:117 a=PO7r1zJSAAAA:8 a=kxgCfahG5_wA:10 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=_Sy8tSWxdDoA:10 a=ctWZexKtWnL2h3DUuaYA:9 a=CjuIK1q_8ugA:10 Cc: arch@freebsd.org, "Jordan K. Hubbard" 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, 26 Jul 2013 21:14:03 -0000 On Fri, 26 Jul 2013, Pawel Jakub Dawidek wrote: > On Fri, Jul 26, 2013 at 06:04:15PM +1000, Bruce Evans wrote: >> On Thu, 25 Jul 2013, Pawel Jakub Dawidek wrote: >> >>> Returning to this thread after a short break. I removed all >>> {,u}int{8,16.32.64} types and implemented only 'number' type which is >>> uint64_t. Looks much nicer now. >> >> The numeric type should be floating point. Or better yet, bignum. Or >> more practically, uintmax_t. > > The uintmax_t in theory can change in the future, which would make > sending numeric type from system with larger uintmax_t to system with > smaller uintmax_t problematic. Using uint64_t is especially broken then, since uint64_t is too small to represent numbers on the system with larger uintmax_t. But how is the data sent across systems by your API? Bruce From owner-freebsd-arch@FreeBSD.ORG Fri Jul 26 21:17:15 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 87F112DA for ; Fri, 26 Jul 2013 21:17:15 +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 4C35120B7 for ; Fri, 26 Jul 2013 21:17:14 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id EC5335A5; Fri, 26 Jul 2013 23:12:09 +0200 (CEST) Date: Fri, 26 Jul 2013 23:17:51 +0200 From: Pawel Jakub Dawidek To: Bruce Evans Subject: Re: General purpose library for name/value pairs. Message-ID: <20130726211751.GB1811@garage.freebsd.pl> References: <20130705195255.GB25842@garage.freebsd.pl> <60317.1373055040@critter.freebsd.dk> <20130708150308.GE1383@garage.freebsd.pl> <717D098F-D07E-45B0-B9F0-8D8BCEF06923@mail.turbofuzz.com> <20130708213351.GB1405@garage.freebsd.pl> <20130725202832.GD1400@garage.freebsd.pl> <20130726175858.Y1061@besplex.bde.org> <20130726181108.GA1811@garage.freebsd.pl> <20130727070531.D4895@besplex.bde.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DKU6Jbt7q3WqK7+M" Content-Disposition: inline In-Reply-To: <20130727070531.D4895@besplex.bde.org> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: arch@freebsd.org, "Jordan K. Hubbard" 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, 26 Jul 2013 21:17:15 -0000 --DKU6Jbt7q3WqK7+M Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 27, 2013 at 07:13:51AM +1000, Bruce Evans wrote: > On Fri, 26 Jul 2013, Pawel Jakub Dawidek wrote: >=20 > > On Fri, Jul 26, 2013 at 06:04:15PM +1000, Bruce Evans wrote: > >> On Thu, 25 Jul 2013, Pawel Jakub Dawidek wrote: > >> > >>> Returning to this thread after a short break. I removed all > >>> {,u}int{8,16.32.64} types and implemented only 'number' type which is > >>> uint64_t. Looks much nicer now. > >> > >> The numeric type should be floating point. Or better yet, bignum. Or > >> more practically, uintmax_t. > > > > The uintmax_t in theory can change in the future, which would make > > sending numeric type from system with larger uintmax_t to system with > > smaller uintmax_t problematic. >=20 > Using uint64_t is especially broken then, since uint64_t is too small to > represent numbers on the system with larger uintmax_t. [...] At least the user is aware of the size and is not surprised by some undefined behaviour. > [...] But how is the > data sent across systems by your API? By nvlist_send(sock, nvl). --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com --DKU6Jbt7q3WqK7+M Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iEYEARECAAYFAlHy538ACgkQForvXbEpPzR3NwCg1QMaWepCetNaiW60cquHB1az JBQAn0OL/eKto6mR2+TNT/kJbdzOggFC =s8bc -----END PGP SIGNATURE----- --DKU6Jbt7q3WqK7+M-- From owner-freebsd-arch@FreeBSD.ORG Sat Jul 27 00:45:02 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3B2DC6EB for ; Sat, 27 Jul 2013 00:45:02 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-pb0-f43.google.com (mail-pb0-f43.google.com [209.85.160.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 12DAD28F0 for ; Sat, 27 Jul 2013 00:45:01 +0000 (UTC) Received: by mail-pb0-f43.google.com with SMTP id md12so2587486pbc.2 for ; Fri, 26 Jul 2013 17:45:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=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=fgE+CCBgRjF+lSalQkmZOscuMM5fYpQxppHoTRVxw6M=; b=Wv18NWoe+Wcz0vGS2X8YrXQglXgz5mHvaJR30NziQYy7ufqhU/v7u58aAqh39MO5/q QzSIpU6vztmfTuNBxz7EUXjw+zSGxqAUjHazyeO0I5/6VCK/y3SXX5dv6S+YdA8ayPZR 8sHy3lPEZThqv7wy+ah+18Mb2XQ0Kc37fBkqB2YOpG0BUuLa99Ci7gmV9LxM76uZbiVQ 6lbRXEbN6EZ+vYiVwTamJ2Uj0+5dTNIupIQTZaxFp3g35CETKY9FvSVaMtKs1aPDBT5J tbUd+IBNlwskUeF1k2pZXHnBOHnTIeHTpC7Vct0GeMdTQ4lU0gWqtAgCWq1RAGy9pF0D giAw== X-Received: by 10.66.160.3 with SMTP id xg3mr27565695pab.28.1374885901219; Fri, 26 Jul 2013 17:45:01 -0700 (PDT) Received: from [10.45.125.101] ([156.39.10.22]) by mx.google.com with ESMTPSA id ht5sm62617206pbb.29.2013.07.26.17.44.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 26 Jul 2013 17:45:00 -0700 (PDT) Sender: Warner Losh Subject: Re: amd64: -O2 even with DEBUG Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20130726185425.GS26412@funkthat.com> Date: Fri, 26 Jul 2013 17:44:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51F221D4.8040308@FreeBSD.org> <20130726185425.GS26412@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQko61/0VC2ITEOcUlGVG+v/2+1naj7w3J1oosvIytrg8FOgeYwuxP8E0RmwXpYvXOckGbGY Cc: 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: Sat, 27 Jul 2013 00:45:02 -0000 On Jul 26, 2013, at 11:54 AM, John-Mark Gurney wrote: > Andriy Gapon wrote this message on Fri, Jul 26, 2013 at 10:14 +0300: >> I wonder why amd64 is distinguished to have -O2 in COPTFLAGS even = when DEBUG is >> defined. For all other archs it's -O for that case. >>=20 >> Perhaps, this was discussed / explained in the past, but I would = appreciate it >> being said again (or even written as a comment in kern.pre.mk). >=20 > It's probably because at least gcc produces terrible amd64 code w/o > it... It will constantly reload the register it uses to do relative > loads w/ the same value even though nothing changed... makes = performance > suck...=20 Still looks like it is implemented wrongly though... Warner From owner-freebsd-arch@FreeBSD.ORG Sat Jul 27 04:17:00 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 26312A93 for ; Sat, 27 Jul 2013 04:17:00 +0000 (UTC) (envelope-from johnandsara2@cox.net) Received: from eastrmfepo201.cox.net (eastrmfepo201.cox.net [68.230.241.216]) by mx1.freebsd.org (Postfix) with ESMTP id C70242690 for ; Sat, 27 Jul 2013 04:16:59 +0000 (UTC) Received: from eastrmimpo210 ([68.230.241.225]) by eastrmfepo201.cox.net (InterMail vM.8.01.05.09 201-2260-151-124-20120717) with ESMTP id <20130727041652.LCAO3846.eastrmfepo201.cox.net@eastrmimpo210> for ; Sat, 27 Jul 2013 00:16:52 -0400 Received: from [192.168.3.22] ([72.209.222.174]) by eastrmimpo210 with cox id 5GGs1m0053mNb2Y01GGsxA; Sat, 27 Jul 2013 00:16:52 -0400 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A020203.51F349B4.0096,ss=1,re=0.000,fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=2.0 cv=fILnK+me c=1 sm=1 a=RZXkl5K4sfjB2XQwGxStDQ==:17 a=f5xKl4ys9bwA:10 a=JZmkJHaIjS4A:10 a=G8Uczd0VNMoA:10 a=Wajolswj7cQA:10 a=8nJEP1OIZ-IA:10 a=kviXuzpPAAAA:8 a=Vdp-kwHCbhwA:10 a=ndarulzW-dxtTV8orJQA:9 a=wPNLvfGTeEIA:10 a=RZXkl5K4sfjB2XQwGxStDQ==:117 X-CM-Score: 0.00 Authentication-Results: cox.net; none Message-ID: <51F34AE0.8000605@cox.net> Date: Sat, 27 Jul 2013 00:21:52 -0400 From: "John D. Hendrickson and Sara Darnell" User-Agent: Thunderbird 2.0.0.24 (X11/20100228) MIME-Version: 1.0 To: Chris Rees Subject: Re: mount(1) without /etc/fstab References: <51EFA71B.1070601@FreeBSD.org> <4Ap21m01Q2X408g01Ap3sn> In-Reply-To: <4Ap21m01Q2X408g01Ap3sn> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Andriy Gapon , freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: johnandsara2@cox.net List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jul 2013 04:17:00 -0000 i agree. you should be jailed if you f'up mount so that it ignores fstab figure it out. don't break it. Chris Rees wrote: > On 24 Jul 2013, at 11:06, Andriy Gapon wrote: > >> I found behavior of mount(1) rather annoying when there is no /etc/fstab. >> Some systems legitimately do not need (anything in) /etc/fstab, so all of that >> complaining is in vain. >> >> Should mount(1) be silenced in this case? >> Or should we have and install an empty etc/fstab just to please mount(1)? > > I think mount should be silenced. This is a problem that has come up in a couple of ports that complain-- the package building jails don't have fstabs, and we have to work around that. > > Chris From owner-freebsd-arch@FreeBSD.ORG Sat Jul 27 07:24:31 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5ABE2AB2 for ; Sat, 27 Jul 2013 07:24:31 +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 A51AC2AA6 for ; Sat, 27 Jul 2013 07:24:30 +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 KAA05424 for ; Sat, 27 Jul 2013 10:24:29 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1V2yrc-000NCK-MV for freebsd-arch@freebsd.org; Sat, 27 Jul 2013 10:24:28 +0300 Message-ID: <51F37578.2080405@FreeBSD.org> Date: Sat, 27 Jul 2013 10:23:36 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130708 Thunderbird/17.0.7 MIME-Version: 1.0 To: freebsd-arch@FreeBSD.org Subject: Re: amd64: -O2 even with DEBUG References: <51F221D4.8040308@FreeBSD.org> <20130726185425.GS26412@funkthat.com> In-Reply-To: <20130726185425.GS26412@funkthat.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 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: Sat, 27 Jul 2013 07:24:31 -0000 on 26/07/2013 21:54 John-Mark Gurney said the following: > Andriy Gapon wrote this message on Fri, Jul 26, 2013 at 10:14 +0300: >> I wonder why amd64 is distinguished to have -O2 in COPTFLAGS even when DEBUG is >> defined. For all other archs it's -O for that case. >> >> Perhaps, this was discussed / explained in the past, but I would appreciate it >> being said again (or even written as a comment in kern.pre.mk). > > It's probably because at least gcc produces terrible amd64 code w/o > it... It will constantly reload the register it uses to do relative > loads w/ the same value even though nothing changed... makes performance > suck... Well, we are talking about the DEBUG case. So I am not sure if better performance has more importance than better debugging. And I believe that -O2 does make debugging harder. -- Andriy Gapon