From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 10 05:08: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 751D6106566C; Sun, 10 Jul 2011 05:08:08 +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 2679C8FC13; Sun, 10 Jul 2011 05:08:08 +0000 (UTC) Received: from 63.imp.bsdimp.com (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p6A56T6C012132 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Sat, 9 Jul 2011 23:06:29 -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: <20110705201214.GA31647@sandvine.com> Date: Sat, 9 Jul 2011 23:06:28 -0600 Content-Transfer-Encoding: 7bit Message-Id: <005E93BB-0DD4-495A-80E1-E6263C04EB17@bsdimp.com> References: <20110702193724.5c55a6c9@kan.dnsalias.net> <20110703020827.GA5763@sandvine.com> <20110703103531.4a553271@kan.dnsalias.net> <20110705140527.17362ed5@kan.dnsalias.net> <20110705201214.GA31647@sandvine.com> To: Ed Maste 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, 09 Jul 2011 23:06:30 -0600 (MDT) Cc: freebsd-hackers@FreeBSD.org, Robert Millan Subject: Re: [PATCH] __FreeBSD_kernel__ 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, 10 Jul 2011 05:08:08 -0000 I know this is a little late, but... On Jul 5, 2011, at 2:12 PM, Ed Maste wrote: > On Tue, Jul 05, 2011 at 02:05:27PM -0400, Alexander Kabaev wrote: > >> I agree with all of the above reasons, but none of them change the fact >> that __linux__ is used left and right to identify both kernel and >> userland environments just as __FreeBSD__ is. You choose to disable >> __FreeBSD__ in GNU/kFreeBSD presumably because it makes your life >> porting software easier and are asking FreeBSD project to cope with >> the decision. This breaks compiles of new software with older >> compilers than do not define the macro, takes __FreeBSD__ out of >> symmetry with __linux__ and other similarly defined platform macros >> and forces a race to update every other compiler out there to follow >> the suit. I fail to see the benefits out-weighting the drawbacks in >> this scenario. > > There are two separate issues here - the macro itself, and where it's > defined. > > On the topic of the macro itself, __FreeBSD__ implies something about > the kernel and the libc, and it used to be the same case for __linux__. > This became broken for __linux__ once people started combining a Linux > kernel with other than glibc, and it would break if those combining > the FreeBSD kernel with another libc defined __FreeBSD__. > > (A note on terminology - some may dislike the "GNU/" name for various > reasons, but either way their project is properly called "Debian > GNU/kFreeBSD." I'll refer to it as "kFreeBSD" here for brevity though, > since the kFreeBSD part is the unique aspect of this project vs other > Debian ports, and the full name is rather awkward to type.) > > kFreeBSD can't define __FreeBSD__, since it will break any existing > software that uses that to infer something about the libc in use. So, > that project had a choice; they could have created a new macro > __Debian_GNU_kFreeBSD__, say, that indicates the kernel and libc in use. > However, defining __FreeBSD_kernel__ (and __glibc__ presumably) makes > more sense, and actually reduces the porting effort for both them and > the FreeBSD porters. Any effort on porting software to the FreeBSD > kernel done by either project is then applicable to the other. If > kFreeBSD project members make a change to get some piece of software > working on a FreeBSD kernel and then gets that change commited upstream > we can take advantage of that work without any additional effort on our > part. I think we should define this. > On the topic of where such a macro should be defined I originally had > no strong opinion. However, valid points have been raised about > compiling software for FreeBSD using compilers that are not the one in > the base system (from ports or otherwise, and GCC or otherwise). This > I think is a very valid point and one that would make me lean towards > defining the macro in sys/param.h. How workable is it to #include > sys/param.h to pick up the macro where needed? Why can't the other compilers conform to the new standard instead? Warner From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 10 05:19:41 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 7550C1065670; Sun, 10 Jul 2011 05:19:41 +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 3248B8FC13; Sun, 10 Jul 2011 05:19:41 +0000 (UTC) Received: from 63.imp.bsdimp.com (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p6A5HNgs012206 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Sat, 9 Jul 2011 23:17:23 -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: Date: Sat, 9 Jul 2011 23:17:22 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E12E358.80002@FreeBSD.org> To: Robert Millan 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, 09 Jul 2011 23:17:23 -0600 (MDT) Cc: freebsd-hackers@FreeBSD.org, Dimitry Andric , Ed Maste Subject: Re: [PATCH] __FreeBSD_cc_version in 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, 10 Jul 2011 05:19:41 -0000 On Jul 5, 2011, at 7:36 AM, Robert Millan wrote: > 2011/7/5 Dimitry Andric : >> As far as I can see, this code only gives warnings when compiled with >> gcc 4.5 or higher, and when using the -Wundef flag. Isn't it easier = to >> just remove the -Wundef flag here? >=20 > Here's a patch to remove -Wundef. I think it's a bad idea however, > IMHO it's better to fix the cause of the warning instead. I think it is a better idea to fix the warning too. I liked your first = patch better. Warner From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 10 05:24:43 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 293F9106564A for ; Sun, 10 Jul 2011 05:24:43 +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 777098FC12 for ; Sun, 10 Jul 2011 05:24:42 +0000 (UTC) Received: from 63.imp.bsdimp.com (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p6A5JQUk012211 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Sat, 9 Jul 2011 23:19:27 -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: Date: Sat, 9 Jul 2011 23:19:23 -0600 Content-Transfer-Encoding: 7bit Message-Id: <55627D64-E412-4D04-AA17-3D912EEE6589@bsdimp.com> References: <4E11ECE2.9050402@freebsd.org> To: grarpamp 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, 09 Jul 2011 23:19:27 -0600 (MDT) Cc: freebsd-hackers@FreeBSD.org Subject: Re: Jails: Setting different times in jails 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, 10 Jul 2011 05:24:43 -0000 Why on earth would you want this? Warner On Jul 7, 2011, at 2:31 AM, grarpamp wrote: >> possibly achievable in libc? > > I don't know. Where else would it be done? > stat, utimes, gettimeofday, clock_gettime, > adjtime, etc and their variations. > > I've not checked what currently happens, but I > don't think root in a jail should be able to set > any kernel time parameters, absent a syscall > that says it should. > >> in any case file this idea somewhere.. :-) > > Don't know here either. I looked at the lists and > hackers seemed closest. I'll bcc current. Someone > could maybe todo-wiki this thread as low hanging > fruit. Cheers. > _______________________________________________ > 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 Sun Jul 10 14:31:52 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 C95AB106564A; Sun, 10 Jul 2011 14:31:52 +0000 (UTC) (envelope-from rmh.aybabtu@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 878C48FC08; Sun, 10 Jul 2011 14:31:52 +0000 (UTC) Received: by iyb11 with SMTP id 11so3875883iyb.13 for ; Sun, 10 Jul 2011 07:31:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=sU32VB5TaGCvrqK+fTOdGLHTg/huCm1AKh7KZ/7xQrM=; b=aVWRk642PWw/jWkf05LZA0kcRnenfJaX9SGeZyaisZsfsZyUUOpGMfUjbwfNwg3M2W QoIhOmd3SeEpbx1nN8lNRZ1vrprCYa6qMbYKWoc7e9n4zVirMuWNXPSDIV2/RBja9ufy ISPzlho1agzGJfUUYDnuLSBISB4sOJiEg1/co= MIME-Version: 1.0 Received: by 10.42.8.212 with SMTP id j20mr3580090icj.287.1310308311702; Sun, 10 Jul 2011 07:31:51 -0700 (PDT) Sender: rmh.aybabtu@gmail.com Received: by 10.42.229.3 with HTTP; Sun, 10 Jul 2011 07:31:51 -0700 (PDT) Date: Sun, 10 Jul 2011 16:31:51 +0200 X-Google-Sender-Auth: CMysUIOk6KkLaEtblWvQy_0QYhw Message-ID: From: Robert Millan To: freebsd-hackers@freebsd.org, Ed Maste Content-Type: multipart/mixed; boundary=005045015b5e771b4504a7b7ed91 Cc: Subject: [PATCH] Improve utf-8 -> cp437 console map 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, 10 Jul 2011 14:31:53 -0000 --005045015b5e771b4504a7b7ed91 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This patch adds a few improvements to utf-8 -> cp436 console map (mostly with Catalan characters in mind, but it probably benefits other languages). The new mappings are as follows: =E2=96=AE -> =E2=96=88 =C3=80=C3=88=C3=8D=C3=8F=C3=93=C3=92=C3=9A -> AEIIOOU =C5=80 / =C4=BF -> l / L --=20 Robert Millan --005045015b5e771b4504a7b7ed91 Content-Type: text/plain; charset=US-ASCII; name="108_teken_utf8_table.diff" Content-Disposition: attachment; filename="108_teken_utf8_table.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gpy3q9n40 LS0tIGEvc3lzL2Rldi9zeXNjb25zL3NjdGVybS10ZWtlbi5jCisrKyBiL3N5cy9kZXYvc3lzY29u cy9zY3Rlcm0tdGVrZW4uYwpAQCAtNDI0LDEwICs0MjQsMTggQEAKIAl7IDB4MDBiNiwgMHgxNCwg MHgwMCB9LCB7IDB4MDBiNywgMHhmYSwgMHgwMCB9LAogCXsgMHgwMGJhLCAweGE3LCAweDAwIH0s IHsgMHgwMGJiLCAweGFmLCAweDAwIH0sCiAJeyAweDAwYmMsIDB4YWMsIDB4MDAgfSwgeyAweDAw YmQsIDB4YWIsIDB4MDAgfSwKLQl7IDB4MDBiZiwgMHhhOCwgMHgwMCB9LCB7IDB4MDBjNCwgMHg4 ZSwgMHgwMSB9LAotCXsgMHgwMGM2LCAweDkyLCAweDAwIH0sIHsgMHgwMGM3LCAweDgwLCAweDAw IH0sCi0JeyAweDAwYzksIDB4OTAsIDB4MDAgfSwgeyAweDAwZDEsIDB4YTUsIDB4MDAgfSwKLQl7 IDB4MDBkNiwgMHg5OSwgMHgwMCB9LCB7IDB4MDBkYywgMHg5YSwgMHgwMCB9LAorCXsgMHgwMGJm LCAweGE4LCAweDAwIH0sIHsgMHgwMGMwLCAweDQxLCAweDAwIH0sCisJeyAweDAwYzEsIDB4NDEs IDB4MDAgfSwgeyAweDAwYzIsIDB4NDEsIDB4MDAgfSwKKwl7IDB4MDBjNCwgMHg4ZSwgMHgwMSB9 LCB7IDB4MDBjNiwgMHg5MiwgMHgwMCB9LCAKKwl7IDB4MDBjNywgMHg4MCwgMHgwMCB9LCB7IDB4 MDBjOCwgMHg0NSwgMHgwMCB9LAorCXsgMHgwMGM5LCAweDkwLCAweDAwIH0sIHsgMHgwMGNhLCAw eDQ1LCAweDAwIH0sCisJeyAweDAwY2IsIDB4NDUsIDB4MDAgfSwgeyAweDAwY2MsIDB4NDksIDB4 MDAgfSwKKwl7IDB4MDBjZCwgMHg0OSwgMHgwMCB9LCB7IDB4MDBjZSwgMHg0OSwgMHgwMCB9LAor CXsgMHgwMGNmLCAweDQ5LCAweDAwIH0sIHsgMHgwMGQxLCAweGE1LCAweDAwIH0sCisJeyAweDAw ZDIsIDB4NGYsIDB4MDAgfSwgeyAweDAwZDMsIDB4NGYsIDB4MDAgfSwKKwl7IDB4MDBkNCwgMHg0 ZiwgMHgwMCB9LCB7IDB4MDBkNiwgMHg5OSwgMHgwMCB9LCAKKwl7IDB4MDBkOSwgMHg1NSwgMHgw MCB9LCB7IDB4MDBkYSwgMHg1NSwgMHgwMCB9LAorCXsgMHgwMGRiLCAweDU1LCAweDAwIH0sIHsg MHgwMGRjLCAweDlhLCAweDAwIH0sCiAJeyAweDAwZGYsIDB4ZTEsIDB4MDAgfSwgeyAweDAwZTAs IDB4ODUsIDB4MDAgfSwKIAl7IDB4MDBlMSwgMHhhMCwgMHgwMCB9LCB7IDB4MDBlMiwgMHg4Mywg MHgwMCB9LAogCXsgMHgwMGU0LCAweDg0LCAweDAwIH0sIHsgMHgwMGU1LCAweDg2LCAweDAwIH0s CkBAIC00NDIsNiArNDUwLDcgQEAKIAl7IDB4MDBmOCwgMHhlZCwgMHgwMCB9LCB7IDB4MDBmOSwg MHg5NywgMHgwMCB9LAogCXsgMHgwMGZhLCAweGEzLCAweDAwIH0sIHsgMHgwMGZiLCAweDk2LCAw eDAwIH0sCiAJeyAweDAwZmMsIDB4ODEsIDB4MDAgfSwgeyAweDAwZmYsIDB4OTgsIDB4MDAgfSwK Kwl7IDB4MDEzZiwgMHg0YywgMHgwMCB9LCB7IDB4MDE0MCwgMHg2YywgMHgwMCB9LAogCXsgMHgw MTkyLCAweDlmLCAweDAwIH0sIHsgMHgwMzkzLCAweGUyLCAweDAwIH0sCiAJeyAweDAzOTgsIDB4 ZTksIDB4MDAgfSwgeyAweDAzYTMsIDB4ZTQsIDB4MDAgfSwKIAl7IDB4MDNhNiwgMHhlOCwgMHgw MCB9LCB7IDB4MDNhOSwgMHhlYSwgMHgwMCB9LApAQCAtNDkwLDcgKzQ5OSw4IEBACiAJeyAweDI1 ODQsIDB4ZGMsIDB4MDAgfSwgeyAweDI1ODgsIDB4ZGIsIDB4MDAgfSwKIAl7IDB4MjU4YywgMHhk ZCwgMHgwMCB9LCB7IDB4MjU5MCwgMHhkZSwgMHgwMCB9LAogCXsgMHgyNTkxLCAweGIwLCAweDAy IH0sIHsgMHgyNWEwLCAweGZlLCAweDAwIH0sCi0JeyAweDI1YWMsIDB4MTYsIDB4MDAgfSwgeyAw eDI1YjIsIDB4MWUsIDB4MDAgfSwKKwl7IDB4MjVhYywgMHgxNiwgMHgwMCB9LCAKKwl7IDB4MjVh ZSwgMHhkYiwgMHgwMCB9LCB7IDB4MjViMiwgMHgxZSwgMHgwMCB9LAogCXsgMHgyNWJhLCAweDEw LCAweDAwIH0sIHsgMHgyNWJjLCAweDFmLCAweDAwIH0sCiAJeyAweDI1YzQsIDB4MTEsIDB4MDAg fSwgeyAweDI1Y2IsIDB4MDksIDB4MDAgfSwKIAl7IDB4MjVkOCwgMHgwOCwgMHgwMCB9LCB7IDB4 MjVkOSwgMHgwYSwgMHgwMCB9LAo= --005045015b5e771b4504a7b7ed91-- From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 10 16:56: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 02360106566C for ; Sun, 10 Jul 2011 16:56:09 +0000 (UTC) (envelope-from lidl@hydra.pix.net) Received: from hydra.pix.net (hydra.pix.net [71.241.230.60]) by mx1.freebsd.org (Postfix) with ESMTP id B1FDC8FC12 for ; Sun, 10 Jul 2011 16:56:08 +0000 (UTC) Received: from hydra.pix.net (localhost [127.0.0.1]) by hydra.pix.net (8.14.4/8.14.4) with ESMTP id p6AGgsoE050872; Sun, 10 Jul 2011 12:42:54 -0400 (EDT) (envelope-from lidl@hydra.pix.net) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97 at mail.pix.net Received: (from lidl@localhost) by hydra.pix.net (8.14.4/8.14.4/Submit) id p6AGgqFl050871; Sun, 10 Jul 2011 12:42:52 -0400 (EDT) (envelope-from lidl) Date: Sun, 10 Jul 2011 12:42:52 -0400 From: Kurt Lidl To: Warner Losh Message-ID: <20110710164252.GA50703@pix.net> References: <4E11ECE2.9050402@freebsd.org> <55627D64-E412-4D04-AA17-3D912EEE6589@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55627D64-E412-4D04-AA17-3D912EEE6589@bsdimp.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org, grarpamp Subject: Re: Jails: Setting different times in jails 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, 10 Jul 2011 16:56:09 -0000 On Sat, Jul 09, 2011 at 11:19:23PM -0600, Warner Losh wrote: > Why on earth would you want this? Oh, it's not hard to imagine why you want to do this. Say you're testing a particular date rollover event, and want to make sure your software is up to snuff. Doing it in a jail would make it easy to do it. I hacked over a unix kernel to do this for Y2K testing, along with the company's mandatory 9/9/99 testing (and we extended it through to 1-Mar-2000 just to be thorough). In that case, not only did I just start the systems with a clock value of 9/8/99, I hacked it so the time was incremented by one second at each hardclock, rather than 1/100 of a second. So my applications saw every second of every "day" between 9/8/99 and 3/1/00. (Remember that 28-Feb-2000 went straight through to 1-Mar-2000 -- 2000 was NOT a leap year!) Heck, maybe if this got put in, Apple would pick it up and finally make the calandering stuff in OS X not fail every daylight savings time. Nah, I'm just dreaming now... -Kurt > On Jul 7, 2011, at 2:31 AM, grarpamp wrote: > > >> possibly achievable in libc? > > > > I don't know. Where else would it be done? > > stat, utimes, gettimeofday, clock_gettime, > > adjtime, etc and their variations. > > > > I've not checked what currently happens, but I > > don't think root in a jail should be able to set > > any kernel time parameters, absent a syscall > > that says it should. > > > >> in any case file this idea somewhere.. :-) > > > > Don't know here either. I looked at the lists and > > hackers seemed closest. I'll bcc current. Someone > > could maybe todo-wiki this thread as low hanging > > fruit. Cheers. > > _______________________________________________ > > 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" > > > > > > _______________________________________________ > 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 Mon Jul 11 10:54: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 674AD1065740; Mon, 11 Jul 2011 10:54:07 +0000 (UTC) (envelope-from rmh.aybabtu@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 259308FC1B; Mon, 11 Jul 2011 10:54:06 +0000 (UTC) Received: by iyb11 with SMTP id 11so4562225iyb.13 for ; Mon, 11 Jul 2011 03:54:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=tHwpvbh4R9tD/EpX1L79QYDQf/SJ7Epk+Fi7QL53vJs=; b=ROr9192dfWZodvJ1oUAT5wgKdmAHQSuXybvjz3S1V/zL8jAynRRE3G/GBS/ToiGjh0 +JBmsyDoeYOROD5DzWG+qvnuJcFm+M/mDNi6B+R3pMVh0/WTjIbK8Hr2C218czQ0pCeh yJL0PmDWmFjR6nfndCd/9e4QRDeZt9EaKS4ps= MIME-Version: 1.0 Received: by 10.42.172.133 with SMTP id n5mr5006128icz.421.1310381646353; Mon, 11 Jul 2011 03:54:06 -0700 (PDT) Sender: rmh.aybabtu@gmail.com Received: by 10.42.229.3 with HTTP; Mon, 11 Jul 2011 03:54:06 -0700 (PDT) Date: Mon, 11 Jul 2011 12:54:06 +0200 X-Google-Sender-Auth: VE9rF022u_f1xKvioQ_D-xqMPbQ Message-ID: From: Robert Millan To: freebsd-hackers@freebsd.org, Ed Maste Content-Type: multipart/mixed; boundary=90e6ba6e87fa8d13b704a7c900b0 Cc: Petr Salinger Subject: [PATCH] Improve LinuxThreads compatibility in rfork() 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, 11 Jul 2011 10:54:07 -0000 --90e6ba6e87fa8d13b704a7c900b0 Content-Type: text/plain; charset=UTF-8 This patch made by Petr Salinger improves compatibility with LinuxThreads in rfork() syscall. The Linux clone() implementation allows specifying the signal sent to parent when child terminates (instead of SIGCHLD). As the threading implementation in Debian GNU/kFreeBSD is LinuxThreads-based, we had to diverge from upstream kFreeBSD ABI and implement this extension. I hope it is acceptable for you to use the same encoding, this way we would archieve ABI compatibility to run Debian GNU/kFreeBSD inside a chroot/jail on top of a FreeBSD system. Thanks for considering -- Robert Millan --90e6ba6e87fa8d13b704a7c900b0 Content-Type: text/plain; charset=US-ASCII; name="007_clone_signals.diff" Content-Disposition: attachment; filename="007_clone_signals.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gpzbdpww0 LS0tIGEvc3lzL2tlcm4va2Vybl9mb3JrLmMKKysrIGIvc3lzL2tlcm4va2Vybl9mb3JrLmMKQEAg LTQ3Nyw3ICs0NzcsMTMgQEAKIAkJcDItPnBfc2lnYWN0cyA9IG5ld3NpZ2FjdHM7CiAJfQogCWlm IChmbGFncyAmIFJGTElOVVhUSFBOKSAKLQkgICAgICAgIHAyLT5wX3NpZ3BhcmVudCA9IFNJR1VT UjE7CisJeworCQlpbnQgc2lnOworCQlzaWcgPSBSRlRIUE5TSUdOVU0oZmxhZ3MpOworCSAgICAg ICAgaWYgKHNpZyA9PSAwKSBzaWcgPSBTSUdVU1IxOworCSAgICAgICAgaWYgKHNpZyA9PSBTSUdD SExEKSBzaWcgPSAwOworCSAgICAgICAgcDItPnBfc2lncGFyZW50ID0gc2lnOworCX0KIAllbHNl CiAJICAgICAgICBwMi0+cF9zaWdwYXJlbnQgPSBTSUdDSExEOwogCi0tLSBhL3N5cy9zeXMvdW5p c3RkLmgKKysrIGIvc3lzL3N5cy91bmlzdGQuaApAQCAtMTgyLDYgKzE4MiwxMCBAQAogI2RlZmlu ZQlSRkhJR0hQSUQJKDE8PDE4KQkvKiB1c2UgYSBwaWQgaGlnaGVyIHRoYW4gMTAgKGlkbGVwcm9j KSAqLwogI2RlZmluZQlSRlBQV0FJVAkoMTw8MzEpCS8qIHBhcmVudCBzbGVlcHMgdW50aWwgY2hp bGQgZXhpdHMgKHZmb3JrKSAqLwogI2RlZmluZQlSRktFUk5FTE9OTFkJKFJGU1RPUFBFRCB8IFJG SElHSFBJRCB8IFJGUFBXQUlUKQorI2RlZmluZSBSRlRIUE5TSElGVAkyNAkvKiByZXNlcnZlIGJp dHMgMjQtMzAgKi8KKyNkZWZpbmUgUkZUSFBOTUFTSwkweDdGICAgIC8qIGZvciBjb21wYXRpYmls aXR5IHdpdGggbGludXh0aHJlYWRzL2Nsb25lKCkgICAqLworCQkJCS8qIGFsbG93IHRvIHNwZWNp ZnkgICJjbG9uZSBleGl0IHBhcmVudCBub3RpZmljYXRpb24iIHNpZ25hbCAqLworI2RlZmluZSBS RlRIUE5TSUdOVU0oZmxhZ3MpCSgoKGZsYWdzKSA+PiBSRlRIUE5TSElGVCkgJiBSRlRIUE5NQVNL KQogCiAjZW5kaWYgLyogX19CU0RfVklTSUJMRSAqLwogCg== --90e6ba6e87fa8d13b704a7c900b0-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 11 12:08:06 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 53231106566B; Mon, 11 Jul 2011 12:08:06 +0000 (UTC) (envelope-from webmaster@kibab.com) Received: from mx0.deglitch.com (cl-414.sto-01.se.sixxs.net [IPv6:2001:16d8:ff00:19d::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0488E8FC12; Mon, 11 Jul 2011 12:08:06 +0000 (UTC) Received: from zugang.kibab.com (unknown [78.110.54.255]) by mx0.deglitch.com (Postfix) with ESMTPA id 435EB8FC2E; Mon, 11 Jul 2011 16:08:00 +0400 (MSD) Received: from 139.149.1.231 (SquirrelMail authenticated user kibab) by zugang.kibab.com with HTTP; Mon, 11 Jul 2011 16:08:01 +0400 Message-ID: In-Reply-To: <4E18D88B.4060805@FreeBSD.org> References: <4E167C94.70300@kibab.com> <4E186B89.8080003@FreeBSD.org> <4E18D88B.4060805@FreeBSD.org> Date: Mon, 11 Jul 2011 16:08:01 +0400 From: "Ilya Bakulin" To: "Doug Barton" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-hackers@freebsd.org Subject: Re: Capsicum project: Ideas needed 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, 11 Jul 2011 12:08:06 -0000 chroot constraints only filesystem namespace, but doesn't prevent process from sending/receiving data via network, or from accessing other global namespaces such as PID namespace, SHM namespace, and from executing any system calls. In contract to chroot, Capsicum framework significantly increases application security by restricting access to all mentioned namespaces. More information about Capsicum, its design and goals is available here: http://www.cl.cam.ac.uk/research/security/capsicum/papers/2010usenix-security-capsicum-website.pdf On Sun, July 10, 2011 2:39 am, Doug Barton wrote: > On 07/09/2011 07:54, Gabor Kovesdan wrote: >> Anyway, consider sendmail and BIND. I think these are important enough >> to get some more protection. > > What additional protection could capsicum offer beyond chroot'ing? > (That's not a snark, I don't quite understand all the moving parts here.) > > > 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/ > > _______________________________________________ > 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" > > !DSPAM:4e18d8b510435369347983! > > > -- Regards, Ilya Bakulin http://kibab.com xmpp://kibab612@jabber.ru From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 11 12:33:41 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 3222F106566C; Mon, 11 Jul 2011 12:33:41 +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 A26548FC12; Mon, 11 Jul 2011 12:33:40 +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 p6BCXW6a081246 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Jul 2011 15:33:32 +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 p6BCXWN9051722; Mon, 11 Jul 2011 15:33:32 +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 p6BCXWUN051721; Mon, 11 Jul 2011 15:33:32 +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: Mon, 11 Jul 2011 15:33:32 +0300 From: Kostik Belousov To: Robert Millan Message-ID: <20110711123332.GS43872@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0lx/R+CYDdR/AN/7" Content-Disposition: inline In-Reply-To: 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.3 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, Ed Maste , Petr Salinger Subject: Re: [PATCH] Improve LinuxThreads compatibility in rfork() 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, 11 Jul 2011 12:33:41 -0000 --0lx/R+CYDdR/AN/7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 11, 2011 at 12:54:06PM +0200, Robert Millan wrote: > This patch made by Petr Salinger improves compatibility with > LinuxThreads in rfork() syscall. The Linux clone() implementation > allows specifying the signal sent to parent when child terminates > (instead of SIGCHLD). >=20 > As the threading implementation in Debian GNU/kFreeBSD is > LinuxThreads-based, we had to diverge from upstream kFreeBSD ABI and > implement this extension. >=20 > I hope it is acceptable for you to use the same encoding, this way we > would archieve ABI compatibility to run Debian GNU/kFreeBSD inside a > chroot/jail on top of a FreeBSD system. >=20 > Thanks for considering >=20 > --=20 > Robert Millan > --- a/sys/kern/kern_fork.c > +++ b/sys/kern/kern_fork.c > @@ -477,7 +477,13 @@ > p2->p_sigacts =3D newsigacts; > } > if (flags & RFLINUXTHPN)=20 > - p2->p_sigparent =3D SIGUSR1; > + { > + int sig; > + sig =3D RFTHPNSIGNUM(flags); > + if (sig =3D=3D 0) sig =3D SIGUSR1; > + if (sig =3D=3D SIGCHLD) sig =3D 0; > + p2->p_sigparent =3D sig; > + } > else > p2->p_sigparent =3D SIGCHLD; > =20 > --- a/sys/sys/unistd.h > +++ b/sys/sys/unistd.h > @@ -182,6 +182,10 @@ > #define RFHIGHPID (1<<18) /* use a pid higher than 10 (idleproc) */ > #define RFPPWAIT (1<<31) /* parent sleeps until child exits (vfork) */ > #define RFKERNELONLY (RFSTOPPED | RFHIGHPID | RFPPWAIT) > +#define RFTHPNSHIFT 24 /* reserve bits 24-30 */ > +#define RFTHPNMASK 0x7F /* for compatibility with linuxthreads/clone(= ) */ > + /* allow to specify "clone exit parent notification" signal */ > +#define RFTHPNSIGNUM(flags) (((flags) >> RFTHPNSHIFT) & RFTHPNMASK) > =20 > #endif /* __BSD_VISIBLE */ > =20 I looked at this patch some time ago already. Can you, please, describe the reasoning behind the > + if (sig =3D=3D SIGCHLD) sig =3D 0; line ? --0lx/R+CYDdR/AN/7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk4a7ZsACgkQC3+MBN1Mb4jHtQCdFtXxd7IPd2EOHy8m69ikcFjU MJsAoLdgwXH65XU7DLUUsMGGTOL+AwcF =Bltg -----END PGP SIGNATURE----- --0lx/R+CYDdR/AN/7-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 11 12:43:23 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 7BAB21065677; Mon, 11 Jul 2011 12:43:23 +0000 (UTC) (envelope-from edwin@mavetju.org) Received: from mail4out.barnet.com.au (mail4out.barnet.com.au [202.83.178.123]) by mx1.freebsd.org (Postfix) with ESMTP id 379B38FC0C; Mon, 11 Jul 2011 12:43:22 +0000 (UTC) Received: by mail4out.barnet.com.au (Postfix, from userid 1001) id A172837B996; Mon, 11 Jul 2011 22:24:37 +1000 (EST) X-Viruscan-Id: <4E1AEB850000CCCB790355@BarNet> Received: from mail4auth.barnet.com.au (mail4.barnet.com.au [202.83.178.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.barnet.com.au", Issuer "Equifax" (verified OK)) by mail4.barnet.com.au (Postfix) with ESMTPS id 430254220CA; Mon, 11 Jul 2011 22:24:37 +1000 (EST) Received: from [10.204.250.200] (ppp121-44-203-127.lns20.syd7.internode.on.net [121.44.203.127]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail4auth.barnet.com.au (Postfix) with ESMTPSA id D64CE37B98E; Mon, 11 Jul 2011 22:24:36 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Edwin Groothuis In-Reply-To: <20110708070105.GA2057@a91-153-123-205.elisa-laajakaista.fi> Date: Mon, 11 Jul 2011 22:24:35 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <87CF3F5E-9733-45CD-B21D-021EC0E70F4B@mavetju.org> References: <20110705192434.GA57761@jh> <201107052102.p65L2lWN055393@fire.js.berklix.net> <20110708070105.GA2057@a91-153-123-205.elisa-laajakaista.fi> To: Jaakko Heinonen X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Mon, 11 Jul 2011 13:25:43 +0000 Cc: "Julian H. Stacey" , hackers@freebsd.org, Ivana Belgers , edwin@FreeBSD.org Subject: Re: regression error with calendar 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, 11 Jul 2011 12:43:23 -0000 Hello Jaakko, Thanks for pointing these out to me, I have fixed the one from PR = 157718, I will check this one out tomorrow. Edwin On 08/07/2011, at 5:01 PM, Jaakko Heinonen wrote: > On 2011-07-05, Julian H. Stacey wrote: >> Jaakko Heinonen wrote: >>> On 2011-07-05, Julian H. Stacey wrote: >>>> There's a regression error with calendar between FreeBSD-8.1 & = 8.2-RELEASES >>>> Test data: >>>> ----- >>>> Tue+1 TESTXXXXX 1 >>>> Tuesday+1 TESTXXXXX 2 >>>> * Tuesday+1 TESTXXXXX 3 >>>> Tuesday+1 * TESTXXXXX 4 >>>> Tuesday TESTXXXXX5 >>>> Tuesday TESTXXXXX6 >>>> ----- >>>=20 >>> This look like PR bin/155873 >>> (http://www.freebsd.org/cgi/query-pr.cgi?pr=3D155873). >>=20 >> Ah Yes, that's the same problem. Thanks ! Can FreeBSD please revert >> the broken code out of CVS, until/ if author / importer / whoever >> might want to fix it. The new code breaks basic common = functionality, >> to add rare usage exotica. >=20 > I guess that reverting r205821 would mean reverting all of edwin's > recent calendar(1) work > (http://svnweb.freebsd.org/base/user/edwin/calendar/?view=3Dlog). >=20 >> Broken calendar code failed to mail prompt me to call meetings in = time. >> Probably caused lots of missed reminders. >=20 > There is also another recent calendar(1) regression: >=20 > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D157718 >=20 > Edwin, please comment if you plan to take a look at these regressions. >=20 > --=20 > Jaakko From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 11 13:33:52 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 7BF21106564A; Mon, 11 Jul 2011 13:33:52 +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 012F08FC08; Mon, 11 Jul 2011 13:33:51 +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 p6BDXhNC087374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Jul 2011 16:33:43 +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 p6BDXhcW009843; Mon, 11 Jul 2011 16:33:43 +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 p6BDXhRP009841; Mon, 11 Jul 2011 16:33:43 +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: Mon, 11 Jul 2011 16:33:42 +0300 From: Kostik Belousov To: Petr Salinger Message-ID: <20110711133342.GT43872@deviant.kiev.zoral.com.ua> References: <20110711123332.GS43872@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="skzcsJvRJWOW8YcK" Content-Disposition: inline In-Reply-To: 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.3 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, Robert Millan , current@freebsd.org Subject: Re: [PATCH] Improve LinuxThreads compatibility in rfork() 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, 11 Jul 2011 13:33:52 -0000 --skzcsJvRJWOW8YcK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 11, 2011 at 03:27:56PM +0200, Petr Salinger wrote: > >>This patch made by Petr Salinger improves compatibility with > >>LinuxThreads in rfork() syscall. The Linux clone() implementation > >>allows specifying the signal sent to parent when child terminates > >>(instead of SIGCHLD). > >> > >>As the threading implementation in Debian GNU/kFreeBSD is > >>LinuxThreads-based, we had to diverge from upstream kFreeBSD ABI and > >>implement this extension. > >> > >>I hope it is acceptable for you to use the same encoding, this way we > >>would archieve ABI compatibility to run Debian GNU/kFreeBSD inside a > >>chroot/jail on top of a FreeBSD system. > >> > >>Thanks for considering > >> > >>-- > >>Robert Millan > > > >>--- a/sys/kern/kern_fork.c > >>+++ b/sys/kern/kern_fork.c > >>@@ -477,7 +477,13 @@ > >> p2->p_sigacts =3D newsigacts; > >> } > >> if (flags & RFLINUXTHPN) > >>- p2->p_sigparent =3D SIGUSR1; > >>+ { > >>+ int sig; > >>+ sig =3D RFTHPNSIGNUM(flags); > >>+ if (sig =3D=3D 0) sig =3D SIGUSR1; > >>+ if (sig =3D=3D SIGCHLD) sig =3D 0; > >>+ p2->p_sigparent =3D sig; > >>+ } > >> else > >> p2->p_sigparent =3D SIGCHLD; > >> > >>--- a/sys/sys/unistd.h > >>+++ b/sys/sys/unistd.h > >>@@ -182,6 +182,10 @@ > >> #define RFHIGHPID (1<<18) /* use a pid higher than 10=20 > >> (idleproc) */ > >> #define RFPPWAIT (1<<31) /* parent sleeps until child exits=20 > >> (vfork) */ > >> #define RFKERNELONLY (RFSTOPPED | RFHIGHPID | RFPPWAIT) > >>+#define RFTHPNSHIFT 24 /* reserve bits 24-30 */ > >>+#define RFTHPNMASK 0x7F /* for compatibility with=20 > >>linuxthreads/clone() */ > >>+ /* allow to specify "clone exit parent=20 > >>notification" signal */ > >>+#define RFTHPNSIGNUM(flags) (((flags) >> RFTHPNSHIFT) & RFTHPNMASK) > >> > >> #endif /* __BSD_VISIBLE */ > >> > >I looked at this patch some time ago already. > > > >Can you, please, describe the reasoning behind the > >>+ if (sig =3D=3D SIGCHLD) sig =3D 0; > >line ? >=20 > The main reason is backward compatibility. > The original FreeBSD code allows only to select between > SIGUSR1 or SIGCHLD signals. >=20 > The our extension changes meaning of RFLINUXTHPN to select signal based o= n=20 > bits 24-30 of passed flags instead of using SIGUSR1 every time. >=20 > When the passed "signal" number is zero, it should behave identically > on plain FreeBSD and in our environment, therefore SIGUSR1 is selected. > The assumption is (have been) that (yet) undefined bits are zero. > That way we are backward compatible with original FreeBSD. >=20 > We still need an alternative way to select "none signal is sent" > after child exit (under linux #0 is used). >=20 > The SIGCHLD can be "selected" (also on original FreeBSD) by not specifyin= g=20 > RFLINUXTHPN, therefore combination of RFLINUXTHPN and passed "signal"=20 > number SIGCHLD is (have been) used for "none signal". >=20 > BTW, the opposite side is in >=20 > http://anonscm.debian.org/viewvc/glibc-bsd/trunk/glibc-ports/kfreebsd/clo= ne.c?view=3Dmarkup I shall state that the sig =3D=3D SIGCHLD case is ugly. Having the separate flag "do not send signal to the parent" would be much less clumsy. What are the requirements for the ABI stability for Debian/kFreeBSD ? Can this be fixed now, or is it too late ? Would you care to update the rfork(2) man page ? Also, it would be ideal to reformat the kern_fork.c change according to our style(9). --skzcsJvRJWOW8YcK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk4a+7YACgkQC3+MBN1Mb4gmgwCfUVmivVjIURnzUngyWGE5P9Mf uEoAn3wVaWVpnufNVnAXpok+rJJWwPzB =dmIw -----END PGP SIGNATURE----- --skzcsJvRJWOW8YcK-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 11 13:50:46 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 91EA6106566C for ; Mon, 11 Jul 2011 13:50:46 +0000 (UTC) (envelope-from Petr.Salinger@seznam.cz) Received: from relay.felk.cvut.cz (relay.felk.cvut.cz [147.32.80.7]) by mx1.freebsd.org (Postfix) with ESMTP id E15D98FC15 for ; Mon, 11 Jul 2011 13:50:45 +0000 (UTC) Received: from sci.felk.cvut.cz (sci.felk.cvut.cz [147.32.83.100]) by relay.felk.cvut.cz (8.14.4/8.14.4) with ESMTP id p6BDIwwS069958; Mon, 11 Jul 2011 15:18:58 +0200 (CEST) (envelope-from Petr.Salinger@seznam.cz) Date: Mon, 11 Jul 2011 15:27:56 +0200 (CEST) From: Petr Salinger X-X-Sender: salinger@sci.felk.cvut.cz To: Kostik Belousov In-Reply-To: <20110711123332.GS43872@deviant.kiev.zoral.com.ua> Message-ID: References: <20110711123332.GS43872@deviant.kiev.zoral.com.ua> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-FELK-MailScanner-Information: X-MailScanner-ID: p6BDIwwS069958 X-FELK-MailScanner: Found to be clean X-FELK-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-1.119, required 6, AWL 0.00, BAYES_00 -1.90, FREEMAIL_FROM 0.00, SPF_NEUTRAL 0.78) X-FELK-MailScanner-From: petr.salinger@seznam.cz X-FELK-MailScanner-To: freebsd-hackers@freebsd.org, kostikbel@gmail.com, rmh@debian.org X-FELK-MailScanner-Watermark: 1310995139.16891@IcFE9t9GO2jAmOFT0yZaSg X-Spam-Status: No Cc: freebsd-hackers@freebsd.org, Robert Millan Subject: Re: [PATCH] Improve LinuxThreads compatibility in rfork() 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, 11 Jul 2011 13:50:46 -0000 >> This patch made by Petr Salinger improves compatibility with >> LinuxThreads in rfork() syscall. The Linux clone() implementation >> allows specifying the signal sent to parent when child terminates >> (instead of SIGCHLD). >> >> As the threading implementation in Debian GNU/kFreeBSD is >> LinuxThreads-based, we had to diverge from upstream kFreeBSD ABI and >> implement this extension. >> >> I hope it is acceptable for you to use the same encoding, this way we >> would archieve ABI compatibility to run Debian GNU/kFreeBSD inside a >> chroot/jail on top of a FreeBSD system. >> >> Thanks for considering >> >> -- >> Robert Millan > >> --- a/sys/kern/kern_fork.c >> +++ b/sys/kern/kern_fork.c >> @@ -477,7 +477,13 @@ >> p2->p_sigacts = newsigacts; >> } >> if (flags & RFLINUXTHPN) >> - p2->p_sigparent = SIGUSR1; >> + { >> + int sig; >> + sig = RFTHPNSIGNUM(flags); >> + if (sig == 0) sig = SIGUSR1; >> + if (sig == SIGCHLD) sig = 0; >> + p2->p_sigparent = sig; >> + } >> else >> p2->p_sigparent = SIGCHLD; >> >> --- a/sys/sys/unistd.h >> +++ b/sys/sys/unistd.h >> @@ -182,6 +182,10 @@ >> #define RFHIGHPID (1<<18) /* use a pid higher than 10 (idleproc) */ >> #define RFPPWAIT (1<<31) /* parent sleeps until child exits (vfork) */ >> #define RFKERNELONLY (RFSTOPPED | RFHIGHPID | RFPPWAIT) >> +#define RFTHPNSHIFT 24 /* reserve bits 24-30 */ >> +#define RFTHPNMASK 0x7F /* for compatibility with linuxthreads/clone() */ >> + /* allow to specify "clone exit parent notification" signal */ >> +#define RFTHPNSIGNUM(flags) (((flags) >> RFTHPNSHIFT) & RFTHPNMASK) >> >> #endif /* __BSD_VISIBLE */ >> > I looked at this patch some time ago already. > > Can you, please, describe the reasoning behind the >> + if (sig == SIGCHLD) sig = 0; > line ? The main reason is backward compatibility. The original FreeBSD code allows only to select between SIGUSR1 or SIGCHLD signals. The our extension changes meaning of RFLINUXTHPN to select signal based on bits 24-30 of passed flags instead of using SIGUSR1 every time. When the passed "signal" number is zero, it should behave identically on plain FreeBSD and in our environment, therefore SIGUSR1 is selected. The assumption is (have been) that (yet) undefined bits are zero. That way we are backward compatible with original FreeBSD. We still need an alternative way to select "none signal is sent" after child exit (under linux #0 is used). The SIGCHLD can be "selected" (also on original FreeBSD) by not specifying RFLINUXTHPN, therefore combination of RFLINUXTHPN and passed "signal" number SIGCHLD is (have been) used for "none signal". BTW, the opposite side is in http://anonscm.debian.org/viewvc/glibc-bsd/trunk/glibc-ports/kfreebsd/clone.c?view=markup Petr From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 11 14:02: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 B62B61065674 for ; Mon, 11 Jul 2011 14:02:26 +0000 (UTC) (envelope-from rmh.aybabtu@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 754918FC25 for ; Mon, 11 Jul 2011 14:02:26 +0000 (UTC) Received: by iyb11 with SMTP id 11so4756750iyb.13 for ; Mon, 11 Jul 2011 07:02:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=zyWiItSWHyQqiqkc3krb1piCxyjj1CunHPrLMr3q2yU=; b=kWFqLq6lfvdXcJ7jvbuSUuQ4Ce9EmEvPMDsPGNz7MWXaOTmDGsSxCczs9Y89Xd3xzB OVfQOT7jcTEmqFbphukr2EOQo/6MGnEHViebWehrSh5/hYqczmf592RAQIz9u3WZ0GSv wPvbGNttYH6furwjIuRtfIxcPLwK6qrCP7o5g= MIME-Version: 1.0 Received: by 10.42.1.74 with SMTP id 10mr5310100icf.86.1310392946011; Mon, 11 Jul 2011 07:02:26 -0700 (PDT) Sender: rmh.aybabtu@gmail.com Received: by 10.42.229.3 with HTTP; Mon, 11 Jul 2011 07:02:25 -0700 (PDT) In-Reply-To: <20110711133342.GT43872@deviant.kiev.zoral.com.ua> References: <20110711123332.GS43872@deviant.kiev.zoral.com.ua> <20110711133342.GT43872@deviant.kiev.zoral.com.ua> Date: Mon, 11 Jul 2011 16:02:25 +0200 X-Google-Sender-Auth: 9M5zRDd6S4ZT7R0oKuN8Xzcpyf8 Message-ID: From: Robert Millan To: Kostik Belousov Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org, current@freebsd.org, Petr Salinger Subject: Re: [PATCH] Improve LinuxThreads compatibility in rfork() 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, 11 Jul 2011 14:02:26 -0000 2011/7/11 Kostik Belousov : > I shall state that the sig == SIGCHLD case is ugly. Having the separate > flag "do not send signal to the parent" would be much less clumsy. > What are the requirements for the ABI stability for Debian/kFreeBSD ? > Can this be fixed now, or is it too late ? Perhaps we could make a smooth transition by implementing both methods on our kernel, then update glibc to use the new one, and only remove the deprecated method in our kernel after a full release cycle. Petr, do you think this could fly? We'd be breaking backward compatibility in userland, but if I understand correctly we do this already and our only supported upgrade path is "first upgrade kernel, then userland" anyway. -- Robert Millan From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 11 14:14:52 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 E2A4C106566B for ; Mon, 11 Jul 2011 14:14:51 +0000 (UTC) (envelope-from Petr.Salinger@seznam.cz) Received: from relay.felk.cvut.cz (relay.felk.cvut.cz [147.32.80.7]) by mx1.freebsd.org (Postfix) with ESMTP id 65C9F8FC1E for ; Mon, 11 Jul 2011 14:14:50 +0000 (UTC) Received: from sci.felk.cvut.cz (sci.felk.cvut.cz [147.32.83.100]) by relay.felk.cvut.cz (8.14.4/8.14.4) with ESMTP id p6BEEc9F073451; Mon, 11 Jul 2011 16:14:38 +0200 (CEST) (envelope-from Petr.Salinger@seznam.cz) Date: Mon, 11 Jul 2011 16:23:36 +0200 (CEST) From: Petr Salinger X-X-Sender: salinger@sci.felk.cvut.cz To: Kostik Belousov In-Reply-To: <20110711133342.GT43872@deviant.kiev.zoral.com.ua> Message-ID: References: <20110711123332.GS43872@deviant.kiev.zoral.com.ua> <20110711133342.GT43872@deviant.kiev.zoral.com.ua> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-FELK-MailScanner-Information: X-MailScanner-ID: p6BEEc9F073451 X-FELK-MailScanner: Found to be clean X-FELK-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-1.119, required 6, AWL 0.00, BAYES_00 -1.90, FREEMAIL_FROM 0.00, SPF_NEUTRAL 0.78) X-FELK-MailScanner-From: petr.salinger@seznam.cz X-FELK-MailScanner-To: current@freebsd.org, freebsd-hackers@freebsd.org, kostikbel@gmail.com, rmh@debian.org X-FELK-MailScanner-Watermark: 1310998479.6933@rQF0UD8XI1GYzmeowRQmjg X-Spam-Status: No Cc: freebsd-hackers@freebsd.org, Robert Millan , current@freebsd.org Subject: Re: [PATCH] Improve LinuxThreads compatibility in rfork() 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, 11 Jul 2011 14:14:52 -0000 >>> Can you, please, describe the reasoning behind the >>>> + if (sig == SIGCHLD) sig = 0; >>> line ? >> >> The main reason is backward compatibility. >> The original FreeBSD code allows only to select between >> SIGUSR1 or SIGCHLD signals. >> >> The our extension changes meaning of RFLINUXTHPN to select signal based on >> bits 24-30 of passed flags instead of using SIGUSR1 every time. >> >> When the passed "signal" number is zero, it should behave identically >> on plain FreeBSD and in our environment, therefore SIGUSR1 is selected. >> The assumption is (have been) that (yet) undefined bits are zero. >> That way we are backward compatible with original FreeBSD. >> >> We still need an alternative way to select "none signal is sent" >> after child exit (under linux #0 is used). >> >> The SIGCHLD can be "selected" (also on original FreeBSD) by not specifying >> RFLINUXTHPN, therefore combination of RFLINUXTHPN and passed "signal" >> number SIGCHLD is (have been) used for "none signal". >> >> BTW, the opposite side is in >> >> http://anonscm.debian.org/viewvc/glibc-bsd/trunk/glibc-ports/kfreebsd/clone.c?view=markup > > I shall state that the sig == SIGCHLD case is ugly. Having the separate > flag "do not send signal to the parent" would be much less clumsy. > What are the requirements for the ABI stability for Debian/kFreeBSD ? > Can this be fixed now, or is it too late ? It should be backward compatible with one previous version. What about in long term this: RFLINUXTHPN bit will be renamed and will have meaning "select signal based on bits 24-30 of passed flags" - zero would mean "no signal" - SIGCHLD would mean undefined - SIGUSR1 would mean SIGUSR1 It is ABI/API breakage under original FreeBSD. The question is how frequently RFLINUXTHPN is used under native FreeBSD and its port collection. And under "Debian GNU/kFreeBSD COMPAT" or 8-COMPAT - SIGCHLD would mean "no signal" We do not use SIGUSR1 currently, the eglibc side can detect whether it runs under new-enough kernel and decide whether use 0 or SIGCHLD for "no signal". The kernel side would be something like: if (flags & RFLINUXTHPN) { p2->p_sigparent = RFTHPNSIGNUM(flags); #if COMPAT8 if (p2->p_sigparent == SIGCHLD) p2->p_sigparent = 0; #endif } Petr From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 11 14:22:41 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 236901065672; Mon, 11 Jul 2011 14:22:41 +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 B78FD8FC20; Mon, 11 Jul 2011 14:22:40 +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 p6BEMXDA091566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Jul 2011 17:22:33 +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 p6BEMXtr016122; Mon, 11 Jul 2011 17:22:33 +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 p6BEMXFN016100; Mon, 11 Jul 2011 17:22:33 +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: Mon, 11 Jul 2011 17:22:33 +0300 From: Kostik Belousov To: Petr Salinger Message-ID: <20110711142232.GU43872@deviant.kiev.zoral.com.ua> References: <20110711123332.GS43872@deviant.kiev.zoral.com.ua> <20110711133342.GT43872@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="czRehjsqUdpaVUeF" Content-Disposition: inline In-Reply-To: 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.3 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, Robert Millan , current@freebsd.org Subject: Re: [PATCH] Improve LinuxThreads compatibility in rfork() 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, 11 Jul 2011 14:22:41 -0000 --czRehjsqUdpaVUeF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 11, 2011 at 04:23:36PM +0200, Petr Salinger wrote: > >>>Can you, please, describe the reasoning behind the > >>>>+ if (sig =3D=3D SIGCHLD) sig =3D 0; > >>>line ? > >> > >>The main reason is backward compatibility. > >>The original FreeBSD code allows only to select between > >>SIGUSR1 or SIGCHLD signals. > >> > >>The our extension changes meaning of RFLINUXTHPN to select signal based= on > >>bits 24-30 of passed flags instead of using SIGUSR1 every time. > >> > >>When the passed "signal" number is zero, it should behave identically > >>on plain FreeBSD and in our environment, therefore SIGUSR1 is selected. > >>The assumption is (have been) that (yet) undefined bits are zero. > >>That way we are backward compatible with original FreeBSD. > >> > >>We still need an alternative way to select "none signal is sent" > >>after child exit (under linux #0 is used). > >> > >>The SIGCHLD can be "selected" (also on original FreeBSD) by not specify= ing > >>RFLINUXTHPN, therefore combination of RFLINUXTHPN and passed "signal" > >>number SIGCHLD is (have been) used for "none signal". > >> > >>BTW, the opposite side is in > >> > >>http://anonscm.debian.org/viewvc/glibc-bsd/trunk/glibc-ports/kfreebsd/c= lone.c?view=3Dmarkup > > > >I shall state that the sig =3D=3D SIGCHLD case is ugly. Having the separ= ate > >flag "do not send signal to the parent" would be much less clumsy. > >What are the requirements for the ABI stability for Debian/kFreeBSD ? > >Can this be fixed now, or is it too late ? >=20 > It should be backward compatible with one previous version. >=20 > What about in long term this: >=20 > RFLINUXTHPN bit will be renamed and will have meaning > "select signal based on bits 24-30 of passed flags" >=20 > - zero would mean "no signal" > - SIGCHLD would mean undefined > - SIGUSR1 would mean SIGUSR1 >=20 > It is ABI/API breakage under original FreeBSD. > The question is how frequently RFLINUXTHPN is used under native FreeBSD > and its port collection. RFLINUXPTH was used by the linuxthreads port, that was popular in the time of FreeBSD 4.x and may be 5.x to run mysql. I will object against this breakage. >=20 > And under "Debian GNU/kFreeBSD COMPAT" or 8-COMPAT > - SIGCHLD would mean "no signal" We never user COMPAT to _change_ the meaning of something, only to exclude some functionality, like syscall. >=20 > We do not use SIGUSR1 currently, the eglibc side can detect whether > it runs under new-enough kernel and decide whether use 0 or SIGCHLD > for "no signal". >=20 > The kernel side would be something like: >=20 > if (flags & RFLINUXTHPN) > { > p2->p_sigparent =3D RFTHPNSIGNUM(flags); > #if COMPAT8 > if (p2->p_sigparent =3D=3D SIGCHLD) > p2->p_sigparent =3D 0; > #endif > } No, this is even uglier, and see the note about compat. BTW, it seems that our rfork(2) ignores unknown flags. This should be fixed, might be in the same patch. --czRehjsqUdpaVUeF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk4bBygACgkQC3+MBN1Mb4jK3wCfUDTbE+y2thPnkLBRDkRLq53a wWQAnjkr4O8ngWU0FTCHpzsmnMbLAl1Q =yDiE -----END PGP SIGNATURE----- --czRehjsqUdpaVUeF-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 11 14:42: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 D5D421065670; Mon, 11 Jul 2011 14:42:01 +0000 (UTC) (envelope-from Petr.Salinger@seznam.cz) Received: from relay.felk.cvut.cz (relay.felk.cvut.cz [147.32.80.7]) by mx1.freebsd.org (Postfix) with ESMTP id 556128FC1B; Mon, 11 Jul 2011 14:42:00 +0000 (UTC) Received: from sci.felk.cvut.cz (sci.felk.cvut.cz [147.32.83.100]) by relay.felk.cvut.cz (8.14.4/8.14.4) with ESMTP id p6BEfkVT075273; Mon, 11 Jul 2011 16:41:46 +0200 (CEST) (envelope-from Petr.Salinger@seznam.cz) Date: Mon, 11 Jul 2011 16:50:44 +0200 (CEST) From: Petr Salinger X-X-Sender: salinger@sci.felk.cvut.cz To: Kostik Belousov In-Reply-To: <20110711142232.GU43872@deviant.kiev.zoral.com.ua> Message-ID: References: <20110711123332.GS43872@deviant.kiev.zoral.com.ua> <20110711133342.GT43872@deviant.kiev.zoral.com.ua> <20110711142232.GU43872@deviant.kiev.zoral.com.ua> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-FELK-MailScanner-Information: X-MailScanner-ID: p6BEfkVT075273 X-FELK-MailScanner: Found to be clean X-FELK-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-1.119, required 6, AWL 0.00, BAYES_00 -1.90, FREEMAIL_FROM 0.00, SPF_NEUTRAL 0.78) X-FELK-MailScanner-From: petr.salinger@seznam.cz X-FELK-MailScanner-To: current@freebsd.org, freebsd-hackers@freebsd.org, kostikbel@gmail.com, rmh@debian.org X-FELK-MailScanner-Watermark: 1311000109.70713@DRdNcjyQcQ4+cR/VzNgwIA X-Spam-Status: No Cc: freebsd-hackers@freebsd.org, Robert Millan , current@freebsd.org Subject: Re: [PATCH] Improve LinuxThreads compatibility in rfork() 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, 11 Jul 2011 14:42:01 -0000 > RFLINUXPTH was used by the linuxthreads port, that was popular in the > time of FreeBSD 4.x and may be 5.x to run mysql. I will object against > this breakage. Do I understand correctly that API/ABI backward compatibility with previous FreeBSD releases w.r.t RFLINUXPTH is needed ? The 1st patch satisfies this. I agree that SIGCHLD part is not easily readable. Petr From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 11 15:06: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 63B01106566C; Mon, 11 Jul 2011 15:06:23 +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 CF78B8FC1A; Mon, 11 Jul 2011 15:06:22 +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 p6BF6Fbh095052 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Jul 2011 18:06:15 +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 p6BF6FQQ049890; Mon, 11 Jul 2011 18:06:15 +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 p6BF6E4H049889; Mon, 11 Jul 2011 18:06:14 +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: Mon, 11 Jul 2011 18:06:14 +0300 From: Kostik Belousov To: Petr Salinger Message-ID: <20110711150614.GV43872@deviant.kiev.zoral.com.ua> References: <20110711123332.GS43872@deviant.kiev.zoral.com.ua> <20110711133342.GT43872@deviant.kiev.zoral.com.ua> <20110711142232.GU43872@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IX4edXMD7HczJcpd" Content-Disposition: inline In-Reply-To: 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.3 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, Robert Millan , current@freebsd.org Subject: Re: [PATCH] Improve LinuxThreads compatibility in rfork() 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, 11 Jul 2011 15:06:23 -0000 --IX4edXMD7HczJcpd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 11, 2011 at 04:50:44PM +0200, Petr Salinger wrote: > >RFLINUXPTH was used by the linuxthreads port, that was popular in the > >time of FreeBSD 4.x and may be 5.x to run mysql. I will object against > >this breakage. >=20 > Do I understand correctly that API/ABI backward compatibility with=20 > previous FreeBSD releases w.r.t RFLINUXPTH is needed ? Yes, I think so. >=20 > The 1st patch satisfies this. I agree that SIGCHLD part > is not easily readable. The SIGCHLD part is ugly. This is why I am asking about possible ways to overcome this. --IX4edXMD7HczJcpd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk4bEWYACgkQC3+MBN1Mb4gP/QCeKk+yrsL0D5YH6TD0NiYlqHeH UxIAoL8ywZCzTIFuvWY3oXoVuXe8QLpc =cYjR -----END PGP SIGNATURE----- --IX4edXMD7HczJcpd-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 11 15:34: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 A7D6E106573C; Mon, 11 Jul 2011 15:34:40 +0000 (UTC) (envelope-from Petr.Salinger@seznam.cz) Received: from relay.felk.cvut.cz (relay.felk.cvut.cz [147.32.80.7]) by mx1.freebsd.org (Postfix) with ESMTP id 21D5C8FC1F; Mon, 11 Jul 2011 15:34:39 +0000 (UTC) Received: from sci.felk.cvut.cz (sci.felk.cvut.cz [147.32.83.100]) by relay.felk.cvut.cz (8.14.4/8.14.4) with ESMTP id p6BFYPnO085033; Mon, 11 Jul 2011 17:34:25 +0200 (CEST) (envelope-from Petr.Salinger@seznam.cz) Date: Mon, 11 Jul 2011 17:43:23 +0200 (CEST) From: Petr Salinger X-X-Sender: salinger@sci.felk.cvut.cz To: Kostik Belousov In-Reply-To: <20110711150614.GV43872@deviant.kiev.zoral.com.ua> Message-ID: References: <20110711123332.GS43872@deviant.kiev.zoral.com.ua> <20110711133342.GT43872@deviant.kiev.zoral.com.ua> <20110711142232.GU43872@deviant.kiev.zoral.com.ua> <20110711150614.GV43872@deviant.kiev.zoral.com.ua> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-FELK-MailScanner-Information: X-MailScanner-ID: p6BFYPnO085033 X-FELK-MailScanner: Found to be clean X-FELK-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-1.119, required 6, AWL 0.00, BAYES_00 -1.90, FREEMAIL_FROM 0.00, SPF_NEUTRAL 0.78) X-FELK-MailScanner-From: petr.salinger@seznam.cz X-FELK-MailScanner-To: current@freebsd.org, freebsd-hackers@freebsd.org, kostikbel@gmail.com, rmh@debian.org X-FELK-MailScanner-Watermark: 1311003268.14331@EbEHICip5uMYeksDqjPmBQ X-Spam-Status: No Cc: freebsd-hackers@freebsd.org, Robert Millan , current@freebsd.org Subject: Re: [PATCH] Improve LinuxThreads compatibility in rfork() 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, 11 Jul 2011 15:34:40 -0000 >> The 1st patch satisfies this. I agree that SIGCHLD part >> is not easily readable. > The SIGCHLD part is ugly. This is why I am asking about possible ways > to overcome this. We need a way to specify "no signal". It can be "new flag" or "ugly SIGCHLD". new flag: pros: cleaner design cons: one bit of flags eaten cons: GNU/kFreeBSD have to detect at runtime which "no signal" have to use cons: GNU/kFreeBSD have to add "ugly SIGCHLD" for some time (up-to and including next Debian release) anyway ugly SIGCHLD: pros: immediate GNU/kFreeBSD compatibility cons: ugly design But definitely, it would be much, much better to have "new flag" compared to diverge indefinitely ;-) What should be name of the "new flag" ? #define RFTHPNONE (1<<19) /* do not send exit notification signal to the parent */ Petr From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 11 15:41: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 8E4021065689; Mon, 11 Jul 2011 15:41:10 +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 2D5268FC16; Mon, 11 Jul 2011 15:41:09 +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 p6BFf2DZ097906 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Jul 2011 18:41:02 +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 p6BFf2e2051132; Mon, 11 Jul 2011 18:41:02 +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 p6BFf2ED051131; Mon, 11 Jul 2011 18:41:02 +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: Mon, 11 Jul 2011 18:41:02 +0300 From: Kostik Belousov To: Petr Salinger Message-ID: <20110711154102.GW43872@deviant.kiev.zoral.com.ua> References: <20110711123332.GS43872@deviant.kiev.zoral.com.ua> <20110711133342.GT43872@deviant.kiev.zoral.com.ua> <20110711142232.GU43872@deviant.kiev.zoral.com.ua> <20110711150614.GV43872@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Z0wTxTCd2IDq3u/i" Content-Disposition: inline In-Reply-To: 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.3 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, Robert Millan , current@freebsd.org Subject: Re: [PATCH] Improve LinuxThreads compatibility in rfork() 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, 11 Jul 2011 15:41:10 -0000 --Z0wTxTCd2IDq3u/i Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 11, 2011 at 05:43:23PM +0200, Petr Salinger wrote: > >>The 1st patch satisfies this. I agree that SIGCHLD part > >>is not easily readable. > >The SIGCHLD part is ugly. This is why I am asking about possible ways > >to overcome this. >=20 > We need a way to specify "no signal". > It can be "new flag" or "ugly SIGCHLD". >=20 > new flag: > pros: cleaner design > cons: one bit of flags eaten > cons: GNU/kFreeBSD have to detect at runtime which "no signal" have to = use > cons: GNU/kFreeBSD have to add "ugly SIGCHLD" for some time > (up-to and including next Debian release) anyway >=20 > ugly SIGCHLD: > pros: immediate GNU/kFreeBSD compatibility > cons: ugly design >=20 > But definitely, it would be much, much better to have "new flag" compared= =20 > to diverge indefinitely ;-) >=20 > What should be name of the "new flag" ? >=20 > #define RFTHPNONE (1<<19) /* do not send exit notification signal to the= =20 > parent */ >=20 I would instead use a new flag to specify a signal sent on the child death. Like RFTSIGZMB. If flag is not set, SIGCHLD is used. If it is set, the bit slice is used as signal number, 0 means do not send any signal. Please note that the signal should be checked for validity, it must be <=3D _SIG_MAXSIG). --Z0wTxTCd2IDq3u/i Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk4bGY0ACgkQC3+MBN1Mb4iB3ACg7W4IXzVsMQdGWspxVlmx2A7i icYAnjOSgI2LR2L42ailheOMQ4OdmDOF =ARQi -----END PGP SIGNATURE----- --Z0wTxTCd2IDq3u/i-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 11 16:03: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 6ABA2106566B; Mon, 11 Jul 2011 16:03:29 +0000 (UTC) (envelope-from Petr.Salinger@seznam.cz) Received: from relay.felk.cvut.cz (relay.felk.cvut.cz [147.32.80.7]) by mx1.freebsd.org (Postfix) with ESMTP id DB52B8FC29; Mon, 11 Jul 2011 16:03:28 +0000 (UTC) Received: from sci.felk.cvut.cz (sci.felk.cvut.cz [147.32.83.100]) by relay.felk.cvut.cz (8.14.4/8.14.4) with ESMTP id p6BG3How086824; Mon, 11 Jul 2011 18:03:17 +0200 (CEST) (envelope-from Petr.Salinger@seznam.cz) Date: Mon, 11 Jul 2011 18:12:15 +0200 (CEST) From: Petr Salinger X-X-Sender: salinger@sci.felk.cvut.cz To: Kostik Belousov In-Reply-To: <20110711154102.GW43872@deviant.kiev.zoral.com.ua> Message-ID: References: <20110711123332.GS43872@deviant.kiev.zoral.com.ua> <20110711133342.GT43872@deviant.kiev.zoral.com.ua> <20110711142232.GU43872@deviant.kiev.zoral.com.ua> <20110711150614.GV43872@deviant.kiev.zoral.com.ua> <20110711154102.GW43872@deviant.kiev.zoral.com.ua> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-FELK-MailScanner-Information: X-MailScanner-ID: p6BG3How086824 X-FELK-MailScanner: Found to be clean X-FELK-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-1.119, required 6, AWL 0.00, BAYES_00 -1.90, FREEMAIL_FROM 0.00, SPF_NEUTRAL 0.78) X-FELK-MailScanner-From: petr.salinger@seznam.cz X-FELK-MailScanner-To: current@freebsd.org, freebsd-hackers@freebsd.org, kostikbel@gmail.com, rmh@debian.org X-FELK-MailScanner-Watermark: 1311004997.74881@3PVEEZ+jUrOzDdbDuZJulA X-Spam-Status: No Cc: freebsd-hackers@freebsd.org, Robert Millan , current@freebsd.org Subject: Re: [PATCH] Improve LinuxThreads compatibility in rfork() 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, 11 Jul 2011 16:03:29 -0000 > I would instead use a new flag to specify a signal sent on the child > death. Like RFTSIGZMB. If flag is not set, SIGCHLD is used. If it is > set, the bit slice is used as signal number, 0 means do not send any > signal. > > Please note that the signal should be checked for validity, it must be > <= _SIG_MAXSIG). We used this: #define RFTHPNSHIFT 24 /* reserve bits 24-30 */ #define RFTHPNMASK 0x7F /* for compatibility with linuxthreads/clone() */ /* allow to specify "clone exit parent notification" signal */ #define RFTHPNSIGNUM(flags) (((flags) >> RFTHPNSHIFT) & RFTHPNMASK) Therefore signal #128 (_SIG_MAXSIG) cannot be selected. Should the bit slice be 7 or 8 bits ? Petr From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 11 17:24: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 167C61065670; Mon, 11 Jul 2011 17:24:18 +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 0DA7A8FC0C; Mon, 11 Jul 2011 17:24:16 +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 p6BHO8Mr006955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Jul 2011 20:24:08 +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 p6BHO8pA054637; Mon, 11 Jul 2011 20:24:08 +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 p6BHO8wJ054636; Mon, 11 Jul 2011 20:24:08 +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: Mon, 11 Jul 2011 20:24:08 +0300 From: Kostik Belousov To: Petr Salinger Message-ID: <20110711172408.GX43872@deviant.kiev.zoral.com.ua> References: <20110711123332.GS43872@deviant.kiev.zoral.com.ua> <20110711133342.GT43872@deviant.kiev.zoral.com.ua> <20110711142232.GU43872@deviant.kiev.zoral.com.ua> <20110711150614.GV43872@deviant.kiev.zoral.com.ua> <20110711154102.GW43872@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TOkWJigZa0YodlBE" Content-Disposition: inline In-Reply-To: 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.3 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, Robert Millan , current@freebsd.org Subject: Re: [PATCH] Improve LinuxThreads compatibility in rfork() 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, 11 Jul 2011 17:24:18 -0000 --TOkWJigZa0YodlBE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 11, 2011 at 06:12:15PM +0200, Petr Salinger wrote: > >I would instead use a new flag to specify a signal sent on the child > >death. Like RFTSIGZMB. If flag is not set, SIGCHLD is used. If it is > >set, the bit slice is used as signal number, 0 means do not send any > >signal. > > > >Please note that the signal should be checked for validity, it must be > ><=3D _SIG_MAXSIG). >=20 > We used this: >=20 > #define RFTHPNSHIFT 24 /* reserve bits 24-30 */ > #define RFTHPNMASK 0x7F /* for compatibility with=20 > linuxthreads/clone() */ > /* allow to specify "clone exit parent=20 > notification" signal */ > #define RFTHPNSIGNUM(flags) (((flags) >> RFTHPNSHIFT) & RFTHPNMASK) >=20 > Therefore signal #128 (_SIG_MAXSIG) cannot be selected. >=20 > Should the bit slice be 7 or 8 bits ? I propose to go 8 bits, and add the check to be future-proof. It seems that we already parse GNU/kFreeBSD brandnote. I think this could be used to distinguish between old behaviour, that is currently used by your libc, and proposed new interface, if __FreeBSD_version is bumped and honored by glibc. You might need to store the brandinfo somewhere in struct proc or use the separate struct sysentvec. --TOkWJigZa0YodlBE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk4bMbgACgkQC3+MBN1Mb4gEcACfdj7xc3GIUFHXKmc7JIeohaMR zcMAn2rCwH7+ioEK42bpY+4iDFftWu2j =bNtr -----END PGP SIGNATURE----- --TOkWJigZa0YodlBE-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 11 17:57: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 2F3F61065673; Mon, 11 Jul 2011 17:57:12 +0000 (UTC) (envelope-from Petr.Salinger@seznam.cz) Received: from relay.felk.cvut.cz (relay.felk.cvut.cz [147.32.80.7]) by mx1.freebsd.org (Postfix) with ESMTP id A61F58FC1F; Mon, 11 Jul 2011 17:57:10 +0000 (UTC) Received: from sci.felk.cvut.cz (sci.felk.cvut.cz [147.32.83.100]) by relay.felk.cvut.cz (8.14.4/8.14.4) with ESMTP id p6BHuwJS091697; Mon, 11 Jul 2011 19:56:58 +0200 (CEST) (envelope-from Petr.Salinger@seznam.cz) Date: Mon, 11 Jul 2011 20:05:56 +0200 (CEST) From: Petr Salinger X-X-Sender: salinger@sci.felk.cvut.cz To: Kostik Belousov In-Reply-To: <20110711172408.GX43872@deviant.kiev.zoral.com.ua> Message-ID: References: <20110711123332.GS43872@deviant.kiev.zoral.com.ua> <20110711133342.GT43872@deviant.kiev.zoral.com.ua> <20110711142232.GU43872@deviant.kiev.zoral.com.ua> <20110711150614.GV43872@deviant.kiev.zoral.com.ua> <20110711154102.GW43872@deviant.kiev.zoral.com.ua> <20110711172408.GX43872@deviant.kiev.zoral.com.ua> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-FELK-MailScanner-Information: X-MailScanner-ID: p6BHuwJS091697 X-FELK-MailScanner: Found to be clean X-FELK-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-1.119, required 6, AWL 0.00, BAYES_00 -1.90, FREEMAIL_FROM 0.00, SPF_NEUTRAL 0.78) X-FELK-MailScanner-From: petr.salinger@seznam.cz X-FELK-MailScanner-To: current@freebsd.org, freebsd-hackers@freebsd.org, kostikbel@gmail.com, rmh@debian.org X-FELK-MailScanner-Watermark: 1311011819.22339@gHoEZ/dW6hA7X9y9f898Vw X-Spam-Status: No Cc: freebsd-hackers@freebsd.org, Robert Millan , current@freebsd.org Subject: Re: [PATCH] Improve LinuxThreads compatibility in rfork() 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, 11 Jul 2011 17:57:12 -0000 >> Should the bit slice be 7 or 8 bits ? > I propose to go 8 bits, and add the check to be future-proof. > It seems that we already parse GNU/kFreeBSD brandnote. I think this > could be used to distinguish between old behaviour, that is currently > used by your libc, and proposed new interface, if __FreeBSD_version > is bumped and honored by glibc. You might need to store the brandinfo > somewhere in struct proc or use the separate struct sysentvec. No, the version in brandnote is compile-time minimal supported version, we will detect at runtime (by "sysctl kern.osreldate") which interface we should use. So far defined rfork() options: /* * XXX currently, some operations without RFPROC set are not supported. */ #define RFNAMEG (1<<0) /* UNIMPL new plan9 `name space' */ #define RFENVG (1<<1) /* UNIMPL copy plan9 `env space' */ #define RFFDG (1<<2) /* copy fd table */ #define RFNOTEG (1<<3) /* UNIMPL create new plan9 `note group' */ #define RFPROC (1<<4) /* change child (else changes curproc) */ #define RFMEM (1<<5) /* share `address space' */ #define RFNOWAIT (1<<6) /* give child to init */ #define RFCNAMEG (1<<10) /* UNIMPL zero plan9 `name space' */ #define RFCENVG (1<<11) /* UNIMPL zero plan9 `env space' */ #define RFCFDG (1<<12) /* close all fds, zero fd table */ #define RFTHREAD (1<<13) /* enable kernel thread support */ #define RFSIGSHARE (1<<14) /* share signal handlers */ #define RFLINUXTHPN (1<<16) /* do linux clone exit parent notification */ #define RFSTOPPED (1<<17) /* leave child in a stopped state */ #define RFHIGHPID (1<<18) /* use a pid higher than 10 (idleproc) */ #define RFPPWAIT (1<<31) /* parent sleeps until child exits (vfork) */ #define RFKERNELONLY (RFSTOPPED | RFHIGHPID | RFPPWAIT) The new interface will add: #define RFTSIGZMB (1<<19) #define RFTSIGSHIFT 20 /* reserve bits 20-27 */ #define RFTSIGMASK 0xFF #define RFTSIGNUM(flags) (((flags) >> RFTSIGSHIFT) & RFTSIGMASK) #define RFTSIGFLAGS(signum) ((signum) << RFTSIGSHIFT) Seems this interface be acceptable ? Petr From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 11 18:03: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 B4674106564A; Mon, 11 Jul 2011 18:03:10 +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 C60D38FC08; Mon, 11 Jul 2011 18:03:09 +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 p6BI2kVl009618 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Jul 2011 21:02:47 +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 p6BI2kOd056069; Mon, 11 Jul 2011 21:02:46 +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 p6BI2kP8056068; Mon, 11 Jul 2011 21:02:46 +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: Mon, 11 Jul 2011 21:02:46 +0300 From: Kostik Belousov To: Petr Salinger Message-ID: <20110711180246.GA43872@deviant.kiev.zoral.com.ua> References: <20110711133342.GT43872@deviant.kiev.zoral.com.ua> <20110711142232.GU43872@deviant.kiev.zoral.com.ua> <20110711150614.GV43872@deviant.kiev.zoral.com.ua> <20110711154102.GW43872@deviant.kiev.zoral.com.ua> <20110711172408.GX43872@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ib0MfiC6BuP+wsSj" Content-Disposition: inline In-Reply-To: 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.3 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, Robert Millan , current@freebsd.org Subject: Re: [PATCH] Improve LinuxThreads compatibility in rfork() 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, 11 Jul 2011 18:03:10 -0000 --ib0MfiC6BuP+wsSj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 11, 2011 at 08:05:56PM +0200, Petr Salinger wrote: > >>Should the bit slice be 7 or 8 bits ? >=20 > >I propose to go 8 bits, and add the check to be future-proof. >=20 > >It seems that we already parse GNU/kFreeBSD brandnote. I think this > >could be used to distinguish between old behaviour, that is currently > >used by your libc, and proposed new interface, if __FreeBSD_version > >is bumped and honored by glibc. You might need to store the brandinfo > >somewhere in struct proc or use the separate struct sysentvec. >=20 > No, the version in brandnote is compile-time minimal supported version, > we will detect at runtime (by "sysctl kern.osreldate") which interface we= =20 > should use. >=20 >=20 > So far defined rfork() options: >=20 > /* > * XXX currently, some operations without RFPROC set are not supported. > */ >=20 > #define RFNAMEG (1<<0) /* UNIMPL new plan9 `name space' */ > #define RFENVG (1<<1) /* UNIMPL copy plan9 `env space' */ > #define RFFDG (1<<2) /* copy fd table */ > #define RFNOTEG (1<<3) /* UNIMPL create new plan9 `note=20 > group' */ > #define RFPROC (1<<4) /* change child (else changes=20 > curproc) */ > #define RFMEM (1<<5) /* share `address space' */ > #define RFNOWAIT (1<<6) /* give child to init */ > #define RFCNAMEG (1<<10) /* UNIMPL zero plan9 `name space' */ > #define RFCENVG (1<<11) /* UNIMPL zero plan9 `env space' */ > #define RFCFDG (1<<12) /* close all fds, zero fd table */ > #define RFTHREAD (1<<13) /* enable kernel thread support */ > #define RFSIGSHARE (1<<14) /* share signal handlers */ > #define RFLINUXTHPN (1<<16) /* do linux clone exit parent=20 > notification */ > #define RFSTOPPED (1<<17) /* leave child in a stopped state */ > #define RFHIGHPID (1<<18) /* use a pid higher than 10=20 > (idleproc) */ > #define RFPPWAIT (1<<31) /* parent sleeps until child exits=20 > (vfork) */ > #define RFKERNELONLY (RFSTOPPED | RFHIGHPID | RFPPWAIT) >=20 >=20 > The new interface will add: >=20 > #define RFTSIGZMB (1<<19) > #define RFTSIGSHIFT 20 /* reserve bits 20-27 */=20 > #define RFTSIGMASK 0xFF=20 > #define RFTSIGNUM(flags) (((flags) >> RFTSIGSHIFT) & RFTSIGMASK) > #define RFTSIGFLAGS(signum) ((signum) << RFTSIGSHIFT) >=20 > Seems this interface be acceptable ? Looks good to me. --ib0MfiC6BuP+wsSj Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk4bOsYACgkQC3+MBN1Mb4j6hgCfYSWLtnCtQ8i0t+q5ONU2S4iZ Xu4AoOqUDzohAK7PbnZBEzYQkGHcHpx+ =LIfS -----END PGP SIGNATURE----- --ib0MfiC6BuP+wsSj-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 12 00:44:15 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 88D111065670 for ; Tue, 12 Jul 2011 00:44:15 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-4.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 1C5C6157AF5; Tue, 12 Jul 2011 00:43:55 +0000 (UTC) Message-ID: <4E1B98CA.7000806@FreeBSD.org> Date: Mon, 11 Jul 2011 17:43:54 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110706 Thunderbird/5.0 MIME-Version: 1.0 To: Ilya Bakulin References: <4E167C94.70300@kibab.com> <4E186B89.8080003@FreeBSD.org> <4E18D88B.4060805@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.2pre OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Capsicum project: Ideas needed 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, 12 Jul 2011 00:44:15 -0000 On 07/11/2011 05:08, Ilya Bakulin wrote: > chroot constraints only filesystem namespace, but doesn't prevent process > from sending/receiving data via network, ... which is kind of important for DNS software. :) > or from accessing other global > namespaces such as PID namespace, SHM namespace, and from executing any > system calls. Fair enough, although I'd love to see an actual threat analysis before I concluded that BIND should be close to the top of the list. Thanks for the response, 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 Tue Jul 12 05:00: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 1CB10106564A for ; Tue, 12 Jul 2011 05:00:27 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id C9D738FC0A for ; Tue, 12 Jul 2011 05:00:26 +0000 (UTC) Received: by vxg33 with SMTP id 33so4385593vxg.13 for ; Mon, 11 Jul 2011 22:00:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=dYGtQOIMn8NHU1bYgU+5vD1o9tRV/WLWthcVOwL1xbk=; b=WUIavguMxLbccBpyMhXNbY2cbP5hYRgnbPGV5jKabE81sEzaK+KN3DBnCgRyZcHTnK uyRLBUBHXOr7S/sC7gIfjPOf08enY8VvxfNL1T3ka5Cfy7f42j9gANHfjZFomzCXjYC7 ExZscECvdoRIEjPfOC+JKGD/vu41Roz52UsiM= MIME-Version: 1.0 Received: by 10.220.117.74 with SMTP id p10mr1630217vcq.141.1310446824708; Mon, 11 Jul 2011 22:00:24 -0700 (PDT) Received: by 10.220.72.75 with HTTP; Mon, 11 Jul 2011 22:00:24 -0700 (PDT) Date: Mon, 11 Jul 2011 22:00:24 -0700 Message-ID: From: Garrett Cooper To: freebsd-hackers@freebsd.org Content-Type: multipart/mixed; boundary=485b3939bd357bdc8404a7d82db7 Subject: [PATCH] Remove dead code in netstat from route.c 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, 12 Jul 2011 05:00:27 -0000 --485b3939bd357bdc8404a7d82db7 Content-Type: text/plain; charset=ISO-8859-1 Hi, While trying to determine how to print out routes via kvm for net-snmp, I noticed that there's a chunk of code from the 4.4 BSD Lite days that isn't executed in netstat as NewTree is always 0. The following patch removes that dead code and gets the FreeBSD source for netstat more in line with NetBSD and OpenBSD's copy. Thanks! -Garrett --485b3939bd357bdc8404a7d82db7 Content-Type: text/x-patch; charset=US-ASCII; name="remove-dead-4-4-bsd-lite-netstat-code.patch" Content-Disposition: attachment; filename="remove-dead-4-4-bsd-lite-netstat-code.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gq0e4zjf0 SW5kZXg6IHVzci5iaW4vbmV0c3RhdC9yb3V0ZS5jCj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHVzci5iaW4vbmV0 c3RhdC9yb3V0ZS5jCShyZXZpc2lvbiAyMjM4MjQpCisrKyB1c3IuYmluL25ldHN0YXQvcm91dGUu Ywkod29ya2luZyBjb3B5KQpAQCAtMTIwLDggKzEyMCw2IEBACiBzdHJ1Y3QJcmFkaXhfbWFzayBy bWFzazsKIHN0cnVjdAlyYWRpeF9ub2RlX2hlYWQgKipydF90YWJsZXM7CiAKLWludAlOZXdUcmVl ID0gMDsKLQogc3RydWN0CXRpbWVzcGVjIHVwdGltZTsKIAogc3RhdGljIHN0cnVjdCBzb2NrYWRk ciAqa2dldHNhKHN0cnVjdCBzb2NrYWRkciAqKTsKQEAgLTEzMCw4ICsxMjgsNiBAQAogc3RhdGlj IHZvaWQgc2l6ZV9jb2xzX3J0ZW50cnkoc3RydWN0IHJ0ZW50cnkgKnJ0KTsKIHN0YXRpYyB2b2lk IHBfdHJlZShzdHJ1Y3QgcmFkaXhfbm9kZSAqKTsKIHN0YXRpYyB2b2lkIHBfcnRub2RlKHZvaWQp Owotc3RhdGljIHZvaWQgbnRyZWVzdHVmZih2b2lkKTsKLXN0YXRpYyB2b2lkIG5wX3J0ZW50cnko c3RydWN0IHJ0X21zZ2hkciAqKTsKIHN0YXRpYyB2b2lkIHBfc29ja2FkZHIoc3RydWN0IHNvY2th ZGRyICosIHN0cnVjdCBzb2NrYWRkciAqLCBpbnQsIGludCk7CiBzdGF0aWMgY29uc3QgY2hhciAq Zm10X3NvY2thZGRyKHN0cnVjdCBzb2NrYWRkciAqc2EsIHN0cnVjdCBzb2NrYWRkciAqbWFzaywK ICAgICBpbnQgZmxhZ3MpOwpAQCAtMTcwLDQ2ICsxNjYsNDEgQEAKIAogCXByaW50ZigiUm91dGlu ZyB0YWJsZXNcbiIpOwogCi0JaWYgKEFmbGFnID09IDAgJiYgTmV3VHJlZSkKLQkJbnRyZWVzdHVm ZigpOwotCWVsc2UgewotCQlpZiAocnRyZWUgPT0gMCkgewotCQkJcHJpbnRmKCJydF90YWJsZXM6 IHN5bWJvbCBub3QgaW4gbmFtZWxpc3RcbiIpOwotCQkJcmV0dXJuOwotCQl9CisJaWYgKHJ0cmVl ID09IDApIHsKKwkJcHJpbnRmKCJydF90YWJsZXM6IHN5bWJvbCBub3QgaW4gbmFtZWxpc3RcbiIp OworCQlyZXR1cm47CisJfQogCi0JCWlmIChrcmVhZCgodV9sb25nKShydHJlZSksIChjaGFyICop KHJ0X3RhYmxlcyksIChudW1maWJzICoKLQkJICAgIChBRl9NQVgrMSkgKiBzaXplb2Yoc3RydWN0 IHJhZGl4X25vZGVfaGVhZCAqKSkpICE9IDApCi0JCQlyZXR1cm47Ci0JCWZvciAoaSA9IDA7IGkg PD0gQUZfTUFYOyBpKyspIHsKLQkJCWludCB0bXBmaWI7Ci0JCQlpZiAoaSAhPSBBRl9JTkVUKQot CQkJCXRtcGZpYiA9IDA7Ci0JCQllbHNlCi0JCQkJdG1wZmliID0gZmlibnVtOwotCQkJcm5ocCA9 IChzdHJ1Y3QgcmFkaXhfbm9kZV9oZWFkICoqKSpydF90YWJsZXM7Ci0JCQkvKiBDYWxjdWxhdGUg dGhlIGluLWtlcm5lbCBhZGRyZXNzLiAqLwotCQkJcm5ocCArPSB0bXBmaWIgKiAoQUZfTUFYKzEp ICsgaTsKLQkJCS8qIFJlYWQgdGhlIGluIGtlcm5lbCByaG4gcG9pbnRlci4gKi8KLQkJCWlmIChr Z2V0KHJuaHAsIHJuaCkgIT0gMCkKLQkJCQljb250aW51ZTsKLQkJCWlmIChybmggPT0gTlVMTCkK LQkJCQljb250aW51ZTsKLQkJCS8qIFJlYWQgdGhlIHJuaCBkYXRhLiAqLwotCQkJaWYgKGtnZXQo cm5oLCBoZWFkKSAhPSAwKQotCQkJCWNvbnRpbnVlOwotCQkJaWYgKGkgPT0gQUZfVU5TUEVDKSB7 Ci0JCQkJaWYgKEFmbGFnICYmIGFmID09IDApIHsKLQkJCQkJcHJpbnRmKCJOZXRtYXNrczpcbiIp OwotCQkJCQlwX3RyZWUoaGVhZC5ybmhfdHJlZXRvcCk7Ci0JCQkJfQotCQkJfSBlbHNlIGlmIChh ZiA9PSBBRl9VTlNQRUMgfHwgYWYgPT0gaSkgewotCQkJCXNpemVfY29scyhpLCBoZWFkLnJuaF90 cmVldG9wKTsKLQkJCQlwcl9mYW1pbHkoaSk7Ci0JCQkJZG9fcnRlbnQgPSAxOwotCQkJCXByX3J0 aGRyKGkpOworCWlmIChrcmVhZCgodV9sb25nKShydHJlZSksIChjaGFyICopKHJ0X3RhYmxlcyks IChudW1maWJzICoKKwkgICAgKEFGX01BWCsxKSAqIHNpemVvZihzdHJ1Y3QgcmFkaXhfbm9kZV9o ZWFkICopKSkgIT0gMCkKKwkJcmV0dXJuOworCWZvciAoaSA9IDA7IGkgPD0gQUZfTUFYOyBpKysp IHsKKwkJaW50IHRtcGZpYjsKKwkJaWYgKGkgIT0gQUZfSU5FVCkKKwkJCXRtcGZpYiA9IDA7CisJ CWVsc2UKKwkJCXRtcGZpYiA9IGZpYm51bTsKKwkJcm5ocCA9IChzdHJ1Y3QgcmFkaXhfbm9kZV9o ZWFkICoqKSpydF90YWJsZXM7CisJCS8qIENhbGN1bGF0ZSB0aGUgaW4ta2VybmVsIGFkZHJlc3Mu ICovCisJCXJuaHAgKz0gdG1wZmliICogKEFGX01BWCsxKSArIGk7CisJCS8qIFJlYWQgdGhlIGlu IGtlcm5lbCByaG4gcG9pbnRlci4gKi8KKwkJaWYgKGtnZXQocm5ocCwgcm5oKSAhPSAwKQorCQkJ Y29udGludWU7CisJCWlmIChybmggPT0gTlVMTCkKKwkJCWNvbnRpbnVlOworCQkvKiBSZWFkIHRo ZSBybmggZGF0YS4gKi8KKwkJaWYgKGtnZXQocm5oLCBoZWFkKSAhPSAwKQorCQkJY29udGludWU7 CisJCWlmIChpID09IEFGX1VOU1BFQykgeworCQkJaWYgKEFmbGFnICYmIGFmID09IDApIHsKKwkJ CQlwcmludGYoIk5ldG1hc2tzOlxuIik7CiAJCQkJcF90cmVlKGhlYWQucm5oX3RyZWV0b3ApOwog CQkJfQorCQl9IGVsc2UgaWYgKGFmID09IEFGX1VOU1BFQyB8fCBhZiA9PSBpKSB7CisJCQlzaXpl X2NvbHMoaSwgaGVhZC5ybmhfdHJlZXRvcCk7CisJCQlwcl9mYW1pbHkoaSk7CisJCQlkb19ydGVu dCA9IDE7CisJCQlwcl9ydGhkcihpKTsKIAkJfQogCX0KIH0KQEAgLTUxMyw3NiArNTA0LDYgQEAK IH0KIAogc3RhdGljIHZvaWQKLW50cmVlc3R1ZmYodm9pZCkKLXsKLQlzaXplX3QgbmVlZGVkOwot CWludCBtaWJbNl07Ci0JY2hhciAqYnVmLCAqbmV4dCwgKmxpbTsKLQlzdHJ1Y3QgcnRfbXNnaGRy ICpydG07Ci0KLQltaWJbMF0gPSBDVExfTkVUOwotCW1pYlsxXSA9IFBGX1JPVVRFOwotCW1pYlsy XSA9IDA7Ci0JbWliWzNdID0gMDsKLQltaWJbNF0gPSBORVRfUlRfRFVNUDsKLQltaWJbNV0gPSAw OwotCWlmIChzeXNjdGwobWliLCA2LCBOVUxMLCAmbmVlZGVkLCBOVUxMLCAwKSA8IDApIHsKLQkJ ZXJyKDEsICJzeXNjdGw6IG5ldC5yb3V0ZS4wLjAuZHVtcCBlc3RpbWF0ZSIpOwotCX0KLQotCWlm ICgoYnVmID0gbWFsbG9jKG5lZWRlZCkpID09IDApIHsKLQkJZXJyeCgyLCAibWFsbG9jKCVsdSki LCAodW5zaWduZWQgbG9uZyluZWVkZWQpOwotCX0KLQlpZiAoc3lzY3RsKG1pYiwgNiwgYnVmLCAm bmVlZGVkLCBOVUxMLCAwKSA8IDApIHsKLQkJZXJyKDEsICJzeXNjdGw6IG5ldC5yb3V0ZS4wLjAu ZHVtcCIpOwotCX0KLQlsaW0gID0gYnVmICsgbmVlZGVkOwotCWZvciAobmV4dCA9IGJ1ZjsgbmV4 dCA8IGxpbTsgbmV4dCArPSBydG0tPnJ0bV9tc2dsZW4pIHsKLQkJcnRtID0gKHN0cnVjdCBydF9t c2doZHIgKiluZXh0OwotCQlucF9ydGVudHJ5KHJ0bSk7Ci0JfQotfQotCi1zdGF0aWMgdm9pZAot bnBfcnRlbnRyeShzdHJ1Y3QgcnRfbXNnaGRyICpydG0pCi17Ci0Jc3RydWN0IHNvY2thZGRyICpz YSA9IChzdHJ1Y3Qgc29ja2FkZHIgKikocnRtICsgMSk7Ci0jaWZkZWYgbm90ZGVmCi0Jc3RhdGlj IGludCBtYXNrc19kb25lLCBiYW5uZXJfcHJpbnRlZDsKLSNlbmRpZgotCXN0YXRpYyBpbnQgb2xk X2FmOwotCWludCBhZjEgPSAwLCBpbnRlcmVzdGluZyA9IFJURl9VUCB8IFJURl9HQVRFV0FZIHwg UlRGX0hPU1Q7Ci0KLSNpZmRlZiBub3RkZWYKLQkvKiBmb3IgdGhlIG1vbWVudCwgbmV0bWFza3Mg YXJlIHNraXBwZWQgb3ZlciAqLwotCWlmICghYmFubmVyX3ByaW50ZWQpIHsKLQkJcHJpbnRmKCJO ZXRtYXNrczpcbiIpOwotCQliYW5uZXJfcHJpbnRlZCA9IDE7Ci0JfQotCWlmIChtYXNrc19kb25l ID09IDApIHsKLQkJaWYgKHJ0bS0+cnRtX2FkZHJzICE9IFJUQV9EU1QgKSB7Ci0JCQltYXNrc19k b25lID0gMTsKLQkJCWFmMSA9IHNhLT5zYV9mYW1pbHk7Ci0JCX0KLQl9IGVsc2UKLSNlbmRpZgot CQlhZjEgPSBzYS0+c2FfZmFtaWx5OwotCWlmIChhZjEgIT0gb2xkX2FmKSB7Ci0JCXByX2ZhbWls eShhZjEpOwotCQlvbGRfYWYgPSBhZjE7Ci0JfQotCWlmIChydG0tPnJ0bV9hZGRycyA9PSBSVEFf RFNUKQotCQlwX3NvY2thZGRyKHNhLCBOVUxMLCAwLCAzNik7Ci0JZWxzZSB7Ci0JCXBfc29ja2Fk ZHIoc2EsIE5VTEwsIHJ0bS0+cnRtX2ZsYWdzLCAxNik7Ci0JCXNhID0gKHN0cnVjdCBzb2NrYWRk ciAqKShTQV9TSVpFKHNhKSArIChjaGFyICopc2EpOwotCQlwX3NvY2thZGRyKHNhLCBOVUxMLCAw LCAxOCk7Ci0JfQotCXBfZmxhZ3MocnRtLT5ydG1fZmxhZ3MgJiBpbnRlcmVzdGluZywgIiUtNi42 cyAiKTsKLQlwdXRjaGFyKCdcbicpOwotfQotCi1zdGF0aWMgdm9pZAogcF9zb2NrYWRkcihzdHJ1 Y3Qgc29ja2FkZHIgKnNhLCBzdHJ1Y3Qgc29ja2FkZHIgKm1hc2ssIGludCBmbGFncywgaW50IHdp ZHRoKQogewogCWNvbnN0IGNoYXIgKmNwOwo= --485b3939bd357bdc8404a7d82db7-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 12 06:19: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 AB94F1065670 for ; Tue, 12 Jul 2011 06:19:28 +0000 (UTC) (envelope-from "melifaro@ipfw.ru"@mail.ipfw.ru) Received: from mail.ipfw.ru (unknown [IPv6:2a01:4f8:120:6141::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4A7688FC1B for ; Tue, 12 Jul 2011 06:19:27 +0000 (UTC) Received: from v6.mpls.in ([2a02:978:2::5] helo=ws.su29.net) by mail.ipfw.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from <"melifaro@ipfw.ru"@mail.ipfw.ru>) id 1QgWJa-000HSP-V2; Tue, 12 Jul 2011 10:19:27 +0400 Message-ID: <4E1BE6D8.60805@ipfw.ru> Date: Tue, 12 Jul 2011 10:16:56 +0400 From: "Alexander V. Chernikov" User-Agent: Thunderbird 2.0.0.24 (X11/20100515) MIME-Version: 1.0 To: Garrett Cooper References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: "melifaro@ipfw.ru"@mail.ipfw.ru Cc: freebsd-hackers@freebsd.org Subject: Re: [PATCH] Remove dead code in netstat from route.c 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, 12 Jul 2011 06:19:28 -0000 Garrett Cooper wrote: > Hi, > While trying to determine how to print out routes via kvm for > net-snmp, I noticed that there's a chunk of code from the 4.4 BSD Lite > days that isn't executed in netstat as NewTree is always 0. The > following patch removes that dead code and gets the FreeBSD source for > netstat more in line with NetBSD and OpenBSD's copy. > Thanks! Hello! This code is still working (I've tested it several months ago). Using RT_DUMP sysctl gives us less information than KVM, but this is much more better way of requesting infromation: KVM heavily assumes RADIX rtee is used and simply implement walking the tree in userland (p_tree()) which is quite hackish. Since some dynamic routing software can change massive amounts of data at once (BGP session with full-view going up/down) or physical interface with several hundred vlans goes up/down - requesting routing data via KVM can lead to fully unexpected behaviour. Calling this on regular basis on net-snmp is not the best thing one can do. Additionally, there can be address families where RADIX is unnecessary complicated since only direct key match is required (MPLS, for example). Moving from RADIX implementation for such family will require a lot of 'if (af == AF_MPLS)' code in many base userland utilities since assumption that RADIX is used do exists in many places, unfortunately. Requesting routes via KVM is completely undocumented and kernel internals dependent way. From the other side, NET_RT_DUMP sysctl is documented in sysctl(3) and is used by all major routing software (quagga, bird,openbgp). It also brings us more RADIX-dependent which should be avoided. > -Garrett > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Tue Jul 12 07:11:00 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 D55681065670 for ; Tue, 12 Jul 2011 07:11:00 +0000 (UTC) (envelope-from yanegomi@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 8AD148FC16 for ; Tue, 12 Jul 2011 07:11:00 +0000 (UTC) Received: by vws18 with SMTP id 18so4477241vws.13 for ; Tue, 12 Jul 2011 00:10:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=+HY9Njx/gJcpOHrzHbTg7mFwU8rA77iuac7kZLdLaXY=; b=FGzM4taniV/IV9aHyugNQ6y7xZP5gg+9YF1f82NKZRiYp/MHA3oY2wPcFZORgM8AlE U8ic6eGEqI9l55dwpsdGYSborUjVaKbcIivc/2ag15EUVtgGbrnuEYzFfT1yCh7798iN bhIu5x/OgBamRB0DXIcaO4Y+B01ZNo+uoIvtg= MIME-Version: 1.0 Received: by 10.221.1.11 with SMTP id no11mr1086400vcb.246.1310454659569; Tue, 12 Jul 2011 00:10:59 -0700 (PDT) Received: by 10.220.72.75 with HTTP; Tue, 12 Jul 2011 00:10:59 -0700 (PDT) In-Reply-To: <4E1BE6D8.60805@ipfw.ru> References: <4E1BE6D8.60805@ipfw.ru> Date: Tue, 12 Jul 2011 00:10:59 -0700 Message-ID: From: Garrett Cooper To: "Alexander V. Chernikov" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: [PATCH] Remove dead code in netstat from route.c 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, 12 Jul 2011 07:11:00 -0000 On Mon, Jul 11, 2011 at 11:16 PM, Alexander V. Chernikov wrote: > Garrett Cooper wrote: >> Hi, >> =A0 =A0 While trying to determine how to print out routes via kvm for >> net-snmp, I noticed that there's a chunk of code from the 4.4 BSD Lite >> days that isn't executed in netstat as NewTree is always 0. The >> following patch removes that dead code and gets the FreeBSD source for >> netstat more in line with NetBSD and OpenBSD's copy. >> Thanks! > > Hello! > > This code is still working (I've tested it several months ago). Using > RT_DUMP sysctl gives us less information than KVM, but this is much more > =A0better way of requesting infromation: > KVM heavily assumes RADIX rtee is used and simply implement walking the > tree in userland (p_tree()) which is quite hackish. Since some dynamic > routing software can change massive amounts of data at once (BGP session > with full-view going up/down) or physical interface with several hundred > vlans goes up/down - requesting routing data via KVM can lead to fully > unexpected behaviour. Calling this on regular basis on net-snmp is not > the best thing one can do. > > Additionally, there can be address families where RADIX is unnecessary > complicated since only direct key match is required (MPLS, for example). > Moving from RADIX implementation for such family will require a lot of > 'if (af =3D=3D AF_MPLS)' code in many base userland utilities since > assumption that RADIX is used do exists in many places, unfortunately. > > Requesting routes via KVM is completely undocumented and kernel > internals dependent way. From the other side, NET_RT_DUMP sysctl is > documented in sysctl(3) and is used by all major routing software > (quagga, bird,openbgp). It also brings us more RADIX-dependent which > should be avoided. That's a compelling argument, but why is NewTree hardwired to 0 then (apart from the fact that kvm works with non-live kernel images)? Thanks, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 12 09:07: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 2B527106564A; Tue, 12 Jul 2011 09:07:45 +0000 (UTC) (envelope-from Petr.Salinger@seznam.cz) Received: from relay.felk.cvut.cz (relay.felk.cvut.cz [147.32.80.7]) by mx1.freebsd.org (Postfix) with ESMTP id BC5308FC13; Tue, 12 Jul 2011 09:07:44 +0000 (UTC) Received: from sci.felk.cvut.cz (sci.felk.cvut.cz [147.32.83.100]) by relay.felk.cvut.cz (8.14.4/8.14.4) with ESMTP id p6C97T8F039166; Tue, 12 Jul 2011 11:07:29 +0200 (CEST) (envelope-from Petr.Salinger@seznam.cz) Date: Tue, 12 Jul 2011 11:16:28 +0200 (CEST) From: Petr Salinger X-X-Sender: salinger@sci.felk.cvut.cz To: Kostik Belousov In-Reply-To: <20110711180246.GA43872@deviant.kiev.zoral.com.ua> Message-ID: References: <20110711133342.GT43872@deviant.kiev.zoral.com.ua> <20110711142232.GU43872@deviant.kiev.zoral.com.ua> <20110711150614.GV43872@deviant.kiev.zoral.com.ua> <20110711154102.GW43872@deviant.kiev.zoral.com.ua> <20110711172408.GX43872@deviant.kiev.zoral.com.ua> <20110711180246.GA43872@deviant.kiev.zoral.com.ua> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="546530387-125356705-1310462188=:10573" X-FELK-MailScanner-Information: X-MailScanner-ID: p6C97T8F039166 X-FELK-MailScanner: Found to be clean X-FELK-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-1.119, required 6, AWL 0.00, BAYES_00 -1.90, FREEMAIL_FROM 0.00, SPF_NEUTRAL 0.78) X-FELK-MailScanner-From: petr.salinger@seznam.cz X-FELK-MailScanner-To: current@freebsd.org, freebsd-hackers@freebsd.org, kostikbel@gmail.com, rmh@debian.org X-FELK-MailScanner-Watermark: 1311066452.38149@HEepPH6xI6E9buxH/JsZtQ X-Spam-Status: No Cc: freebsd-hackers@freebsd.org, Robert Millan , current@freebsd.org Subject: Re: [PATCH] Improve LinuxThreads compatibility in rfork() 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, 12 Jul 2011 09:07:45 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --546530387-125356705-1310462188=:10573 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed >> Seems this interface be acceptable ? > > Looks good to me. The proposed code changes are in the attached patch. Proposed wording of addition into RFORK(2): DESCRIPTION: RFTSIGZMB If set, the kernel will return selected signal number instead of SIGCHILD upon thread exit for the child. The selected signal number have to be encoded into flags by ORing RFTSIGFLAGS(signum). ERRORS: EINVAL An invalid signal was specified. Petr --546530387-125356705-1310462188=:10573 Content-Type: TEXT/x-diff; name=006_lt-rf.diff Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=006_lt-rf.diff LS0tIGEvc3lzL2tlcm4va2Vybl9mb3JrLmMNCisrKyBiL3N5cy9rZXJuL2tl cm5fZm9yay5jDQpAQCAtNDc2LDcgKzQ3NiwxMCBAQA0KIAkJc2lnYWN0c19j b3B5KG5ld3NpZ2FjdHMsIHAxLT5wX3NpZ2FjdHMpOw0KIAkJcDItPnBfc2ln YWN0cyA9IG5ld3NpZ2FjdHM7DQogCX0NCi0JaWYgKGZsYWdzICYgUkZMSU5V WFRIUE4pIA0KKw0KKwlpZiAoZmxhZ3MgJiBSRlRTSUdaTUIpDQorCSAgICAg ICAgcDItPnBfc2lncGFyZW50ID0gUkZUU0lHTlVNKGZsYWdzKTsNCisJZWxz ZSBpZiAoZmxhZ3MgJiBSRkxJTlVYVEhQTikNCiAJICAgICAgICBwMi0+cF9z aWdwYXJlbnQgPSBTSUdVU1IxOw0KIAllbHNlDQogCSAgICAgICAgcDItPnBf c2lncGFyZW50ID0gU0lHQ0hMRDsNCkBAIC03MjMsNiArNzI2LDkgQEANCiAJ aWYgKChmbGFncyAmIChSRkZER3xSRkNGREcpKSA9PSAoUkZGREd8UkZDRkRH KSkNCiAJCXJldHVybiAoRUlOVkFMKTsNCiANCisJaWYgKChmbGFncyAmIFJG VFNJR1pNQikgJiYgKFJGVFNJR05VTShmbGFncykgPiBfU0lHX01BWFNJRykp DQorCQlyZXR1cm4gKEVJTlZBTCk7DQorDQogCXAxID0gdGQtPnRkX3Byb2M7 DQogDQogCS8qDQotLS0gYS9zeXMvc3lzL3VuaXN0ZC5oDQorKysgYi9zeXMv c3lzL3VuaXN0ZC5oDQpAQCAtMTgwLDYgKzE4MCwxMSBAQA0KICNkZWZpbmUJ UkZMSU5VWFRIUE4JKDE8PDE2KQkvKiBkbyBsaW51eCBjbG9uZSBleGl0IHBh cmVudCBub3RpZmljYXRpb24gKi8NCiAjZGVmaW5lCVJGU1RPUFBFRAkoMTw8 MTcpCS8qIGxlYXZlIGNoaWxkIGluIGEgc3RvcHBlZCBzdGF0ZSAqLw0KICNk ZWZpbmUJUkZISUdIUElECSgxPDwxOCkJLyogdXNlIGEgcGlkIGhpZ2hlciB0 aGFuIDEwIChpZGxlcHJvYykgKi8NCisjZGVmaW5lCVJGVFNJR1pNQgkoMTw8 MTkpCS8qIHNlbGVjdCBzaWduYWwgZm9yIGV4aXQgcGFyZW50IG5vdGlmaWNh dGlvbiAqLw0KKyNkZWZpbmUJUkZUU0lHU0hJRlQJMjAJLyogc2VsZWN0ZWQg c2lnbmFsIG51bWJlciBpcyBpbiBiaXRzIDIwLTI3ICAqLw0KKyNkZWZpbmUJ UkZUU0lHTUFTSwkweEZGDQorI2RlZmluZQlSRlRTSUdOVU0oZmxhZ3MpCSgo KGZsYWdzKSA+PiBSRlRTSUdTSElGVCkgJiBSRlRTSUdNQVNLKQ0KKyNkZWZp bmUJUkZUU0lHRkxBR1Moc2lnbnVtKQkoKHNpZ251bSkgPDwgUkZUU0lHU0hJ RlQpDQogI2RlZmluZQlSRlBQV0FJVAkoMTw8MzEpCS8qIHBhcmVudCBzbGVl cHMgdW50aWwgY2hpbGQgZXhpdHMgKHZmb3JrKSAqLw0KICNkZWZpbmUJUkZL RVJORUxPTkxZCShSRlNUT1BQRUQgfCBSRkhJR0hQSUQgfCBSRlBQV0FJVCkN CiANCg== --546530387-125356705-1310462188=:10573-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 12 10:35:35 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 8717F106566B; Tue, 12 Jul 2011 10:35:35 +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 1E3BF8FC13; Tue, 12 Jul 2011 10:35:34 +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 p6CAZRBD080097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Jul 2011 13:35:27 +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 p6CAZQrK092183; Tue, 12 Jul 2011 13:35:26 +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 p6CAZQfM092182; Tue, 12 Jul 2011 13:35:26 +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: Tue, 12 Jul 2011 13:35:26 +0300 From: Kostik Belousov To: Petr Salinger Message-ID: <20110712103526.GF43872@deviant.kiev.zoral.com.ua> References: <20110711142232.GU43872@deviant.kiev.zoral.com.ua> <20110711150614.GV43872@deviant.kiev.zoral.com.ua> <20110711154102.GW43872@deviant.kiev.zoral.com.ua> <20110711172408.GX43872@deviant.kiev.zoral.com.ua> <20110711180246.GA43872@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qJM7dOmrnYWq+SaN" Content-Disposition: inline In-Reply-To: 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.3 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, Robert Millan , current@freebsd.org Subject: Re: [PATCH] Improve LinuxThreads compatibility in rfork() 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, 12 Jul 2011 10:35:35 -0000 --qJM7dOmrnYWq+SaN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 12, 2011 at 11:16:28AM +0200, Petr Salinger wrote: > >>Seems this interface be acceptable ? > > > >Looks good to me. >=20 > The proposed code changes are in the attached patch. >=20 > Proposed wording of addition into RFORK(2): Below is the patch I intend to commit after you retest it. I added the checks for validity of the flags, and some rewording to the manual page. diff --git a/lib/libc/sys/rfork.2 b/lib/libc/sys/rfork.2 index f1ae14b..993fd1b 100644 --- a/lib/libc/sys/rfork.2 +++ b/lib/libc/sys/rfork.2 @@ -5,7 +5,7 @@ .\" .\" $FreeBSD$ .\" -.Dd March 15, 2011 +.Dd July 12, 2011 .Dt RFORK 2 .Os .Sh NAME @@ -84,6 +84,16 @@ Note that a lot of code will not run correctly in such a= n environment. .It Dv RFSIGSHARE If set, the kernel will force sharing the sigacts structure between the child and the parent. +.It Dv RFTSIGZMB +If set, the kernel will deliver a specified signal to the parent +upon the child exit, instead of default SIGCHILD. +The signal number +.Dv signum +is specified by oring the +.Dv RFTSIGFLAGS(signum) +expression into +.Fa flags . +Specifying signal number 0 disables signal delivery upon the child exit. .It Dv RFLINUXTHPN If set, the kernel will return SIGUSR1 instead of SIGCHILD upon thread exit for the child. @@ -164,6 +174,8 @@ would be exceeded (see Both the RFFDG and the RFCFDG flags were specified. .It Bq Er EINVAL Any flags not listed above were specified. +.It Bq Er EINVAL +An invalid signal number was specified. .It Bq Er ENOMEM There is insufficient swap space for the new process. .El diff --git a/sys/kern/kern_fork.c b/sys/kern/kern_fork.c index a8abd8e..9d3e22d 100644 --- a/sys/kern/kern_fork.c +++ b/sys/kern/kern_fork.c @@ -476,7 +476,10 @@ do_fork(struct thread *td, int flags, struct proc *p2,= struct thread *td2, sigacts_copy(newsigacts, p1->p_sigacts); p2->p_sigacts =3D newsigacts; } - if (flags & RFLINUXTHPN)=20 + + if (flags & RFTSIGZMB) + p2->p_sigparent =3D RFTSIGNUM(flags); + else if (flags & RFLINUXTHPN) p2->p_sigparent =3D SIGUSR1; else p2->p_sigparent =3D SIGCHLD; @@ -719,10 +722,22 @@ fork1(struct thread *td, int flags, int pages, struct= proc **procp) static int curfail; static struct timeval lastfail; =20 + /* Check for the undefined or unimplemented flags. */ + if ((flags & ~(RFFLAGS | RFTSIGFLAGS(RFTSIGMASK))) !=3D 0) + return (EINVAL); + + /* Signal value requires RFTSIGZMB. */ + if ((flags & RFTSIGFLAGS(RFTSIGMASK)) !=3D 0 && (flags & RFTSIGZMB) =3D= =3D 0) + return (EINVAL); + /* Can't copy and clear. */ if ((flags & (RFFDG|RFCFDG)) =3D=3D (RFFDG|RFCFDG)) return (EINVAL); =20 + /* Check the validity of the signal number. */ + if ((flags & RFTSIGZMB) !=3D 0 && (u_int)RFTSIGNUM(flags) > _SIG_MAXSIG) + return (EINVAL); + p1 =3D td->td_proc; =20 /* diff --git a/sys/sys/unistd.h b/sys/sys/unistd.h index 378308d..9d56a3a 100644 --- a/sys/sys/unistd.h +++ b/sys/sys/unistd.h @@ -180,8 +180,16 @@ #define RFLINUXTHPN (1<<16) /* do linux clone exit parent notification */ #define RFSTOPPED (1<<17) /* leave child in a stopped state */ #define RFHIGHPID (1<<18) /* use a pid higher than 10 (idleproc) */ +#define RFTSIGZMB (1<<19) /* select signal for exit parent notification */ +#define RFTSIGSHIFT 20 /* selected signal number is in bits 20-27 */ +#define RFTSIGMASK 0xFF +#define RFTSIGNUM(flags) (((flags) >> RFTSIGSHIFT) & RFTSIGMASK) +#define RFTSIGFLAGS(signum) ((signum) << RFTSIGSHIFT) #define RFPPWAIT (1<<31) /* parent sleeps until child exits (vfork) */ #define RFKERNELONLY (RFSTOPPED | RFHIGHPID | RFPPWAIT) +#define RFFLAGS (RFFDG | RFPROC | RFMEM | RFNOWAIT | RFCFDG | \ + RFTHREAD | RFSIGSHARE | RFLINUXTHPN | RFSTOPPED | RFHIGHPID | RFTSIGZM= B | \ + RFPPWAIT) =20 #endif /* __BSD_VISIBLE */ =20 --qJM7dOmrnYWq+SaN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk4cI20ACgkQC3+MBN1Mb4hM7gCeIk2P6FoqM7j24okpKp/hpnj8 ryEAoM3cL/0UcCUBjoes4UUS/nU5P8ZC =nlxa -----END PGP SIGNATURE----- --qJM7dOmrnYWq+SaN-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 12 10:41: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 34D73106566B; Tue, 12 Jul 2011 10:41:56 +0000 (UTC) (envelope-from krivenok.dmitry@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 923048FC08; Tue, 12 Jul 2011 10:41:55 +0000 (UTC) Received: by bwa20 with SMTP id 20so5365040bwa.13 for ; Tue, 12 Jul 2011 03:41:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/fN2useYO8Ndrqwu6clNo+doJjrnGVgWfd+xEIBuzks=; b=d2yn7YHiw3R60agbyRp2rP9axCFEIxgNxSlPXhsMaY3q5x4scs76eWiO1qXTGWYVOY Oc3+PbwGbC4JdL+qgvPZ74bxTC6M6d7rGUiQheSjqFSX1B1DSWN493pGIA8MjMnZKjll uclxsbIxRZeCJSnw/iyAG1rJTXDcOW/hOaDn4= MIME-Version: 1.0 Received: by 10.204.37.73 with SMTP id w9mr2139866bkd.274.1310467314329; Tue, 12 Jul 2011 03:41:54 -0700 (PDT) Received: by 10.204.37.132 with HTTP; Tue, 12 Jul 2011 03:41:54 -0700 (PDT) In-Reply-To: <201107071446.54447.jhb@freebsd.org> References: <201107071446.54447.jhb@freebsd.org> Date: Tue, 12 Jul 2011 14:41:54 +0400 Message-ID: From: Dmitry Krivenok To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: pri_to_rtp returns invalid initial priority 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, 12 Jul 2011 10:41:56 -0000 No it cannot be r222802. Actually, I found a bug fixed in r222802 about a month ago (kern/157657) and I've patched source code of my FreeBSD-8.2 (this is the only difference between my tree and stock FreeBSD-8.2). I thought that build with KERNFAST=1 could be a problem, but I've done clean build and still see the same. On Thu, Jul 7, 2011 at 10:46 PM, John Baldwin wrote: > On Thursday, July 07, 2011 6:37:02 am Dmitry Krivenok wrote: >> Hi Hackers, >> I've developed a simple kld which demonstrates a problem I found on my >> FreeBSD-8.2. > > Maybe revision 222802? > > -- > John Baldwin > -- Sincerely yours, Dmitry V. Krivenok e-mail: krivenok.dmitry@gmail.com skype: krivenok_dmitry jabber: krivenok_dmitry@jabber.ru icq: 242-526-443 From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 12 11:19:58 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 E68C61065749 for ; Tue, 12 Jul 2011 11:19:58 +0000 (UTC) (envelope-from "melifaro@ipfw.ru"@mail.ipfw.ru) Received: from mail.ipfw.ru (unknown [IPv6:2a01:4f8:120:6141::2]) by mx1.freebsd.org (Postfix) with ESMTP id 83A3D8FC2F for ; Tue, 12 Jul 2011 11:19:58 +0000 (UTC) Received: from birdie.ipv6.meganet.ru ([2a02:978::1008] helo=bibi.ipfw.ru) by mail.ipfw.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from <"melifaro@ipfw.ru"@mail.ipfw.ru>) id 1Qgb0P-000Ik4-DA; Tue, 12 Jul 2011 15:19:57 +0400 Message-ID: <4E1C2C7B.5050109@ipfw.ru> Date: Tue, 12 Jul 2011 15:14:03 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20110301 Thunderbird/3.1.7 MIME-Version: 1.0 To: Garrett Cooper References: <4E1BE6D8.60805@ipfw.ru> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: "melifaro@ipfw.ru"@mail.ipfw.ru Cc: freebsd-hackers@freebsd.org Subject: Re: [PATCH] Remove dead code in netstat from route.c 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, 12 Jul 2011 11:19:59 -0000 On 12.07.2011 11:10, Garrett Cooper wrote: > On Mon, Jul 11, 2011 at 11:16 PM, Alexander V. Chernikov > wrote: >> Garrett Cooper wrote: >>> Hi, >>> While trying to determine how to print out routes via kvm for >>> net-snmp, I noticed that there's a chunk of code from the 4.4 BSD Lite >>> days that isn't executed in netstat as NewTree is always 0. The >>> following patch removes that dead code and gets the FreeBSD source for >>> netstat more in line with NetBSD and OpenBSD's copy. >>> Thanks! >> >> Hello! >> >> This code is still working (I've tested it several months ago). Using >> RT_DUMP sysctl gives us less information than KVM, but this is much more >> better way of requesting infromation: >> KVM heavily assumes RADIX rtee is used and simply implement walking the >> tree in userland (p_tree()) which is quite hackish. Since some dynamic >> routing software can change massive amounts of data at once (BGP session >> with full-view going up/down) or physical interface with several hundred >> vlans goes up/down - requesting routing data via KVM can lead to fully >> unexpected behaviour. Calling this on regular basis on net-snmp is not >> the best thing one can do. >> >> Additionally, there can be address families where RADIX is unnecessary >> complicated since only direct key match is required (MPLS, for example). >> Moving from RADIX implementation for such family will require a lot of >> 'if (af == AF_MPLS)' code in many base userland utilities since >> assumption that RADIX is used do exists in many places, unfortunately. >> >> Requesting routes via KVM is completely undocumented and kernel >> internals dependent way. From the other side, NET_RT_DUMP sysctl is >> documented in sysctl(3) and is used by all major routing software >> (quagga, bird,openbgp). It also brings us more RADIX-dependent which >> should be avoided. > > That's a compelling argument, but why is NewTree hardwired to 0 > then (apart from the fact that kvm works with non-live kernel images)? I don't know - It was too long ago :) Walking RADIX directly gives an advantage of accessing its internal fields like "refcount" and "use" values which we are get used to see in 'netstat -rn' output, for example. > Thanks, > -Garrett > From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 12 14:27:38 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 502881065674; Tue, 12 Jul 2011 14:27:38 +0000 (UTC) (envelope-from Petr.Salinger@seznam.cz) Received: from relay.felk.cvut.cz (relay.felk.cvut.cz [147.32.80.7]) by mx1.freebsd.org (Postfix) with ESMTP id C38008FC16; Tue, 12 Jul 2011 14:27:37 +0000 (UTC) Received: from sci.felk.cvut.cz (sci.felk.cvut.cz [147.32.83.100]) by relay.felk.cvut.cz (8.14.4/8.14.4) with ESMTP id p6CERO1E066991; Tue, 12 Jul 2011 16:27:24 +0200 (CEST) (envelope-from Petr.Salinger@seznam.cz) Date: Tue, 12 Jul 2011 16:36:24 +0200 (CEST) From: Petr Salinger X-X-Sender: salinger@sci.felk.cvut.cz To: Kostik Belousov In-Reply-To: <20110712103526.GF43872@deviant.kiev.zoral.com.ua> Message-ID: References: <20110711142232.GU43872@deviant.kiev.zoral.com.ua> <20110711150614.GV43872@deviant.kiev.zoral.com.ua> <20110711154102.GW43872@deviant.kiev.zoral.com.ua> <20110711172408.GX43872@deviant.kiev.zoral.com.ua> <20110711180246.GA43872@deviant.kiev.zoral.com.ua> <20110712103526.GF43872@deviant.kiev.zoral.com.ua> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-FELK-MailScanner-Information: X-MailScanner-ID: p6CERO1E066991 X-FELK-MailScanner: Found to be clean X-FELK-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-1.119, required 6, AWL 0.00, BAYES_00 -1.90, FREEMAIL_FROM 0.00, SPF_NEUTRAL 0.78) X-FELK-MailScanner-From: petr.salinger@seznam.cz X-FELK-MailScanner-To: current@freebsd.org, freebsd-hackers@freebsd.org, kostikbel@gmail.com, rmh@debian.org X-FELK-MailScanner-Watermark: 1311085645.06565@zVRW0eVb5adjF12m3TDUow X-Spam-Status: No Cc: freebsd-hackers@freebsd.org, Robert Millan , current@freebsd.org Subject: Re: [PATCH] Improve LinuxThreads compatibility in rfork() 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, 12 Jul 2011 14:27:38 -0000 > Below is the patch I intend to commit after you retest it. I applied it against our 8.2 based package, altered our "clone" to use this new interface and run eglibc testsuite. No regression. Our runtime detection of this new interface will be based on "sysctl kern.osreldate". > some rewording to the manual page. You might want to reword also RFLINUXTHPN part "kernel will return" -> "kernel will deliver" Can we expect MFC before 8.3 release ? Thanks Petr From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 12 19:46:14 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 2D004106566C; Tue, 12 Jul 2011 19:46:14 +0000 (UTC) (envelope-from rmh.aybabtu@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 E0C168FC14; Tue, 12 Jul 2011 19:46:13 +0000 (UTC) Received: by iyb11 with SMTP id 11so6378182iyb.13 for ; Tue, 12 Jul 2011 12:46:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=lXJ+1AYmZAjHH18lewEUP4McJygy5LanVn9/OcL9Z5A=; b=poM0ztRmih3/LeMKH6w9ad5ZCqsIPQeuD1h8yH9F3l78SCl7uHVLa6T9jsGPUYdw5p vHmJhDYMTi52Ar5/Tfhr3U34IPSHXQ768mzIUBKF4FESfafIWmJv52/KUdc9umukpz9S dL7/Omj6ffMJ5u/dS1EdOM+RPEMxoGyEQRJYM= MIME-Version: 1.0 Received: by 10.42.147.65 with SMTP id m1mr265011icv.46.1310499973134; Tue, 12 Jul 2011 12:46:13 -0700 (PDT) Sender: rmh.aybabtu@gmail.com Received: by 10.42.222.7 with HTTP; Tue, 12 Jul 2011 12:46:12 -0700 (PDT) Date: Tue, 12 Jul 2011 21:46:12 +0200 X-Google-Sender-Auth: t3GV2Bih3JgRmLqhAm8KzqWxq3c Message-ID: From: Robert Millan To: freebsd-hackers@freebsd.org, Ed Maste Content-Type: multipart/mixed; boundary=90e6ba1efd3a6077af04a7e48d27 Cc: Subject: [PATCH] fake pre-processor macros when building on non-FreeBSD system 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, 12 Jul 2011 19:46:14 -0000 --90e6ba1efd3a6077af04a7e48d27 Content-Type: text/plain; charset=UTF-8 When building kernel code on a non-FreeBSD system, kernel source still expects pre-processor macros to be those of a FreeBSD system. If __linux__ is defined, build will break. If __FreeBSD__ isn't defined, build will break too. This small patch "fakes" the pre-processor macros of FreeBSD so that non-FreeBSD systems such as GNU/Linux can build the kernel of FreeBSD too. -- Robert Millan --90e6ba1efd3a6077af04a7e48d27 Content-Type: text/plain; charset=US-ASCII; name="prepro.diff" Content-Disposition: attachment; filename="prepro.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gq19u68y0 LS0tIGEvc3lzL2NvbmYva2Vybi5wcmUubWsKKysrIGIvc3lzL2NvbmYva2Vybi5wcmUubWsKQEAg LTkwLDYgKzkwLDE0IEBACiAuZW5kaWYKIFdFUlJPUj89IC1XZXJyb3IKIAorLmlmICFkZWZpbmVk KE9QU1lTKQorT1BTWVMhPSB1bmFtZSAtcworLmVuZGlmCisKKy5pZiAke09QU1lTfSAhPSAiRnJl ZUJTRCIKK0NGTEFHUys9IC1VbGludXggLVVfX2xpbnV4X18gLURfX0ZyZWVCU0RfXworLmVuZGlm CisKICMgWFhYIExPQ09SRSBtZWFucyAiZG9uJ3QgZGVjbGFyZSBDIHN0dWZmIiBub3QgImZvciBs b2NvcmUucyIuCiBBU01fQ0ZMQUdTPSAteCBhc3NlbWJsZXItd2l0aC1jcHAgLURMT0NPUkUgJHtD RkxBR1N9CiAKLS0tIGEvc3lzL2NvbmYva21vZC5taworKysgYi9zeXMvY29uZi9rbW9kLm1rCkBA IC05Niw2ICs5NiwxNCBAQAogQ0ZMQUdTKz0JLURfS0VSTkVMCiBDRkxBR1MrPQktREtMRF9NT0RV TEUKIAorLmlmICFkZWZpbmVkKE9QU1lTKQorT1BTWVMhPQkJdW5hbWUgLXMKKy5lbmRpZgorCisu aWYgJHtPUFNZU30gIT0gIkZyZWVCU0QiCitDRkxBR1MrPQktVWxpbnV4IC1VX19saW51eF9fIC1E X19GcmVlQlNEX18KKy5lbmRpZgorCiAjIERvbid0IHVzZSBhbnkgc3RhbmRhcmQgb3Igc291cmNl LXJlbGF0aXZlIGluY2x1ZGUgZGlyZWN0b3JpZXMuCiBDU1REPQkJYzk5CiBOT1NURElOQz0JLW5v c3RkaW5jCg== --90e6ba1efd3a6077af04a7e48d27-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 12 20:00:58 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 3625F1065677; Tue, 12 Jul 2011 20:00:58 +0000 (UTC) (envelope-from rmh.aybabtu@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id E56DE8FC12; Tue, 12 Jul 2011 20:00:57 +0000 (UTC) Received: by iwr19 with SMTP id 19so6366944iwr.13 for ; Tue, 12 Jul 2011 13:00:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=uSW/YOdyiBmtaSnx65sMJ09f34USj0jiLjBEZRuqi0M=; b=KCYkG2H+BSOLhhkpwg8YeGpmqEQoVKtsdlJBjTcRtSZqTVIaF+eyzAja6OKqmaTSq/ eaUJ+YVHWmP0Q70MJze2zqIUMHYaEFCjdsmKls+mFqF2CgG46Qx07NNr4O+SkJNc5qdU LsUnpePqwRlrTpnOw9q+5lFu3xywh3maho61E= MIME-Version: 1.0 Received: by 10.42.73.9 with SMTP id q9mr312161icj.314.1310500856865; Tue, 12 Jul 2011 13:00:56 -0700 (PDT) Sender: rmh.aybabtu@gmail.com Received: by 10.42.222.7 with HTTP; Tue, 12 Jul 2011 13:00:56 -0700 (PDT) In-Reply-To: References: Date: Tue, 12 Jul 2011 22:00:56 +0200 X-Google-Sender-Auth: EUMdX4ru7gwCtsbD0UcPn40fqKY Message-ID: From: Robert Millan To: Oliver Pinter , freebsd-hackers@freebsd.org, Ed Maste Content-Type: multipart/mixed; boundary=90e6ba6148bc0d21f504a7e4c2eb Cc: Subject: Re: [PATCH] fake pre-processor macros when building on non-FreeBSD system 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, 12 Jul 2011 20:00:58 -0000 --90e6ba6148bc0d21f504a7e4c2eb Content-Type: text/plain; charset=UTF-8 2011/7/12 Oliver Pinter : > +.if ${OPSYS} != "FreeBSD" > > and what's the status example on NetBSD? I didn't think of it. There are some instances of __NetBSD__ and also __OpenBSD__ in the kernel tree, and the same problem can be fixed for these two systems with minimal effort. Here's a new version of the patch, which also adds -U__NetBSD__ and -U__OpenBSD__ to CFLAGS. -- Robert Millan --90e6ba6148bc0d21f504a7e4c2eb Content-Type: text/plain; charset=US-ASCII; name="prepro.diff" Content-Disposition: attachment; filename="prepro.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gq1aajr50 LS0tIGEvc3lzL2NvbmYva2Vybi5wcmUubWsKKysrIGIvc3lzL2NvbmYva2Vybi5wcmUubWsKQEAg LTkwLDYgKzkwLDE0IEBACiAuZW5kaWYKIFdFUlJPUj89IC1XZXJyb3IKIAorLmlmICFkZWZpbmVk KE9QU1lTKQorT1BTWVMhPSB1bmFtZSAtcworLmVuZGlmCisKKy5pZiAke09QU1lTfSAhPSAiRnJl ZUJTRCIKK0NGTEFHUys9IC1VbGludXggLVVfX2xpbnV4X18gLVVfX05ldEJTRF9fIC1VX19PcGVu QlNEX18gLURfX0ZyZWVCU0RfXworLmVuZGlmCisKICMgWFhYIExPQ09SRSBtZWFucyAiZG9uJ3Qg ZGVjbGFyZSBDIHN0dWZmIiBub3QgImZvciBsb2NvcmUucyIuCiBBU01fQ0ZMQUdTPSAteCBhc3Nl bWJsZXItd2l0aC1jcHAgLURMT0NPUkUgJHtDRkxBR1N9CiAKLS0tIGEvc3lzL2NvbmYva21vZC5t aworKysgYi9zeXMvY29uZi9rbW9kLm1rCkBAIC05Niw2ICs5NiwxNCBAQAogQ0ZMQUdTKz0JLURf S0VSTkVMCiBDRkxBR1MrPQktREtMRF9NT0RVTEUKIAorLmlmICFkZWZpbmVkKE9QU1lTKQorT1BT WVMhPQkJdW5hbWUgLXMKKy5lbmRpZgorCisuaWYgJHtPUFNZU30gIT0gIkZyZWVCU0QiCitDRkxB R1MrPQktVWxpbnV4IC1VX19saW51eF9fIC1VX19OZXRCU0RfXyAtVV9fT3BlbkJTRF9fIC1EX19G cmVlQlNEX18KKy5lbmRpZgorCiAjIERvbid0IHVzZSBhbnkgc3RhbmRhcmQgb3Igc291cmNlLXJl bGF0aXZlIGluY2x1ZGUgZGlyZWN0b3JpZXMuCiBDU1REPQkJYzk5CiBOT1NURElOQz0JLW5vc3Rk aW5jCg== --90e6ba6148bc0d21f504a7e4c2eb-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 12 20:43: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 56D10106566C; Tue, 12 Jul 2011 20:43:47 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id E03B08FC19; Tue, 12 Jul 2011 20:43:46 +0000 (UTC) Received: by vxg33 with SMTP id 33so5174181vxg.13 for ; Tue, 12 Jul 2011 13:43:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; bh=oMx++8YHMKhzrHZlmaU4Du0XlytsdDQa37vuiLJwCjU=; b=aX+C5tDD/JifDafnYzYyardxZZqepihpojCn1dx01CIQtu1bn++QPca4hRVNEAhPDh 7554uWaiw4QCwecVgcFUbhDo7uIO3S9feIfkHUx86nu7g9keKHdszh4Ord9halONDUEK wWrR7Z2Fa1ls2cGj1lw8IWm8vy1eSj+3SniY8= Received: by 10.52.22.11 with SMTP id z11mr390080vde.496.1310503425952; Tue, 12 Jul 2011 13:43: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 c9sm5172503vdv.16.2011.07.12.13.43.43 (version=SSLv3 cipher=OTHER); Tue, 12 Jul 2011 13:43:44 -0700 (PDT) Date: Tue, 12 Jul 2011 16:43:37 -0400 From: Alexander Kabaev To: Robert Millan Message-ID: <20110712164337.07e387eb@kan.dnsalias.net> In-Reply-To: References: X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/E70VSwE+9JiP5gRVx//pJ68"; protocol="application/pgp-signature" Cc: freebsd-hackers@freebsd.org, Ed, Maste , Oliver Pinter Subject: Re: [PATCH] fake pre-processor macros when building on non-FreeBSD system 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, 12 Jul 2011 20:43:47 -0000 --Sig_/E70VSwE+9JiP5gRVx//pJ68 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 12 Jul 2011 22:00:56 +0200 Robert Millan wrote: > 2011/7/12 Oliver Pinter : > > +.if ${OPSYS} !=3D "FreeBSD" > > > > and what's the status example on NetBSD? >=20 > I didn't think of it. There are some instances of __NetBSD__ and also > __OpenBSD__ in the kernel tree, and the same problem can be fixed for > these two systems with minimal effort. >=20 > Here's a new version of the patch, which also adds -U__NetBSD__ and > -U__OpenBSD__ to CFLAGS. >=20 > --=20 > Robert Millan Whatever happened to using a proper cross-tool to do the job? Why is this hack needed? --=20 Alexander Kabaev --Sig_/E70VSwE+9JiP5gRVx//pJ68 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iD8DBQFOHLH+Q6z1jMm+XZYRAsm5AKDO16/zGI2beKzgA3Zfh1xb+1qScgCeJabW 9fj5pdmv8riwJ5Dp4kd2MJU= =HDnc -----END PGP SIGNATURE----- --Sig_/E70VSwE+9JiP5gRVx//pJ68-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 12 20:43: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 59D541065672; Tue, 12 Jul 2011 20:43:47 +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 BC1AD8FC0A; Tue, 12 Jul 2011 20:43:46 +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 p6CKhb6B028884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Jul 2011 23:43:37 +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 p6CKhbAF014322; Tue, 12 Jul 2011 23:43:37 +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 p6CKhb4j014321; Tue, 12 Jul 2011 23:43:37 +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: Tue, 12 Jul 2011 23:43:37 +0300 From: Kostik Belousov To: Petr Salinger Message-ID: <20110712204337.GJ43872@deviant.kiev.zoral.com.ua> References: <20110711150614.GV43872@deviant.kiev.zoral.com.ua> <20110711154102.GW43872@deviant.kiev.zoral.com.ua> <20110711172408.GX43872@deviant.kiev.zoral.com.ua> <20110711180246.GA43872@deviant.kiev.zoral.com.ua> <20110712103526.GF43872@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZP5/UaesXwhUwRsu" Content-Disposition: inline In-Reply-To: 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.3 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, Robert Millan , current@freebsd.org Subject: Re: [PATCH] Improve LinuxThreads compatibility in rfork() 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, 12 Jul 2011 20:43:47 -0000 --ZP5/UaesXwhUwRsu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 12, 2011 at 04:36:24PM +0200, Petr Salinger wrote: > >Below is the patch I intend to commit after you retest it. >=20 > I applied it against our 8.2 based package, > altered our "clone" to use this new=20 > interface and run eglibc testsuite. No regression. >=20 > Our runtime detection of this new interface will be based > on "sysctl kern.osreldate". I will bump revision for stable/8 when merging, but I do not see much reason to bump on HEAD right now. >=20 >=20 > >some rewording to the manual page. >=20 > You might want to reword also RFLINUXTHPN part > "kernel will return" -> "kernel will deliver" >=20 > Can we expect MFC before 8.3 release ? I just committed this to HEAD. Will MFC in a week, unless some problems arise. --ZP5/UaesXwhUwRsu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk4csfgACgkQC3+MBN1Mb4jj2wCfRxS9QKW9g+5lBx/tYqZKkXLU YJsAn0/H9x2olqhbuyRmi0Lk9sMpCmci =BLhR -----END PGP SIGNATURE----- --ZP5/UaesXwhUwRsu-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 12 21:06:13 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 A421A106566C; Tue, 12 Jul 2011 21:06:13 +0000 (UTC) (envelope-from rmh.aybabtu@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 60D778FC0C; Tue, 12 Jul 2011 21:06:13 +0000 (UTC) Received: by iyb11 with SMTP id 11so6450350iyb.13 for ; Tue, 12 Jul 2011 14:06:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=8pDwIWnNGqCqHzoyxZoNMUL68gr3cYARECJNiorBLns=; b=F1vSmk6jaizJz2xGMdSToZe8Dyk7t/iEr2qfY8x2vftVX5XL1lF7WNM1Is6tTPUf9r SpzyCQmZFvUrXg/3SYBzlqJxap9Tjzxrwmz+qF9U0GOt53RpgcC/9SVxobs9Q+dUeG2b tNuCApOILwpP7MaHByCXrOoW9rc9p4Cd5Jw14= MIME-Version: 1.0 Received: by 10.42.204.3 with SMTP id fk3mr332814icb.515.1310504772730; Tue, 12 Jul 2011 14:06:12 -0700 (PDT) Sender: rmh.aybabtu@gmail.com Received: by 10.42.222.7 with HTTP; Tue, 12 Jul 2011 14:06:12 -0700 (PDT) In-Reply-To: <20110712164337.07e387eb@kan.dnsalias.net> References: <20110712164337.07e387eb@kan.dnsalias.net> Date: Tue, 12 Jul 2011 23:06:12 +0200 X-Google-Sender-Auth: GKoTVnla8ZTgztJ5UgAWbM0OoqY Message-ID: From: Robert Millan To: Alexander Kabaev Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org, Ed Maste , Oliver Pinter Subject: Re: [PATCH] fake pre-processor macros when building on non-FreeBSD system 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, 12 Jul 2011 21:06:13 -0000 2011/7/12 Alexander Kabaev : > Whatever happened to using a proper cross-tool to do the job? Why would one need to build a cross-compiler in order to compile userland-agnostic code for the same CPU architecture? This would be like requiring a cross-compiler in order to build things like GRUB or SeaBIOS. > Why is this hack needed? The kernel tree expects flags like __linux__ or __FreeBSD__ to have a different meaning when compiling for kernel space. Instead of "we're building code that will run on $foo", they mean "we're building $foo itself". This assumption is correct most of the time, but not always so. My patch addresses some of the situations in which the assumption fails. -- Robert Millan From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 12 21:21: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 B70AC106566C; Tue, 12 Jul 2011 21:21:37 +0000 (UTC) (envelope-from rmh.aybabtu@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 6F85E8FC17; Tue, 12 Jul 2011 21:21:37 +0000 (UTC) Received: by iyb11 with SMTP id 11so6462960iyb.13 for ; Tue, 12 Jul 2011 14:21:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=fdqc2hRlmcqUaXGPyjvOCvc1xbsAIMh57CEIWrUI5Ms=; b=QV5/ygVwdx37QYp6k8ONTLr8vszdZJV6pnF3qQbdFLxMblhrKGKFdq4AvYJus1lQK9 xLJYw5LSx1vs1ljE8BISJDmeD3K/amnyorUzX+ah/mYYS+rSDVmRN530zp1pXMMYdxlG B8Lz80nLKwP5Ptd9b8pCX4bY8tUMRboxG7d60= MIME-Version: 1.0 Received: by 10.42.147.65 with SMTP id m1mr360844icv.46.1310505696679; Tue, 12 Jul 2011 14:21:36 -0700 (PDT) Sender: rmh.aybabtu@gmail.com Received: by 10.42.222.7 with HTTP; Tue, 12 Jul 2011 14:21:36 -0700 (PDT) In-Reply-To: <20110712204337.GJ43872@deviant.kiev.zoral.com.ua> References: <20110711150614.GV43872@deviant.kiev.zoral.com.ua> <20110711154102.GW43872@deviant.kiev.zoral.com.ua> <20110711172408.GX43872@deviant.kiev.zoral.com.ua> <20110711180246.GA43872@deviant.kiev.zoral.com.ua> <20110712103526.GF43872@deviant.kiev.zoral.com.ua> <20110712204337.GJ43872@deviant.kiev.zoral.com.ua> Date: Tue, 12 Jul 2011 23:21:36 +0200 X-Google-Sender-Auth: TzrqMztSGscTL1Wu-_C6JGRnImw Message-ID: From: Robert Millan To: Kostik Belousov Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org, current@freebsd.org, Petr Salinger Subject: Re: [PATCH] Improve LinuxThreads compatibility in rfork() 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, 12 Jul 2011 21:21:37 -0000 2011/7/12 Kostik Belousov : > I just committed this to HEAD. Will MFC in a week, unless some problems > arise. Thanks! > I will bump revision for stable/8 when merging, but I do not see much > reason to bump on HEAD right now. Uhm I think we can survive without a bump in HEAD. For now we will need to keep our backward-compatibility patch anyway, and when the bump happens on stable/8 our sysctl comparison will identify 900039 as new ABI. Petr is that correct? -- Robert Millan From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 12 21:38: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 0BC301065673; Tue, 12 Jul 2011 21:38:12 +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 A06078FC14; Tue, 12 Jul 2011 21:38:11 +0000 (UTC) Received: by vws18 with SMTP id 18so5238329vws.13 for ; Tue, 12 Jul 2011 14:38:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; bh=mQP06jiZAQhTok4F3PTr0tRo3Ln5JHlG/wevEJbrflk=; b=rD1RSzntgYDFoHS3Tg72jF/hdfPmLSbZfS6MybXcc/AtudGTPF/v4YLn/c1bAyX3mc DPcM4qzX/9lJrMD9XNUgh8fad5uirVR+3N1L3bkLpD5GUdngkqtGvl3nQcoHLAQIZzix FxcUi2OgVrjCGGOTmnrmNcqs+22ZWYFwErXIw= Received: by 10.52.22.148 with SMTP id d20mr429083vdf.453.1310506690705; Tue, 12 Jul 2011 14:38:10 -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 bd5sm2401925vcb.35.2011.07.12.14.38.09 (version=SSLv3 cipher=OTHER); Tue, 12 Jul 2011 14:38:09 -0700 (PDT) Date: Tue, 12 Jul 2011 17:38:03 -0400 From: Alexander Kabaev To: Robert Millan Message-ID: <20110712173803.4979d741@kan.dnsalias.net> In-Reply-To: References: <20110712164337.07e387eb@kan.dnsalias.net> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/CDX74KCQylI=NdEgh1ZfMG1"; protocol="application/pgp-signature" Cc: freebsd-hackers@freebsd.org, Ed, Maste , Oliver Pinter Subject: Re: [PATCH] fake pre-processor macros when building on non-FreeBSD system 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, 12 Jul 2011 21:38:12 -0000 --Sig_/CDX74KCQylI=NdEgh1ZfMG1 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 12 Jul 2011 23:06:12 +0200 Robert Millan wrote: > 2011/7/12 Alexander Kabaev : > > Whatever happened to using a proper cross-tool to do the job? >=20 > Why would one need to build a cross-compiler in order to compile > userland-agnostic code for the same CPU architecture? This would be > like requiring a cross-compiler in order to build things like GRUB or > SeaBIOS. >=20 > > Why is this hack needed? >=20 > The kernel tree expects flags like __linux__ or __FreeBSD__ to have a > different meaning when compiling for kernel space. Instead of "we're > building code that will run on $foo", they mean "we're building $foo > itself". This assumption is correct most of the time, but not always > so. My patch addresses some of the situations in which the assumption > fails. >=20 > --=20 > Robert Millan The fact that Linux compiler with manually undefined and re-defined platform macros can compile is a coincidence and is not guaranteed to work and certainly is not a goal of FreeBSD project so this can be broken at any moment. Relying on that is unwise, putting hacks into FreeBSD sources to legitimize the practice is not the move I would support as well. Traditionally, IMHO. --=20 Alexander Kabaev --Sig_/CDX74KCQylI=NdEgh1ZfMG1 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iD8DBQFOHL6/Q6z1jMm+XZYRAgbpAJ9a/Cfw3W/rYKV/A/ZxuxL3V9C1EQCgop6T SbL4a1iQYhKO1Mw/5rGSEyM= =EVg+ -----END PGP SIGNATURE----- --Sig_/CDX74KCQylI=NdEgh1ZfMG1-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 12 21:44: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 9AAB61065673; Tue, 12 Jul 2011 21:44:25 +0000 (UTC) (envelope-from Petr.Salinger@seznam.cz) Received: from relay.felk.cvut.cz (relay.felk.cvut.cz [147.32.80.7]) by mx1.freebsd.org (Postfix) with ESMTP id 1850B8FC17; Tue, 12 Jul 2011 21:44:23 +0000 (UTC) Received: from sci.felk.cvut.cz (sci.felk.cvut.cz [147.32.83.100]) by relay.felk.cvut.cz (8.14.4/8.14.4) with ESMTP id p6CLi5W0093602; Tue, 12 Jul 2011 23:44:05 +0200 (CEST) (envelope-from Petr.Salinger@seznam.cz) Date: Tue, 12 Jul 2011 23:53:05 +0200 (CEST) From: Petr Salinger X-X-Sender: salinger@sci.felk.cvut.cz To: Robert Millan In-Reply-To: Message-ID: References: <20110711150614.GV43872@deviant.kiev.zoral.com.ua> <20110711154102.GW43872@deviant.kiev.zoral.com.ua> <20110711172408.GX43872@deviant.kiev.zoral.com.ua> <20110711180246.GA43872@deviant.kiev.zoral.com.ua> <20110712103526.GF43872@deviant.kiev.zoral.com.ua> <20110712204337.GJ43872@deviant.kiev.zoral.com.ua> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-FELK-MailScanner-Information: X-MailScanner-ID: p6CLi5W0093602 X-FELK-MailScanner: Found to be clean X-FELK-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-1.119, required 6, AWL 0.00, BAYES_00 -1.90, FREEMAIL_FROM 0.00, SPF_NEUTRAL 0.78) X-FELK-MailScanner-From: petr.salinger@seznam.cz X-FELK-MailScanner-To: current@freebsd.org, freebsd-hackers@freebsd.org, kostikbel@gmail.com, rmh@debian.org X-FELK-MailScanner-Watermark: 1311111846.61093@TuNctzhbfAQ3xyu/Wv33mw X-Spam-Status: No Cc: Kostik Belousov , freebsd-hackers@freebsd.org, current@freebsd.org Subject: Re: [PATCH] Improve LinuxThreads compatibility in rfork() 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, 12 Jul 2011 21:44:25 -0000 >> I will bump revision for stable/8 when merging, but I do not see much >> reason to bump on HEAD right now. Many thanks. > Uhm I think we can survive without a bump in HEAD. For now we will > need to keep our backward-compatibility patch anyway, and when the > bump happens on stable/8 our sysctl comparison will identify 900039 as > new ABI. We cannot survive without a bump in HEAD before 9.0 release, but we do not need bump immediately. So far the condition for new API will be if ( (osreldate >= 900040) || ((osreldate >= 803000) && (osreldate < 900000))) Of course, when MFC will bump revision, the 803000 constant will change (probably to 802509). Petr From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 12 21:57:11 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 8F633106564A; Tue, 12 Jul 2011 21:57:11 +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 F264E8FC15; Tue, 12 Jul 2011 21:57:10 +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 p6CLurYX034236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Jul 2011 00:56:53 +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 p6CLurmm016966; Wed, 13 Jul 2011 00:56:53 +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 p6CLurWx016965; Wed, 13 Jul 2011 00:56:53 +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: Wed, 13 Jul 2011 00:56:53 +0300 From: Kostik Belousov To: Petr Salinger Message-ID: <20110712215653.GL43872@deviant.kiev.zoral.com.ua> References: <20110711172408.GX43872@deviant.kiev.zoral.com.ua> <20110711180246.GA43872@deviant.kiev.zoral.com.ua> <20110712103526.GF43872@deviant.kiev.zoral.com.ua> <20110712204337.GJ43872@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="t3wCcZxwnWQbJWrM" Content-Disposition: inline In-Reply-To: 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.3 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, Robert Millan , current@freebsd.org Subject: Re: [PATCH] Improve LinuxThreads compatibility in rfork() 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, 12 Jul 2011 21:57:11 -0000 --t3wCcZxwnWQbJWrM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 12, 2011 at 11:53:05PM +0200, Petr Salinger wrote: > >>I will bump revision for stable/8 when merging, but I do not see much > >>reason to bump on HEAD right now. >=20 > Many thanks. >=20 > >Uhm I think we can survive without a bump in HEAD. For now we will > >need to keep our backward-compatibility patch anyway, and when the > >bump happens on stable/8 our sysctl comparison will identify 900039 as > >new ABI. >=20 > We cannot survive without a bump in HEAD before 9.0 release, > but we do not need bump immediately. Right, the point is that you can just say 'do not use 9.0-current earlier then r223966', and check only for >=3D 8025XX, where XX is the bump at MFC. >=20 > So far the condition for new API will be >=20 > if ( (osreldate >=3D 900040) > || ((osreldate >=3D 803000) && (osreldate < 900000))) >=20 > Of course, when MFC will bump revision, the 803000 constant > will change (probably to 802509). >=20 > Petr --t3wCcZxwnWQbJWrM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk4cwyQACgkQC3+MBN1Mb4ijWwCg5tbkrkKTj6AWRwHoNUjA++Co TVoAoMEjk2Hk8pafGLB/aKKFJP6M0wM8 =bIEd -----END PGP SIGNATURE----- --t3wCcZxwnWQbJWrM-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 12 21:59: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 93D33106566B; Tue, 12 Jul 2011 21:59:07 +0000 (UTC) (envelope-from rmh.aybabtu@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 503448FC14; Tue, 12 Jul 2011 21:59:07 +0000 (UTC) Received: by iyb11 with SMTP id 11so6491614iyb.13 for ; Tue, 12 Jul 2011 14:59:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=77pkdiwUePTN1BK9+N7dGKIToV0ax4N4uD8OlmqiBlM=; b=pXnYmskl7dnsJ056perVKnHaNQ0KUzULx4Uuu9CqgffG6PdI+K1D1eOAGcAnbKSn1v saCRNYIG1fXBllL7Ks2d2GmGahXzAlNOrBSnBckqW3R8TpWsPQ03njkwjKNlnxqxHnaP hQYvBK9GGIyzc71zld/5DfPpI/HICZU43jcZ4= MIME-Version: 1.0 Received: by 10.42.100.72 with SMTP id z8mr399673icn.448.1310507945494; Tue, 12 Jul 2011 14:59:05 -0700 (PDT) Sender: rmh.aybabtu@gmail.com Received: by 10.42.222.7 with HTTP; Tue, 12 Jul 2011 14:59:05 -0700 (PDT) In-Reply-To: <20110712173803.4979d741@kan.dnsalias.net> References: <20110712164337.07e387eb@kan.dnsalias.net> <20110712173803.4979d741@kan.dnsalias.net> Date: Tue, 12 Jul 2011 23:59:05 +0200 X-Google-Sender-Auth: g4PDJwQH1ToJOkcd_HEX4qxZzAM Message-ID: From: Robert Millan To: Alexander Kabaev Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org, Ed Maste , Oliver Pinter Subject: Re: [PATCH] fake pre-processor macros when building on non-FreeBSD system 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, 12 Jul 2011 21:59:07 -0000 2011/7/12 Alexander Kabaev : > The fact that Linux compiler with manually undefined and re-defined > platform macros can compile is a coincidence and is not guaranteed to > work and certainly is not a goal of FreeBSD project so this can be > broken at any moment. There must be some missunderstanding, I never asked the FreeBSD project to garantee this works, or that it won't break in the future. I'm not holding anyone responsible in case it breaks, or anything similar to that. Once it works, however, it is not a coincidence: We've been working to archieve this (most of my other patches sent to this list go in this direction). That aside, it seems there's some interest in FreeBSD community about building the kernel on GNU/Linux. In particular, MIPS porters have it in their TODO list: http://wiki.freebsd.org/FreeBSD/mips/todo > putting hacks into > FreeBSD sources to legitimize the practice is not the move I would > support as well. Traditionally, IMHO. I try to take a neutral stance and merely follow on what the source tree expects. If the source tree does things like: #ifdef __FreeBSD__ // code that expects to be built as part of the FreeBSD kernel tree // (this chunk of code is invariably what we want, no matter the compiler we're using) #endif #ifdef __linux__ // code that expects to be built as part of the Linux tree // (this chunk of code depends on out-of-tree headers and will never build, no matter the compiler we're using) #endif I naively read this as "when building kernel code, we assume these macros refer to *what* we're building rather than to what are we building it *for*". My naive mind can't tell if this assumption is correct or not, it merely tries to adapt to existing practice. If the assumption is not correct, then I would propose a different kind of solution to the problem. So before we proceed, could you clarify whether the assumption is correct or not? -- Robert Millan From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 12 21:59:14 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 C314A106570F; Tue, 12 Jul 2011 21:59:14 +0000 (UTC) (envelope-from oliver.pntr@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 71D708FC1D; Tue, 12 Jul 2011 21:59:14 +0000 (UTC) Received: by yxl31 with SMTP id 31so1144104yxl.13 for ; Tue, 12 Jul 2011 14:59:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XyhjoclBdjAyXgw2c6IboJdfQn9HRnkP+6up7VgNmtc=; b=nMFzLVU0UX5gnykJ7dK/0maHHgM3y6Vpsox+80QeljN1hTfqyssjDi/P1GZkgU2BwY V56bvyoVOH/n/nYPGGEl32k5ejyshoLSkYJaxx7Y1iq8dKUs7kW9ITiLtrNZj4uMalu1 9LCGaOGXcEpKc37JkSMPYFh+InDuBb4GKKGJU= MIME-Version: 1.0 Received: by 10.150.253.15 with SMTP id a15mr658233ybi.160.1310506332024; Tue, 12 Jul 2011 14:32:12 -0700 (PDT) Received: by 10.150.138.14 with HTTP; Tue, 12 Jul 2011 14:32:11 -0700 (PDT) In-Reply-To: References: Date: Tue, 12 Jul 2011 23:32:11 +0200 Message-ID: From: Oliver Pinter To: Robert Millan Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, Ed Maste Subject: Re: [PATCH] fake pre-processor macros when building on non-FreeBSD system 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, 12 Jul 2011 21:59:14 -0000 On 7/12/11, Robert Millan wrote: > 2011/7/12 Oliver Pinter : >> +.if ${OPSYS} != "FreeBSD" >> >> and what's the status example on NetBSD? > > I didn't think of it. There are some instances of __NetBSD__ and also > __OpenBSD__ in the kernel tree, and the same problem can be fixed for > these two systems with minimal effort. > > Here's a new version of the patch, which also adds -U__NetBSD__ and > -U__OpenBSD__ to CFLAGS. > > -- > Robert Millan > This seem like an ugly hack.. Please keep in your mind, FreeBSD is not linux; and I hope, never be From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 12 22:12:43 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 095BF1065670 for ; Tue, 12 Jul 2011 22:12:43 +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 D15728FC19 for ; Tue, 12 Jul 2011 22:12:42 +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 <0LO80050IO95ID00@smtpauth1.wiscmail.wisc.edu>; Tue, 12 Jul 2011 16:12:41 -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 <0LO800F24O92YH40@smtpauth1.wiscmail.wisc.edu>; Tue, 12 Jul 2011 16:12:38 -0500 (CDT) Date: Tue, 12 Jul 2011 16:12:38 -0500 From: Nathan Whitehorn In-reply-to: To: Robert Millan Message-id: <4E1CB8C6.7090405@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=128.104.160.176 X-Spam-PmxInfo: Server=avs-9, Version=5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.7.12.210317, SenderIP=128.104.160.176 References: <20110712164337.07e387eb@kan.dnsalias.net> User-Agent: Mozilla/5.0 (X11; U; FreeBSD powerpc; en-US; rv:1.9.2.18) Gecko/20110706 Thunderbird/3.1.11 Cc: freebsd-hackers@freebsd.org, Ed Maste , Oliver Pinter Subject: Re: [PATCH] fake pre-processor macros when building on non-FreeBSD system 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, 12 Jul 2011 22:12:43 -0000 On 07/12/11 16:06, Robert Millan wrote: > 2011/7/12 Alexander Kabaev: >> Whatever happened to using a proper cross-tool to do the job? > Why would one need to build a cross-compiler in order to compile > userland-agnostic code for the same CPU architecture? This would be > like requiring a cross-compiler in order to build things like GRUB or > SeaBIOS. For one, it might have a different ABI, which isn't actually that different an issue than the one you find yourself facing. -Nathan From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 12 22:28: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 7D20E1065670 for ; Tue, 12 Jul 2011 22:28:04 +0000 (UTC) (envelope-from falkman@gamozo.org) Received: from que11.charter.net (que11.charter.net [209.225.8.21]) by mx1.freebsd.org (Postfix) with ESMTP id 177298FC0A for ; Tue, 12 Jul 2011 22:28:02 +0000 (UTC) Received: from imp10 ([10.20.200.15]) by mta31.charter.net (InterMail vM.7.09.02.04 201-2219-117-106-20090629) with ESMTP id <20110712221006.KDYJ3994.mta31.charter.net@imp10> for ; Tue, 12 Jul 2011 18:10:06 -0400 Received: from [192.168.1.115] ([75.135.75.204]) by imp10 with smtp.charter.net id 7AA61h0024QU3rf05AA6Xa; Tue, 12 Jul 2011 18:10:06 -0400 X-Authority-Analysis: v=1.1 cv=G6Q69DB3AUoJKS2BpLRaz8MQ2NORN7h5HRzrJMPOhRw= c=1 sm=1 a=CpZYxkIGCHkA:10 a=1oZn42fZWVAA:10 a=EZ1XIdwCItEA:10 a=8nJEP1OIZ-IA:10 a=HEs2YkztZRVyeANDsLw8Eg==:17 a=yArUfgI9z4XnWFJVbgcA:9 a=4V3MPM6CZksUHslxwK8A:7 a=wPNLvfGTeEIA:10 a=HEs2YkztZRVyeANDsLw8Eg==:117 Message-ID: <4E1CC63D.6040606@gamozo.org> Date: Tue, 12 Jul 2011 17:10:05 -0500 From: Brandon Falk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: System Fails to Boot (Deadlock?) 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, 12 Jul 2011 22:28:04 -0000 Hello, My machine somehow fails to boot into FreeBSD (off the cd, since it fails to boot, I can't install it in the first place). It goes through and ends up stopping deadlock style. No printouts of errors (besides a ppc problem, which is not fatal) and no crash/oops/panic. It just... stops and locks up. I know my motherboards PCI system has failed, as well as lan (getting a new one tomorrow), which is probably what is causing the problem. The thing is that Windows 7 and Linux happen to boot just fine on my machine, so although my system has a failing motherboard and may cause errors, I still feel like it shouldn't be causing this much of an issue on boot. I tried verbose logging and got no more information anyways. It will be nearly impossible to diagnose this error so I'm looking for tips on where to look. I'm an avid programmer and I could fix the problem if I were able to find it. I could just compile custom kernels to give printout and debug messages every step, but that would be a long process if there is a better way. Keep in mind I do not have FreeBSD installed, no serial or parallel ports, and I'm booting from a CD. Once I get the new motherboard I will probably not care about fixing this problem, as I'd be replacing it. So this is more of an overnight deal that I'd like to look into. System: Intel i7 970 24GB ram Asus Sabertooth X58 motherboard If you need more system info, I'd be glad to give it. -Brandon Falk From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 12 22:33: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 303DC106564A; Tue, 12 Jul 2011 22:33:02 +0000 (UTC) (envelope-from rmh.aybabtu@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 CF4348FC0C; Tue, 12 Jul 2011 22:33:01 +0000 (UTC) Received: by iyb11 with SMTP id 11so6516101iyb.13 for ; Tue, 12 Jul 2011 15:33:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=9AfH0jEL1sfR47pdBeRPi7L6vqFg2x3BTJgbmxd0HP4=; b=tEJJWkvoXbUACT1QYDBeH9pPalBFCQr9Ml707ln+Dkl45xTVraXnY3LoqeV8soeaIl zrxJyJyMUDqsup0qWc/Nu93FPzAPQFKFHEaQLvtsO0zNytVbuNAMPU0LCvSa6bOPvMxt dSvcLki79ng6vwMMqfJ3zUgVoC5cOsGKwWVtw= MIME-Version: 1.0 Received: by 10.42.146.133 with SMTP id j5mr401813icv.180.1310509981102; Tue, 12 Jul 2011 15:33:01 -0700 (PDT) Sender: rmh.aybabtu@gmail.com Received: by 10.42.222.7 with HTTP; Tue, 12 Jul 2011 15:33:01 -0700 (PDT) In-Reply-To: <4E1CB8C6.7090405@freebsd.org> References: <20110712164337.07e387eb@kan.dnsalias.net> <4E1CB8C6.7090405@freebsd.org> Date: Wed, 13 Jul 2011 00:33:01 +0200 X-Google-Sender-Auth: 5lK_rVzbU_hShPDTAr4JaizCYxQ Message-ID: From: Robert Millan To: Nathan Whitehorn Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Ed Maste , Oliver Pinter Subject: Re: [PATCH] fake pre-processor macros when building on non-FreeBSD system 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, 12 Jul 2011 22:33:02 -0000 2011/7/12 Nathan Whitehorn : > On 07/12/11 16:06, Robert Millan wrote: >> Why would one need to build a cross-compiler in order to compile >> userland-agnostic code for the same CPU architecture? =C2=A0This would b= e >> like requiring a cross-compiler in order to build things like GRUB or >> SeaBIOS. > > For one, it might have a different ABI, which isn't actually that differe= nt > an issue than the one you find yourself facing. ABI can mean many things in this context. It could mean libc ABI, it could mean internal kernel interfaces, or even C calling conventions. When it comes to libc and syscall ABI, it doesn't really matter which one we provide, because -nostdinc -nostdlib completely discards it, as the kernel doesn't use any libc headers or link with libc in any way. When it comes to internal kernel interfaces, a few of them can be selected in the FreeBSD kernel tree: the FreeBSD one, the NetBSD one, the OpenBSD one, even the Linux interface. However, only one of them (FreeBSD interface) is implemented. If you select e.g. NetBSD interface you get build errors such as "sys/device.h not found". Those errors happen because the NetBSD interface was selected for building the kernel of FreeBSD, NOT because we're building on FreeBSD. They would happen all the same if we attempted this on any other platform, including NetBSD. --=20 Robert Millan From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 12 23:07: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 79CCA1065670; Tue, 12 Jul 2011 23:07:25 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from agogare.doit.wisc.edu (agogare.doit.wisc.edu [144.92.197.211]) by mx1.freebsd.org (Postfix) with ESMTP id 4B9688FC15; Tue, 12 Jul 2011 23:07:25 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth2.wiscmail.wisc.edu by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0LO800E00TKCIC00@smtpauth2.wiscmail.wisc.edu>; Tue, 12 Jul 2011 18:07:24 -0500 (CDT) Received: from anacreon.physics.wisc.edu (anacreon.physics.wisc.edu [128.104.160.176]) by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0LO8003Z4TKBHX20@smtpauth2.wiscmail.wisc.edu>; Tue, 12 Jul 2011 18:07:23 -0500 (CDT) Date: Tue, 12 Jul 2011 18:07:23 -0500 From: Nathan Whitehorn In-reply-to: To: Robert Millan Message-id: <4E1CD3AB.3030106@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=128.104.160.176 X-Spam-PmxInfo: Server=avs-11, Version=5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.7.12.225415, SenderIP=128.104.160.176 References: <20110712164337.07e387eb@kan.dnsalias.net> <4E1CB8C6.7090405@freebsd.org> User-Agent: Mozilla/5.0 (X11; U; FreeBSD powerpc; en-US; rv:1.9.2.18) Gecko/20110706 Thunderbird/3.1.11 Cc: freebsd-hackers@freebsd.org, Ed Maste , Oliver Pinter Subject: Re: [PATCH] fake pre-processor macros when building on non-FreeBSD system 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, 12 Jul 2011 23:07:25 -0000 On 07/12/11 17:33, Robert Millan wrote: > 2011/7/12 Nathan Whitehorn: >> On 07/12/11 16:06, Robert Millan wrote: >>> Why would one need to build a cross-compiler in order to compile >>> userland-agnostic code for the same CPU architecture? This would be >>> like requiring a cross-compiler in order to build things like GRUB or >>> SeaBIOS. >> For one, it might have a different ABI, which isn't actually that different >> an issue than the one you find yourself facing. > ABI can mean many things in this context. It could mean libc ABI, it > could mean internal kernel interfaces, or even C calling conventions. The one I meant was the third one. Linux and FreeBSD happen, though not entirely by chance, to use almost exactly the same ABI on most platforms (but not all!). Assuming, and requiring, interchangeability of ABIs here thus seems like a poor choice. Once you've decided you might have a different ABI, you need a cross-compiler, and that would simultaneously take care of defining various platform-specific macros. The "isn't actually that different" comment, which wasn't a particularly useful thing to say, was that you could conceivably claim, under very broad definitions of what ABI means, that having __FreeBSD__ defined is in fact a part of the system ABI, just like the calling conventions or the stack frame layout. In either case, you would be expected to use a cross-compiler. -Nathan From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 12 23:39:44 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 C8A30106564A; Tue, 12 Jul 2011 23:39:44 +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 6B5488FC18; Tue, 12 Jul 2011 23:39:44 +0000 (UTC) Received: by vws18 with SMTP id 18so5314241vws.13 for ; Tue, 12 Jul 2011 16:39:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; bh=NbiITQ5co9SEIWYuO1m4aZZ11h6ydup2XvZiF3MLqR8=; b=eV/IveKmr7E5NyaZDMjCSjwQcyei3D0xBGImJ27BeWB+Cn/+9MEekIEMRSOPM92VKN U0tlv4IREnXWqndIpzwEJ5rKG007tGYMJhoUN13M53NqkH1FZ2cuBYlaFwEjR7DlGyrK CjwAQwnUIBZEAgsA4tZ+aJDYpOCBBk1rPM0A0= Received: by 10.220.92.9 with SMTP id p9mr38851vcm.68.1310513983414; Tue, 12 Jul 2011 16:39:43 -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 ej19sm1458156vcb.6.2011.07.12.16.39.41 (version=SSLv3 cipher=OTHER); Tue, 12 Jul 2011 16:39:42 -0700 (PDT) Date: Tue, 12 Jul 2011 19:39:35 -0400 From: Alexander Kabaev To: Robert Millan Message-ID: <20110712193935.507892a2@kan.dnsalias.net> In-Reply-To: References: <20110712164337.07e387eb@kan.dnsalias.net> <20110712173803.4979d741@kan.dnsalias.net> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/fMebwPRXiZrlMCEm+9ZlMIq"; protocol="application/pgp-signature" Cc: freebsd-hackers@freebsd.org, Ed, Maste , Oliver Pinter Subject: Re: [PATCH] fake pre-processor macros when building on non-FreeBSD system 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, 12 Jul 2011 23:39:44 -0000 --Sig_/fMebwPRXiZrlMCEm+9ZlMIq Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 12 Jul 2011 23:59:05 +0200 Robert Millan wrote: > 2011/7/12 Alexander Kabaev : > > The fact that Linux compiler with manually undefined and re-defined > > platform macros can compile is a coincidence and is not guaranteed > > to work and certainly is not a goal of FreeBSD project so this can > > be broken at any moment. >=20 > There must be some missunderstanding, I never asked the FreeBSD > project to garantee this works, or that it won't break in the future. > I'm not holding anyone responsible in case it breaks, or anything > similar to that. >=20 > Once it works, however, it is not a coincidence: We've been working to > archieve this (most of my other patches sent to this list go in this > direction). >=20 But it is the coincidence. See the other email by Nathan, I could not have said it better. Just defining __FreeBSD__ in Linux compiler does not magically turn it into compiler for FreeBSD. > That aside, it seems there's some interest in FreeBSD community about > building the kernel on GNU/Linux. In particular, MIPS porters have it > in their TODO list: > http://wiki.freebsd.org/FreeBSD/mips/todo >=20 Not sure what they mean there. There is a general desire for FreeBSD to be able to build the first set of bootstrap tools on other OSes (Linux, MAC OS X) that has come up several times in recent years. Host tools were to be used to build cross-toolchain only in all discussions I've been part of so far. > > putting hacks into > > FreeBSD sources to legitimize the practice is not the move I would > > support as well. Traditionally, IMHO. >=20 > I try to take a neutral stance and merely follow on what the source > tree expects. If the source tree does things like: >=20 > #ifdef __FreeBSD__ > // code that expects to be built as part of the FreeBSD kernel tree > // (this chunk of code is invariably what we want, no matter the > compiler we're using) > #endif >=20 > #ifdef __linux__ > // code that expects to be built as part of the Linux tree > // (this chunk of code depends on out-of-tree headers and will never > build, no matter the compiler we're using) > #endif >=20 > I naively read this as "when building kernel code, we assume these > macros refer to *what* we're building rather than to what are we > building it *for*". >=20 See Nathan's email again. __FreeBSD__ also means that code can expect certain ABI or some other detail to match established FreeBSD practice, which are not necessarily adhered to by the Linux compiler. Take your own example and imagine using the same assumption with Mac OS X toolchain. *what* and *for* both apply here, if I understand your dilemma correctly. > My naive mind can't tell if this assumption is correct or not, it > merely tries to adapt to existing practice. If the assumption is not > correct, then I would propose a different kind of solution to the > problem. >=20 > So before we proceed, could you clarify whether the assumption is > correct or not? >=20 --=20 Alexander Kabaev --Sig_/fMebwPRXiZrlMCEm+9ZlMIq Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iD8DBQFOHNs8Q6z1jMm+XZYRAr5dAJ41p2l4Rly/MGiqZQNfNBGrIwEfLACg6VZz 7t1z/i/8z9t95SuEuX1iEms= =sUr5 -----END PGP SIGNATURE----- --Sig_/fMebwPRXiZrlMCEm+9ZlMIq-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 13 07:00:41 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 37BBE1065674; Wed, 13 Jul 2011 07:00:41 +0000 (UTC) (envelope-from rmh.aybabtu@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id D76E98FC17; Wed, 13 Jul 2011 07:00:40 +0000 (UTC) Received: by iwr19 with SMTP id 19so6812767iwr.13 for ; Wed, 13 Jul 2011 00:00:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=kFEKmIOcwM78BGsnXC/3vBhG/KD1dXCqz40bo+tip5c=; b=UVL+XKIPoRXfG1fLrUPyskkzUKm2vcXKmGSVYisbQhqWocMupyMsMNIzN5ce8ZxrgG OG4BV3WtWoksfntHPzr7PNnDaLlvmQmdQ6a5Ywh+sScP0KtISW0Juq6BuIwFROexDqgB djuJqvWkfes6BANbyz1A8VCnYLlAEPfFd1bXE= MIME-Version: 1.0 Received: by 10.42.73.9 with SMTP id q9mr878988icj.314.1310540440145; Wed, 13 Jul 2011 00:00:40 -0700 (PDT) Sender: rmh.aybabtu@gmail.com Received: by 10.42.222.7 with HTTP; Wed, 13 Jul 2011 00:00:39 -0700 (PDT) In-Reply-To: <4E1CD3AB.3030106@freebsd.org> References: <20110712164337.07e387eb@kan.dnsalias.net> <4E1CB8C6.7090405@freebsd.org> <4E1CD3AB.3030106@freebsd.org> Date: Wed, 13 Jul 2011 09:00:39 +0200 X-Google-Sender-Auth: bJUpEHp1L_ct74nducgH8_zK4iM Message-ID: From: Robert Millan To: Nathan Whitehorn Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org, Ed Maste , Oliver Pinter Subject: Re: [PATCH] fake pre-processor macros when building on non-FreeBSD system 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, 13 Jul 2011 07:00:41 -0000 2011/7/13 Nathan Whitehorn : > The one I meant was the third one. Linux and FreeBSD happen, though not > entirely by chance, to use almost exactly the same ABI on most platforms > (but not all!). Assuming, and requiring, interchangeability of ABIs here > thus seems like a poor choice. Once you've decided you might have a > different ABI, you need a cross-compiler, and that would simultaneously take > care of defining various platform-specific macros. > > The "isn't actually that different" comment, which wasn't a particularly > useful thing to say, was that you could conceivably claim, under very broad > definitions of what ABI means, that having __FreeBSD__ defined is in fact a > part of the system ABI, just like the calling conventions or the stack frame > layout. In either case, you would be expected to use a cross-compiler. I understand the problem you describe, but I don't see how this is related to the presence of those macros. C ABI is selected with compiler flags such as -mabi=n32 or -mregparm=3. There's no technical requirement for your kernel ABI to match your userland ABI. If it does, it is an arbitrary choice (or coincidence). In either case, when you tell me that there's something special with regard to C ABI when GCC has been compiled for FreeBSD userland, I can't make any sense of this. In first place, because none of gcc/config/i386/freebsd.h implies it. In second place, because other projects (like GRUB) also have specific ABI requirements, and never had this kind of problem. However, there's clear evidence that none of this is intended in the source code. If existing practice in the FreeBSD tree supported your claim, you'd see things like: #ifndef __FreeBSD__ #error "we can't garantee that this compiler implements the desired C ABI" #endif but none of this happens. Instead, __FreeBSD__ is used to check for tautology: #ifdef __FreeBSD__ // working code here #elif __NetBSD__ // include headers that aren't present anywhere in the kernel tree #endif I understand the purpose of this, but please don't tell me it has anything to do with C ABI. -- Robert Millan From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 13 12:06: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 15F891065670 for ; Wed, 13 Jul 2011 12:06: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 E34508FC1B for ; Wed, 13 Jul 2011 12:06:27 +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 7EC0846B0A; Wed, 13 Jul 2011 08:06:27 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 1C7438A02F; Wed, 13 Jul 2011 08:06:27 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Wed, 13 Jul 2011 07:49:35 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <4E1CC63D.6040606@gamozo.org> In-Reply-To: <4E1CC63D.6040606@gamozo.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201107130749.35335.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 13 Jul 2011 08:06:27 -0400 (EDT) Cc: Brandon Falk Subject: Re: System Fails to Boot (Deadlock?) 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, 13 Jul 2011 12:06:28 -0000 On Tuesday, July 12, 2011 6:10:05 pm Brandon Falk wrote: > Hello, > > My machine somehow fails to boot into FreeBSD (off the cd, since it > fails to boot, I can't install it in the first place). It goes through > and ends up stopping deadlock style. No printouts of errors (besides a > ppc problem, which is not fatal) and no crash/oops/panic. It just... > stops and locks up. I know my motherboards PCI system has failed, as > well as lan (getting a new one tomorrow), which is probably what is > causing the problem. The thing is that Windows 7 and Linux happen to > boot just fine on my machine, so although my system has a failing > motherboard and may cause errors, I still feel like it shouldn't be > causing this much of an issue on boot. I tried verbose logging and got > no more information anyways. It will be nearly impossible to diagnose > this error so I'm looking for tips on where to look. How far does it get when it locks? Is it able to load /boot/loader off of the CD ok? Is it getting into the kernel far enough to output stuff to the console? Is it getting into sysinstall and hanging at some sysinstall screen? Also, is this host on the network and able to PXE? It's a lot easier to test custom kernels if needed using PXE than CDs (no need to burn a new CD each time, etc.). -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 14 01:14: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 0EA51106564A for ; Thu, 14 Jul 2011 01:14:40 +0000 (UTC) (envelope-from falkman@gamozo.org) Received: from mta11.charter.net (mta11.charter.net [216.33.127.80]) by mx1.freebsd.org (Postfix) with ESMTP id BB9C58FC12 for ; Thu, 14 Jul 2011 01:14:38 +0000 (UTC) Received: from imp10 ([10.20.200.15]) by mta11.charter.net (InterMail vM.7.09.02.04 201-2219-117-106-20090629) with ESMTP id <20110714011438.BFUG4091.mta11.charter.net@imp10> for ; Wed, 13 Jul 2011 21:14:38 -0400 Received: from [192.168.1.115] ([75.135.75.204]) by imp10 with smtp.charter.net id 7dEd1h00R4QU3rf05dEd7l; Wed, 13 Jul 2011 21:14:38 -0400 X-Authority-Analysis: v=1.1 cv=G6Q69DB3AUoJKS2BpLRaz8MQ2NORN7h5HRzrJMPOhRw= c=1 sm=1 a=CpZYxkIGCHkA:10 a=n2w-IegYaSwA:10 a=EZ1XIdwCItEA:10 a=8nJEP1OIZ-IA:10 a=HEs2YkztZRVyeANDsLw8Eg==:17 a=qSvyiPJel4O5c5DP35sA:9 a=YJKds1QQKK3uRXgrmhoA:7 a=wPNLvfGTeEIA:10 a=HEs2YkztZRVyeANDsLw8Eg==:117 Message-ID: <4E1E42FC.3080407@gamozo.org> Date: Wed, 13 Jul 2011 20:14:36 -0500 From: Brandon Falk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <4E1CC63D.6040606@gamozo.org> <201107130749.35335.jhb@freebsd.org> <4E1D9FA3.30403@gamozo.org> <4E1DC0B2.5070909@FreeBSD.org> In-Reply-To: <4E1DC0B2.5070909@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: System Fails to Boot (Deadlock?) 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, 14 Jul 2011 01:14:40 -0000 On 7/13/2011 10:58 AM, John Baldwin wrote: > On 7/13/11 9:37 AM, Brandon Falk wrote: >> On 7/13/2011 6:49 AM, John Baldwin wrote: >>> On Tuesday, July 12, 2011 6:10:05 pm Brandon Falk wrote: >>>> Hello, >>>> >>>> My machine somehow fails to boot into FreeBSD (off the cd, since it >>>> fails to boot, I can't install it in the first place). It goes through >>>> and ends up stopping deadlock style. No printouts of errors (besides a >>>> ppc problem, which is not fatal) and no crash/oops/panic. It just... >>>> stops and locks up. I know my motherboards PCI system has failed, as >>>> well as lan (getting a new one tomorrow), which is probably what is >>>> causing the problem. The thing is that Windows 7 and Linux happen to >>>> boot just fine on my machine, so although my system has a failing >>>> motherboard and may cause errors, I still feel like it shouldn't be >>>> causing this much of an issue on boot. I tried verbose logging and got >>>> no more information anyways. It will be nearly impossible to diagnose >>>> this error so I'm looking for tips on where to look. >>> How far does it get when it locks? Is it able to load /boot/loader off >>> of the CD ok? Is it getting into the kernel far enough to output stuff >>> to the >>> console? Is it getting into sysinstall and hanging at some sysinstall >>> screen? >>> >>> Also, is this host on the network and able to PXE? It's a lot easier >>> to test >>> custom kernels if needed using PXE than CDs (no need to burn a new CD >>> each >>> time, etc.). >>> >> >> Since it's on a native box, I have no good way of copying the text, so >> perhaps later I'll copy it by hand. /boot/loader launches just fine, and >> it's outputting messages just fine, until it just halts. It does not hit >> sysinstall. This box also does not have net as LAN is shot on the >> motherboard (hence getting the new motherboard). > > What is the last message it outputs before it hangs? > Hello, Sorry, I've been busy with work and I can't be bothered with rebooting my machine right now. But, it seems I have duplicated a very similar issue under a VM. Under the 9.0-CURRENT-201105-amd64-bootonly.iso iso it 'locks' up during boot with yet again no error message or crash. This only seems to happen when 8 cores are allocated to the VM, everything is just fine and dandy with 4, 2, or 1 core(s). (Note, on my native box I was using the 8.2-RELEASE amd64 bootonly iso). On the VM the last messages I get are: SMB: AP CPU #x Launched! x being a number inclusive and between 1-7, in a random order (obviously the cpus start at 'random' times). I cannot duplicate this error on a successfully installed FreeBSD-8.2-RELEASE-amd64 using the same hardware settings. Hmm, I just thought perhaps it is a CD issue... I tried FreeBSD-8.2-RELEASE-amd64-bootonly on 8, 4, 2, and 1 cores, and it seems to work just fine... argh. -Brandon From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 14 01:38:06 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 CBE11106566C for ; Thu, 14 Jul 2011 01:38:06 +0000 (UTC) (envelope-from falkman@gamozo.org) Received: from mta21.charter.net (mta21.charter.net [216.33.127.81]) by mx1.freebsd.org (Postfix) with ESMTP id 8AA008FC0A for ; Thu, 14 Jul 2011 01:38:06 +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 <20110714013805.OSDU3880.mta21.charter.net@imp10> for ; Wed, 13 Jul 2011 21:38:05 -0400 Received: from [192.168.1.115] ([75.135.75.204]) by imp10 with smtp.charter.net id 7de51h00C4QU3rf05de5ST; Wed, 13 Jul 2011 21:38:05 -0400 X-Authority-Analysis: v=1.1 cv=G6Q69DB3AUoJKS2BpLRaz8MQ2NORN7h5HRzrJMPOhRw= c=1 sm=1 a=CpZYxkIGCHkA:10 a=n2w-IegYaSwA:10 a=EZ1XIdwCItEA:10 a=8nJEP1OIZ-IA:10 a=HEs2YkztZRVyeANDsLw8Eg==:17 a=0P8WPeZgXdFGByAHO64A:9 a=4gb9QyMgyg7wML6yqx4A:7 a=wPNLvfGTeEIA:10 a=HEs2YkztZRVyeANDsLw8Eg==:117 Message-ID: <4E1E487C.5020803@gamozo.org> Date: Wed, 13 Jul 2011 20:38:04 -0500 From: Brandon Falk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <4E1CC63D.6040606@gamozo.org> <201107130749.35335.jhb@freebsd.org> <4E1D9FA3.30403@gamozo.org> <4E1DC0B2.5070909@FreeBSD.org> <4E1E42FC.3080407@gamozo.org> In-Reply-To: <4E1E42FC.3080407@gamozo.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: System Fails to Boot (Deadlock?) 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, 14 Jul 2011 01:38:06 -0000 On 7/13/2011 8:14 PM, Brandon Falk wrote: > On 7/13/2011 10:58 AM, John Baldwin wrote: >> On 7/13/11 9:37 AM, Brandon Falk wrote: >>> On 7/13/2011 6:49 AM, John Baldwin wrote: >>>> On Tuesday, July 12, 2011 6:10:05 pm Brandon Falk wrote: >>>>> Hello, >>>>> >>>>> My machine somehow fails to boot into FreeBSD (off the cd, since it >>>>> fails to boot, I can't install it in the first place). It goes >>>>> through >>>>> and ends up stopping deadlock style. No printouts of errors >>>>> (besides a >>>>> ppc problem, which is not fatal) and no crash/oops/panic. It just... >>>>> stops and locks up. I know my motherboards PCI system has failed, as >>>>> well as lan (getting a new one tomorrow), which is probably what is >>>>> causing the problem. The thing is that Windows 7 and Linux happen to >>>>> boot just fine on my machine, so although my system has a failing >>>>> motherboard and may cause errors, I still feel like it shouldn't be >>>>> causing this much of an issue on boot. I tried verbose logging and >>>>> got >>>>> no more information anyways. It will be nearly impossible to diagnose >>>>> this error so I'm looking for tips on where to look. >>>> How far does it get when it locks? Is it able to load /boot/loader off >>>> of the CD ok? Is it getting into the kernel far enough to output stuff >>>> to the >>>> console? Is it getting into sysinstall and hanging at some sysinstall >>>> screen? >>>> >>>> Also, is this host on the network and able to PXE? It's a lot easier >>>> to test >>>> custom kernels if needed using PXE than CDs (no need to burn a new CD >>>> each >>>> time, etc.). >>>> >>> >>> Since it's on a native box, I have no good way of copying the text, so >>> perhaps later I'll copy it by hand. /boot/loader launches just fine, >>> and >>> it's outputting messages just fine, until it just halts. It does not >>> hit >>> sysinstall. This box also does not have net as LAN is shot on the >>> motherboard (hence getting the new motherboard). >> >> What is the last message it outputs before it hangs? >> > > Hello, > > Sorry, I've been busy with work and I can't be bothered with rebooting > my machine right now. But, it seems I have duplicated a very similar > issue under a VM. Under the 9.0-CURRENT-201105-amd64-bootonly.iso iso > it 'locks' up during boot with yet again no error message or crash. > This only seems to happen when 8 cores are allocated to the VM, > everything is just fine and dandy with 4, 2, or 1 core(s). (Note, on > my native box I was using the 8.2-RELEASE amd64 bootonly iso). > > On the VM the last messages I get are: > > SMB: AP CPU #x Launched! > > x being a number inclusive and between 1-7, in a random order > (obviously the cpus start at 'random' times). > > I cannot duplicate this error on a successfully installed > FreeBSD-8.2-RELEASE-amd64 using the same hardware settings. > > Hmm, I just thought perhaps it is a CD issue... I tried > FreeBSD-8.2-RELEASE-amd64-bootonly on 8, 4, 2, and 1 cores, and it > seems to work just fine... argh. > > -Brandon > Hello, Sorry for spamming out more and more messages, but I noticed another pattern in the VM. It happens to fail sometimes even on 4 cores, it seems to be COMPLETELY random (ugh...), in the matter that one time it will boot, I'll do nothing but hit 'reboot', then it will work, then it wont, then it will, etc. I am not making any modifications to the system or hardware, it just seems to be completely random. I bet that sometime I may be able to get it to boot in a kernel with even 8 cores, but the randomness would make it very hard to do so. I'll try to get more information when I get back soon. Give me a heads up if this problem seems to be a common issue or something I may be overlooking. I'm anticipating putting FreeBSD on my main machine, but since I have 12 cores on my main machine, I don't think it will boot any time soon... -Brandon From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 14 01:38: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 AC1191065673 for ; Thu, 14 Jul 2011 01:38:28 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 683138FC18 for ; Thu, 14 Jul 2011 01:38:28 +0000 (UTC) Received: by vxg33 with SMTP id 33so6378602vxg.13 for ; Wed, 13 Jul 2011 18:38:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zjj1UmtgVUpNnrZiI0SDqUl4bihKg7SfYlHxzfo0WQw=; b=dSqKgXymIFQOrivLTDS3HUi+5yMJnEHCuh9T5hoVyXqmpvzeno21kg77Ye9PreJ1qa CwT9emQQ45qMrAYxgBIt7ZYDzWDesw1He2KRYtqIsuQFssja7XaAogAAHP+3xaqhiI2O rRmnQPD5QQ1hM47ATT026PpGXsQJAmk83Qmu4= MIME-Version: 1.0 Received: by 10.220.117.74 with SMTP id p10mr488361vcq.141.1310607507322; Wed, 13 Jul 2011 18:38:27 -0700 (PDT) Received: by 10.220.72.75 with HTTP; Wed, 13 Jul 2011 18:38:27 -0700 (PDT) In-Reply-To: <4E1E42FC.3080407@gamozo.org> References: <4E1CC63D.6040606@gamozo.org> <201107130749.35335.jhb@freebsd.org> <4E1D9FA3.30403@gamozo.org> <4E1DC0B2.5070909@FreeBSD.org> <4E1E42FC.3080407@gamozo.org> Date: Wed, 13 Jul 2011 18:38:27 -0700 Message-ID: From: Garrett Cooper To: Brandon Falk Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: System Fails to Boot (Deadlock?) 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, 14 Jul 2011 01:38:28 -0000 On Wed, Jul 13, 2011 at 6:14 PM, Brandon Falk wrote: > On 7/13/2011 10:58 AM, John Baldwin wrote: >> >> On 7/13/11 9:37 AM, Brandon Falk wrote: >>> >>> On 7/13/2011 6:49 AM, John Baldwin wrote: >>>> >>>> On Tuesday, July 12, 2011 6:10:05 pm Brandon Falk wrote: >>>>> >>>>> Hello, >>>>> >>>>> My machine somehow fails to boot into FreeBSD (off the cd, since it >>>>> fails to boot, I can't install it in the first place). It goes through >>>>> and ends up stopping deadlock style. No printouts of errors (besides a >>>>> ppc problem, which is not fatal) and no crash/oops/panic. It just... >>>>> stops and locks up. I know my motherboards PCI system has failed, as >>>>> well as lan (getting a new one tomorrow), which is probably what is >>>>> causing the problem. The thing is that Windows 7 and Linux happen to >>>>> boot just fine on my machine, so although my system has a failing >>>>> motherboard and may cause errors, I still feel like it shouldn't be >>>>> causing this much of an issue on boot. I tried verbose logging and got >>>>> no more information anyways. It will be nearly impossible to diagnose >>>>> this error so I'm looking for tips on where to look. >>>> >>>> How far does it get when it locks? Is it able to load /boot/loader off >>>> of the CD ok? Is it getting into the kernel far enough to output stuff >>>> to the >>>> console? Is it getting into sysinstall and hanging at some sysinstall >>>> screen? >>>> >>>> Also, is this host on the network and able to PXE? It's a lot easier >>>> to test >>>> custom kernels if needed using PXE than CDs (no need to burn a new CD >>>> each >>>> time, etc.). >>>> >>> >>> Since it's on a native box, I have no good way of copying the text, so >>> perhaps later I'll copy it by hand. /boot/loader launches just fine, and >>> it's outputting messages just fine, until it just halts. It does not hit >>> sysinstall. This box also does not have net as LAN is shot on the >>> motherboard (hence getting the new motherboard). >> >> What is the last message it outputs before it hangs? >> > > Hello, > > Sorry, I've been busy with work and I can't be bothered with rebooting my > machine right now. But, it seems I have duplicated a very similar issue > under a VM. Under the 9.0-CURRENT-201105-amd64-bootonly.iso iso it 'locks' > up during boot with yet again no error message or crash. This only seems to > happen when 8 cores are allocated to the VM, everything is just fine and > dandy with 4, 2, or 1 core(s). (Note, on my native box I was using the > 8.2-RELEASE amd64 bootonly iso). > > On the VM the last messages I get are: > > SMB: AP CPU #x Launched! > > x being a number inclusive and between 1-7, in a random order (obviously the > cpus start at 'random' times). > > I cannot duplicate this error on a successfully installed > FreeBSD-8.2-RELEASE-amd64 using the same hardware settings. > > Hmm, I just thought perhaps it is a CD issue... I tried > FreeBSD-8.2-RELEASE-amd64-bootonly on 8, 4, 2, and 1 cores, and it seems to > work just fine... argh. Ok -- this sounds familiar. I saw something like that with the May FreeBSD CURRENT USB snapshot on an r710, but things worked after I properly configured the LSI RAID volume on the machine. Thanks, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 14 06:22: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 4C112106564A for ; Thu, 14 Jul 2011 06:22:50 +0000 (UTC) (envelope-from lichray@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 116C78FC12 for ; Thu, 14 Jul 2011 06:22:49 +0000 (UTC) Received: by vws18 with SMTP id 18so6541385vws.13 for ; Wed, 13 Jul 2011 23:22:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=org2UH236yNdjbePIzDl5nfu1rmg9AsPp+1rtbhOIOk=; b=h9ReguQuZbJH9L1SXzLnWgrNlrckkC6W4ySSpaHGCl7i9E+oP36q7L9nKP0g+pgVXV MFnRS94UvI46Y2ZiIrSYWvkE9+IE86OJNhKxQX80c7tuZBMIKCCYcVVmZ2E+6KyJqSXK lizHHenAD/nqXFdqy9ikYZVfe4blr86wsiRmA= MIME-Version: 1.0 Received: by 10.52.177.166 with SMTP id cr6mr585151vdc.151.1310624569514; Wed, 13 Jul 2011 23:22:49 -0700 (PDT) Received: by 10.52.110.168 with HTTP; Wed, 13 Jul 2011 23:22:49 -0700 (PDT) Date: Thu, 14 Jul 2011 01:22:49 -0500 Message-ID: From: Zhihao Yuan To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: [GSoC]I want to remove everything perl/tcl/gtags in the new nvi 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, 14 Jul 2011 06:22:50 -0000 Hi hackers, I'm doing my GSoC project, "Multibyte Encoding Support in Nvi" at https://github.com/lichray/nvi2 . Currently, the editor can support read/display/write multibyte encoding through iconv. Before adding more features like file encoding detection, I want to remove some features in nvi. First, gtags mode. This feature was imported by http://lists.gnu.org/archive/html/global-commit/2005-01/msg00002.html . There's no gtags in our base system, and I can't find it in ports. This feature is useless (nvi-1.8x does not have it) and unexpected in the code (GTAGS macro everywhere). In a word, I want to remove it. Second, the perl/tcl interpreter support; you can apply a perl/tcl command to the file whiling you are editing. I beg no one here used this feature before. If the logic is simple, you can use subst; if it's not, you'd better write a script and run perl/tcl outside. I regard it as feature creep, and I don't like it. Any comments? -- Zhihao Yuan, nickname lichray The best way to predict the future is to invent it. ___________________________________________________ 4BSD -- http://4bsd.biz/ From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 14 06:32: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 ACB751065677 for ; Thu, 14 Jul 2011 06:32:18 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 743DD8FC12 for ; Thu, 14 Jul 2011 06:32:18 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id E34B57300A; Thu, 14 Jul 2011 08:49:17 +0200 (CEST) Date: Thu, 14 Jul 2011 08:49:17 +0200 From: Luigi Rizzo To: Zhihao Yuan Message-ID: <20110714064917.GB74835@onelab2.iet.unipi.it> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-hackers@freebsd.org Subject: Re: [GSoC]I want to remove everything perl/tcl/gtags in the new nvi 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, 14 Jul 2011 06:32:18 -0000 On Thu, Jul 14, 2011 at 01:22:49AM -0500, Zhihao Yuan wrote: > Hi hackers, > > I'm doing my GSoC project, "Multibyte Encoding Support in Nvi" at > https://github.com/lichray/nvi2 . Currently, the editor can support > read/display/write multibyte encoding through iconv. Before adding > more features like file encoding detection, I want to remove some > features in nvi. > > First, gtags mode. This feature was imported by > http://lists.gnu.org/archive/html/global-commit/2005-01/msg00002.html > . There's no gtags in our base system, and I can't find it in ports. > This feature is useless (nvi-1.8x does not have it) and unexpected in > the code (GTAGS macro everywhere). In a word, I want to remove it. > > Second, the perl/tcl interpreter support; you can apply a perl/tcl > command to the file whiling you are editing. I beg no one here used > this feature before. If the logic is simple, you can use subst; if > it's not, you'd better write a script and run perl/tcl outside. I > regard it as feature creep, and I don't like it. > > Any comments? what you suggest makes perfect sense. I'd also like to commend the attitude: not just say that you don't like something, but also do proper investigation and give sensible motivations for your likes or dislikes. Bravo. cheers luigi > -- > Zhihao Yuan, nickname lichray > The best way to predict the future is to invent it. > ___________________________________________________ > 4BSD -- http://4bsd.biz/ > _______________________________________________ > 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 Thu Jul 14 14:08: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 1FA3B106564A for ; Thu, 14 Jul 2011 14:08:02 +0000 (UTC) (envelope-from lidl@hydra.pix.net) Received: from hydra.pix.net (hydra.pix.net [71.241.230.60]) by mx1.freebsd.org (Postfix) with ESMTP id D07FC8FC0A for ; Thu, 14 Jul 2011 14:08:01 +0000 (UTC) Received: from hydra.pix.net (localhost [127.0.0.1]) by hydra.pix.net (8.14.4/8.14.4) with ESMTP id p6EE6j0X060674; Thu, 14 Jul 2011 10:06:45 -0400 (EDT) (envelope-from lidl@hydra.pix.net) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97 at mail.pix.net Received: (from lidl@localhost) by hydra.pix.net (8.14.4/8.14.4/Submit) id p6EE6jAK060673; Thu, 14 Jul 2011 10:06:45 -0400 (EDT) (envelope-from lidl) Date: Thu, 14 Jul 2011 10:06:45 -0400 From: Kurt Lidl To: Zhihao Yuan Message-ID: <20110714140645.GA60562@pix.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org Subject: Re: [GSoC]I want to remove everything perl/tcl/gtags in the new nvi 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, 14 Jul 2011 14:08:02 -0000 On Thu, Jul 14, 2011 at 01:22:49AM -0500, Zhihao Yuan wrote: > Second, the perl/tcl interpreter support; you can apply a perl/tcl > command to the file whiling you are editing. I beg no one here used > this feature before. Bzzt. I've used the perl interpreter before on a project. In that case, we were using vi as an editor for some very large text fields that were handled via perl to retrieve/store them into a database, done through a DBI proxy daemon. We could do multiple edits this way, without having to capture the field to a scratch file, invoke vi on it, again and again. One persistant vi... At the time, the speed mattered. > If the logic is simple, you can use subst; if > it's not, you'd better write a script and run perl/tcl outside. I > regard it as feature creep, and I don't like it. > > Any comments? I don't really care that the perl/tcl integration stays or goes, but it's certainly not "never been used". -Kurt From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 14 17:07:59 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 AF20C106566B for ; Thu, 14 Jul 2011 17:07:59 +0000 (UTC) (envelope-from lichray@gmail.com) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by mx1.freebsd.org (Postfix) with ESMTP id 3FCB48FC17 for ; Thu, 14 Jul 2011 17:07:58 +0000 (UTC) Received: by fxe6 with SMTP id 6so1004172fxe.17 for ; Thu, 14 Jul 2011 10:07:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=owqqrggzk8Tm1X0QZZyVLCfyWp+x3ToNa809iE4PEE4=; b=PkgCcndWlDUM0syw/604EM5be3R/lIyINKtHLEAPPXjWxWzmGUIfkpHoFzOnHPBXMB EFQtT4iG2FZ7hrZ+b3FPEouQfP5xpSgT+lGcUisfO0TpU6c5sQgqg8aAe4nmVKQLv99k e7UYhr8GuZkQdWOVzxOn7KhL0hZe8oxtC6G7k= MIME-Version: 1.0 Received: by 10.223.62.194 with SMTP id y2mr3754848fah.123.1310663250404; Thu, 14 Jul 2011 10:07:30 -0700 (PDT) Received: by 10.223.97.14 with HTTP; Thu, 14 Jul 2011 10:07:29 -0700 (PDT) In-Reply-To: References: Date: Thu, 14 Jul 2011 12:07:29 -0500 Message-ID: From: Zhihao Yuan To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: Fwd: [GSoC]I want to remove everything perl/tcl/gtags in the new nvi 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, 14 Jul 2011 17:07:59 -0000 Both the guy and me failed to reply to the group. Let me forward it. ---------- Forwarded message ---------- From: Zhihao Yuan Date: Thu, Jul 14, 2011 at 3:58 AM Subject: Re: [GSoC]I want to remove everything perl/tcl/gtags in the new nvi To: Sebastian Chmielewski On Thu, Jul 14, 2011 at 3:26 AM, Sebastian Chmielewski wrote: > > > 2011/7/14 Zhihao Yuan >> >> . There's no gtags in our base system, and I can't find it in ports. >> This feature is useless (nvi-1.8x does not have it) and unexpected in >> the code (GTAGS macro everywhere). In a word, I want to remove it. >> > Command 'gtags' is provided by GNU Global: > Port: global-5.7.7 > Path: /usr/ports/devel/global > Info: A source code tag system > I'm using it with Vim editor. 'make tags' in /usr/src/ also supports > 'gtags'. Vim can do gtags, perl, python, ruby... Nvi does not even support dict completion and syntax highlighting. I don't think nvi is suitable for daily coding now and the gtags support is not making things better. I regards nvi as a trustful editor when you login into other ppl's machines. Because it's almost not configurable, so you can trust it's behavior. In such case, a "greatest common divisor" feature set is enough. -- Zhihao Yuan, nickname lichray The best way to predict the future is to invent it. ___________________________________________________ 4BSD -- http://4bsd.biz/ -- Zhihao Yuan, nickname lichray The best way to predict the future is to invent it. ___________________________________________________ 4BSD -- http://4bsd.biz/ From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 14 18:13: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 3F901106566B for ; Thu, 14 Jul 2011 18:13:04 +0000 (UTC) (envelope-from sean@coreitpro.com) Received: from masakari.coreitpro.com (masakari.coreitpro.com [38.98.245.188]) by mx1.freebsd.org (Postfix) with ESMTP id 048168FC13 for ; Thu, 14 Jul 2011 18:13:03 +0000 (UTC) Received: from Uller.local (static-74-109-127-34.phlapa.fios.verizon.net [74.109.127.34]) (authenticated bits=0) by masakari.coreitpro.com (8.14.4/8.14.4) with ESMTP id p6EHqr4D073740 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 14 Jul 2011 13:52:54 -0400 (EDT) (envelope-from sean@coreitpro.com) Message-ID: <4E1F2CF0.7020501@coreitpro.com> Date: Thu, 14 Jul 2011 13:52:48 -0400 From: "Sean M. Collins" Organization: Core IT Pro User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: Fwd: [GSoC]I want to remove everything perl/tcl/gtags in the new nvi 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, 14 Jul 2011 18:13:04 -0000 On 7/14/11 1:07 PM, Zhihao Yuan wrote: > I regards nvi as a trustful editor when you login into other ppl's > machines. Yes - this is the exact use case for Vi in my mind. If I needed features I'd install vim. Come to think of it, since there is already a vim-lite and vim port, why not make a logical progression in features like so: nvi vim-lite vim Happy hacking Zhihao! -- Sean Collins Core IT Pro, LLC www.coreitpro.com From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 14 18:27:11 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 1C1871065677 for ; Thu, 14 Jul 2011 18:27:11 +0000 (UTC) (envelope-from dhesser@accima.com) Received: from mail.odessaoffice.com (mail.odessaoffice.com [64.146.146.8]) by mx1.freebsd.org (Postfix) with ESMTP id F04A68FC1B for ; Thu, 14 Jul 2011 18:27:10 +0000 (UTC) Received: from belinda.androcles.org ([::ffff:199.204.207.9]) (AUTH: CRAM-MD5 dhesser@accima.com, TLS: TLSv1/SSLv3, 256bits, AES256-SHA) by mail.odessaoffice.com with esmtp; Thu, 14 Jul 2011 11:17:07 -0700 id 0030C00F.4E1F32A3.00003F99 Date: Thu, 14 Jul 2011 11:17:07 -0700 From: "Duane H. Hesser" To: Zhihao Yuan Message-Id: <20110714111707.66d5978a.dhesser@accima.com> In-Reply-To: References: X-Mailer: Sylpheed 3.0.0 (GTK+ 2.22.1; i386-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: [GSoC]I want to remove everything perl/tcl/gtags in the new nvi X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dhesser@accima.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 18:27:11 -0000 On Thu, 14 Jul 2011 01:22:49 -0500 Zhihao Yuan wrote: > Hi hackers, > > I'm doing my GSoC project, "Multibyte Encoding Support in Nvi" at > https://github.com/lichray/nvi2 . Currently, the editor can support > read/display/write multibyte encoding through iconv. Before adding > more features like file encoding detection, I want to remove some > features in nvi. > > First, gtags mode. This feature was imported by > http://lists.gnu.org/archive/html/global-commit/2005-01/msg00002.html > . There's no gtags in our base system, and I can't find it in ports. > This feature is useless (nvi-1.8x does not have it) and unexpected in > the code (GTAGS macro everywhere). In a word, I want to remove it. > > Second, the perl/tcl interpreter support; you can apply a perl/tcl > command to the file whiling you are editing. I beg no one here used > this feature before. If the logic is simple, you can use subst; if > it's not, you'd better write a script and run perl/tcl outside. I > regard it as feature creep, and I don't like it. > > Any comments? > > -- > Zhihao Yuan, nickname lichray "gtags" is the tag preparation command of the "global" source code tag system, which was quite popular within freebsd a few years back. It provided tags to permit access to function references as well as function definitions. It also provided an "htags" command which produced a fully linked hypertext version of a source project, and someone maintained a hypertext copy of the FreeBSD sources on the FreeBSD website for a while. I'm not sure when or why global disappeared from the website (or distribution) but it may have been dropped when it "went GNU" (although I'm surprised to find there is no port). Shigio Yamaguchi, the author of the cvs commit that you reference, might have better information if you're interested (and you can find his email address). The "global" distribution is still available at http://www.gnu.org/s/global/globaldoc.html Note that I have no opinion whether the nvi code you mention should or should not be removed. This is offered in the event you want to check a little further before you decide. ------ Duane Hesser From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 14 21:37: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 DBFF1106564A for ; Thu, 14 Jul 2011 21:37:48 +0000 (UTC) (envelope-from lichray@gmail.com) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by mx1.freebsd.org (Postfix) with ESMTP id 72C5E8FC13 for ; Thu, 14 Jul 2011 21:37:47 +0000 (UTC) Received: by fxe6 with SMTP id 6so1278574fxe.17 for ; Thu, 14 Jul 2011 14:37:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9CpstuIxmDVa5i9sT3iPTbDf50FyVqDywJLP9ttM2Kw=; b=kZxOPTwO1t8x/Vks2uFgEW2t8QmBV7Gw5wx5m+D4bwQef/xlnurtx0lMVbgi1Ptlya hXY4YTGY47X4NdbDtKy/BcqKaKBCbmUez5fnQBjtaFOgoV3xmkqlQSmuEC5ZGsSlTY8N SUuehJ3cjqgYCGYc1IX1xdu9JX18K06Kww/us= MIME-Version: 1.0 Received: by 10.223.102.67 with SMTP id f3mr1319328fao.47.1310679466911; Thu, 14 Jul 2011 14:37:46 -0700 (PDT) Received: by 10.223.97.14 with HTTP; Thu, 14 Jul 2011 14:37:46 -0700 (PDT) In-Reply-To: <4E1F2CF0.7020501@coreitpro.com> References: <4E1F2CF0.7020501@coreitpro.com> Date: Thu, 14 Jul 2011 16:37:46 -0500 Message-ID: From: Zhihao Yuan To: "Sean M. Collins" Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org Subject: Re: Fwd: [GSoC]I want to remove everything perl/tcl/gtags in the new nvi 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, 14 Jul 2011 21:37:48 -0000 Here is my introspection: Q: Why drop DB3/4? A: Licenses problem. Q: Licenses problem matters? A: It causes we can't accept nvi-1.8x in our base system. Q: Why an editor in the base system? A: Always accessible. Anywhere (SSH), any situation (inc. system crashes). Q: Why not vim-lite/original-vi? A: POSIX-compliance, backward-compliance. Q: Why nvi? A: Availability, everlasting behaviors. Yes. I regards the Availability as Nvi's Core Competency. Perl, Tcl, gtags, they are not always available, so the related nvi features should be dropped. On Thu, Jul 14, 2011 at 12:52 PM, Sean M. Collins wrote: > On 7/14/11 1:07 PM, Zhihao Yuan wrote: >> I regards nvi as a trustful editor when you login into other ppl's >> machines. > > Yes - this is the exact use case for Vi in my mind. If I needed features > I'd install vim. Come to think of it, since there is already a vim-lite > and vim port, why not make a logical progression in features like so: > > nvi > vim-lite > vim > > Happy hacking Zhihao! > > -- > Sean Collins > Core IT Pro, LLC > www.coreitpro.com > _______________________________________________ > 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" > -- Zhihao Yuan, nickname lichray The best way to predict the future is to invent it. ___________________________________________________ 4BSD -- http://4bsd.biz/ From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 15 09:02:35 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 B3566106566B; Fri, 15 Jul 2011 09:02:35 +0000 (UTC) (envelope-from jeremie@le-hen.org) Received: from smtp5-g21.free.fr (unknown [IPv6:2a01:e0c:1:1599::14]) by mx1.freebsd.org (Postfix) with ESMTP id DF35F8FC12; Fri, 15 Jul 2011 09:02:32 +0000 (UTC) Received: from endor.tataz.chchile.org (unknown [82.233.239.98]) by smtp5-g21.free.fr (Postfix) with ESMTP id 2D8E4D480EA; Fri, 15 Jul 2011 11:02:24 +0200 (CEST) Received: from felucia.tataz.chchile.org (felucia.tataz.chchile.org [192.168.1.9]) by endor.tataz.chchile.org (Postfix) with ESMTP id 0D9D03403F; Fri, 15 Jul 2011 09:02:24 +0000 (UTC) Received: by felucia.tataz.chchile.org (Postfix, from userid 1000) id DEB0DA1271; Fri, 15 Jul 2011 09:02:23 +0000 (UTC) Date: Fri, 15 Jul 2011 11:02:23 +0200 From: Jeremie Le Hen To: Kostik Belousov Message-ID: <20110715090223.GA20572@felucia.tataz.chchile.org> References: <20100920162925.GL6864@felucia.tataz.chchile.org> <20100920192708.GK2389@deviant.kiev.zoral.com.ua> <20100927094651.GB57265@felucia.tataz.chchile.org> <20100927154457.GJ43070@deviant.kiev.zoral.com.ua> <20101005181804.GJ7536@felucia.tataz.chchile.org> <20101105213905.GT30284@felucia.tataz.chchile.org> <20101105190023.29e5d39d@kan.dnsalias.net> <20101106194702.GN2392@deviant.kiev.zoral.com.ua> <20110601214723.GD53247@felucia.tataz.chchile.org> <20110602100617.GF48734@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="adJ1OR3c6QgCpb/j" Content-Disposition: inline In-Reply-To: <20110602100617.GF48734@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: kan@freebsd.org, freebsd-hackers@freebsd.org, Jeremie Le Hen , "b. f." , portmgr@freebsd.org Subject: Re: compiling ports with SSP 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, 15 Jul 2011 09:02:35 -0000 --adJ1OR3c6QgCpb/j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Kostik, Alexander, I've Cc'ed portmgr@ because once this patch will reach the tree, I think we will be ready to enable -fstack-protector for ports. On Thu, Jun 02, 2011 at 01:06:17PM +0300, Kostik Belousov wrote: > > > > > > > > > > I dare to remind you about my patch. Do you have any other concerns? > > > > > > > > > > Thanks. > > > > > Regards, > > > > > -- > > > > > Jeremie Le Hen > > > > > > > > Hmm, I thought I did approve this patch already a long time agi, but > > > > since you asked: > > > > > > > > +.if defined(SHLIB_LDSCRIPT) && exists(${.CURDIR}/${SHLIB_LDSCRIPT}) > > > > > > > > this should be: > > > > > > > > +.if defined(SHLIB_LDSCRIPT) > > > > > > > > ditto for all other similar places. Otherwise I do not think we should > > > > hold the patch in queue ans should unleash it on unsuspecting public. > > > > > > Also, I think the "DEBUG" lines should be removed. > > > > Sure, I'll do it in my next update. > > > > > You install the libxxx.ld and then symlink libxxx.so to libxxx.ld. > > > Why ? Would it be enough to install just the libxxx.so ? > > > > I just thought it would be less puzzling for users than noticing that > > libc.so is only a few hundred of ascii. I don't have a strong opinion > > about this though. > I prefer to not have a symlink. > > > > > > Otherwise, I think you need the similar > > > .if ${SHLIBDIR} == ${LIBDIR} > > > magic, that is better to be avoided. > > > > Can you explain a little bit more about this one please? I'm willing to > > post an updated patch for further review. > I think this comment was somehow related to the fact that make install > does not work from the buildenv, or something similar. > It was too long time ago for me to remember details. > > Also, I remember there was a concern about linker script not being > installed in the cross-build environment during buildworld, or something > close to what I stated. Was it resolved ? > > [I pinged you some time ago, you did not responded]. I finally found some time to finish my patch. There was a few things to fix to be able to compile 32 bits library shims. I've also removed the symlink to libc.ld (which is installed directly as libc.so now). Now you have the following: % # ls -l lib*/libc.* % -r--r--r-- 1 root wheel 3650256 Jul 15 09:09 lib/libc.a % -r--r--r-- 1 root wheel 68 Jul 15 09:09 lib/libc.so % -r--r--r-- 1 root wheel 2472468 Jul 15 09:16 lib32/libc.a % -r--r--r-- 1 root wheel 76 Jul 15 09:16 lib32/libc.so % -r--r--r-- 1 root wheel 1277960 Jul 15 09:16 lib32/libc.so.7 % # cat lib/libc.so % /* $FreeBSD */ % GROUP ( /lib/libc.so.7 /usr/lib/libssp_nonshared.a ) % # cat lib32/libc.so % /* $FreeBSD */ % GROUP ( /usr/lib32/libc.so.7 /usr/lib32/libssp_nonshared.a ) Thanks. Best regards, -- Jeremie Le Hen Humans are born free and equal. But some are more equal than others. Coluche --adJ1OR3c6QgCpb/j Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="ld_ssp_nonshared.diff" diff -urNp -x '*.orig' -x 'typescript*' -x '*.swp' -x BEASTIE /usr/src.HEAD_20111506/lib/libc/Makefile /usr/src/lib/libc/Makefile --- /usr/src.HEAD_20111506/lib/libc/Makefile 2011-02-25 01:04:39.000000000 +0100 +++ /usr/src/lib/libc/Makefile 2011-06-25 14:17:05.000000000 +0200 @@ -30,6 +30,7 @@ CFLAGS+=-DNLS CLEANFILES+=tags INSTALL_PIC_ARCHIVE= PRECIOUSLIB= +SHLIB_LDSCRIPT=libc.ldscript .ifndef NO_THREAD_STACK_UNWIND CANCELPOINTS_CFLAGS=-fexceptions diff -urNp -x '*.orig' -x 'typescript*' -x '*.swp' -x BEASTIE /usr/src.HEAD_20111506/lib/libc/libc.ldscript /usr/src/lib/libc/libc.ldscript --- /usr/src.HEAD_20111506/lib/libc/libc.ldscript 1970-01-01 01:00:00.000000000 +0100 +++ /usr/src/lib/libc/libc.ldscript 2011-07-14 17:02:29.000000000 +0200 @@ -0,0 +1,2 @@ +/* $FreeBSD$ */ +GROUP ( @@SHLIB@@ @@LIBDIR@@/libssp_nonshared.a ) diff -urNp -x '*.orig' -x 'typescript*' -x '*.swp' -x BEASTIE /usr/src.HEAD_20111506/share/mk/bsd.lib.mk /usr/src/share/mk/bsd.lib.mk --- /usr/src.HEAD_20111506/share/mk/bsd.lib.mk 2011-04-19 20:09:21.000000000 +0200 +++ /usr/src/share/mk/bsd.lib.mk 2011-07-14 22:36:02.000000000 +0200 @@ -282,6 +282,13 @@ _libinstall: ${_INSTALLFLAGS} ${_SHLINSTALLFLAGS} \ ${SHLIB_NAME} ${DESTDIR}${SHLIBDIR} .if defined(SHLIB_LINK) +.if defined(SHLIB_LDSCRIPT) && !empty(SHLIB_LDSCRIPT) && exists(${.CURDIR}/${SHLIB_LDSCRIPT}) + sed -e 's,@@SHLIB@@,${SHLIBDIR}/${SHLIB_NAME},g' \ + -e 's,@@LIBDIR@@,${LIBDIR},g' \ + ${.CURDIR}/${SHLIB_LDSCRIPT} > lib${LIB}.ld + ${INSTALL} -S -C -o ${LIBOWN} -g ${LIBGRP} -m ${LIBMODE} \ + ${_INSTALLFLAGS} lib${LIB}.ld ${DESTDIR}${LIBDIR}/${SHLIB_LINK} +.else .if ${SHLIBDIR} == ${LIBDIR} ln -fs ${SHLIB_NAME} ${DESTDIR}${LIBDIR}/${SHLIB_LINK} .else @@ -292,8 +299,9 @@ _libinstall: rm -f ${DESTDIR}${LIBDIR}/${SHLIB_NAME} .endif .endif -.endif -.endif +.endif # SHLIB_LDSCRIPT +.endif # SHLIB_LINK +.endif # SHIB_NAME .if defined(INSTALL_PIC_ARCHIVE) && defined(LIB) && !empty(LIB) && ${MK_TOOLCHAIN} != "no" ${INSTALL} -o ${LIBOWN} -g ${LIBGRP} -m ${LIBMODE} \ ${_INSTALLFLAGS} lib${LIB}_pic.a ${DESTDIR}${LIBDIR} @@ -361,6 +369,9 @@ clean: .endif .if defined(SHLIB_NAME) .if defined(SHLIB_LINK) +.if defined(SHLIB_LDSCRIPT) && exists(${.CURDIR}/${SHLIB_LDSCRIPT}) + rm -f lib${LIB}.ld +.endif rm -f ${SHLIB_LINK} .endif .if defined(LIB) && !empty(LIB) --adJ1OR3c6QgCpb/j-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 15 11:08: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 A9B2C106566C for ; Fri, 15 Jul 2011 11:08:12 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 1B9098FC18 for ; Fri, 15 Jul 2011 11:08:11 +0000 (UTC) Received: from outgoing.leidinger.net (p4FC4368C.dip.t-dialin.net [79.196.54.140]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 4020684401C; Fri, 15 Jul 2011 12:51:21 +0200 (CEST) Received: from webmail.leidinger.net (webmail.Leidinger.net [IPv6:fd73:10c7:2053:1::3:102]) by outgoing.leidinger.net (Postfix) with ESMTP id 809122108; Fri, 15 Jul 2011 12:51:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1310727078; bh=6h9RUcSOLqXrplgKzn8XX25VDz77VF3XKLhTgoNF3fI=; h=Message-ID:Date:From:To:Cc:Subject:References:In-Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding; b=zyEL4w7fQoev9mHqlpbNHS8bd7auwa/Jh6vVCHkfQT1ZAqECw0iJiMHToRyWfLyQi cusuf0T3/tWZKStuF2s56kmy/xrK3lTgOsswGzHGQfYGqS9ZhfdwUB3ALrVNVjg33X Z9GoW6N0Lbx1pH+hhXoNCwOfXB5EhEbb7EIpioOifFUeHGMc+cSE/jSUlEisUAKTyl Oj+xXJ05d2/LQK9cgC0CnVpBCXWUBjwUCn/AS/0oOoqUS8DLSvrdivY4qOVvHDQk3a ffuMe8Rcqruh2NzYzYEMRa/VLk4LBUc1bCfMkaq7tWLvuzLMslhlBPqIOJ4H4nfBBn XdyojwleYAMvw== Received: (from www@localhost) by webmail.leidinger.net (8.14.4/8.14.4/Submit) id p6FApHAZ019522; Fri, 15 Jul 2011 12:51:17 +0200 (CEST) (envelope-from Alexander@Leidinger.net) X-Authentication-Warning: webmail.leidinger.net: www set sender to Alexander@Leidinger.net using -f Received: from 62.72.127.66 ([62.72.127.66]) by webmail.leidinger.net (Horde Framework) with HTTP; Fri, 15 Jul 2011 12:51:17 +0200 Message-ID: <20110715125117.20556cwl94hp8lgl@webmail.leidinger.net> Date: Fri, 15 Jul 2011 12:51:17 +0200 From: Alexander Leidinger To: Kurt Lidl References: <20110714140645.GA60562@pix.net> In-Reply-To: <20110714140645.GA60562@pix.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.6) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 4020684401C.AC31C X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-0.1, required 6, autolearn=disabled, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1311331881.9278@k5vAT42C6TJdQSiM6tU75A X-EBL-Spam-Status: No X-Mailman-Approved-At: Fri, 15 Jul 2011 11:27:20 +0000 Cc: freebsd-hackers@freebsd.org, Zhihao Yuan Subject: Re: [GSoC]I want to remove everything perl/tcl/gtags in the new nvi 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, 15 Jul 2011 11:08:12 -0000 Quoting Kurt Lidl (from Thu, 14 Jul 2011 10:06:45 -0400): > On Thu, Jul 14, 2011 at 01:22:49AM -0500, Zhihao Yuan wrote: >> Second, the perl/tcl interpreter support; you can apply a perl/tcl >> command to the file whiling you are editing. I beg no one here used >> this feature before. > > Bzzt. I've used the perl interpreter before on a project. [description of use-case] >> Any comments? > > I don't really care that the perl/tcl integration stays or goes, but > it's certainly not "never been used". Let's rephrase it: as nvi needs to link to perl, and we do not have a perl in the base since a loooong time, surely nobody was using the stock basesystem-nvi with the perl (and tcl) interpreter. As we also will not import perl/tcl into the basesystem again (at least not in the foreseable future), the code is useless for our basesystem. Whoever wants a vi with with such an interpreter, needs to compile one himself anyway and there are enough alternatives in the ports. Bye, Alexander. -- ** MAXIMUM TERMINALS ACTIVE. TRY AGAIN LATER ** http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 15 17:18: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 F41AA106564A for ; Fri, 15 Jul 2011 17:18:18 +0000 (UTC) (envelope-from s@samu.pl) Received: from samu.pl (samu.pl [IPv6:2001:41d0:1:f0cf::1]) by mx1.freebsd.org (Postfix) with ESMTP id 9307C8FC0C for ; Fri, 15 Jul 2011 17:18:18 +0000 (UTC) Received: by samu.pl (Postfix, from userid 1001) id 0B320CDD20; Fri, 15 Jul 2011 19:18:17 +0200 (CEST) To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Fri, 15 Jul 2011 19:18:16 +0200 From: s Message-ID: X-Sender: s@samu.pl User-Agent: RoundCube Webmail/0.5.1 Subject: Finding symlink information in MAC Framework 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, 15 Jul 2011 17:18:19 -0000 Hello everyone, I am trying to get some information related to the symlink which is being accessed by the user in MAC Framework. Currently I managed to get the uid/gid of the owner of the symlink that is being read, but now I need to get the same information about the target, that the symlink points to. static int samplemac_vnode_check_link (struct ucred *cred, struct vnode *vp, struct label *vplabel) { int error; struct vattr vap; error = VOP_GETATTR(vp, &vap, cred); if (error) return (1); if(vap.va_uid != 0) { log(LOG_NOTICE, "stub_vnode_check_readlink: %i, gid: %i\n", vap.va_uid, vap.va_gid); return (0); } return (0); } And I have no idea how could I do that. Where should I look for that info? And what way would be the fastest? -- Pozdrawiam, Jakub 'samu' Szafrański From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 16 13:12: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 14426106566B for ; Sat, 16 Jul 2011 13:12:08 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by mx1.freebsd.org (Postfix) with ESMTP id A44848FC15 for ; Sat, 16 Jul 2011 13:12:07 +0000 (UTC) Received: by fxe6 with SMTP id 6so3149076fxe.17 for ; Sat, 16 Jul 2011 06:12:06 -0700 (PDT) Received: by 10.223.28.65 with SMTP id l1mr7061916fac.136.1310820221826; Sat, 16 Jul 2011 05:43:41 -0700 (PDT) Received: from [192.168.10.3] ([82.76.253.74]) by mx.google.com with ESMTPS id n27sm1492426faa.28.2011.07.16.05.43.39 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 16 Jul 2011 05:43:40 -0700 (PDT) From: Vlad Galu Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 16 Jul 2011 14:43:37 +0200 Message-Id: To: freebsd-hackers@freebsd.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@freebsd.org Subject: FIB separation 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, 16 Jul 2011 13:12:08 -0000 Hello, A couple of years ago, Stef Walter proposed a patch[1] that enforced the = scope of routing messages. The general consesus was that the best = approach would be the OpenBSD way - transporting the FIB number in the = message and letting the user applications filter out unwanted messages. Are there any plans to tackle this before 9.0? Thanks, Vlad [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/134931= From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 16 16:04: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 C7489106566B for ; Sat, 16 Jul 2011 16:04:36 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.vlsi.ee.noda.tus.ac.jp (sekine00.ee.noda.sut.ac.jp [133.31.107.40]) by mx1.freebsd.org (Postfix) with ESMTP id 4FD0A8FC13 for ; Sat, 16 Jul 2011 16:04:36 +0000 (UTC) Received: from alph.allbsd.org (p3028-ipbf608funabasi.chiba.ocn.ne.jp [125.175.94.28]) (user=hrs mech=DIGEST-MD5 bits=128) by mail.vlsi.ee.noda.tus.ac.jp (8.14.4/8.14.4) with ESMTP id p6GFgqAB048453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 17 Jul 2011 00:43:02 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.14.4/8.14.4) with ESMTP id p6GFgoX4063155; Sun, 17 Jul 2011 00:42:52 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Sun, 17 Jul 2011 00:42:48 +0900 (JST) Message-Id: <20110717.004248.48765964696292481.hrs@allbsd.org> To: dudu@dudu.ro From: Hiroki Sato In-Reply-To: References: X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Sun_Jul_17_00_42_48_2011_981)--" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (mail.vlsi.ee.noda.tus.ac.jp [133.31.107.40]); Sun, 17 Jul 2011 00:43:02 +0900 (JST) X-Spam-Status: No, score=2.0 required=14.0 tests=BAYES_40, CONTENT_TYPE_PRESENT, RCVD_IN_RP_RNBL, SPF_SOFTFAIL, X_MAILER_PRESENT autolearn=no version=3.3.1 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.vlsi.ee.noda.tus.ac.jp Cc: freebsd-hackers@FreeBSD.org, freebsd-net@FreeBSD.org Subject: Re: FIB separation 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, 16 Jul 2011 16:04:36 -0000 ----Security_Multipart(Sun_Jul_17_00_42_48_2011_981)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Vlad Galu wrote in : du> Hello, du> du> A couple of years ago, Stef Walter proposed a patch[1] that enforced du> the scope of routing messages. The general consesus was that the best du> approach would be the OpenBSD way - transporting the FIB number in the du> message and letting the user applications filter out unwanted du> messages. du> du> Are there any plans to tackle this before 9.0? I am looking into this and investigating other possible extensions in rtsock messages such as addition of a fib member to rt_msghdr. I am not sure it can be done before 9.0, though... -- Hiroki ----Security_Multipart(Sun_Jul_17_00_42_48_2011_981)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk4hsXgACgkQTyzT2CeTzy1r7ACfbgol4iQfmS6VrGRpxJXyNJhh c3IAnRTg+4PdOqLwm9jkL6HZApfW/SiA =UC+i -----END PGP SIGNATURE----- ----Security_Multipart(Sun_Jul_17_00_42_48_2011_981)---- From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 16 16:21: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 0D331106566C; Sat, 16 Jul 2011 16:21:57 +0000 (UTC) (envelope-from "melifaro@ipfw.ru"@mail.ipfw.ru) Received: from mail.ipfw.ru (unknown [IPv6:2a01:4f8:120:6141::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8706B8FC15; Sat, 16 Jul 2011 16:21:56 +0000 (UTC) Received: from v6.mpls.in ([2a02:978:2::5] helo=ws.su29.net) by mail.ipfw.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from <"melifaro@ipfw.ru"@mail.ipfw.ru>) id 1Qi7co-0001Lq-V6; Sat, 16 Jul 2011 20:21:55 +0400 Message-ID: <4E21BA0B.6080800@ipfw.ru> Date: Sat, 16 Jul 2011 20:19:23 +0400 From: "Alexander V. Chernikov" User-Agent: Thunderbird 2.0.0.24 (X11/20100515) MIME-Version: 1.0 To: Hiroki Sato References: <20110717.004248.48765964696292481.hrs@allbsd.org> In-Reply-To: <20110717.004248.48765964696292481.hrs@allbsd.org> X-Enigmail-Version: 0.96.0 Content-Type: multipart/mixed; boundary="------------000402000609000100040606" Sender: "melifaro@ipfw.ru"@mail.ipfw.ru Cc: freebsd-hackers@FreeBSD.org, dudu@dudu.ro, "Bjoern A. Zeeb" , freebsd-net@FreeBSD.org Subject: Re: FIB separation 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, 16 Jul 2011 16:21:57 -0000 This is a multi-part message in MIME format. --------------000402000609000100040606 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hiroki Sato wrote: > Vlad Galu wrote > in : > > du> Hello, > du> > du> A couple of years ago, Stef Walter proposed a patch[1] that enforced > du> the scope of routing messages. The general consesus was that the best > du> approach would be the OpenBSD way - transporting the FIB number in the > du> message and letting the user applications filter out unwanted > du> messages. > du> > du> Are there any plans to tackle this before 9.0? > > I am looking into this and investigating other possible extensions in > rtsock messages such as addition of a fib member to rt_msghdr. I am > not sure it can be done before 9.0, though... Actually there were an off-list discussion with bz@ and julian@ about interface fibs and rtsock changes several weeks ago. Initial messages: http://lists.freebsd.org/pipermail/freebsd-net/2011-June/029040.html I've got 3 different patches: 1) straight forwarded kern/134931 fix (no fib in rtsock, no breaking ABI, send to bz@) 2) adding fib in rtsock with rtsock versioning and other ABI keeping tricks 3) adding special RTA which can contain TLV pairs, with single defined TLV with routing socket As a result of discussion, first patch was sent to bz@. Since patches from kern/134931 are outdated attaching it here. It is very much like original patch from kern/134931. The only difference is using PACKET_TAG_RTSOCKFAM mbuf_tag more heavily. This is required for keeping raw_input() with same number of parameters. Actually it looks rather hackish now. > > -- Hiroki -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4hugsACgkQwcJ4iSZ1q2nd1gCcDAgOIEjNbunK9QeADDEvyMa8 WtYAn1rlwUMzeSh1nX8o7Pw5TpZsfCJx =TsVz -----END PGP SIGNATURE----- --------------000402000609000100040606 Content-Type: text/plain; name="rtmsg_20110704-CURRENT.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="rtmsg_20110704-CURRENT.diff" Index: netinet/in.c =================================================================== --- netinet/in.c (revision 223741) +++ netinet/in.c (working copy) @@ -1009,7 +1009,7 @@ static void in_addralias_rtmsg(int cmd, struct in_ (struct sockaddr *)&target->ia_addr; rt_newaddrmsg(cmd, (struct ifaddr *)target, - 0, &msg_rt); + 0, &msg_rt, RT_ALLFIBS); RTFREE(pfx_ro.ro_rt); } return; Index: net/route.c =================================================================== --- net/route.c (revision 223741) +++ net/route.c (working copy) @@ -384,7 +384,7 @@ miss: */ bzero(&info, sizeof(info)); info.rti_info[RTAX_DST] = dst; - rt_missmsg(msgtype, &info, 0, err); + rt_missmsg(msgtype, &info, 0, err, fibnum); } done: if (newrt) @@ -609,7 +609,7 @@ out: info.rti_info[RTAX_GATEWAY] = gateway; info.rti_info[RTAX_NETMASK] = netmask; info.rti_info[RTAX_AUTHOR] = src; - rt_missmsg(RTM_REDIRECT, &info, flags, error); + rt_missmsg(RTM_REDIRECT, &info, flags, error, fibnum); if (ifa != NULL) ifa_free(ifa); } @@ -1522,7 +1522,7 @@ rtinit1(struct ifaddr *ifa, int cmd, int flags, in } RT_ADDREF(rt); RT_UNLOCK(rt); - rt_newaddrmsg(cmd, ifa, error, rt); + rt_newaddrmsg(cmd, ifa, error, rt, fibnum); RT_LOCK(rt); RT_REMREF(rt); if (cmd == RTM_DELETE) { Index: net/route.h =================================================================== --- net/route.h (revision 223741) +++ net/route.h (working copy) @@ -303,6 +303,11 @@ struct rt_addrinfo { struct ifnet *rti_ifp; }; +struct rt_dispatch_ctx { + unsigned short family; /* Socket family */ + int fibnum; /* FIB for message or -1 for all */ +}; + /* * This macro returns the size of a struct sockaddr when passed * through a routing socket. Basically we round up sa_len to @@ -317,6 +322,8 @@ struct rt_addrinfo { #ifdef _KERNEL +#define RT_ALLFIBS -1 + #define RT_LINK_IS_UP(ifp) (!((ifp)->if_capabilities & IFCAP_LINKSTATE) \ || (ifp)->if_link_state == LINK_STATE_UP) @@ -364,8 +371,8 @@ struct ifmultiaddr; void rt_ieee80211msg(struct ifnet *, int, void *, size_t); void rt_ifannouncemsg(struct ifnet *, int); void rt_ifmsg(struct ifnet *); -void rt_missmsg(int, struct rt_addrinfo *, int, int); -void rt_newaddrmsg(int, struct ifaddr *, int, struct rtentry *); +void rt_missmsg(int, struct rt_addrinfo *, int, int, int); +void rt_newaddrmsg(int, struct ifaddr *, int, struct rtentry *, int); void rt_newmaddrmsg(int, struct ifmultiaddr *); int rt_setgate(struct rtentry *, struct sockaddr *, struct sockaddr *); void rt_maskedcopy(struct sockaddr *, struct sockaddr *, struct sockaddr *); Index: net/rtsock.c =================================================================== --- net/rtsock.c (revision 223741) +++ net/rtsock.c (working copy) @@ -159,7 +159,7 @@ static void rt_setmetrics(u_long which, const stru struct rt_metrics_lite *out); static void rt_getmetrics(const struct rt_metrics_lite *in, struct rt_metrics *out); -static void rt_dispatch(struct mbuf *, const struct sockaddr *); +static void rt_dispatch(struct mbuf *, const struct sockaddr *, int); static struct netisr_handler rtsock_nh = { .nh_name = "rtsock", @@ -200,17 +200,16 @@ static void rts_input(struct mbuf *m) { struct sockproto route_proto; - unsigned short *family; + struct rt_dispatch_ctx *ctx; struct m_tag *tag; route_proto.sp_family = PF_ROUTE; - tag = m_tag_find(m, PACKET_TAG_RTSOCKFAM, NULL); + route_proto.sp_protocol = 0; + tag = m_tag_find(m, PACKET_TAG_RTSOCK, NULL); if (tag != NULL) { - family = (unsigned short *)(tag + 1); - route_proto.sp_protocol = *family; - m_tag_delete(m, tag); - } else - route_proto.sp_protocol = 0; + ctx = (struct rt_dispatch_ctx*)(tag + 1); + route_proto.sp_protocol = ctx->family; + } raw_input(m, &route_proto, &route_src); } @@ -892,10 +891,10 @@ flush: */ unsigned short family = rp->rcb_proto.sp_family; rp->rcb_proto.sp_family = 0; - rt_dispatch(m, info.rti_info[RTAX_DST]); + rt_dispatch(m, info.rti_info[RTAX_DST], so->so_fibnum); rp->rcb_proto.sp_family = family; } else - rt_dispatch(m, info.rti_info[RTAX_DST]); + rt_dispatch(m, info.rti_info[RTAX_DST], so->so_fibnum); } /* info.rti_info[RTAX_DST] (used above) can point inside of rtm */ if (rtm) @@ -1127,7 +1126,7 @@ again: * destination. */ void -rt_missmsg(int type, struct rt_addrinfo *rtinfo, int flags, int error) +rt_missmsg(int type, struct rt_addrinfo *rtinfo, int flags, int error, int fibnum) { struct rt_msghdr *rtm; struct mbuf *m; @@ -1142,7 +1141,7 @@ void rtm->rtm_flags = RTF_DONE | flags; rtm->rtm_errno = error; rtm->rtm_addrs = rtinfo->rti_addrs; - rt_dispatch(m, sa); + rt_dispatch(m, sa, fibnum); } /* @@ -1167,7 +1166,7 @@ rt_ifmsg(struct ifnet *ifp) ifm->ifm_flags = ifp->if_flags | ifp->if_drv_flags; ifm->ifm_data = ifp->if_data; ifm->ifm_addrs = 0; - rt_dispatch(m, NULL); + rt_dispatch(m, NULL, RT_ALLFIBS); } /* @@ -1179,7 +1178,7 @@ rt_ifmsg(struct ifnet *ifp) * copies of it. */ void -rt_newaddrmsg(int cmd, struct ifaddr *ifa, int error, struct rtentry *rt) +rt_newaddrmsg(int cmd, struct ifaddr *ifa, int error, struct rtentry *rt, int fibnum) { struct rt_addrinfo info; struct sockaddr *sa = NULL; @@ -1237,7 +1236,7 @@ void rtm->rtm_errno = error; rtm->rtm_addrs = info.rti_addrs; } - rt_dispatch(m, sa); + rt_dispatch(m, sa, fibnum); } } @@ -1273,7 +1272,7 @@ rt_newmaddrmsg(int cmd, struct ifmultiaddr *ifma) __func__)); ifmam->ifmam_index = ifp->if_index; ifmam->ifmam_addrs = info.rti_addrs; - rt_dispatch(m, ifma->ifma_addr); + rt_dispatch(m, ifma->ifma_addr, RT_ALLFIBS); } static struct mbuf * @@ -1333,7 +1332,7 @@ rt_ieee80211msg(struct ifnet *ifp, int what, void if (m->m_flags & M_PKTHDR) m->m_pkthdr.len += data_len; mtod(m, struct if_announcemsghdr *)->ifan_msglen += data_len; - rt_dispatch(m, NULL); + rt_dispatch(m, NULL, RT_ALLFIBS); } } @@ -1349,27 +1348,30 @@ rt_ifannouncemsg(struct ifnet *ifp, int what) m = rt_makeifannouncemsg(ifp, RTM_IFANNOUNCE, what, &info); if (m != NULL) - rt_dispatch(m, NULL); + rt_dispatch(m, NULL, RT_ALLFIBS); } static void -rt_dispatch(struct mbuf *m, const struct sockaddr *sa) +rt_dispatch(struct mbuf *m, const struct sockaddr *sa, int fibnum) { + struct rt_dispatch_ctx *ctx; struct m_tag *tag; /* * Preserve the family from the sockaddr, if any, in an m_tag for * use when injecting the mbuf into the routing socket buffer from - * the netisr. + * the netisr. Additionally save the fibnum if needed. */ - if (sa != NULL) { - tag = m_tag_get(PACKET_TAG_RTSOCKFAM, sizeof(unsigned short), - M_NOWAIT); + if (sa != NULL || fibnum >= 0) { + tag = m_tag_get(PACKET_TAG_RTSOCK, + sizeof(struct rt_dispatch_ctx*), M_NOWAIT); if (tag == NULL) { m_freem(m); return; } - *(unsigned short *)(tag + 1) = sa->sa_family; + ctx = (struct rt_dispatch_ctx*)(tag + 1); + ctx->family = sa->sa_family; + ctx->fibnum = fibnum; m_tag_prepend(m, tag); } #ifdef VIMAGE Index: net/raw_usrreq.c =================================================================== --- net/raw_usrreq.c (revision 223741) +++ net/raw_usrreq.c (working copy) @@ -48,6 +48,7 @@ #include #include #include +#include MTX_SYSINIT(rawcb_mtx, &rawcb_mtx, "rawcb", MTX_DEF); @@ -74,7 +75,18 @@ raw_input(struct mbuf *m0, struct sockproto *proto struct rawcb *rp; struct mbuf *m = m0; struct socket *last; + struct rt_dispatch_ctx *ctx; + struct m_tag *tag = NULL; + int fibnum = RT_ALLFIBS; + if (proto->sp_family == PF_ROUTE) { + tag = m_tag_find(m, PACKET_TAG_RTSOCK, NULL); + if (tag != NULL) { + ctx = (struct rt_dispatch_ctx*)(tag + 1); + fibnum = ctx->fibnum; + } + } + last = 0; mtx_lock(&rawcb_mtx); LIST_FOREACH(rp, &V_rawcb_list, list) { @@ -83,6 +95,10 @@ raw_input(struct mbuf *m0, struct sockproto *proto if (rp->rcb_proto.sp_protocol && rp->rcb_proto.sp_protocol != proto->sp_protocol) continue; + if ((proto->sp_family == PF_ROUTE) && (fibnum >= 0) && + (rp->rcb_socket != NULL) && + (fibnum != rp->rcb_socket->so_fibnum)) + continue; if (last) { struct mbuf *n; n = m_copy(m, 0, (int)M_COPYALL); Index: netinet6/in6.c =================================================================== --- netinet6/in6.c (revision 223741) +++ netinet6/in6.c (working copy) @@ -1280,7 +1280,7 @@ in6_purgeaddr(struct ifaddr *ifa) rt_mask(&rt0) = (struct sockaddr *)&mask; rt_key(&rt0) = (struct sockaddr *)&addr; rt0.rt_flags = RTF_HOST | RTF_STATIC; - rt_newaddrmsg(RTM_DELETE, ifa, 0, &rt0); + rt_newaddrmsg(RTM_DELETE, ifa, 0, &rt0, RT_ALLFIBS); /* * leave from multicast groups we have joined for the interface @@ -1858,7 +1858,7 @@ in6_ifinit(struct ifnet *ifp, struct in6_ifaddr *i rt_mask(&rt) = (struct sockaddr *)&mask; rt_key(&rt) = (struct sockaddr *)&addr; rt.rt_flags = RTF_UP | RTF_HOST | RTF_STATIC; - rt_newaddrmsg(RTM_ADD, &ia->ia_ifa, 0, &rt); + rt_newaddrmsg(RTM_ADD, &ia->ia_ifa, 0, &rt, RT_ALLFIBS); } return (error); Index: netinet6/nd6_rtr.c =================================================================== --- netinet6/nd6_rtr.c (revision 223741) +++ netinet6/nd6_rtr.c (working copy) @@ -458,7 +458,7 @@ nd6_rtmsg(int cmd, struct rtentry *rt) } else ifa = NULL; - rt_missmsg(cmd, &info, rt->rt_flags, 0); + rt_missmsg(cmd, &info, rt->rt_flags, 0, RT_ALLFIBS); if (ifa != NULL) ifa_free(ifa); } Index: sys/mbuf.h =================================================================== --- sys/mbuf.h (revision 223741) +++ sys/mbuf.h (working copy) @@ -945,7 +945,7 @@ struct mbuf *m_unshare(struct mbuf *, int how); #define PACKET_TAG_IPFORWARD 18 /* ipforward info */ #define PACKET_TAG_MACLABEL (19 | MTAG_PERSISTENT) /* MAC label */ #define PACKET_TAG_PF 21 /* PF + ALTQ information */ -#define PACKET_TAG_RTSOCKFAM 25 /* rtsock sa family */ +#define PACKET_TAG_RTSOCK 25 /* rtsock info */ #define PACKET_TAG_IPOPTIONS 27 /* Saved IP options */ #define PACKET_TAG_CARP 28 /* CARP info */ #define PACKET_TAG_IPSEC_NAT_T_PORTS 29 /* two uint16_t */ --------------000402000609000100040606-- From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 16 16:22:16 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 0248E106564A; Sat, 16 Jul 2011 16:22:16 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by mx1.freebsd.org (Postfix) with ESMTP id 6B6E58FC12; Sat, 16 Jul 2011 16:22:14 +0000 (UTC) Received: by fxe6 with SMTP id 6so3281298fxe.17 for ; Sat, 16 Jul 2011 09:22:14 -0700 (PDT) Received: by 10.223.53.77 with SMTP id l13mr7160459fag.84.1310833334029; Sat, 16 Jul 2011 09:22:14 -0700 (PDT) Received: from [192.168.10.3] ([82.76.253.74]) by mx.google.com with ESMTPS id r12sm1607684fam.0.2011.07.16.09.22.12 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 16 Jul 2011 09:22:13 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Vlad Galu In-Reply-To: <20110717.004248.48765964696292481.hrs@allbsd.org> Date: Sat, 16 Jul 2011 18:22:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <08E81571-34DA-41E2-B06E-3BFC9C046895@dudu.ro> References: <20110717.004248.48765964696292481.hrs@allbsd.org> To: Hiroki Sato X-Mailer: Apple Mail (2.1084) Cc: freebsd-hackers@FreeBSD.org, freebsd-net@FreeBSD.org Subject: Re: FIB separation 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, 16 Jul 2011 16:22:16 -0000 On Jul 16, 2011, at 5:42 PM, Hiroki Sato wrote: > Vlad Galu wrote > in : >=20 > du> Hello, > du> > du> A couple of years ago, Stef Walter proposed a patch[1] that = enforced > du> the scope of routing messages. The general consesus was that the = best > du> approach would be the OpenBSD way - transporting the FIB number in = the > du> message and letting the user applications filter out unwanted > du> messages. > du> > du> Are there any plans to tackle this before 9.0? >=20 > I am looking into this and investigating other possible extensions in > rtsock messages such as addition of a fib member to rt_msghdr. I am > not sure it can be done before 9.0, though... >=20 > -- Hiroki Thanks! Even if this gets postponed for 10.0, living with a backport of = the official implementation would be easier than maintaining a homegrown solution. VG