From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 17 12:11:08 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B59FF106566C for ; Sun, 17 Apr 2011 12:11:08 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 6F9F98FC0C for ; Sun, 17 Apr 2011 12:11:08 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1QBQoh-000EDX-AP; Sun, 17 Apr 2011 15:11:03 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: "J. Hellenthal" In-reply-to: <20110416233839.GA72223@DataIX.net> References: <8CDCA9824BFE47E-176C-A720@web-mmc-d04.sysops.aol.com> <20110416233839.GA72223@DataIX.net> Comments: In-reply-to "J. Hellenthal" message dated "Sat, 16 Apr 2011 19:38:39 -0400." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 17 Apr 2011 15:11:03 +0300 From: Daniel Braniss Message-ID: Cc: freebsd-hackers@freebsd.org, dieterbsd@engineer.com Subject: Re: Add SUM sysctl X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 12:11:08 -0000 > > --Kj7319i9nmIyA2yE > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > On Sat, Apr 16, 2011 at 04:46:53PM -0600, Warren Block wrote: > >On Sat, 16 Apr 2011, dieterbsd@engineer.com wrote: > > > >>Suggestion 2: The kernel may not have an official flag for single > >>vs multi user mode but you can fake it. Try something like > >>"pgrep syslogd". If syslogd is running assume multiuser mode. If > >>syslogd is not running assume single user mode. > > > >Another option: kern.hostid is set nonzero pretty early in the rc > >scripts. > > Same as getty(8). That also will not be running in SU and in most cases > is a clear indication that nothing else is running unless you have a > remote only machine without a console in which you have purposely > disabled getty(8). > > --=20 > > Regards, > J. Hellenthal > WWJD when something gets too complicated, it's usualy helpful to look for other ways out: the /(root) + /usr + kernel-debuging + src is less than 1GB, so what I do (when diskless is not an option), I have a 2 partitions, both bootable, and so i ALWAYS update the non active one, then 1- I always have a working / in case the update screwed something 2- I can update without problems. my $.02 danny From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 17 13:35:09 2011 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10B7C106564A; Sun, 17 Apr 2011 13:35:09 +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 25A1A8FC13; Sun, 17 Apr 2011 13:35:07 +0000 (UTC) Received: from porto.topspin.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 QAA21224; Sun, 17 Apr 2011 16:35:06 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1QBS82-000MFY-IT; Sun, 17 Apr 2011 16:35:06 +0300 Message-ID: <4DAAEC89.1090103@FreeBSD.org> Date: Sun, 17 Apr 2011 16:35:05 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110308 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: hackers@FreeBSD.org, freebsd-threads@FreeBSD.org References: <4DA98197.8060104@FreeBSD.org> In-Reply-To: <4DA98197.8060104@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=x-viet-vps Content-Transfer-Encoding: 7bit Cc: Subject: Re: puzzled: fork +libthr X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 13:35:09 -0000 on 16/04/2011 14:46 Andriy Gapon said the following: > > Guys, > > I am trying to debug this chromium issue: > http://trillian.chruetertee.ch/chromium/ticket/13 > Not sure SOCK_SEQPACKET mentioned in the ticket is an actual culprit, the > problem that interests me is that pthread_cond_wait() returns EPERM where it > shouldn't. That happens on stable/8. > > I compared ktrace of chromium on stable/8 and head. Startup traces are very > similar until execution gets to one particular place. At that place stable/8 > chromium executes pthread_cond_wait - I see _umtx_op(UMTX_OP_CV_WAIT) and that's > where EPERM is returned. On the other hand it seems that head chromium executes > something different at exactly the same place, perhaps sem_wait - I see > _umtx_op(UMTX_OP_WAIT_UINT_PRIVATE). So this is puzzle #1 for me why chromimum > build or run-time chooses a different thing to call/use at that place. OK, this was simple. This is because of the new userland condvar implementation in head. The call is the same pthread_cond_wait, just the different implementation in libthr. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 17 14:39:46 2011 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97EE61065674; Sun, 17 Apr 2011 14:39:46 +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 AB1268FC16; Sun, 17 Apr 2011 14:39:45 +0000 (UTC) Received: from porto.topspin.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 RAA21629; Sun, 17 Apr 2011 17:39:44 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1QBT8Z-000MGx-TU; Sun, 17 Apr 2011 17:39:43 +0300 Message-ID: <4DAAFBAF.90700@FreeBSD.org> Date: Sun, 17 Apr 2011 17:39:43 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110308 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: hackers@FreeBSD.org, freebsd-threads@FreeBSD.org References: <4DA98197.8060104@FreeBSD.org> In-Reply-To: <4DA98197.8060104@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=x-viet-vps Content-Transfer-Encoding: 7bit Cc: Subject: Re: puzzled: fork +libthr X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 14:39:46 -0000 on 16/04/2011 14:46 Andriy Gapon said the following: > The second puzzle is the EPERM return value itself, on stable/8. > From what I seem chromium does a bunch of forks before it gets to the place of > interest. My debugging shows that those forks are "single-threaded" (i.e. code > in thr_fork.c is not called). And then in a process/thread that makes that > pthread_cond_wait call I see that libthr and kernel have different opinions > about what current TID is. Userland part uses what is actually a kernel TID of > its parent thread (the one that called fork). And given how the work is divided > between userland and kernel in libthr, that mismatch leads to serious consequences. > > So my question is why libthr doesn't see its actual TID. Maybe some > initialization code is not invoked. BTW, chromium is linked to both libc and > libthr (per ldd). But it seems that there are no pthread calls up the fork > chain until that pthread_cond_wait call. The second problem seems to be caused by chrome binary being linked to libc and libthr in "incorrect order", libc comes before libthr in ldd output. My debugging shows that fork is resolved from libc, not from libthr. Not sure what to blame here: - build toolchain for putting libc before libthr - rtld for not preferring libthr over libc - libc/libthr for being split into two pieces in the current way -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 17 15:42:07 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4F6E1065672; Sun, 17 Apr 2011 15:42:07 +0000 (UTC) (envelope-from eischen@vigrid.com) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 8E4A28FC0C; Sun, 17 Apr 2011 15:42:07 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.4/8.14.4/NETPLEX) with ESMTP id p3HFL7Um024525; Sun, 17 Apr 2011 11:21:07 -0400 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.6 (mail.netplex.net [204.213.176.10]); Sun, 17 Apr 2011 11:21:07 -0400 (EDT) Date: Sun, 17 Apr 2011 11:21:07 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Andriy Gapon In-Reply-To: <4DAAFBAF.90700@FreeBSD.org> Message-ID: References: <4DA98197.8060104@FreeBSD.org> <4DAAFBAF.90700@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: hackers@freebsd.org, freebsd-threads@freebsd.org Subject: Re: puzzled: fork +libthr X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 15:42:07 -0000 On Sun, 17 Apr 2011, Andriy Gapon wrote: > on 16/04/2011 14:46 Andriy Gapon said the following: >> The second puzzle is the EPERM return value itself, on stable/8. >> From what I seem chromium does a bunch of forks before it gets to the place of >> interest. My debugging shows that those forks are "single-threaded" (i.e. code >> in thr_fork.c is not called). And then in a process/thread that makes that >> pthread_cond_wait call I see that libthr and kernel have different opinions >> about what current TID is. Userland part uses what is actually a kernel TID of >> its parent thread (the one that called fork). And given how the work is divided >> between userland and kernel in libthr, that mismatch leads to serious consequences. >> >> So my question is why libthr doesn't see its actual TID. Maybe some >> initialization code is not invoked. BTW, chromium is linked to both libc and >> libthr (per ldd). But it seems that there are no pthread calls up the fork >> chain until that pthread_cond_wait call. > > The second problem seems to be caused by chrome binary being linked to libc and > libthr in "incorrect order", libc comes before libthr in ldd output. My > debugging shows that fork is resolved from libc, not from libthr. > Not sure what to blame here: > - build toolchain for putting libc before libthr > - rtld for not preferring libthr over libc > - libc/libthr for being split into two pieces in the current way - The build procedure for chromium. libc/[libc_r, libpthread, libthr] have always behaved that way since the libc/libc_r split. -- DE From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 17 15:56:58 2011 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10B3A1065694; Sun, 17 Apr 2011 15:56:58 +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 23A518FC17; Sun, 17 Apr 2011 15:56:56 +0000 (UTC) Received: from porto.topspin.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 SAA22261; Sun, 17 Apr 2011 18:56:53 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1QBULF-000MIi-CZ; Sun, 17 Apr 2011 18:56:53 +0300 Message-ID: <4DAB0DC4.4060504@FreeBSD.org> Date: Sun, 17 Apr 2011 18:56:52 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110308 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Daniel Eischen References: <4DA98197.8060104@FreeBSD.org> <4DAAFBAF.90700@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: hackers@FreeBSD.org, freebsd-threads@FreeBSD.org Subject: Re: puzzled: fork +libthr X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 15:56:58 -0000 on 17/04/2011 18:21 Daniel Eischen said the following: > On Sun, 17 Apr 2011, Andriy Gapon wrote: > >> on 16/04/2011 14:46 Andriy Gapon said the following: >>> The second puzzle is the EPERM return value itself, on stable/8. >>> From what I seem chromium does a bunch of forks before it gets to the place of >>> interest. My debugging shows that those forks are "single-threaded" (i.e. code >>> in thr_fork.c is not called). And then in a process/thread that makes that >>> pthread_cond_wait call I see that libthr and kernel have different opinions >>> about what current TID is. Userland part uses what is actually a kernel TID of >>> its parent thread (the one that called fork). And given how the work is divided >>> between userland and kernel in libthr, that mismatch leads to serious >>> consequences. >>> >>> So my question is why libthr doesn't see its actual TID. Maybe some >>> initialization code is not invoked. BTW, chromium is linked to both libc and >>> libthr (per ldd). But it seems that there are no pthread calls up the fork >>> chain until that pthread_cond_wait call. >> >> The second problem seems to be caused by chrome binary being linked to libc and >> libthr in "incorrect order", libc comes before libthr in ldd output. My >> debugging shows that fork is resolved from libc, not from libthr. >> Not sure what to blame here: >> - build toolchain for putting libc before libthr >> - rtld for not preferring libthr over libc >> - libc/libthr for being split into two pieces in the current way > > - The build procedure for chromium. > > libc/[libc_r, libpthread, libthr] have always behaved that > way since the libc/libc_r split. Well, I wouldn't blame it so expressly: -pthread is the first option on the linkage command line, there is -lc there also. I would expect that that would do the right thing, but it doesn't. And that's a PITA for porting. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 17 18:42:07 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4BF41065673; Sun, 17 Apr 2011 18:42:07 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 624858FC12; Sun, 17 Apr 2011 18:42:07 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.4/8.14.4/NETPLEX) with ESMTP id p3HILvuX006335; Sun, 17 Apr 2011 14:21:57 -0400 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.6 (mail.netplex.net [204.213.176.10]); Sun, 17 Apr 2011 14:21:57 -0400 (EDT) Date: Sun, 17 Apr 2011 14:21:57 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Andriy Gapon In-Reply-To: <4DAB0DC4.4060504@FreeBSD.org> Message-ID: References: <4DA98197.8060104@FreeBSD.org> <4DAAFBAF.90700@FreeBSD.org> <4DAB0DC4.4060504@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: hackers@freebsd.org, freebsd-threads@freebsd.org Subject: Re: puzzled: fork +libthr X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 18:42:07 -0000 On Sun, 17 Apr 2011, Andriy Gapon wrote: > on 17/04/2011 18:21 Daniel Eischen said the following: >> On Sun, 17 Apr 2011, Andriy Gapon wrote: >> >>> on 16/04/2011 14:46 Andriy Gapon said the following: >>>> The second puzzle is the EPERM return value itself, on stable/8. >>>> From what I seem chromium does a bunch of forks before it gets to the place of >>>> interest. My debugging shows that those forks are "single-threaded" (i.e. code >>>> in thr_fork.c is not called). And then in a process/thread that makes that >>>> pthread_cond_wait call I see that libthr and kernel have different opinions >>>> about what current TID is. Userland part uses what is actually a kernel TID of >>>> its parent thread (the one that called fork). And given how the work is divided >>>> between userland and kernel in libthr, that mismatch leads to serious >>>> consequences. >>>> >>>> So my question is why libthr doesn't see its actual TID. Maybe some >>>> initialization code is not invoked. BTW, chromium is linked to both libc and >>>> libthr (per ldd). But it seems that there are no pthread calls up the fork >>>> chain until that pthread_cond_wait call. >>> >>> The second problem seems to be caused by chrome binary being linked to libc and >>> libthr in "incorrect order", libc comes before libthr in ldd output. My >>> debugging shows that fork is resolved from libc, not from libthr. >>> Not sure what to blame here: >>> - build toolchain for putting libc before libthr >>> - rtld for not preferring libthr over libc >>> - libc/libthr for being split into two pieces in the current way >> >> - The build procedure for chromium. >> >> libc/[libc_r, libpthread, libthr] have always behaved that >> way since the libc/libc_r split. > > Well, I wouldn't blame it so expressly: -pthread is the first option on the > linkage command line, there is -lc there also. I would expect that that would > do the right thing, but it doesn't. And that's a PITA for porting. ports have been doing the right thing for years; I think they probably just remove the explicit -lc because -lc is implied. I'm not saying that you couldn't change the linker to ignore -lc, but we've gotten (so far) without it. I recall it was a little bit of work to get some ports to behave correctly, but it was very managable. But perhaps @ports has a different view of history ;-) -- DE From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 17 19:49:57 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C91F106566B for ; Sun, 17 Apr 2011 19:49:57 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id C09768FC12 for ; Sun, 17 Apr 2011 19:49:56 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlYGAAZEq02DaFvO/2dsb2JhbACET5NMjjiyXo9EgSmDTnoEjgM X-IronPort-AV: E=Sophos;i="4.64,228,1301889600"; d="scan'208";a="118615383" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 17 Apr 2011 15:49:48 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 9BCB5B3F3A for ; Sun, 17 Apr 2011 15:49:48 -0400 (EDT) Date: Sun, 17 Apr 2011 15:49:48 -0400 (EDT) From: Rick Macklem To: freebsd-hackers@freebsd.org Message-ID: <397135152.167477.1303069788579.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE7 (Win)/6.0.10_GA_2692) Subject: SMP question w.r.t. reading kernel variables X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 19:49:57 -0000 Hi, I should know the answer to this, but... When reading a global kernel variable, where its modifications are protected by a mutex, is it necessary to get the mutex lock to just read its value? For example: A if ((mp->mnt_kern_flag & MNTK_UNMOUNTF) != 0) return (EPERM); versus B MNT_ILOCK(mp); if ((mp->mnt_kern_flag & MNTK_UNMOUNTF) != 0) { MNT_IUNLOCK(mp); return (EPERM); } MNT_IUNLOCK(mp); My hunch is that B is necessary if you need an up-to-date value for the variable (mp->mnt_kern_flag in this case). Is that correct? Thanks in advance for help with this, rick From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 17 20:52:10 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C53E6106564A for ; Sun, 17 Apr 2011 20:52:10 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7F7838FC18 for ; Sun, 17 Apr 2011 20:52:10 +0000 (UTC) Received: by gxk28 with SMTP id 28so1991791gxk.13 for ; Sun, 17 Apr 2011 13:52:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3GOBVwEaPQTOzzxu57f41FATGqIpWKPY0bDintYTi3o=; b=kPENSthUkxgSOiPbDtw2H/wKqBdTO1AQoTOxQB4Y5/OCo8sedaMtWgJKqi0tMf5WA3 RmsszoMwiIfkNye8x5ktwxXveRos5lQ1WgraBghaShlPLoWgcNO0LvonZCp4ZV2nVyrf hYmkoa299uY3zHGZhr72RKtKlVAe2Q1W3gMr4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=ogvAfdAJqAnQx8LIRVTtrv7jzUIfcQWgt026OFOFTOtyOp0clUfgPnlyWzo3HVBfwz pKviyDK8ie2B5cNzga0bnxLMrLSkjb60wUoE9KO+wlsOskBWXJUQ8nqILKb4Ww5Ia1Nu 8G5vW+rAAhUYEOcCeo3S5E/iwxOu3aRWJgHpE= MIME-Version: 1.0 Received: by 10.236.76.161 with SMTP id b21mr2914736yhe.222.1303071764189; Sun, 17 Apr 2011 13:22:44 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.236.103.131 with HTTP; Sun, 17 Apr 2011 13:22:44 -0700 (PDT) In-Reply-To: <397135152.167477.1303069788579.JavaMail.root@erie.cs.uoguelph.ca> References: <397135152.167477.1303069788579.JavaMail.root@erie.cs.uoguelph.ca> Date: Sun, 17 Apr 2011 22:22:44 +0200 X-Google-Sender-Auth: UktoYauQTiw8XO7uQg-FsJeeyPg Message-ID: From: Attilio Rao To: Rick Macklem Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: SMP question w.r.t. reading kernel variables X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 20:52:10 -0000 2011/4/17 Rick Macklem : > Hi, > > I should know the answer to this, but... When reading a global kernel > variable, where its modifications are protected by a mutex, is it > necessary to get the mutex lock to just read its value? > > For example: > A =C2=A0 =C2=A0if ((mp->mnt_kern_flag & MNTK_UNMOUNTF) !=3D 0) > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return (EPERM); > versus > B =C2=A0 =C2=A0MNT_ILOCK(mp); > =C2=A0 =C2=A0 if ((mp->mnt_kern_flag & MNTK_UNMOUNTF) !=3D 0) { > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MNT_IUNLOCK(mp); > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return (EPERM); > =C2=A0 =C2=A0 } > =C2=A0 =C2=A0 MNT_IUNLOCK(mp); > > My hunch is that B is necessary if you need an up-to-date value > for the variable (mp->mnt_kern_flag in this case). > > Is that correct? > > Thanks in advance for help with this, rick In general, FreeBSD kernel assumes that read and writes of the word boundry and of the int types are always atomic. Considering this, if a kernel variable is of int type or word boundry size you don't strictly need a lock there. Anyway, locking also bring some side effect, like usage of memory and compiler barriers... while it is true that bounded read/writes should be seq points, it is not too obvious to predict if the barrier is necessary or not, is implied or not in every architecture we support. Said that, for a matter of consistency and of better semantic, I prefer to also lock "simple" read/writes when the objects are explicitly equipped to do that. Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 17 20:59:55 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 014DF106564A for ; Sun, 17 Apr 2011 20:59:54 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 34CB28FC19 for ; Sun, 17 Apr 2011 20:59:53 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p3HKxopr024389 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 17 Apr 2011 23:59:50 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p3HKxoAw027646; Sun, 17 Apr 2011 23:59:50 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p3HKxovA027645; Sun, 17 Apr 2011 23:59:50 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 17 Apr 2011 23:59:50 +0300 From: Kostik Belousov To: Rick Macklem Message-ID: <20110417205950.GV48734@deviant.kiev.zoral.com.ua> References: <397135152.167477.1303069788579.JavaMail.root@erie.cs.uoguelph.ca> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kAOhhqH5290wydqT" Content-Disposition: inline In-Reply-To: <397135152.167477.1303069788579.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-hackers@freebsd.org Subject: Re: SMP question w.r.t. reading kernel variables X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 20:59:55 -0000 --kAOhhqH5290wydqT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 17, 2011 at 03:49:48PM -0400, Rick Macklem wrote: > Hi, >=20 > I should know the answer to this, but... When reading a global kernel > variable, where its modifications are protected by a mutex, is it > necessary to get the mutex lock to just read its value? >=20 > For example: > A if ((mp->mnt_kern_flag & MNTK_UNMOUNTF) !=3D 0) > return (EPERM); > versus > B MNT_ILOCK(mp); > if ((mp->mnt_kern_flag & MNTK_UNMOUNTF) !=3D 0) { > MNT_IUNLOCK(mp); > return (EPERM); > } > MNT_IUNLOCK(mp); >=20 > My hunch is that B is necessary if you need an up-to-date value > for the variable (mp->mnt_kern_flag in this case). >=20 > Is that correct? mnt_kern_flag read is atomic on all architectures. If, as I suspect, the fragment is for the VFS_UNMOUNT() fs method, then VFS guarantees the stability of mnt_kern_flag, by blocking other attempts to unmount until current one is finished. If not, then either you do not need the lock, or provided snipped which takes a lock is unsufficient, since you are dropping the lock but continue the action that depends on the flag not being set. --kAOhhqH5290wydqT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk2rVMYACgkQC3+MBN1Mb4gB3ACePUpmsKcRi+YR8JrDJV9eILIE FvIAoOd7y/4YwblAStOkizqUNQ+0bamZ =6NGS -----END PGP SIGNATURE----- --kAOhhqH5290wydqT-- From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 17 22:23:45 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92689106564A for ; Sun, 17 Apr 2011 22:23:45 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 546DE8FC08 for ; Sun, 17 Apr 2011 22:23:45 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAHFnq02DaFvO/2dsb2JhbACETqIEiG+qQo9FgSmDTnoEjgM X-IronPort-AV: E=Sophos;i="4.64,229,1301889600"; d="scan'208";a="117733651" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 17 Apr 2011 18:23:44 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 8B86EB3F30; Sun, 17 Apr 2011 18:23:44 -0400 (EDT) Date: Sun, 17 Apr 2011 18:23:44 -0400 (EDT) From: Rick Macklem To: Kostik Belousov Message-ID: <1146958696.171268.1303079024509.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20110417205950.GV48734@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE7 (Win)/6.0.10_GA_2692) Cc: freebsd-hackers@freebsd.org Subject: Re: SMP question w.r.t. reading kernel variables X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 22:23:45 -0000 > On Sun, Apr 17, 2011 at 03:49:48PM -0400, Rick Macklem wrote: > > Hi, > > > > I should know the answer to this, but... When reading a global > > kernel > > variable, where its modifications are protected by a mutex, is it > > necessary to get the mutex lock to just read its value? > > > > For example: > > A if ((mp->mnt_kern_flag & MNTK_UNMOUNTF) != 0) > > return (EPERM); > > versus > > B MNT_ILOCK(mp); > > if ((mp->mnt_kern_flag & MNTK_UNMOUNTF) != 0) { > > MNT_IUNLOCK(mp); > > return (EPERM); > > } > > MNT_IUNLOCK(mp); > > > > My hunch is that B is necessary if you need an up-to-date value > > for the variable (mp->mnt_kern_flag in this case). > > > > Is that correct? > > mnt_kern_flag read is atomic on all architectures. > If, as I suspect, the fragment is for the VFS_UNMOUNT() fs method, > then VFS guarantees the stability of mnt_kern_flag, by blocking > other attempts to unmount until current one is finished. > If not, then either you do not need the lock, or provided snipped > which takes a lock is unsufficient, since you are dropping the lock > but continue the action that depends on the flag not being set. Sounds like A should be ok then. The tests matter when dounmount() calls VFS_SYNC() and VFS_UNMOUNT(), pretty much as you guessed. To be honest, most of it will be the thread doing the dounmount() call, although other threads fall through VOP_INACTIVE() while they are terminating in VFS_UNMOUNT() and these need to do the test, too. { I just don't know much about the SMP stuff, so I don't know when a cache on another core might still have a stale copy of a value. I've heard the term "memory barrier", but don't really know what it means.:-) Thanks, rick From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 17 23:22:27 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0078E1065673; Sun, 17 Apr 2011 23:22:27 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6DCE08FC14; Sun, 17 Apr 2011 23:22:26 +0000 (UTC) Received: by vws18 with SMTP id 18so4067190vws.13 for ; Sun, 17 Apr 2011 16:22:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:date:from:to:cc:subject:message-id:in-reply-to :references:x-mailer:mime-version:content-type; bh=/R20/6IpQBNTb1NhS8o97alWsvXPGA10n7sVlJgjSEo=; b=wT7pm+VrVubl+sydBP2jo3b9wHz0h+E59Cfnva2qvOlD5Lza7m5iGerApwrV6KJKGo ZtWEj+vdm6GUdrqj3Qqy98wsFCevPw1xcoydl+zk/45jpfFrEUrahwjvZtSlMSjmxouQ lLQrNU3iLXZZikmCjGqn6rpIDrV/MjFZ0781g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=sv4cLnf8TOd2pxTos6gEO08GCjUykDM6+xZtXXy0wQ6EcjD3+kamE+F+uF4mR1U4Tq iST/D0Pm5Px9AUtimrtKhoBfl6bakGxH1RzTLCTC9/J7BGLYRyxj/9NNecO3rD9iv8Yk M36k2FeJviE+1IrG0IVPCLLKJQdkeczN+6FgU= Received: by 10.52.173.168 with SMTP id bl8mr2078721vdc.106.1303081094508; Sun, 17 Apr 2011 15:58:14 -0700 (PDT) Received: from kan.dnsalias.net (c-24-63-226-98.hsd1.ma.comcast.net [24.63.226.98]) by mx.google.com with ESMTPS id h23sm3000284vbz.21.2011.04.17.15.58.12 (version=SSLv3 cipher=OTHER); Sun, 17 Apr 2011 15:58:13 -0700 (PDT) Date: Sun, 17 Apr 2011 18:58:07 -0400 From: Alexander Kabaev To: Andriy Gapon Message-ID: <20110417185807.1a06347a@kan.dnsalias.net> In-Reply-To: <4DAAFBAF.90700@FreeBSD.org> References: <4DA98197.8060104@FreeBSD.org> <4DAAFBAF.90700@FreeBSD.org> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/4RPTx2z_gCy3dk77ArUp3nn"; protocol="application/pgp-signature" Cc: hackers@FreeBSD.org, freebsd-threads@FreeBSD.org Subject: Re: puzzled: fork +libthr X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 23:22:27 -0000 --Sig_/4RPTx2z_gCy3dk77ArUp3nn Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sun, 17 Apr 2011 17:39:43 +0300 Andriy Gapon wrote: > on 16/04/2011 14:46 Andriy Gapon said the following: > > The second puzzle is the EPERM return value itself, on stable/8. > > From what I seem chromium does a bunch of forks before it gets to > > the place of interest. My debugging shows that those forks are > > "single-threaded" (i.e. code in thr_fork.c is not called). And > > then in a process/thread that makes that pthread_cond_wait call I > > see that libthr and kernel have different opinions about what > > current TID is. Userland part uses what is actually a kernel TID > > of its parent thread (the one that called fork). And given how the > > work is divided between userland and kernel in libthr, that > > mismatch leads to serious consequences. > >=20 > > So my question is why libthr doesn't see its actual TID. Maybe some > > initialization code is not invoked. BTW, chromium is linked to > > both libc and libthr (per ldd). But it seems that there are no > > pthread calls up the fork chain until that pthread_cond_wait call. >=20 > The second problem seems to be caused by chrome binary being linked > to libc and libthr in "incorrect order", libc comes before libthr in > ldd output. My debugging shows that fork is resolved from libc, not > from libthr. Not sure what to blame here: > - build toolchain for putting libc before libthr > - rtld for not preferring libthr over libc > - libc/libthr for being split into two pieces in the current way Why rtld would make any special allowances for libthr?! It does exactly what it is told to do, just as it should. --=20 Alexander Kabaev --Sig_/4RPTx2z_gCy3dk77ArUp3nn Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iD8DBQFNq3CDQ6z1jMm+XZYRAgN6AJ4yIEHX69BJmHGpR7RbyLQWOSbPcQCgwpdw A00+NB4c9I0kDFp3IBWiSTQ= =5L07 -----END PGP SIGNATURE----- --Sig_/4RPTx2z_gCy3dk77ArUp3nn-- From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 18 00:54:46 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5B8F106564A; Mon, 18 Apr 2011 00:54:46 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2FF6C8FC14; Mon, 18 Apr 2011 00:54:45 +0000 (UTC) Received: by qwc9 with SMTP id 9so2637334qwc.13 for ; Sun, 17 Apr 2011 17:54:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:date:from:to:cc:subject:message-id:in-reply-to :references:x-mailer:mime-version:content-type; bh=3aj6+XS3Sux759LVDUb9/NKYUF/B5a+gmQP9aNoH3G4=; b=BhdRoskGuWqKrRUEKLRJlt/LDcac7Mh4rA8h9pcoHxIe/q/XUd+z6LNPvxoT1slyEo eefGS1aLdXmrC/R7v9tLdYfYjWGZjuEATq5oRe6AO+PsO3bjUsQN2UaRLckmDM1CV0RW MyrxQsNMWv24tR8ZEbsumUvQAQe84qBJqdHck= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=UJQK5Z0Id2otHU0HKiBcnyq6wiDwOkj0+EvhwzLrmWLAYQLyZnHuRG6VRbtTF5P3wK VY75/u/wQ6u5iX6R2SrED7P1PFZe8yLmUzanWA7rxgy+5ji5W41gbu2yYYIRQMGKVxqh aya2jD+qc/scWhMN14qdvAX/psacQm10AxMLw= Received: by 10.224.70.206 with SMTP id e14mr2291452qaj.82.1303088085476; Sun, 17 Apr 2011 17:54:45 -0700 (PDT) Received: from kan.dnsalias.net (c-24-63-226-98.hsd1.ma.comcast.net [24.63.226.98]) by mx.google.com with ESMTPS id k2sm3687845qcu.31.2011.04.17.17.54.43 (version=SSLv3 cipher=OTHER); Sun, 17 Apr 2011 17:54:44 -0700 (PDT) Date: Sun, 17 Apr 2011 20:54:38 -0400 From: Alexander Kabaev To: Andriy Gapon Message-ID: <20110417205438.69235fc4@kan.dnsalias.net> In-Reply-To: <4DAB0DC4.4060504@FreeBSD.org> References: <4DA98197.8060104@FreeBSD.org> <4DAAFBAF.90700@FreeBSD.org> <4DAB0DC4.4060504@FreeBSD.org> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/j2JDM.XEw90xCQARPs0Hy1Z"; protocol="application/pgp-signature" Cc: freebsd-threads@FreeBSD.org, hackers@FreeBSD.org Subject: Re: puzzled: fork +libthr X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 00:54:46 -0000 --Sig_/j2JDM.XEw90xCQARPs0Hy1Z Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sun, 17 Apr 2011 18:56:52 +0300 Andriy Gapon wrote: > on 17/04/2011 18:21 Daniel Eischen said the following: > > On Sun, 17 Apr 2011, Andriy Gapon wrote: > >=20 > >> on 16/04/2011 14:46 Andriy Gapon said the following: > >>> The second puzzle is the EPERM return value itself, on stable/8. > >>> From what I seem chromium does a bunch of forks before it gets to > >>> the place of interest. My debugging shows that those forks are > >>> "single-threaded" (i.e. code in thr_fork.c is not called). And > >>> then in a process/thread that makes that pthread_cond_wait call I > >>> see that libthr and kernel have different opinions about what > >>> current TID is. Userland part uses what is actually a kernel TID > >>> of its parent thread (the one that called fork). And given how > >>> the work is divided between userland and kernel in libthr, that > >>> mismatch leads to serious consequences. > >>> > >>> So my question is why libthr doesn't see its actual TID. Maybe > >>> some initialization code is not invoked. BTW, chromium is linked > >>> to both libc and libthr (per ldd). But it seems that there are > >>> no pthread calls up the fork chain until that pthread_cond_wait > >>> call. > >> > >> The second problem seems to be caused by chrome binary being > >> linked to libc and libthr in "incorrect order", libc comes before > >> libthr in ldd output. My debugging shows that fork is resolved > >> from libc, not from libthr. Not sure what to blame here: > >> - build toolchain for putting libc before libthr > >> - rtld for not preferring libthr over libc > >> - libc/libthr for being split into two pieces in the current way > >=20 > > - The build procedure for chromium. > >=20 > > libc/[libc_r, libpthread, libthr] have always behaved that > > way since the libc/libc_r split. >=20 > Well, I wouldn't blame it so expressly: -pthread is the first option > on the linkage command line, there is -lc there also. I would expect > that that would do the right thing, but it doesn't. And that's a > PITA for porting. >=20 I would blame it, and expressly at that. -pthread is a shortcut for {-lpthread -lc} instead of just {-lc} in the place where implied libc is provided by the compiler driver and has no magic properties you want it it to have. If chromium build infrastructure circumvents that, it is only said build infrastructure to blame. --=20 Alexander Kabaev --Sig_/j2JDM.XEw90xCQARPs0Hy1Z Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iD8DBQFNq4vSQ6z1jMm+XZYRApBKAJ9aGRTlhM3hLJi9udq9pCfhgtjrUQCgwsWw XI3npvXN9OTU3qmsiuojyxw= =qqhI -----END PGP SIGNATURE----- --Sig_/j2JDM.XEw90xCQARPs0Hy1Z-- From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 18 04:14:47 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5EF7106564A for ; Mon, 18 Apr 2011 04:14:47 +0000 (UTC) (envelope-from mwm@mired.org) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8D1F08FC0A for ; Mon, 18 Apr 2011 04:14:47 +0000 (UTC) Received: by gyg13 with SMTP id 13so1747216gyg.13 for ; Sun, 17 Apr 2011 21:14:46 -0700 (PDT) Received: by 10.100.248.4 with SMTP id v4mr2295245anh.83.1303100086273; Sun, 17 Apr 2011 21:14:46 -0700 (PDT) Received: from bhuda.mired.org (h4.173.90.75.dynamic.ip.windstream.net [75.90.173.4]) by mx.google.com with ESMTPS id c4sm5105468ana.23.2011.04.17.21.14.45 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 17 Apr 2011 21:14:46 -0700 (PDT) Date: Mon, 18 Apr 2011 00:14:39 -0400 From: Mike Meyer To: freebsd-hackers@freebsd.org Message-ID: <20110418001439.3e4237dd@bhuda.mired.org> In-Reply-To: References: <8CDCA9824BFE47E-176C-A720@web-mmc-d04.sysops.aol.com> <20110416233839.GA72223@DataIX.net> Organization: Meyer Consulting X-Mailer: Claws Mail 3.7.7 (GTK+ 2.22.1; amd64-portbld-freebsd8.1) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAG1BMVEXguIzRkGnhyaz069mXhW0WHRnbrnR9WCQ6LB0CchNMAAACSUlEQVQ4jV2TQW7jMAxFGaPQOgQEdZaGMsgBrAvUA03dCxj1Uu4U2gfwQD7AGNax51NK07RcxXz6/CSl0Ij450vkPG1jzpIZM1UwDCl/xB14TWnNX8A00Qj5a0mnVFVbVUz4MeErea2HikSRqZzY894zwg9p2+/AtO8LzxFED+tNAUFeU29iFOLRxlZAcdo9A8wi8ZBMV4BKPde82Oxrvs6BTkulQIClte0DLFzzsKk9j1MBex8iUaP00Bd78S/muyFScrTXz6zLkEUxJp+SabQfNOs4f4Jpx5qSZ/304PWwlEWP1cOn/mJQR7EOD+uKhjcBLziuL7xoY5Xm+VFAUSw/LwwwsHEHxihpwV4EJH0xXRkbw1PkRw+X4pEuSJwBggqk+HEYKkiL5/74/nQkogigzQsAFrakxZyfw3wMIEEZPv4AWMfxwqE5GNxGaERjmH+PG8AE0L4/w9g0lsp1raLYAN5azQa+AOoO9NwcpFkTrG2VKNMNEL5UKUUAw34tha0z7onUG0oBoNtczE04GwFE3wCHc0ChezAJ6A1WMV81AtY7wDAJSlXwV+4cwBvsOsrQMRawfQEBz0deEZ7WNpV2szckIKo5VpDHDSDvF1GItwqqAlG01Hh50BGtVhuUkjkasg/14bYFGCgWg1fSWHvmOoJck2xdp9ZvZBHzDVTzX23TkrOn7qe5U2COEw5D4Vx3qEQpFY2Z/3QFnJxzp7YCmSMG19nOUoe869zZfOQb5ywQuWu0yCn5+8gxZz+BE7vG3j4/wbf4D/sXN9Wug1s7AAAAAElFTkSuQmCC Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: Add SUM sysctl X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 04:14:47 -0000 On Sun, 17 Apr 2011 15:11:03 +0300 Daniel Braniss wrote: > when something gets too complicated, it's usualy helpful to look for other ways > out: > the /(root) + /usr + kernel-debuging + src is less than 1GB, so what I > do (when diskless is not an option), I have a 2 partitions, both bootable, > and so i ALWAYS update the non active one, then > 1- I always have a working / in case the update screwed something > 2- I can update without problems. A number of people have mentioned this, but none have pointed out that with a ZFS system, you don't even have to keep a spare partition around to do this. Cryx provided this script (http://anonsvn.h3q.com/projects/freebsd-patches/browser/manageBE/manageBE) which makes updating a FreeBSD system as simple any Unix system I've seen. http://www.mired.org/consulting.html Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 18 06:24:17 2011 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5EBAB106566B; Mon, 18 Apr 2011 06:24:17 +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 675698FC13; Mon, 18 Apr 2011 06:24:16 +0000 (UTC) Received: from porto.topspin.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 JAA03098; Mon, 18 Apr 2011 09:24:11 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1QBhsZ-000Ozc-J8; Mon, 18 Apr 2011 09:24:11 +0300 Message-ID: <4DABD90A.1080402@FreeBSD.org> Date: Mon, 18 Apr 2011 09:24:10 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110308 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Alexander Kabaev References: <4DA98197.8060104@FreeBSD.org> <4DAAFBAF.90700@FreeBSD.org> <4DAB0DC4.4060504@FreeBSD.org> <20110417205438.69235fc4@kan.dnsalias.net> In-Reply-To: <20110417205438.69235fc4@kan.dnsalias.net> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-threads@FreeBSD.org, hackers@FreeBSD.org Subject: Re: puzzled: fork +libthr X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 06:24:17 -0000 on 18/04/2011 03:54 Alexander Kabaev said the following: > > I would blame it, and expressly at that. -pthread is a shortcut for > {-lpthread -lc} instead of just {-lc} in the place where implied libc > is provided by the compiler driver and has no magic properties you want > it it to have. If chromium build infrastructure circumvents that, it is > only said build infrastructure to blame. OK, I see, thank you. Still inconvenient. As in: if we know for a fact that "gcc ... -pthread -lc" results in a broken binary, then IMO we should do something about that. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 18 11:57:27 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32415106566C for ; Mon, 18 Apr 2011 11:57:27 +0000 (UTC) (envelope-from rank1seeker@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id AD1C08FC0A for ; Mon, 18 Apr 2011 11:57:26 +0000 (UTC) Received: by bwz12 with SMTP id 12so5126611bwz.13 for ; Mon, 18 Apr 2011 04:57:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:from:to:subject:date:content-type :content-transfer-encoding:in-reply-to:references:x-mailer; bh=qL5kojwqMehOZnchSLrRSbCwB7Esgao82Uc4RTzu1zM=; b=IUBNZ5VZ2WAGvtwHtFxZQrP737zZ9dtKLOAKm0mZ2GyJD56n9V9tKG39Ns7paffiQm OvbZKnDSV244e0VovRlpzry1T3gUw9u+KsobQYIwl7bAygGC6wy0iIOC7vvvYdMYXZed Dc40IvaesYj/styrohMjnEylr0vywl6tdTGbs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:subject:date:content-type :content-transfer-encoding:in-reply-to:references:x-mailer; b=FXQUd7XcI3fJoQGBJnkcDa+XSGTcuZ6vaP7B5S44bw80IwFAZhvKyEI0/lABSLyeJC 3Athwk0bEO99BUiqIfMVDahC8OpxppzBw0KujI3ycnoGpjotTlEusBzkeNTXiOt+ajmZ LcwC0X9nbIZiFayoJxLMzw217QISD+1bNasi8= Received: by 10.204.84.166 with SMTP id j38mr4091058bkl.84.1303127844810; Mon, 18 Apr 2011 04:57:24 -0700 (PDT) Received: from DEV (93-141-110-103.adsl.net.t-com.hr [93.141.110.103]) by mx.google.com with ESMTPS id a23sm3111228bkc.16.2011.04.18.04.57.22 (version=SSLv3 cipher=OTHER); Mon, 18 Apr 2011 04:57:23 -0700 (PDT) Message-ID: <20110418.115215.546.1@DEV> From: rank1seeker@gmail.com To: freebsd-hackers@freebsd.org Date: Mon, 18 Apr 2011 13:52:15 +0200 Content-Type: text/plain; charset="Windows-1250" Content-Transfer-Encoding: quoted-printable In-Reply-To: References: <8CDCA9824BFE47E-176C-A720@web-mmc-d04.sysops.aol.com> <20110416233839.GA72223@DataIX.net> X-Mailer: POP Peeper (3.7.0.0) Subject: Re: Add SUM sysctl X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 11:57:27 -0000 I would like, to thank you all, for your ideas.=0D=0A=0D=0AThere are 2 ways = of going into SUM (Single user mode)=0D=0A1) Rebooting into it=0D=0A2) = Drop from MUM=0D=0A=0D=0AMy solution MUST cover both cases, of entering = into SUM.=0D=0A=0D=0AOnce I enter SUM, I set it up, via 1 script, which = enables deamons and other stuff, that I need, for certain task. (i.e; I = wana use mouse, so I activate moused ...)=0D=0ANow, after those steps, if = that machine is web server, which serves only static content, then = enabling apache, makes it fully functional server, in SUM!=0D=0AI see = now, that both SUM and MUM define BOOTED/STARTED/RUNNING FreeBSD. -> = Thx, to Daniel O'Connor, for pointing into this direction.=0D=0ASo SUM = defines basic functionality and MUM ...=0D=0ASo where is a BORDER of SUM = and MUM. How many "stuff" has to be enabled/activated to decalre it as = MUM, instead of SUM?=0D=0AWhere does exactly SUM, becomes MUM. As long as = kernel is being asked, it doesn't differentiate between SUM and = MUM.=0D=0AKernel "sees" amonut of "pressure" induced by deamones, users, = processes.=0D=0A=0D=0ANow to cut that chatter short, to solution = ...=0D=0A=0D=0AI've tried by looking at init state:=0D=0A# ps -U root | = grep 'init -s'=0D=0ABUT, after exiting into MUM, from SUM:=0D=0ASUM->MUM = (/sbin/init -s) 'init -s' remained.=0D=0AIf sys booted directly into MUM, = I see (/sbin/init --), which also remains upon drop to SUM.=0D=0ASo init = state can only be used, to determine, how sys has been = booted/started.=0D=0A=0D=0ATo cut it even shorter (skipping tried sysctl = vars, env, etc ...)=0D=0A=0D=0A=0D=0ASolution, which passed my = requirement, was one from J. Hellenthal's advice.=0D=0AThx!=0D=0AIt = works, with both cases of entering into SUM.=0D=0AAlso covers case, where = I enable stuff, that I need in SUM and which could confuse function, into = thinking it is in MUM.=0D=0A=0D=0A=0D=0AHere is an resulting function: = (/bin/sh)=0D=0A--=0D=0A# Are we in a SUM=0D=0Ain_sum ()=0D=0A{=0D=0A = if [ "`/bin/pgrep -x getty`" ]; then=0D=0A return 1=0D=0A = else=0D=0A return 0=0D=0A = fi=0D=0A}=0D=0A--=0D=0A=0D=0A=0D=0ADomagoj Smol=E8i=E6=0D=0A From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 18 13:57:26 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EECB51065670 for ; Mon, 18 Apr 2011 13:57:25 +0000 (UTC) (envelope-from freebsd@psconsult.nl) Received: from mx1.psconsult.nl (unknown [IPv6:2001:7b8:30f:e0::5059:ee8a]) by mx1.freebsd.org (Postfix) with ESMTP id 8670B8FC12 for ; Mon, 18 Apr 2011 13:57:25 +0000 (UTC) Received: from mx1.psconsult.nl (psc11.adsl.iaf.nl [80.89.238.138]) by mx1.psconsult.nl (8.14.4/8.14.4) with ESMTP id p3IDvJjU001443 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 18 Apr 2011 15:57:24 +0200 (CEST) (envelope-from freebsd@psconsult.nl) Received: (from paul@localhost) by mx1.psconsult.nl (8.14.4/8.14.4/Submit) id p3IDvJhi001442 for freebsd-hackers@freebsd.org; Mon, 18 Apr 2011 15:57:19 +0200 (CEST) (envelope-from freebsd@psconsult.nl) X-Authentication-Warning: mx1.psconsult.nl: paul set sender to freebsd@psconsult.nl using -f Date: Mon, 18 Apr 2011 15:57:19 +0200 From: Paul Schenkeveld To: freebsd-hackers@freebsd.org Message-ID: <20110418135719.GA89086@psconsult.nl> References: <8CDCA9824BFE47E-176C-A720@web-mmc-d04.sysops.aol.com> <20110416233839.GA72223@DataIX.net> <20110418.115215.546.1@DEV> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110418.115215.546.1@DEV> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: Add SUM sysctl X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 13:57:26 -0000 On Mon, Apr 18, 2011 at 01:52:15PM +0200, rank1seeker@gmail.com wrote: > > There are 2 ways of going into SUM (Single user mode) > 1) Rebooting into it > 2) Drop from MUM > > My solution MUST cover both cases, of entering into SUM. > > Once I enter SUM, I set it up, via 1 script, which enables deamons and other stuff, that I need, for certain task. (i.e; I wana use mouse, so I activate moused ...) > Now, after those steps, if that machine is web server, which serves only static content, then enabling apache, makes it fully functional server, in SUM! > I see now, that both SUM and MUM define BOOTED/STARTED/RUNNING FreeBSD. -> Thx, to Daniel O'Connor, for pointing into this direction. > So SUM defines basic functionality and MUM ... > So where is a BORDER of SUM and MUM. How many "stuff" has to be enabled/activated to decalre it as MUM, instead of SUM? > Where does exactly SUM, becomes MUM. As long as kernel is being asked, it doesn't differentiate between SUM and MUM. > Kernel "sees" amonut of "pressure" induced by deamones, users, processes. > > Now to cut that chatter short, to solution ... > > I've tried by looking at init state: > # ps -U root | grep 'init -s' > BUT, after exiting into MUM, from SUM: > SUM->MUM (/sbin/init -s) 'init -s' remained. > If sys booted directly into MUM, I see (/sbin/init --), which also remains upon drop to SUM. > So init state can only be used, to determine, how sys has been booted/started. > > To cut it even shorter (skipping tried sysctl vars, env, etc ...) > > > Solution, which passed my requirement, was one from J. Hellenthal's advice. > Thx! > It works, with both cases of entering into SUM. > Also covers case, where I enable stuff, that I need in SUM and which could confuse function, into thinking it is in MUM. > > > Here is an resulting function: (/bin/sh) > -- > # Are we in a SUM > in_sum () > { > if [ "`/bin/pgrep -x getty`" ]; then > return 1 > else > return 0 > fi > } > -- Which works in most cases except: 1. You have disable getty in /etc/ttys because the system is headless. 2. You have logged in to all virtual consoles so all getty processes have been replaced by login shells. My personal conclusion after 25+ years of UNIX system administration is that: 1. System V supports runlevels to distinguish between SUM and various levels of MUM but that is not waterproof. Linux supposedly have adopted the System V runlevel concept. 2. BSDs traditionally do not have a clear line between SUM and MUM, for example, when going back from MUM to SUM, some processes that were started in MUM keep running, filesystems are still mounted and things configured for MUM are not de-configured. Also during transition from SUM to MUM, when rc encounters an error, it will drop into a "twilight zone" kind of SUM where some MUM initialisation is completed but not all of it. 3. To be really safe, you should check for everything that should not be running/mounted/configured before doing "dangerous stuff" (TM) and not rely on a single test that may result in false positives or false negatives. Personally I seldomly drop into SUM via shutdown but prefer to reboot into SUM. My $0.02 Regards, Paul Schenkeveld From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 18 16:56:28 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F6DB1065674; Mon, 18 Apr 2011 16:56:28 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 255258FC0A; Mon, 18 Apr 2011 16:56:28 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id D1B8546B51; Mon, 18 Apr 2011 12:56:27 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 66AC48A01B; Mon, 18 Apr 2011 12:56:27 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Mon, 18 Apr 2011 08:24:57 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <20110415.150349.671.1@DEV> <20110416.142444.546.5@DEV> In-Reply-To: <20110416.142444.546.5@DEV> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201104180824.57541.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 18 Apr 2011 12:56:27 -0400 (EDT) Cc: rank1seeker@gmail.com, Pawel Jakub Dawidek Subject: Re: Add SUM sysctl X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 16:56:28 -0000 On Saturday, April 16, 2011 10:24:44 am rank1seeker@gmail.com wrote: > After compilation of kernel and world in MUM, kernel is installed in MUM, > but to install world, we reboot into SUM, then install world. (HANDBOOK) > Now, in case of GELI usage AND if upgrading is taking place, i.e; 8.2 -> > 8.3, once you reboot into SUM to install world, you are doomed, BECAUSE > ... > Kernel will bitch (GELI part), about world->kernel mismatch and you won't > be able to install world as you cant decrypt geom providers!! > The only way to save yourself in that case is to restore /boot/kernel.old, > or one is doomed. This seems broken to me. An 8.3 kernel+modules should be able to handle GELI devices with an 8.2 world. If they can't, it means someone broke the ABI. Even a 9.0 kernel should work fine with an 8.x-stable world. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 18 16:56:29 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 43545106566B for ; Mon, 18 Apr 2011 16:56:29 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 18C738FC17 for ; Mon, 18 Apr 2011 16:56:29 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id BECF046B58; Mon, 18 Apr 2011 12:56:28 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 563A08A02A; Mon, 18 Apr 2011 12:56:28 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Mon, 18 Apr 2011 08:31:33 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <397135152.167477.1303069788579.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <397135152.167477.1303069788579.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201104180831.33796.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 18 Apr 2011 12:56:28 -0400 (EDT) Cc: Rick Macklem Subject: Re: SMP question w.r.t. reading kernel variables X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 16:56:29 -0000 On Sunday, April 17, 2011 3:49:48 pm Rick Macklem wrote: > Hi, > > I should know the answer to this, but... When reading a global kernel > variable, where its modifications are protected by a mutex, is it > necessary to get the mutex lock to just read its value? > > For example: > A if ((mp->mnt_kern_flag & MNTK_UNMOUNTF) != 0) > return (EPERM); > versus > B MNT_ILOCK(mp); > if ((mp->mnt_kern_flag & MNTK_UNMOUNTF) != 0) { > MNT_IUNLOCK(mp); > return (EPERM); > } > MNT_IUNLOCK(mp); > > My hunch is that B is necessary if you need an up-to-date value > for the variable (mp->mnt_kern_flag in this case). > > Is that correct? You already have good followups from Attilio and Kostik, but one thing to keep in mind is that if a simple read is part of a larger "atomic operation" then it may still need a lock. In this case Kostik points out that another lock prevents updates to mnt_kern_flag so that this is safe. However, if not for that you would need to consider the case that another thread sets the flag on the next instruction. Even the B case above might still have that problem since you drop the lock right after checking it and the rest of the function is implicitly assuming the flag is never set perhaps (or it needs to handle the case that the flag might become set in the future while MNT_ILOCK() is dropped). One way you can make that code handle that race is by holding MNT_ILOCK() around the entire function, but that approach is often only suitable for a simple routine. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 18 18:03:33 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B4361065670 for ; Mon, 18 Apr 2011 18:03:33 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.garage.freebsd.pl (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id BA30B8FC17 for ; Mon, 18 Apr 2011 18:03:32 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 8817445C9F; Mon, 18 Apr 2011 20:03:30 +0200 (CEST) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 6C4C245B36; Mon, 18 Apr 2011 20:03:25 +0200 (CEST) Date: Mon, 18 Apr 2011 20:03:16 +0200 From: Pawel Jakub Dawidek To: John Baldwin Message-ID: <20110418180316.GA3097@garage.freebsd.pl> References: <20110415.150349.671.1@DEV> <20110416.142444.546.5@DEV> <201104180824.57541.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="h31gzZEtNLTqOjlF" Content-Disposition: inline In-Reply-To: <201104180824.57541.jhb@freebsd.org> X-OS: FreeBSD 9.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: rank1seeker@gmail.com, freebsd-hackers@freebsd.org Subject: Re: Add SUM sysctl X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 18:03:33 -0000 --h31gzZEtNLTqOjlF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 18, 2011 at 08:24:57AM -0400, John Baldwin wrote: > On Saturday, April 16, 2011 10:24:44 am rank1seeker@gmail.com wrote: > > After compilation of kernel and world in MUM, kernel is installed in MU= M,=20 > > but to install world, we reboot into SUM, then install world. (HANDBOOK) > > Now, in case of GELI usage AND if upgrading is taking place, i.e; 8.2 -= >=20 > > 8.3, once you reboot into SUM to install world, you are doomed, BECAUSE= =20 > > ... > > Kernel will bitch (GELI part), about world->kernel mismatch and you won= 't=20 > > be able to install world as you cant decrypt geom providers!! > > The only way to save yourself in that case is to restore /boot/kernel.o= ld,=20 > > or one is doomed. >=20 > This seems broken to me. An 8.3 kernel+modules should be able to handle = GELI=20 > devices with an 8.2 world. If they can't, it means someone broke the ABI= =2E =20 > Even a 9.0 kernel should work fine with an 8.x-stable world. This is generally not expected to have a bit of the system encrypted. You either have whole root encrypted and there is no userland involved to attach it or you have some secure partition encrypted. I don't fully understand how you can boot your system and then need to attach GELI provider to be able to install world. If you booted fine then your system is available and not encrypted. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com --h31gzZEtNLTqOjlF Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk2sfOQACgkQForvXbEpPzQ3iQCguZmX062IEPzPMBYNMAHwAWtB 3S0AoOhJt7imwkuOzGpKAQ3MPe8jQCGx =UOMQ -----END PGP SIGNATURE----- --h31gzZEtNLTqOjlF-- From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 18 20:22:39 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35113106566B; Mon, 18 Apr 2011 20:22:39 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id D0C3F8FC14; Mon, 18 Apr 2011 20:22:38 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au4AAMecrE2DaFvO/2dsb2JhbACET5JnjnyIb6sVkHWBKYFZgXV6BI4A X-IronPort-AV: E=Sophos;i="4.64,234,1301889600"; d="scan'208";a="118738597" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 18 Apr 2011 16:22:37 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id B7545B3F4D; Mon, 18 Apr 2011 16:22:37 -0400 (EDT) Date: Mon, 18 Apr 2011 16:22:37 -0400 (EDT) From: Rick Macklem To: John Baldwin Message-ID: <857645844.237335.1303158157618.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <201104180831.33796.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE7 (Win)/6.0.10_GA_2692) Cc: freebsd-hackers@freebsd.org Subject: Re: SMP question w.r.t. reading kernel variables X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 20:22:39 -0000 > On Sunday, April 17, 2011 3:49:48 pm Rick Macklem wrote: > > Hi, > > > > I should know the answer to this, but... When reading a global > > kernel > > variable, where its modifications are protected by a mutex, is it > > necessary to get the mutex lock to just read its value? > > > > For example: > > A if ((mp->mnt_kern_flag & MNTK_UNMOUNTF) != 0) > > return (EPERM); > > versus > > B MNT_ILOCK(mp); > > if ((mp->mnt_kern_flag & MNTK_UNMOUNTF) != 0) { > > MNT_IUNLOCK(mp); > > return (EPERM); > > } > > MNT_IUNLOCK(mp); > > > > My hunch is that B is necessary if you need an up-to-date value > > for the variable (mp->mnt_kern_flag in this case). > > > > Is that correct? > > You already have good followups from Attilio and Kostik, but one thing > to keep > in mind is that if a simple read is part of a larger "atomic > operation" then > it may still need a lock. In this case Kostik points out that another > lock > prevents updates to mnt_kern_flag so that this is safe. However, if > not for > that you would need to consider the case that another thread sets the > flag on > the next instruction. Even the B case above might still have that > problem > since you drop the lock right after checking it and the rest of the > function > is implicitly assuming the flag is never set perhaps (or it needs to > handle > the case that the flag might become set in the future while > MNT_ILOCK() is > dropped). > > One way you can make that code handle that race is by holding > MNT_ILOCK() > around the entire function, but that approach is often only suitable > for a > simple routine. > All of this makes sense. What I was concerned about was memory cache consistency and whet (if anything) has to be done to make sure a thread doesn't see a stale cached value for the memory location. Here's a generic example of what I was thinking of: (assume x is a global int and y is a local int on the thread's stack) - time proceeds down the screen thread X on CPU 0 thread Y on CPU 1 x = 0; x = 0; /* 0 for x's location in CPU 1's memory cache */ x = 1; y = x; --> now, is "y" guaranteed to be 1 or can it get the stale cached 0 value? if not, what needs to be done to guarantee it? For the original example, I am fine so long as the bit is seen as set after dounmount() has set it. Also, I see cases of: mtx_lock(&np); np->n_attrstamp = 0; mtx_unlock(&np); in the regular NFS client. Why is the assignment mutex locked? (I had assumed it was related to the above memory caching issue, but now I'm not so sure.) Thanks a lot for all the good responses, rick ps: I guess it comes down to whether or not "atomic" includes ensuring memory cache consistency. I'll admit I assumed "atomic" meant that the memory access or modify couldn't be interleaved with one done to the same location by another CPU, but not memory cache consistency. From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 18 20:26:57 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E9201065675; Mon, 18 Apr 2011 20:26:57 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id E4F3C8FC0C; Mon, 18 Apr 2011 20:26:56 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAPWdrE2DaFvO/2dsb2JhbACET6FjiG+rI5B1gSmDTnoEjgA X-IronPort-AV: E=Sophos;i="4.64,234,1301889600"; d="scan'208";a="118739118" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 18 Apr 2011 16:26:56 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 2F807B3F56; Mon, 18 Apr 2011 16:26:56 -0400 (EDT) Date: Mon, 18 Apr 2011 16:26:56 -0400 (EDT) From: Rick Macklem To: John Baldwin Message-ID: <1179635042.237706.1303158416180.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <857645844.237335.1303158157618.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE7 (Win)/6.0.10_GA_2692) Cc: freebsd-hackers@freebsd.org Subject: Re: SMP question w.r.t. reading kernel variables X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 20:26:57 -0000 > > > All of this makes sense. What I was concerned about was memory cache > consistency and whet (if anything) has to be done to make sure a Oops, "whet" should have been "what".. From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 18 21:15:02 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D9F51065672 for ; Mon, 18 Apr 2011 21:15:02 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 54C318FC1B for ; Mon, 18 Apr 2011 21:15:02 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id E5ECC46B45; Mon, 18 Apr 2011 17:15:01 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 801B18A027; Mon, 18 Apr 2011 17:15:01 -0400 (EDT) From: John Baldwin To: Rick Macklem Date: Mon, 18 Apr 2011 17:12:14 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <857645844.237335.1303158157618.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <857645844.237335.1303158157618.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201104181712.14457.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 18 Apr 2011 17:15:01 -0400 (EDT) Cc: freebsd-hackers@freebsd.org Subject: Re: SMP question w.r.t. reading kernel variables X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 21:15:02 -0000 On Monday, April 18, 2011 4:22:37 pm Rick Macklem wrote: > > On Sunday, April 17, 2011 3:49:48 pm Rick Macklem wrote: > > > Hi, > > > > > > I should know the answer to this, but... When reading a global > > > kernel > > > variable, where its modifications are protected by a mutex, is it > > > necessary to get the mutex lock to just read its value? > > > > > > For example: > > > A if ((mp->mnt_kern_flag & MNTK_UNMOUNTF) != 0) > > > return (EPERM); > > > versus > > > B MNT_ILOCK(mp); > > > if ((mp->mnt_kern_flag & MNTK_UNMOUNTF) != 0) { > > > MNT_IUNLOCK(mp); > > > return (EPERM); > > > } > > > MNT_IUNLOCK(mp); > > > > > > My hunch is that B is necessary if you need an up-to-date value > > > for the variable (mp->mnt_kern_flag in this case). > > > > > > Is that correct? > > > > You already have good followups from Attilio and Kostik, but one thing > > to keep > > in mind is that if a simple read is part of a larger "atomic > > operation" then > > it may still need a lock. In this case Kostik points out that another > > lock > > prevents updates to mnt_kern_flag so that this is safe. However, if > > not for > > that you would need to consider the case that another thread sets the > > flag on > > the next instruction. Even the B case above might still have that > > problem > > since you drop the lock right after checking it and the rest of the > > function > > is implicitly assuming the flag is never set perhaps (or it needs to > > handle > > the case that the flag might become set in the future while > > MNT_ILOCK() is > > dropped). > > > > One way you can make that code handle that race is by holding > > MNT_ILOCK() > > around the entire function, but that approach is often only suitable > > for a > > simple routine. > > > All of this makes sense. What I was concerned about was memory cache > consistency and whet (if anything) has to be done to make sure a thread > doesn't see a stale cached value for the memory location. > > Here's a generic example of what I was thinking of: > (assume x is a global int and y is a local int on the thread's stack) > - time proceeds down the screen > thread X on CPU 0 thread Y on CPU 1 > x = 0; > x = 0; /* 0 for x's location in CPU 1's memory cache */ > x = 1; > y = x; > --> now, is "y" guaranteed to be 1 or can it get the stale cached 0 value? > if not, what needs to be done to guarantee it? Well, the bigger problem is getting the CPU and compiler to order the instructions such that they don't execute out of order, etc. Because of that, even if your code has 'x = 0; x = 1;' as adjacent threads in thread X, the 'x = 1' may actually execute a good bit after the 'y = x' on CPU 1. Locks force that to sychronize as the CPUs coordinate around the lock cookie (e.g. the 'mtx_lock' member of 'struct mutex'). > Also, I see cases of: > mtx_lock(&np); > np->n_attrstamp = 0; > mtx_unlock(&np); > in the regular NFS client. Why is the assignment mutex locked? (I had assumed > it was related to the above memory caching issue, but now I'm not so sure.) In general I think writes to data that are protected by locks should always be protected by locks. In some cases you may be able to read data using "weaker" locking (where "no locking" can be a form of weaker locking, but also a read/shared lock is weak, and if a variable is protected by multiple locks, then any singe lock is weak, but sufficient for reading while all of the associated locks must be held for writing) than writing, but writing generally requires "full" locking (write locks, etc.). The case above may be excessive caution on my part, but I'd rather be safe than sorry for writes. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 19 17:23:29 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F7331065670 for ; Tue, 19 Apr 2011 17:23:29 +0000 (UTC) (envelope-from cliftonr@oz.volcano.org) Received: from hrndva-omtalb.mail.rr.com (hrndva-omtalb.mail.rr.com [71.74.56.124]) by mx1.freebsd.org (Postfix) with ESMTP id 48DD98FC15 for ; Tue, 19 Apr 2011 17:23:29 +0000 (UTC) Received: from hrndva-omtalb.mail.rr.com ([10.128.143.52]) by hrndva-qmta02.mail.rr.com with ESMTP id <20110419171344827.BALM5185@hrndva-qmta02.mail.rr.com> for ; Tue, 19 Apr 2011 17:13:44 +0000 X-Authority-Analysis: v=1.1 cv=qyUSAyc82z9xLljZQc9ErY9Tl2GSEfqK/XYZS35I9d8= c=1 sm=0 a=z1TLwsU0kBEA:10 a=q1A4uwALsQMA:10 a=TgPToyY2OQsA:10 a=kj9zAlcOel0A:10 a=G5OLwwqwWgs+1dCEPNHTSw==:17 a=6I5d2MoRAAAA:8 a=jb__rZ8GAAAA:8 a=H9iEQFZ8AAAA:8 a=ac3IfjoEGWV7Sfb5AkkA:9 a=6HQiZRNdpsNgcHOFxLYA:7 a=CjuIK1q_8ugA:10 a=SV7veod9ZcQA:10 a=sHp_62vNEjwA:10 a=fZFZujrNNEQA:10 a=G5OLwwqwWgs+1dCEPNHTSw==:117 X-Cloudmark-Score: 0 X-Originating-IP: 75.80.196.236 Received: from [75.80.196.236] ([75.80.196.236:8576] helo=oz.volcano.org) by hrndva-oedge02.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id C6/17-08375-672CDAD4; Tue, 19 Apr 2011 17:12:22 +0000 Received: by oz.volcano.org (Postfix, from userid 1001) id D614E5082A; Tue, 19 Apr 2011 07:12:21 -1000 (HST) Date: Tue, 19 Apr 2011 07:12:21 -1000 From: Clifton Royston To: freebsd-hackers@freebsd.org Message-ID: <20110419171221.GA49924@lava.net> Mail-Followup-To: freebsd-hackers@freebsd.org References: <20110419120029.1394510656E3@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201104181712.14457.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i Subject: Re: SMP question w.r.t. reading kernel variables X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 17:23:29 -0000 On Tue, Apr 19, 2011 at 12:00:29PM +0000, freebsd-hackers-request@freebsd.org wrote: > Subject: Re: SMP question w.r.t. reading kernel variables > To: Rick Macklem > Cc: freebsd-hackers@freebsd.org > Message-ID: <201104181712.14457.jhb@freebsd.org> [John Baldwin] > On Monday, April 18, 2011 4:22:37 pm Rick Macklem wrote: > > > On Sunday, April 17, 2011 3:49:48 pm Rick Macklem wrote: ... > > All of this makes sense. What I was concerned about was memory cache > > consistency and whet (if anything) has to be done to make sure a thread > > doesn't see a stale cached value for the memory location. > > > > Here's a generic example of what I was thinking of: > > (assume x is a global int and y is a local int on the thread's stack) > > - time proceeds down the screen > > thread X on CPU 0 thread Y on CPU 1 > > x = 0; > > x = 0; /* 0 for x's location in CPU 1's memory cache */ > > x = 1; > > y = x; > > --> now, is "y" guaranteed to be 1 or can it get the stale cached 0 value? > > if not, what needs to be done to guarantee it? > > Well, the bigger problem is getting the CPU and compiler to order the > instructions such that they don't execute out of order, etc. Because of that, > even if your code has 'x = 0; x = 1;' as adjacent threads in thread X, > the 'x = 1' may actually execute a good bit after the 'y = x' on CPU 1. Actually, as I recall the rules for C, it's worse than that. For this (admittedly simplified scenario), "x=0;" in thread X may never execute unless it's declared volatile, as the compiler may optimize it out and emit no code for it. > Locks force that to sychronize as the CPUs coordinate around the lock cookie > (e.g. the 'mtx_lock' member of 'struct mutex'). > > > Also, I see cases of: > > mtx_lock(&np); > > np->n_attrstamp = 0; > > mtx_unlock(&np); > > in the regular NFS client. Why is the assignment mutex locked? (I had assumed > > it was related to the above memory caching issue, but now I'm not so sure.) > > In general I think writes to data that are protected by locks should always be > protected by locks. In some cases you may be able to read data using "weaker" > locking (where "no locking" can be a form of weaker locking, but also a > read/shared lock is weak, and if a variable is protected by multiple locks, > then any singe lock is weak, but sufficient for reading while all of the > associated locks must be held for writing) than writing, but writing generally > requires "full" locking (write locks, etc.). What he said. In addition to all that, lock operations generate "atomic" barriers which a compiler or optimizer is prevented from moving code across. -- Clifton -- Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 20 02:59:36 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1DBEF106566C for ; Wed, 20 Apr 2011 02:59:36 +0000 (UTC) (envelope-from no-reply@dropboxmail.com) Received: from mailman-2.dropboxmail.com (mailman-2.dropboxmail.com [75.126.110.122]) by mx1.freebsd.org (Postfix) with ESMTP id D59548FC1D for ; Wed, 20 Apr 2011 02:59:35 +0000 (UTC) Received: from mailman-2.dropboxmail.com (localhost [127.0.0.1]) by mailman-2.dropboxmail.com (Postfix) with ESMTP id 27904492110 for ; Wed, 20 Apr 2011 02:45:06 +0000 (UTC) X-DomainKeys: Sendmail DomainKeys Filter v0.6.0 mailman-2.dropboxmail.com 27904492110 DomainKey-Signature: a=rsa-sha1; s=m1; d=dropboxmail.com; c=simple; q=dns; b=g0+p7n+wXrEkFOjHzeQiAV3a6Kvn1tez6fil1SrB2Yl4hC/QU2Q/IvABdSD8wFCpd tNw6PPCPKck+Y3rslnNMpZv5C7NhWlWzC5SswfxXSINpGvSa3NPEpxWFdhKksJfIn5e MJ79I8wgfA/76T7fkKe/ltwxt6SB8roKTz0ko4Y= MIME-Version: 1.0 From: Dropbox To: freebsd-hackers@freebsd.org Date: Wed, 20 Apr 2011 02:45:06 +0000 Message-Id: <20110420024506.27904492110@mailman-2.dropboxmail.com> Content-Type: text/plain; charset="utf8" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Masoom Shaikh invited you to Dropbox X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: masoom.shaikh@gmail.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 02:59:36 -0000 Masoom Shaikh wants you to try Dropbox! Dropbox lets you bring all your photos, docs and videos with you anywhere and share them easily. Get started here: http://www.dropbox.com/link/20.D0SkTdGfjo/Njg3MzIzMTQzNw?src=referrals_bulk9 - The Dropbox Team ____________________________________________________ To stop receiving invites from Dropbox, please go to http://www.dropbox.com/bl/0e74a09e7f6a/freebsd-hackers%40freebsd.org From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 20 12:42:56 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA07F1065670 for ; Wed, 20 Apr 2011 12:42:56 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 884978FC1C for ; Wed, 20 Apr 2011 12:42:56 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8BAMHTrk2DaFvO/2dsb2JhbACEUJJijwGIb60okSmBKYFZgXV6BI4i X-IronPort-AV: E=Sophos;i="4.64,246,1301889600"; d="scan'208";a="118951275" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 20 Apr 2011 08:42:55 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 89BEBB3F5B; Wed, 20 Apr 2011 08:42:55 -0400 (EDT) Date: Wed, 20 Apr 2011 08:42:55 -0400 (EDT) From: Rick Macklem To: Clifton Royston Message-ID: <1204340426.330830.1303303375497.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20110419171221.GA49924@lava.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE7 (Win)/6.0.10_GA_2692) Cc: freebsd-hackers@freebsd.org Subject: Re: SMP question w.r.t. reading kernel variables X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 12:42:57 -0000 > On Tue, Apr 19, 2011 at 12:00:29PM +0000, > freebsd-hackers-request@freebsd.org wrote: > > Subject: Re: SMP question w.r.t. reading kernel variables > > To: Rick Macklem > > Cc: freebsd-hackers@freebsd.org > > Message-ID: <201104181712.14457.jhb@freebsd.org> > > [John Baldwin] > > On Monday, April 18, 2011 4:22:37 pm Rick Macklem wrote: > > > > On Sunday, April 17, 2011 3:49:48 pm Rick Macklem wrote: > ... > > > All of this makes sense. What I was concerned about was memory > > > cache > > > consistency and whet (if anything) has to be done to make sure a > > > thread > > > doesn't see a stale cached value for the memory location. > > > > > > Here's a generic example of what I was thinking of: > > > (assume x is a global int and y is a local int on the thread's > > > stack) > > > - time proceeds down the screen > > > thread X on CPU 0 thread Y on CPU 1 > > > x = 0; > > > x = 0; /* 0 for x's location > > > in CPU 1's memory cache */ > > > x = 1; > > > y = x; > > > --> now, is "y" guaranteed to be 1 or can it get the stale cached > > > 0 value? > > > if not, what needs to be done to guarantee it? > > > > Well, the bigger problem is getting the CPU and compiler to order > > the > > instructions such that they don't execute out of order, etc. Because > > of that, > > even if your code has 'x = 0; x = 1;' as adjacent threads in thread > > X, > > the 'x = 1' may actually execute a good bit after the 'y = x' on CPU > > 1. > > Actually, as I recall the rules for C, it's worse than that. For > this (admittedly simplified scenario), "x=0;" in thread X may never > execute unless it's declared volatile, as the compiler may optimize it > out and emit no code for it. > > > > Locks force that to sychronize as the CPUs coordinate around the > > lock cookie > > (e.g. the 'mtx_lock' member of 'struct mutex'). > > > > > Also, I see cases of: > > > mtx_lock(&np); > > > np->n_attrstamp = 0; > > > mtx_unlock(&np); > > > in the regular NFS client. Why is the assignment mutex locked? (I > > > had assumed > > > it was related to the above memory caching issue, but now I'm not > > > so sure.) > > > > In general I think writes to data that are protected by locks should > > always be > > protected by locks. In some cases you may be able to read data using > > "weaker" > > locking (where "no locking" can be a form of weaker locking, but > > also a > > read/shared lock is weak, and if a variable is protected by multiple > > locks, > > then any singe lock is weak, but sufficient for reading while all of > > the > > associated locks must be held for writing) than writing, but writing > > generally > > requires "full" locking (write locks, etc.). > Oops, I now see that you've differentiated between writing and reading. (I mistakenly just stated that you had recommended a lock for reading. Sorry about my misinterpretation of the above on the first quick read.) > What he said. In addition to all that, lock operations generate > "atomic" barriers which a compiler or optimizer is prevented from > moving code across. > All good and useful comments, thanks. The above example was meant to be contrived, to indicate what I was worried about w.r.t. memory caches. Here's a somewhat simplified version of what my actual problem is: (Mostly fyi, in case you are interested.) Thread X is doing a forced dismount of an NFS volume, it (in dounmount()): - sets MNTK_UNMOUNTF - calls VFS_SYNC()/nfs_sync() - so this doesn't get hung on an unresponsive server it must test for MNTK_UNMOUNTF and return an error it is set. This seems fine, since it is the same thread and in a called function. (I can't imagine that the optimizer could move setting of a global flag to after a function call which might use it.) - calls VFS_UNMOUNT()/nfs_unmount() - now the fun begins... after some other stuff, it calls nfscl_umount() to get rid of the state info (opens/locks...) nfscl_umount() - synchronizes with other threads that will use this state (see below) using the combination of a mutex and a shared/exclusive sleep lock. (Because of various quirks in the code, this shared/exclusive lock is a locally coded version and I happenned to call the shared case a refcnt and the exclusive case just a lock.) Other threads that will use state info (open/lock...) will: -call nfscl_getcl() - this function does two things that are relevant 1 - it allocates a new clientid, as required, while holding the mutex - this case needs to check for MNTK_UNMOUNTF and return error, in case the clientid has already been deleted by nfscl_umount() above. (This happens before #2 because the sleep lock is in the clientd structure.) --> it must see the MNTK_UNMOUNTF set if it happens after (in a temporal sense) being set by dounmount() 2 - while holding the mutex, it acquires the shared lock - if this happens before nfscl_umount() gets the exclusive lock, it is fine, since acquisition of the exclusive lock above will wait for its release however - if it acquires the shared lock after nfscl_umount() has had the exclusive lock or competes with nfscl_umount() for the lock, it could be in trouble. - my planned fix for this is to test for MNTK_UNMOUNTF as it tries to get the shared lock (and fail with an error return if it is set) before if goes to sleep waiting for the exclusive lock to be released. (Othere things acquire this exclusive lock, so waiting for it usually makes sense, except this case.) --> again, I think this is fine so long as it sees MNTK_UNMOUNTF set when the the test occurs after (in a temporal sense) it was set by the forced dismount thread, since that thread set it before calling VFS_UNMOUNT()...nfscl_umount(). Now, in practice, I don't believe there is a problem, but since I have yet to see anyone state what the rules/assumptions for memory cache consistency are w.r.t. SMP, I thought I'd pursue it. I have learned about the "compiler boundaries" (ie. where the optimizer might move stuff) and other good stuff from this discussion and I thank you guys for that. rick From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 20 19:49:17 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4979B106566C for ; Wed, 20 Apr 2011 19:49:17 +0000 (UTC) (envelope-from alan.l.cox@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 09FF68FC08 for ; Wed, 20 Apr 2011 19:49:16 +0000 (UTC) Received: by iyj12 with SMTP id 12so1221308iyj.13 for ; Wed, 20 Apr 2011 12:49:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=EQppfzATiV+II6ZQSzeeMM0TtcGYUq5XyLFzld8aVQw=; b=CY2ZbCoi40oDTUjn1vljScptWqjc1hAhM8HOJeOaBQvP+Zw4zceuaE23jh+AiB7pqu Ri5wL4rax/n3sRk8rjOkPv6FMBpUNTj5L/QdoAI55g0PSnBNLMMzaybkxQ8vcLf2hC4t kWMDC9RL6iopKnRHqCvxnQP6ZF7U/g7M3J/dU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=kNAQPMDn2NWd+5Mfv1CJzetDDAhA/iluZcnKMqM2Iv3nrEFFGL5yCPJYkwxX7Uzfu1 5ppzv/mFL1GszI8C0+FRA6gKneBRALGuWca4QyvoUl1Z4YS+ORGiG/GNq+HrBqO4mMUp 5A/HqCR+XYykepkK2cHkrCiFU3LKIMcMFNcRg= MIME-Version: 1.0 Received: by 10.42.75.130 with SMTP id a2mr448471ick.320.1303328956303; Wed, 20 Apr 2011 12:49:16 -0700 (PDT) Received: by 10.42.166.10 with HTTP; Wed, 20 Apr 2011 12:49:16 -0700 (PDT) In-Reply-To: <1204340426.330830.1303303375497.JavaMail.root@erie.cs.uoguelph.ca> References: <20110419171221.GA49924@lava.net> <1204340426.330830.1303303375497.JavaMail.root@erie.cs.uoguelph.ca> Date: Wed, 20 Apr 2011 14:49:16 -0500 Message-ID: From: Alan Cox To: Rick Macklem Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers Subject: Re: SMP question w.r.t. reading kernel variables X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: alc@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 19:49:17 -0000 On Wed, Apr 20, 2011 at 7:42 AM, Rick Macklem wrote: > > On Tue, Apr 19, 2011 at 12:00:29PM +0000, > > freebsd-hackers-request@freebsd.org wrote: > > > Subject: Re: SMP question w.r.t. reading kernel variables > > > To: Rick Macklem > > > Cc: freebsd-hackers@freebsd.org > > > Message-ID: <201104181712.14457.jhb@freebsd.org> > > > > [John Baldwin] > > > On Monday, April 18, 2011 4:22:37 pm Rick Macklem wrote: > > > > > On Sunday, April 17, 2011 3:49:48 pm Rick Macklem wrote: > > ... > > > > All of this makes sense. What I was concerned about was memory > > > > cache > > > > consistency and whet (if anything) has to be done to make sure a > > > > thread > > > > doesn't see a stale cached value for the memory location. > > > > > > > > Here's a generic example of what I was thinking of: > > > > (assume x is a global int and y is a local int on the thread's > > > > stack) > > > > - time proceeds down the screen > > > > thread X on CPU 0 thread Y on CPU 1 > > > > x = 0; > > > > x = 0; /* 0 for x's location > > > > in CPU 1's memory cache */ > > > > x = 1; > > > > y = x; > > > > --> now, is "y" guaranteed to be 1 or can it get the stale cached > > > > 0 value? > > > > if not, what needs to be done to guarantee it? > > > > > > Well, the bigger problem is getting the CPU and compiler to order > > > the > > > instructions such that they don't execute out of order, etc. Because > > > of that, > > > even if your code has 'x = 0; x = 1;' as adjacent threads in thread > > > X, > > > the 'x = 1' may actually execute a good bit after the 'y = x' on CPU > > > 1. > > > > Actually, as I recall the rules for C, it's worse than that. For > > this (admittedly simplified scenario), "x=0;" in thread X may never > > execute unless it's declared volatile, as the compiler may optimize it > > out and emit no code for it. > > > > > > > Locks force that to sychronize as the CPUs coordinate around the > > > lock cookie > > > (e.g. the 'mtx_lock' member of 'struct mutex'). > > > > > > > Also, I see cases of: > > > > mtx_lock(&np); > > > > np->n_attrstamp = 0; > > > > mtx_unlock(&np); > > > > in the regular NFS client. Why is the assignment mutex locked? (I > > > > had assumed > > > > it was related to the above memory caching issue, but now I'm not > > > > so sure.) > > > > > > In general I think writes to data that are protected by locks should > > > always be > > > protected by locks. In some cases you may be able to read data using > > > "weaker" > > > locking (where "no locking" can be a form of weaker locking, but > > > also a > > > read/shared lock is weak, and if a variable is protected by multiple > > > locks, > > > then any singe lock is weak, but sufficient for reading while all of > > > the > > > associated locks must be held for writing) than writing, but writing > > > generally > > > requires "full" locking (write locks, etc.). > > > Oops, I now see that you've differentiated between writing and reading. > (I mistakenly just stated that you had recommended a lock for reading. > Sorry about my misinterpretation of the above on the first quick read.) > > > What he said. In addition to all that, lock operations generate > > "atomic" barriers which a compiler or optimizer is prevented from > > moving code across. > > > All good and useful comments, thanks. > > The above example was meant to be contrived, to indicate what I was > worried about w.r.t. memory caches. > Here's a somewhat simplified version of what my actual problem is: > (Mostly fyi, in case you are interested.) > > Thread X is doing a forced dismount of an NFS volume, it (in dounmount()): > - sets MNTK_UNMOUNTF > - calls VFS_SYNC()/nfs_sync() > - so this doesn't get hung on an unresponsive server it must test > for MNTK_UNMOUNTF and return an error it is set. This seems fine, > since it is the same thread and in a called function. (I can't > imagine that the optimizer could move setting of a global flag > to after a function call which might use it.) > - calls VFS_UNMOUNT()/nfs_unmount() > - now the fun begins... > after some other stuff, it calls nfscl_umount() to get rid of the > state info (opens/locks...) > nfscl_umount() - synchronizes with other threads that will use this > state (see below) using the combination of a mutex and a > shared/exclusive sleep lock. (Because of various quirks in the > code, this shared/exclusive lock is a locally coded version and > I happenned to call the shared case a refcnt and the exclusive > case just a lock.) > > Other threads that will use state info (open/lock...) will: > -call nfscl_getcl() > - this function does two things that are relevant > 1 - it allocates a new clientid, as required, while holding the mutex > - this case needs to check for MNTK_UNMOUNTF and return error, in > case the clientid has already been deleted by nfscl_umount() above. > (This happens before #2 because the sleep lock is in the clientd > structure.) > --> it must see the MNTK_UNMOUNTF set if it happens after (in a temporal > sense) > being set by dounmount() > 2 - while holding the mutex, it acquires the shared lock > - if this happens before nfscl_umount() gets the exclusive lock, it is > fine, since acquisition of the exclusive lock above will wait for > its > release > however > - if it acquires the shared lock after nfscl_umount() has had the > exclusive lock or competes with nfscl_umount() for the lock, it > could be in trouble. > - my planned fix for this is to test for MNTK_UNMOUNTF as it tries > to get the shared lock (and fail with an error return if it is > set) > before if goes to sleep waiting for the exclusive lock to be > released. (Othere things acquire this exclusive lock, so waiting > for > it usually makes sense, except this case.) > --> again, I think this is fine so long as it sees MNTK_UNMOUNTF set when > the > the test occurs after (in a temporal sense) it was set by the forced > dismount > thread, since that thread set it before calling > VFS_UNMOUNT()...nfscl_umount(). > > Now, in practice, I don't believe there is a problem, but since I have yet > to > see anyone state what the rules/assumptions for memory cache consistency > are > w.r.t. SMP, I thought I'd pursue it. > > In essence, the rules are as follows. Take any given memory location X. Suppose a series of writes, X1, X2, X3, .. are performed on this location. Once a particular processor has read the effect of say, X2, any future read on the same location by the same processor can't roll back in time to read the effect of an earlier write such as X1. That future read must return at least the result of X2, but you should not expect that the effect of a write, say X3, is seen instantaneously by another processor. Now, if you consider two memory locations X and Y simultaneously, this is where things become complicated. While one processor may see a write X1 before it sees a write Y1, i.e., it reads the effects of X1 and then Y0, another processor may see these writes occurring in the opposite order, i.e., it reads Y1 and then X0. In fact, in some machines, this can happen even if X1 and Y1 are performed by the same processor. Memory barriers if used correctly allow you, the programmer, to control the order in which writes to X and Y are seen. For example, suppose one processor performs a write X1 followed by a "release" write Y1, then another processor performs an "acquire" read on location Y. If this other processor sees the effect of the "release" write Y1, then it is guaranteed to see the effect of the write X1 when it later reads X. This is why mtx_lock() is implemented using an "acquire" read-modify-write operation and mtx_unlock() is implemented using a "release" operation. However, a write doesn't have to be between the "acquire" and the "release" to be ordered by the "release". In other words, suppose that your Thread X does 1. Set MNTK_UNMOUNTF 2. Acquire a standard FreeBSD mutex "m". 3. Update some data structures. 4. Release mutex "m". Then, other threads that acquire "m" after step 4 has occurred will see MNTK_UNMOUNTF as set. But, other threads that beat thread X to step 2 may or may not see MNTK_UNMOUNTF as set. The question that I have about your specific scenario is concerned with VOP_SYNC(). Do you care if another thread performing nfscl_getcl() after thread X has performed VOP_SYNC() doesn't see MNTK_UNMOUNTF as set? Another relevant question is "Does VOP_SYNC() acquire and release the same mutex as nfscl_umount() and nfscl_getcl()?" Regards, Alan From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 20 21:27:57 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9BC7106564A for ; Wed, 20 Apr 2011 21:27:57 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 637C98FC08 for ; Wed, 20 Apr 2011 21:27:57 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkEHABVPr02DaFvO/2dsb2JhbACEUZMpjkKIb60pkRaBKYNOegSOIg X-IronPort-AV: E=Sophos;i="4.64,247,1301889600"; d="scan'208";a="119030013" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 20 Apr 2011 17:27:56 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 7266AB3F73; Wed, 20 Apr 2011 17:27:56 -0400 (EDT) Date: Wed, 20 Apr 2011 17:27:56 -0400 (EDT) From: Rick Macklem To: alc@freebsd.org Message-ID: <1793102603.378435.1303334876373.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE7 (Win)/6.0.10_GA_2692) Cc: freebsd-hackers Subject: Re: SMP question w.r.t. reading kernel variables X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 21:27:57 -0000 [good stuff snipped for brevity] > > 1. Set MNTK_UNMOUNTF > 2. Acquire a standard FreeBSD mutex "m". > 3. Update some data structures. > 4. Release mutex "m". > > Then, other threads that acquire "m" after step 4 has occurred will > see > MNTK_UNMOUNTF as set. But, other threads that beat thread X to step 2 > may > or may not see MNTK_UNMOUNTF as set. > First off, Alan, thanks for the great explanation. I think it would be nice if this was captured somewhere in the docs, if it isn't already there somewhere (I couldn't spot it, but that doesn't mean anything:-). > The question that I have about your specific scenario is concerned > with > VOP_SYNC(). Do you care if another thread performing nfscl_getcl() > after > thread X has performed VOP_SYNC() doesn't see MNTK_UNMOUNTF as set? Well, no and yes. It doesn't matter if it doesn't see it after thread X performed nfs_sync(), but it does matter that the threads calling nfscl_getcl() see it before they compete with thread X for the sleep lock. > Another > relevant question is "Does VOP_SYNC() acquire and release the same > mutex as > nfscl_umount() and nfscl_getcl()?" > No. So, to get this to work correctly it sounds like I have to do one of the following: 1 - mtx_lock(m); mtx_unlock(m); in nfs_sync(), where "m" is the mutex used by nfscl_getcl() for the NFS open/lock state. or 2 - mtx_lock(m); mtx_unlock(m); mtx_lock(m); before the point where I care that the threads executing nfscl_getcl() see MNTK_UMOUNTF set in nfscl_umount(). or 3 - mtx_lock(m2); mtx_unlock(m2); in nfscl_getcl(), where m2 is the mutex used by thread X when setting MNTK_UMOUNTF, before mtx_lock(m); and then testing MNTK_UMOUNTF plus acquiring the sleep lock. (By doing it before, I can avoid any LOR issue and do an msleep() without worrying about having two mutex locks.) I think #3 reads the best, so I'll probably do that one. One more question, if you don't mind. Is step 3 in your explanation necessary for this to work? If it is, I can just create some global variable that I assign a value to between mtx_lock(m2); mtx_unlock(m2); but it won't be used for anything, so I thought I'd check if it is necessary? Thanks again for the clear explanation, rick From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 20 21:40:23 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 99275106566B; Wed, 20 Apr 2011 21:40:23 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 3E5468FC0A; Wed, 20 Apr 2011 21:40:22 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkEHAFpSr02DaFvO/2dsb2JhbACEUJMqjkK2G5ERgSmDTnoEjiI X-IronPort-AV: E=Sophos;i="4.64,247,1301889600"; d="scan'208";a="119031229" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 20 Apr 2011 17:40:22 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 632DFB3F32; Wed, 20 Apr 2011 17:40:22 -0400 (EDT) Date: Wed, 20 Apr 2011 17:40:22 -0400 (EDT) From: Rick Macklem To: alc@freebsd.org Message-ID: <1904651983.378809.1303335622389.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <1793102603.378435.1303334876373.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE7 (Win)/6.0.10_GA_2692) Cc: freebsd-hackers Subject: Re: SMP question w.r.t. reading kernel variables X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 21:40:23 -0000 > [good stuff snipped for brevity] > > > > 1. Set MNTK_UNMOUNTF > > 2. Acquire a standard FreeBSD mutex "m". > > 3. Update some data structures. > > 4. Release mutex "m". > > > > Then, other threads that acquire "m" after step 4 has occurred will > > see > > MNTK_UNMOUNTF as set. But, other threads that beat thread X to step > > 2 > > may > > or may not see MNTK_UNMOUNTF as set. > > > First off, Alan, thanks for the great explanation. I think it would be > nice if this was captured somewhere in the docs, if it isn't already > there somewhere (I couldn't spot it, but that doesn't mean > anything:-). > > > The question that I have about your specific scenario is concerned > > with > > VOP_SYNC(). Do you care if another thread performing nfscl_getcl() > > after > > thread X has performed VOP_SYNC() doesn't see MNTK_UNMOUNTF as set? > > Well, no and yes. It doesn't matter if it doesn't see it after thread > X > performed nfs_sync(), but it does matter that the threads calling > nfscl_getcl() > see it before they compete with thread X for the sleep lock. > > > Another > > relevant question is "Does VOP_SYNC() acquire and release the same > > mutex as > > nfscl_umount() and nfscl_getcl()?" > > > No. So, to get this to work correctly it sounds like I have to do one > of the following: > 1 - mtx_lock(m); mtx_unlock(m); in nfs_sync(), where "m" is the mutex > used > by nfscl_getcl() for the NFS open/lock state. > or > 2 - mtx_lock(m); mtx_unlock(m); mtx_lock(m); before the point where I > care > that the threads executing nfscl_getcl() see MNTK_UMOUNTF set in > nfscl_umount(). > or > 3 - mtx_lock(m2); mtx_unlock(m2); in nfscl_getcl(), where m2 is the > mutex used > by thread X when setting MNTK_UMOUNTF, before mtx_lock(m); and then > testing > MNTK_UMOUNTF plus acquiring the sleep lock. (By doing it before, I can > avoid > any LOR issue and do an msleep() without worrying about having two > mutex locks.) > > I think #3 reads the best, so I'll probably do that one. > > One more question, if you don't mind. > > Is step 3 in your explanation necessary for this to work? If it is, I > can just create > some global variable that I assign a value to between mtx_lock(m2); > mtx_unlock(m2); > but it won't be used for anything, so I thought I'd check if it is > necessary? > Oops, I screwed up this question. For my #3, all that needs to be done in nfscl_getcl() before I care if it sees MNTK_UMOUNTF set is mtx_lock(m2); since that has already gone through your steps 1-4. The question w.r.t. do you really need your step 3 would apply to the cases where I was using "m" (the mutex nfscl_umount() and nfscl_getcl() already use instead of the one used by thread X). rick From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 21 05:42:58 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93E2F106564A for ; Thu, 21 Apr 2011 05:42:58 +0000 (UTC) (envelope-from giffunip@tutopia.com) Received: from nm25.bullet.mail.sp2.yahoo.com (nm25.bullet.mail.sp2.yahoo.com [98.139.91.95]) by mx1.freebsd.org (Postfix) with SMTP id 72F898FC13 for ; Thu, 21 Apr 2011 05:42:58 +0000 (UTC) Received: from [98.139.91.69] by nm25.bullet.mail.sp2.yahoo.com with NNFMP; 21 Apr 2011 05:29:56 -0000 Received: from [98.139.91.12] by tm9.bullet.mail.sp2.yahoo.com with NNFMP; 21 Apr 2011 05:29:56 -0000 Received: from [127.0.0.1] by omp1012.mail.sp2.yahoo.com with NNFMP; 21 Apr 2011 05:29:56 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 317711.18870.bm@omp1012.mail.sp2.yahoo.com Received: (qmail 80374 invoked by uid 60001); 21 Apr 2011 05:29:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1303363795; bh=JQCTnPgqa4QeJ1RkV5AN9iyQBM2OVqjOyyMYF86EuQM=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=h2XCNs3HJFOVTkP5G05ZSdLVcQV3T5S9wHgtbyjGC3puHuIKYN56OYubpPyY/D4UxrTR1fzbHKmXJRXVh/531qdQ+Bvk6W20pyu77MB2XLOwH9W9amRmZzyHr73cYIQAVDaassQNnHtOcph9EFhcLFjARziNHqjl156JGqioedU= Message-ID: <725315.78611.qm@web113511.mail.gq1.yahoo.com> X-YMail-OSG: GxjV.ecVM1nYe.thGGD_9FySQjZBCmY6U_fvyYzj3tu.X.W WP4LpaUXjDgnvSU36FCaQbj3.6Rckr2k4gPTZFp5rdvQqfuHBHZoWluhHQ4O AdMZYOhCZzar.COjujKuWf44WmfLmbqYIhckQyeqCWyYsHjyRwLFj4yl6aL6 PkMiVfyZY93Gx1I6IAXKUV1C3X0eEIVpE8KyVr1_EhyrbSINqDdHDI9cNQzz aIWDivdjSfqcq9LrLaO5QCfFFsrCeZWDrz7.pBJjbfMbGp5jkqHjNGX0jy_k BQbMVJmN9BIKeXSIWggzFhU5nbmvXhFpDXsOywgJzM7iD99MLcYnqGTqyVoZ R5LNDcX9Seyz.xdDuU0EtzaIgICGudcLQO.SLaYPACXuYQXWdHYE1HNDBe6L lBxz.LVwUegYQiLI- Received: from [190.157.141.135] by web113511.mail.gq1.yahoo.com via HTTP; Wed, 20 Apr 2011 22:29:55 PDT X-RocketYMMF: giffunip X-Mailer: YahooMailClassic/12.0.2 YahooMailWebService/0.8.109.295617 Date: Wed, 20 Apr 2011 22:29:55 -0700 (PDT) From: "Pedro F. Giffuni" To: hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Thu, 21 Apr 2011 10:57:40 +0000 Cc: Subject: Log/linear quantizations in DTrace X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: giffunip@tutopia.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 05:42:58 -0000 Just thought someone might be interested in the new Dtrace developments being made at Joyent that have just been contributed to Illumos: http://dtrace.org/blogs/bmc/2011/02/08/llquantize/ http://www2.purplecow.org/?p=189 cheers, Pedro. From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 21 19:37:40 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D2DE106564A for ; Thu, 21 Apr 2011 19:37:40 +0000 (UTC) (envelope-from lgj@usenix.org) Received: from lonestar.usenix.org (lonestar.usenix.org [131.106.3.102]) by mx1.freebsd.org (Postfix) with ESMTP id 849E48FC18 for ; Thu, 21 Apr 2011 19:37:40 +0000 (UTC) Received: from negroni.usenix.org (negroni.usenix.org [131.106.3.145]) (authenticated bits=0) by lonestar.usenix.org (8.14.2/8.14.2) with ESMTP id p3LJbZ1i029900 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 21 Apr 2011 12:37:40 -0700 (PDT) From: Lionel Garth Jones Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 21 Apr 2011 12:37:39 -0700 Message-Id: To: freebsd-hackers@freebsd.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-DCC-USENIX-Metrics: lonestar; whitelist X-Spam-Status: No, score=0.7 required=6.0 tests=ALL_TRUSTED, FH_DATE_PAST_20XX autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on lonestar X-Mailman-Approved-At: Thu, 21 Apr 2011 19:54:50 +0000 Subject: USENIX HotPar '11 Registration Now Open to Everyone X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 19:37:40 -0000 You are invited to join us for the 3rd USENIX Workshop on Hot Topics in Parallelism (HotPar '11). The workshop will take place May 26-27, 2011, in Berkeley, CA. http://www.usenix.org/hotpar11/proga/ HotPar '11 will bring together researchers and practitioners doing innovative work in the area of parallel computing. HotPar recognizes the broad impact of multicore computing and seeks relevant contributions in all fields, including application design, languages and compilers, systems, and architecture. Attendance at the workshop is now open the USENIX community. To ensure a productive environment, it will be limited to 75 participants. Register today to ensure your place. This year's outstanding program includes a diverse range of hot research areas including multicore performance optimization, pervasive parallelism, algorithm architecture, and more. Please join us at Clark Kerr on the University of California, Berkeley, campus for the workshop covering the most innovative research in parallel computing. We look forward to seeing you there. Sincerely, Michael McCool, Intel Mendel Rosenblum, Stanford University HotPar '11 Program Co-Chairs hotpar11chairs@usenix.org ------------------------------------------------------------------------ 3rd USENIX Workshop on Hot Topics in Parallelism (HotPar '11) Sponsored by USENIX in cooperation with ACM SIGMETRICS, ACM SIGSOFT, ACM SIGOPS, ACM SIGARCH, and ACM SIGPLAN May 26-27, 2011, Berkeley, CA http://www.usenix.org/hotpar11/proga/ ----------------------------------------------------------------------- From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 21 21:25:12 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10F04106564A; Thu, 21 Apr 2011 21:25:12 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id ADF6E8FC19; Thu, 21 Apr 2011 21:25:11 +0000 (UTC) Received: from sbhfislrext01.fnfis.com ([192.168.249.167]) by SCSFISLTC02 (8.14.3/8.14.3) with ESMTP id p3LLPAjf001075; Thu, 21 Apr 2011 16:25:10 -0500 Received: from sbhfisltcgw02.FNFIS.COM (Not Verified[10.132.248.122]) by sbhfislrext01.fnfis.com with MailMarshal (v6, 5, 4, 7535) id ; Thu, 21 Apr 2011 16:25:03 -0500 Received: from sbhfisltcgw02.FNFIS.COM ([10.132.248.122]) by sbhfisltcgw02.FNFIS.COM with Microsoft SMTPSVC(6.0.3790.4675); Thu, 21 Apr 2011 16:25:10 -0500 Received: from dtwin ([10.132.254.135]) by sbhfisltcgw02.FNFIS.COM over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 21 Apr 2011 16:25:06 -0500 From: "Devin Teske" To: , Date: Thu, 21 Apr 2011 14:24:35 -0700 Organization: Vicor, Inc. Message-ID: <02a701cc006a$887da210$9978e630$@vicor.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcwAZojr2S8H9KcjT0+Gt5oHQUc5ZA== Content-Language: en-us X-OriginalArrivalTime: 21 Apr 2011 21:25:07.0803 (UTC) FILETIME=[967A42B0:01CC006A] Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "Teske, Devin" Subject: [UPDATE] host-setup(1): a dialog(1)-based utility for configuring FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 21:25:12 -0000 Hi List Members! I'm proud to announce the first update to my host-setup utility (a dialog(1)-based host configurator for FreeBSD). The following changes have been made: - fixed bug where /etc/resolv.conf would be created with 0600 permissions - fixed bug when switching from one default gateway to NO default gateway - fixed typo in the title of netmask prompt and ifconfig options dialog - fixed bug that prevented entry of netmask if no netmask is configured You can get the updated version here: http://druidbsd.sourceforge.net/download/host-setup.txt or http://druidbsd.sourceforge.net/download/host-setup.gz or http://druidbsd.sourceforge.net/ For those not familiar with my host-setup(1) utility, it is a 2,500+ line shell script that utilizes the dialog(1) utility to walk the system administrator through setting up their TimeZone, Hostname, Network Interfaces, Default Gateway, and DNS. Our custom FreeBSD installer sets this script as the root login shell, making it very easy for field engineers to quickly get a system on the network without having to use the command-line (and without having to reboot either). Underneath the hood - behind the system of prompts and dialogs - this script manages both the contents of /etc/rc.conf, /etc/resolv.conf, and others as well as utilizing ifconfig(8), route(8), and many other tools to avoid requiring a reboot, prompting you if you would like to make the new changes effective when values are changed from their active settings. Here's the patch to show the details: --- host-setup.3_0 2011-02-10 19:14:30.000000000 -0800 +++ host-setup 2011-04-21 13:38:58.000000000 -0700 @@ -2,12 +2,12 @@ # -*- tab-width: 4 -*- ;; Emacs # vi: set tabstop=4 :: Vi/ViM # -# Revision: 3.0 +# Revision: 3.1 # Created: September 21st, 2010 -# Last Modified: December 6th, 2010 +# Last Modified: April 21st, 2011 ############################################################ COPYRIGHT # -# Devin Teske (c)2006-2010. All Rights Reserved. +# Devin Teske (c)2006-2011. All Rights Reserved. # # Redistribution and use in source and binary forms, with or without # modification, are permitted provided that the following conditions @@ -1353,8 +1353,10 @@ dialog_input_hostname() # permissions and ownership to match resolv.conf(5) before # we write it out and mv(1) it into place). # - quietly chmod "$( stat -f '%#Lp' "$RESOLV_CONF" )" "$tmpfile" - quietly chown "$( stat -f '%u:%g' "$RESOLV_CONF" )" "$tmpfile" + local mode="$( stat -f '%#Lp' "$RESOLV_CONF" 2> /dev/null )" + local owner="$( stat -f '%u:%g' "$RESOLV_CONF" 2> /dev/null )" + quietly chmod "${mode:-0644}" "$tmpfile" + quietly chown "${owner:-root:wheel}" "$tmpfile" # # Operate on resolv.conf(5), replacing only the last @@ -1646,7 +1648,7 @@ dialog_input_netmask() # while :; do - dialog --title "$brand${band:+}${progname:-$0}" \ + dialog --title "$brand${brand:+ }${progname:-$0}" \ --hline "Use numbers, punctuation, TAB or ENTER" \ --inputbox "$msg" 10 50 \ "$_netmask" \ @@ -1664,7 +1666,7 @@ dialog_input_netmask() [ $retval -eq $SUCCESS ] || return $retval # Return success if NULL value was entered - [ "$_netmask" ] || return $SUCCESS + [ "$_input" ] || return $SUCCESS # Take only the first "word" of the user's input _netmask="$_input" @@ -1705,7 +1707,7 @@ dialog_input_options() msg="Please enter additional network media options to be" msg="$msg passed to ifconfig(8) for the $interface interface:" - dialog --title "$brand${band:+}${progname:-$0}" \ + dialog --title "$brand${brand:+ }${progname:-$0}" \ --hline "Use numbers, punctuation, TAB or ENTER" \ --inputbox "$msg" 9 70 \ "$options" \ @@ -2183,9 +2185,12 @@ dialog_menu_netdev_edit() local dr="$( sysrc_get defaultrouter )" err err=$( ifconfig $interface inet $ipaddr \ netmask $netmask $options 2>&1 ) - if [ $? -eq $SUCCESS -a "$dr" ]; then - err=$( route add default "$dr" 2>&1 ) - [ $? -eq $SUCCESS ] || dialog_msgbox "$err" + if [ $? -eq $SUCCESS ]; then + if [ "$dr" -a "$dr" != "NO" ]; then + err=$( route add default "$dr" 2>&1 ) + [ $? -eq $SUCCESS ] || \ + dialog_msgbox "$err" + fi else dialog_msgbox "$err" fi @@ -2524,7 +2529,7 @@ exit $SUCCESS # # $Header$ # -# $Copyright: 2006-2010. Devin Teske. All Rights Reserved. $ +# $Copyright: 2006-2011. Devin Teske. All Rights Reserved. $ # # $Log$ # -- Cheers, Devin Teske -> FUN STUFF <- -----BEGIN GEEK CODE BLOCK----- Version 3.12 GAT/CS/B/CC/E/IT/MC/M/MU/P/S/TW d+(++) s: a- C+++@$ UB++++$ P++++@$ L++++$ E- W+++ N? o? K? w@ O M++$ V- PS+>++ PE@ Y+ PGP-> t(+) 5? X(+) R(-) tv+ b+>++ DI+ D+(++) G++ e>++++ h r+++ z+++ ------END GEEK CODE BLOCK------ Learn about the "Geek Code": http://www.geekcode.com/ -> LEGAL DISCLAIMER <- This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy. -> END TRANSMISSION <- _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. _____________ From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 21 21:17:26 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 517321065674 for ; Thu, 21 Apr 2011 21:17:26 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id 9D8C78FC12 for ; Thu, 21 Apr 2011 21:17:25 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id AF63B1E000E4; Thu, 21 Apr 2011 23:00:29 +0200 (CEST) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.4/8.14.3) with ESMTP id p3LKxhBG075776; Thu, 21 Apr 2011 22:59:43 +0200 (CEST) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.4/8.14.3/Submit) id p3LKxhnD075775; Thu, 21 Apr 2011 22:59:43 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Thu, 21 Apr 2011 22:59:42 +0200 To: emulation@freebsd.org Message-ID: <20110421205942.GA75591@triton8.kn-bremen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Thu, 21 Apr 2011 21:26:29 +0000 Cc: freebsd-hackers@freebsd.org, Alexander Leidinger , "J.R. Oldroyd" , Andrew Gallatin Subject: Does this Linuxolaotor DVB wrapper port look good now? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 21:17:26 -0000 Also at: http://people.freebsd.org/~nox/dvb/linux_dvbwrapper-kmod.shar If anyone can test it, even the better! :) (Still seems to be working here with the Linux w_scan on dvb-s2.) Thanx! Juergen PS: If anyone is wondering why this is a port now, one of the header contains lgpl'd parts out of the Linux dvb headers and I got no reply from the author of those parts... :( # This is a shell archive. Save it in a file, remove anything before # this line, and then unpack it by entering "sh file". Note, it may # create directories; files and directories will be owned by you and # have default permissions. # # This archive contains: # # linux_dvbwrapper-kmod/ # linux_dvbwrapper-kmod/Makefile # linux_dvbwrapper-kmod/pkg-descr # linux_dvbwrapper-kmod/files/ # linux_dvbwrapper-kmod/files/Makefile # linux_dvbwrapper-kmod/files/linux_dvb.h # linux_dvbwrapper-kmod/files/linux_dvb_compat.h # linux_dvbwrapper-kmod/files/linux_dvb_ioctl.h # linux_dvbwrapper-kmod/files/linux_dvbwrapper.c # echo c - linux_dvbwrapper-kmod/ mkdir -p linux_dvbwrapper-kmod/ > /dev/null 2>&1 echo x - linux_dvbwrapper-kmod/Makefile sed 's/^X//' >linux_dvbwrapper-kmod/Makefile << '66b9bcdcacf08b242d7eaa0e47aae7b9' X# New ports collection makefile for: linux_dvbwrapper-kmod X# Date created: Thu Apr 21 17:34:08 CEST 2011 X# Whom: nox@FreeBSD.org X# X# $FreeBSD: $ X# X XPORTNAME= linux_dvbwrapper-kmod XPORTVERSION= 1.0 XCATEGORIES= multimedia kld XDISTFILES= # none X XMAINTAINER= nox@FreeBSD.org XCOMMENT= Linux compatibility layer - DVB ioctl handler X XONLY_FOR_ARCHS= i386 amd64 X X.include X XPLIST_FILES+= "@cwd /" XPLIST_FILES+= ${KMODDIR:C,^/,,}/linux_dvbwrapper.ko XPLIST_FILES+= "@exec kldxref ${KMODDIR}" XPLIST_FILES+= "@unexec kldxref ${KMODDIR}" X X# install where x11/nvidia-driver does also: XKMODDIR= /boot/modules X XMAKE_ENV+= KMODDIR="${KMODDIR}" X XSYSDIR?= ${SRC_BASE}/sys XMAKE_ENV+= SYSDIR="${SYSDIR}" X XCFLAGS+= ${DEBUG_FLAGS} X X.if !exists(${SYSDIR}/Makefile) XIGNORE= requires kernel source to be installed X.endif X Xdo-extract: X ${MKDIR} ${WRKSRC} X ${CP} ${FILESDIR}/Makefile ${FILESDIR}/*.[ch] ${WRKSRC} X X.include 66b9bcdcacf08b242d7eaa0e47aae7b9 echo x - linux_dvbwrapper-kmod/pkg-descr sed 's/^X//' >linux_dvbwrapper-kmod/pkg-descr << '51aa72c06ddc530c5f43cce2137dd05f' XThis kld adds DVB ioctl handling to the Linux compatibility layer Xso that Linux apps can talk to DVB/ATSC tuners via /dev/dvb/adapterX. X XNote this port does not contain actual DVB drivers, those are Xprovided by e.g. the multimedia/webcamd port. X XWWW: http://people.freebsd.org/~nox/dvb/ 51aa72c06ddc530c5f43cce2137dd05f echo c - linux_dvbwrapper-kmod/files/ mkdir -p linux_dvbwrapper-kmod/files/ > /dev/null 2>&1 echo x - linux_dvbwrapper-kmod/files/Makefile sed 's/^X//' >linux_dvbwrapper-kmod/files/Makefile << 'ff39e52f2dfa811e700ef33bcb10ae95' X# $FreeBSD: $ X X.if ${MACHINE_ARCH} == "amd64" XSFX= 32 XCFLAGS+=-DCOMPAT_FREEBSD32 -DCOMPAT_LINUX32 X.endif X XCWARNFLAGS+=-Wno-missing-prototypes X XKMOD= linux_dvbwrapper XSRCS= linux_dvbwrapper.c X X.include ff39e52f2dfa811e700ef33bcb10ae95 echo x - linux_dvbwrapper-kmod/files/linux_dvb.h sed 's/^X//' >linux_dvbwrapper-kmod/files/linux_dvb.h << '6677d8bf6fe9a16f05c826d0c116c855' X/* X * Extracted from , which is: X * X * Copyright (C) 2000 Marcus Metzler X * Ralph Metzler X * Holger Waechtler X * Andre Draszik X * for convergence integrated media GmbH X * X * This program is free software; you can redistribute it and/or X * modify it under the terms of the GNU Lesser General Public License X * as published by the Free Software Foundation; either version 2.1 X * of the License, or (at your option) any later version. X * X * This program is distributed in the hope that it will be useful, X * but WITHOUT ANY WARRANTY; without even the implied warranty of X * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the X * GNU General Public License for more details. X * X * You should have received a copy of the GNU Lesser General Public License X * along with this program; if not, write to the Free Software X * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. X * X */ X X#ifndef __LINUX_DVB_H X#define __LINUX_DVB_H X X#include X Xstruct dtv_property { X uint32_t cmd; X uint32_t reserved[3]; X union { X uint32_t data; X struct { X uint8_t data[32]; X uint32_t len; X uint32_t reserved1[3]; X void *reserved2; X } buffer; X } u; X int result; X} __attribute__ ((packed)); X X/* num of properties cannot exceed DTV_IOCTL_MAX_MSGS per ioctl */ X#define DTV_IOCTL_MAX_MSGS 64 X Xstruct dtv_properties { X uint32_t num; X struct dtv_property *props; X}; X X#define FE_SET_PROPERTY _IOW('o', 82, struct dtv_properties) X/* X * This is broken on linux as well but they workaround it in the driver. X * Since this is impossible to do on FreeBSD fix the header instead. X * Detailed and discussion : X * http://lists.freebsd.org/pipermail/freebsd-multimedia/2010-April/010958.html X */ X#define FE_GET_PROPERTY _IOW('o', 83, struct dtv_properties) X X#endif /*__LINUX_DVB_H*/ 6677d8bf6fe9a16f05c826d0c116c855 echo x - linux_dvbwrapper-kmod/files/linux_dvb_compat.h sed 's/^X//' >linux_dvbwrapper-kmod/files/linux_dvb_compat.h << '827c22870bae42a8ffb3d63ad3e605d6' X#ifndef __LINUX_DVB_COMPAT_H X#define __LINUX_DVB_COMPAT_H X X#include X Xstruct l_dtv_property { X uint32_t cmd; X uint32_t reserved[3]; X union { X uint32_t data; X struct { X uint8_t data[32]; X uint32_t len; X uint32_t reserved1[3]; X l_uintptr_t reserved2; X } buffer; X } u; X l_int result; X} __attribute__ ((packed)); X Xstruct l_dtv_properties { X uint32_t num; X l_uintptr_t props; X}; X X#endif /*__LINUX_DVB_H*/ 827c22870bae42a8ffb3d63ad3e605d6 echo x - linux_dvbwrapper-kmod/files/linux_dvb_ioctl.h sed 's/^X//' >linux_dvbwrapper-kmod/files/linux_dvb_ioctl.h << '0599fcbdb1e16725afdc6cae52772454' X/*- X * Copyright (c) 2011 Juergen Lock X * All rights reserved. X * X * Redistribution and use in source and binary forms, with or without X * modification, are permitted provided that the following conditions X * are met: X * 1. Redistributions of source code must retain the above copyright X * notice, this list of conditions and the following disclaimer X * in this position and unchanged. X * 2. Redistributions in binary form must reproduce the above copyright X * notice, this list of conditions and the following disclaimer in the X * documentation and/or other materials provided with the distribution. X * 3. The name of the author may not be used to endorse or promote products X * derived from this software without specific prior written permission. X * X * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR X * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES X * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. X * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, X * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT X * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, X * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY X * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT X * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF X * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. X * X * $FreeBSD: $ X */ X X#ifndef _LINUX_DVB_IOCTL_H_ X#define _LINUX_DVB_IOCTL_H_ X X/* X * ioctl X * X * XXX comments in Linux' indicate these X * could be arch-dependant... X */ X#define LINUX_IOC_VOID 0 X#define LINUX_IOC_IN 0x40000000 X#define LINUX_IOC_OUT 0x80000000 X#define LINUX_IOC_INOUT (LINUX_IOC_IN|LINUX_IOC_OUT) X X/* X * DVB (osd.h and video.h not handled) X */ X#define LINUX_AUDIO_STOP 0x6f01 /* 0x00006f01 */ X#define LINUX_AUDIO_PLAY 0x6f02 /* 0x00006f02 */ X#define LINUX_AUDIO_PAUSE 0x6f03 /* 0x00006f03 */ X#define LINUX_AUDIO_CONTINUE 0x6f04 /* 0x00006f04 */ X#define LINUX_AUDIO_SELECT_SOURCE 0x6f05 /* 0x00006f05 */ X#define LINUX_AUDIO_SET_MUTE 0x6f06 /* 0x00006f06 */ X#define LINUX_AUDIO_SET_AV_SYNC 0x6f07 /* 0x00006f07 */ X#define LINUX_AUDIO_SET_BYPASS_MODE 0x6f08 /* 0x00006f08 */ X#define LINUX_AUDIO_CHANNEL_SELECT 0x6f09 /* 0x00006f09 */ X#define LINUX_AUDIO_GET_STATUS 0x6f0a /* 0x80206f0a */ X#define LINUX_AUDIO_GET_CAPABILITIES 0x6f0b /* 0x80046f0b */ X#define LINUX_AUDIO_CLEAR_BUFFER 0x6f0c /* 0x00006f0c */ X#define LINUX_AUDIO_SET_ID 0x6f0d /* 0x00006f0d */ X#define LINUX_AUDIO_SET_MIXER 0x6f0e /* 0x40086f0e */ X#define LINUX_AUDIO_SET_STREAMTYPE 0x6f0f /* 0x00006f0f */ X#define LINUX_AUDIO_SET_EXT_ID 0x6f10 /* 0x00006f10 */ X#define LINUX_AUDIO_SET_ATTRIBUTES 0x6f11 /* 0x40026f11 */ X#define LINUX_AUDIO_SET_KARAOKE 0x6f12 /* 0x400c6f12 */ X#define LINUX_AUDIO_GET_PTS 0x6f13 /* 0x80086f13 */ X#define LINUX_AUDIO_BILINGUAL_CHANNEL_SELECT 0x6f14 /* 0x00006f14 */ X#define LINUX_DMX_START 0x6f29 /* 0x00006f29 */ X#define LINUX_DMX_STOP 0x6f2a /* 0x00006f2a */ X#define LINUX_DMX_SET_FILTER 0x6f2b /* 0x403c6f2b */ X#define LINUX_DMX_SET_PES_FILTER 0x6f2c /* 0x40146f2c */ X#define LINUX_DMX_SET_BUFFER_SIZE 0x6f2d /* 0x00006f2d */ X#define LINUX_DMX_GET_PES_PIDS 0x6f2f /* 0x800a6f2f */ X#define LINUX_DMX_GET_CAPS 0x6f30 /* 0x80086f30 */ X#define LINUX_DMX_SET_SOURCE 0x6f31 /* 0x40046f31 */ X#define LINUX_DMX_GET_STC 0x6f32 /* 0xc0106f32 */ X#define LINUX_DMX_ADD_PID 0x6f33 /* 0x40026f33 */ X#define LINUX_DMX_REMOVE_PID 0x6f34 /* 0x40026f34 */ X#define LINUX_FE_GET_INFO 0x6f3d /* 0x80a86f3d */ X#define LINUX_FE_DISEQC_RESET_OVERLOAD 0x6f3e /* 0x00006f3e */ X#define LINUX_FE_DISEQC_SEND_MASTER_CMD 0x6f3f /* 0x40076f3f */ X#define LINUX_FE_DISEQC_RECV_SLAVE_REPLY 0x6f40 /* 0x800c6f40 */ X#define LINUX_FE_DISEQC_SEND_BURST 0x6f41 /* 0x00006f41 */ X#define LINUX_FE_SET_TONE 0x6f42 /* 0x00006f42 */ X#define LINUX_FE_SET_VOLTAGE 0x6f43 /* 0x00006f43 */ X#define LINUX_FE_ENABLE_HIGH_LNB_VOLTAGE 0x6f44 /* 0x00006f44 */ X#define LINUX_FE_READ_STATUS 0x6f45 /* 0x80046f45 */ X#define LINUX_FE_READ_BER 0x6f46 /* 0x80046f46 */ X#define LINUX_FE_READ_SIGNAL_STRENGTH 0x6f47 /* 0x80026f47 */ X#define LINUX_FE_READ_SNR 0x6f48 /* 0x80026f48 */ X#define LINUX_FE_READ_UNCORRECTED_BLOCKS 0x6f49 /* 0x80046f49 */ X#define LINUX_FE_SET_FRONTEND 0x6f4c /* 0x40246f4c */ X#define LINUX_FE_GET_FRONTEND 0x6f4d /* 0x80246f4d */ X#define LINUX_FE_GET_EVENT 0x6f4e /* 0x80286f4e */ X#define LINUX_FE_DISHNETWORK_SEND_LEGACY_CMD 0x6f50 /* 0x00006f50 */ X#define LINUX_FE_SET_FRONTEND_TUNE_MODE 0x6f51 /* 0x00006f51 */ X#define LINUX_FE_SET_PROPERTY 0x6f52 /* 0x40086f52 */ X#define LINUX_FE_GET_PROPERTY 0x6f53 /* 0x80086f53 */ X#define LINUX_CA_RESET 0x6f80 /* 0x00006f80 */ X#define LINUX_CA_GET_CAP 0x6f81 /* 0x80106f81 */ X#define LINUX_CA_GET_SLOT_INFO 0x6f82 /* 0x800c6f82 */ X#define LINUX_CA_GET_DESCR_INFO 0x6f83 /* 0x80086f83 */ X#define LINUX_CA_GET_MSG 0x6f84 /* 0x810c6f84 */ X#define LINUX_CA_SEND_MSG 0x6f85 /* 0x410c6f85 */ X#define LINUX_CA_SET_DESCR 0x6f86 /* 0x40106f86 */ X#define LINUX_CA_SET_PID 0x6f87 /* 0x40086f87 */ X X/* X * DVB net.h X * (LINUX_NET_ADD_IF and LINUX___NET_ADD_IF_OLD overlap with X * LINUX_DMX_REMOVE_PID) X */ X#define LINUX_NET_ADD_IF 0x6f34 /* 0xc0066f34 */ X#define LINUX_NET_REMOVE_IF 0x6f35 /* 0x00006f35 */ X#define LINUX_NET_GET_IF 0x6f36 /* 0xc0066f36 */ X#define LINUX___NET_ADD_IF_OLD 0x6f34 /* 0xc0046f34 */ X#define LINUX___NET_GET_IF_OLD 0x6f36 /* 0xc0046f36 */ X X#define LINUX_IOCTL_DVB_MIN LINUX_AUDIO_STOP X#define LINUX_IOCTL_DVB_MAX LINUX_CA_SET_PID X X#endif /* !_LINUX_DVB_IOCTL_H_ */ 0599fcbdb1e16725afdc6cae52772454 echo x - linux_dvbwrapper-kmod/files/linux_dvbwrapper.c sed 's/^X//' >linux_dvbwrapper-kmod/files/linux_dvbwrapper.c << '62000c07502c575e896a5f7ba0f4c3e5' X/*- X * Copyright (c) 2011 Juergen Lock X * All rights reserved. X * X * Redistribution and use in source and binary forms, with or without X * modification, are permitted provided that the following conditions X * are met: X * 1. Redistributions of source code must retain the above copyright X * notice, this list of conditions and the following disclaimer. X * 2. Redistributions in binary form must reproduce the above copyright X * notice, this list of conditions and the following disclaimer in the X * documentation and/or other materials provided with the distribution. X * X * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND X * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE X * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE X * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE X * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL X * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS X * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) X * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT X * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY X * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF X * SUCH DAMAGE. X */ X X#include X__FBSDID("$FreeBSD: $"); X X#include X#include X#include X#include X#include X#include X#include X#include X#include X#include X#include X X#include X#include X#include X#include X X#ifdef COMPAT_LINUX32 X#include X#include X#else X#include X#include X#endif X#include X#include X X#include "linux_dvb_ioctl.h" X#include "linux_dvb.h" X#include "linux_dvb_compat.h" X Xstatic linux_ioctl_function_t linux_ioctl_dvb; Xstatic struct linux_ioctl_handler dvb_handler = X{ linux_ioctl_dvb, LINUX_IOCTL_DVB_MIN, LINUX_IOCTL_DVB_MAX }; X XSYSINIT (dvbwrapper_register, SI_SUB_KLD, SI_ORDER_MIDDLE, X linux_ioctl_register_handler, &dvb_handler); XSYSUNINIT(dvbwrapper_unregister, SI_SUB_KLD, SI_ORDER_MIDDLE, X linux_ioctl_unregister_handler, &dvb_handler); X Xstatic MALLOC_DEFINE(M_LINUX_DVB, "linux_dvbwrapper", "Linux DVB wrapper"); X Xstatic int Xlinux_dvbwrapper_modevent(module_t mod, int cmd, void *data) X{ X return (0); X} X XDEV_MODULE(linux_dvbwrapper, linux_dvbwrapper_modevent, NULL); XMODULE_DEPEND(linux_dvbwrapper, linux, 1, 1, 1); X X#if ((__FreeBSD_version >= 900000) && (__FreeBSD_version < 900035)) || \ X (__FreeBSD_version < 802503) X/* X * Map some anonymous memory in user space of size sz, rounded up to the page X * boundary. X */ Xint Xcopyout_map(struct thread *td, vm_offset_t *addr, size_t sz) X{ X struct vmspace *vms; X int error; X vm_size_t size; X X vms = td->td_proc->p_vmspace; X X /* X * Map somewhere after heap in process memory. X */ X PROC_LOCK(td->td_proc); X *addr = round_page((vm_offset_t)vms->vm_daddr + X lim_max(td->td_proc, RLIMIT_DATA)); X PROC_UNLOCK(td->td_proc); X X /* round size up to page boundry */ X size = (vm_size_t)round_page(sz); X X error = vm_mmap(&vms->vm_map, addr, size, PROT_READ | PROT_WRITE, X VM_PROT_ALL, MAP_PRIVATE | MAP_ANON, OBJT_DEFAULT, NULL, 0); X X return (error); X} X X/* X * Unmap memory in user space. X */ Xint Xcopyout_unmap(struct thread *td, vm_offset_t addr, size_t sz) X{ X vm_map_t map; X vm_size_t size; X X if (sz == 0) X return (0); X X map = &td->td_proc->p_vmspace->vm_map; X size = (vm_size_t)round_page(sz); X X if (vm_map_remove(map, addr, addr + size) != KERN_SUCCESS) X return (EINVAL); X X return (0); X} X#endif X Xstatic int Xlinux_to_bsd_dtv_properties(struct l_dtv_properties *lvps, struct dtv_properties *vps) X{ X X vps->num = lvps->num; X vps->props = PTRIN(lvps->props); /* possible pointer size conversion */ X return (0); X} X Xstatic int Xlinux_to_bsd_dtv_property(struct l_dtv_property *lvp, struct dtv_property *vp) X{ X X /* X * Everything until u.buffer.reserved2 is fixed size so X * just memcpy it. X */ X memcpy(vp, lvp, offsetof(struct l_dtv_property, u.buffer.reserved2)); X /* X * The pointer may be garbage since it's part of a union, X * currently no Linux code uses it so just set it to NULL. X */ X vp->u.buffer.reserved2 = NULL; X vp->result = lvp->result; X return (0); X} X Xstatic int Xbsd_to_linux_dtv_property(struct dtv_property *vp, struct l_dtv_property *lvp) X{ X X /* X * Everything until u.buffer.reserved2 is fixed size so X * just memcpy it. X */ X memcpy(lvp, vp, offsetof(struct l_dtv_property, u.buffer.reserved2)); X /* X * The pointer may be garbage since it's part of a union, X * currently no Linux code uses it so just set it to NULL. X */ X lvp->u.buffer.reserved2 = PTROUT(NULL); X lvp->result = vp->result; X return (0); X} X Xstatic int Xlinux_ioctl_dvb(struct thread *td, struct linux_ioctl_args *args) X{ X struct file *fp; X int error, i; X struct l_dtv_properties l_vps; X struct dtv_properties vps; X struct l_dtv_property *l_vp, *l_p; X struct dtv_property *vp, *p; X size_t l_propsiz, propsiz; X vm_offset_t uvp; X X l_vp = NULL; X vp = NULL; X X switch (args->cmd & 0xffff) { X case LINUX_AUDIO_STOP: X case LINUX_AUDIO_PLAY: X case LINUX_AUDIO_PAUSE: X case LINUX_AUDIO_CONTINUE: X case LINUX_AUDIO_SELECT_SOURCE: X case LINUX_AUDIO_SET_MUTE: X case LINUX_AUDIO_SET_AV_SYNC: X case LINUX_AUDIO_SET_BYPASS_MODE: X case LINUX_AUDIO_CHANNEL_SELECT: X case LINUX_AUDIO_CLEAR_BUFFER: X case LINUX_AUDIO_SET_ID: X case LINUX_AUDIO_SET_STREAMTYPE: X case LINUX_AUDIO_SET_EXT_ID: X case LINUX_AUDIO_BILINGUAL_CHANNEL_SELECT: X case LINUX_DMX_START: X case LINUX_DMX_STOP: X case LINUX_DMX_SET_BUFFER_SIZE: X case LINUX_NET_REMOVE_IF: X case LINUX_FE_DISEQC_RESET_OVERLOAD: X case LINUX_FE_DISEQC_SEND_BURST: X case LINUX_FE_SET_TONE: X case LINUX_FE_SET_VOLTAGE: X case LINUX_FE_ENABLE_HIGH_LNB_VOLTAGE: X case LINUX_FE_DISHNETWORK_SEND_LEGACY_CMD: X case LINUX_FE_SET_FRONTEND_TUNE_MODE: X case LINUX_CA_RESET: X if ((args->cmd & IOC_DIRMASK) != LINUX_IOC_VOID) X return ENOIOCTL; X args->cmd = (args->cmd & 0xffff) | IOC_VOID; X break; X X case LINUX_DMX_REMOVE_PID: X /* overlaps with LINUX_NET_ADD_IF */ X if ((args->cmd & IOC_DIRMASK) == LINUX_IOC_INOUT) X goto net_add_if; X /* FALLTHRU */ X case LINUX_AUDIO_SET_MIXER: X case LINUX_AUDIO_SET_ATTRIBUTES: X case LINUX_AUDIO_SET_KARAOKE: X case LINUX_DMX_SET_FILTER: X case LINUX_DMX_SET_PES_FILTER: X case LINUX_DMX_SET_SOURCE: X case LINUX_DMX_ADD_PID: X case LINUX_FE_DISEQC_SEND_MASTER_CMD: X case LINUX_FE_SET_FRONTEND: X case LINUX_CA_SEND_MSG: X case LINUX_CA_SET_DESCR: X case LINUX_CA_SET_PID: X args->cmd = (args->cmd & ~IOC_DIRMASK) | IOC_IN; X break; X X case LINUX_AUDIO_GET_STATUS: X case LINUX_AUDIO_GET_CAPABILITIES: X case LINUX_AUDIO_GET_PTS: X case LINUX_DMX_GET_PES_PIDS: X case LINUX_DMX_GET_CAPS: X case LINUX_FE_GET_INFO: X case LINUX_FE_DISEQC_RECV_SLAVE_REPLY: X case LINUX_FE_READ_STATUS: X case LINUX_FE_READ_BER: X case LINUX_FE_READ_SIGNAL_STRENGTH: X case LINUX_FE_READ_SNR: X case LINUX_FE_READ_UNCORRECTED_BLOCKS: X case LINUX_FE_GET_FRONTEND: X case LINUX_FE_GET_EVENT: X case LINUX_CA_GET_CAP: X case LINUX_CA_GET_SLOT_INFO: X case LINUX_CA_GET_DESCR_INFO: X case LINUX_CA_GET_MSG: X args->cmd = (args->cmd & ~IOC_DIRMASK) | IOC_OUT; X break; X X case LINUX_DMX_GET_STC: X case LINUX_NET_GET_IF: X net_add_if: X args->cmd = (args->cmd & ~IOC_DIRMASK) | IOC_INOUT; X break; X X case LINUX_FE_SET_PROPERTY: X case LINUX_FE_GET_PROPERTY: X error = copyin((void *)args->arg, &l_vps, sizeof(l_vps)); X if (error) X return (error); X linux_to_bsd_dtv_properties(&l_vps, &vps); X if ((vps.num == 0) || vps.num > DTV_IOCTL_MAX_MSGS) X return EINVAL; X X l_propsiz = vps.num * sizeof(*l_vp); X propsiz = vps.num * sizeof(*vp); X l_vp = malloc(l_propsiz, M_LINUX_DVB, M_WAITOK); X vp = malloc(propsiz, M_LINUX_DVB, M_WAITOK); X error = copyin((void *)vps.props, l_vp, l_propsiz); X if (error) X goto out2; X for (i = vps.num, l_p = l_vp, p = vp; i--; ++l_p, ++p) X linux_to_bsd_dtv_property(l_p, p); X X error = copyout_map(td, &uvp, propsiz); X if (error) X goto out2; X copyout(vp, (void *)uvp, propsiz); X X if ((error = fget(td, args->fd, &fp)) != 0) { X (void)copyout_unmap(td, uvp, propsiz); X goto out2; X } X vps.props = (void *)uvp; X if ((args->cmd & 0xffff) == LINUX_FE_SET_PROPERTY) X error = fo_ioctl(fp, FE_SET_PROPERTY, &vps, td->td_ucred, td); X else X error = fo_ioctl(fp, FE_GET_PROPERTY, &vps, td->td_ucred, td); X if (error) { X (void)copyout_unmap(td, uvp, propsiz); X goto out; X } X error = copyin((void *)uvp, vp, propsiz); X (void)copyout_unmap(td, uvp, propsiz); X if (error) X goto out; X for (i = vps.num, l_p = l_vp, p = vp; i--; ++l_p, ++p) X bsd_to_linux_dtv_property(p, l_p); X linux_to_bsd_dtv_properties(&l_vps, &vps); X copyout(l_vp, (void *)vps.props, l_propsiz); X X out: X fdrop(fp, td); X out2: X if (l_vp) X free(l_vp, M_LINUX_DVB); X if (vp) X free(vp, M_LINUX_DVB); X return (error); X X default: return (ENOIOCTL); X } X X error = ioctl(td, (struct ioctl_args *)args); X return (error); X} 62000c07502c575e896a5f7ba0f4c3e5 exit From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 22 02:01:26 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9BA5106566C for ; Fri, 22 Apr 2011 02:01:26 +0000 (UTC) (envelope-from ctuffli@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id B2BED8FC0C for ; Fri, 22 Apr 2011 02:01:26 +0000 (UTC) Received: by pzk27 with SMTP id 27so188810pzk.13 for ; Thu, 21 Apr 2011 19:01:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=X5KcfGDUIbPVwLZkaj0SwBN53Ps0lmO3a1I5Jy0IYvI=; b=brxanN9OWpHHmS6Se8SBUBcEpDKDQ6IIoDZ8lBXiPltFR51ISFJY/6K77QzPziJ75k ToTIrx4JyZ8ZpCasTDYZZabO5i2ZCuBH+Lri08DmgpFfbvYL3MLeRPeMuctVX3/kwYkd bYMoHOWGfTrLbd2KKvQjo/yVOTsuo6DKrj74o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=UZujLir12tcMV1Vh4Q5e4JbCWiem2kxEtWFMMZOxjljqWLdvPrYSdtbRnuWWrykJB1 l2SQXrRLBLnlITR7IuYtLoP5Y7XZJBNi/sssFZB7htdfBElNI0A1VvMhE3Tyjo3FUtAW yQWUYLQce1VV3So11ghPJtf5rTzpyCb08WLDE= MIME-Version: 1.0 Received: by 10.68.27.33 with SMTP id q1mr883646pbg.21.1303436244669; Thu, 21 Apr 2011 18:37:24 -0700 (PDT) Received: by 10.68.49.72 with HTTP; Thu, 21 Apr 2011 18:37:24 -0700 (PDT) Date: Thu, 21 Apr 2011 18:37:24 -0700 Message-ID: From: Chuck Tuffli To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: no KLD symbols in dtrace? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 02:01:26 -0000 (Note I'm new to DTrace, so this may be ignorance on my part) I have re-built a stock 8.2 kernel and enabled dtrace as per the handbook (including WITH_CTF=1) and have built a kld also using WITH_CTF=1. When I run the following dtrace -n"bus_release_resource:entry { stack(); }" the output looks like ... 0 33759 bus_release_resource:entry 0xffffffff813db04e 0xffffffff813db091 kernel`device_detach+0x84 kernel`driver_module_handler+0x37c kernel`module_unload+0x49 kernel`linker_file_unload+0x178 kernel`kern_kldunload+0x117 kernel`syscallenter+0x23d kernel`syscall+0x4b kernel`0xffffffff808c5572 where the 0xffffffff813dbXXX addresses correspond to my kld. But I was expecting to see symbolic names instead of addresses. Is there something else I need to do to add the kld's symbols to the system? TIA. ---chuck From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 22 02:42:18 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0466106564A for ; Fri, 22 Apr 2011 02:42:17 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 93CB78FC13 for ; Fri, 22 Apr 2011 02:42:17 +0000 (UTC) Received: by qwc9 with SMTP id 9so165902qwc.13 for ; Thu, 21 Apr 2011 19:42:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:date:from:to:cc:subject:message-id:in-reply-to :references:x-mailer:mime-version:content-type; bh=ADCqJQx07bw5MGNJ7T4jIs44nds+FJuFiiN6pe8BLxc=; b=TXFlCtA06L4xpbX//itkV/b0CUiX5eRj+3U2QFGAlFNO/NM8Ae8yNUKx/A5HMhi24O CXtv/UqUzw3M2iUPT633a6lXqvghIlaQv9Jm7T+HtHSCQ9c+ujpZxbyI1cwJyAEYkBn3 fhO8T4RYlNpjFQAGqScXuZUdO/dn5WxliTATc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=aRb7h+eH8sHPBbK7c+ZkmSAMjbFxfjVIFLqQxR5xgxK3t7g1+yKciwACgceFlybKnN Ez/Ecx8bBNG5wbhQfab/+WmeskV2QP/mBr1BFoSdYFJbq+JuIg2bFczVcPsqguU0EenG 6Z7wwfg0vQsfceP9V4SLiaZ2ic/e32b8fiww0= Received: by 10.229.48.70 with SMTP id q6mr464735qcf.224.1303438579900; Thu, 21 Apr 2011 19:16:19 -0700 (PDT) Received: from kan.dnsalias.net (c-24-63-226-98.hsd1.ma.comcast.net [24.63.226.98]) by mx.google.com with ESMTPS id c27sm1755296qck.10.2011.04.21.19.16.16 (version=SSLv3 cipher=OTHER); Thu, 21 Apr 2011 19:16:17 -0700 (PDT) Date: Thu, 21 Apr 2011 22:16:11 -0400 From: Alexander Kabaev To: Chuck Tuffli Message-ID: <20110421221611.7f52ca98@kan.dnsalias.net> In-Reply-To: References: X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/QuMx3YPjunOVi3IK3zHpAvQ"; protocol="application/pgp-signature" Cc: freebsd-hackers@freebsd.org Subject: Re: no KLD symbols in dtrace? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 02:42:18 -0000 --Sig_/QuMx3YPjunOVi3IK3zHpAvQ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Thu, 21 Apr 2011 18:37:24 -0700 Chuck Tuffli wrote: > (Note I'm new to DTrace, so this may be ignorance on my part) >=20 > I have re-built a stock 8.2 kernel and enabled dtrace as per the > handbook (including WITH_CTF=3D1) and have built a kld also using > WITH_CTF=3D1. When I run the following >=20 > dtrace -n"bus_release_resource:entry { stack(); }" >=20 > the output looks like > ... > 0 33759 bus_release_resource:entry > 0xffffffff813db04e > 0xffffffff813db091 > kernel`device_detach+0x84 > kernel`driver_module_handler+0x37c > kernel`module_unload+0x49 > kernel`linker_file_unload+0x178 > kernel`kern_kldunload+0x117 > kernel`syscallenter+0x23d > kernel`syscall+0x4b > kernel`0xffffffff808c5572 >=20 > where the 0xffffffff813dbXXX addresses correspond to my kld. But I was > expecting to see symbolic names instead of addresses. Is there > something else I need to do to add the kld's symbols to the system? > TIA. >=20 There is an omission on our .mk files which prevents CTF info to be generated for kld modules, regardless of WITH_CTF flag. I had discovered this at work just recently and have been using the following patch for the time being: http://people.freebsd.org/~kan/kmod-dtrace.diff If you can confirm it works for you too, I'll get it committed. =20 Thanks, --=20 Alexander Kabaev --Sig_/QuMx3YPjunOVi3IK3zHpAvQ Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iD8DBQFNsOTwQ6z1jMm+XZYRAn7HAJ9jFl2fVg2PeEVNhFlwKc6CiWrilwCfX/x8 Ymf4nnVZXY3/k3ZpVsbue+A= =J6jf -----END PGP SIGNATURE----- --Sig_/QuMx3YPjunOVi3IK3zHpAvQ-- From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 22 14:27:32 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B17B4106564A for ; Fri, 22 Apr 2011 14:27:32 +0000 (UTC) (envelope-from ctuffli@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8951E8FC19 for ; Fri, 22 Apr 2011 14:27:32 +0000 (UTC) Received: by pzk27 with SMTP id 27so432618pzk.13 for ; Fri, 22 Apr 2011 07:27:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=WMNbOrNQm7dCspjnp2HRZ1MRXn3qL5u23U1SNuyC0c0=; b=M82EhJ3MXR3VObfu+RtEOtDoR87IyWw0iqipoYdMgL+DG+lMGqBcy/BcIfrt9x44wQ MTc7dH4yBfxkERLtC6+iz3jay/hBLrQ6m+6oLIo2yLvSa1biKMMXDQSclRPCLZE/Ip1E 9v/5jA2NGwtijFSpSeBoP5kc1YZrdPRogcbRY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=bmrSsvb5tsysJpzybKbZ/WFeMImGobUFnv9cviHlxMxFcLJ2CRoxEEmSC7s7kgO3DO kt8EwwJzP8psp8fa1jCE5XIRsTV6Monae46wFLCTTIqXPqrVM1Z3x+VIlK8QxyJDXVZt jbBC20oTBJ0gER1nUfuSfGFGaOuPHkR4rRF9Q= MIME-Version: 1.0 Received: by 10.68.20.129 with SMTP id n1mr1814854pbe.155.1303482451931; Fri, 22 Apr 2011 07:27:31 -0700 (PDT) Received: by 10.68.49.72 with HTTP; Fri, 22 Apr 2011 07:27:30 -0700 (PDT) In-Reply-To: <20110421221611.7f52ca98@kan.dnsalias.net> References: <20110421221611.7f52ca98@kan.dnsalias.net> Date: Fri, 22 Apr 2011 07:27:30 -0700 Message-ID: From: Chuck Tuffli To: Alexander Kabaev Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: no KLD symbols in dtrace? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 14:27:32 -0000 On Thu, Apr 21, 2011 at 7:16 PM, Alexander Kabaev wrote: ... > There is an omission on our .mk files which prevents CTF info to be > generated for kld modules, regardless of WITH_CTF flag. I had > discovered this at work just recently and have been using the > following patch for the time being: > > http://people.freebsd.org/~kan/kmod-dtrace.diff > > If you can confirm it works for you too, I'll get it committed. I patched /usr/src/sys/conf/kmod.mk and rebuilt my kld. It looks like ctfmerge is called at the end of the build, but dtrace still shows just the address. Maybe I missed a step? ---chuck From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 22 14:55:18 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id EF2351065676; Fri, 22 Apr 2011 14:55:18 +0000 (UTC) Date: Fri, 22 Apr 2011 14:55:18 +0000 From: Alexander Best To: Devin Teske Message-ID: <20110422145518.GA16734@freebsd.org> References: <02a701cc006a$887da210$9978e630$@vicor.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <02a701cc006a$887da210$9978e630$@vicor.com> Cc: freebsd-hackers@freebsd.org, freebsd-questions@freebsd.org, "Teske, Devin" Subject: Re: [UPDATE] host-setup(1): a dialog(1)-based utility for configuring FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 14:55:19 -0000 On Thu Apr 21 11, Devin Teske wrote: > Hi List Members! > > > > I'm proud to announce the first update to my host-setup utility (a > dialog(1)-based host configurator for FreeBSD). The following changes have been > made: > > > > - fixed bug where /etc/resolv.conf would be created with 0600 permissions > > - fixed bug when switching from one default gateway to NO default gateway > > - fixed typo in the title of netmask prompt and ifconfig options dialog > > - fixed bug that prevented entry of netmask if no netmask is configured > > > > You can get the updated version here: > > > > http://druidbsd.sourceforge.net/download/host-setup.txt otaku% sudo ./host-setup.txt User cancelled. otaku% echo $? 1 otaku% > > or > > http://druidbsd.sourceforge.net/download/host-setup.gz > > or > > http://druidbsd.sourceforge.net/ > > > > > > For those not familiar with my host-setup(1) utility, it is a 2,500+ line shell > script that utilizes the dialog(1) utility to walk the system administrator > through setting up their TimeZone, Hostname, Network Interfaces, Default > Gateway, and DNS. Our custom FreeBSD installer sets this script as the root > login shell, making it very easy for field engineers to quickly get a system on > the network without having to use the command-line (and without having to reboot > either). Underneath the hood - behind the system of prompts and dialogs - this > script manages both the contents of /etc/rc.conf, /etc/resolv.conf, and others > as well as utilizing ifconfig(8), route(8), and many other tools to avoid > requiring a reboot, prompting you if you would like to make the new changes > effective when values are changed from their active settings. > > > > Here's the patch to show the details: > > > > --- host-setup.3_0 2011-02-10 19:14:30.000000000 -0800 > > +++ host-setup 2011-04-21 13:38:58.000000000 -0700 > > @@ -2,12 +2,12 @@ > > # -*- tab-width: 4 -*- ;; Emacs > > # vi: set tabstop=4 :: Vi/ViM > > # > > -# Revision: 3.0 > > +# Revision: 3.1 > > # Created: September 21st, 2010 > > -# Last Modified: December 6th, 2010 > > +# Last Modified: April 21st, 2011 > > ############################################################ COPYRIGHT > > # > > -# Devin Teske (c)2006-2010. All Rights Reserved. > > +# Devin Teske (c)2006-2011. All Rights Reserved. > > # > > # Redistribution and use in source and binary forms, with or without > > # modification, are permitted provided that the following conditions > > @@ -1353,8 +1353,10 @@ dialog_input_hostname() > > # permissions and ownership to match resolv.conf(5) before > > # we write it out and mv(1) it into place). > > # > > - quietly chmod "$( stat -f '%#Lp' "$RESOLV_CONF" )" "$tmpfile" > > - quietly chown "$( stat -f '%u:%g' "$RESOLV_CONF" )" "$tmpfile" > > + local mode="$( stat -f '%#Lp' "$RESOLV_CONF" 2> /dev/null )" > > + local owner="$( stat -f '%u:%g' "$RESOLV_CONF" 2> /dev/null )" > > + quietly chmod "${mode:-0644}" "$tmpfile" > > + quietly chown "${owner:-root:wheel}" "$tmpfile" > > # > > # Operate on resolv.conf(5), replacing only the last > > @@ -1646,7 +1648,7 @@ dialog_input_netmask() > > # > > while :; do > > - dialog --title "$brand${band:+}${progname:-$0}" \ > > + dialog --title "$brand${brand:+ }${progname:-$0}" \ > > --hline "Use numbers, punctuation, TAB or ENTER" \ > > --inputbox "$msg" 10 50 \ > > "$_netmask" \ > > @@ -1664,7 +1666,7 @@ dialog_input_netmask() > > [ $retval -eq $SUCCESS ] || return $retval > > # Return success if NULL value was entered > > - [ "$_netmask" ] || return $SUCCESS > > + [ "$_input" ] || return $SUCCESS > > # Take only the first "word" of the user's input > > _netmask="$_input" > > @@ -1705,7 +1707,7 @@ dialog_input_options() > > msg="Please enter additional network media options to be" > > msg="$msg passed to ifconfig(8) for the $interface interface:" > > - dialog --title "$brand${band:+}${progname:-$0}" \ > > + dialog --title "$brand${brand:+ }${progname:-$0}" \ > > --hline "Use numbers, punctuation, TAB or ENTER" \ > > --inputbox "$msg" 9 70 \ > > "$options" \ > > @@ -2183,9 +2185,12 @@ dialog_menu_netdev_edit() > > local dr="$( sysrc_get defaultrouter )" err > > err=$( ifconfig $interface inet $ipaddr \ > > netmask $netmask $options 2>&1 ) > > - if [ $? -eq $SUCCESS -a "$dr" ]; then > > - err=$( route add default "$dr" 2>&1 ) > > - [ $? -eq $SUCCESS ] || dialog_msgbox "$err" > > + if [ $? -eq $SUCCESS ]; then > > + if [ "$dr" -a "$dr" != "NO" ]; then > > + err=$( route add default "$dr" 2>&1 ) > > + [ $? -eq $SUCCESS ] || \ > > + dialog_msgbox "$err" > > + fi > > else > > dialog_msgbox "$err" > > fi > > @@ -2524,7 +2529,7 @@ exit $SUCCESS > > # > > # $Header$ > > # > > -# $Copyright: 2006-2010. Devin Teske. All Rights Reserved. $ > > +# $Copyright: 2006-2011. Devin Teske. All Rights Reserved. $ > > # > > # $Log$ > > # > > > > > > > > -- > > Cheers, > > Devin Teske > > > > -> FUN STUFF <- > > -----BEGIN GEEK CODE BLOCK----- > > Version 3.12 > > GAT/CS/B/CC/E/IT/MC/M/MU/P/S/TW d+(++) s: a- C+++@$ UB++++$ P++++@$ L++++$ E- > > W+++ N? o? K? w@ O M++$ V- PS+>++ PE@ Y+ PGP-> t(+) 5? X(+) R(-) tv+ b+>++ DI+ > > D+(++) G++ e>++++ h r+++ z+++ > > ------END GEEK CODE BLOCK------ > > Learn about the "Geek Code": http://www.geekcode.com/ > > > > -> LEGAL DISCLAIMER <- > > This message contains confidential and proprietary information > > of the sender, and is intended only for the person(s) to whom it > > is addressed. Any use, distribution, copying or disclosure by any > > other person is strictly prohibited. If you have received this > > message in error, please notify the e-mail sender immediately, > > and delete the original message without making a copy. > > > > -> END TRANSMISSION <- > > _____________ > > The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. > _____________ -- a13x From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 22 15:13:25 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67D33106564A; Fri, 22 Apr 2011 15:13:25 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 2C3688FC1B; Fri, 22 Apr 2011 15:13:24 +0000 (UTC) Received: from sbhfislrext01.fnfis.com ([192.168.249.167]) by SCSFISLTC02 (8.14.3/8.14.3) with ESMTP id p3MFDO2g012693; Fri, 22 Apr 2011 10:13:24 -0500 Received: from sbhfisltcgw02.FNFIS.COM (Not Verified[10.132.248.122]) by sbhfislrext01.fnfis.com with MailMarshal (v6, 5, 4, 7535) id ; Fri, 22 Apr 2011 10:13:19 -0500 Received: from sbhfisltcgw02.FNFIS.COM ([10.132.248.122]) by sbhfisltcgw02.FNFIS.COM with Microsoft SMTPSVC(6.0.3790.4675); Fri, 22 Apr 2011 10:13:24 -0500 Received: from lummox ([10.132.254.135]) by sbhfisltcgw02.FNFIS.COM over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 22 Apr 2011 10:13:23 -0500 From: "Devin Teske" To: "'Alexander Best'" References: <02a701cc006a$887da210$9978e630$@vicor.com> <20110422145518.GA16734@freebsd.org> Date: Fri, 22 Apr 2011 08:13:20 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20110422145518.GA16734@freebsd.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Thread-Index: AcwA/WSEabu3wT3nS3yAMKilSzM3wQAALtVw X-OriginalArrivalTime: 22 Apr 2011 15:13:24.0002 (UTC) FILETIME=[D2CA1020:01CC00FF] Cc: freebsd-hackers@freebsd.org, freebsd-questions@freebsd.org, "'Teske, Devin'" Subject: RE: [UPDATE] host-setup(1): a dialog(1)-based utility for configuring FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 15:13:25 -0000 > -----Original Message----- > From: Alexander Best [mailto:arundel@freebsd.org] > Sent: Friday, April 22, 2011 7:55 AM > To: Devin Teske > Cc: freebsd-hackers@freebsd.org; freebsd-questions@freebsd.org; Teske, > Devin > Subject: Re: [UPDATE] host-setup(1): a dialog(1)-based utility for > configuring FreeBSD > > On Thu Apr 21 11, Devin Teske wrote: > > Hi List Members! > > > > > > > > I'm proud to announce the first update to my host-setup utility (a > > dialog(1)-based host configurator for FreeBSD). The following changes > have been > > made: > > > > > > > > - fixed bug where /etc/resolv.conf would be created with 0600 > permissions > > > > - fixed bug when switching from one default gateway to NO default > gateway > > > > - fixed typo in the title of netmask prompt and ifconfig options dialog > > > > - fixed bug that prevented entry of netmask if no netmask is configured > > > > > > > > You can get the updated version here: > > > > > > > > http://druidbsd.sourceforge.net/download/host-setup.txt > > otaku% sudo ./host-setup.txt > User cancelled. > otaku% echo $? > 1 > otaku% Can you provide me with the output of "uname -spr"? It's working fine for me on FreeBSD 8.1-RELEASE i386. Where you're bombing out is line 2403: [ $retval -eq 0 ] || die "User cancelled." Functionally, that is testing the return status of dialog(1) for the initial menu. See if you can execute this (a rough approximation of the initial menu): dialog --clear --title foo --hline bar --menu abc 17 55 9 1 a 2 b 3 c 4 d 5 e X x 2> /tmp/dialog.menu.foo A menu should appear. Select an item and then execute for me: echo $? If the above doesn't work, then I suspect that your dialog(1) is not working properly. I'd then go and try this as a sanity check: cd /usr/share/examples/dialog sh menubox echo $? The result in both cases (as long as you actually select a menu item) should be "0". Also... (just as a sanity check for me) your /bin/sh is not a symlink to bash is it? -- Devin > > > > > or > > > > http://druidbsd.sourceforge.net/download/host-setup.gz > > > > or > > > > http://druidbsd.sourceforge.net/ > > > > > > > > > > > > For those not familiar with my host-setup(1) utility, it is a 2,500+ > line shell > > script that utilizes the dialog(1) utility to walk the system > administrator > > through setting up their TimeZone, Hostname, Network Interfaces, Default > > Gateway, and DNS. Our custom FreeBSD installer sets this script as the > root > > login shell, making it very easy for field engineers to quickly get a > system on > > the network without having to use the command-line (and without having > to reboot > > either). Underneath the hood - behind the system of prompts and dialogs > - this > > script manages both the contents of /etc/rc.conf, /etc/resolv.conf, and > others > > as well as utilizing ifconfig(8), route(8), and many other tools to > avoid > > requiring a reboot, prompting you if you would like to make the new > changes > > effective when values are changed from their active settings. > > > > > > > > Here's the patch to show the details: > > > > > > > > --- host-setup.3_0 2011-02-10 19:14:30.000000000 -0800 > > > > +++ host-setup 2011-04-21 13:38:58.000000000 -0700 > > > > @@ -2,12 +2,12 @@ > > > > # -*- tab-width: 4 -*- ;; Emacs > > > > # vi: set tabstop=4 :: Vi/ViM > > > > # > > > > -# Revision: 3.0 > > > > +# Revision: 3.1 > > > > # Created: September 21st, 2010 > > > > -# Last Modified: December 6th, 2010 > > > > +# Last Modified: April 21st, 2011 > > > > ############################################################ COPYRIGHT > > > > # > > > > -# Devin Teske (c)2006-2010. All Rights Reserved. > > > > +# Devin Teske (c)2006-2011. All Rights Reserved. > > > > # > > > > # Redistribution and use in source and binary forms, with or without > > > > # modification, are permitted provided that the following conditions > > > > @@ -1353,8 +1353,10 @@ dialog_input_hostname() > > > > # permissions and ownership to match resolv.conf(5) before > > > > # we write it out and mv(1) it into place). > > > > # > > > > - quietly chmod "$( stat -f '%#Lp' "$RESOLV_CONF" )" > "$tmpfile" > > > > - quietly chown "$( stat -f '%u:%g' "$RESOLV_CONF" )" > "$tmpfile" > > > > + local mode="$( stat -f '%#Lp' "$RESOLV_CONF" 2> /dev/null )" > > > > + local owner="$( stat -f '%u:%g' "$RESOLV_CONF" 2> /dev/null > )" > > > > + quietly chmod "${mode:-0644}" "$tmpfile" > > > > + quietly chown "${owner:-root:wheel}" "$tmpfile" > > > > # > > > > # Operate on resolv.conf(5), replacing only the last > > > > @@ -1646,7 +1648,7 @@ dialog_input_netmask() > > > > # > > > > while :; do > > > > - dialog --title "$brand${band:+}${progname:-$0}" \ > > > > + dialog --title "$brand${brand:+ }${progname:-$0}" \ > > > > --hline "Use numbers, punctuation, TAB or ENTER" \ > > > > --inputbox "$msg" 10 50 \ > > > > "$_netmask" \ > > > > @@ -1664,7 +1666,7 @@ dialog_input_netmask() > > > > [ $retval -eq $SUCCESS ] || return $retval > > > > # Return success if NULL value was entered > > > > - [ "$_netmask" ] || return $SUCCESS > > > > + [ "$_input" ] || return $SUCCESS > > > > # Take only the first "word" of the user's input > > > > _netmask="$_input" > > > > @@ -1705,7 +1707,7 @@ dialog_input_options() > > > > msg="Please enter additional network media options to be" > > > > msg="$msg passed to ifconfig(8) for the $interface interface:" > > > > - dialog --title "$brand${band:+}${progname:-$0}" \ > > > > + dialog --title "$brand${brand:+ }${progname:-$0}" \ > > > > --hline "Use numbers, punctuation, TAB or ENTER" \ > > > > --inputbox "$msg" 9 70 \ > > > > "$options" \ > > > > @@ -2183,9 +2185,12 @@ dialog_menu_netdev_edit() > > > > local dr="$( sysrc_get defaultrouter )" err > > > > err=$( ifconfig $interface inet $ipaddr \ > > > > netmask $netmask $options 2>&1 ) > > > > - if [ $? -eq $SUCCESS -a "$dr" ]; then > > > > - err=$( route add default "$dr" 2>&1 ) > > > > - [ $? -eq $SUCCESS ] || dialog_msgbox "$err" > > > > + if [ $? -eq $SUCCESS ]; then > > > > + if [ "$dr" -a "$dr" != "NO" ]; then > > > > + err=$( route add default "$dr" 2>&1 ) > > > > + [ $? -eq $SUCCESS ] || \ > > > > + dialog_msgbox "$err" > > > > + fi > > > > else > > > > dialog_msgbox "$err" > > > > fi > > > > @@ -2524,7 +2529,7 @@ exit $SUCCESS > > > > # > > > > # $Header$ > > > > # > > > > -# $Copyright: 2006-2010. Devin Teske. All Rights Reserved. $ > > > > +# $Copyright: 2006-2011. Devin Teske. All Rights Reserved. $ > > > > # > > > > # $Log$ > > > > # > > > > > > > > > > > > > > > > -- > > > > Cheers, > > > > Devin Teske > > > > > > > > -> FUN STUFF <- > > > > -----BEGIN GEEK CODE BLOCK----- > > > > Version 3.12 > > > > GAT/CS/B/CC/E/IT/MC/M/MU/P/S/TW d+(++) s: a- C+++@$ UB++++$ P++++@$ > L++++$ E- > > > > W+++ N? o? K? w@ O M++$ V- PS+>++ PE@ Y+ PGP-> t(+) 5? X(+) R(-) tv+ > b+>++ DI+ > > > > D+(++) G++ e>++++ h r+++ z+++ > > > > ------END GEEK CODE BLOCK------ > > > > Learn about the "Geek Code": http://www.geekcode.com/ > > > > > > > > -> LEGAL DISCLAIMER <- > > > > This message contains confidential and proprietary information > > > > of the sender, and is intended only for the person(s) to whom it > > > > is addressed. Any use, distribution, copying or disclosure by any > > > > other person is strictly prohibited. If you have received this > > > > message in error, please notify the e-mail sender immediately, > > > > and delete the original message without making a copy. > > > > > > > > -> END TRANSMISSION <- > > > > _____________ > > > > The information contained in this message is proprietary and/or > confidential. If you are not the intended recipient, please: (i) delete > the message and all copies; (ii) do not disclose, distribute or use the > message in any manner; and (iii) notify the sender immediately. In > addition, please be aware that any message addressed to our domain is > subject to archiving and review by persons other than the intended > recipient. Thank you. > > _____________ > > -- > a13x _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. _____________ From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 22 15:25:04 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C663A106568B for ; Fri, 22 Apr 2011 15:25:04 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 658268FC18 for ; Fri, 22 Apr 2011 15:25:04 +0000 (UTC) Received: by qwc9 with SMTP id 9so392424qwc.13 for ; Fri, 22 Apr 2011 08:25:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:date:from:to:cc:subject:message-id:in-reply-to :references:x-mailer:mime-version:content-type; bh=rCtV7BMVD4m8ehjWnadKn85j5sM2q2eRPjkzVO+GTY8=; b=qEmcglnm2MRq2OAvvz+hb3rNwSDURIk1J/gAF0OXgbYMU8Q4pnvoIsM+RPjMCQ9kT+ aimO2Q6cj3tV+a//KEVzWQlo+hw5Xc5gtTF0CClVm3AAnwUAwyAiGrUoFAE6y+BLYcR0 R4tYzosiJk/JAaINsG/h6P7+gMHxIgP+IW1Y0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=XQHGShywWdfTaVoYwMqt6OCy4iORL5KAt/1s9AiiM8asGxG8qdAybojouKtj6z1ygp ndmYTv8xQL/Awvfuec0a6nVw/RPaOOiOK9YuUe52tZhhuY6D6qFh2NSlsrlgy7fozivz lzRJJbeMjFMrO2W6mfj+S/tQfflrLUykWkTdo= Received: by 10.224.184.11 with SMTP id ci11mr859199qab.195.1303485903452; Fri, 22 Apr 2011 08:25:03 -0700 (PDT) Received: from kan.dnsalias.net (c-24-63-226-98.hsd1.ma.comcast.net [24.63.226.98]) by mx.google.com with ESMTPS id s9sm2122268qco.12.2011.04.22.08.25.01 (version=SSLv3 cipher=OTHER); Fri, 22 Apr 2011 08:25:02 -0700 (PDT) Date: Fri, 22 Apr 2011 11:24:44 -0400 From: Alexander Kabaev To: Chuck Tuffli Message-ID: <20110422112444.0e423a80@kan.dnsalias.net> In-Reply-To: References: <20110421221611.7f52ca98@kan.dnsalias.net> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/qKUQ40h8DyiC_6Wwb6Rh52b"; protocol="application/pgp-signature" Cc: freebsd-hackers@freebsd.org Subject: Re: no KLD symbols in dtrace? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 15:25:04 -0000 --Sig_/qKUQ40h8DyiC_6Wwb6Rh52b Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Fri, 22 Apr 2011 07:27:30 -0700 Chuck Tuffli wrote: > On Thu, Apr 21, 2011 at 7:16 PM, Alexander Kabaev > wrote: ... > > There is an omission on our .mk files which prevents CTF info to be > > generated for kld modules, regardless of WITH_CTF flag. I had > > discovered this at work just recently and have been using the > > following patch for the time being: > > > > http://people.freebsd.org/~kan/kmod-dtrace.diff > > > > If you can confirm it works for you too, I'll get it committed. >=20 > I patched /usr/src/sys/conf/kmod.mk and rebuilt my kld. It looks like > ctfmerge is called at the end of the build, but dtrace still shows > just the address. Maybe I missed a step? >=20 > ---chuck Do ctfdump -tf on your kld and verify that what it outputs actually makes sense. Do kldload and see if fbt provider knows about your module and functions. There is nothing else special that I can think off. Maybe make sure that you compile your sources with -g in the first place? DWARF debug info is what CTF generation utils use to figure out types and function prototypes. --=20 Alexander Kabaev --Sig_/qKUQ40h8DyiC_6Wwb6Rh52b Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iD8DBQFNsZ3MQ6z1jMm+XZYRAnWgAJ9j2/z6U7Dzk9h/38aizse20ENu5QCZAQrT LH3Fgzgret4Y1wH6E2bpURA= =S9C0 -----END PGP SIGNATURE----- --Sig_/qKUQ40h8DyiC_6Wwb6Rh52b-- From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 22 15:41:47 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 0109D1065673; Fri, 22 Apr 2011 15:41:47 +0000 (UTC) Date: Fri, 22 Apr 2011 15:41:46 +0000 From: Alexander Best To: Devin Teske Message-ID: <20110422154146.GA26083@freebsd.org> References: <02a701cc006a$887da210$9978e630$@vicor.com> <20110422145518.GA16734@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: freebsd-hackers@freebsd.org, freebsd-questions@freebsd.org, "'Teske, Devin'" Subject: Re: [UPDATE] host-setup(1): a dialog(1)-based utility for configuring FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 15:41:47 -0000 On Fri Apr 22 11, Devin Teske wrote: > > > > -----Original Message----- > > From: Alexander Best [mailto:arundel@freebsd.org] > > Sent: Friday, April 22, 2011 7:55 AM > > To: Devin Teske > > Cc: freebsd-hackers@freebsd.org; freebsd-questions@freebsd.org; Teske, > > Devin > > Subject: Re: [UPDATE] host-setup(1): a dialog(1)-based utility for > > configuring FreeBSD > > > > On Thu Apr 21 11, Devin Teske wrote: > > > Hi List Members! > > > > > > > > > > > > I'm proud to announce the first update to my host-setup utility (a > > > dialog(1)-based host configurator for FreeBSD). The following changes > > have been > > > made: > > > > > > > > > > > > - fixed bug where /etc/resolv.conf would be created with 0600 > > permissions > > > > > > - fixed bug when switching from one default gateway to NO default > > gateway > > > > > > - fixed typo in the title of netmask prompt and ifconfig options dialog > > > > > > - fixed bug that prevented entry of netmask if no netmask is configured > > > > > > > > > > > > You can get the updated version here: > > > > > > > > > > > > http://druidbsd.sourceforge.net/download/host-setup.txt > > > > otaku% sudo ./host-setup.txt > > User cancelled. > > otaku% echo $? > > 1 > > otaku% > > Can you provide me with the output of "uname -spr"? FreeBSD 9.0-CURRENT amd64 > > It's working fine for me on FreeBSD 8.1-RELEASE i386. > > Where you're bombing out is line 2403: > [ $retval -eq 0 ] || die "User cancelled." > > Functionally, that is testing the return status of dialog(1) for the initial > menu. See if you can execute this (a rough approximation of the initial > menu): > > dialog --clear --title foo --hline bar --menu abc 17 55 9 1 a 2 b 3 c 4 d 5 > e X x 2> /tmp/dialog.menu.foo doesn't work. :( otaku% echo $? 255 otaku% cat /tmp/dialog.menu.foo Error: Unknown option --hline. Use --help to list options. otaku% taku% whereis dialog dialog: /usr/bin/dialog /usr/share/man/en.ISO8859-15/man1/dialog.1.gz /usr/src/gnu/usr.bin/dialog otaku% /usr/bin/dialog cdialog (ComeOn Dialog!) version 1.1-20100428 Copyright 2000-2007,2008 Thomas E. Dickey This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. [...] > > A menu should appear. Select an item and then execute for me: > > echo $? > > If the above doesn't work, then I suspect that your dialog(1) is not working > properly. I'd then go and try this as a sanity check: > > cd /usr/share/examples/dialog otaku% cd /usr/share/examples/dialog cd: no such file or directory: /usr/share/examples/dialog > sh menubox > echo $? > > The result in both cases (as long as you actually select a menu item) should > be "0". > > Also... (just as a sanity check for me) your /bin/sh is not a symlink to > bash is it? otaku% file /bin/sh /bin/sh: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically linked (uses shared libs), for FreeBSD 9.0 (900034), stripped > -- > Devin > > > > > > > > > > or > > > > > > http://druidbsd.sourceforge.net/download/host-setup.gz > > > > > > or > > > > > > http://druidbsd.sourceforge.net/ > > > > > > > > > > > > > > > > > > For those not familiar with my host-setup(1) utility, it is a 2,500+ > > line shell > > > script that utilizes the dialog(1) utility to walk the system > > administrator > > > through setting up their TimeZone, Hostname, Network Interfaces, Default > > > Gateway, and DNS. Our custom FreeBSD installer sets this script as the > > root > > > login shell, making it very easy for field engineers to quickly get a > > system on > > > the network without having to use the command-line (and without having > > to reboot > > > either). Underneath the hood - behind the system of prompts and dialogs > > - this > > > script manages both the contents of /etc/rc.conf, /etc/resolv.conf, and > > others > > > as well as utilizing ifconfig(8), route(8), and many other tools to > > avoid > > > requiring a reboot, prompting you if you would like to make the new > > changes > > > effective when values are changed from their active settings. > > > > > > > > > > > > Here's the patch to show the details: > > > > > > > > > > > > --- host-setup.3_0 2011-02-10 19:14:30.000000000 -0800 > > > > > > +++ host-setup 2011-04-21 13:38:58.000000000 -0700 > > > > > > @@ -2,12 +2,12 @@ > > > > > > # -*- tab-width: 4 -*- ;; Emacs > > > > > > # vi: set tabstop=4 :: Vi/ViM > > > > > > # > > > > > > -# Revision: 3.0 > > > > > > +# Revision: 3.1 > > > > > > # Created: September 21st, 2010 > > > > > > -# Last Modified: December 6th, 2010 > > > > > > +# Last Modified: April 21st, 2011 > > > > > > ############################################################ COPYRIGHT > > > > > > # > > > > > > -# Devin Teske (c)2006-2010. All Rights Reserved. > > > > > > +# Devin Teske (c)2006-2011. All Rights Reserved. > > > > > > # > > > > > > # Redistribution and use in source and binary forms, with or without > > > > > > # modification, are permitted provided that the following conditions > > > > > > @@ -1353,8 +1353,10 @@ dialog_input_hostname() > > > > > > # permissions and ownership to match resolv.conf(5) before > > > > > > # we write it out and mv(1) it into place). > > > > > > # > > > > > > - quietly chmod "$( stat -f '%#Lp' "$RESOLV_CONF" )" > > "$tmpfile" > > > > > > - quietly chown "$( stat -f '%u:%g' "$RESOLV_CONF" )" > > "$tmpfile" > > > > > > + local mode="$( stat -f '%#Lp' "$RESOLV_CONF" 2> /dev/null )" > > > > > > + local owner="$( stat -f '%u:%g' "$RESOLV_CONF" 2> /dev/null > > )" > > > > > > + quietly chmod "${mode:-0644}" "$tmpfile" > > > > > > + quietly chown "${owner:-root:wheel}" "$tmpfile" > > > > > > # > > > > > > # Operate on resolv.conf(5), replacing only the last > > > > > > @@ -1646,7 +1648,7 @@ dialog_input_netmask() > > > > > > # > > > > > > while :; do > > > > > > - dialog --title "$brand${band:+}${progname:-$0}" \ > > > > > > + dialog --title "$brand${brand:+ }${progname:-$0}" \ > > > > > > --hline "Use numbers, punctuation, TAB or ENTER" \ > > > > > > --inputbox "$msg" 10 50 \ > > > > > > "$_netmask" \ > > > > > > @@ -1664,7 +1666,7 @@ dialog_input_netmask() > > > > > > [ $retval -eq $SUCCESS ] || return $retval > > > > > > # Return success if NULL value was entered > > > > > > - [ "$_netmask" ] || return $SUCCESS > > > > > > + [ "$_input" ] || return $SUCCESS > > > > > > # Take only the first "word" of the user's input > > > > > > _netmask="$_input" > > > > > > @@ -1705,7 +1707,7 @@ dialog_input_options() > > > > > > msg="Please enter additional network media options to be" > > > > > > msg="$msg passed to ifconfig(8) for the $interface interface:" > > > > > > - dialog --title "$brand${band:+}${progname:-$0}" \ > > > > > > + dialog --title "$brand${brand:+ }${progname:-$0}" \ > > > > > > --hline "Use numbers, punctuation, TAB or ENTER" \ > > > > > > --inputbox "$msg" 9 70 \ > > > > > > "$options" \ > > > > > > @@ -2183,9 +2185,12 @@ dialog_menu_netdev_edit() > > > > > > local dr="$( sysrc_get defaultrouter )" err > > > > > > err=$( ifconfig $interface inet $ipaddr \ > > > > > > netmask $netmask $options 2>&1 ) > > > > > > - if [ $? -eq $SUCCESS -a "$dr" ]; then > > > > > > - err=$( route add default "$dr" 2>&1 ) > > > > > > - [ $? -eq $SUCCESS ] || dialog_msgbox "$err" > > > > > > + if [ $? -eq $SUCCESS ]; then > > > > > > + if [ "$dr" -a "$dr" != "NO" ]; then > > > > > > + err=$( route add default "$dr" 2>&1 ) > > > > > > + [ $? -eq $SUCCESS ] || \ > > > > > > + dialog_msgbox "$err" > > > > > > + fi > > > > > > else > > > > > > dialog_msgbox "$err" > > > > > > fi > > > > > > @@ -2524,7 +2529,7 @@ exit $SUCCESS > > > > > > # > > > > > > # $Header$ > > > > > > # > > > > > > -# $Copyright: 2006-2010. Devin Teske. All Rights Reserved. $ > > > > > > +# $Copyright: 2006-2011. Devin Teske. All Rights Reserved. $ > > > > > > # > > > > > > # $Log$ > > > > > > # > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Cheers, > > > > > > Devin Teske > > > > > > > > > > > > -> FUN STUFF <- > > > > > > -----BEGIN GEEK CODE BLOCK----- > > > > > > Version 3.12 > > > > > > GAT/CS/B/CC/E/IT/MC/M/MU/P/S/TW d+(++) s: a- C+++@$ UB++++$ P++++@$ > > L++++$ E- > > > > > > W+++ N? o? K? w@ O M++$ V- PS+>++ PE@ Y+ PGP-> t(+) 5? X(+) R(-) tv+ > > b+>++ DI+ > > > > > > D+(++) G++ e>++++ h r+++ z+++ > > > > > > ------END GEEK CODE BLOCK------ > > > > > > Learn about the "Geek Code": http://www.geekcode.com/ > > > > > > > > > > > > -> LEGAL DISCLAIMER <- > > > > > > This message contains confidential and proprietary information > > > > > > of the sender, and is intended only for the person(s) to whom it > > > > > > is addressed. Any use, distribution, copying or disclosure by any > > > > > > other person is strictly prohibited. If you have received this > > > > > > message in error, please notify the e-mail sender immediately, > > > > > > and delete the original message without making a copy. > > > > > > > > > > > > -> END TRANSMISSION <- > > > > > > _____________ > > > > > > The information contained in this message is proprietary and/or > > confidential. If you are not the intended recipient, please: (i) delete > > the message and all copies; (ii) do not disclose, distribute or use the > > message in any manner; and (iii) notify the sender immediately. In > > addition, please be aware that any message addressed to our domain is > > subject to archiving and review by persons other than the intended > > recipient. Thank you. > > > _____________ > > > > -- > > a13x > > _____________ > > The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. > _____________ -- a13x From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 22 15:44:36 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1201106564A for ; Fri, 22 Apr 2011 15:44:36 +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 135698FC08 for ; Fri, 22 Apr 2011 15:44:35 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA00398; Fri, 22 Apr 2011 18:44:32 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4DB1A25F.8040700@FreeBSD.org> Date: Fri, 22 Apr 2011 18:44:31 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110309 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Chuck Tuffli References: <20110421221611.7f52ca98@kan.dnsalias.net> <20110422112444.0e423a80@kan.dnsalias.net> In-Reply-To: <20110422112444.0e423a80@kan.dnsalias.net> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org Subject: Re: no KLD symbols in dtrace? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 15:44:36 -0000 on 22/04/2011 18:24 Alexander Kabaev said the following: > Do ctfdump -tf on your kld and verify that what it outputs actually > makes sense. Do kldload and see if fbt provider knows about your module > and functions. There is nothing else special that I can think off. > > Maybe make sure that you compile your sources with -g in the first > place? DWARF debug info is what CTF generation utils use to figure out > types and function prototypes. Also, dtrace process needs to access the module file for address-to-name translation. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 22 15:56:07 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4A56106564A for ; Fri, 22 Apr 2011 15:56:07 +0000 (UTC) (envelope-from ctuffli@gmail.com) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id 718DD8FC1A for ; Fri, 22 Apr 2011 15:56:07 +0000 (UTC) Received: by pxi6 with SMTP id 6so1656114pxi.17 for ; Fri, 22 Apr 2011 08:56:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HZt0fo+AFVh9C/+9ba4YLCXHarlW3LBba1Po+1C898w=; b=jx+eQ5qXWLdn4OJmDpF1nfs+0c+eYKBk0z9h3lU2LLz+zPi4G3WFKX52/C713rd2YH cspotHgMMIx4QxEsPb6hUnJF/RlEwAg8W8+0s1rN9w4u8kr2m03syytTy73loscw6obS hD9znkyErbv1kN82sNFs3k47We7hRW4Kmjfxg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=wq7Fo64cNMKvIb0C4n2RRgIrSt7QPdE28pAlVtPGnJJgn1P/3fYBhF+tsEfuYgvNtF cvmjK4CJfzjWsYRj770l+NTzSrFIh6ai14EIN4WJzST4XAtMs7KsgiJdmXXqVCPZNl9a UBpSZnmwOP2T0RdW5gXGpTHiFWn+zQK2yDHcQ= MIME-Version: 1.0 Received: by 10.68.27.65 with SMTP id r1mr1773735pbg.289.1303487766858; Fri, 22 Apr 2011 08:56:06 -0700 (PDT) Received: by 10.68.49.72 with HTTP; Fri, 22 Apr 2011 08:56:06 -0700 (PDT) In-Reply-To: <4DB1A25F.8040700@FreeBSD.org> References: <20110421221611.7f52ca98@kan.dnsalias.net> <20110422112444.0e423a80@kan.dnsalias.net> <4DB1A25F.8040700@FreeBSD.org> Date: Fri, 22 Apr 2011 08:56:06 -0700 Message-ID: From: Chuck Tuffli To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: no KLD symbols in dtrace? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 15:56:07 -0000 On Fri, Apr 22, 2011 at 8:44 AM, Andriy Gapon wrote: > on 22/04/2011 18:24 Alexander Kabaev said the following: >> Do ctfdump -tf on your kld and verify that what it outputs actually >> makes sense. Do kldload and see if fbt provider knows about your module >> and functions. There is nothing else special that I can think off. The ctfdump looks correct and dtrace -ln "fbt::ocs_*:" shows the kld's function names >> Maybe make sure that you compile your sources with -g in the first >> place? DWARF debug info is what CTF generation utils use to figure out >> types and function prototypes. OK > Also, dtrace process needs to access the module file for address-to-name translation. Hmm ... I'm building this module out of tree. Where does dtrace look for modules? ---chuck From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 22 16:35:12 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15214106564A; Fri, 22 Apr 2011 16:35:12 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id 971DA8FC12; Fri, 22 Apr 2011 16:35:11 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 915BDE6254; Fri, 22 Apr 2011 17:35:10 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=date:from :to:cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=mail; bh=VznXDc3oMyo7 /bsulAJDOn7bU1g=; b=t1iMEGkB9KyK1IBnxhm5Bqz86n4V7wevHyGW8Vhc7y3h dssrhGDuOK7Puejg0eRiiR3bXZJC0OG2spf5m2UP5KrDqhn2QpbD+hQbX1Qpoy5G GK6CTf8abXjH98wzy52a6Ta+xLEvLdxn9egbJZr2fkEEF3tdzLillmBYLY1POs0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=date:from:to :cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; q=dns; s=mail; b=wKYllK Nwc63qd7R/V3ej985AIQwZTNAGbyDpVMcgu5QcFsUkVlh8slfJeG+qed7BznP7oV 8mGmfhnzRDszHe/Cdvgph3mAjwl6FBklPqNy4MpXlZOGda0NGAIf2dsrbnztzdWn GmQ2YLv5EcWb8lTCr1PMHN5xO6XsxhLaqQ8h8= Received: from unknown (188-222-18-231.zone13.bethere.co.uk [188.222.18.231]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id 24840E61FA; Fri, 22 Apr 2011 17:35:10 +0100 (BST) Date: Fri, 22 Apr 2011 17:35:09 +0100 From: Bruce Cran To: Alexander Best Message-ID: <20110422173509.000077ba@unknown> In-Reply-To: <20110422154146.GA26083@freebsd.org> References: <02a701cc006a$887da210$9978e630$@vicor.com> <20110422145518.GA16734@freebsd.org> <20110422154146.GA26083@freebsd.org> X-Mailer: Claws Mail 3.7.8cvs47 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Devin Teske , freebsd-questions@freebsd.org, "'Teske, Devin'" Subject: Re: [UPDATE] host-setup(1): a dialog(1)-based utility for configuring FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 16:35:12 -0000 On Fri, 22 Apr 2011 15:41:46 +0000 Alexander Best wrote: > FreeBSD 9.0-CURRENT amd64 A new version of dialog was imported a few days ago - maybe something broke? -- Bruce Cran From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 22 16:41:09 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B406106564A for ; Fri, 22 Apr 2011 16:41:09 +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 922E08FC08 for ; Fri, 22 Apr 2011 16:41:08 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA01014; Fri, 22 Apr 2011 19:41:04 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4DB1AFA0.7030401@FreeBSD.org> Date: Fri, 22 Apr 2011 19:41:04 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110309 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Chuck Tuffli References: <20110421221611.7f52ca98@kan.dnsalias.net> <20110422112444.0e423a80@kan.dnsalias.net> <4DB1A25F.8040700@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org Subject: Re: no KLD symbols in dtrace? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 16:41:09 -0000 on 22/04/2011 18:56 Chuck Tuffli said the following: > On Fri, Apr 22, 2011 at 8:44 AM, Andriy Gapon wrote: >> Also, dtrace process needs to access the module file for address-to-name translation. > > Hmm ... I'm building this module out of tree. Where does dtrace look > for modules? I think that exactly at the place from which a module is loaded. You can double-check with kldstat -v, e.g.: 2 1 0xffffffff80c6c000 217f20 zfs.ko (/boot/kernel/zfs.ko) -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 22 16:51:19 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F228F106566B; Fri, 22 Apr 2011 16:51:19 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id B8D958FC12; Fri, 22 Apr 2011 16:51:19 +0000 (UTC) Received: from sbhfislrext02.fnfis.com ([192.168.249.140]) by SCSFISLTC02 (8.14.3/8.14.3) with ESMTP id p3MGpIXB022872; Fri, 22 Apr 2011 11:51:18 -0500 Received: from sbhfisltcgw01.FNFIS.COM (Not Verified[10.132.248.121]) by sbhfislrext02.fnfis.com with MailMarshal (v6, 5, 4, 7535) id ; Fri, 22 Apr 2011 11:51:16 -0500 Received: from SBHFISLTCGW04.FNFIS.COM ([10.132.248.123]) by sbhfisltcgw01.FNFIS.COM with Microsoft SMTPSVC(6.0.3790.4675); Fri, 22 Apr 2011 11:51:18 -0500 Received: from dtwin ([10.132.254.135]) by SBHFISLTCGW04.FNFIS.COM over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 22 Apr 2011 11:51:16 -0500 From: "Devin Teske" To: "'Alexander Best'" Date: Fri, 22 Apr 2011 09:50:50 -0700 Organization: Vicor, Inc. Message-ID: <039d01cc010d$73438830$59ca9890$@vicor.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcwBCiNK12Cv/J8MR6udsBjVysi4FA== Content-Language: en-us X-OriginalArrivalTime: 22 Apr 2011 16:51:17.0746 (UTC) FILETIME=[7FD04520:01CC010D] Cc: freebsd-hackers@freebsd.org, freebsd-questions@freebsd.org, "'Teske, Devin'" Subject: dialog(1) changed in RELENG_9 (was RE: [UPDATE] host-setup(1): a dialog(1)-based utility for configuring FreeBSD) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 16:51:20 -0000 > -----Original Message----- > From: Alexander Best [mailto:arundel@freebsd.org] > Sent: Friday, April 22, 2011 8:42 AM > To: Devin Teske > Cc: freebsd-hackers@freebsd.org; freebsd-questions@freebsd.org; 'Teske, > Devin' > Subject: Re: [UPDATE] host-setup(1): a dialog(1)-based utility for configuring > FreeBSD > > On Fri Apr 22 11, Devin Teske wrote: > > > > > -----Original Message----- > > > From: Alexander Best [mailto:arundel@freebsd.org] > > > Sent: Friday, April 22, 2011 7:55 AM > > > To: Devin Teske > > > Cc: freebsd-hackers@freebsd.org; freebsd-questions@freebsd.org; > > > Teske, Devin > > > Subject: Re: [UPDATE] host-setup(1): a dialog(1)-based utility for > > > configuring FreeBSD > > > > > > On Thu Apr 21 11, Devin Teske wrote: > > > > Hi List Members! > > > > > > > > I'm proud to announce the first update to my host-setup utility (a > > > > dialog(1)-based host configurator for FreeBSD). The following > > > > changes > > > have been > > > > made: > > > > > > > > - fixed bug where /etc/resolv.conf would be created with 0600 > > > permissions > > > > - fixed bug when switching from one default gateway to NO default > > > gateway > > > > - fixed typo in the title of netmask prompt and ifconfig options > > > > dialog > > > > - fixed bug that prevented entry of netmask if no netmask is > > > > configured > > > > > > > > You can get the updated version here: > > > > > > > > http://druidbsd.sourceforge.net/download/host-setup.txt > > > > > > otaku% sudo ./host-setup.txt > > > User cancelled. > > > otaku% echo $? > > > 1 > > > otaku% > > > > Can you provide me with the output of "uname -spr"? > > FreeBSD 9.0-CURRENT amd64 I haven't yet had a chance to pull that one down and install it yet. Hopefully you can help me out with this one here. > > > > > It's working fine for me on FreeBSD 8.1-RELEASE i386. > > > > Where you're bombing out is line 2403: > > [ $retval -eq 0 ] || die "User cancelled." > > > > Functionally, that is testing the return status of dialog(1) for the > > initial menu. See if you can execute this (a rough approximation of > > the initial > > menu): > > > > dialog --clear --title foo --hline bar --menu abc 17 55 9 1 a 2 b 3 c > > 4 d 5 e X x 2> /tmp/dialog.menu.foo > > doesn't work. :( Bummer! We'll have to fix that. > > otaku% echo $? > 255 > otaku% cat /tmp/dialog.menu.foo > > Error: Unknown option --hline. > Use --help to list options. Aha! I think I remember seeing in the list a thread related to swapping out dialog(1) for something new. This must be it. > > > otaku% > > taku% whereis dialog > dialog: /usr/bin/dialog /usr/share/man/en.ISO8859-15/man1/dialog.1.gz > /usr/src/gnu/usr.bin/dialog > > otaku% /usr/bin/dialog > cdialog (ComeOn Dialog!) version 1.1-20100428 Copyright 2000-2007,2008 Thomas > E. Dickey This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR > PURPOSE. I can't recall as I don't have the thread in front of me, but why was dialog(1) replaced with cdialog? licensing? performance? I guess I could code my script to support this new dialog(1), but... can you see if the below works (I removed the "--hline" option): dialog --clear --title foo --menu abc 17 55 9 1 a 2 b 3 c 4 d 5 e X x 2> /tmp/dialog.menu.foo If that succeeds, then I can modify my script to not use `--hline' on RELENG_9 and higher (referencing `sysctl -n kern.osreldate` for example). > > [...] > > > > > A menu should appear. Select an item and then execute for me: > > > > echo $? > > > > If the above doesn't work, then I suspect that your dialog(1) is not > > working properly. I'd then go and try this as a sanity check: > > > > cd /usr/share/examples/dialog > > otaku% cd /usr/share/examples/dialog > cd: no such file or directory: /usr/share/examples/dialog Really? I would have thought that the examples in that directory (which are merely shell scripts) would have been recoded for cdialog rather than altogether removed. Maybe there was licensing issues there too. Was there? > > > sh menubox > > echo $? > > > > The result in both cases (as long as you actually select a menu item) > > should be "0". > > > > Also... (just as a sanity check for me) your /bin/sh is not a symlink > > to bash is it? > > otaku% file /bin/sh > /bin/sh: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically > linked (uses shared libs), for FreeBSD 9.0 (900034), stripped Cool. Though I'm still disappointed that my beloved dialog(1) has gone missing (rather, replaced with something doesn't accept the same arguments and/or options)(which is the problem that we're experiencing here). Is there anybody familiar with the changing-out dialog(1) that can bring me up to speed with reasoning and specifics for RELENG_9? Also, might it be prudent -- before cutting 9_0_RELEASE -- to add the fact that dialog(1) no longer accepts `--hline' to the UPGRADING and/or ERRATA documents? -- Devin > > > -- > > Devin > > > > > > > > > > > or > > > > http://druidbsd.sourceforge.net/download/host-setup.gz > > > > or > > > > http://druidbsd.sourceforge.net/ > > > > > > > > For those not familiar with my host-setup(1) utility, it is a 2,500+ line shell > > > > script that utilizes the dialog(1) utility to walk the system administrator > > > > through setting up their TimeZone, Hostname, Network Interfaces, > > > > Default Gateway, and DNS. Our custom FreeBSD installer sets this > > > > script as the root login shell, making it very easy for field engineers to quickly > > > > get a system on the network without having to use the command-line (and > > > > without having to reboot either). Underneath the hood - behind the system > > > > of prompts and dialogs - this script manages both the contents of /etc/rc.conf, > > > > /etc/resolv.conf, and others as well as utilizing ifconfig(8), route(8), and many > > > > other tools to avoid requiring a reboot, prompting you if you would like to > > > > make the new changes effective when values are changed from their active > > > > settings. > > > > > > > > Here's the patch to show the details: > > > > > > > > [snip] > > > > -- > > > > Cheers, > > > > Devin Teske > > > > > > > > -> FUN STUFF <- > > > > -----BEGIN GEEK CODE BLOCK----- > > > > Version 3.12 > > > > GAT/CS/B/CC/E/IT/MC/M/MU/P/S/TW d+(++) s: a- C+++@$ UB++++$ P++++@$ L++++$ E- > > > > W+++ N? o? K? w@ O M++$ V- PS+>++ PE@ Y+ PGP-> t(+) 5? X(+) R(-) W+++ tv+ b+>++ DI+ > > > > D+(++) G++ e>++++ h r+++ z+++ > > > > ------END GEEK CODE BLOCK------ > > > > Learn about the "Geek Code": http://www.geekcode.com/ > > > > > > > > -> LEGAL DISCLAIMER <- > > > > This message contains confidential and proprietary information > > > > of the sender, and is intended only for the person(s) to whom it > > > > is addressed. Any use, distribution, copying or disclosure by any > > > > other person is strictly prohibited. If you have received this > > > > message in error, please notify the e-mail sender immediately, > > > > and delete the original message without making a copy. > > > > > > > > -> END TRANSMISSION <- > > > > _____________ > > > > > > > > The information contained in this message is proprietary and/or > > > confidential. If you are not the intended recipient, please: (i) > > > delete the message and all copies; (ii) do not disclose, distribute > > > or use the message in any manner; and (iii) notify the sender > > > immediately. In addition, please be aware that any message addressed > > > to our domain is subject to archiving and review by persons other > > > than the intended recipient. Thank you. > > > > _____________ > > > > > > -- > > > a13x > > > > _____________ > > > > The information contained in this message is proprietary and/or confidential. If > you are not the intended recipient, please: (i) delete the message and all copies; > (ii) do not disclose, distribute or use the message in any manner; and (iii) notify > the sender immediately. In addition, please be aware that any message > addressed to our domain is subject to archiving and review by persons other than > the intended recipient. Thank you. > > _____________ > > -- > a13x _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. _____________ From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 22 16:51:50 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C77D31065675; Fri, 22 Apr 2011 16:51:50 +0000 (UTC) (envelope-from ctuffli@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7FBFC8FC08; Fri, 22 Apr 2011 16:51:50 +0000 (UTC) Received: by pzk27 with SMTP id 27so492844pzk.13 for ; Fri, 22 Apr 2011 09:51:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=x1Jhw5HlJadOCQ6AP/OEdPs08l3mKODVM64KtWjry8U=; b=gTiEJUnylPbqETdNL8BQ6f9m+wId3fPS2opKwsr8uL20igg1l6fUjzk+621s4Wxl6X qlqWXOj961zCJ6gqVDhShPmaoSUmqgBxOGTYlHu1byleWw+oYWRIFbR+HKBRMejO+qHX pGUL+eUX2VWd0Jfo+Jee3alZQ0YoCARS8Us+U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=qb1/1yYUdgU0rfHDfYI5H5Ww74fB8/TG0YOatmtG/1a+1TlrH9uoE8xY0qynE2nLW+ 3aXMkFsMPJKtjH60CYjQBbU1yHFsbkquN/oH1C4EvSxvRq2BbuCyioZAAkPQE9SuPL8k /OqQEsPgpMuLIBCby10ePz9eH/q18iAX+fvvg= MIME-Version: 1.0 Received: by 10.68.20.129 with SMTP id n1mr1997979pbe.155.1303491110070; Fri, 22 Apr 2011 09:51:50 -0700 (PDT) Received: by 10.68.49.72 with HTTP; Fri, 22 Apr 2011 09:51:50 -0700 (PDT) In-Reply-To: <4DB1AFA0.7030401@FreeBSD.org> References: <20110421221611.7f52ca98@kan.dnsalias.net> <20110422112444.0e423a80@kan.dnsalias.net> <4DB1A25F.8040700@FreeBSD.org> <4DB1AFA0.7030401@FreeBSD.org> Date: Fri, 22 Apr 2011 09:51:50 -0700 Message-ID: From: Chuck Tuffli To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: no KLD symbols in dtrace? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 16:51:50 -0000 On Fri, Apr 22, 2011 at 9:41 AM, Andriy Gapon wrote: > on 22/04/2011 18:56 Chuck Tuffli said the following: >> On Fri, Apr 22, 2011 at 8:44 AM, Andriy Gapon wrote: >>> Also, dtrace process needs to access the module file for address-to-nam= e translation. >> >> Hmm ... I'm building this module out of tree. Where does dtrace look >> for modules? > > I think that exactly at the place from which a module is loaded. > You can double-check with kldstat -v, e.g.: > =A02 =A0 =A01 0xffffffff80c6c000 217f20 =A0 zfs.ko (/boot/kernel/zfs.ko) Ah-ha! I was loading the module with a relative path (i.e. kldload ./ocs.ko), but when I switched this to use the full path (i.e. kldload /home/ctuffli/ocs.ko) everything worked. 2 33759 bus_release_resource:entry ocs.ko`ocs_release_bus+0x2e ocs.ko`ocs_pci_detach+0x31 kernel`device_detach+0x84 kernel`driver_module_handler+0x37c kernel`module_unload+0x49 kernel`linker_file_unload+0x178 kernel`kern_kldunload+0x117 kernel`syscallenter+0x23d kernel`syscall+0x4b kernel`0xffffffff808c5572 Thanks for the patch and all your help! ---chuck From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 22 16:53:09 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A1978106567F; Fri, 22 Apr 2011 16:53:09 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 65B9E8FC12; Fri, 22 Apr 2011 16:53:09 +0000 (UTC) Received: from sbhfislrext01.fnfis.com ([192.168.249.167]) by SCSFISLTC02 (8.14.3/8.14.3) with ESMTP id p3MGr7lR024616; Fri, 22 Apr 2011 11:53:07 -0500 Received: from sbhfisltcgw02.FNFIS.COM (Not Verified[10.132.248.122]) by sbhfislrext01.fnfis.com with MailMarshal (v6, 5, 4, 7535) id ; Fri, 22 Apr 2011 11:53:02 -0500 Received: from SBHFISLTCGW04.FNFIS.COM ([10.132.248.123]) by sbhfisltcgw02.FNFIS.COM with Microsoft SMTPSVC(6.0.3790.4675); Fri, 22 Apr 2011 11:53:07 -0500 Received: from dtwin ([10.132.254.135]) by SBHFISLTCGW04.FNFIS.COM over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 22 Apr 2011 11:53:06 -0500 From: "Devin Teske" To: "'Bruce Cran'" , "'Alexander Best'" References: <02a701cc006a$887da210$9978e630$@vicor.com> <20110422145518.GA16734@freebsd.org> <20110422154146.GA26083@freebsd.org> <20110422173509.000077ba@unknown> In-Reply-To: <20110422173509.000077ba@unknown> Date: Fri, 22 Apr 2011 09:52:44 -0700 Organization: Vicor, Inc. Message-ID: <039f01cc010d$b476d0f0$1d6472d0$@vicor.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHbf51LIKsKPgssf99P131HkrB38wGbPSlTAgK1w+gCwVx/+gErfQdllA7FXZA= Content-Language: en-us X-OriginalArrivalTime: 22 Apr 2011 16:53:06.0637 (UTC) FILETIME=[C0B7B7D0:01CC010D] Cc: freebsd-hackers@freebsd.org, freebsd-questions@freebsd.org, "'Teske, Devin'" Subject: RE: [UPDATE] host-setup(1): a dialog(1)-based utility for configuring FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 16:53:09 -0000 > -----Original Message----- > From: Bruce Cran [mailto:bruce@cran.org.uk] > Sent: Friday, April 22, 2011 9:35 AM > To: Alexander Best > Cc: Devin Teske; freebsd-hackers@freebsd.org; freebsd-questions@freebsd.org; > 'Teske, Devin' > Subject: Re: [UPDATE] host-setup(1): a dialog(1)-based utility for configuring > FreeBSD > > On Fri, 22 Apr 2011 15:41:46 +0000 > Alexander Best wrote: > > > FreeBSD 9.0-CURRENT amd64 > > A new version of dialog was imported a few days ago - maybe something broke? Looks like `--hline' is not supported anymore. Thinking this should either be patched or documented in ERRATA/UPGRADING. > > -- > Bruce Cran _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. _____________ From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 22 17:05:18 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id C4CB21065674; Fri, 22 Apr 2011 17:05:18 +0000 (UTC) Date: Fri, 22 Apr 2011 17:05:18 +0000 From: Alexander Best To: Devin Teske Message-ID: <20110422170518.GA41759@freebsd.org> References: <039d01cc010d$73438830$59ca9890$@vicor.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <039d01cc010d$73438830$59ca9890$@vicor.com> Cc: freebsd-hackers@freebsd.org, freebsd-questions@freebsd.org, "'Teske, Devin'" Subject: Re: dialog(1) changed in RELENG_9 (was RE: [UPDATE] host-setup(1): a dialog(1)-based utility for configuring FreeBSD) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 17:05:18 -0000 On Fri Apr 22 11, Devin Teske wrote: > > -----Original Message----- > > From: Alexander Best [mailto:arundel@freebsd.org] > > Sent: Friday, April 22, 2011 8:42 AM > > To: Devin Teske > > Cc: freebsd-hackers@freebsd.org; freebsd-questions@freebsd.org; 'Teske, > > Devin' > > Subject: Re: [UPDATE] host-setup(1): a dialog(1)-based utility for configuring > > FreeBSD > > > > On Fri Apr 22 11, Devin Teske wrote: > > > > > > > -----Original Message----- > > > > From: Alexander Best [mailto:arundel@freebsd.org] > > > > Sent: Friday, April 22, 2011 7:55 AM > > > > To: Devin Teske > > > > Cc: freebsd-hackers@freebsd.org; freebsd-questions@freebsd.org; > > > > Teske, Devin > > > > Subject: Re: [UPDATE] host-setup(1): a dialog(1)-based utility for > > > > configuring FreeBSD > > > > > > > > On Thu Apr 21 11, Devin Teske wrote: > > > > > Hi List Members! > > > > > > > > > > I'm proud to announce the first update to my host-setup utility (a > > > > > dialog(1)-based host configurator for FreeBSD). The following > > > > > changes > > > > have been > > > > > made: > > > > > > > > > > - fixed bug where /etc/resolv.conf would be created with 0600 > > > > permissions > > > > > - fixed bug when switching from one default gateway to NO default > > > > gateway > > > > > - fixed typo in the title of netmask prompt and ifconfig options > > > > > dialog > > > > > - fixed bug that prevented entry of netmask if no netmask is > > > > > configured > > > > > > > > > > You can get the updated version here: > > > > > > > > > > http://druidbsd.sourceforge.net/download/host-setup.txt > > > > > > > > otaku% sudo ./host-setup.txt > > > > User cancelled. > > > > otaku% echo $? > > > > 1 > > > > otaku% > > > > > > Can you provide me with the output of "uname -spr"? > > > > FreeBSD 9.0-CURRENT amd64 > > I haven't yet had a chance to pull that one down and install it yet. Hopefully > you can help me out with this one here. > > > > > > > > > It's working fine for me on FreeBSD 8.1-RELEASE i386. > > > > > > Where you're bombing out is line 2403: > > > [ $retval -eq 0 ] || die "User cancelled." > > > > > > Functionally, that is testing the return status of dialog(1) for the > > > initial menu. See if you can execute this (a rough approximation of > > > the initial > > > menu): > > > > > > dialog --clear --title foo --hline bar --menu abc 17 55 9 1 a 2 b 3 c > > > 4 d 5 e X x 2> /tmp/dialog.menu.foo > > > > doesn't work. :( > > Bummer! We'll have to fix that. > > > > > > otaku% echo $? > > 255 > > otaku% cat /tmp/dialog.menu.foo > > > > Error: Unknown option --hline. > > Use --help to list options. > > Aha! I think I remember seeing in the list a thread related to swapping out > dialog(1) for something new. This must be it. > > > > > > > otaku% > > > > taku% whereis dialog > > dialog: /usr/bin/dialog /usr/share/man/en.ISO8859-15/man1/dialog.1.gz > > /usr/src/gnu/usr.bin/dialog > > > > otaku% /usr/bin/dialog > > cdialog (ComeOn Dialog!) version 1.1-20100428 Copyright 2000-2007,2008 Thomas > > E. Dickey This is free software; see the source for copying conditions. There > is NO > > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR > > PURPOSE. > > I can't recall as I don't have the thread in front of me, but why was dialog(1) > replaced with cdialog? licensing? performance? > > I guess I could code my script to support this new dialog(1), but... can you see > if the below works (I removed the "--hline" option): > > dialog --clear --title foo --menu abc 17 55 9 1 a 2 b 3 c 4 d 5 e X x 2> > /tmp/dialog.menu.foo > > If that succeeds, then I can modify my script to not use `--hline' on RELENG_9 > and higher (referencing `sysctl -n kern.osreldate` for example). that works with $? == 0 > > > > > > [...] > > > > > > > > A menu should appear. Select an item and then execute for me: > > > > > > echo $? > > > > > > If the above doesn't work, then I suspect that your dialog(1) is not > > > working properly. I'd then go and try this as a sanity check: > > > > > > cd /usr/share/examples/dialog > > > > otaku% cd /usr/share/examples/dialog > > cd: no such file or directory: /usr/share/examples/dialog > > Really? I would have thought that the examples in that directory (which are > merely shell scripts) would have been recoded for cdialog rather than altogether > removed. Maybe there was licensing issues there too. Was there? > > > > > > > sh menubox > > > echo $? > > > > > > The result in both cases (as long as you actually select a menu item) > > > should be "0". > > > > > > Also... (just as a sanity check for me) your /bin/sh is not a symlink > > > to bash is it? > > > > otaku% file /bin/sh > > /bin/sh: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically > > linked (uses shared libs), for FreeBSD 9.0 (900034), stripped > > Cool. Though I'm still disappointed that my beloved dialog(1) has gone missing > (rather, replaced with something doesn't accept the same arguments and/or > options)(which is the problem that we're experiencing here). > > Is there anybody familiar with the changing-out dialog(1) that can bring me up > to speed with reasoning and specifics for RELENG_9? Also, might it be prudent -- > before cutting 9_0_RELEASE -- to add the fact that dialog(1) no longer accepts > `--hline' to the UPGRADING and/or ERRATA documents? > -- > Devin > > > > > > -- > > > Devin > > > > > > > > > > > > > > > or > > > > > http://druidbsd.sourceforge.net/download/host-setup.gz > > > > > or > > > > > http://druidbsd.sourceforge.net/ > > > > > > > > > > For those not familiar with my host-setup(1) utility, it is a 2,500+ > line shell > > > > > script that utilizes the dialog(1) utility to walk the system > administrator > > > > > through setting up their TimeZone, Hostname, Network Interfaces, > > > > > Default Gateway, and DNS. Our custom FreeBSD installer sets this > > > > > script as the root login shell, making it very easy for field engineers > to quickly > > > > > get a system on the network without having to use the command-line (and > > > > > without having to reboot either). Underneath the hood - behind the > system > > > > > of prompts and dialogs - this script manages both the contents of > /etc/rc.conf, > > > > > /etc/resolv.conf, and others as well as utilizing ifconfig(8), route(8), > and many > > > > > other tools to avoid requiring a reboot, prompting you if you would like > to > > > > > make the new changes effective when values are changed from their active > > > > > settings. > > > > > > > > > > Here's the patch to show the details: > > > > > > > > > > [snip] > > > > > -- > > > > > Cheers, > > > > > Devin Teske > > > > > > > > > > -> FUN STUFF <- > > > > > -----BEGIN GEEK CODE BLOCK----- > > > > > Version 3.12 > > > > > GAT/CS/B/CC/E/IT/MC/M/MU/P/S/TW d+(++) s: a- C+++@$ UB++++$ P++++@$ > L++++$ E- > > > > > W+++ N? o? K? w@ O M++$ V- PS+>++ PE@ Y+ PGP-> t(+) 5? X(+) R(-) W+++ > tv+ b+>++ DI+ > > > > > D+(++) G++ e>++++ h r+++ z+++ > > > > > ------END GEEK CODE BLOCK------ > > > > > Learn about the "Geek Code": http://www.geekcode.com/ > > > > > > > > > > -> LEGAL DISCLAIMER <- > > > > > This message contains confidential and proprietary information > > > > > of the sender, and is intended only for the person(s) to whom it > > > > > is addressed. Any use, distribution, copying or disclosure by any > > > > > other person is strictly prohibited. If you have received this > > > > > message in error, please notify the e-mail sender immediately, > > > > > and delete the original message without making a copy. > > > > > > > > > > -> END TRANSMISSION <- > > > > > _____________ > > > > > > > > > > The information contained in this message is proprietary and/or > > > > confidential. If you are not the intended recipient, please: (i) > > > > delete the message and all copies; (ii) do not disclose, distribute > > > > or use the message in any manner; and (iii) notify the sender > > > > immediately. In addition, please be aware that any message addressed > > > > to our domain is subject to archiving and review by persons other > > > > than the intended recipient. Thank you. > > > > > _____________ > > > > > > > > -- > > > > a13x > > > > > > _____________ > > > > > > The information contained in this message is proprietary and/or > confidential. If > > you are not the intended recipient, please: (i) delete the message and all > copies; > > (ii) do not disclose, distribute or use the message in any manner; and (iii) > notify > > the sender immediately. In addition, please be aware that any message > > addressed to our domain is subject to archiving and review by persons other > than > > the intended recipient. Thank you. > > > _____________ > > > > -- > > a13x > > _____________ > > The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. > _____________ -- a13x From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 22 18:24:24 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8F2A106564A for ; Fri, 22 Apr 2011 18:24:24 +0000 (UTC) (envelope-from robert.lorentz@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4E3948FC0A for ; Fri, 22 Apr 2011 18:24:23 +0000 (UTC) Received: by yxl31 with SMTP id 31so266555yxl.13 for ; Fri, 22 Apr 2011 11:24:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:from:content-type:x-mailer:message-id :date:to:content-transfer-encoding:mime-version; bh=89XWWYPaYQ2zu2AwkXyK2Szyf2WggTiZWBJkdxa4rRU=; b=IqJrJweqx1TRHhUV187g4O/RIpfJx0ue72XauCaOuWMpI7WyO7tRgZ7UFYoc5c6hPv Nx+NYZuiyf99tNymyPymXrmZ2xic5oHYvZkjAFB9GX62ZrQg62F1SjGIUT0R+qTabmEU f1oUmHPPh0fduSE8Ne0t8s0pK33c74WaqfkhQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:content-type:x-mailer:message-id:date:to :content-transfer-encoding:mime-version; b=wN5vYrHufAHCcyo3JyXS3JWdbsQwsawXhysf3Wcyf03BuogevlUPwCi5yabbcFdwGk Nt3ys5X1ei95CdO1KJSStTryJm09qmqTPNeKRtyrJJQJcot5KsKW7muBEPP4e6AUK5yj 7u4E+6dnPKVK7QDTEwF6EZXqi2RSqLSOUsaPk= Received: by 10.236.53.74 with SMTP id f50mr1381928yhc.380.1303495103055; Fri, 22 Apr 2011 10:58:23 -0700 (PDT) Received: from [10.93.102.8] ([166.137.9.195]) by mx.google.com with ESMTPS id 51sm302322yha.58.2011.04.22.10.58.20 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 22 Apr 2011 10:58:21 -0700 (PDT) From: Robert Lorentz Content-Type: text/plain; charset=us-ascii X-Mailer: iPhone Mail (8G4) Message-Id: Date: Fri, 22 Apr 2011 13:58:15 -0400 To: "freebsd-hackers@freebsd.org" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (iPhone Mail 8G4) Subject: Looking for resources to get started X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 18:24:25 -0000 Hi, I'm very interested in getting started with FreeBSD development. My interest= s are wide but specifically core OS, performance, scheduling, cryptography, p= erhaps filesystems etc.=20 I have seen the "Ideas" list and there is some good stuff there but those ar= e fairly complex/large tasks. Where can I find something more basic to addre= ss to get myself familiar with the process of contributing? My motivation for contributing is to learn more about the FreeBSD kernel and= core OS and to put my skills toward FreeBSD which I find interesting and wo= rthwhile. I am knowledgable in C, scheduling, data interface, somewhat also= in cryptography Thanks, Robert= From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 22 18:28:36 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 3C5521065673 for ; Fri, 22 Apr 2011 18:28:36 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-5.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id C560B15098A; Fri, 22 Apr 2011 18:28:35 +0000 (UTC) Message-ID: <4DB1C8CC.4060803@FreeBSD.org> Date: Fri, 22 Apr 2011 11:28:28 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.15) Gecko/20110326 Thunderbird/3.1.9 MIME-Version: 1.0 To: Robert Lorentz References: In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-hackers@freebsd.org" Subject: Re: Looking for resources to get started X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 18:28:36 -0000 On 04/22/2011 10:58, Robert Lorentz wrote: > Hi, > > I'm very interested in getting started with FreeBSD development. My interests are wide but specifically core OS, performance, scheduling, cryptography, perhaps filesystems etc. > > I have seen the "Ideas" list and there is some good stuff there but those are fairly complex/large tasks. Where can I find something more basic to address to get myself familiar with the process of contributing? > > My motivation for contributing is to learn more about the FreeBSD kernel and core OS and to put my skills toward FreeBSD which I find interesting and worthwhile. I am knowledgable in C, scheduling, data interface, somewhat also in cryptography One project that I'd very much like to see support for is truecrypt: http://www.truecrypt.org/ That will combine several of the interests that you mentioned above. Good luck, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 22 20:01:27 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B767106566B for ; Fri, 22 Apr 2011 20:01:27 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3FFB18FC0C for ; Fri, 22 Apr 2011 20:01:26 +0000 (UTC) Received: by qwc9 with SMTP id 9so493825qwc.13 for ; Fri, 22 Apr 2011 13:01:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=dUIBuFgX5DKnG1Ka/3SGjDr00XlHKfjuKkjuTlpAjJ4=; b=JWP+uucNAMLlmYqaC5Xv0FM+9Lskje3YLO+I4QxI9YIs2notMo1xOlCe9Du3dEmE0w fDkfo3/zIzMs0KB4380EneeNFJzaDz+IigKgjN0r239BhC9rQJaLJqPeFc2lIhUBC+p+ ngoJexoaSMtnnkYLjGHBI+19o4kIcZUxwyRqk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=MSm2W7cUicpAMEGfo0oTDPbLj2n3aG7QZaRURw+RS/NzhALWvv1di9xfu4f2ge4Vyz hv6TKUXcTte/IUBpwLn/fV1dVzpFiDUY2vje1pHqVBefHSGU80rd4K/5EkBa23LFiRbw 4PyZH/7eKFNi8/jdB5kgc8TUqlYd/T2CDbXWI= MIME-Version: 1.0 Received: by 10.229.119.151 with SMTP id z23mr1075060qcq.2.1303502485537; Fri, 22 Apr 2011 13:01:25 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.229.96.79 with HTTP; Fri, 22 Apr 2011 13:01:25 -0700 (PDT) In-Reply-To: References: Date: Fri, 22 Apr 2011 13:01:25 -0700 X-Google-Sender-Auth: -dP1TxR5x3dmMDvqBnIhOxnerz0 Message-ID: From: Artem Belevich To: Robert Lorentz Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-hackers@freebsd.org" Subject: Re: Looking for resources to get started X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 20:01:27 -0000 On Fri, Apr 22, 2011 at 10:58 AM, Robert Lorentz wrote: > Hi, > > I'm very interested in getting started with FreeBSD development. My inter= ests are wide but specifically core OS, performance, scheduling, cryptograp= hy, perhaps filesystems etc. > > I have seen the "Ideas" list and there is some good stuff there but those= are fairly complex/large tasks. Where can I find something more basic to a= ddress to get myself familiar with the process of contributing? > > My motivation for contributing is to learn more about the FreeBSD kernel = and core OS and to put my skills toward FreeBSD which I find interesting an= d worthwhile. I am =A0knowledgable in C, scheduling, data interface, somewh= at also in cryptography Problem report list may be helpful: http://www.freebsd.org/support/bugreports.html There are always things that need fixing. There's a good chance you'll find something that matches your preferences. --Artem From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 22 21:07:48 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 180181065673 for ; Fri, 22 Apr 2011 21:07:48 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from adsum.doit.wisc.edu (adsum.doit.wisc.edu [144.92.197.210]) by mx1.freebsd.org (Postfix) with ESMTP id CF1428FC15 for ; Fri, 22 Apr 2011 21:07:47 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth1.wiscmail.wisc.edu by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0LK20090AO0ZI200@smtpauth1.wiscmail.wisc.edu>; Fri, 22 Apr 2011 16:07:47 -0500 (CDT) Received: from anacreon.physics.wisc.edu (anacreon.physics.wisc.edu [128.104.160.176]) by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0LK200JOQO0XCU20@smtpauth1.wiscmail.wisc.edu>; Fri, 22 Apr 2011 16:07:45 -0500 (CDT) Date: Fri, 22 Apr 2011 16:07:45 -0500 From: Nathan Whitehorn In-reply-to: <039d01cc010d$73438830$59ca9890$@vicor.com> To: Devin Teske Message-id: <4DB1EE21.9030705@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=128.104.160.176 X-Spam-PmxInfo: Server=avs-9, Version=5.6.0.2009776, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.4.22.205724, SenderIP=128.104.160.176 References: <039d01cc010d$73438830$59ca9890$@vicor.com> User-Agent: Mozilla/5.0 (X11; U; FreeBSD powerpc; en-US; rv:1.9.2.15) Gecko/20110305 Thunderbird/3.1.9 Cc: "'Teske, Devin'" , 'Alexander Best' , freebsd-questions@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: dialog(1) changed in RELENG_9 (was RE: [UPDATE] host-setup(1): a dialog(1)-based utility for configuring FreeBSD) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 21:07:48 -0000 On 04/22/11 11:50, Devin Teske wrote: >> -----Original Message----- >> From: Alexander Best [mailto:arundel@freebsd.org] >> Sent: Friday, April 22, 2011 8:42 AM >> To: Devin Teske >> Cc: freebsd-hackers@freebsd.org; freebsd-questions@freebsd.org; 'Teske, >> Devin' >> Subject: Re: [UPDATE] host-setup(1): a dialog(1)-based utility for configuring >> FreeBSD >> >> On Fri Apr 22 11, Devin Teske wrote: >>>> -----Original Message----- >>>> From: Alexander Best [mailto:arundel@freebsd.org] >>>> Sent: Friday, April 22, 2011 7:55 AM >>>> To: Devin Teske >>>> Cc: freebsd-hackers@freebsd.org; freebsd-questions@freebsd.org; >>>> Teske, Devin >>>> Subject: Re: [UPDATE] host-setup(1): a dialog(1)-based utility for >>>> configuring FreeBSD >>>> >>>> On Thu Apr 21 11, Devin Teske wrote: >>>>> Hi List Members! >>>>> >>>>> I'm proud to announce the first update to my host-setup utility (a >>>>> dialog(1)-based host configurator for FreeBSD). The following >>>>> changes >>>> have been >>>>> made: >>>>> >>>>> - fixed bug where /etc/resolv.conf would be created with 0600 >>>> permissions >>>>> - fixed bug when switching from one default gateway to NO default >>>> gateway >>>>> - fixed typo in the title of netmask prompt and ifconfig options >>>>> dialog >>>>> - fixed bug that prevented entry of netmask if no netmask is >>>>> configured >>>>> >>>>> You can get the updated version here: >>>>> >>>>> http://druidbsd.sourceforge.net/download/host-setup.txt >>>> otaku% sudo ./host-setup.txt >>>> User cancelled. >>>> otaku% echo $? >>>> 1 >>>> otaku% >>> Can you provide me with the output of "uname -spr"? >> FreeBSD 9.0-CURRENT amd64 > I haven't yet had a chance to pull that one down and install it yet. Hopefully > you can help me out with this one here. > >>> It's working fine for me on FreeBSD 8.1-RELEASE i386. >>> >>> Where you're bombing out is line 2403: >>> [ $retval -eq 0 ] || die "User cancelled." >>> >>> Functionally, that is testing the return status of dialog(1) for the >>> initial menu. See if you can execute this (a rough approximation of >>> the initial >>> menu): >>> >>> dialog --clear --title foo --hline bar --menu abc 17 55 9 1 a 2 b 3 c >>> 4 d 5 e X x 2> /tmp/dialog.menu.foo >> doesn't work. :( > Bummer! We'll have to fix that. > > >> otaku% echo $? >> 255 >> otaku% cat /tmp/dialog.menu.foo >> >> Error: Unknown option --hline. >> Use --help to list options. > Aha! I think I remember seeing in the list a thread related to swapping out > dialog(1) for something new. This must be it. > >> >> otaku% >> >> taku% whereis dialog >> dialog: /usr/bin/dialog /usr/share/man/en.ISO8859-15/man1/dialog.1.gz >> /usr/src/gnu/usr.bin/dialog >> >> otaku% /usr/bin/dialog >> cdialog (ComeOn Dialog!) version 1.1-20100428 Copyright 2000-2007,2008 Thomas >> E. Dickey This is free software; see the source for copying conditions. There > is NO >> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR >> PURPOSE. > I can't recall as I don't have the thread in front of me, but why was dialog(1) > replaced with cdialog? licensing? performance? > > I guess I could code my script to support this new dialog(1), but... can you see > if the below works (I removed the "--hline" option): > > dialog --clear --title foo --menu abc 17 55 9 1 a 2 b 3 c 4 d 5 e X x 2> > /tmp/dialog.menu.foo > > If that succeeds, then I can modify my script to not use `--hline' on RELENG_9 > and higher (referencing `sysctl -n kern.osreldate` for example). > > >> [...] >> >>> A menu should appear. Select an item and then execute for me: >>> >>> echo $? >>> >>> If the above doesn't work, then I suspect that your dialog(1) is not >>> working properly. I'd then go and try this as a sanity check: >>> >>> cd /usr/share/examples/dialog >> otaku% cd /usr/share/examples/dialog >> cd: no such file or directory: /usr/share/examples/dialog > Really? I would have thought that the examples in that directory (which are > merely shell scripts) would have been recoded for cdialog rather than altogether > removed. Maybe there was licensing issues there too. Was there? > > >>> sh menubox >>> echo $? >>> >>> The result in both cases (as long as you actually select a menu item) >>> should be "0". >>> >>> Also... (just as a sanity check for me) your /bin/sh is not a symlink >>> to bash is it? >> otaku% file /bin/sh >> /bin/sh: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically >> linked (uses shared libs), for FreeBSD 9.0 (900034), stripped > Cool. Though I'm still disappointed that my beloved dialog(1) has gone missing > (rather, replaced with something doesn't accept the same arguments and/or > options)(which is the problem that we're experiencing here). > > Is there anybody familiar with the changing-out dialog(1) that can bring me up > to speed with reasoning and specifics for RELENG_9? Also, might it be prudent -- > before cutting 9_0_RELEASE -- to add the fact that dialog(1) no longer accepts > `--hline' to the UPGRADING and/or ERRATA documents? It's almost entirely compatible, but I apologize for the breakage you experienced. The reasons it was replaced it were that it (a) has a better libdialog API, (b) has a better license (LGPL instead of GPL), (c) is maintained, and (d) supports 8-bit character sets. If there is some specific feature you are interested in (--hline for instance), I'd suggest writing to Thomas Dickey, the maintainer. -Nathan From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 23 04:58:37 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2B3B106566B for ; Sat, 23 Apr 2011 04:58:37 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 7B7E78FC08 for ; Sat, 23 Apr 2011 04:58:37 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p3N4wZvv055242 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 22 Apr 2011 21:58:36 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4DB25CAC.3090903@freebsd.org> Date: Fri, 22 Apr 2011 21:59:24 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Robert Lorentz References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-hackers@freebsd.org" Subject: Re: Looking for resources to get started X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2011 04:58:37 -0000 On 4/22/11 10:58 AM, Robert Lorentz wrote: > Hi, > > I'm very interested in getting started with FreeBSD development. My interests are wide but specifically core OS, performance, scheduling, cryptography, perhaps filesystems etc. > > I have seen the "Ideas" list and there is some good stuff there but those are fairly complex/large tasks. Where can I find something more basic to address to get myself familiar with the process of contributing? ok so the first things are: Find a way to get an updating image of the sources in your favourite SCM system, (svn, cvs, p4, git, hg) once you have that, get familiar with building kernels, booting new kernel images and how to recover when you screw it up.. that should take you a couple of weeks if you haven't already done so. then pick an area that interests you and just start playing with the code. Add printfs, learn to trace execution with gdb, dtrace, etc. Pretty soon you'll find something to fix, there are plenty of things to fix. Make a patch and submit it and get to know the procedure. Don't worry, things will LEAP out at you to be fixed :-) Get to know the people in the area you are playing with and discuss your changes and ideas with them. If you get too annoying by fixing too many things well they'll punish you by putting you up for your own commit privs. :-) This is not a company. No-one is going to assign you work.. do what you want. > My motivation for contributing is to learn more about the FreeBSD kernel and core OS and to put my skills toward FreeBSD which I find interesting and worthwhile. I am knowledgable in C, scheduling, data interface, somewhat also in cryptography > > Thanks, > > Robert_______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 23 07:55:01 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7140F106564A; Sat, 23 Apr 2011 07:55:01 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id E42078FC13; Sat, 23 Apr 2011 07:55:00 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 08746E6260; Sat, 23 Apr 2011 08:55:00 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=date:from :to:cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=mail; bh=yqqtLU4Z40Ha BZBkF1Yqmo9lTHU=; b=ppSuIbBas/khiFQXm+D0GpFjc7/F9ijsOPxbLiQotdSk xsNySnBI8aojeATwyi1qumgx0yizxC3UNVhdlUwXQ0c0w1wYJd2eGui8TmrQ3fUf SQzBDvr+4fCvLFMO5+nBTrvnBSRG9CDn/hmipUzwy55SkJOtz6LWFmekwwlsmiQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=date:from:to :cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; q=dns; s=mail; b=Pwj6QO FLm1vNv2H3gZ5D3o1TtWpaPuEBIkLvGkfNXWdJwNMfmcecDHNlroXl/1gdxFNCbj svoV7hJ3Iu3PWc82QpTxBAeU8eWC95qdGm8EqquHpQ91lnQRhGa/qX9B59g8yj4m pfCWCfGDSJKr+1S5aHu9JWIB9d0OSllOQuuKQ= Received: from unknown (188-222-18-231.zone13.bethere.co.uk [188.222.18.231]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id A3BC1E61AE; Sat, 23 Apr 2011 08:54:59 +0100 (BST) Date: Sat, 23 Apr 2011 08:54:51 +0100 From: Bruce Cran To: "Devin Teske" Message-ID: <20110423085451.00002c29@unknown> In-Reply-To: <039f01cc010d$b476d0f0$1d6472d0$@vicor.com> References: <02a701cc006a$887da210$9978e630$@vicor.com> <20110422145518.GA16734@freebsd.org> <20110422154146.GA26083@freebsd.org> <20110422173509.000077ba@unknown> <039f01cc010d$b476d0f0$1d6472d0$@vicor.com> X-Mailer: Claws Mail 3.7.8cvs9 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "'Teske, Devin'" , 'Alexander Best' , freebsd-questions@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: [UPDATE] host-setup(1): a dialog(1)-based utility for configuring FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2011 07:55:01 -0000 On Fri, 22 Apr 2011 09:52:44 -0700 "Devin Teske" wrote: > Looks like `--hline' is not supported anymore. Thinking this should > either be patched or documented in ERRATA/UPGRADING. I think you mean UPDATING :) -- Bruce Cran From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 23 12:04:47 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74FDF10656A9; Sat, 23 Apr 2011 12:04:47 +0000 (UTC) (envelope-from dickey@saltmine.radix.net) Received: from saltmine.radix.net (saltmine.radix.net [207.192.128.40]) by mx1.freebsd.org (Postfix) with ESMTP id 159338FC17; Sat, 23 Apr 2011 12:04:46 +0000 (UTC) Received: from saltmine.radix.net (localhost [127.0.0.1]) by saltmine.radix.net (8.12.2/8.12.2) with ESMTP id p3NBgxGf007488; Sat, 23 Apr 2011 07:43:09 -0400 (EDT) Received: (from dickey@localhost) by saltmine.radix.net (8.12.2/8.12.2/Submit) id p3NBgs9n007482; Sat, 23 Apr 2011 07:42:54 -0400 (EDT) Date: Sat, 23 Apr 2011 07:42:54 -0400 From: Thomas Dickey To: Bruce Cran Message-ID: <20110423114253.GA5836@saltmine.radix.net> References: <02a701cc006a$887da210$9978e630$@vicor.com> <20110422145518.GA16734@freebsd.org> <20110422154146.GA26083@freebsd.org> <20110422173509.000077ba@unknown> <039f01cc010d$b476d0f0$1d6472d0$@vicor.com> <20110423085451.00002c29@unknown> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0OAP2g/MAC+5xKAE" Content-Disposition: inline In-Reply-To: <20110423085451.00002c29@unknown> User-Agent: Mutt/1.3.27i X-Mailman-Approved-At: Sat, 23 Apr 2011 12:35:07 +0000 Cc: 'Alexander Best' , Devin Teske , "'Teske, Devin'" , freebsd-hackers@freebsd.org, freebsd-questions@freebsd.org Subject: Re: [UPDATE] host-setup(1): a dialog(1)-based utility for configuring FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2011 12:04:47 -0000 --0OAP2g/MAC+5xKAE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Apr 23, 2011 at 08:54:51AM +0100, Bruce Cran wrote: > On Fri, 22 Apr 2011 09:52:44 -0700 > "Devin Teske" wrote: >=20 > > Looks like `--hline' is not supported anymore. Thinking this should > > either be patched or documented in ERRATA/UPGRADING. >=20 > I think you mean UPDATING :) perhaps. But reporting bugs is nicer than long discussion threads. --=20 Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net --0OAP2g/MAC+5xKAE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (SunOS) Comment: For info see http://www.gnupg.org iD8DBQFNsrf7tIqByHxlDocRAq3vAJsFeADdkVVwiliZ4tPErRvB78PBXwCgkv3c uPdk5b2Ye6Xm4Q65ohoO+Lk= =tRH6 -----END PGP SIGNATURE----- --0OAP2g/MAC+5xKAE-- From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 23 18:23:51 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A566B106564A for ; Sat, 23 Apr 2011 18:23:51 +0000 (UTC) (envelope-from lankfordandrew@charter.net) Received: from que21.charter.net (que21.charter.net [209.225.8.22]) by mx1.freebsd.org (Postfix) with ESMTP id F31C48FC08 for ; Sat, 23 Apr 2011 18:23:50 +0000 (UTC) Received: from imp10 ([10.20.200.15]) by mta21.charter.net (InterMail vM.7.09.02.04 201-2219-117-106-20090629) with ESMTP id <20110423180218.FWWY11595.mta21.charter.net@imp10> for ; Sat, 23 Apr 2011 14:02:18 -0400 Received: from [192.168.1.110] ([75.138.215.209]) by imp10 with smtp.charter.net id b62J1g0094XeuP70562JtL; Sat, 23 Apr 2011 14:02:18 -0400 X-Authority-Analysis: v=1.1 cv=67PPgUc0CtgM8E27DXTM5SVmNQEiZYYnqhTvr1M71DI= c=1 sm=1 a=Vf9Zk9rDW_cA:10 a=yUnIBFQkZM0A:10 a=XrFk8IW1Pep/MeV13so3Wg==:17 a=mm42jZN0RS8BPFkFUt8A:9 a=QEXdDO2ut3YA:10 a=-YY1akn8NftsE5Y1aEsA:9 a=zbgr6P8ScK3G2UTGUsYA:7 a=XrFk8IW1Pep/MeV13so3Wg==:117 Message-ID: <4DB3142A.4000807@charter.net> Date: Sat, 23 Apr 2011 14:02:18 -0400 From: Andrew Lankford User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.16) Gecko/20101210 Thunderbird/3.0.11 MIME-Version: 1.0 To: hackers@freebsd.org X-Mailman-Approved-At: Sat, 23 Apr 2011 18:50:14 +0000 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: scd and mcd X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2011 18:23:51 -0000 While we're talking about recent MFC's for SATA hardware (works for me, but I still need the old ata drivers for my cdrom), is anyone out there really still using the mcd (fbsd 1.0 vintage) and scd (2.0.5) drivers? From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 23 21:46:28 2011 Return-Path: Delivered-To: hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D12C106564A for ; Sat, 23 Apr 2011 21:46:28 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 07FF18FC15 for ; Sat, 23 Apr 2011 21:46:27 +0000 (UTC) Received: from [10.0.0.63] (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p3NLgDMA005437 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Sat, 23 Apr 2011 15:42:15 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <4DB3142A.4000807@charter.net> Date: Sat, 23 Apr 2011 15:42:12 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <1E3F5B85-5A1A-4118-A9D8-932F46619C79@bsdimp.com> References: <4DB3142A.4000807@charter.net> To: Andrew Lankford X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Sat, 23 Apr 2011 15:42:15 -0600 (MDT) Cc: hackers@FreeBSD.ORG Subject: Re: scd and mcd X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2011 21:46:28 -0000 On Apr 23, 2011, at 12:02 PM, Andrew Lankford wrote: > While we're talking about recent MFC's for SATA hardware (works for = me, but I still need the old ata drivers for my cdrom), is anyone out = there really still using the mcd (fbsd 1.0 vintage) and scd (2.0.5) = drivers? mcd and scd are ISA-only devices. ISA expansion bus only. ISA slots = disappeared off Mobos about 4 years ago entirely. PATA/IDE connectors = have been built into mobos for the past 15ish years. They were = important for the 386 (now not supported) and 486 machines. Since the = 486 machines in question maxed out at 32MB, and 8.x has trouble running = in 32MB on x86, I'm guessing there aren't too many 486 SX/DX machines = running 8.x. Therefore, I'd bet money that neither mcd nor scd have attached on any = machine running 8.x :) Warner From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 23 23:25:10 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45F491065679 for ; Sat, 23 Apr 2011 23:25:10 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id 1EAAB8FC16 for ; Sat, 23 Apr 2011 23:25:10 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id p3NNP4ho010668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 23 Apr 2011 16:25:05 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id p3NNP4T2010667; Sat, 23 Apr 2011 16:25:04 -0700 (PDT) Received: from fbsd61 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA14915; Sat, 23 Apr 11 16:20:44 PDT Date: Sat, 23 Apr 2011 16:19:38 -0700 From: perryh@pluto.rain.com To: imp@bsdimp.com Message-Id: <4db35e8a.R5LDMfg8cygIRbfF%perryh@pluto.rain.com> References: <4DB3142A.4000807@charter.net> <1E3F5B85-5A1A-4118-A9D8-932F46619C79@bsdimp.com> In-Reply-To: <1E3F5B85-5A1A-4118-A9D8-932F46619C79@bsdimp.com> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: lankfordandrew@charter.net, hackers@freebsd.org Subject: Re: scd and mcd X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2011 23:25:10 -0000 Warner Losh wrote: > mcd and scd are ISA-only devices ... They were important for the > 386 (now not supported) and 486 machines. Since the 486 machines > in question maxed out at 32MB, and 8.x has trouble running in 32MB > on x86, I'm guessing there aren't too many 486 SX/DX machines > running 8.x. 486 were the last for which ISA was the primary bus, but ISA was still present (bridged from PCI) on most Pentium systems and common at least as recently as Pentium-II. (I don't have a disassembled P-III handy to check whether it has an ISA slot.) From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 23 23:42:27 2011 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF93A1065674 for ; Sat, 23 Apr 2011 23:42:27 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 58A448FC14 for ; Sat, 23 Apr 2011 23:42:27 +0000 (UTC) Received: from [10.0.0.63] (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p3NNbvwt006040 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Sat, 23 Apr 2011 17:37:59 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) From: Warner Losh In-Reply-To: <4db35e8a.R5LDMfg8cygIRbfF%perryh@pluto.rain.com> Date: Sat, 23 Apr 2011 17:37:57 -0600 Message-Id: References: <4DB3142A.4000807@charter.net> <1E3F5B85-5A1A-4118-A9D8-932F46619C79@bsdimp.com> <4db35e8a.R5LDMfg8cygIRbfF%perryh@pluto.rain.com> To: perryh@pluto.rain.com X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Sat, 23 Apr 2011 17:37:59 -0600 (MDT) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: lankfordandrew@charter.net, hackers@FreeBSD.org Subject: Re: scd and mcd X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2011 23:42:28 -0000 On Apr 23, 2011, at 5:19 PM, perryh@pluto.rain.com wrote: > Warner Losh wrote: >=20 >> mcd and scd are ISA-only devices ... They were important for the >> 386 (now not supported) and 486 machines. Since the 486 machines >> in question maxed out at 32MB, and 8.x has trouble running in 32MB >> on x86, I'm guessing there aren't too many 486 SX/DX machines >> running 8.x. >=20 > 486 were the last for which ISA was the primary bus, but ISA was > still present (bridged from PCI) on most Pentium systems and common > at least as recently as Pentium-II. (I don't have a disassembled > P-III handy to check whether it has an ISA slot.) Most Pentium II and newer systems had IDE connectors on the motherboard. = Many of the Pentium I ones did too. Only if you didn't have IDE = connectors on mobo would you be likely to consider one of these CD's. = Also, I think they topped out at 4x or 8x speed since they had a custom = interface. Warner