From owner-freebsd-arch@FreeBSD.ORG Sun Apr 27 01:06:53 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 528F737B401; Sun, 27 Apr 2003 01:06:53 -0700 (PDT) Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63]) by mx1.FreeBSD.org (Postfix) with ESMTP id 925B843F3F; Sun, 27 Apr 2003 01:06:52 -0700 (PDT) (envelope-from DougB@freebsd.org) Received: from master.dougb.net (12-234-22-23.client.attbi.com[12.234.22.23]) by sccrmhc03.attbi.com (sccrmhc03) with SMTP id <20030427080651003006bcmre>; Sun, 27 Apr 2003 08:06:51 +0000 Date: Sun, 27 Apr 2003 01:06:50 -0700 (PDT) From: Doug Barton To: Scott Long In-Reply-To: <20030426231507.K657@znfgre.qbhto.arg> Message-ID: <20030427010221.H657@znfgre.qbhto.arg> References: <20030426154030.M13476@znfgre.qbhto.arg> <3EAB12AC.8050707@btc.adaptec.com><3EAB7486.2060107@btc.adaptec.com> <20030426231507.K657@znfgre.qbhto.arg> Organization: http://www.FreeBSD.org/ X-message-flag: Outlook -- Not just for spreading viruses anymore! MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: FreeBSD-rc@yahoogroups.com cc: freebsd-arch@freebsd.org Subject: Re: [FreeBSD-rc] Re: RFC: Removal of the old rc system from -current X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Apr 2003 08:06:53 -0000 On Sat, 26 Apr 2003, Doug Barton wrote: > Before you have another knee-jerk REaction to my proposal, please stop and > think about how much different this scenario is than something like a > kernel interface or binary. It occurs to me that this may have come out sounding a lot harsher than I meant it. I'm certainly not implying that Scott is a bonehead, that's obviously not the case. This situation actually is very different than other release engineering concerns, which is why I'm saying, "stop and think" about it. It also occurred to me that part of the problem here is that I failed to make these differences clear in my original post. I think it's just a case of being so close to the code that I had assumed it was obvious to everyone. :) Hope this helps, Doug -- This .signature sanitized for your protection From owner-freebsd-arch@FreeBSD.ORG Sun Apr 27 03:02:41 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B64D737B401 for ; Sun, 27 Apr 2003 03:02:40 -0700 (PDT) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2529343F75 for ; Sun, 27 Apr 2003 03:02:40 -0700 (PDT) (envelope-from jordbaer@mac.com) Received: from asmtp01.mac.com (asmtp01-qfe3 [10.13.10.65]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id h3RA2dGm024405 for ; Sun, 27 Apr 2003 03:02:39 -0700 (PDT) Received: from mac.com ([195.202.35.98]) by asmtp01.mac.com (Netscape Messaging Server 4.15) with ESMTP id HDZYKE00.VSS for ; Sun, 27 Apr 2003 03:02:38 -0700 Date: Sun, 27 Apr 2003 12:02:34 +0200 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=ISO-8859-1; format=flowed From: =?ISO-8859-1?Q?Bodo_R=FCskamp?= To: arch@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <5E112B5E-7897-11D7-BB6A-000393DB98F8@mac.com> X-Mailer: Apple Mail (2.552) Subject: misc patches to FreeBSD (Geode, USB, kqueue, ObjC) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Apr 2003 10:02:41 -0000 Hi, I have compiled a list of patches for FreeBSD on=20 . They are the result of=20 using the FreeBSD kernel on our Set-Top-Box hardware, which uses the=20 Geode processor by National Semiconductor. We used to patch the past FreeBSD releases since 4.3 to get our=20 software working, but since our product is now released, we would like=20= to merge the patches into the main FreeBSD repository, so that they are=20= included in FreeBSD 4.9. A short overview: http://www.clabsms.de/FreeBSD/patch.sys.i386.i386.identcpu.c http://www.clabsms.de/FreeBSD/patch.sys.i386.i386.vm_machdep.c These patches are to support the NSC Geode processor. http://www.clabsms.de/FreeBSD/patch.sys.net.bpf.c http://www.clabsms.de/FreeBSD/patch.sys.dev.usb.usb.c These patches add the kqueue(2) interface to bpf(4) and usb(4). http://www.clabsms.de/FreeBSD/patch.sys.dev.usb.ohci.c This contains a fix for a serious bug in the OHCI code that was present=20= for a very long time in FreeBSD and NetBSD: The attach/detach routines=20= have a bug that makes the usbd hang in the kernel (unkillable). Also=20 some minor fixes are included, ported from NetBSD 1.6.1. http://www.clabsms.de/FreeBSD/patch.sys.netgraph.ng_ksocket.c This patch makes the connect() function of ng_ksocket work. http://www.clabsms.de/FreeBSD/patch.contrib.libobjc.objc.hash.h http://www.clabsms.de/FreeBSD/patch.contrib.libobjc.objc.thr.h Patches for the ObjC include headers that are required, if you use GCC=20= with all warnings turned on. ; Bodo R=FCskamp --=20 Bodo R=FCskamp = From owner-freebsd-arch@FreeBSD.ORG Sun Apr 27 03:53:17 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C720B37B401 for ; Sun, 27 Apr 2003 03:53:16 -0700 (PDT) Received: from yello.shallow.net (yello.shallow.net [203.18.243.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id E682E43FCB for ; Sun, 27 Apr 2003 03:53:15 -0700 (PDT) (envelope-from joshua@shallow.net) Received: by yello.shallow.net (Postfix, from userid 1001) id 947EC2B94; Sun, 27 Apr 2003 20:53:13 +1000 (EST) Date: Sun, 27 Apr 2003 20:53:13 +1000 From: Joshua Goodall To: freebsd-arch@freebsd.org Message-ID: <20030427105313.GA507@roughtrade.net> References: <20030426154030.M13476@znfgre.qbhto.arg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030426154030.M13476@znfgre.qbhto.arg> User-Agent: Mutt/1.5.3i cc: freebsd-rc@yahoogroups.com Subject: Re: RFC: Removal of the old rc system from -current X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Apr 2003 10:53:17 -0000 On Sat, Apr 26, 2003 at 03:46:08PM -0700, Doug Barton wrote: > We're also starting to see some confusion on the part of users about > having both systems on disk. Time to teach mergemaster about files that are now stale, so it can offer to remove (or archive) them for the user? J From owner-freebsd-arch@FreeBSD.ORG Sun Apr 27 06:03:37 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E1B5B37B401; Sun, 27 Apr 2003 06:03:37 -0700 (PDT) Received: from magic.adaptec.com (magic-mail.adaptec.com [208.236.45.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 30A3B43F3F; Sun, 27 Apr 2003 06:03:37 -0700 (PDT) (envelope-from scott_long@btc.adaptec.com) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.11.6/8.11.6) with ESMTP id h3RD0mZ23164; Sun, 27 Apr 2003 06:00:48 -0700 Received: from btc.btc.adaptec.com ([10.100.0.52]) by redfish.adaptec.com (8.8.8p2+Sun/8.8.8) with ESMTP id GAA15265; Sun, 27 Apr 2003 06:03:29 -0700 (PDT) Received: from btc.adaptec.com (hollin [10.100.253.56]) by btc.btc.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id HAA01098; Sun, 27 Apr 2003 07:03:27 -0600 (MDT) Message-ID: <3EABD516.2090100@btc.adaptec.com> Date: Sun, 27 Apr 2003 07:03:18 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Doug Barton References: <20030426154030.M13476@znfgre.qbhto.arg> <3EAB12AC.8050707@btc.adaptec.com> <20030426223810.Y657@znfgre.qbhto.arg> <3EAB7486.2060107@btc.adaptec.com> <20030426231507.K657@znfgre.qbhto.arg> <20030427010221.H657@znfgre.qbhto.arg> In-Reply-To: <20030427010221.H657@znfgre.qbhto.arg> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: FreeBSD-rc@yahoogroups.com cc: freebsd-arch@freebsd.org Subject: Re: [FreeBSD-rc] Re: RFC: Removal of the old rc system from -current X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Apr 2003 13:03:38 -0000 Doug Barton wrote: > On Sat, 26 Apr 2003, Doug Barton wrote: > > >>Before you have another knee-jerk REaction to my proposal, please stop and >>think about how much different this scenario is than something like a >>kernel interface or binary. > > > It occurs to me that this may have come out sounding a lot harsher than I > meant it. I'm certainly not implying that Scott is a bonehead, that's > obviously not the case. This situation actually is very different than > other release engineering concerns, which is why I'm saying, "stop and > think" about it. > > It also occurred to me that part of the problem here is that I failed to > make these differences clear in my original post. I think it's just a case > of being so close to the code that I had assumed it was obvious to > everyone. :) > > Hope this helps, > > Doug > Doug, My premise is this: there are people who cvsup and build world on a regular basis, track current@, etc, and there are those who are only interested in running official releases. My concern is not the first group, but the second group. The old rc system has been around for quite some time, and it might be a shock if it disappears without warning. The fact that 5.1 has the possiblity of being a worthly release means that more people are likely to jump straight from 4.x to 5.1, and might not be aware of rcNG from 5.0. These aren't the people who will be doing mergemaster, these are the people who will install from CD then might try to configure things in the way that they used to be familiar with. Your change to src/etc/rc looks great and is exactly what I had in mind. Looking at the other feedback that this thread has gotten, rcNG appears to be a hit and is greatly appreciated. Thanks a lot for yours and others hard work. Scott From owner-freebsd-arch@FreeBSD.ORG Sun Apr 27 07:03:56 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5170E37B401; Sun, 27 Apr 2003 07:03:56 -0700 (PDT) Received: from storm.FreeBSD.org.uk (storm.FreeBSD.org.uk [194.242.157.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 57EDE43F3F; Sun, 27 Apr 2003 07:03:55 -0700 (PDT) (envelope-from mark@grondar.org) Received: from storm.FreeBSD.org.uk (Ugrondar@localhost [127.0.0.1]) by storm.FreeBSD.org.uk (8.12.7/8.12.7) with ESMTP id h3RE3pSQ001704; Sun, 27 Apr 2003 15:03:52 +0100 (BST) (envelope-from mark@grondar.org) Received: (from Ugrondar@localhost)h3RE3pbi001703; Sun, 27 Apr 2003 15:03:51 +0100 (BST) X-Authentication-Warning: storm.FreeBSD.org.uk: Ugrondar set sender to mark@grondar.org using -f Received: from grondar.org (localhost [127.0.0.1])h3RE4TPm084271; Sun, 27 Apr 2003 15:04:29 +0100 (BST) (envelope-from mark@grondar.org) From: Mark Murray Message-Id: <200304271404.h3RE4TPm084271@grimreaper.grondar.org> To: Scott Long In-Reply-To: Your message of "Sun, 27 Apr 2003 07:03:18 MDT." <3EABD516.2090100@btc.adaptec.com> Date: Sun, 27 Apr 2003 15:04:29 +0100 Sender: mark@grondar.org cc: Doug Barton cc: FreeBSD-rc@yahoogroups.com cc: freebsd-arch@freebsd.org Subject: Re: [FreeBSD-rc] Re: RFC: Removal of the old rc system from -current X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Apr 2003 14:03:56 -0000 Scott Long writes: > My premise is this: there are people who cvsup and build world on a > regular basis, track current@, etc, and there are those who are only > interested in running official releases. My concern is not the first > group, but the second group. The old rc system has been around for > quite some time, and it might be a shock if it disappears without > warning. This would be a plus IMO. I'm aware of at least one FreeBSDer who installed from CD and wondered why his changes to rc.* (not rc.d.*) didn't work at all. Removing those files simplifies things. M -- Mark Murray iumop ap!sdn w,I idlaH From owner-freebsd-arch@FreeBSD.ORG Sun Apr 27 07:11:37 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AF3CA37B401; Sun, 27 Apr 2003 07:11:37 -0700 (PDT) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A4F943F93; Sun, 27 Apr 2003 07:11:36 -0700 (PDT) (envelope-from des@ofug.org) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 4194F5308; Sun, 27 Apr 2003 16:11:33 +0200 (CEST) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Scott Long From: Dag-Erling Smorgrav Date: Sun, 27 Apr 2003 16:11:32 +0200 In-Reply-To: <3EABD516.2090100@btc.adaptec.com> (Scott Long's message of "Sun, 27 Apr 2003 07:03:18 -0600") Message-ID: User-Agent: Gnus/5.090015 (Oort Gnus v0.15) Emacs/21.2 References: <20030426154030.M13476@znfgre.qbhto.arg> <3EAB12AC.8050707@btc.adaptec.com> <20030426223810.Y657@znfgre.qbhto.arg> <3EAB7486.2060107@btc.adaptec.com> <20030426231507.K657@znfgre.qbhto.arg> <20030427010221.H657@znfgre.qbhto.arg> <3EABD516.2090100@btc.adaptec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: Doug Barton cc: FreeBSD-rc@yahoogroups.com cc: freebsd-arch@freebsd.org Subject: Re: [FreeBSD-rc] Re: RFC: Removal of the old rc system from -current X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Apr 2003 14:11:38 -0000 Scott Long writes: > My premise is this: there are people who cvsup and build world on a > regular basis, track current@, etc, and there are those who are only > interested in running official releases. My concern is not the first > group, but the second group. The old rc system has been around for > quite some time, and it might be a shock if it disappears without > warning. The fact that 5.1 has the possiblity of being a worthly > release means that more people are likely to jump straight from 4.x > to 5.1, and might not be aware of rcNG from 5.0. These aren't the > people who will be doing mergemaster, these are the people who will > install from CD then might try to configure things in the way that > they used to be familiar with. The configuration mechanism hasn't changed, except for details like variable names which are not directly related to rcNG (portmap -> rpcbind, xntpd -> ntpd). The only thing that has changed is the way the configuration is applied behind the scenes. Normal users won't notice rcNG in a negative sense (though they may discover that they can now easily start and stop services); if they have trouble configuring their 5.1 systems, it'll be because of things like the switch from pam.conf to pam.d, the introduction of nsswitch, or the deprecation of usbd and pccardd in favor of devd. The kind of people who hack their rc scripts such that rcNG will break their setup should know better than to upgrade blindly, and should hopefully have the skills required to port their hacks to 5.1. If they don't, they shouldn't have been messing with the rc scripts in the first place. DES -- Dag-Erling Smorgrav - des@ofug.org From owner-freebsd-arch@FreeBSD.ORG Sun Apr 27 07:13:13 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 58B3337B401; Sun, 27 Apr 2003 07:13:13 -0700 (PDT) Received: from shrike.submonkey.net (pc1-cdif2-5-cust38.cdif.cable.ntl.com [81.101.150.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4970043FBF; Sun, 27 Apr 2003 07:13:12 -0700 (PDT) (envelope-from setantae@submonkey.net) Received: from setantae by shrike.submonkey.net with local (Exim 4.12) id 199mtx-000IYQ-00; Sun, 27 Apr 2003 15:13:09 +0100 Date: Sun, 27 Apr 2003 15:13:09 +0100 From: Ceri Davies To: Mark Murray Message-ID: <20030427141309.GA71304@submonkey.net> Mail-Followup-To: Ceri Davies , Mark Murray , Scott Long , Doug Barton , FreeBSD-rc@yahoogroups.com, freebsd-arch@freebsd.org References: <3EABD516.2090100@btc.adaptec.com> <200304271404.h3RE4TPm084271@grimreaper.grondar.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200304271404.h3RE4TPm084271@grimreaper.grondar.org> User-Agent: Mutt/1.5.4i Sender: Ceri Davies cc: Scott Long cc: Doug Barton cc: FreeBSD-rc@yahoogroups.com cc: freebsd-arch@freebsd.org Subject: Re: [FreeBSD-rc] Re: RFC: Removal of the old rc system from -current X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Apr 2003 14:13:13 -0000 On Sun, Apr 27, 2003 at 03:04:29PM +0100, Mark Murray wrote: > Scott Long writes: > > My premise is this: there are people who cvsup and build world on a > > regular basis, track current@, etc, and there are those who are only > > interested in running official releases. My concern is not the first > > group, but the second group. The old rc system has been around for > > quite some time, and it might be a shock if it disappears without > > warning. > > This would be a plus IMO. I'm aware of at least one FreeBSDer who > installed from CD and wondered why his changes to rc.* (not rc.d.*) > didn't work at all. Removing those files simplifies things. Yes. Those users are unlikely to know to specify rc_ng="NO" , so rc.* won't work for them anyway. Ceri -- From owner-freebsd-arch@FreeBSD.ORG Sun Apr 27 10:35:02 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E26B737B401; Sun, 27 Apr 2003 10:35:02 -0700 (PDT) Received: from kientzle.com (h-66-166-149-50.SNVACAID.covad.net [66.166.149.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C2C543F3F; Sun, 27 Apr 2003 10:35:02 -0700 (PDT) (envelope-from kientzle@acm.org) Received: from acm.org (ugly.x.kientzle.com [66.166.149.51]) by kientzle.com (8.11.3/8.11.3) with ESMTP id h3RHZ0v51736; Sun, 27 Apr 2003 10:35:00 -0700 (PDT) (envelope-from kientzle@acm.org) Message-ID: <3EAC150E.6090605@acm.org> Date: Sun, 27 Apr 2003 10:36:14 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.6) Gecko/20011206 X-Accept-Language: en-us, en MIME-Version: 1.0 To: FreeBSD-rc@yahoogroups.com References: <20030426154030.M13476@znfgre.qbhto.arg> <3EAB12AC.8050707@btc.adaptec.com> <20030426223810.Y657@znfgre.qbhto.arg> <3EAB7486.2060107@btc.adaptec.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Doug Barton cc: freebsd-arch@freebsd.org Subject: Re: [FreeBSD-rc] Re: RFC: Removal of the old rc system from -current X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: kientzle@acm.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Apr 2003 17:35:03 -0000 Scott Long wrote: > Adding a big "if [ "${rc_ng}" = "NO" ]; then echo "rc_ng=NO is > deprecated, unsupported, and will go away in the next release"; fi" to > the scripts allows us to cover our rears, This is a good idea, but I would go even further. At the top of every rcOG script, I would put echo ": This script is deprecated and should not be used." echo ": 'man rc' for more information." The transition period starts when the old scripts start whining. Do this today! ;-) The real problem with just axing rcOG is that people won't know what happened, nor where to look for information about what replaced it. A message like the above will serve as a warning not only to people who set rc_ng=NO, but also to people who start to edit one of the rcOG scripts. Tim From owner-freebsd-arch@FreeBSD.ORG Sun Apr 27 14:23:50 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8053B37B401 for ; Sun, 27 Apr 2003 14:23:50 -0700 (PDT) Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B02A43F75 for ; Sun, 27 Apr 2003 14:23:50 -0700 (PDT) (envelope-from DougB@freebsd.org) Received: from master.dougb.net (12-234-22-23.client.attbi.com[12.234.22.23]) by rwcrmhc51.attbi.com (rwcrmhc51) with SMTP id <200304272123490510019nrfe>; Sun, 27 Apr 2003 21:23:49 +0000 Date: Sun, 27 Apr 2003 14:23:49 -0700 (PDT) From: Doug Barton To: Joshua Goodall In-Reply-To: <20030427105313.GA507@roughtrade.net> Message-ID: <20030427142319.X3465@znfgre.qbhto.arg> References: <20030426154030.M13476@znfgre.qbhto.arg> <20030427105313.GA507@roughtrade.net> Organization: http://www.FreeBSD.org/ X-message-flag: Outlook -- Not just for spreading viruses anymore! MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-rc@yahoogroups.com cc: freebsd-arch@freebsd.org Subject: Re: [FreeBSD-rc] Re: RFC: Removal of the old rc system from -current X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Apr 2003 21:23:50 -0000 On Sun, 27 Apr 2003, Joshua Goodall wrote: > On Sat, Apr 26, 2003 at 03:46:08PM -0700, Doug Barton wrote: > > We're also starting to see some confusion on the part of users about > > having both systems on disk. > > Time to teach mergemaster about files that are now stale, so it can > offer to remove (or archive) them for the user? Yep. That patch is going in right after rcOG is removed. Doug -- This .signature sanitized for your protection From owner-freebsd-arch@FreeBSD.ORG Sun Apr 27 14:51:01 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1AAF137B401 for ; Sun, 27 Apr 2003 14:51:01 -0700 (PDT) Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 868B543FAF for ; Sun, 27 Apr 2003 14:51:00 -0700 (PDT) (envelope-from DougB@freebsd.org) Received: from master.dougb.net (12-234-22-23.client.attbi.com[12.234.22.23]) by rwcrmhc51.attbi.com (rwcrmhc51) with SMTP id <20030427215059051001apqme>; Sun, 27 Apr 2003 21:51:00 +0000 Date: Sun, 27 Apr 2003 14:50:59 -0700 (PDT) From: Doug Barton To: Scott Long In-Reply-To: <3EABD516.2090100@btc.adaptec.com> Message-ID: <20030427142856.H3465@znfgre.qbhto.arg> References: <20030426154030.M13476@znfgre.qbhto.arg> <3EAB12AC.8050707@btc.adaptec.com><3EAB7486.2060107@btc.adaptec.com> <20030427010221.H657@znfgre.qbhto.arg> <3EABD516.2090100@btc.adaptec.com> Organization: http://www.FreeBSD.org/ X-message-flag: Outlook -- Not just for spreading viruses anymore! MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: FreeBSD-rc@yahoogroups.com cc: freebsd-arch@freebsd.org Subject: Re: [FreeBSD-rc] Re: RFC: Removal of the old rc system from -current X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Apr 2003 21:51:01 -0000 On Sun, 27 Apr 2003, Scott Long wrote: > Doug, > > My premise is this: there are people who cvsup and build world on a > regular basis, track current@, etc, and there are those who are only > interested in running official releases. My concern is not the first > group, but the second group. So far I agree with you 100%. :) > The old rc system has been around for quite some time, and it might be a > shock if it disappears without warning. The fact that 5.1 has the > possiblity of being a worthly release means that more people are likely > to jump straight from 4.x to 5.1, and might not be aware of rcNG from > 5.0. So the question I'm asking is, which is a greater shock. Making a clean break from old to new in the 5.1 release, or leaving the bits around but non-functional in 5.1, and then yanking them away in 5.2? As others have pointed out, Joe Average User interacts with the rc system through only one channel, the config files (rc.conf, rc.firewall, sysctl.conf, etc.). That mechanism is totally unchanged from branch to branch. We're even supporting old names for variables like xntpd, portmap, etc. The other thing that occurs to me is that if the people you're most concerned about are those installing the release for the first time, perhaps we can work together on a splash screen in sysinstall that highlights this as one of the new features in 5.x? While I understand your concerns from a general release engineering perspective, because of the uniqueness of this case, I not only think that they are unfounded, but I think that your proposed solution will actually make the problem you're trying to solve worse. BTW, in addition to the annoying message in /etc/rc I also just committed a notice in UPDATING so we can catch as many people as possible before the change. Doug -- This .signature sanitized for your protection From owner-freebsd-arch@FreeBSD.ORG Mon Apr 28 03:03:40 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 023B637B401 for ; Mon, 28 Apr 2003 03:03:40 -0700 (PDT) Received: from mx.nsu.ru (mx.nsu.ru [212.192.164.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF16643F85 for ; Mon, 28 Apr 2003 03:03:38 -0700 (PDT) (envelope-from danfe@regency.nsu.ru) Received: from mail by mx.nsu.ru with drweb-scanned (Exim 3.36 #1 (Debian)) id 19A5VX-00043d-00; Mon, 28 Apr 2003 17:05:11 +0700 Received: from regency.nsu.ru ([193.124.210.26]) by mx.nsu.ru with esmtp (Exim 3.36 #1 (Debian)) id 19A5V5-0003vO-00; Mon, 28 Apr 2003 17:04:43 +0700 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.12.8/8.12.8) with ESMTP id h3SA2nCT072024; Mon, 28 Apr 2003 17:02:49 +0700 (NOVST) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.12.8/8.12.8/Submit) id h3SA2luw072023; Mon, 28 Apr 2003 17:02:47 +0700 (NOVST) Date: Mon, 28 Apr 2003 17:02:46 +0700 From: Alexey Dokuchaev To: Joshua Goodall Message-ID: <20030428100246.GB70290@regency.nsu.ru> References: <20030426154030.M13476@znfgre.qbhto.arg> <20030427105313.GA507@roughtrade.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030427105313.GA507@roughtrade.net> User-Agent: Mutt/1.4i X-Envelope-To: joshua@roughtrade.net, freebsd-arch@freebsd.org, freebsd-rc@yahoogroups.com X-Bogosity: No, tests=bogofilter, spamicity=0.000174, version=0.11.1.4 X-Spam-Status: No, hits=-34.0 required=5.0 tests=BOGOFILTER_TEST_PASS,EMAIL_ATTRIBUTION,IN_REP_TO, QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_MUTT version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) cc: freebsd-rc@yahoogroups.com cc: freebsd-arch@freebsd.org Subject: Re: RFC: Removal of the old rc system from -current X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2003 10:03:41 -0000 On Sun, Apr 27, 2003 at 08:53:13PM +1000, Joshua Goodall wrote: > On Sat, Apr 26, 2003 at 03:46:08PM -0700, Doug Barton wrote: > > We're also starting to see some confusion on the part of users about > > having both systems on disk. > > Time to teach mergemaster about files that are now stale, so it can > offer to remove (or archive) them for the user? It would be nice to teach make intallworld to remove stale files from the base as well. ./danfe From owner-freebsd-arch@FreeBSD.ORG Mon Apr 28 05:06:40 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D9B4E37B401 for ; Mon, 28 Apr 2003 05:06:40 -0700 (PDT) Received: from gw.nectar.cc (gw.nectar.cc [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 05E2343F75 for ; Mon, 28 Apr 2003 05:06:40 -0700 (PDT) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.nectar.cc (Postfix) with ESMTP id 6DE68E; Mon, 28 Apr 2003 07:06:39 -0500 (CDT) Received: by madman.celabo.org (Postfix, from userid 1001) id BA07878C66; Mon, 28 Apr 2003 07:06:38 -0500 (CDT) Date: Mon, 28 Apr 2003 07:06:38 -0500 From: "Jacques A. Vidrine" To: Poul-Henning Kamp Message-ID: <20030428120638.GA3289@madman.celabo.org> References: <31398.1049876261@critter.freebsd.dk> <20030409122620.GC19391@madman.celabo.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030409122620.GC19391@madman.celabo.org> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.3i-ja.1 cc: arch@freebsd.org Subject: Re: endianess of /etc/pwd.db X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2003 12:06:41 -0000 On Wed, Apr 09, 2003 at 07:26:20AM -0500, Jacques A. Vidrine wrote: > On Wed, Apr 09, 2003 at 10:17:41AM +0200, Poul-Henning Kamp wrote: > > > > Kris ran into this problem: copying a /etc/pwd.db from one endianess > > to another gave him really weird uid/gid numbers. > > > > The DB code itself is endianess-agnostic, so the first warning one > > gets is the weird UID/GID. > > > > Should we make the endianess of this file explicit to prevent this > > pit-fall for our users ? The cost would be less than epsilon. > > I am working in this area recently, and the exact same thought > occurred to me. I think we should do it. I would add a file format > version flag, the absence of which indicates the current MD format, > and adjust getpwent/pwd_mkdb accordingly. Are there any other tools > that would need to be touched? In case you didn't otherwise notice, this is done. The `.db' files now have versioned entries. It is necessary for the `old MD formatted' and `new MI formatted' entries to co-exist within the .db files so that old binaries still work. A `version key' within the database indicates to consumers what version they should use for lookups. The key is "\xFF" "VERSION" (8 bytes) and the value is a single byte representation of the integer version. The `old MD formatted' version is version 3; the `new MI formatted' version is version 4. All entries have historically had a single-byte tag to seperate the namespace for lookups by name, by user-ID, and so forth. The tags have had values that happened to be ASCII-encoded digits (i.e. '1' -> '\x31', '2' -> 'x32', ... ). These tags are now interpreted to contain the version in the upper four bits, and the namespace in the lower four bits. (Now you see why I picked version 3 for old entries.) For example, the keys for the entry `nectar:*:1001:...' on i386 would be "\x31" "nectar" MD (version 3) by name "\x32" "\xe9\x03\0\0" MD (version 3) by user-ID "\x41" "nectar" MI (version 4) by name "\x42" "\0\0\x03\xe9" MI (version 4) by user-ID Version 4 (MI formatted) entries have all integers encoded as 32-bit values in network byte order, but are otherwise the same as the old MD formatted entries. libc will read version 4 entries if the version key is present, or else attempt to read version 3 entries. pwd_mkdb creates both version 3 and version 4 entries. Thus, you may safely move your versioned '.db' files between architectures (as long as the DB format itself doesn't change!), and binaries using a new libc will return the right results for getpwent() et. al. Cheers, -- Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal nectar@celabo.org . jvidrine@verio.net . nectar@freebsd.org . nectar@kth.se From owner-freebsd-arch@FreeBSD.ORG Mon Apr 28 07:02:49 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AE83437B401 for ; Mon, 28 Apr 2003 07:02:49 -0700 (PDT) Received: from h132-197-179-27.gte.com (h132-197-179-27.gte.com [132.197.179.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF83143F93 for ; Mon, 28 Apr 2003 07:02:46 -0700 (PDT) (envelope-from ak03@gte.com) Received: from kanpc.gte.com (ak03@localhost [127.0.0.1]) h3SE2jnT099447; Mon, 28 Apr 2003 10:02:45 -0400 (EDT) (envelope-from ak03@kanpc.gte.com) Received: (from ak03@localhost) by kanpc.gte.com (8.12.9/8.12.9/Submit) id h3SE2iYh099446; Mon, 28 Apr 2003 10:02:44 -0400 (EDT) Date: Mon, 28 Apr 2003 10:02:44 -0400 From: Alexander Kabaev To: Bodo =?KOI8-R?Q?R=FCskamp?= Message-Id: <20030428100244.2e9caf88.ak03@gte.com> In-Reply-To: <5E112B5E-7897-11D7-BB6A-000393DB98F8@mac.com> References: <5E112B5E-7897-11D7-BB6A-000393DB98F8@mac.com> Organization: Verizon Data Services X-Mailer: Sylpheed version 0.8.11claws90 (GTK+ 1.2.10; i386-portbld-freebsd5.0) Mime-Version: 1.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit cc: arch@freebsd.org Subject: Re: misc patches to FreeBSD (Geode, USB, kqueue, ObjC) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2003 14:02:50 -0000 On Sun, 27 Apr 2003 12:02:34 +0200 Bodo Rüskamp wrote: > > http://www.clabsms.de/FreeBSD/patch.contrib.libobjc.objc.hash.h > http://www.clabsms.de/FreeBSD/patch.contrib.libobjc.objc.thr.h > Patches for the ObjC include headers that are required, if you use GCC > > with all warnings turned on. Those should probably be reported to GCC team. FreeBSD does not maintain local patches against stock libobjc sources and would like to keep it that way. Thanks a lot for submitting your patches. -- Alexander Kabaev From owner-freebsd-arch@FreeBSD.ORG Mon Apr 28 07:13:48 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2CCB837B401; Mon, 28 Apr 2003 07:13:48 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F4F643F75; Mon, 28 Apr 2003 07:13:47 -0700 (PDT) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.9/8.12.9) with ESMTP id h3SEDj46099401; Mon, 28 Apr 2003 16:13:45 +0200 (CEST) (envelope-from phk@phk.freebsd.dk) To: "Jacques A. Vidrine" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 28 Apr 2003 07:06:38 CDT." <20030428120638.GA3289@madman.celabo.org> Date: Mon, 28 Apr 2003 16:13:45 +0200 Message-ID: <99400.1051539225@critter.freebsd.dk> cc: arch@freebsd.org Subject: Re: endianess of /etc/pwd.db X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2003 14:13:48 -0000 In message <20030428120638.GA3289@madman.celabo.org>, "Jacques A. Vidrine" writ es: >On Wed, Apr 09, 2003 at 07:26:20AM -0500, Jacques A. Vidrine wrote: >> On Wed, Apr 09, 2003 at 10:17:41AM +0200, Poul-Henning Kamp wrote: >> > >> > Kris ran into this problem: copying a /etc/pwd.db from one endianess >> > to another gave him really weird uid/gid numbers. >> > >> > The DB code itself is endianess-agnostic, so the first warning one >> > gets is the weird UID/GID. >> > >> > Should we make the endianess of this file explicit to prevent this >> > pit-fall for our users ? The cost would be less than epsilon. > >In case you didn't otherwise notice, this is done. I could be a bit worried about doubling the size of the file, but for a transistion period it does make sense. Great work! -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Mon Apr 28 08:53:12 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1EC2E37B401 for ; Mon, 28 Apr 2003 08:53:12 -0700 (PDT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 49C2643F85 for ; Mon, 28 Apr 2003 08:53:11 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.9/8.12.6) with ESMTP id h3SFrAVI045838; Mon, 28 Apr 2003 08:53:10 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9/8.12.6/Submit) id h3SFrA0w045837; Mon, 28 Apr 2003 08:53:10 -0700 (PDT) Date: Mon, 28 Apr 2003 08:53:10 -0700 (PDT) From: Matthew Dillon Message-Id: <200304281553.h3SFrA0w045837@apollo.backplane.com> To: Scott Long References: <20030426154030.M13476@znfgre.qbhto.arg> <3EAB12AC.8050707@btc.adaptec.com> cc: freebsd-rc@yahoogroups.com cc: freebsd-arch@freebsd.org Subject: Re: RFC: Removal of the old rc system from -current X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2003 15:53:12 -0000 :Doug, : :I totally understand and support the issues with maintenance. I do, :however, have a couple of questions: : :1. Have all ports been preened of dependence on rcOG? :2. What about 3rd party software that is not in ports? : :Would it be possible and acceptable to officially deprecate rcOG in 5.1 :and then remove it sometime in June or July? I understand that this :extends the maintenance of rcOG a tiny bit, but it will also help users :and vendors transition. Also, will any seatbelts be in place to catch :software that tries to do things the rcOG way? : :Thanks! : :Scott I think you can safely scrap rcOG in 5.x. Ports should not be touching /etc/rc* scripts at all, except perhaps /etc/rc.conf, and ports install their own startup scripts in /usr/local/etc/rc.d (which I assume is still fully supported in rcNG). Most developers are conditioned not to touch the actual rc scripts in /etc so I would expect that getting rid of rcOG in 5.x would be an almost painless affair. Focus on the things that really could cause problems, not on the things that are not likely to. -Matt From owner-freebsd-arch@FreeBSD.ORG Mon Apr 28 10:34:37 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6AE0537B404 for ; Mon, 28 Apr 2003 10:34:37 -0700 (PDT) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 94F2843F93 for ; Mon, 28 Apr 2003 10:34:36 -0700 (PDT) (envelope-from DougB@freebsd.org) Received: from master.dougb.net (12-234-22-23.client.attbi.com[12.234.22.23]) by sccrmhc02.attbi.com (sccrmhc02) with SMTP id <2003042817343500200o1pgse>; Mon, 28 Apr 2003 17:34:35 +0000 Date: Mon, 28 Apr 2003 10:34:34 -0700 (PDT) From: Doug Barton To: Alexey Dokuchaev In-Reply-To: <20030428100246.GB70290@regency.nsu.ru> Message-ID: <20030428103349.G3894@znfgre.qbhto.arg> References: <20030426154030.M13476@znfgre.qbhto.arg> <20030427105313.GA507@roughtrade.net> <20030428100246.GB70290@regency.nsu.ru> Organization: http://www.FreeBSD.org/ X-message-flag: Outlook -- Not just for spreading viruses anymore! MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-arch@freebsd.org Subject: Re: [FreeBSD-rc] Re: RFC: Removal of the old rc system from -current X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2003 17:34:37 -0000 On Mon, 28 Apr 2003, Alexey Dokuchaev wrote: > On Sun, Apr 27, 2003 at 08:53:13PM +1000, Joshua Goodall wrote: > > On Sat, Apr 26, 2003 at 03:46:08PM -0700, Doug Barton wrote: > > > We're also starting to see some confusion on the part of users about > > > having both systems on disk. > > > > Time to teach mergemaster about files that are now stale, so it can > > offer to remove (or archive) them for the user? > > It would be nice to teach make intallworld to remove stale files from > the base as well. There is an enormous amount of discussion about that point in the -current archives. Suffice it to say, it's not nearly as easy as it sounds. Doug -- This .signature sanitized for your protection From owner-freebsd-arch@FreeBSD.ORG Mon Apr 28 12:28:58 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2AC9837B401 for ; Mon, 28 Apr 2003 12:28:58 -0700 (PDT) Received: from mail.westbend.net (ns1.westbend.net [216.47.253.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 00CA143FBD for ; Mon, 28 Apr 2003 12:28:57 -0700 (PDT) (envelope-from hetzels@westbend.net) Received: from Admin02 (admin02.westbend.net [216.47.253.19]) by mail.westbend.net (8.12.9/8.12.9) with SMTP id h3SJSrdR020745; Mon, 28 Apr 2003 14:28:53 -0500 (CDT) (envelope-from hetzels@westbend.net) Message-ID: <009001c30dbc$684a2c10$13fd2fd8@Admin02> From: "Scot W. Hetzel" To: References: <20030426154030.M13476@znfgre.qbhto.arg> Date: Mon, 28 Apr 2003 14:28:54 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Spam-Status: No, hits=-0.3 required=8.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_OE version=2.43 cc: freebsd-rc@yahoogroups.com Subject: Re: Removal of the old rc system from -current X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2003 19:28:58 -0000 From: "Doug Barton" > 2. Backport /etc/rc.subr to RELENG_4 prior to 4.9-Release. The purpose > here is to allow ports authors to make use of the rcNG system for their > startup scripts, and to possibly allow us to backport major features that > just work better in the NG framework. > I started porting my ports rc scripts to work on both rcNG and rcOG systems. In this process I found the ideal solution for the ports rc.d script: 1. define default port variables in the script 2. check for /etc/rc.subr a. if rc.subr exists, use rcNG style b. if rc.subr not exists 1. source /etc/defaults/rc.conf (or /etc/rc.conf) 2. use rcOG style This way we can keep compatibility with previous releases as well in the ports tree. (see ports/security/cyrus-sasl/files/*.sh & PR 51505). Then after a period of time we could drop the rcOG support from the ports tree. Another option would be to have bsd.port.mk detect that /etc/rc.subr doesn't exist, and then install a rc.subr on these older systems. Scot From owner-freebsd-arch@FreeBSD.ORG Mon Apr 28 12:45:04 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 604FE37B401; Mon, 28 Apr 2003 12:45:04 -0700 (PDT) Received: from magic.adaptec.com (magic-mail.adaptec.com [208.236.45.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id A15CF43FA3; Mon, 28 Apr 2003 12:45:01 -0700 (PDT) (envelope-from scott_long@btc.adaptec.com) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.11.6/8.11.6) with ESMTP id h3SJg8Z06018; Mon, 28 Apr 2003 12:42:08 -0700 Received: from btc.btc.adaptec.com ([10.100.0.52]) by redfish.adaptec.com (8.8.8p2+Sun/8.8.8) with ESMTP id MAA11696; Mon, 28 Apr 2003 12:44:53 -0700 (PDT) Received: from btc.adaptec.com (hollin [10.100.253.56]) by btc.btc.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id NAA01738; Mon, 28 Apr 2003 13:44:51 -0600 (MDT) Message-ID: <3EAD83F5.7030302@btc.adaptec.com> Date: Mon, 28 Apr 2003 13:41:41 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3) Gecko/20030414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Doug Barton References: <20030426154030.M13476@znfgre.qbhto.arg> <20030427105313.GA507@roughtrade.net> <20030428100246.GB70290@regency.nsu.ru> <20030428103349.G3894@znfgre.qbhto.arg> In-Reply-To: <20030428103349.G3894@znfgre.qbhto.arg> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Alexey Dokuchaev cc: freebsd-arch@freebsd.org Subject: Re: [FreeBSD-rc] Re: RFC: Removal of the old rc system from -current X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2003 19:45:04 -0000 Doug Barton wrote: > On Mon, 28 Apr 2003, Alexey Dokuchaev wrote: > > >>On Sun, Apr 27, 2003 at 08:53:13PM +1000, Joshua Goodall wrote: >> >>>On Sat, Apr 26, 2003 at 03:46:08PM -0700, Doug Barton wrote: >>> >>>>We're also starting to see some confusion on the part of users about >>>>having both systems on disk. >>> >>>Time to teach mergemaster about files that are now stale, so it can >>>offer to remove (or archive) them for the user? >> >>It would be nice to teach make intallworld to remove stale files from >>the base as well. > > > There is an enormous amount of discussion about that point in the -current > archives. Suffice it to say, it's not nearly as easy as it sounds. > > Doug > Doug, I think that you and others have convinced me that there isn't an overwhelming need to deprecate rcOG. The only gate to removing it for 5.1 is that I would like for you and Scot Hetzel to get with Bruce Mah and write up appropriate release documentation to help users with any transition issues. I know that Bruce has some specific questions that he would like answered. Thanks, Scott From owner-freebsd-arch@FreeBSD.ORG Mon Apr 28 13:52:11 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 422B137B404; Mon, 28 Apr 2003 13:52:11 -0700 (PDT) Received: from mx.nsu.ru (mx.nsu.ru [212.192.164.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED90F43F3F; Mon, 28 Apr 2003 13:52:09 -0700 (PDT) (envelope-from danfe@regency.nsu.ru) Received: from mail by mx.nsu.ru with drweb-scanned (Exim 3.36 #1 (Debian)) id 19AFdN-00078E-00; Tue, 29 Apr 2003 03:53:57 +0700 Received: from regency.nsu.ru ([193.124.210.26]) by mx.nsu.ru with esmtp (Exim 3.36 #1 (Debian)) id 19AFd1-0006zA-00; Tue, 29 Apr 2003 03:53:35 +0700 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.12.8/8.12.8) with ESMTP id h3SKpaCT091448; Tue, 29 Apr 2003 03:51:36 +0700 (NOVST) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.12.8/8.12.8/Submit) id h3SKpZLj091447; Tue, 29 Apr 2003 03:51:36 +0700 (NOVST) Date: Tue, 29 Apr 2003 03:51:35 +0700 From: Alexey Dokuchaev To: Doug Barton Message-ID: <20030428205135.GA91050@regency.nsu.ru> References: <20030426154030.M13476@znfgre.qbhto.arg> <20030427105313.GA507@roughtrade.net> <20030428100246.GB70290@regency.nsu.ru> <20030428103349.G3894@znfgre.qbhto.arg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030428103349.G3894@znfgre.qbhto.arg> User-Agent: Mutt/1.4i X-Envelope-To: DougB@freebsd.org, freebsd-arch@freebsd.org X-Bogosity: No, tests=bogofilter, spamicity=0.000006, version=0.11.1.4 X-Spam-Status: No, hits=-34.0 required=5.0 tests=BOGOFILTER_TEST_PASS,EMAIL_ATTRIBUTION,IN_REP_TO, QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_MUTT version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) cc: freebsd-arch@freebsd.org Subject: Re: [FreeBSD-rc] Re: RFC: Removal of the old rc system from -current X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2003 20:52:11 -0000 On Mon, Apr 28, 2003 at 10:34:34AM -0700, Doug Barton wrote: > On Mon, 28 Apr 2003, Alexey Dokuchaev wrote: > > > On Sun, Apr 27, 2003 at 08:53:13PM +1000, Joshua Goodall wrote: > > > On Sat, Apr 26, 2003 at 03:46:08PM -0700, Doug Barton wrote: > > > > We're also starting to see some confusion on the part of users about > > > > having both systems on disk. > > > > > > Time to teach mergemaster about files that are now stale, so it can > > > offer to remove (or archive) them for the user? > > > > It would be nice to teach make intallworld to remove stale files from > > the base as well. > > There is an enormous amount of discussion about that point in the -current > archives. Suffice it to say, it's not nearly as easy as it sounds. Thanks for the pointers; I think I really need start reading current@ nevertheless some of my friendly committers said it turned to chat@ rather recently. ;-) Since of my perfectionism, I might consider doing some work (if not removing the issue completely at some point) in this area. ./danfe From owner-freebsd-arch@FreeBSD.ORG Mon Apr 28 13:56:10 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E835837B401 for ; Mon, 28 Apr 2003 13:56:10 -0700 (PDT) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3DD1543F93 for ; Mon, 28 Apr 2003 13:56:10 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.9/8.12.9) with ESMTP id h3SKtpm2067250; Mon, 28 Apr 2003 13:55:51 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.9/8.12.9/Submit) id h3SKtpjg067249; Mon, 28 Apr 2003 13:55:51 -0700 (PDT) Date: Mon, 28 Apr 2003 13:55:51 -0700 From: "David O'Brien" To: Mike Makonnen Message-ID: <20030428205551.GB67147@dragon.nuxi.com> References: <20030426154030.M13476@znfgre.qbhto.arg> <20030427005543.GA96834@BSDWins.Com> <20030427060142.JOJH28930.out004.verizon.net@kokeb.ambesa.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030427060142.JOJH28930.out004.verizon.net@kokeb.ambesa.net> User-Agent: Mutt/1.4i X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: FreeBSD-rc@yahoogroups.com cc: freebsd-arch@freebsd.org Subject: Re: [FreeBSD-rc] Re: RFC: Removal of the old rc system from -current X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: FreeBSD-rc@yahoogroups.com, freebsd-arch@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2003 20:56:11 -0000 On Sun, Apr 27, 2003 at 02:01:41AM -0400, Mike Makonnen wrote: > > I did notice something the other day, though, that I have a > > question about. What is the status of /etc/netstart? Are there > > plans to upgrade it to be aware of rcNG? ... > We should have functionality equivalent to it by 5.2. I don't think that it > should be a requirement to meet before removing rcOG, though. I have to strongly disagree. I use 'netstart' too often on my main development machines to be with out for any amount of time. From owner-freebsd-arch@FreeBSD.ORG Mon Apr 28 14:13:34 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7F18E37B401; Mon, 28 Apr 2003 14:13:34 -0700 (PDT) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id C857443F93; Mon, 28 Apr 2003 14:13:31 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by canning.wemm.org (Postfix) with ESMTP id ABDF12A7EA; Mon, 28 Apr 2003 14:13:31 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Scott Long In-Reply-To: <3EAD83F5.7030302@btc.adaptec.com> Date: Mon, 28 Apr 2003 14:13:31 -0700 From: Peter Wemm Message-Id: <20030428211331.ABDF12A7EA@canning.wemm.org> cc: Alexey Dokuchaev cc: Doug Barton cc: freebsd-arch@freebsd.org Subject: Re: [FreeBSD-rc] Re: RFC: Removal of the old rc system from -current X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2003 21:13:34 -0000 Scott Long wrote: > I think that you and others have convinced me that there isn't an > overwhelming need to deprecate rcOG. My take on this whole thing is that having two implementations doesn't encourage a clean break. Suppose we have two third party vendors. One supplies a rcOG hook because they were too lazy to convert it, and put in their instructions "Be sure to set rcng=NO in /etc/rc.conf". Then, you get another component from another vendor, who only supplies a rcNG startup module. The user now has two conflicting sets of startup hooks to reconcile and will be forced to get their hands dirty and translate one of them to the other. IMHO, make a clean break and get it over and done with. Get everybody on the same page. Making the clean break also means that we will find anything that has been missed (eg: /etc/netstart as referenced later in this thread) sooner rather than later. Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-arch@FreeBSD.ORG Mon Apr 28 14:25:38 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0AF6837B401; Mon, 28 Apr 2003 14:25:38 -0700 (PDT) Received: from mx.nsu.ru (mx.nsu.ru [212.192.164.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id B58B043FCB; Mon, 28 Apr 2003 14:25:36 -0700 (PDT) (envelope-from danfe@regency.nsu.ru) Received: from mail by mx.nsu.ru with drweb-scanned (Exim 3.36 #1 (Debian)) id 19AG8d-0000qp-00; Tue, 29 Apr 2003 04:26:15 +0700 Received: from regency.nsu.ru ([193.124.210.26]) by mx.nsu.ru with esmtp (Exim 3.36 #1 (Debian)) id 19AG8N-0000kR-00; Tue, 29 Apr 2003 04:25:59 +0700 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.12.8/8.12.8) with ESMTP id h3SLO0CT092414; Tue, 29 Apr 2003 04:24:00 +0700 (NOVST) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.12.8/8.12.8/Submit) id h3SLO0X2092413; Tue, 29 Apr 2003 04:24:00 +0700 (NOVST) Date: Tue, 29 Apr 2003 04:24:00 +0700 From: Alexey Dokuchaev To: Peter Wemm Message-ID: <20030428212400.GC91050@regency.nsu.ru> References: <3EAD83F5.7030302@btc.adaptec.com> <20030428211331.ABDF12A7EA@canning.wemm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030428211331.ABDF12A7EA@canning.wemm.org> User-Agent: Mutt/1.4i X-Envelope-To: peter@wemm.org, scott_long@btc.adaptec.com, DougB@freebsd.org, freebsd-arch@freebsd.org X-Bogosity: No, tests=bogofilter, spamicity=0.000009, version=0.11.1.4 X-Spam-Status: No, hits=-34.0 required=5.0 tests=BOGOFILTER_TEST_PASS,EMAIL_ATTRIBUTION,IN_REP_TO, QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_MUTT version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) cc: Scott Long cc: Doug Barton cc: freebsd-arch@freebsd.org Subject: Re: [FreeBSD-rc] Re: RFC: Removal of the old rc system from -current X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2003 21:25:38 -0000 On Mon, Apr 28, 2003 at 02:13:31PM -0700, Peter Wemm wrote: > Scott Long wrote: > > > I think that you and others have convinced me that there isn't an > > overwhelming need to deprecate rcOG. > > My take on this whole thing is that having two implementations doesn't > encourage a clean break. Suppose we have two third party vendors. One > supplies a rcOG hook because they were too lazy to convert it, and put in > their instructions "Be sure to set rcng=NO in /etc/rc.conf". > > Then, you get another component from another vendor, who only supplies > a rcNG startup module. The user now has two conflicting sets of startup > hooks to reconcile and will be forced to get their hands dirty and translate > one of them to the other. > > IMHO, make a clean break and get it over and done with. Get everybody on > the same page. Making the clean break also means that we will find anything > that has been missed (eg: /etc/netstart as referenced later in this thread) > sooner rather than later. I tend to agree: vendors that are too concerned with keeping their software compatible with RELENG_4 could spend a few human/minutes for compatibility with rcOG; others should just go for rnNG as de facto standard. Dropping rcOG for 5.1(2?) seems to help to avoid future problems rather than creating them. Just my $.02. ./danfe From owner-freebsd-arch@FreeBSD.ORG Mon Apr 28 14:42:38 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2420F37B401 for ; Mon, 28 Apr 2003 14:42:38 -0700 (PDT) Received: from pop017.verizon.net (pop017pub.verizon.net [206.46.170.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id D827243F93 for ; Mon, 28 Apr 2003 14:42:36 -0700 (PDT) (envelope-from mtm@identd.net) Received: from kokeb.ambesa.net ([138.88.144.71]) by pop017.verizon.net (InterMail vM.5.01.05.33 201-253-122-126-133-20030313) with ESMTP id <20030428214236.TAYE27254.pop017.verizon.net@kokeb.ambesa.net>; Mon, 28 Apr 2003 16:42:36 -0500 Date: Mon, 28 Apr 2003 17:42:35 -0400 From: Mike Makonnen To: FreeBSD-rc@yahoogroups.com, freebsd-arch@freebsd.org In-Reply-To: <20030428205551.GB67147@dragon.nuxi.com> References: <20030426154030.M13476@znfgre.qbhto.arg> <20030427005543.GA96834@BSDWins.Com> <20030427060142.JOJH28930.out004.verizon.net@kokeb.ambesa.net> <20030428205551.GB67147@dragon.nuxi.com> X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i386-portbld-freebsd5.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at pop017.verizon.net from [138.88.144.71] at Mon, 28 Apr 2003 16:42:35 -0500 Message-Id: <20030428214236.TAYE27254.pop017.verizon.net@kokeb.ambesa.net> cc: dev-null@NUXI.com cc: FreeBSD-rc@yahoogroups.com cc: freebsd-arch@freebsd.org Subject: Re: [FreeBSD-rc] Re: RFC: Removal of the old rc system from -current X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2003 21:42:38 -0000 > ... > > We should have functionality equivalent to it by 5.2. I don't think that it > > should be a requirement to meet before removing rcOG, though. > > I have to strongly disagree. I use 'netstart' too often on my main > development machines to be with out for any amount of time. This should tide you over. Please test, make appropriate changes and commit. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc mtm@identd.net | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 mtm@FreeBSD.Org| FreeBSD - The Power To Serve Index: etc/netstart =================================================================== RCS file: /home/ncvs/src/etc/netstart,v retrieving revision 1.60 diff -u -r1.60 netstart --- etc/netstart 18 May 2001 09:14:39 -0000 1.60 +++ etc/netstart 28 Apr 2003 21:37:30 -0000 @@ -34,6 +34,36 @@ # the network by hand, this script will do it for you). # +. /etc/rc.subr + +load_rc_config 'XXX' +/etc/rc.d/pccard start +/etc/rc.d/hostname start +/etc/rc.d/ipmon start +/etc/rc.d/ipfilter start +/etc/rc.d/ipnat start +/etc/rc.d/ipfs start +/etc/rc.d/sppp start +/etc/rc.d/atm1.sh start +/etc/rc.d/atm2.sh start +/etc/rc.d/atm3.sh start +/etc/rc.d/netif start +/etc/rc.d/ipsec start +/etc/rc.d/dhclient start +/etc/rc.d/isdnd start +/etc/rc.d/ppp-user start +/etc/rc.d/ipfw start +/etc/rc.d/network2 start +/etc/rc.d/ip6fw start +/etc/rc.d/network_ipv6 start +/etc/rc.d/mroute6d start +/etc/rc.d/route6d start +/etc/rc.d/mrouted start +/etc/rc.d/routed start +/etc/rc.d/nisdomain start + +exit 0 + # If there is a global system configuration file, suck it in. if [ -f /etc/defaults/rc.conf ]; then . /etc/defaults/rc.conf From owner-freebsd-arch@FreeBSD.ORG Mon Apr 28 14:46:19 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 38B3C37B401; Mon, 28 Apr 2003 14:46:19 -0700 (PDT) Received: from magic.adaptec.com (magic-mail.adaptec.com [208.236.45.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 83B6A43F85; Mon, 28 Apr 2003 14:46:18 -0700 (PDT) (envelope-from Scott_Long@adaptec.com) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.11.6/8.11.6) with ESMTP id h3SLhPZ18613; Mon, 28 Apr 2003 14:43:25 -0700 Received: from OTCEXC01.otc.adaptec.com (otcexc01.otc.adaptec.com [10.12.1.27]) by redfish.adaptec.com (8.8.8p2+Sun/8.8.8) with ESMTP id OAA09379; Mon, 28 Apr 2003 14:46:15 -0700 (PDT) Received: by otcexc01.otc.adaptec.com with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Apr 2003 17:46:14 -0400 Message-ID: <6100BCEB85F8E244959C756C04E0EDD1010F7EEA@otcexc01.otc.adaptec.com> From: "Long, Scott" To: "'Peter Wemm'" Date: Mon, 28 Apr 2003 17:46:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain cc: Alexey Dokuchaev cc: Doug Barton cc: freebsd-arch@freebsd.org Subject: RE: [FreeBSD-rc] Re: RFC: Removal of the old rc system from -curr ent X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2003 21:46:19 -0000 Ok, let me modify and clarify my statement: I no longer feel that keeping rcOG around in a deprecated state for 5.1 is a requirement. However: 1. Doug should work out appropriate release documentation with Bruce Mah that notes the removal of rcOG in 5.1, what the benefits of rcNG is, and any transition steps neede by users and developers. 2. The issue of /etc/netstart should be addressed. If it truly provides unique functionality that is both useful and does not exist in rcNG, then that needs to be addressed before 5.1. Scott > -----Original Message----- > From: Peter Wemm [mailto:peter@wemm.org] > Sent: Monday, April 28, 2003 3:14 PM > To: Long, Scott > Cc: Doug Barton; Alexey Dokuchaev; freebsd-arch@freebsd.org > Subject: Re: [FreeBSD-rc] Re: RFC: Removal of the old rc system from > -current > > > Scott Long wrote: > > > I think that you and others have convinced me that there isn't an > > overwhelming need to deprecate rcOG. > > My take on this whole thing is that having two implementations doesn't > encourage a clean break. Suppose we have two third party > vendors. One > supplies a rcOG hook because they were too lazy to convert > it, and put in > their instructions "Be sure to set rcng=NO in /etc/rc.conf". > > Then, you get another component from another vendor, who only supplies > a rcNG startup module. The user now has two conflicting sets > of startup > hooks to reconcile and will be forced to get their hands > dirty and translate > one of them to the other. > > IMHO, make a clean break and get it over and done with. Get > everybody on > the same page. Making the clean break also means that we > will find anything > that has been missed (eg: /etc/netstart as referenced later > in this thread) > sooner rather than later. > > Cheers, > -Peter > -- > Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com > "All of this is for nothing if we don't go to the stars" - JMS/B5 > From owner-freebsd-arch@FreeBSD.ORG Mon Apr 28 14:48:33 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A574537B401; Mon, 28 Apr 2003 14:48:33 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 953EB43F3F; Mon, 28 Apr 2003 14:48:32 -0700 (PDT) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.9/8.12.9) with ESMTP id h3SLmP46045790; Mon, 28 Apr 2003 23:48:26 +0200 (CEST) (envelope-from phk@phk.freebsd.dk) To: Peter Wemm From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 28 Apr 2003 14:13:31 PDT." <20030428211331.ABDF12A7EA@canning.wemm.org> Date: Mon, 28 Apr 2003 23:48:25 +0200 Message-ID: <45789.1051566505@critter.freebsd.dk> cc: Alexey Dokuchaev cc: Scott Long cc: Doug Barton cc: freebsd-arch@freebsd.org Subject: Re: [FreeBSD-rc] Re: RFC: Removal of the old rc system from -current X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2003 21:48:34 -0000 In message <20030428211331.ABDF12A7EA@canning.wemm.org>, Peter Wemm writes: >Suppose we have two third party vendors. One >supplies a rcOG hook because they were too lazy to convert it, and put in >their instructions "Be sure to set rcng=NO in /etc/rc.conf". > >Then, you get another component from another vendor, who only supplies >a rcNG startup module. The user now has two conflicting sets of startup >hooks to reconcile and will be forced to get their hands dirty and translate >one of them to the other. This is exactly some people think that protocols and specifications should not offer options unless they are non-exclusive and support for them is mandatory. >IMHO, make a clean break and get it over and done with. Get everybody on >the same page. Making the clean break also means that we will find anything >that has been missed (eg: /etc/netstart as referenced later in this thread) >sooner rather than later. Agreed. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Mon Apr 28 15:19:51 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AFAD137B401; Mon, 28 Apr 2003 15:19:51 -0700 (PDT) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id BBEE143FA3; Mon, 28 Apr 2003 15:19:50 -0700 (PDT) (envelope-from DougB@freebsd.org) Received: from 12-234-22-23.client.attbi.com ([12.234.22.23]) by sccrmhc02.attbi.com (sccrmhc02) with SMTP id <2003042822194900200o3s4je>; Mon, 28 Apr 2003 22:19:49 +0000 Date: Mon, 28 Apr 2003 15:19:47 -0700 (PDT) From: Doug Barton To: "Long, Scott" In-Reply-To: <6100BCEB85F8E244959C756C04E0EDD1010F7EEA@otcexc01.otc.adaptec.com> Message-ID: <20030428151302.G60570@12-234-22-23.pyvrag.nggov.pbz> References: <6100BCEB85F8E244959C756C04E0EDD1010F7EEA@otcexc01.otc.adaptec.com> Organization: http://www.FreeBSD.org/ X-message-flag: Outlook -- Not just for spreading viruses anymore! MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Alexey Dokuchaev cc: freebsd-arch@freebsd.org cc: freebsd-rc@yahoogroups.com Subject: RE: [FreeBSD-rc] Re: RFC: Removal of the old rc system from -curr ent X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2003 22:19:52 -0000 On Mon, 28 Apr 2003, Long, Scott wrote: > Ok, let me modify and clarify my statement: > > I no longer feel that keeping rcOG around in a deprecated state > for 5.1 is a requirement. Fabulous! :) > However: > > 1. Doug should work out appropriate release documentation with > Bruce Mah that notes the removal of rcOG in 5.1, what the > benefits of rcNG is, and any transition steps neede by > users and developers. This was planned all along, but it's good that you pointed it out as a necessary step. Bruce and I already had one marginally related conversation about this, and I'll be glad to wrap this topic up with him, or anyone else from re@ that needs more details. > 2. The issue of /etc/netstart should be addressed. Mike sent in one canidate for this already. If the people here who rely on netstart could give it a go, we'll commit it asap. I'm glad this issue was raised, and of course, if there is anything else missing, please let us know asap. The date I have in mind for the axe'ification is May 1. This will give people who haven't caught up on e-mail yet a chance to respond, and give us a few days (including the weekend) to fix anything else that needs fixing before the expected code freeze on 5/5. If re@ has any more concrete plans than that for the freeze, or would like to suggest an alternate date for removing rcOG, then I'm happy to reconsider this. Thanks, Doug -- This .signature sanitized for your protection From owner-freebsd-arch@FreeBSD.ORG Mon Apr 28 15:35:58 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6874437B401; Mon, 28 Apr 2003 15:35:58 -0700 (PDT) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF4DD43FBD; Mon, 28 Apr 2003 15:35:57 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.9/8.12.9) with ESMTP id h3SMZbm2068217; Mon, 28 Apr 2003 15:35:37 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.9/8.12.9/Submit) id h3SMZbBq068216; Mon, 28 Apr 2003 15:35:37 -0700 (PDT) Date: Mon, 28 Apr 2003 15:35:37 -0700 From: "David O'Brien" To: Doug Barton Message-ID: <20030428223537.GA68013@dragon.nuxi.com> References: <6100BCEB85F8E244959C756C04E0EDD1010F7EEA@otcexc01.otc.adaptec.com> <20030428151302.G60570@12-234-22-23.pyvrag.nggov.pbz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030428151302.G60570@12-234-22-23.pyvrag.nggov.pbz> User-Agent: Mutt/1.4i X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: Alexey Dokuchaev cc: freebsd-rc@yahoogroups.com cc: "Long, Scott" cc: freebsd-arch@FreeBSD.org Subject: Re: [FreeBSD-rc] Re: RFC: Removal of the old rc system from -curr ent X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: freebsd-arch@FreeBSD.org, freebsd-rc@yahoogroups.com List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2003 22:35:58 -0000 On Mon, Apr 28, 2003 at 03:19:47PM -0700, Doug Barton wrote: > > 2. The issue of /etc/netstart should be addressed. > > Mike sent in one canidate for this already. If the people here who rely on > netstart could give it a go, we'll commit it asap. I'm glad this issue was > raised, and of course, if there is anything else missing, please let us > know asap. Just commit it. It mostly gets used when you're in a FUBAR situation. If it doesn't fully work, we'll fix it. I think it is enough that we have a WIP. From owner-freebsd-arch@FreeBSD.ORG Mon Apr 28 16:45:04 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9BC5E37B401 for ; Mon, 28 Apr 2003 16:45:04 -0700 (PDT) Received: from bsdone.bsdwins.com (www.bsdwins.com [192.58.184.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id B0A6C43F93 for ; Mon, 28 Apr 2003 16:45:03 -0700 (PDT) (envelope-from jwd@bsdwins.com) Received: from bsdone.bsdwins.com (localhost [127.0.0.1]) by bsdone.bsdwins.com (8.12.9/8.12.9) with ESMTP id h3SNdqC1066351; Mon, 28 Apr 2003 19:39:52 -0400 (EDT) (envelope-from jwd@www.bsdwins.com) Received: (from jwd@localhost) by bsdone.bsdwins.com (8.12.9/8.12.9/Submit) id h3SNdqjb066350; Mon, 28 Apr 2003 19:39:52 -0400 (EDT) Date: Mon, 28 Apr 2003 19:39:52 -0400 From: John De Boseky To: freebsd-arch@freebsd.org, freebsd-rc@yahoogroups.com Message-ID: <20030428233952.GA66229@BSDWins.Com> References: <6100BCEB85F8E244959C756C04E0EDD1010F7EEA@otcexc01.otc.adaptec.com> <20030428151302.G60570@12-234-22-23.pyvrag.nggov.pbz> <20030428223537.GA68013@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030428223537.GA68013@dragon.nuxi.com> User-Agent: Mutt/1.4.1i Subject: Re: [FreeBSD-rc] Re: RFC: Removal of the old rc system from -curr ent X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2003 23:45:04 -0000 ----- David O'Brien's Original Message ----- > On Mon, Apr 28, 2003 at 03:19:47PM -0700, Doug Barton wrote: > > > 2. The issue of /etc/netstart should be addressed. > > > > Mike sent in one canidate for this already. If the people here who rely on > > netstart could give it a go, we'll commit it asap. I'm glad this issue was > > raised, and of course, if there is anything else missing, please let us > > know asap. > > Just commit it. It mostly gets used when you're in a FUBAR situation. > If it doesn't fully work, we'll fix it. I think it is enough that we > have a WIP. I'll test and commit it later this evenning if it doesn't show up before then.. From owner-freebsd-arch@FreeBSD.ORG Mon Apr 28 19:15:35 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 29AE637B401 for ; Mon, 28 Apr 2003 19:15:35 -0700 (PDT) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id B347843F85 for ; Mon, 28 Apr 2003 19:15:33 -0700 (PDT) (envelope-from Alex.Wilkinson@dsto.defence.gov.au) Received: from dsto-ms2.dsto.defence.gov.au (dsto-ms2.dsto.defence.gov.au [131.185.2.150]) by digger1.defence.gov.au with ESMTP id h3T2Fq7U005777 for ; Tue, 29 Apr 2003 11:45:52 +0930 (CST) Received: from muttley.dsto.defence.gov.au (unverified) by dsto-ms2.dsto.defence.gov.au for ; Tue, 29 Apr 2003 11:45:26 +0930 Received: from ednex501.dsto.defence.gov.au (ednex501.dsto.defence.gov.au [131.185.2.81])h3T20bh27812 for ; Tue, 29 Apr 2003 11:30:37 +0930 (CST) Received: from squirm.dsto.defence.gov.au ([131.185.75.211]) by ednex501.dsto.defence.gov.au with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 28HDA7VZ; Tue, 29 Apr 2003 11:30:27 +0930 Date: Tue, 29 Apr 2003 11:30:37 +0930 (CST) From: "Wilkinson,Alex" X-X-Sender: wilkinsa@squirm.dsto.defence.gov.au To: freebsd-arch@freebsd.org In-Reply-To: <20030426154030.M13476@znfgre.qbhto.arg> Message-ID: <20030429112908.F55052@squirm.dsto.defence.gov.au> References: <20030426154030.M13476@znfgre.qbhto.arg> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RFC: Removal of the old rc system from -current X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Alex.Wilkinson@dsto.defence.gov.au List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2003 02:15:35 -0000 Is there a project page for this ? Anyone have a URL ? - aW :[ Please respect followups to -arch, and avoid cross-posting responses, thanks. ] : :Summary: : :I'm proposing the removal of the old rc system from HEAD, and all :subsequent 5.x releases. From owner-freebsd-arch@FreeBSD.ORG Mon Apr 28 19:24:03 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3FA7E37B401 for ; Mon, 28 Apr 2003 19:24:03 -0700 (PDT) Received: from bsdone.bsdwins.com (www.bsdwins.com [192.58.184.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 72A9043FA3 for ; Mon, 28 Apr 2003 19:24:02 -0700 (PDT) (envelope-from jwd@bsdwins.com) Received: from bsdone.bsdwins.com (localhost [127.0.0.1]) by bsdone.bsdwins.com (8.12.9/8.12.9) with ESMTP id h3T2IoC1067078; Mon, 28 Apr 2003 22:18:50 -0400 (EDT) (envelope-from jwd@www.bsdwins.com) Received: (from jwd@localhost) by bsdone.bsdwins.com (8.12.9/8.12.9/Submit) id h3T2Io6t067077; Mon, 28 Apr 2003 22:18:50 -0400 (EDT) Date: Mon, 28 Apr 2003 22:18:50 -0400 From: John De Boskey To: freebsd-arch@freebsd.org, freebsd-rc@yahoogroups.com Message-ID: <20030429021850.GA67022@BSDWins.Com> References: <6100BCEB85F8E244959C756C04E0EDD1010F7EEA@otcexc01.otc.adaptec.com> <20030428151302.G60570@12-234-22-23.pyvrag.nggov.pbz> <20030428223537.GA68013@dragon.nuxi.com> <20030428233952.GA66229@BSDWins.Com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030428233952.GA66229@BSDWins.Com> User-Agent: Mutt/1.4.1i Subject: /etc/netstart patch update (Was: Re: [FreeBSD-rc] Re: RFC: Removal of the old rc system from -curr ent) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2003 02:24:03 -0000 ----- John De Boseky's Original Message ----- > > I'll test and commit it later this evenning if it doesn't show up > before then.. Some comments: Is there a reason we have atm1, and then atm2.sh & atm3.sh? This naming scheme does not seem to be followed by any of the other numerically postfixed scripts. I believe etc/network_ipv6 needs the following patch: Index: etc/rc.d/network_ipv6 =================================================================== RCS file: /home/ncvs/src/etc/rc.d/network_ipv6,v retrieving revision 1.32 diff -u -r1.32 network_ipv6 --- etc/rc.d/network_ipv6 12 Oct 2002 10:31:31 -0000 1.32 +++ etc/rc.d/network_ipv6 29 Apr 2003 02:15:48 -0000 @@ -32,6 +32,8 @@ # REQUIRE: network2 # KEYWORD: FreeBSD +. /etc/rc.subr + name="network_ipv6" rcvar=`set_rcvar ipv6` start_cmd="network_ipv6_start" I'll get this and netstart committed in a bit. I can deal with atm?.sh if folks think it should be done. -John From owner-freebsd-arch@FreeBSD.ORG Mon Apr 28 20:01:33 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AE8AC37B401 for ; Mon, 28 Apr 2003 20:01:33 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id BBBED43F93 for ; Mon, 28 Apr 2003 20:01:32 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.8/8.12.3) with ESMTP id h3T31UA7085642; Mon, 28 Apr 2003 21:01:31 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 28 Apr 2003 21:01:26 -0600 (MDT) Message-Id: <20030428.210126.55832947.imp@bsdimp.com> To: mtm@identd.net From: "M. Warner Losh" In-Reply-To: <20030428214236.TAYE27254.pop017.verizon.net@kokeb.ambesa.net> References: <20030427060142.JOJH28930.out004.verizon.net@kokeb.ambesa.net> <20030428205551.GB67147@dragon.nuxi.com> <20030428214236.TAYE27254.pop017.verizon.net@kokeb.ambesa.net> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: dev-null@NUXI.com cc: FreeBSD-rc@yahoogroups.com cc: freebsd-arch@freebsd.org Subject: Re: [FreeBSD-rc] Re: RFC: Removal of the old rc system from -current X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2003 03:01:34 -0000 In message: <20030428214236.TAYE27254.pop017.verizon.net@kokeb.ambesa.net> Mike Makonnen writes: : > ... : > > We should have functionality equivalent to it by 5.2. I don't think that it : > > should be a requirement to meet before removing rcOG, though. : > : > I have to strongly disagree. I use 'netstart' too often on my main : > development machines to be with out for any amount of time. : : This should tide you over. : Please test, make appropriate changes and commit. : : Cheers. : -- : Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc : mtm@identd.net | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 : mtm@FreeBSD.Org| FreeBSD - The Power To Serve : : Index: etc/netstart : =================================================================== : RCS file: /home/ncvs/src/etc/netstart,v : retrieving revision 1.60 : diff -u -r1.60 netstart : --- etc/netstart 18 May 2001 09:14:39 -0000 1.60 : +++ etc/netstart 28 Apr 2003 21:37:30 -0000 : @@ -34,6 +34,36 @@ : # the network by hand, this script will do it for you). : # : : +. /etc/rc.subr : + : +load_rc_config 'XXX' : +/etc/rc.d/pccard start This is bogus, unless you are using OLDCARD. You really want devd here instead. : +/etc/rc.d/hostname start : +/etc/rc.d/ipmon start : +/etc/rc.d/ipfilter start : +/etc/rc.d/ipnat start : +/etc/rc.d/ipfs start : +/etc/rc.d/sppp start : +/etc/rc.d/atm1.sh start : +/etc/rc.d/atm2.sh start : +/etc/rc.d/atm3.sh start : +/etc/rc.d/netif start : +/etc/rc.d/ipsec start : +/etc/rc.d/dhclient start : +/etc/rc.d/isdnd start : +/etc/rc.d/ppp-user start : +/etc/rc.d/ipfw start : +/etc/rc.d/network2 start : +/etc/rc.d/ip6fw start : +/etc/rc.d/network_ipv6 start : +/etc/rc.d/mroute6d start : +/etc/rc.d/route6d start : +/etc/rc.d/mrouted start : +/etc/rc.d/routed start : +/etc/rc.d/nisdomain start From owner-freebsd-arch@FreeBSD.ORG Mon Apr 28 21:22:04 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2F35837B401 for ; Mon, 28 Apr 2003 21:22:04 -0700 (PDT) Received: from out005.verizon.net (out005pub.verizon.net [206.46.170.143]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2877243F75 for ; Mon, 28 Apr 2003 21:22:03 -0700 (PDT) (envelope-from mtm@identd.net) Received: from kokeb.ambesa.net ([138.88.144.71]) by out005.verizon.net (InterMail vM.5.01.05.33 201-253-122-126-133-20030313) with ESMTP id <20030429042202.ULRH25152.out005.verizon.net@kokeb.ambesa.net>; Mon, 28 Apr 2003 23:22:02 -0500 Date: Tue, 29 Apr 2003 00:22:01 -0400 From: Mike Makonnen To: FreeBSD-rc@yahoogroups.com In-Reply-To: <20030429021850.GA67022@BSDWins.Com> References: <6100BCEB85F8E244959C756C04E0EDD1010F7EEA@otcexc01.otc.adaptec.com> <20030428151302.G60570@12-234-22-23.pyvrag.nggov.pbz> <20030428223537.GA68013@dragon.nuxi.com> <20030428233952.GA66229@BSDWins.Com> <20030429021850.GA67022@BSDWins.Com> X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i386-portbld-freebsd5.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out005.verizon.net from [138.88.144.71] at Mon, 28 Apr 2003 23:22:01 -0500 Message-Id: <20030429042202.ULRH25152.out005.verizon.net@kokeb.ambesa.net> cc: freebsd-arch@freebsd.org cc: freebsd-rc@yahoogroups.com cc: jwd@bsdwins.com Subject: Re: /etc/netstart patch update (Was: Re: [FreeBSD-rc] Re: RFC: Removal of the old rc system from -curr ent) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2003 04:22:04 -0000 On Mon, 28 Apr 2003 22:18:50 -0400 John De Boskey wrote: > Some comments: > > Is there a reason we have atm1, and then atm2.sh & atm3.sh? This > naming scheme does not seem to be followed by any of the other > numerically postfixed scripts. If a script has a '.sh' suffix it means that it's is run inside the callers process. Otherwise, the default is to run the script in a subshell. In rcNG this means that if you need persistence of a variable from one script to another you need to give it a .sh suffix. The atm2.sh and atm3.sh scripts share a couple of variables, so it was necessary to have them execute in the same process as /etc/rc. Ideally, this shouldn't happen, but I don't have an ATM interface and I don't know how it's supposed to be setup, so I left those scripts largely untouched in hopes that someone who does use them can rewrite the scripts for rcNG. > I believe etc/network_ipv6 needs the following patch: Correct. Thanks. > I can deal > with atm?.sh if folks think it should be done. If you know what you're doing with ATM, yes please. Otherwise, please leave them as they are. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc mtm@identd.net | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 mtm@FreeBSD.Org| FreeBSD - The Power To Serve From owner-freebsd-arch@FreeBSD.ORG Mon Apr 28 21:28:50 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1B20837B401 for ; Mon, 28 Apr 2003 21:28:50 -0700 (PDT) Received: from pop015.verizon.net (pop015pub.verizon.net [206.46.170.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C80A43F85 for ; Mon, 28 Apr 2003 21:28:49 -0700 (PDT) (envelope-from mtm@identd.net) Received: from kokeb.ambesa.net ([138.88.144.71]) by pop015.verizon.net (InterMail vM.5.01.05.33 201-253-122-126-133-20030313) with ESMTP id <20030429042848.XQGV6016.pop015.verizon.net@kokeb.ambesa.net>; Mon, 28 Apr 2003 23:28:48 -0500 Date: Tue, 29 Apr 2003 00:28:47 -0400 From: Mike Makonnen To: "M. Warner Losh" In-Reply-To: <20030428.210126.55832947.imp@bsdimp.com> References: <20030427060142.JOJH28930.out004.verizon.net@kokeb.ambesa.net> <20030428205551.GB67147@dragon.nuxi.com> <20030428214236.TAYE27254.pop017.verizon.net@kokeb.ambesa.net> <20030428.210126.55832947.imp@bsdimp.com> X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i386-portbld-freebsd5.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at pop015.verizon.net from [138.88.144.71] at Mon, 28 Apr 2003 23:28:47 -0500 Message-Id: <20030429042848.XQGV6016.pop015.verizon.net@kokeb.ambesa.net> cc: FreeBSD-rc@yahoogroups.com cc: freebsd-arch@freebsd.org Subject: Re: [FreeBSD-rc] Re: RFC: Removal of the old rc system from -current X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2003 04:28:50 -0000 On Mon, 28 Apr 2003 21:01:26 -0600 (MDT) "M. Warner Losh" wrote: > : > : +. /etc/rc.subr > : + > : +load_rc_config 'XXX' > : +/etc/rc.d/pccard start > > This is bogus, unless you are using OLDCARD. You really want devd > here instead. > No. The intention here is to duplicate the functionality in netstart. The /etc/netstart script uses some functions in /etc/rc.network, sets up ipv6, and also sources /etc/rc.pccard. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc mtm@identd.net | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 mtm@FreeBSD.Org| FreeBSD - The Power To Serve From owner-freebsd-arch@FreeBSD.ORG Mon Apr 28 21:45:10 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 63DD137B401; Mon, 28 Apr 2003 21:45:10 -0700 (PDT) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6759843FA3; Mon, 28 Apr 2003 21:45:09 -0700 (PDT) (envelope-from archie@dellroad.org) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id VAA81756; Mon, 28 Apr 2003 21:38:40 -0700 (PDT) Received: from arch20m.dellroad.org (localhost [127.0.0.1]) by arch20m.dellroad.org (8.12.8/8.12.8) with ESMTP id h3T4cd2r069529; Mon, 28 Apr 2003 21:38:39 -0700 (PDT) (envelope-from archie@arch20m.dellroad.org) Received: (from archie@localhost) by arch20m.dellroad.org (8.12.8/8.12.8/Submit) id h3T4cdHE069528; Mon, 28 Apr 2003 21:38:39 -0700 (PDT) From: Archie Cobbs Message-Id: <200304290438.h3T4cdHE069528@arch20m.dellroad.org> In-Reply-To: <20030426231749.H48182@gamplex.bde.org> To: Bruce Evans Date: Mon, 28 Apr 2003 21:38:39 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII cc: Poul-Henning Kamp cc: gibbs@FreeBSD.ORG cc: freebsd-arch@FreeBSD.ORG Subject: Re: lots of malloc(M_WAITOK)'s in interrupt context from camisr X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2003 04:45:10 -0000 Bruce Evans wrote: > > I would tend to think that while sleeping in interrupt threads > > should be avoided, it should only be avoided "at reasonable cost", > > not "at any cost". > > I think it may actually work now in some cases, since there is now an > ithread context to sleep on, but camisr() in general is not such a [ moving this followup to -arch ] Random thought.. it's always seemed unnatural to me to say that interrupt threads can't sleep. Why couldn't the system be designed so that if an interrupt thread tried to sleep, it would actually sleep but atomically (a) detach itself from the interrupt and (b) spawn a new thread to handle future interrupts. I.e., sleep with "on demand" additional interrupt thread creation. To avoid reentrancy problems, we would probably also want to block re-entry into the same interrupt handler function until the original handler returned. If you did this, code wouldn't have to "know" whether it was running in an interrupt. Of course, for efficiency you don't want to do a lot of sleeping while handling interrupts, but in practice the need to probably only arises very rarely (e.g., insertion/removal, ifconfig up/down, etc.). -Archie __________________________________________________________________________ Archie Cobbs * Precision I/O * http://www.precisionio.com From owner-freebsd-arch@FreeBSD.ORG Mon Apr 28 22:11:56 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2709437B401 for ; Mon, 28 Apr 2003 22:11:56 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C46C43F3F for ; Mon, 28 Apr 2003 22:11:55 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.8/8.12.3) with ESMTP id h3T5BsA7086259; Mon, 28 Apr 2003 23:11:54 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 28 Apr 2003 23:11:45 -0600 (MDT) Message-Id: <20030428.231145.104032794.imp@bsdimp.com> To: mtm@identd.net From: "M. Warner Losh" In-Reply-To: <20030429042848.XQGV6016.pop015.verizon.net@kokeb.ambesa.net> References: <20030428214236.TAYE27254.pop017.verizon.net@kokeb.ambesa.net> <20030428.210126.55832947.imp@bsdimp.com> <20030429042848.XQGV6016.pop015.verizon.net@kokeb.ambesa.net> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: FreeBSD-rc@yahoogroups.com cc: freebsd-arch@freebsd.org Subject: Re: [FreeBSD-rc] Re: RFC: Removal of the old rc system from -current X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2003 05:11:56 -0000 In message: <20030429042848.XQGV6016.pop015.verizon.net@kokeb.ambesa.net> Mike Makonnen writes: : On Mon, 28 Apr 2003 21:01:26 -0600 (MDT) : "M. Warner Losh" wrote: : : > : : > : +. /etc/rc.subr : > : + : > : +load_rc_config 'XXX' : > : +/etc/rc.d/pccard start : > : > This is bogus, unless you are using OLDCARD. You really want devd : > here instead. : > : : No. : The intention here is to duplicate the functionality in netstart. : The /etc/netstart script uses some functions in /etc/rc.network, sets up : ipv6, and also sources /etc/rc.pccard. Almost right, but /etc/rc.pccard is nearly OBE. You have to run both pccard and devd in rcNG to do the right thing here. Trust me, I know a thing or two about pccard. Warner From owner-freebsd-arch@FreeBSD.ORG Mon Apr 28 23:58:40 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EE9C237B401 for ; Mon, 28 Apr 2003 23:58:40 -0700 (PDT) Received: from pop018.verizon.net (pop018pub.verizon.net [206.46.170.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0ED7943FBF for ; Mon, 28 Apr 2003 23:58:40 -0700 (PDT) (envelope-from mtm@identd.net) Received: from kokeb.ambesa.net ([138.88.144.71]) by pop018.verizon.net (InterMail vM.5.01.05.33 201-253-122-126-133-20030313) with ESMTP id <20030429065839.ZDGV17739.pop018.verizon.net@kokeb.ambesa.net>; Tue, 29 Apr 2003 01:58:39 -0500 Date: Tue, 29 Apr 2003 02:58:38 -0400 From: Mike Makonnen To: "M. Warner Losh" In-Reply-To: <20030428.231145.104032794.imp@bsdimp.com> References: <20030428214236.TAYE27254.pop017.verizon.net@kokeb.ambesa.net> <20030428.210126.55832947.imp@bsdimp.com> <20030429042848.XQGV6016.pop015.verizon.net@kokeb.ambesa.net> <20030428.231145.104032794.imp@bsdimp.com> X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i386-portbld-freebsd5.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at pop018.verizon.net from [138.88.144.71] at Tue, 29 Apr 2003 01:58:38 -0500 Message-Id: <20030429065839.ZDGV17739.pop018.verizon.net@kokeb.ambesa.net> cc: FreeBSD-rc@yahoogroups.com cc: freebsd-arch@freebsd.org Subject: Re: [FreeBSD-rc] Re: RFC: Removal of the old rc system from -current X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2003 06:58:41 -0000 On Mon, 28 Apr 2003 23:11:45 -0600 (MDT) "M. Warner Losh" wrote: > > Almost right, but /etc/rc.pccard is nearly OBE. You have to run both > pccard and devd in rcNG to do the right thing here. Trust me, I know > a thing or two about pccard. > I was not commenting as to the correctness of it. Just explaining why it was there. If it's broken please feel free to correct it. In that case, netstart in -STABLE might need unbreaking too. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc mtm@identd.net | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 mtm@FreeBSD.Org| FreeBSD - The Power To Serve From owner-freebsd-arch@FreeBSD.ORG Tue Apr 29 05:25:05 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0DC0137B401 for ; Tue, 29 Apr 2003 05:25:05 -0700 (PDT) Received: from gandalf.online.bg (gandalf.online.bg [217.75.128.9]) by mx1.FreeBSD.org (Postfix) with SMTP id 0ED0043F3F for ; Tue, 29 Apr 2003 05:25:03 -0700 (PDT) (envelope-from roam@ringlet.net) Received: (qmail 13871 invoked from network); 29 Apr 2003 12:19:19 -0000 Received: from office.sbnd.net (HELO straylight.ringlet.net) (217.75.140.130) by gandalf.online.bg with SMTP; 29 Apr 2003 12:19:19 -0000 Received: (qmail 48707 invoked by uid 1000); 29 Apr 2003 12:22:43 -0000 Date: Tue, 29 Apr 2003 15:22:42 +0300 From: Peter Pentchev To: "Scot W. Hetzel" Message-ID: <20030429122242.GB680@straylight.oblivion.bg> Mail-Followup-To: "Scot W. Hetzel" , freebsd-arch@freebsd.org, freebsd-rc@yahoogroups.com References: <20030426154030.M13476@znfgre.qbhto.arg> <009001c30dbc$684a2c10$13fd2fd8@Admin02> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TiqCXmo5T1hvSQQg" Content-Disposition: inline In-Reply-To: <009001c30dbc$684a2c10$13fd2fd8@Admin02> User-Agent: Mutt/1.5.4i cc: freebsd-rc@yahoogroups.com cc: freebsd-arch@freebsd.org Subject: Re: Removal of the old rc system from -current X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2003 12:25:05 -0000 --TiqCXmo5T1hvSQQg Content-Type: text/plain; charset=windows-1251 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 28, 2003 at 02:28:54PM -0500, Scot W. Hetzel wrote: > From: "Doug Barton" > > 2. Backport /etc/rc.subr to RELENG_4 prior to 4.9-Release. The purpose > > here is to allow ports authors to make use of the rcNG system for their > > startup scripts, and to possibly allow us to backport major features th= at > > just work better in the NG framework. > > > I started porting my ports rc scripts to work on both rcNG and rcOG syste= ms. > In this process I found the ideal solution for the ports rc.d script: >=20 > 1. define default port variables in the script > 2. check for /etc/rc.subr > a. if rc.subr exists, use rcNG style > b. if rc.subr not exists > 1. source /etc/defaults/rc.conf (or /etc/rc.conf) > 2. use rcOG style Actually, this ought to be more like: b. if rc.subr does not exist 1. source /etc/defaults/rc.conf 2. if the source_rc_confs function exists, execute it 3. if the source_rc_confs function does not exist, try to emulate it by checking for the files listed in the rc_conf_files variable and sourcing them if they exist. G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@sbnd.net roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence claims to be an Epimenides paradox, but it is lying. --TiqCXmo5T1hvSQQg Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD4DBQE+rm6S7Ri2jRYZRVMRAvinAJ0WgJcyu5/eC5GBBXMuHNnOZp49vQCYhA9J XQ0PR35LdlPZRT5SeH/g5w== =VXOV -----END PGP SIGNATURE----- --TiqCXmo5T1hvSQQg-- From owner-freebsd-arch@FreeBSD.ORG Tue Apr 29 10:03:29 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 36A2D37B4C7 for ; Tue, 29 Apr 2003 10:03:28 -0700 (PDT) Received: from mail.westbend.net (ns1.westbend.net [216.47.253.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2681343F93 for ; Tue, 29 Apr 2003 10:03:27 -0700 (PDT) (envelope-from hetzels@westbend.net) Received: from Admin02 (admin02.westbend.net [216.47.253.19]) by mail.westbend.net (8.12.9/8.12.9) with SMTP id h3TH3JdR002361; Tue, 29 Apr 2003 12:03:23 -0500 (CDT) (envelope-from hetzels@westbend.net) Message-ID: <008401c30e71$3fade480$13fd2fd8@Admin02> From: "Scot W. Hetzel" To: "Peter Pentchev" References: <20030426154030.M13476@znfgre.qbhto.arg> <009001c30dbc$684a2c10$13fd2fd8@Admin02> <20030429122242.GB680@straylight.oblivion.bg> Date: Tue, 29 Apr 2003 12:03:21 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Spam-Status: No, hits=-0.3 required=8.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_OE version=2.43 cc: freebsd-rc@yahoogroups.com cc: freebsd-arch@freebsd.org Subject: Re: Removal of the old rc system from -current X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2003 17:03:29 -0000 From: "Peter Pentchev" > From "Scot W. Hetzel" >> I started porting my ports rc scripts to work on both rcNG and rcOG systems. >>In this process I found the ideal solution for the ports rc.d script: >> >> 1. define default port variables in the script >> 2. check for /etc/rc.subr >> a. if rc.subr exists, use rcNG style >> b. if rc.subr not exists >> 1. source /etc/defaults/rc.conf (or /etc/rc.conf) >> 2. use rcOG style > >Actually, this ought to be more like: >b. if rc.subr does not exist >1. source /etc/defaults/rc.conf >2. if the source_rc_confs function exists, execute it >3. if the source_rc_confs function does not exist, > try to emulate it by checking for the files listed > in the rc_conf_files variable and sourcing them if > they exist. This is what I have in the rcOG portion of the script to bring in the rc.conf settings: # Suck in the configuration variables. if [ -z "${source_rc_confs_defined}" ]; then if [ -r /etc/defaults/rc.conf ]; then . /etc/defaults/rc.conf source_rc_confs elif [ -r /etc/rc.conf ]; then . /etc/rc.conf fi fi Any changes I should make to it? Scot From owner-freebsd-arch@FreeBSD.ORG Tue Apr 29 10:28:10 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 12BA737B401 for ; Tue, 29 Apr 2003 10:28:10 -0700 (PDT) Received: from gandalf.online.bg (gandalf.online.bg [217.75.128.9]) by mx1.FreeBSD.org (Postfix) with SMTP id 38B0343F93 for ; Tue, 29 Apr 2003 10:28:08 -0700 (PDT) (envelope-from roam@ringlet.net) Received: (qmail 18076 invoked from network); 29 Apr 2003 17:22:24 -0000 Received: from sbnd.online.bg (HELO straylight.ringlet.net) (217.75.129.196) by gandalf.online.bg with SMTP; 29 Apr 2003 17:22:22 -0000 Received: (qmail 81183 invoked by uid 1000); 29 Apr 2003 17:25:44 -0000 Date: Tue, 29 Apr 2003 20:25:44 +0300 From: Peter Pentchev To: "Scot W. Hetzel" Message-ID: <20030429172544.GA80819@straylight.oblivion.bg> Mail-Followup-To: "Scot W. Hetzel" , freebsd-arch@freebsd.org, freebsd-rc@yahoogroups.com References: <20030426154030.M13476@znfgre.qbhto.arg> <009001c30dbc$684a2c10$13fd2fd8@Admin02> <20030429122242.GB680@straylight.oblivion.bg> <008401c30e71$3fade480$13fd2fd8@Admin02> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GvXjxJ+pjyke8COw" Content-Disposition: inline In-Reply-To: <008401c30e71$3fade480$13fd2fd8@Admin02> User-Agent: Mutt/1.5.4i cc: freebsd-rc@yahoogroups.com cc: freebsd-arch@freebsd.org Subject: Re: Removal of the old rc system from -current X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2003 17:28:10 -0000 --GvXjxJ+pjyke8COw Content-Type: text/plain; charset=windows-1251 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 29, 2003 at 12:03:21PM -0500, Scot W. Hetzel wrote: > From: "Peter Pentchev" > > From "Scot W. Hetzel" > >> I started porting my ports rc scripts to work on both rcNG and rcOG > systems. > >>In this process I found the ideal solution for the ports rc.d script: > >> > >> 1. define default port variables in the script > >> 2. check for /etc/rc.subr > >> a. if rc.subr exists, use rcNG style > >> b. if rc.subr not exists > >> 1. source /etc/defaults/rc.conf (or /etc/rc.conf) > >> 2. use rcOG style > > > >Actually, this ought to be more like: > >b. if rc.subr does not exist > >1. source /etc/defaults/rc.conf > >2. if the source_rc_confs function exists, execute it > >3. if the source_rc_confs function does not exist, > > try to emulate it by checking for the files listed > > in the rc_conf_files variable and sourcing them if > > they exist. >=20 > This is what I have in the rcOG portion of the script to bring in the > rc.conf settings: >=20 > # Suck in the configuration variables. > if [ -z "${source_rc_confs_defined}" ]; then > if [ -r /etc/defaults/rc.conf ]; then > . /etc/defaults/rc.conf > source_rc_confs > elif [ -r /etc/rc.conf ]; then > . /etc/rc.conf > fi > fi >=20 > Any changes I should make to it? None that I can think of, actually. The only issue that bothers me somewhat is that the above might miss an /etc/rc.conf.local; however, if /etc/defaults/rc.conf does not have source_rc_confs_defined, then we are clearly not on any reasonably recent FreeBSD system, so I don't know whether any assumptions should be made about the existence and relevance of /etc/rc.conf.local. On any reasonably recent FreeBSD system with rcOG, source_rc_confs_defined would be defined, and source_rc_confs() should take care of all the conf files. G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@sbnd.net roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 Thit sentence is not self-referential because "thit" is not a word. --GvXjxJ+pjyke8COw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+rrWY7Ri2jRYZRVMRAklEAKClNzaJN4zk9ayEDzowVvkPolmHfACeOffA BJp8N709VS8lHVTkoku3uQo= =Ro6K -----END PGP SIGNATURE----- --GvXjxJ+pjyke8COw-- From owner-freebsd-arch@FreeBSD.ORG Tue Apr 29 11:04:51 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 35D3E37B405 for ; Tue, 29 Apr 2003 11:04:51 -0700 (PDT) Received: from mail.speakeasy.net (mail14.speakeasy.net [216.254.0.214]) by mx1.FreeBSD.org (Postfix) with ESMTP id 00CA043FBF for ; Tue, 29 Apr 2003 11:04:50 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 11711 invoked from network); 29 Apr 2003 18:04:54 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 29 Apr 2003 18:04:54 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.8/8.12.8) with ESMTP id h3TI4kOv018960; Tue, 29 Apr 2003 14:04:46 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200304290438.h3T4cdHE069528@arch20m.dellroad.org> Date: Tue, 29 Apr 2003 14:04:51 -0400 (EDT) From: John Baldwin To: Archie Cobbs cc: Poul-Henning Kamp cc: gibbs@FreeBSD.ORG cc: freebsd-arch@FreeBSD.ORG Subject: Re: lots of malloc(M_WAITOK)'s in interrupt context from camisr X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2003 18:04:51 -0000 On 29-Apr-2003 Archie Cobbs wrote: > Bruce Evans wrote: >> > I would tend to think that while sleeping in interrupt threads >> > should be avoided, it should only be avoided "at reasonable cost", >> > not "at any cost". >> >> I think it may actually work now in some cases, since there is now an >> ithread context to sleep on, but camisr() in general is not such a > > [ moving this followup to -arch ] > > Random thought.. it's always seemed unnatural to me to say that > interrupt threads can't sleep. > > Why couldn't the system be designed so that if an interrupt thread > tried to sleep, it would actually sleep but atomically (a) detach > itself from the interrupt and (b) spawn a new thread to handle future > interrupts. I.e., sleep with "on demand" additional interrupt thread > creation. > > To avoid reentrancy problems, we would probably also want to block > re-entry into the same interrupt handler function until the original > handler returned. > > If you did this, code wouldn't have to "know" whether it was running > in an interrupt. > > Of course, for efficiency you don't want to do a lot of sleeping > while handling interrupts, but in practice the need to probably only > arises very rarely (e.g., insertion/removal, ifconfig up/down, etc.). If you need to do more work in your interrupt routine than just wakeups and dinking with registers, you can always wake up a software interrupt handler or some other random kthread to do things that take a long amount of time. Sleeping in an interrupt thread would destroy interrupt latency far worse than it is now. I'm sure we can all agree that that would be unacceptable. Rather than making the interrupt thread implementation very complex with magical spawning kthreads and such, I would prefer that driver authors kick up software interrupt threads and the like on their own and keep the ithread implementation simple. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ From owner-freebsd-arch@FreeBSD.ORG Tue Apr 29 12:42:57 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8B96737B401; Tue, 29 Apr 2003 12:42:57 -0700 (PDT) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id B48A843F85; Tue, 29 Apr 2003 12:42:56 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0394.cvx22-bradley.dialup.earthlink.net ([209.179.199.139] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19Ab09-0001SZ-00; Tue, 29 Apr 2003 12:42:54 -0700 Message-ID: <3EAED569.193E333E@mindspring.com> Date: Tue, 29 Apr 2003 12:41:29 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: John Baldwin References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a407e9c346ce08dc94865dbe2ca5b48990350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c cc: Poul-Henning Kamp cc: gibbs@FreeBSD.ORG cc: Archie Cobbs cc: freebsd-arch@FreeBSD.ORG Subject: Re: lots of malloc(M_WAITOK)'s in interrupt context from camisr X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2003 19:42:58 -0000 John Baldwin wrote: > On 29-Apr-2003 Archie Cobbs wrote: > > [ moving this followup to -arch ] > > > > Random thought.. it's always seemed unnatural to me to say that > > interrupt threads can't sleep. > > > > Why couldn't the system be designed so that if an interrupt thread > > tried to sleep, it would actually sleep but atomically (a) detach > > itself from the interrupt and (b) spawn a new thread to handle future > > interrupts. I.e., sleep with "on demand" additional interrupt thread > > creation. [ ... ] > If you need to do more work in your interrupt routine than just wakeups > and dinking with registers, you can always wake up a software interrupt > handler or some other random kthread to do things that take a long amount > of time. Sleeping in an interrupt thread would destroy interrupt latency > far worse than it is now. I'm sure we can all agree that that would be > unacceptable. Rather than making the interrupt thread implementation > very complex with magical spawning kthreads and such, I would prefer that > driver authors kick up software interrupt threads and the like on their > own and keep the ithread implementation simple. Raising a software interrupt to handle the work presents its own set of problems; for example, one of the biggest factors in TCP performance is the latency between the interrupt for the packets, and the running of the NETISR code. There are knobs to get rid of this, but they are not on by default. Adding soft interrupts also presents the possibility that the soft interrupt thread will be scheduled on a CPU other than the one that took the hard interrupt. If this occurs, then every interrupt is going to result in a cache-bust and a TLB hit, so unless you can guarantee affinity between the hard interrupt CPU and the soft interrupt thread, you are pretty screwed. This is currently also a factor in TCP performance on SMP machines, when you are using NETISR, which can effectively cause the mbufs with the data to CPU-hop during protocol processing. IMO, it's much better to run interrupts as far to completion as possible. The Jeff Mogul paper is instructive here (seperating between hard and soft interrupt processing is the main recipe for receiver livelock); so are the Peter Druschel/Mohit Aron/Rice University papers on the SCALA Server Project. I think that to effectively handle, for example, disk interrupts for an NFS server the way you are suggesting would require that a lot of the disk I/O subsystem be changed to support the moral equivalent of the DEVICE_POLLING interface in the network code; that's not really worth it. Better to do the work when the hardware asks you to do it, than to pray for rain. You are still screwed on user space process CPU starvation, no matter what you do, unless you go to something like weighted fair share queueing, and the kernel threads participate in the scheduling process as priority-lending peers for the user space code. That's really complicated to implement, although QLinux seems to have been able to do it with a fairly small team (who are, admittedly, professor-level professional OS researchers). -- Terry From owner-freebsd-arch@FreeBSD.ORG Tue Apr 29 16:00:03 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A37A037B401; Tue, 29 Apr 2003 16:00:03 -0700 (PDT) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8FAE743FDF; Tue, 29 Apr 2003 16:00:02 -0700 (PDT) (envelope-from archie@dellroad.org) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id PAA87985; Tue, 29 Apr 2003 15:54:20 -0700 (PDT) Received: from arch20m.dellroad.org (localhost [127.0.0.1]) by arch20m.dellroad.org (8.12.8/8.12.8) with ESMTP id h3TMsJ2r072779; Tue, 29 Apr 2003 15:54:19 -0700 (PDT) (envelope-from archie@arch20m.dellroad.org) Received: (from archie@localhost) by arch20m.dellroad.org (8.12.8/8.12.8/Submit) id h3TMsJ7F072778; Tue, 29 Apr 2003 15:54:19 -0700 (PDT) From: Archie Cobbs Message-Id: <200304292254.h3TMsJ7F072778@arch20m.dellroad.org> In-Reply-To: To: John Baldwin Date: Tue, 29 Apr 2003 15:54:19 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII cc: Poul-Henning Kamp cc: Archie Cobbs cc: freebsd-arch@FreeBSD.ORG Subject: Re: lots of malloc(M_WAITOK)'s in interrupt context from camisr X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2003 23:00:03 -0000 John Baldwin wrote: > If you need to do more work in your interrupt routine than just wakeups > and dinking with registers, you can always wake up a software interrupt > handler or some other random kthread to do things that take a long amount > of time. Sure you can do that but I'm saying doing that is more complicated than necessary in some situations. > Sleeping in an interrupt thread would destroy interrupt latency > far worse than it is now. I'm sure we can all agree that that would be > unacceptable. I'm only advocating doing it for rare events like device insertion/removal, etc. > Rather than making the interrupt thread implementation > very complex with magical spawning kthreads and such, I would prefer that > driver authors kick up software interrupt threads and the like on their > own and keep the ithread implementation simple. I'd argue that complexity in one place is preferable to complexity in 100 places (ie., every device driver). -Archie __________________________________________________________________________ Archie Cobbs * Precision I/O * http://www.precisionio.com From owner-freebsd-arch@FreeBSD.ORG Tue Apr 29 16:44:33 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 280F037B401; Tue, 29 Apr 2003 16:44:33 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 14AE943F85; Tue, 29 Apr 2003 16:44:32 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost [127.0.0.1]) by harmony.village.org (8.12.8/8.12.3) with ESMTP id h3TNiTA7093598; Tue, 29 Apr 2003 17:44:29 -0600 (MDT) (envelope-from imp@harmony.village.org) Message-Id: <200304292344.h3TNiTA7093598@harmony.village.org> To: Archie Cobbs In-reply-to: Your message of "Tue, 29 Apr 2003 15:54:19 PDT." <200304292254.h3TMsJ7F072778@arch20m.dellroad.org> References: <200304292254.h3TMsJ7F072778@arch20m.dellroad.org> Date: Tue, 29 Apr 2003 17:44:29 -0600 From: Warner Losh cc: Poul-Henning Kamp cc: freebsd-arch@freebsd.org Subject: Re: lots of malloc(M_WAITOK)'s in interrupt context from camisr X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2003 23:44:33 -0000 In message <200304292254.h3TMsJ7F072778@arch20m.dellroad.org> Archie Cobbs writes: : > Sleeping in an interrupt thread would destroy interrupt latency : > far worse than it is now. I'm sure we can all agree that that would be : > unacceptable. : : I'm only advocating doing it for rare events like device : insertion/removal, etc. You shouldn't be doing attach/detach from an interrupt context, but rather from a thread context. Right now there's no locking, so it works, but when locking goes in you might not be able do so. Depends on the choice of lock I have: faster spin locks wouldn't work, but slower mutexes would. Warner From owner-freebsd-arch@FreeBSD.ORG Tue Apr 29 17:12:02 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 48BC537B401; Tue, 29 Apr 2003 17:12:02 -0700 (PDT) Received: from hda.hda.com (host65.hda.com [63.104.68.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id B5EB343F93; Tue, 29 Apr 2003 17:11:59 -0700 (PDT) (envelope-from dufault@hda.com) Received: from hda.com (skinny.hda.com [198.252.184.80]) by hda.hda.com (8.11.6/8.11.6) with ESMTP id h3U0N1w92947; Tue, 29 Apr 2003 20:23:02 -0400 (EDT) (envelope-from dufault@hda.com) Date: Tue, 29 Apr 2003 20:11:56 -0400 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: Archie Cobbs From: Peter Dufault In-Reply-To: <200304292254.h3TMsJ7F072778@arch20m.dellroad.org> Message-Id: <5AC4B3BA-7AA0-11D7-BD29-000393B2C586@hda.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) cc: Poul-Henning Kamp cc: freebsd-arch@freebsd.org Subject: Re: lots of malloc(M_WAITOK)'s in interrupt context from camisr X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2003 00:12:02 -0000 On Tuesday, Apr 29, 2003, at 18:54 US/Eastern, Archie Cobbs wrote: > John Baldwin wrote: >> If you need to do more work in your interrupt routine than just >> wakeups >> and dinking with registers, you can always wake up a software >> interrupt >> handler or some other random kthread to do things that take a long >> amount >> of time. > > Sure you can do that but I'm saying doing that is more complicated > than necessary in some situations. > >> Sleeping in an interrupt thread would destroy interrupt >> latency >> far worse than it is now. I'm sure we can all agree that that would >> be >> unacceptable. > > I'm only advocating doing it for rare events like device > insertion/removal, etc. > >> Rather than making the interrupt thread implementation >> very complex with magical spawning kthreads and such, I would prefer >> that >> driver authors kick up software interrupt threads and the like on >> their >> own and keep the ithread implementation simple. > > I'd argue that complexity in one place is preferable to complexity > in 100 places (ie., every device driver). > The issue is promoting not thinking about what context you're working in. It makes sense to have a clean API for kicking off a worker thread, but "automagic" threads that kick in due to lack of thinking out how things work aren't ready for prime time. To do what you're recommending, use a "Permit me to be naive" flag. That puts the complexity in one place recognizing that it might not be the best place. Peter Peter Dufault (dufault@hda.com) From owner-freebsd-arch@FreeBSD.ORG Tue Apr 29 17:45:13 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E22A37B405; Tue, 29 Apr 2003 17:45:13 -0700 (PDT) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id D734143FA3; Tue, 29 Apr 2003 17:45:05 -0700 (PDT) (envelope-from archie@dellroad.org) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id RAA88556; Tue, 29 Apr 2003 17:38:09 -0700 (PDT) Received: from arch20m.dellroad.org (localhost [127.0.0.1]) by arch20m.dellroad.org (8.12.8/8.12.8) with ESMTP id h3U0c82r073289; Tue, 29 Apr 2003 17:38:08 -0700 (PDT) (envelope-from archie@arch20m.dellroad.org) Received: (from archie@localhost) by arch20m.dellroad.org (8.12.8/8.12.8/Submit) id h3U0c8Hj073288; Tue, 29 Apr 2003 17:38:08 -0700 (PDT) From: Archie Cobbs Message-Id: <200304300038.h3U0c8Hj073288@arch20m.dellroad.org> In-Reply-To: <5AC4B3BA-7AA0-11D7-BD29-000393B2C586@hda.com> To: Peter Dufault Date: Tue, 29 Apr 2003 17:38:08 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII cc: Poul-Henning Kamp cc: Archie Cobbs cc: freebsd-arch@freebsd.org Subject: Re: lots of malloc(M_WAITOK)'s in interrupt context from camisr X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2003 00:45:14 -0000 Peter Dufault wrote: > The issue is promoting not thinking about what context you're working in. > It makes sense to have a clean API for kicking off a worker thread, but > "automagic" threads that kick in due to lack of thinking out how things > work aren't ready for prime time. > > To do what you're recommending, use a "Permit me to be naive" flag. > That puts the complexity in one place recognizing that it might not be > the best place. I agree with that... I'm really trying to make out a more abstract point which is that while in practice interrupt events are "different" from other events that a driver sees because they're more time critical, in the more general view they are just events, just like any other event such as "transmit this packet" or "change media mode" or whatever. The fact that the device originates some event instead of the system/user means that an interrupt is the only mechanism available to deliver the event to the device driver (which can be thought of as a FSM). That doesn't necessarily imply that the event itself is somehow fundamentally different from system- or user-originated events. But the fact that "interrupt handlers can't sleep" means that the device driver writer has to treat them differently. This is of course standard practice and I'm not really arguing we should change it, I'm just pointing out that it's one of those "it's always been that way" things that perhaps causes more pain than necessary, and if looked at from first principles might ultimately not be seen as the most elegant way to do things. It evolved the way it is today not because of elegance, but because device driver writers must follow the kernel device API and kernel writers found it easier prohibit sleeping during interrupts :-) -Archie __________________________________________________________________________ Archie Cobbs * Precision I/O * http://www.precisionio.com From owner-freebsd-arch@FreeBSD.ORG Wed Apr 30 08:11:53 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9750A37B401; Wed, 30 Apr 2003 08:11:53 -0700 (PDT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3BB5E43FA3; Wed, 30 Apr 2003 08:11:52 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.12.9/8.12.9) with ESMTP id h3UFBpMS028342 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 30 Apr 2003 11:11:51 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id h3UFBk885824; Wed, 30 Apr 2003 11:11:46 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16047.59314.532227.475952@grasshopper.cs.duke.edu> Date: Wed, 30 Apr 2003 11:11:46 -0400 (EDT) To: John Baldwin In-Reply-To: References: <200304290438.h3T4cdHE069528@arch20m.dellroad.org> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid cc: freebsd-arch@FreeBSD.ORG Subject: Re: lots of malloc(M_WAITOK)'s in interrupt context from camisr X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2003 15:11:53 -0000 John Baldwin writes: > If you need to do more work in your interrupt routine than just wakeups > and dinking with registers, you can always wake up a software interrupt > handler or some other random kthread to do things that take a long amount Dumb question: Exactly what is one allowed to do in an INTR_FAST interrupt context? Obviously, you can't sleep. But can you call wakeup()? Drew From owner-freebsd-arch@FreeBSD.ORG Wed Apr 30 08:18:33 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D85B537B401; Wed, 30 Apr 2003 08:18:33 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE31743FCB; Wed, 30 Apr 2003 08:18:32 -0700 (PDT) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.9/8.12.9) with ESMTP id h3UFIPNj008765; Wed, 30 Apr 2003 17:18:26 +0200 (CEST) (envelope-from phk@phk.freebsd.dk) To: Andrew Gallatin From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 30 Apr 2003 11:11:46 EDT." <16047.59314.532227.475952@grasshopper.cs.duke.edu> Date: Wed, 30 Apr 2003 17:18:25 +0200 Message-ID: <8764.1051715905@critter.freebsd.dk> cc: freebsd-arch@freebsd.org Subject: Re: lots of malloc(M_WAITOK)'s in interrupt context from camisr X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2003 15:18:34 -0000 In message <16047.59314.532227.475952@grasshopper.cs.duke.edu>, Andrew Gallatin writes: > >John Baldwin writes: > > > If you need to do more work in your interrupt routine than just wakeups > > and dinking with registers, you can always wake up a software interrupt > > handler or some other random kthread to do things that take a long amount > >Dumb question: Exactly what is one allowed to do in an INTR_FAST >interrupt context? Obviously, you can't sleep. But can you call >wakeup()? Calling wakeup() is just about it, but we should actually define it more precisely in a suitable man-page. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Wed Apr 30 08:20:40 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7F75D37B401 for ; Wed, 30 Apr 2003 08:20:40 -0700 (PDT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B97543FBF for ; Wed, 30 Apr 2003 08:20:39 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.12.9/8.12.9) with ESMTP id h3UFKdMS029125 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 30 Apr 2003 11:20:39 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id h3UFKYE85847; Wed, 30 Apr 2003 11:20:34 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16047.59842.60959.352839@grasshopper.cs.duke.edu> Date: Wed, 30 Apr 2003 11:20:34 -0400 (EDT) To: "Poul-Henning Kamp" In-Reply-To: <8764.1051715905@critter.freebsd.dk> References: <16047.59314.532227.475952@grasshopper.cs.duke.edu> <8764.1051715905@critter.freebsd.dk> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid cc: freebsd-arch@freebsd.org Subject: Re: lots of malloc(M_WAITOK)'s in interrupt context from camisr X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2003 15:20:40 -0000 Poul-Henning Kamp writes: > In message <16047.59314.532227.475952@grasshopper.cs.duke.edu>, Andrew Gallatin > writes: > > > >John Baldwin writes: > > > > > If you need to do more work in your interrupt routine than just wakeups > > > and dinking with registers, you can always wake up a software interrupt > > > handler or some other random kthread to do things that take a long amount > > > >Dumb question: Exactly what is one allowed to do in an INTR_FAST > >interrupt context? Obviously, you can't sleep. But can you call > >wakeup()? > > Calling wakeup() is just about it, but we should actually define it > more precisely in a suitable man-page. That would be cool. Since wakeup() uses a spinlock, I assume that spinlocks are generally OK too.. Drew From owner-freebsd-arch@FreeBSD.ORG Wed Apr 30 08:40:39 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AFF1A37B401 for ; Wed, 30 Apr 2003 08:40:39 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id BDB5943F85 for ; Wed, 30 Apr 2003 08:40:38 -0700 (PDT) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.9/8.12.9) with ESMTP id h3UFeaNj012433; Wed, 30 Apr 2003 17:40:36 +0200 (CEST) (envelope-from phk@phk.freebsd.dk) To: Andrew Gallatin From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 30 Apr 2003 11:20:34 EDT." <16047.59842.60959.352839@grasshopper.cs.duke.edu> Date: Wed, 30 Apr 2003 17:40:36 +0200 Message-ID: <12432.1051717236@critter.freebsd.dk> cc: freebsd-arch@freebsd.org Subject: Re: lots of malloc(M_WAITOK)'s in interrupt context from camisr X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2003 15:40:40 -0000 In message <16047.59842.60959.352839@grasshopper.cs.duke.edu>, Andrew Gallatin writes: > >Poul-Henning Kamp writes: > > In message <16047.59314.532227.475952@grasshopper.cs.duke.edu>, Andrew Gallatin > > writes: > > > > > >John Baldwin writes: > > > > > > > If you need to do more work in your interrupt routine than just wakeups > > > > and dinking with registers, you can always wake up a software interrupt > > > > handler or some other random kthread to do things that take a long amount > > > > > >Dumb question: Exactly what is one allowed to do in an INTR_FAST > > >interrupt context? Obviously, you can't sleep. But can you call > > >wakeup()? > > > > Calling wakeup() is just about it, but we should actually define it > > more precisely in a suitable man-page. > >That would be cool. Since wakeup() uses a spinlock, I assume that >spinlocks are generally OK too.. I'm not sure you should infer too much yet... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Wed Apr 30 08:52:26 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DFA8537B401 for ; Wed, 30 Apr 2003 08:52:26 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 00B6143F93 for ; Wed, 30 Apr 2003 08:52:26 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.8/8.12.3) with ESMTP id h3UFqKA7098112; Wed, 30 Apr 2003 09:52:20 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 30 Apr 2003 09:52:15 -0600 (MDT) Message-Id: <20030430.095215.48529965.imp@bsdimp.com> To: phk@phk.freebsd.dk From: "M. Warner Losh" In-Reply-To: <12432.1051717236@critter.freebsd.dk> References: <16047.59842.60959.352839@grasshopper.cs.duke.edu> <12432.1051717236@critter.freebsd.dk> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: gallatin@cs.duke.edu cc: freebsd-arch@freebsd.org Subject: Re: lots of malloc(M_WAITOK)'s in interrupt context from camisr X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2003 15:52:27 -0000 In message: <12432.1051717236@critter.freebsd.dk> "Poul-Henning Kamp" writes: : In message <16047.59842.60959.352839@grasshopper.cs.duke.edu>, Andrew Gallatin : writes: : > : >Poul-Henning Kamp writes: : > > In message <16047.59314.532227.475952@grasshopper.cs.duke.edu>, Andrew Gallatin : > > writes: : > > > : > > >John Baldwin writes: : > > > : > > > > If you need to do more work in your interrupt routine than just wakeups : > > > > and dinking with registers, you can always wake up a software interrupt : > > > > handler or some other random kthread to do things that take a long amount : > > > : > > >Dumb question: Exactly what is one allowed to do in an INTR_FAST : > > >interrupt context? Obviously, you can't sleep. But can you call : > > >wakeup()? : > > : > > Calling wakeup() is just about it, but we should actually define it : > > more precisely in a suitable man-page. : > : >That would be cool. Since wakeup() uses a spinlock, I assume that : >spinlocks are generally OK too.. : : I'm not sure you should infer too much yet... Yes. A spinlock in the context of wakeup being safe might be radically different than spinlocks generally being safe. I'm not sure that wakeup is safe in a fast interrupt context even. I've always had to create a soft interrupt and call the sched routine to get it to run. We definitely need to document what's allowed in a fast interrupt handler. Generally as little as possible to placate the hardware and the 'expensive' parts of the driver should be in a soft interrupt thread. Warner From owner-freebsd-arch@FreeBSD.ORG Wed Apr 30 09:41:41 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A14C237B404; Wed, 30 Apr 2003 09:41:41 -0700 (PDT) Received: from gw.nectar.cc (gw.nectar.cc [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id B1D5543FB1; Wed, 30 Apr 2003 09:41:37 -0700 (PDT) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.nectar.cc (Postfix) with ESMTP id 034694; Wed, 30 Apr 2003 11:41:37 -0500 (CDT) Received: by madman.celabo.org (Postfix, from userid 1001) id 18EBC78C4A; Wed, 30 Apr 2003 11:41:36 -0500 (CDT) Date: Wed, 30 Apr 2003 11:41:35 -0500 From: "Jacques A. Vidrine" To: Paul Richards , "W. Josephson" Message-ID: <20030430164135.GB26508@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , Paul Richards , "W. Josephson" , freebsd-arch@FreeBSD.org References: <20030430004907.GA32349@mero.morphisms.net> <20030430031856.GA20258@madman.celabo.org> <20030430144149.GA7786@dragon.nuxi.com> <20030430002014.GA1190@dragon.nuxi.com> <20030430043303.GA46365@mero.morphisms.net> <20030430062647.GA82023@rot13.obsecurity.org> <20030430143121.GK39658@survey.codeburst.net> <20030430152708.GA26216@madman.celabo.org> <20030430153645.GL39658@survey.codeburst.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030430154936.GA58835@mero.morphisms.net> <20030430153645.GL39658@survey.codeburst.net> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.3i-ja.1 cc: freebsd-arch@FreeBSD.org Subject: `Hiding' libc symbols (was Re: cvs commit: src/lib/libc/gen ...) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2003 16:41:42 -0000 [Trimmed cc:list; moving to freebsd-arch] First, has something been broken by making strlcpy/strlcat into a weak reference? Second, for the sake of discussion only, let us assume that (a) we like users, and we want users to use FreeBSD; and (b) we like developers, and we want developers to write software on FreeBSD. Then, let's consider an exercise. Take two software packages: Package X defines a function named `strlcpy', that works well for Package X and may or may not have any relationship to the `strlcpy' we all know and love from OpenBSD. Package Y utilizes strlcpy. It does not define it, but makes the fairly reasonable assumption that the platform provides a working strlcpy with the (now) well-known semantics from OpenBSD. Which of the following scenarios is the least astonishing? Scenario 1. Package X builds and runs, but blows up in certain libc functions. Package Y builds and runs correctly. Scenario 2. Package X builds and runs correctly. Package Y builds, but only if you link it with the rather non-standard `libkitchen_sink'. The image of Package Y is also bigger than on other platforms, because it has two implementations of strlcpy (the one used internally in libc, and the one from libkitchen_sink). Scenario 3. Package X and Package Y both build and run correctly. Guess which scenario applied before my commit to make strlcpy/strlcat weak references? which applies now? which would apply if we broke strlcpy/strlcat into another library? For bonus points, extend the example with Package Z, which uses `strlcpy' but only defines it if it doesn't detect it as implemented on the platform. Maybe multiply the instances of applications such as Package X, Y, and Z by 8000 or so --- how does that affect the issue? Third, specific comments below if you are not bored yet. On Wed, Apr 30, 2003 at 04:36:45PM +0100, Paul Richards wrote: > On Wed, Apr 30, 2003 at 10:27:08AM -0500, Jacques A. Vidrine wrote: > > > > We have no business exporting symbols from libc that are not described > > by any standard. We have no business assuming that if an application > > defines a function called `strlcpy' that it resembles, in intent or in > > actual implementation, our own strlcpy. > > That's an orthogonal issue really, since libc is not a "pure" > implementation of the standard C library, it also includes a number of > extensions that have been bundled into our libc because it's sometimes > a convenient dumping ground. I don't see how you can call that `orthogonal'... that is the root of the issue we are discussing. > Hiding functions that aren't meant to be exported would make sense, > but hiding functions that are intended to be exported but aren't > part of the standard is not so useful. How is it not useful? It is useful for qpopper. It is useful for isc-dhcp. > strlcpy is part of the "FreeBSD libc" since it's a documented interface > for application writers to use. Oh, of course. I forgot that we only support applications written for FreeBSD. I thought we should be a decent platform for ISO C and POSIX applications as well, but that is clearly foolishness. > The alternative is to split out these functions and keep libc pure, and > then link them into our applications if we use them. This is an approach > other platforms have taken but one we've not gone down because of the > proliferation of libraries that then have to be included when writing > apps. What are these other platforms? Could you elaborate on what exactly they are doing that you think we should emulate? There are platforms with `strlcpy' in the base system, but not in libc? There are platforms that have _no_ functions in libc that are not in ISO C? in POSIX? If we were to decide to make such a split, what functions would be OK for libc? Which standard will we take as authoritative? Only ISO C functions? Only POSIX functions? Which options in POSIX? etc On Wed, Apr 30, 2003 at 11:49:36AM -0400, W. Josephson wrote: > On Wed, Apr 30, 2003 at 10:27:08AM -0500, Jacques A. Vidrine wrote: > > We have no business exporting symbols from libc that are not described > > by any standard. We have no business assuming that if an application > > defines a function called `strlcpy' that it resembles, in intent or in > > actual implementation, our own strlcpy. > > Then we should not export functions used internally that aren't > a part of the standards at all and put functions such as strlcpy > that are explicitly exported by design in a different library, no? No, I don't think so. 1) We break the build of many applications if we move commonly- used interface into some new library. 2) We add an annoying difference with other platforms that also implement these commonly-used interfaces. 3) We add code bloat. These commonly-used interfaces are used within libc and within applications. If we split them out into separate libraries, then applications will carry around twice the code. > > return value from our strlcpy. Is it a bug in that application if it > > cannot use parts of libc because of this? No. It is a bug in our > > libc. > > I think this is a separate issue from what gave rise to the > discussion. What is a separate issue? This is _the_ issue. > I still believe it is a mistake to play games with > symbols explicitly exported by libc. Either the symbols should be > exported normally or they shouldn't be exported at all: Think through the consequences of this. e.g. If we did not export `warn' using a weak reference, then dhclient could not be compiled statically on FreeBSD. If we did not export `warn' at all, then we would need to put `warn' in a separate library and break lots of code. > keeping track > of which platform does what with which functions, be they standard > functions or common extensions, just makes life harder for everyone as > far as I can tell. But that is what it sounds like you are suggesting. ``Oh, I forgot, to use strlcpy on FreeBSD, I must add `-lfreebsd', how lame.'' Cheers, -- Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal nectar@celabo.org . jvidrine@verio.net . nectar@freebsd.org . nectar@kth.se From owner-freebsd-arch@FreeBSD.ORG Wed Apr 30 09:46:55 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D5BB437B401; Wed, 30 Apr 2003 09:46:55 -0700 (PDT) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7341943FBD; Wed, 30 Apr 2003 09:46:54 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id h3UGknVo051076 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 Apr 2003 12:46:50 -0400 (EDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.9/8.12.9/Submit) id h3UGklUx051071; Wed, 30 Apr 2003 12:46:47 -0400 (EDT) (envelope-from wollman) Date: Wed, 30 Apr 2003 12:46:47 -0400 (EDT) From: Garrett Wollman Message-Id: <200304301646.h3UGklUx051071@khavrinen.lcs.mit.edu> To: "Jacques A. Vidrine" In-Reply-To: <20030430164135.GB26508@madman.celabo.org> References: <20030430004907.GA32349@mero.morphisms.net> <20030430031856.GA20258@madman.celabo.org> <20030430144149.GA7786@dragon.nuxi.com> <20030430002014.GA1190@dragon.nuxi.com> <20030430043303.GA46365@mero.morphisms.net> <20030430062647.GA82023@rot13.obsecurity.org> <20030430143121.GK39658@survey.codeburst.net> <20030430152708.GA26216@madman.celabo.org> <20030430153645.GL39658@survey.codeburst.net> <20030430154936.GA58835@mero.morphisms.net> <20030430164135.GB26508@madman.celabo.org> X-Spam-Score: -19.8 () IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES X-Scanned-By: MIMEDefang 2.33 (www . roaringpenguin . com / mimedefang) cc: freebsd-arch@FreeBSD.org Subject: `Hiding' libc symbols (was Re: cvs commit: src/lib/libc/gen ...) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2003 16:46:56 -0000 < said: > Package X defines a function named `strlcpy', that works well for > Package X and may or may not have any relationship to the `strlcpy' > we all know and love from OpenBSD. > Which of the following scenarios is the least astonishing? Secnario 4. Package X fails to build with a linker error because the user has attempted to define something that he is not entitled to redefine. (No, I don't know how to accomplish this with our existing toolchain.) -GAWollman From owner-freebsd-arch@FreeBSD.ORG Wed Apr 30 10:57:08 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8186137B401 for ; Wed, 30 Apr 2003 10:57:08 -0700 (PDT) Received: from mail.speakeasy.net (mail14.speakeasy.net [216.254.0.214]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA06443FA3 for ; Wed, 30 Apr 2003 10:57:05 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 23660 invoked from network); 30 Apr 2003 17:52:39 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 30 Apr 2003 17:52:39 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.8/8.12.8) with ESMTP id h3UHqTOv022272; Wed, 30 Apr 2003 13:52:30 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <16047.59314.532227.475952@grasshopper.cs.duke.edu> Date: Wed, 30 Apr 2003 13:52:35 -0400 (EDT) From: John Baldwin To: Andrew Gallatin cc: freebsd-arch@FreeBSD.ORG Subject: Re: lots of malloc(M_WAITOK)'s in interrupt context from camisr X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2003 17:57:08 -0000 On 30-Apr-2003 Andrew Gallatin wrote: > > John Baldwin writes: > > > If you need to do more work in your interrupt routine than just wakeups > > and dinking with registers, you can always wake up a software interrupt > > handler or some other random kthread to do things that take a long amount > > Dumb question: Exactly what is one allowed to do in an INTR_FAST > interrupt context? Obviously, you can't sleep. But can you call > wakeup()? You can call wakeup() so long as you ensure that it won't be missed. Since you can only call msleep() with a sleep mutex, then you would normally need a sleep mutex (which you can't grab in a fast handler) to hold across the call to wakeup() to avoid missing the wakeup(). Since you can't do that, you could have your msleep() use a timeout value, in which case missing a wakeup isn't fatal. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ From owner-freebsd-arch@FreeBSD.ORG Wed Apr 30 11:04:47 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1058137B401; Wed, 30 Apr 2003 11:04:47 -0700 (PDT) Received: from segfault.kiev.ua (segfault.kiev.ua [193.193.193.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 78EB743F93; Wed, 30 Apr 2003 11:04:43 -0700 (PDT) (envelope-from netch@iv.nn.kiev.ua) Received: (from uucp@localhost) by segfault.kiev.ua (8) with UUCP id h4UI4Ulu001958; Wed, 30 Apr 2003 21:04:30 +0300 (EEST) (envelope-from netch@iv.nn.kiev.ua) Received: (from netch@localhost) by iv.nn.kiev.ua (8.12.8p1/8.12.8) id h3UI39b5006835; Wed, 30 Apr 2003 21:03:09 +0300 (EEST) (envelope-from netch) Date: Wed, 30 Apr 2003 21:03:09 +0300 From: Valentin Nechayev To: "Jacques A. Vidrine" , Paul Richards , "W. Josephson" , freebsd-arch@FreeBSD.org Message-ID: <20030430180309.GB312@iv.nn.kiev.ua> References: <20030430031856.GA20258@madman.celabo.org> <20030430144149.GA7786@dragon.nuxi.com> <20030430002014.GA1190@dragon.nuxi.com> <20030430043303.GA46365@mero.morphisms.net> <20030430062647.GA82023@rot13.obsecurity.org> <20030430143121.GK39658@survey.codeburst.net> <20030430152708.GA26216@madman.celabo.org> <20030430153645.GL39658@survey.codeburst.net> <20030430164135.GB26508@madman.celabo.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030430164135.GB26508@madman.celabo.org> X-42: On Organization: Dark side of coredump Subject: Re: `Hiding' libc symbols (was Re: cvs commit: src/lib/libc/gen ...) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2003 18:04:47 -0000 Wed, Apr 30, 2003 at 11:41:35, nectar (Jacques A. Vidrine) wrote about "`Hiding' libc symbols (was Re: cvs commit: src/lib/libc/gen ...)": JAV> Package X defines a function named `strlcpy', that works well for JAV> Package X and may or may not have any relationship to the `strlcpy' JAV> we all know and love from OpenBSD. As already said in discussion in cvs-all@, this is why ports infrastructure exists and has such features as now. You can't do full redesign of the whole FreeBSD for any new application which potentially can run on it but has its own and highly specific insects inside. If application is inconsistent, as qpopper in this example, with current libc, it's better to add something similar to `#define strlcpy qp_strlcpy' to its headers, instead of making changes in libc. If there are a few hundreds of such ports, your approach can be reasonable; but I can't see any reason making things such way for the only one program, and bad program (qpopper's history has too many exploits and its coding style is as ugly as seven sins together). Adding one patch to port is better. Moreover, due to extremal uglyness of qpopper, I think it anyway requires more steps (as static linking with libparanoia, for instance). JAV> Guess which scenario applied before my commit to make strlcpy/strlcat JAV> weak references? which applies now? which would apply if we broke JAV> strlcpy/strlcat into another library? Is strlcpy defined with different interface and/or semantics in any standard, including written, as Single Unix Spec, or real, as local tradition or GNU software? I don't know such issues. JAV> JAV> Oh, of course. I forgot that we only support applications written for JAV> FreeBSD. I thought we should be a decent platform for ISO C and POSIX JAV> applications as well, but that is clearly foolishness. JAV> ISO C and Posix doesn't know strlcpy(). ISO C defines, AFAIR, that all function names matching /^str/ are reserved for future implementations, but it's unreal to forecast seeing another strlcpy() in it. -netch- From owner-freebsd-arch@FreeBSD.ORG Wed Apr 30 14:39:28 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1FDDC37B401; Wed, 30 Apr 2003 14:39:28 -0700 (PDT) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2FEAC43FA3; Wed, 30 Apr 2003 14:39:25 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0402.cvx21-bradley.dialup.earthlink.net ([209.179.193.147] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19AzIQ-0001Ln-00; Wed, 30 Apr 2003 14:39:23 -0700 Message-ID: <3EB04214.BD79BC80@mindspring.com> Date: Wed, 30 Apr 2003 14:37:24 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Garrett Wollman References: <20030430004907.GA32349@mero.morphisms.net> <20030430031856.GA20258@madman.celabo.org> <20030430144149.GA7786@dragon.nuxi.com> <20030430002014.GA1190@dragon.nuxi.com> <20030430043303.GA46365@mero.morphisms.net> <20030430062647.GA82023@rot13.obsecurity.org> <20030430143121.GK39658@survey.codeburst.net> <20030430152708.GA26216@madman.celabo.org> <20030430153645.GL39658@survey.codeburst.net> <20030430154936.GA58835@mero.morphisms.net> <200304301646.h3UGklUx051071@khavrinen.lcs.mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a488f810de9945843c7558d45e8c6066bd350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c cc: "Jacques A. Vidrine" cc: freebsd-arch@FreeBSD.org Subject: Re: `Hiding' libc symbols (was Re: cvs commit: src/lib/libc/gen ...) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2003 21:39:28 -0000 Garrett Wollman wrote: > < said: > > Package X defines a function named `strlcpy', that works well for > > Package X and may or may not have any relationship to the `strlcpy' > > we all know and love from OpenBSD. > > > Which of the following scenarios is the least astonishing? > > Secnario 4. Package X fails to build with a linker error because the > user has attempted to define something that he is not entitled to > redefine. (No, I don't know how to accomplish this with our existing > toolchain.) There is an expectation by users of being able to replace libc functions with instrumented versions. If they replace them with buggy versions, as well, they have to expect that their code will end up being buggy. As far as internal use of libc functions by libc functions, it's problematic: for example, if someone implemented their own heap managing malloc library that called things like sbrk directly, then overriding their choice of function could have consequences. Likewise, a profiling library that wrapped entry an exit into C library functions would get false readings for the functions. That said, for dynamically linked objects, there is support for a special "handle" value of RTLD_NEXT when calling dlsym(), according to POSIX/SUS2. FreeBSD supposedly supports this, and it could be used to navigate the object tree to get the "right" symbol. Also, for libc functions without side effects, the caller could directly reference the strong symbol version, if it believed it to be necessary, and was willing to have profiling time accounded against it instead of against the function it was calling (thus artificailly inflating the expense). Personally, I feel that the ability to override library functions is more important than the ability to link buggy code and have it function anyway, so I'd leave things alone. 8-). -- Terry From owner-freebsd-arch@FreeBSD.ORG Wed Apr 30 18:16:09 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F52A37B401 for ; Wed, 30 Apr 2003 18:16:09 -0700 (PDT) Received: from gw.nectar.cc (gw.nectar.cc [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B08243F93 for ; Wed, 30 Apr 2003 18:16:08 -0700 (PDT) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.nectar.cc (Postfix) with ESMTP id D7C434; Wed, 30 Apr 2003 20:16:07 -0500 (CDT) Received: by madman.celabo.org (Postfix, from userid 1001) id 323E378C4A; Wed, 30 Apr 2003 20:16:07 -0500 (CDT) Date: Wed, 30 Apr 2003 20:16:07 -0500 From: "Jacques A. Vidrine" To: "W. Josephson" Message-ID: <20030501011607.GK30097@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , "W. Josephson" , Paul Richards , freebsd-arch@FreeBSD.org References: <20030430144149.GA7786@dragon.nuxi.com> <20030430002014.GA1190@dragon.nuxi.com> <20030430043303.GA46365@mero.morphisms.net> <20030430062647.GA82023@rot13.obsecurity.org> <20030430143121.GK39658@survey.codeburst.net> <20030430152708.GA26216@madman.celabo.org> <20030430153645.GL39658@survey.codeburst.net> <20030430164135.GB26508@madman.celabo.org> <20030430165422.GA62396@mero.morphisms.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030430165422.GA62396@mero.morphisms.net> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.3i-ja.1 cc: freebsd-arch@FreeBSD.org Subject: Re: `Hiding' libc symbols (was Re: cvs commit: src/lib/libc/gen ...) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2003 01:16:09 -0000 On Wed, Apr 30, 2003 at 12:54:22PM -0400, W. Josephson wrote: > It is, in fact, much better than having to litter the > code with underscores and guessing which ones have been forgotten > or added this time around. I don't like the underscores either. But they are just a symptom of the method we are using to hide symbols, and it is one reason why we haven't hidden many of them already. When someone cares enough to come up with a better solution, it will then no longer be an issue. > At least that has been my experience > when trying to maintain portable software that must compile on a > wide variety of Unix clones and Windows. You don't have to add any underscores in your application code. Cheers, -- Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal nectar@celabo.org . jvidrine@verio.net . nectar@freebsd.org . nectar@kth.se From owner-freebsd-arch@FreeBSD.ORG Wed Apr 30 23:31:21 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6938837B401; Wed, 30 Apr 2003 23:31:21 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id ACC9E43FB1; Wed, 30 Apr 2003 23:31:19 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id QAA22993; Thu, 1 May 2003 16:31:09 +1000 Date: Thu, 1 May 2003 16:31:08 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Andrew Gallatin In-Reply-To: <16047.59314.532227.475952@grasshopper.cs.duke.edu> Message-ID: <20030501144708.I18220@gamplex.bde.org> References: <200304290438.h3T4cdHE069528@arch20m.dellroad.org> <16047.59314.532227.475952@grasshopper.cs.duke.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-arch@freebsd.org Subject: Re: lots of malloc(M_WAITOK)'s in interrupt context from camisr X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2003 06:31:21 -0000 On Wed, 30 Apr 2003, Andrew Gallatin wrote: > John Baldwin writes: > > > If you need to do more work in your interrupt routine than just wakeups > > and dinking with registers, you can always wake up a software interrupt > > handler or some other random kthread to do things that take a long amount (This is about normal interrupt handlers, not INTR_FAST ones.) > Dumb question: Exactly what is one allowed to do in an INTR_FAST > interrupt context? Obviously, you can't sleep. But can you call > wakeup()? You may access driver memory and device i/o space that you have suitably locked. That's all. You may not call any functions that may access other memory (other than the stack) or that may do unsuitable locking. In practice, this means that you should only call bus-space i/o functions and lower-level i/o functions (only after locking i/o accesses of course). The locking is too difficult or expensive to call more. Suitable locking methods include: (1) h/w disabling of interrupts for the !SMP case. (2) simple spinlocks for the SMP case. These must be combined with h/w disabling of interrupts to avoid deadlock if the lock contention occurs on the same CPU. Examples of this may be found in the sio driver in RELENG_4. The only known problems with this are that the lock is too gigantic, yet is not gigantic enough to give unbroken locking for the rule-breaking calls to the non-i/o functions pps_event() and microtime(). Unsuitable locking methods include: (1) Everything in the mtx family. These are used in -current, but that is a bug in -current. They are basically higher level functions. Using them at the lowest (INTR_FAST) level adds complications and overheads to both this level and higher levels. In practice, mtx spinlocks are not very different from the simple spinlocks used in RELENG_4. They just have extra complications and overheads to make them more general and then to reduce them back to simple spinlocks when they are used in INTR_FAST handlers. (2) Using locks for non-driver/non-device memory. These (notably sched_lock) are used in -current, but that is a bug in -current. It is much larger than the bug in (1). It makes all INTR_FAST handlers non-fast at least in the !SMP case, since they may be blocked by other INTR_FAST handlers that are blocked by the general locks even though they don't all have this bug. E.g., exit() holds sched_lock for a long time; clock interrupt handlers are blocked by sched_lock and (in the !SMP case) block all other INTR_FAST handlers while they are blocked; thus exit() may block all INTR_FAST handlers for a long time. In RELENG_4, exit() doesn't block fast interrupt handlers at all. wakeup() is one layer away from being callable, unless the bugs in -current permit it. Bruce From owner-freebsd-arch@FreeBSD.ORG Thu May 1 00:42:46 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF8AE37B405 for ; Thu, 1 May 2003 00:42:46 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2127643FA3 for ; Thu, 1 May 2003 00:42:45 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id RAA32516; Thu, 1 May 2003 17:41:55 +1000 Date: Thu, 1 May 2003 17:41:54 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: "M. Warner Losh" In-Reply-To: <20030430.095215.48529965.imp@bsdimp.com> Message-ID: <20030501164354.S18480@gamplex.bde.org> References: <16047.59842.60959.352839@grasshopper.cs.duke.edu> <20030430.095215.48529965.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: phk@phk.freebsd.dk cc: gallatin@cs.duke.edu cc: freebsd-arch@freebsd.org Subject: Re: lots of malloc(M_WAITOK)'s in interrupt context from camisr X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2003 07:42:47 -0000 On Wed, 30 Apr 2003, M. Warner Losh wrote: > In message: <12432.1051717236@critter.freebsd.dk> > "Poul-Henning Kamp" writes: > : In message <16047.59842.60959.352839@grasshopper.cs.duke.edu>, Andrew Gallatin > : writes: > : > > : >Poul-Henning Kamp writes: > : > > In message <16047.59314.532227.475952@grasshopper.cs.duke.edu>, Andrew Gallatin > : > > writes: > : > > >Dumb question: Exactly what is one allowed to do in an INTR_FAST > : > > >interrupt context? Obviously, you can't sleep. But can you call > : > > >wakeup()? > : > > > : > > Calling wakeup() is just about it, but we should actually define it > : > > more precisely in a suitable man-page. I would have thought that it was obviously unsafe. It is like signal handling, but more so (the restrictions for signal handlers are more like those for ordinary interrupt handlers). Only a very limited set of functions may be called from signal handlers, and putting the list in a man page does very little to prevent ones not in the list being called. No INTR_FAST handlers in -current except loran and adlink seem to actually call wakeup(), but these drivers are just bad examples. The don't even use mutexes. > : >That would be cool. Since wakeup() uses a spinlock, I assume that > : >spinlocks are generally OK too.. > : > : I'm not sure you should infer too much yet... > > Yes. A spinlock in the context of wakeup being safe might be > radically different than spinlocks generally being safe. > > I'm not sure that wakeup is safe in a fast interrupt context even. > I've always had to create a soft interrupt and call the sched routine > to get it to run. The situation in -current seems to be similar to the one for the one for malloc() that started this thread(). Calling wakeup() from your INTR_FAST handler may be safe enough for you, since wakeup() spins on sched_lock as necessary and your driver may not care about this (though it shouldn't use a INTR_FAST handler if it doesn't care about efficiency. However, this increases latency and may affect overheads (+-) for other parts of the system. E.g., in the !SMP case, wakeup() won't spin on sched_lock, since sched_lock cannot be held at that point else we would have deadlock, so the direct cost is tiny. The cost is indirect: to prevent sched_lock being held, holding sched_lock (actually any spinlock) must block INTR_FAST interrupts. > We definitely need to document what's allowed in a fast interrupt > handler. Generally as little as possible to placate the hardware and > the 'expensive' parts of the driver should be in a soft interrupt > thread. Or just in an ordinary interrupt thread. Bruce From owner-freebsd-arch@FreeBSD.ORG Thu May 1 07:02:58 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 28EC637B401; Thu, 1 May 2003 07:02:58 -0700 (PDT) Received: from mx0.freebsd-services.com (survey.codeburst.net [195.149.39.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1756B43FA3; Thu, 1 May 2003 07:02:57 -0700 (PDT) (envelope-from paul@freebsd-services.com) Received: by mx0.freebsd-services.com (Postfix, from userid 1002) id E9F481B214; Thu, 1 May 2003 15:02:55 +0100 (BST) Date: Thu, 1 May 2003 15:02:55 +0100 From: Paul Richards To: "Jacques A. Vidrine" Message-ID: <20030501140255.GB1869@survey.codeburst.net> References: <20030430031856.GA20258@madman.celabo.org> <20030430144149.GA7786@dragon.nuxi.com> <20030430002014.GA1190@dragon.nuxi.com> <20030430043303.GA46365@mero.morphisms.net> <20030430062647.GA82023@rot13.obsecurity.org> <20030430143121.GK39658@survey.codeburst.net> <20030430152708.GA26216@madman.celabo.org> <20030430153645.GL39658@survey.codeburst.net> <20030430164135.GB26508@madman.celabo.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030430164135.GB26508@madman.celabo.org> User-Agent: Mutt/1.4.1i cc: "W. Josephson" cc: freebsd-arch@FreeBSD.org Subject: Re: `Hiding' libc symbols (was Re: cvs commit: src/lib/libc/gen ...) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2003 14:02:58 -0000 On Wed, Apr 30, 2003 at 11:41:35AM -0500, Jacques A. Vidrine wrote: > [Trimmed cc:list; moving to freebsd-arch] > > > First, has something been broken by making strlcpy/strlcat into a weak > reference? Yes, deliberately overloading it from an application now no longer works. What really concerns me though, is that behaviour is only defined for 2 functions. I think this should be backed out, as most people in this thread have pointed out, you've added a quirk to our C library to fix a poorly coded application and whichever way you look at it, that's not the right solution. The implementation of FreeBSD should be what's correct, we shouldn't fudge things to accomodate bad packages, fix the problem where the problem really exists. -- Paul Richards From owner-freebsd-arch@FreeBSD.ORG Thu May 1 07:30:35 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 89EA537B404 for ; Thu, 1 May 2003 07:30:35 -0700 (PDT) Received: from gw.nectar.cc (gw.nectar.cc [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0945D43F85 for ; Thu, 1 May 2003 07:30:34 -0700 (PDT) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.nectar.cc (Postfix) with ESMTP id 791C8A3; Thu, 1 May 2003 09:30:33 -0500 (CDT) Received: by madman.celabo.org (Postfix, from userid 1001) id C8AC078C4A; Thu, 1 May 2003 09:30:32 -0500 (CDT) Date: Thu, 1 May 2003 09:30:32 -0500 From: "Jacques A. Vidrine" To: Paul Richards Message-ID: <20030501143032.GA34163@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , Paul Richards , freebsd-arch@FreeBSD.org References: <20030430144149.GA7786@dragon.nuxi.com> <20030430002014.GA1190@dragon.nuxi.com> <20030430043303.GA46365@mero.morphisms.net> <20030430062647.GA82023@rot13.obsecurity.org> <20030430143121.GK39658@survey.codeburst.net> <20030430152708.GA26216@madman.celabo.org> <20030430153645.GL39658@survey.codeburst.net> <20030430164135.GB26508@madman.celabo.org> <20030501140255.GB1869@survey.codeburst.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030501140255.GB1869@survey.codeburst.net> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.3i-ja.1 cc: freebsd-arch@FreeBSD.org Subject: Re: `Hiding' libc symbols (was Re: cvs commit: src/lib/libc/gen ...) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2003 14:30:35 -0000 On Thu, May 01, 2003 at 03:02:55PM +0100, Paul Richards wrote: > On Wed, Apr 30, 2003 at 11:41:35AM -0500, Jacques A. Vidrine wrote: > > [Trimmed cc:list; moving to freebsd-arch] > > > > > > First, has something been broken by making strlcpy/strlcat into a weak > > reference? > > Yes, deliberately overloading it from an application now no longer > works. Give me a break. Good, it should not work by accident. An application might define strlcpy for its own use, but we should NEVER use the application's strlcpy. [1] > What really concerns me though, is that behaviour is only defined > for 2 functions. No, it is done for some 150+ functions. If the technique didn't have a certain distasteful side-effect when used en masse, I would push for covering almost all of the other symbols libc exports. (If an application defines `strcpy', should we use that from within libc?) But until a better technique arrives, I am happy to apply it a little less liberally. There are some specialized instances where it _does_ make sense to override a function that libc utilizes. malloc and free are one example. The socket-related functions might be another (for SOCKS implementations). The fact that we've `hidden' connect(2) et al using this same technique for over two years without much impact on the functioning of such applications is a pretty good indicator to me that concerns in this area are unfounded. > I think this should be backed out, as most people in this thread > have pointed out, you've added a quirk to our C library to fix a > poorly coded application and whichever way you look at it, that's > not the right solution. > > The implementation of FreeBSD should be what's correct, we shouldn't > fudge things to accomodate bad packages, fix the problem where the > problem really exists. Obviously, I don't see it the same way you do. Calling the application's strlcpy in order to implement some internal libc function is not ``what's correct'', regardless of whether the application is buggy or perfect. Cheers, -- Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal nectar@celabo.org . jvidrine@verio.net . nectar@freebsd.org . nectar@kth.se [1] I know. Never say never. From owner-freebsd-arch@FreeBSD.ORG Thu May 1 07:46:02 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B501737B401; Thu, 1 May 2003 07:46:02 -0700 (PDT) Received: from mx0.freebsd-services.com (survey.codeburst.net [195.149.39.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA63643F3F; Thu, 1 May 2003 07:46:01 -0700 (PDT) (envelope-from paul@freebsd-services.com) Received: by mx0.freebsd-services.com (Postfix, from userid 1002) id B72A51B214; Thu, 1 May 2003 15:46:00 +0100 (BST) Date: Thu, 1 May 2003 15:46:00 +0100 From: Paul Richards To: "Jacques A. Vidrine" , freebsd-arch@FreeBSD.org Message-ID: <20030501144600.GC1869@survey.codeburst.net> References: <20030430002014.GA1190@dragon.nuxi.com> <20030430043303.GA46365@mero.morphisms.net> <20030430062647.GA82023@rot13.obsecurity.org> <20030430143121.GK39658@survey.codeburst.net> <20030430152708.GA26216@madman.celabo.org> <20030430153645.GL39658@survey.codeburst.net> <20030430164135.GB26508@madman.celabo.org> <20030501140255.GB1869@survey.codeburst.net> <20030501143032.GA34163@madman.celabo.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030501143032.GA34163@madman.celabo.org> User-Agent: Mutt/1.4.1i Subject: Re: `Hiding' libc symbols (was Re: cvs commit: src/lib/libc/gen ...) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2003 14:46:03 -0000 On Thu, May 01, 2003 at 09:30:32AM -0500, Jacques A. Vidrine wrote: > On Thu, May 01, 2003 at 03:02:55PM +0100, Paul Richards wrote: > > On Wed, Apr 30, 2003 at 11:41:35AM -0500, Jacques A. Vidrine wrote: > > > [Trimmed cc:list; moving to freebsd-arch] > > > > > > > > > First, has something been broken by making strlcpy/strlcat into a weak > > > reference? > > > > Yes, deliberately overloading it from an application now no longer > > works. > > Give me a break. Good, it should not work by accident. An > application might define strlcpy for its own use, but we should NEVER > use the application's strlcpy. [1] An application doesn't have any business defining a strlcpy, since str* is reserved. The qpopper application is just broken and we shouldn't be "fixing" our libc to work around that. The only time you're likely to do something like this is if you're deliberately overriding the "official" implementation of these functions because you're instrumenting or something of a similar nature. > > What really concerns me though, is that behaviour is only defined > > for 2 functions. > > No, it is done for some 150+ functions. If the technique didn't have 150+? I must have missed that in the commit and subsequent discussion. > a certain distasteful side-effect when used en masse, I would push > for covering almost all of the other symbols libc exports. (If an > application defines `strcpy', should we use that from within libc?) > But until a better technique arrives, I am happy to apply it a little > less liberally. POLA suggests yes, since that's how it's always worked and there are a category of applications that rely on this behaviour (which would work on other platforms but not FreeBSD and for a reason that would be very hard to determine). Just because qpopper is broken doesn't mean that all applications should now be prohibited from exploiting this technique. > > The implementation of FreeBSD should be what's correct, we shouldn't > > fudge things to accomodate bad packages, fix the problem where the > > problem really exists. > > Obviously, I don't see it the same way you do. Calling the > application's strlcpy in order to implement some internal libc > function is not ``what's correct'', regardless of whether the > application is buggy or perfect. Hmm, perhaps a more correct implementation of our libc would not use the exported interface to implement the exported interface (thinking aloud). i.e. there'd be a _strlcpy that strlcpy was just a wrapper for and internally the _strlcpy would be used. -- Paul Richards From owner-freebsd-arch@FreeBSD.ORG Thu May 1 07:53:48 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 578AE37B401 for ; Thu, 1 May 2003 07:53:48 -0700 (PDT) Received: from gw.nectar.cc (gw.nectar.cc [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 75EBC43FA3 for ; Thu, 1 May 2003 07:53:47 -0700 (PDT) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.nectar.cc (Postfix) with ESMTP id B42DA50; Thu, 1 May 2003 09:53:46 -0500 (CDT) Received: by madman.celabo.org (Postfix, from userid 1001) id 0E8A578C4A; Thu, 1 May 2003 09:53:46 -0500 (CDT) Date: Thu, 1 May 2003 09:53:45 -0500 From: "Jacques A. Vidrine" To: Paul Richards Message-ID: <20030501145345.GA34884@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , Paul Richards , freebsd-arch@FreeBSD.org References: <20030430043303.GA46365@mero.morphisms.net> <20030430062647.GA82023@rot13.obsecurity.org> <20030430143121.GK39658@survey.codeburst.net> <20030430152708.GA26216@madman.celabo.org> <20030430153645.GL39658@survey.codeburst.net> <20030430164135.GB26508@madman.celabo.org> <20030501140255.GB1869@survey.codeburst.net> <20030501143032.GA34163@madman.celabo.org> <20030501144600.GC1869@survey.codeburst.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030501144600.GC1869@survey.codeburst.net> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.3i-ja.1 cc: freebsd-arch@FreeBSD.org Subject: Re: `Hiding' libc symbols (was Re: cvs commit: src/lib/libc/gen ...) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2003 14:53:48 -0000 On Thu, May 01, 2003 at 03:46:00PM +0100, Paul Richards wrote: [...] > > No, it is done for some 150+ functions. If the technique didn't have > > 150+? I must have missed that in the commit and subsequent discussion. See src/lib/libc/include/namespace.h . [...] > Hmm, perhaps a more correct implementation of our libc would not > use the exported interface to implement the exported interface > (thinking aloud). > > i.e. there'd be a _strlcpy that strlcpy was just a wrapper for > and internally the _strlcpy would be used. Oh, Paul. That is exactly what we are doing today. strlcpy.c: 41 __weak_reference(_strlcpy, strlcpy); 42 /* 43 * Copy src to string dst of size siz. At most siz-1 characters 44 * will be copied. Always NUL terminates (unless siz == 0). 45 * Returns strlen(src); if retval >= siz, truncation occurred. 46 */ 47 size_t _strlcpy(dst, src, siz) 48 char *dst; 49 const char *src; 50 size_t siz; 51 { A libc consumer (getpwent.c): 587 namesize = _strlcpy(&keybuf[1], name, sizeof(keybuf)-1); Cheers, -- Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal nectar@celabo.org . jvidrine@verio.net . nectar@freebsd.org . nectar@kth.se From owner-freebsd-arch@FreeBSD.ORG Thu May 1 07:58:00 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D788537B401; Thu, 1 May 2003 07:58:00 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 17C9043F93; Thu, 1 May 2003 07:58:00 -0700 (PDT) (envelope-from eischen@pcnet1.pcnet.com) Received: from pcnet1.pcnet.com (localhost [127.0.0.1]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h41EvvBg007093; Thu, 1 May 2003 10:57:57 -0400 (EDT) Received: from localhost (eischen@localhost)h41EvvO9007086; Thu, 1 May 2003 10:57:57 -0400 (EDT) Date: Thu, 1 May 2003 10:57:57 -0400 (EDT) From: Daniel Eischen To: Paul Richards In-Reply-To: <20030501144600.GC1869@survey.codeburst.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-arch@freebsd.org Subject: Re: `Hiding' libc symbols (was Re: cvs commit: src/lib/libc/gen ...) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2003 14:58:01 -0000 On Thu, 1 May 2003, Paul Richards wrote: > On Thu, May 01, 2003 at 09:30:32AM -0500, Jacques A. Vidrine wrote: > > On Thu, May 01, 2003 at 03:02:55PM +0100, Paul Richards wrote: > > > What really concerns me though, is that behaviour is only defined > > > for 2 functions. > > > > No, it is done for some 150+ functions. If the technique didn't have > > 150+? I must have missed that in the commit and subsequent discussion. All the system calls. All the functions that the threads libraries need to override or provide cancellation points for. Also, for fun, do an 'nm libc_r.so.5 | grep " T "' (on an unstripped libc_r) and see how may functions don't begin with underscores. -- Dan Eischen From owner-freebsd-arch@FreeBSD.ORG Thu May 1 08:14:11 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B6A6B37B401 for ; Thu, 1 May 2003 08:14:11 -0700 (PDT) Received: from mx0.freebsd-services.com (survey.codeburst.net [195.149.39.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F9E343FA3 for ; Thu, 1 May 2003 08:14:11 -0700 (PDT) (envelope-from paul@freebsd-services.com) Received: by mx0.freebsd-services.com (Postfix, from userid 1002) id 04FEE1B214; Thu, 1 May 2003 16:14:09 +0100 (BST) Date: Thu, 1 May 2003 16:14:09 +0100 From: Paul Richards To: Bruce Evans Message-ID: <20030501151409.GD1869@survey.codeburst.net> References: <200304290438.h3T4cdHE069528@arch20m.dellroad.org> <16047.59314.532227.475952@grasshopper.cs.duke.edu> <20030501144708.I18220@gamplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030501144708.I18220@gamplex.bde.org> User-Agent: Mutt/1.4.1i cc: Andrew Gallatin cc: freebsd-arch@freebsd.org Subject: Re: lots of malloc(M_WAITOK)'s in interrupt context from camisr X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2003 15:14:12 -0000 On Thu, May 01, 2003 at 04:31:08PM +1000, Bruce Evans wrote: > On Wed, 30 Apr 2003, Andrew Gallatin wrote: > > > John Baldwin writes: > > > > > If you need to do more work in your interrupt routine than just wakeups > > > and dinking with registers, you can always wake up a software interrupt > > > handler or some other random kthread to do things that take a long amount > > (This is about normal interrupt handlers, not INTR_FAST ones.) > > > Dumb question: Exactly what is one allowed to do in an INTR_FAST > > interrupt context? Obviously, you can't sleep. But can you call > > wakeup()? What exactly defines a INTR_FAST interrupt context in the first place. Do we have any rules for when it should be used, it just seems to me that all interrupt handlers should be INTR_FAST and that we'd then just have interrupt handlers. -- Paul Richards From owner-freebsd-arch@FreeBSD.ORG Thu May 1 08:15:08 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2B6F037B401; Thu, 1 May 2003 08:15:08 -0700 (PDT) Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA3F543FBD; Thu, 1 May 2003 08:15:05 -0700 (PDT) (envelope-from ache@pobrecita.freebsd.ru) Received: from pobrecita.freebsd.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.12.9/8.12.9) with ESMTP id h41FF3nd054492; Thu, 1 May 2003 19:15:03 +0400 (MSD) (envelope-from ache@pobrecita.freebsd.ru) Received: (from ache@localhost) by pobrecita.freebsd.ru (8.12.9/8.12.9/Submit) id h41FF2fU054491; Thu, 1 May 2003 19:15:02 +0400 (MSD) Date: Thu, 1 May 2003 19:15:01 +0400 From: "Andrey A. Chernov" To: "Jacques A. Vidrine" , Paul Richards , freebsd-arch@FreeBSD.org Message-ID: <20030501151458.GA54182@nagual.pp.ru> References: <20030430043303.GA46365@mero.morphisms.net> <20030430062647.GA82023@rot13.obsecurity.org> <20030430143121.GK39658@survey.codeburst.net> <20030430152708.GA26216@madman.celabo.org> <20030430153645.GL39658@survey.codeburst.net> <20030430164135.GB26508@madman.celabo.org> <20030501140255.GB1869@survey.codeburst.net> <20030501143032.GA34163@madman.celabo.org> <20030501144600.GC1869@survey.codeburst.net> <20030501145345.GA34884@madman.celabo.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030501145345.GA34884@madman.celabo.org> User-Agent: Mutt/1.5.4i Subject: Re: `Hiding' libc symbols (was Re: cvs commit: src/lib/libc/gen ...) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2003 15:15:08 -0000 On Thu, May 01, 2003 at 09:53:45 -0500, Jacques A. Vidrine wrote: > > A libc consumer (getpwent.c): > 587 namesize = _strlcpy(&keybuf[1], name, sizeof(keybuf)-1); IMHO, it is bad hack at whole, and all namespace.h tricks should be removed. The reason is quite simple. Yes, you can save libc this way, but what happens, if application linked, say, with libc AND libncurses (insert any other system library here)? libc will be saved, but libncurses will not. It means, to be logically, you need to replace strlcpy with _strlcpy in ALL FreeBSD libraries. Better way is stop doing half-singing - half-dancing and produce linker error when application attempts to replace any function in standard namespace. It automatically makes impossible broken binary-only packages. So, I vote for namespace.h removing (i.e. all _ tricks). Who with me? From owner-freebsd-arch@FreeBSD.ORG Thu May 1 08:16:59 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4BFDB37B401 for ; Thu, 1 May 2003 08:16:59 -0700 (PDT) Received: from mx0.freebsd-services.com (survey.codeburst.net [195.149.39.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id BAD8843F93 for ; Thu, 1 May 2003 08:16:58 -0700 (PDT) (envelope-from paul@freebsd-services.com) Received: by mx0.freebsd-services.com (Postfix, from userid 1002) id 1172D1B216; Thu, 1 May 2003 16:16:57 +0100 (BST) Date: Thu, 1 May 2003 16:16:57 +0100 From: Paul Richards To: Poul-Henning Kamp Message-ID: <20030501151657.GE1869@survey.codeburst.net> References: <32183.1049881186@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <32183.1049881186@critter.freebsd.dk> User-Agent: Mutt/1.4.1i cc: arch@freebsd.org Subject: Re: Sharing code between kernel and userland.... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2003 15:16:59 -0000 On Wed, Apr 09, 2003 at 11:39:46AM +0200, Poul-Henning Kamp wrote: > > This is a problem I have hit before, and now I hit it again: I need > to share a function between kernel and userland. > Isn't that what libkern was originally all about? Not that I find that solution particularly elegant since it's a but all or nothing so if we adopt a different solution we should probably get rid of libkern and look at ways of re-sharing some of that code with userland again (since I think they've branched quite a bit now). -- Paul Richards From owner-freebsd-arch@FreeBSD.ORG Thu May 1 08:22:53 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 94FFA37B401 for ; Thu, 1 May 2003 08:22:53 -0700 (PDT) Received: from gw.nectar.cc (gw.nectar.cc [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id B330B43F75 for ; Thu, 1 May 2003 08:22:52 -0700 (PDT) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.nectar.cc (Postfix) with ESMTP id 25C0D50; Thu, 1 May 2003 10:22:52 -0500 (CDT) Received: by madman.celabo.org (Postfix, from userid 1001) id 6BC3478C4A; Thu, 1 May 2003 10:22:51 -0500 (CDT) Date: Thu, 1 May 2003 10:22:51 -0500 From: "Jacques A. Vidrine" To: "Andrey A. Chernov" Message-ID: <20030501152251.GB34992@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , "Andrey A. Chernov" , freebsd-arch@FreeBSD.org References: <20030430062647.GA82023@rot13.obsecurity.org> <20030430143121.GK39658@survey.codeburst.net> <20030430152708.GA26216@madman.celabo.org> <20030430153645.GL39658@survey.codeburst.net> <20030430164135.GB26508@madman.celabo.org> <20030501140255.GB1869@survey.codeburst.net> <20030501143032.GA34163@madman.celabo.org> <20030501144600.GC1869@survey.codeburst.net> <20030501145345.GA34884@madman.celabo.org> <20030501151458.GA54182@nagual.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030501151458.GA54182@nagual.pp.ru> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.3i-ja.1 cc: freebsd-arch@FreeBSD.org Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2003 15:22:53 -0000 On Thu, May 01, 2003 at 07:15:01PM +0400, Andrey A. Chernov wrote: > On Thu, May 01, 2003 at 09:53:45 -0500, Jacques A. Vidrine wrote: > > > > A libc consumer (getpwent.c): > > 587 namesize = _strlcpy(&keybuf[1], name, sizeof(keybuf)-1); > > IMHO, it is bad hack at whole, and all namespace.h tricks should be > removed. > > The reason is quite simple. Yes, you can save libc this way, but what > happens, if application linked, say, with libc AND libncurses (insert any > other system library here)? libc will be saved, but libncurses will not. > It means, to be logically, you need to replace strlcpy with _strlcpy in > ALL FreeBSD libraries. Better way is stop doing half-singing - > half-dancing and produce linker error when application attempts to replace > any function in standard namespace. It automatically makes impossible > broken binary-only packages. > > So, I vote for namespace.h removing (i.e. all _ tricks). Who with me? I'm with you ... as long as: (a) We then post-process libraries (or object files) to automagically handle the symbols (all of them, or maybe just those not covered by some standard we pick in the case of libc). e.g. something such as objcopy --weaken ${.IMPSRC} ${.TARGET} but a bit more work. (b) We give Daniel and others working on threaded libraries a chance to discuss the special needs there. (That _is_ why namespace.h was originally created. We do need to handle stubs somehow; weak symbols alone are not enough.) (c) We do it after 5.1-RELEASE, and before 5.2-RELEASE; or we only do it in 6.x. (d) I don't have to do it all. Cheers, -- Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal nectar@celabo.org . jvidrine@verio.net . nectar@freebsd.org . nectar@kth.se From owner-freebsd-arch@FreeBSD.ORG Thu May 1 08:31:52 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0BF2D37B401 for ; Thu, 1 May 2003 08:31:52 -0700 (PDT) Received: from mail.speakeasy.net (mail13.speakeasy.net [216.254.0.213]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE78643FB1 for ; Thu, 1 May 2003 08:31:50 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 26669 invoked from network); 1 May 2003 15:31:53 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 1 May 2003 15:31:53 -0000 Received: from laptop.baldwin.cx ([216.133.140.1]) by server.baldwin.cx (8.12.8/8.12.8) with ESMTP id h41FVlOv025832; Thu, 1 May 2003 11:31:48 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20030501151409.GD1869@survey.codeburst.net> Date: Thu, 01 May 2003 11:31:32 -0400 (EDT) From: John Baldwin To: Paul Richards cc: Andrew Gallatin cc: freebsd-arch@freebsd.org Subject: Re: lots of malloc(M_WAITOK)'s in interrupt context from camisr X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2003 15:31:52 -0000 On 01-May-2003 Paul Richards wrote: > On Thu, May 01, 2003 at 04:31:08PM +1000, Bruce Evans wrote: >> On Wed, 30 Apr 2003, Andrew Gallatin wrote: >> >> > John Baldwin writes: >> > >> > > If you need to do more work in your interrupt routine than just wakeups >> > > and dinking with registers, you can always wake up a software interrupt >> > > handler or some other random kthread to do things that take a long amount >> >> (This is about normal interrupt handlers, not INTR_FAST ones.) >> >> > Dumb question: Exactly what is one allowed to do in an INTR_FAST >> > interrupt context? Obviously, you can't sleep. But can you call >> > wakeup()? > > What exactly defines a INTR_FAST interrupt context in the first > place. Do we have any rules for when it should be used, it just > seems to me that all interrupt handlers should be INTR_FAST and > that we'd then just have interrupt handlers. Since INTR_FAST handlers can't lock a normal mutex, this would require all device drivers to use spin locks (which either disable or defer interrupts) thus greatly increasing latency. INTR_FAST are only suitable for things such as sio(4) which need very low latency between interrupt assertion and handler execution and cannot deal with that latency for normal interrupt handlers. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ From owner-freebsd-arch@FreeBSD.ORG Thu May 1 08:35:00 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E671237B401; Thu, 1 May 2003 08:35:00 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 28EC843FA3; Thu, 1 May 2003 08:35:00 -0700 (PDT) (envelope-from eischen@pcnet1.pcnet.com) Received: from pcnet1.pcnet.com (localhost [127.0.0.1]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h41FYvBg012699; Thu, 1 May 2003 11:34:57 -0400 (EDT) Received: from localhost (eischen@localhost)h41FYvjA012694; Thu, 1 May 2003 11:34:57 -0400 (EDT) Date: Thu, 1 May 2003 11:34:57 -0400 (EDT) From: Daniel Eischen To: "Andrey A. Chernov" In-Reply-To: <20030501151458.GA54182@nagual.pp.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-arch@freebsd.org Subject: Re: `Hiding' libc symbols (was Re: cvs commit: src/lib/libc/gen ...) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2003 15:35:01 -0000 On Thu, 1 May 2003, Andrey A. Chernov wrote: > On Thu, May 01, 2003 at 09:53:45 -0500, Jacques A. Vidrine wrote: > > > > A libc consumer (getpwent.c): > > 587 namesize = _strlcpy(&keybuf[1], name, sizeof(keybuf)-1); > > IMHO, it is bad hack at whole, and all namespace.h tricks should be > removed. > > The reason is quite simple. Yes, you can save libc this way, but what > happens, if application linked, say, with libc AND libncurses (insert any > other system library here)? libc will be saved, but libncurses will not. > It means, to be logically, you need to replace strlcpy with _strlcpy in > ALL FreeBSD libraries. Better way is stop doing half-singing - > half-dancing and produce linker error when application attempts to replace > any function in standard namespace. It automatically makes impossible > broken binary-only packages. > > So, I vote for namespace.h removing (i.e. all _ tricks). Who with me? Wrong. We need _ tricks for threads libraries to work properly and was the reason it was added in the first place. BDE came up with the idea and it was reviewed by him. People developing and modifying libc need to be aware of the requirements of the threads libraries. Libc isn't in its own little world anymore; it has to play along nicely with others. Sure, you can debate strlcpy/strlcat if you want, but please don't remove things that need to be there (in [un-]namespace.h). -- Dan Eischen From owner-freebsd-arch@FreeBSD.ORG Thu May 1 08:41:43 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D744F37B401; Thu, 1 May 2003 08:41:43 -0700 (PDT) Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A76043F3F; Thu, 1 May 2003 08:41:42 -0700 (PDT) (envelope-from ache@pobrecita.freebsd.ru) Received: from pobrecita.freebsd.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.12.9/8.12.9) with ESMTP id h41Ffdnd054987; Thu, 1 May 2003 19:41:40 +0400 (MSD) (envelope-from ache@pobrecita.freebsd.ru) Received: (from ache@localhost) by pobrecita.freebsd.ru (8.12.9/8.12.9/Submit) id h41FfdIA054986; Thu, 1 May 2003 19:41:39 +0400 (MSD) Date: Thu, 1 May 2003 19:41:39 +0400 From: "Andrey A. Chernov" To: Daniel Eischen Message-ID: <20030501154139.GA54878@nagual.pp.ru> References: <20030501151458.GA54182@nagual.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i cc: freebsd-arch@freebsd.org Subject: Re: `Hiding' libc symbols (was Re: cvs commit: src/lib/libc/gen ...) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2003 15:41:44 -0000 On Thu, May 01, 2003 at 11:34:57 -0400, Daniel Eischen wrote: > > Wrong. We need _ tricks for threads libraries to work properly and > was the reason it was added in the first place. BDE came up with > the idea and it was reviewed by him. Threads is completely another issue. We can do ANY tricks threads needs when it is NOT affects normal linking (under "normal" I mean preventing standard namespace replacement from outside of libc). If current replacement way for threads not allows preventing, it should be changed somehow to be truely libc internal, i.e. not explotable from outside of libc/libc_r/other threads libs. From owner-freebsd-arch@FreeBSD.ORG Thu May 1 08:45:51 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C54237B401; Thu, 1 May 2003 08:45:51 -0700 (PDT) Received: from mx0.freebsd-services.com (survey.codeburst.net [195.149.39.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 850BD43F93; Thu, 1 May 2003 08:45:49 -0700 (PDT) (envelope-from paul@freebsd-services.com) Received: by mx0.freebsd-services.com (Postfix, from userid 1002) id D41C41B218; Thu, 1 May 2003 16:45:48 +0100 (BST) Date: Thu, 1 May 2003 16:45:48 +0100 From: Paul Richards To: "Jacques A. Vidrine" , freebsd-arch@FreeBSD.org Message-ID: <20030501154548.GG1869@survey.codeburst.net> References: <20030430043303.GA46365@mero.morphisms.net> <20030430062647.GA82023@rot13.obsecurity.org> <20030430143121.GK39658@survey.codeburst.net> <20030430152708.GA26216@madman.celabo.org> <20030430153645.GL39658@survey.codeburst.net> <20030430164135.GB26508@madman.celabo.org> <20030501140255.GB1869@survey.codeburst.net> <20030501143032.GA34163@madman.celabo.org> <20030501144600.GC1869@survey.codeburst.net> <20030501145345.GA34884@madman.celabo.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030501145345.GA34884@madman.celabo.org> User-Agent: Mutt/1.4.1i Subject: Re: `Hiding' libc symbols (was Re: cvs commit: src/lib/libc/gen ...) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2003 15:45:51 -0000 On Thu, May 01, 2003 at 09:53:45AM -0500, Jacques A. Vidrine wrote: > On Thu, May 01, 2003 at 03:46:00PM +0100, Paul Richards wrote: > [...] > > > No, it is done for some 150+ functions. If the technique didn't have > > > > 150+? I must have missed that in the commit and subsequent discussion. > > See src/lib/libc/include/namespace.h . > > [...] > > Hmm, perhaps a more correct implementation of our libc would not > > use the exported interface to implement the exported interface > > (thinking aloud). > > > > i.e. there'd be a _strlcpy that strlcpy was just a wrapper for > > and internally the _strlcpy would be used. > > Oh, Paul. That is exactly what we are doing today. (me wanders off to study the code instead of speaking from a very old recollection of how things used to be). -- Paul Richards From owner-freebsd-arch@FreeBSD.ORG Thu May 1 08:51:18 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B56CE37B401; Thu, 1 May 2003 08:51:18 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 06C5D43F75; Thu, 1 May 2003 08:51:18 -0700 (PDT) (envelope-from eischen@pcnet1.pcnet.com) Received: from pcnet1.pcnet.com (localhost [127.0.0.1]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h41FpGBg015153; Thu, 1 May 2003 11:51:16 -0400 (EDT) Received: from localhost (eischen@localhost)h41FpF1X015146; Thu, 1 May 2003 11:51:15 -0400 (EDT) Date: Thu, 1 May 2003 11:51:15 -0400 (EDT) From: Daniel Eischen To: "Andrey A. Chernov" In-Reply-To: <20030501154139.GA54878@nagual.pp.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-arch@freebsd.org Subject: Re: `Hiding' libc symbols (was Re: cvs commit: src/lib/libc/gen ...) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2003 15:51:19 -0000 On Thu, 1 May 2003, Andrey A. Chernov wrote: > On Thu, May 01, 2003 at 11:34:57 -0400, Daniel Eischen wrote: > > > > Wrong. We need _ tricks for threads libraries to work properly and > > was the reason it was added in the first place. BDE came up with > > the idea and it was reviewed by him. > > Threads is completely another issue. We can do ANY tricks threads needs > when it is NOT affects normal linking (under "normal" I mean preventing > standard namespace replacement from outside of libc). If current > replacement way for threads not allows preventing, it should be changed > somehow to be truely libc internal, i.e. not explotable from outside of > libc/libc_r/other threads libs. I'm not sure what you mean, but what we have works well. There may be times that we want to call the internal _foo() and other times were we want to call foo(). How are you going to build a tool that can tell the difference if you reference foo() in both places? IMHO, I don't think we should make libc developers dumb so that they don't have to know whether they should use foo() or _foo(). It's also easier to know which one is being referenced when you are reading the source. -- Dan Eischen From owner-freebsd-arch@FreeBSD.ORG Thu May 1 08:53:44 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D09E537B401; Thu, 1 May 2003 08:53:44 -0700 (PDT) Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A03743FAF; Thu, 1 May 2003 08:53:43 -0700 (PDT) (envelope-from ache@pobrecita.freebsd.ru) Received: from pobrecita.freebsd.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.12.9/8.12.9) with ESMTP id h41Frgnd055311; Thu, 1 May 2003 19:53:42 +0400 (MSD) (envelope-from ache@pobrecita.freebsd.ru) Received: (from ache@localhost) by pobrecita.freebsd.ru (8.12.9/8.12.9/Submit) id h41FrgT5055310; Thu, 1 May 2003 19:53:42 +0400 (MSD) Date: Thu, 1 May 2003 19:53:42 +0400 From: "Andrey A. Chernov" To: "Jacques A. Vidrine" , freebsd-arch@FreeBSD.org Message-ID: <20030501155342.GA55078@nagual.pp.ru> References: <20030430143121.GK39658@survey.codeburst.net> <20030430152708.GA26216@madman.celabo.org> <20030430153645.GL39658@survey.codeburst.net> <20030430164135.GB26508@madman.celabo.org> <20030501140255.GB1869@survey.codeburst.net> <20030501143032.GA34163@madman.celabo.org> <20030501144600.GC1869@survey.codeburst.net> <20030501145345.GA34884@madman.celabo.org> <20030501151458.GA54182@nagual.pp.ru> <20030501152251.GB34992@madman.celabo.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030501152251.GB34992@madman.celabo.org> User-Agent: Mutt/1.5.4i Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2003 15:53:45 -0000 On Thu, May 01, 2003 at 10:22:51 -0500, Jacques A. Vidrine wrote: > > I'm with you ... as long as: So, we can right now back out strlcpy hack at least to minimize future work. It have nothing common with threads, namespace.h is for. Saving libc but not saving other libs application can be linked to gains really nothing. > (a) We then post-process libraries (or object files) to > automagically handle the symbols (all of them, or maybe just > those not covered by some standard we pick in the case of libc). > e.g. something such as > objcopy --weaken ${.IMPSRC} ${.TARGET} > but a bit more work. Ok. > (b) We give Daniel and others working on threaded libraries a chance > to discuss the special needs there. (That _is_ why namespace.h > was originally created. We do need to handle stubs somehow; weak > symbols alone are not enough.) See my another reply (to Daniel) about threads. > (c) We do it after 5.1-RELEASE, and before 5.2-RELEASE; or we only > do it in 6.x. Ok. > (d) I don't have to do it all. I too. :-) Most of work will be to change current threads tricks to prevent them be explotable from outside of libc/libc_r/etc, i.e. to be true internal. It is for our threads team who introduce namespace.h From owner-freebsd-arch@FreeBSD.ORG Thu May 1 09:01:22 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F3D6437B429 for ; Thu, 1 May 2003 09:01:21 -0700 (PDT) Received: from gw.nectar.cc (gw.nectar.cc [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9582C43FBF for ; Thu, 1 May 2003 09:01:20 -0700 (PDT) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.nectar.cc (Postfix) with ESMTP id 09773A3; Thu, 1 May 2003 11:01:20 -0500 (CDT) Received: by madman.celabo.org (Postfix, from userid 1001) id 5E0FF78C4A; Thu, 1 May 2003 11:01:19 -0500 (CDT) Date: Thu, 1 May 2003 11:01:19 -0500 From: "Jacques A. Vidrine" To: "Andrey A. Chernov" Message-ID: <20030501160119.GB35367@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , "Andrey A. Chernov" , freebsd-arch@FreeBSD.org References: <20030430152708.GA26216@madman.celabo.org> <20030430153645.GL39658@survey.codeburst.net> <20030430164135.GB26508@madman.celabo.org> <20030501140255.GB1869@survey.codeburst.net> <20030501143032.GA34163@madman.celabo.org> <20030501144600.GC1869@survey.codeburst.net> <20030501145345.GA34884@madman.celabo.org> <20030501151458.GA54182@nagual.pp.ru> <20030501152251.GB34992@madman.celabo.org> <20030501155342.GA55078@nagual.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030501155342.GA55078@nagual.pp.ru> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.3i-ja.1 cc: freebsd-arch@FreeBSD.org Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2003 16:01:22 -0000 On Thu, May 01, 2003 at 07:53:42PM +0400, Andrey A. Chernov wrote: > On Thu, May 01, 2003 at 10:22:51 -0500, Jacques A. Vidrine wrote: > > > > I'm with you ... as long as: > > So, we can right now back out strlcpy hack at least to minimize future > work. No, that does not follow. strlcpy does not add work for any future solution, and besides, it is not the future yet. > It have nothing common with threads, namespace.h is for. No, you are mistaken. namespace.h 39 /* 40 * ISO C (C90) section. Most names in libc aren't in ISO C, so they 41 * should be here. Most aren't here... 42 */ 43 #define err _err 44 #define warn _warn 45 #define nsdispatch _nsdispatch 46 #define strlcat _strlcat 47 #define strlcpy _strlcpy The comment dates back to 2001. > Saving libc > but not saving other libs application can be linked to gains really > nothing. That is your opinion, and one I do not share. I did not make the commit for no purpose. [...] > > (b) We give Daniel and others working on threaded libraries a chance > > to discuss the special needs there. (That _is_ why namespace.h > > was originally created. We do need to handle stubs somehow; weak > > symbols alone are not enough.) > > See my another reply (to Daniel) about threads. I saw it and I think you are mistaken. > > (d) I don't have to do it all. > > I too. :-) Most of work will be to change current threads tricks to > prevent them be explotable from outside of libc/libc_r/etc, i.e. to be > true internal. It is for our threads team who introduce namespace.h No, I do not think this is a threads-only issue. Cheers, -- Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal nectar@celabo.org . jvidrine@verio.net . nectar@freebsd.org . nectar@kth.se From owner-freebsd-arch@FreeBSD.ORG Thu May 1 09:02:03 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 62E6337B404; Thu, 1 May 2003 09:01:59 -0700 (PDT) Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id DAF4143F93; Thu, 1 May 2003 09:01:57 -0700 (PDT) (envelope-from ache@pobrecita.freebsd.ru) Received: from pobrecita.freebsd.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.12.9/8.12.9) with ESMTP id h41G1tnd055594; Thu, 1 May 2003 20:01:55 +0400 (MSD) (envelope-from ache@pobrecita.freebsd.ru) Received: (from ache@localhost) by pobrecita.freebsd.ru (8.12.9/8.12.9/Submit) id h41G1tao055593; Thu, 1 May 2003 20:01:55 +0400 (MSD) Date: Thu, 1 May 2003 20:01:55 +0400 From: "Andrey A. Chernov" To: Daniel Eischen Message-ID: <20030501160155.GB55078@nagual.pp.ru> References: <20030501154139.GA54878@nagual.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i cc: freebsd-arch@freebsd.org Subject: Re: `Hiding' libc symbols (was Re: cvs commit: src/lib/libc/gen ...) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2003 16:02:03 -0000 On Thu, May 01, 2003 at 11:51:15 -0400, Daniel Eischen wrote: > > Threads is completely another issue. We can do ANY tricks threads needs > > when it is NOT affects normal linking (under "normal" I mean preventing > > standard namespace replacement from outside of libc). If current > > replacement way for threads not allows preventing, it should be changed > > somehow to be truely libc internal, i.e. not explotable from outside of > > libc/libc_r/other threads libs. > > I'm not sure what you mean, but what we have works well. There > may be times that we want to call the internal _foo() and other > times were we want to call foo(). How are you going to build > a tool that can tell the difference if you reference foo() in both > places? Internal _names are the way threads tricks are implemented. I am looking from outside of that scheme, so this details are not needed. From outside of this scheme now I can replace, say, open() with anything I want (because it is _ tricked in threads). It should not happens. I.e. open() replacement in threads should happens, but in linked application - not. It means libc and libc_r must share some unusual replacement way which application never can normally use. From owner-freebsd-arch@FreeBSD.ORG Thu May 1 09:09:48 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9928A37B401; Thu, 1 May 2003 09:09:48 -0700 (PDT) Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3FBC543FB1; Thu, 1 May 2003 09:09:45 -0700 (PDT) (envelope-from ache@pobrecita.freebsd.ru) Received: from pobrecita.freebsd.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.12.9/8.12.9) with ESMTP id h41G9ind055784; Thu, 1 May 2003 20:09:44 +0400 (MSD) (envelope-from ache@pobrecita.freebsd.ru) Received: (from ache@localhost) by pobrecita.freebsd.ru (8.12.9/8.12.9/Submit) id h41G9iWe055783; Thu, 1 May 2003 20:09:44 +0400 (MSD) Date: Thu, 1 May 2003 20:09:44 +0400 From: "Andrey A. Chernov" To: "Jacques A. Vidrine" , freebsd-arch@FreeBSD.org Message-ID: <20030501160944.GC55078@nagual.pp.ru> References: <20030430153645.GL39658@survey.codeburst.net> <20030430164135.GB26508@madman.celabo.org> <20030501140255.GB1869@survey.codeburst.net> <20030501143032.GA34163@madman.celabo.org> <20030501144600.GC1869@survey.codeburst.net> <20030501145345.GA34884@madman.celabo.org> <20030501151458.GA54182@nagual.pp.ru> <20030501152251.GB34992@madman.celabo.org> <20030501155342.GA55078@nagual.pp.ru> <20030501160119.GB35367@madman.celabo.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030501160119.GB35367@madman.celabo.org> User-Agent: Mutt/1.5.4i Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2003 16:09:48 -0000 On Thu, May 01, 2003 at 11:01:19 -0500, Jacques A. Vidrine wrote: > No, you are mistaken. > > namespace.h > > 39 /* > 40 * ISO C (C90) section. Most names in libc aren't in ISO C, so they > 41 * should be here. Most aren't here... > 42 */ > 43 #define err _err > 44 #define warn _warn > 45 #define nsdispatch _nsdispatch > 46 #define strlcat _strlcat > 47 #define strlcpy _strlcpy > > The comment dates back to 2001. And you are mistaken to add str* functions here. While the comment is true for err, warn etc. it is not true for standard-reserved str* prefix. > That is your opinion, and one I do not share. I did not make the > commit for no purpose. I understand your purpose, but point that 1) this way not works when multiply libraries linked and 2) it provokes str* standard reserved prefix incorrectly taken by applications. From owner-freebsd-arch@FreeBSD.ORG Thu May 1 09:13:34 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CCF3737B404; Thu, 1 May 2003 09:13:34 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 18C4443F3F; Thu, 1 May 2003 09:13:34 -0700 (PDT) (envelope-from eischen@pcnet1.pcnet.com) Received: from pcnet1.pcnet.com (localhost [127.0.0.1]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h41GDWBg018359; Thu, 1 May 2003 12:13:32 -0400 (EDT) Received: from localhost (eischen@localhost)h41GDV28018352; Thu, 1 May 2003 12:13:31 -0400 (EDT) Date: Thu, 1 May 2003 12:13:31 -0400 (EDT) From: Daniel Eischen To: "Andrey A. Chernov" In-Reply-To: <20030501160155.GB55078@nagual.pp.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-arch@freebsd.org Subject: Re: `Hiding' libc symbols (was Re: cvs commit: src/lib/libc/gen ...) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2003 16:13:35 -0000 On Thu, 1 May 2003, Andrey A. Chernov wrote: > On Thu, May 01, 2003 at 11:51:15 -0400, Daniel Eischen wrote: > > > Threads is completely another issue. We can do ANY tricks threads needs > > > when it is NOT affects normal linking (under "normal" I mean preventing > > > standard namespace replacement from outside of libc). If current > > > replacement way for threads not allows preventing, it should be changed > > > somehow to be truely libc internal, i.e. not explotable from outside of > > > libc/libc_r/other threads libs. > > > > I'm not sure what you mean, but what we have works well. There > > may be times that we want to call the internal _foo() and other > > times were we want to call foo(). How are you going to build > > a tool that can tell the difference if you reference foo() in both > > places? > > Internal _names are the way threads tricks are implemented. I am looking > from outside of that scheme, so this details are not needed. From outside > of this scheme now I can replace, say, open() with anything I want > (because it is _ tricked in threads). It should not happens. I.e. open() > replacement in threads should happens, but in linked application - not. It > means libc and libc_r must share some unusual replacement way which > application never can normally use. libc foo() wants to call _open(). libc bar() wants to call open(). If both foo() and bar() now reference open() and the ache tool converts all references to open to _open, now both foo() and bar() call _open(). namespace.h also gets rid of compiler errors when you reference _open instead of open. -- Dan Eischen From owner-freebsd-arch@FreeBSD.ORG Thu May 1 09:25:31 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E16FB37B401; Thu, 1 May 2003 09:25:31 -0700 (PDT) Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8BF1943FB1; Thu, 1 May 2003 09:25:30 -0700 (PDT) (envelope-from ache@pobrecita.freebsd.ru) Received: from pobrecita.freebsd.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.12.9/8.12.9) with ESMTP id h41GPTnd056308; Thu, 1 May 2003 20:25:29 +0400 (MSD) (envelope-from ache@pobrecita.freebsd.ru) Received: (from ache@localhost) by pobrecita.freebsd.ru (8.12.9/8.12.9/Submit) id h41GPT88056307; Thu, 1 May 2003 20:25:29 +0400 (MSD) Date: Thu, 1 May 2003 20:25:29 +0400 From: "Andrey A. Chernov" To: "Jacques A. Vidrine" , freebsd-arch@freebsd.org Message-ID: <20030501162529.GA56264@nagual.pp.ru> References: <20030430164135.GB26508@madman.celabo.org> <20030501140255.GB1869@survey.codeburst.net> <20030501143032.GA34163@madman.celabo.org> <20030501144600.GC1869@survey.codeburst.net> <20030501145345.GA34884@madman.celabo.org> <20030501151458.GA54182@nagual.pp.ru> <20030501152251.GB34992@madman.celabo.org> <20030501155342.GA55078@nagual.pp.ru> <20030501160119.GB35367@madman.celabo.org> <20030501160944.GC55078@nagual.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030501160944.GC55078@nagual.pp.ru> User-Agent: Mutt/1.5.4i Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2003 16:25:32 -0000 On Thu, May 01, 2003 at 20:09:44 +0400, Andrey A. Chernov wrote: > On Thu, May 01, 2003 at 11:01:19 -0500, Jacques A. Vidrine wrote: > > No, you are mistaken. > > > > namespace.h > > > > 39 /* > > 40 * ISO C (C90) section. Most names in libc aren't in ISO C, so they > > 41 * should be here. Most aren't here... > > 42 */ > > 43 #define err _err > > 44 #define warn _warn > > 45 #define nsdispatch _nsdispatch > > 46 #define strlcat _strlcat > > 47 #define strlcpy _strlcpy > > > > The comment dates back to 2001. > > And you are mistaken to add str* functions here. While the comment is true > for err, warn etc. it is not true for standard-reserved str* prefix. Just to note: we already have this precedent happens with strcasestr() function, not covered by standards. Some ports define their own strcasestr(). We decide to fix ports instead of libc hacking. And now we have two different ways of handling that case, one for strcasestr() and another for strlcat(). Where is logic? From owner-freebsd-arch@FreeBSD.ORG Thu May 1 10:24:16 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3DAD037B401 for ; Thu, 1 May 2003 10:24:16 -0700 (PDT) Received: from gw.nectar.cc (gw.nectar.cc [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6522943FAF for ; Thu, 1 May 2003 10:24:15 -0700 (PDT) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.nectar.cc (Postfix) with ESMTP id E5DB75; Thu, 1 May 2003 12:24:14 -0500 (CDT) Received: by madman.celabo.org (Postfix, from userid 1001) id 37A7C78C4A; Thu, 1 May 2003 12:24:14 -0500 (CDT) Date: Thu, 1 May 2003 12:24:14 -0500 From: "Jacques A. Vidrine" To: "Andrey A. Chernov" Message-ID: <20030501172414.GA23285@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , "Andrey A. Chernov" , freebsd-arch@freebsd.org References: <20030501140255.GB1869@survey.codeburst.net> <20030501143032.GA34163@madman.celabo.org> <20030501144600.GC1869@survey.codeburst.net> <20030501145345.GA34884@madman.celabo.org> <20030501151458.GA54182@nagual.pp.ru> <20030501152251.GB34992@madman.celabo.org> <20030501155342.GA55078@nagual.pp.ru> <20030501160119.GB35367@madman.celabo.org> <20030501160944.GC55078@nagual.pp.ru> <20030501162529.GA56264@nagual.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030501162529.GA56264@nagual.pp.ru> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.3i-ja.1 cc: freebsd-arch@freebsd.org Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2003 17:24:16 -0000 On Thu, May 01, 2003 at 08:25:29PM +0400, Andrey A. Chernov wrote: > Just to note: we already have this precedent happens with strcasestr() > function, not covered by standards. Some ports define their own > strcasestr(). We decide to fix ports instead of libc hacking. > > And now we have two different ways of handling that case, one for > strcasestr() and another for strlcat(). Where is logic? It is clear from this thread that many people did not know about this option (namespace.h) for resolving such issues. Andrey, I've no disagreement with you that there could be a better way. Until such a better way appears, I think that the namespace.h technique can continue to be used. I will support you or anyone else 100% in introducing a better mechanism. Cheers, -- Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal nectar@celabo.org . jvidrine@verio.net . nectar@freebsd.org . nectar@kth.se From owner-freebsd-arch@FreeBSD.ORG Thu May 1 10:48:49 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E57FF37B401; Thu, 1 May 2003 10:48:49 -0700 (PDT) Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63]) by mx1.FreeBSD.org (Postfix) with ESMTP id 11F8343F3F; Thu, 1 May 2003 10:48:49 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by sccrmhc03.attbi.com (sccrmhc03) with ESMTP id <2003050117484700300fn002e>; Thu, 1 May 2003 17:48:48 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id KAA73643; Thu, 1 May 2003 10:48:46 -0700 (PDT) Date: Thu, 1 May 2003 10:48:45 -0700 (PDT) From: Julian Elischer To: Paul Richards In-Reply-To: <20030501144600.GC1869@survey.codeburst.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: "Jacques A. Vidrine" cc: freebsd-arch@FreeBSD.org Subject: Re: Re: `Hiding' libc symbols (was Re: cvs commit: src/lib/libc/gen ...) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2003 17:48:50 -0000 On Thu, 1 May 2003, Paul Richards wrote: > On Thu, May 01, 2003 at 09:30:32AM -0500, Jacques A. Vidrine wrote: > > On Thu, May 01, 2003 at 03:02:55PM +0100, Paul Richards wrote: > > > On Wed, Apr 30, 2003 at 11:41:35AM -0500, Jacques A. Vidrine wrote: > > > > [Trimmed cc:list; moving to freebsd-arch] > > > > > > > > > > > > First, has something been broken by making strlcpy/strlcat into a weak > > > > reference? > > > > > > Yes, deliberately overloading it from an application now no longer > > > works. > > > > Give me a break. Good, it should not work by accident. An > > application might define strlcpy for its own use, but we should NEVER > > use the application's strlcpy. [1] > > An application doesn't have any business defining a strlcpy, since > str* is reserved. The qpopper application is just broken and we > shouldn't be "fixing" our libc to work around that. Exactly.. This is why we have ports It is also th king of thing that "configure" is supposed to fix.. The port should be altered to fix this and teh maintainers contected and told of the problem. I don't see why the libc needs to be changed at all. From owner-freebsd-arch@FreeBSD.ORG Thu May 1 11:05:49 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A492E37B407 for ; Thu, 1 May 2003 11:05:49 -0700 (PDT) Received: from mail.speakeasy.net (mail13.speakeasy.net [216.254.0.213]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF2EA43FB1 for ; Thu, 1 May 2003 11:05:47 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 29148 invoked from network); 1 May 2003 18:05:53 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 1 May 2003 18:05:53 -0000 Received: from laptop.baldwin.cx ([216.133.140.1]) by server.baldwin.cx (8.12.8/8.12.8) with ESMTP id h41I5iOv026327; Thu, 1 May 2003 14:05:45 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Thu, 01 May 2003 14:05:49 -0400 (EDT) From: John Baldwin To: Julian Elischer cc: "Jacques A. Vidrine" cc: freebsd-arch@FreeBSD.org Subject: Re: Re: `Hiding' libc symbols (was Re: cvs commit: src/lib/libc/gen ...) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2003 18:05:50 -0000 On 01-May-2003 Julian Elischer wrote: > > > On Thu, 1 May 2003, Paul Richards wrote: > >> On Thu, May 01, 2003 at 09:30:32AM -0500, Jacques A. Vidrine wrote: >> > On Thu, May 01, 2003 at 03:02:55PM +0100, Paul Richards wrote: >> > > On Wed, Apr 30, 2003 at 11:41:35AM -0500, Jacques A. Vidrine wrote: >> > > > [Trimmed cc:list; moving to freebsd-arch] >> > > > >> > > > >> > > > First, has something been broken by making strlcpy/strlcat into a weak >> > > > reference? >> > > >> > > Yes, deliberately overloading it from an application now no longer >> > > works. >> > >> > Give me a break. Good, it should not work by accident. An >> > application might define strlcpy for its own use, but we should NEVER >> > use the application's strlcpy. [1] >> >> An application doesn't have any business defining a strlcpy, since >> str* is reserved. The qpopper application is just broken and we >> shouldn't be "fixing" our libc to work around that. > > > > Exactly.. > This is why we have ports > It is also th king of thing that "configure" is supposed to fix.. > The port should be altered to fix this and teh maintainers contected and > told of the problem. > > I don't see why the libc needs to be changed at all. Agreed. Somebody just needs to sit down and fix the qpopper port and then the argument for this change goes away and it can be reverted. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ From owner-freebsd-arch@FreeBSD.ORG Thu May 1 11:28:22 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8691137B401; Thu, 1 May 2003 11:28:22 -0700 (PDT) Received: from gw.nectar.cc (gw.nectar.cc [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB01A43FBF; Thu, 1 May 2003 11:28:21 -0700 (PDT) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.nectar.cc (Postfix) with ESMTP id 397A65; Thu, 1 May 2003 13:28:21 -0500 (CDT) Received: by madman.celabo.org (Postfix, from userid 1001) id 7DF0178C4A; Thu, 1 May 2003 13:28:20 -0500 (CDT) Date: Thu, 1 May 2003 13:28:20 -0500 From: "Jacques A. Vidrine" To: John Baldwin Message-ID: <20030501182820.GA53641@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , John Baldwin , freebsd-arch@FreeBSD.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.3i-ja.1 cc: freebsd-arch@FreeBSD.org Subject: Re: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2003 18:28:22 -0000 On Thu, May 01, 2003 at 02:05:49PM -0400, John Baldwin wrote: > Agreed. Somebody just needs to sit down and fix the qpopper port and > then the argument for this change goes away and it can be reverted. qpopper is not the point. The qpopper port was fixed just a couple of hours after I made the commit to libc. (I had sent the qpopper patch to the port maintainer earlier.) Preventing the bogus behavior from ever happening again was the point. A lot of folks are focused on qpopper and strlcpy. I believe that the big picture is being missed. I moved this thread to freebsd-arch so that we could discuss how to hide all (or most, or non-standard) symbols in libc. Not so that we could argue about this particular commit. I'm backing out the commit in good faith and in the hopes that the big picture comes more clearly into focus. However, I must admit some disappointment in the situation. I believe that this was a good change, one that we need, and one that we should see more of. Cheers, -- Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal nectar@celabo.org . jvidrine@verio.net . nectar@freebsd.org . nectar@kth.se From owner-freebsd-arch@FreeBSD.ORG Thu May 1 11:45:03 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 80D6E37B401 for ; Thu, 1 May 2003 11:45:03 -0700 (PDT) Received: from mail.speakeasy.net (mail14.speakeasy.net [216.254.0.214]) by mx1.FreeBSD.org (Postfix) with ESMTP id 618D243FDD for ; Thu, 1 May 2003 11:45:02 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 29071 invoked from network); 1 May 2003 18:45:07 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 1 May 2003 18:45:07 -0000 Received: from laptop.baldwin.cx ([216.133.140.1]) by server.baldwin.cx (8.12.8/8.12.8) with ESMTP id h41IiwOv026453; Thu, 1 May 2003 14:44:58 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20030501182820.GA53641@madman.celabo.org> Date: Thu, 01 May 2003 14:45:02 -0400 (EDT) From: John Baldwin To: "Jacques A. Vidrine" cc: freebsd-arch@FreeBSD.org Subject: Re: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2003 18:45:03 -0000 On 01-May-2003 Jacques A. Vidrine wrote: > On Thu, May 01, 2003 at 02:05:49PM -0400, John Baldwin wrote: >> Agreed. Somebody just needs to sit down and fix the qpopper port and >> then the argument for this change goes away and it can be reverted. > > qpopper is not the point. The qpopper port was fixed just a couple of > hours after I made the commit to libc. (I had sent the qpopper patch > to the port maintainer earlier.) Preventing the bogus behavior from > ever happening again was the point. > > A lot of folks are focused on qpopper and strlcpy. I believe that > the big picture is being missed. I moved this thread to freebsd-arch > so that we could discuss how to hide all (or most, or non-standard) > symbols in libc. Not so that we could argue about this particular > commit. It seems that many people don't think the symbols in libc need hiding. What is the reason to prevent a user from overriding the functions used by libc? malloc() and free() are an example you agree to, and I don't think we should hide things willy-nilly. There are many uses for overriding symbols in libc that I'm sure neither of us have thought of. Why artificially limit it? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ From owner-freebsd-arch@FreeBSD.ORG Thu May 1 11:56:54 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D15F537B401; Thu, 1 May 2003 11:56:54 -0700 (PDT) Received: from smtp2.server.rpi.edu (smtp2.server.rpi.edu [128.113.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 89FAD43F3F; Thu, 1 May 2003 11:56:53 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp2.server.rpi.edu (8.12.9/8.12.9) with ESMTP id h41IuqWv007216; Thu, 1 May 2003 14:56:52 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20030501182820.GA53641@madman.celabo.org> References: <20030501182820.GA53641@madman.celabo.org> Date: Thu, 1 May 2003 14:56:51 -0400 To: "Jacques A. Vidrine" , John Baldwin From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 cc: freebsd-arch@freebsd.org Subject: Re: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2003 18:56:55 -0000 At 1:28 PM -0500 5/1/03, Jacques A. Vidrine wrote: >On Thu, May 01, 2003, John Baldwin wrote: > > Agreed. Somebody just needs to sit down and fix the qpopper > > port and then the argument for this change goes away and it > > can be reverted. > >qpopper is not the point. The qpopper port was fixed just a >couple of hours after I made the commit to libc. (I had sent >the qpopper patch to the port maintainer earlier.) Preventing >the bogus behavior from ever happening again was the point. > >A lot of folks are focused on qpopper and strlcpy. I believe >that the big picture is being missed. I moved this thread to >freebsd-arch so that we could discuss how to hide all (or most, >or non-standard) symbols in libc. Not so that we could argue >about this particular commit. I think the "big picture" is that many people simply do not agree with your premise. It is not that they are obsessed with the strlcpy() example, but they're using that example to (try to) explain why they disagree with your basic premise. As for me, I'm not quite sure what I think about the big picture. For something like strlcpy, I'm tempted to say "if the user wants to override the routine, then let them. If they get into any trouble, then that's their problem.". However, I can imagine situations where I might not be so cavalier. Let's say the fooblah() routine works by taking advantage of some internal implementation details of a routine called somestd(). Thus, someone could provide a perfectly 100% correct somestd() routine, and they would still break the fooblah() routine, because fooblah() is "cheating" in how *it* uses somestd(). I guess I'd say that for any routine X(), if X() depends on some undocumented (implementation-specific) details of routine Y(), then we should have a _Y() routine for X() to call. Maybe even call it _libc_internal_Y(), to emphasize why it exists, and why X() is calling that instead if Y(). That is my thinking so far on the big picture. I won't even claim that is my final opinion, as I'm sure I could be swayed by a good counter-argument. However, I'm hoping this will help a little bit, just because I'm talking about a generic rule that would cover any routines of X() and Y(). -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-arch@FreeBSD.ORG Thu May 1 12:10:30 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3048E37B401; Thu, 1 May 2003 12:10:30 -0700 (PDT) Received: from gw.nectar.cc (gw.nectar.cc [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 356AF43F93; Thu, 1 May 2003 12:10:29 -0700 (PDT) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.nectar.cc (Postfix) with ESMTP id A7EB569; Thu, 1 May 2003 14:10:28 -0500 (CDT) Received: by madman.celabo.org (Postfix, from userid 1001) id E47D978C4A; Thu, 1 May 2003 14:10:27 -0500 (CDT) Date: Thu, 1 May 2003 14:10:27 -0500 From: "Jacques A. Vidrine" To: John Baldwin Message-ID: <20030501191027.GA53801@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , John Baldwin , freebsd-arch@FreeBSD.org References: <20030501182820.GA53641@madman.celabo.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.3i-ja.1 cc: freebsd-arch@FreeBSD.org Subject: Re: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2003 19:10:30 -0000 On Thu, May 01, 2003 at 02:45:02PM -0400, John Baldwin wrote: > It seems that many people don't think the symbols in libc need > hiding. What is the reason to prevent a user from overriding the > functions used by libc? malloc() and free() are an example you > agree to, and I don't think we should hide things willy-nilly. > There are many uses for overriding symbols in libc that I'm sure > neither of us have thought of. Why artificially limit it? Nothing prevents one from conciously overriding these parts of libc. I'm merely trying to prevent it from happening accidently. Hiding things willy-nilly is indeed not what we should do. There are several reasonable approaches to determining what to hide. (a) Hide all symbols not explicitly defined in ISO C. (b) Ditto, but raise the bar to POSIX. (c) Hide all symbols, except those that are likely to be candidates to be overridden. malloc/free seem to be the only ones here. The reason that it has been willy-nilly to this point is because we have an imperfect mechanism. Why did I pick on strlcpy/strlcat? Well obviously because of the subtle problem with qpopper, but also because these are functions that are often implemented in portable code, right or wrong that may be. (I would likey not have attempted to hide strcpy if that would have been the issue.) Static linking can make these conflicts become apparent, but if you are dynamic linking --- as is usually the case --- these problems stay dormant until they bite you on the ass. This is dangerous behavior and IMHO we should remove the chance for such accidents where possible. It causes no harm to do so. I have now backed out the strlcpy/strlcat commit. Huh, only now do I notice that NetBSD hid strlcpy/strlcat over a year ago in their tree. :-) Cheers, -- Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal nectar@celabo.org . jvidrine@verio.net . nectar@freebsd.org . nectar@kth.se From owner-freebsd-arch@FreeBSD.ORG Thu May 1 12:19:00 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AAC5A37B401; Thu, 1 May 2003 12:19:00 -0700 (PDT) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 215A043FBD; Thu, 1 May 2003 12:18:59 -0700 (PDT) (envelope-from marcel@xcllnt.net) Received: from athlon.pn.xcllnt.net (athlon.pn.xcllnt.net [192.168.4.3]) by ns1.xcllnt.net (8.12.9/8.12.9) with ESMTP id h41JIwwk064532; Thu, 1 May 2003 12:18:58 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from athlon.pn.xcllnt.net (localhost [127.0.0.1]) by athlon.pn.xcllnt.net (8.12.9/8.12.9) with ESMTP id h41JIwg1000831; Thu, 1 May 2003 12:18:58 -0700 (PDT) (envelope-from marcel@athlon.pn.xcllnt.net) Received: (from marcel@localhost) by athlon.pn.xcllnt.net (8.12.9/8.12.9/Submit) id h41JIwL8000830; Thu, 1 May 2003 12:18:58 -0700 (PDT) Date: Thu, 1 May 2003 12:18:58 -0700 From: Marcel Moolenaar To: "Jacques A. Vidrine" , John Baldwin , freebsd-arch@FreeBSD.org Message-ID: <20030501191858.GA778@athlon.pn.xcllnt.net> References: <20030501182820.GA53641@madman.celabo.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030501182820.GA53641@madman.celabo.org> User-Agent: Mutt/1.5.3i Subject: Re: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2003 19:19:01 -0000 On Thu, May 01, 2003 at 01:28:20PM -0500, Jacques A. Vidrine wrote: > > A lot of folks are focused on qpopper and strlcpy. I believe that > the big picture is being missed. Likely. It would probably be a good idea (IFF we continue the discussion) to have a clear list of problems and/or behavioural changes and possible solutions for any of those problems and/or changes and then discuss the items that are unrelated in seperate discussions. I would also like to promote the behaviour that libc changes constitute ABI breakages unless proven otherwise. Party on Wayne! Party on Garth! -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-arch@FreeBSD.ORG Fri May 2 14:37:50 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2784137B404 for ; Fri, 2 May 2003 14:37:50 -0700 (PDT) Received: from mx.vvo.ru (mx.vvo.ru [212.107.196.82]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4703243FAF for ; Fri, 2 May 2003 14:37:48 -0700 (PDT) (envelope-from kenga@vvo.ru) Received: from [212.107.205.26] by mx.vvo.ru (NTMail 5.06.0014/CM4133.52.28e0adbc) with ESMTP id fgqfcaaa for freebsd-arch@freebsd.org; Sat, 3 May 2003 08:44:47 +1100 From: "PAS Laboratry" To: "" Content-Type: multipart/mixed; boundary="x0x0x0x0x0x0x0x0x0x0x0x0x"; charset="Windows-1251" Date: Sat, 3 May 2003 08:44:47 +1100 Message-Id: <21444734504484@mx.vvo.ru> X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: Need representative X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2003 21:37:50 -0000 --x0x0x0x0x0x0x0x0x0x0x0x0x Content-Type: multipart/related; boundary="letters0x0x0x0x0x0x0x0x0x0x0x0x"; charset="Windows-1251" --letters0x0x0x0x0x0x0x0x0x0x0x0x MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1251" Best for you! We are finding a person who is represent new diagnostic device in the region. The device is based on the theory of Oriental medicine and it is named as PAS - [cid:x97aimage_0.jpg] A new processing principle of Pulse waves on the PC is using by the PAS. The developer has found this principle after 14 years of researches On the Five Elements diagrams that are worked out by the PAS you could see the conditions of the elements (in accordance with TCM) and their activity too. Such diagram is a direct order what to do. For example: 1. To chose the diet (in accordance with Ayrveda), 2. To massage by the any method using active points on the body, 3. To use acupuncture properly. There are many applications in researching herbology, homeopathy and so on. Such wide application of the device demands a well-organized network of distributors and we are ready to support our distributors. OUR discounts reach up to 90%!!! If the dealer sells more than 2000 registration, he/she can have such huge discount (but in one region can be only one such dealer). You can test the PAS and we will return the money if the device is not suitable for you (You pay only delivery fees). Why we think the PAS is useful for many people? It is well known fact that skilled pulse doctor works for many years before he will reach the art of diagnosis. The PAS allows be almost the same professor in three or five weeks. It is revolution of penetration of ancient knowledge to our days. Now many people can receive the correct and fast diagnosis at early stages of illness. We are proud that we do a very useful thing and we are sure, in the nearest future many people will use the PAS. And we are very interested in equal in rights partnership in your region. Please ask the details right now via e-mail [1]tigertel@stl.ru. We will answer in a very short time. The information about PAS you can find at the site: [2]www.tiger-tele.com/pas/english/index.html Best regards, the team of the PAS and the manager Serguei Fedotov. Sorry, if our letter disturbed you. References 1. mailto:tigertel@stl.ru 2. file://localhost/tmp/www.tiger-tele.com/pas/english/index.html --letters0x0x0x0x0x0x0x0x0x0x0x0x-- --x0x0x0x0x0x0x0x0x0x0x0x0x-- From owner-freebsd-arch@FreeBSD.ORG Sat May 3 13:14:14 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5ABFC37B401; Sat, 3 May 2003 13:14:14 -0700 (PDT) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8208D43F93; Sat, 3 May 2003 13:14:13 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.9/8.12.9) with ESMTP id h43KE9m2060452; Sat, 3 May 2003 13:14:13 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.9/8.12.9/Submit) id h43KE9wY060451; Sat, 3 May 2003 13:14:09 -0700 (PDT) Date: Sat, 3 May 2003 13:14:09 -0700 From: "David O'Brien" To: "Jacques A. Vidrine" , freebsd-arch@FreeBSD.org Message-ID: <20030503201409.GA41554@dragon.nuxi.com> References: <20030501182820.GA53641@madman.celabo.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030501182820.GA53641@madman.celabo.org> User-Agent: Mutt/1.4i X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Subject: Re: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: freebsd-alpha@FreeBSD.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2003 20:14:14 -0000 On Thu, May 01, 2003 at 01:28:20PM -0500, Jacques A. Vidrine wrote: > A lot of folks are focused on qpopper and strlcpy. I believe that > the big picture is being missed. I moved this thread to freebsd-arch > so that we could discuss how to hide all (or most, or non-standard) > symbols in libc. Not so that we could argue about this particular > commit. Perhaps you and a contentent of the rest are looking at different pictures. In the our big picture, we don't want this being done to most of libc. > I'm backing out the commit in good faith and in the hopes that the > big picture comes more clearly into focus. Thanks. -- -- David (obrien@FreeBSD.org) From owner-freebsd-arch@FreeBSD.ORG Sat May 3 17:33:00 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5FC8537B401; Sat, 3 May 2003 17:33:00 -0700 (PDT) Received: from beastie.mckusick.com (beastie.mckusick.com [209.31.233.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id D7AF743F85; Sat, 3 May 2003 17:32:59 -0700 (PDT) (envelope-from mckusick@beastie.mckusick.com) Received: from beastie.mckusick.com (localhost [127.0.0.1]) by beastie.mckusick.com (8.12.8/8.12.3) with ESMTP id h440WvTh015707; Sat, 3 May 2003 17:32:58 -0700 (PDT) (envelope-from mckusick@beastie.mckusick.com) Message-Id: <200305040032.h440WvTh015707@beastie.mckusick.com> To: Bruce Evans , Jens Schweikhardt X-URL: http://WWW.McKusick.COM/ Date: Sat, 03 May 2003 17:32:57 -0700 From: Kirk McKusick cc: arch@FreeBSD.org cc: Brian Buhrow Subject: Access times on executables (kern/25777) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Kirk McKusick List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 May 2003 00:33:00 -0000 I was asked to review kern/25777 which points out that FreeBSD at some point stopped updating access times on files being executed which is counter to its earlier behavior and to POSIX. I propose that the fix below be put in to restore this behavior. Those concerned with the overhead of the updates can use the "noatimes" mount option to disable it. Comments? Kirk McKusick =-=-=-=-= Index: sys/kern_exec.c =================================================================== RCS file: /usr/ncvs/src/sys/kern/kern_exec.c,v retrieving revision 1.218 diff -c -r1.218 kern_exec.c *** kern_exec.c 1 Apr 2003 01:26:20 -0000 1.218 --- kern_exec.c 4 May 2003 00:26:00 -0000 *************** *** 598,603 **** --- 598,618 ---- exec_setregs(td, imgp->entry_addr, (u_long)(uintptr_t)stack_base, imgp->ps_strings); + /* + * At this point, it counts as an access. + * Ensure that atime gets updated if needed. + */ + if (!(textvp->v_mount->mnt_flag & MNT_NOATIME)) { + struct vattr vattr; + + VATTR_NULL(&vattr); + vfs_timestamp(&vattr.va_atime); + VOP_LEASE(textvp, td, p->p_ucred, LEASE_WRITE); + vn_lock(textvp, LK_EXCLUSIVE | LK_RETRY, td); + (void) VOP_SETATTR(textvp, &vattr, p->p_ucred, td); + VOP_UNLOCK(textvp, 0, td); + } + done1: /* * Free any resources malloc'd earlier that we didn't use. From owner-freebsd-arch@FreeBSD.ORG Sat May 3 18:42:35 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 49BC737B401; Sat, 3 May 2003 18:42:35 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id B8DE143F93; Sat, 3 May 2003 18:42:33 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id LAA27554; Sun, 4 May 2003 11:42:25 +1000 Date: Sun, 4 May 2003 11:42:24 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Kirk McKusick In-Reply-To: <200305040032.h440WvTh015707@beastie.mckusick.com> Message-ID: <20030504110643.Q1248@gamplex.bde.org> References: <200305040032.h440WvTh015707@beastie.mckusick.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@FreeBSD.org cc: Brian Buhrow cc: Jens Schweikhardt Subject: Re: Access times on executables (kern/25777) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 May 2003 01:42:35 -0000 On Sat, 3 May 2003, Kirk McKusick wrote: > I was asked to review kern/25777 which points out that FreeBSD at > some point stopped updating access times on files being executed > which is counter to its earlier behavior and to POSIX. I propose > that the fix below be put in to restore this behavior. Those > concerned with the overhead of the updates can use the "noatimes" > mount option to disable it. Comments? > Index: sys/kern_exec.c > =================================================================== > RCS file: /usr/ncvs/src/sys/kern/kern_exec.c,v > retrieving revision 1.218 > diff -c -r1.218 kern_exec.c > *** kern_exec.c 1 Apr 2003 01:26:20 -0000 1.218 > --- kern_exec.c 4 May 2003 00:26:00 -0000 > *************** > *** 598,603 **** > --- 598,618 ---- > exec_setregs(td, imgp->entry_addr, > (u_long)(uintptr_t)stack_base, imgp->ps_strings); > > + /* > + * At this point, it counts as an access. > + * Ensure that atime gets updated if needed. > + */ > + if (!(textvp->v_mount->mnt_flag & MNT_NOATIME)) { > + struct vattr vattr; > + > + VATTR_NULL(&vattr); > + vfs_timestamp(&vattr.va_atime); > + VOP_LEASE(textvp, td, p->p_ucred, LEASE_WRITE); > + vn_lock(textvp, LK_EXCLUSIVE | LK_RETRY, td); > + (void) VOP_SETATTR(textvp, &vattr, p->p_ucred, td); > + VOP_UNLOCK(textvp, 0, td); > + } > + > done1: > /* > * Free any resources malloc'd earlier that we didn't use. > This doesn't work unless the user has permission to change the atime using utimes(2) with a non-NULL times pointer. My version of it has a VA_EXECVE_ATIME flag which tells VOP_SETATTR() to bypass the permissions checks. I only implemented checking this flag for ufs. Another problem with setting the atime like utimes() would instead of like read() would is that utimes() is required to update the times immediately, so VOP_SETATTR() does this, but updates for read() are normally optimized to just set a flag. The difference is not large for ufs since the UFS_UPDATE() call in ufs_setattr() doesn't wait. The VA_EXECVE_ATIME flag could be used to optimize this, but I didn't try this. The overhead for setting atimes on exec only seemed to be large for nfs. This was before nfs had an attribute cache, and I think it is unavoidable for utimes()-like updates. On one of my systems now, futimes() takes about 12.5 times longer than reading 1 byte from a file on an nfs-mounted file system with the server's file system mounted -async (239 usec versus 19 usec averaged over for 10^4 futimes()s and 10^6 read()s). Bruce