From owner-freebsd-arch Sun Jul 8 1:31:14 2001 Delivered-To: freebsd-arch@freebsd.org Received: from bazooka.unixfreak.org (bazooka.unixfreak.org [63.198.170.138]) by hub.freebsd.org (Postfix) with ESMTP id 27BDA37B406 for ; Sun, 8 Jul 2001 01:31:10 -0700 (PDT) (envelope-from dima@unixfreak.org) Received: from hornet.unixfreak.org (hornet [63.198.170.140]) by bazooka.unixfreak.org (Postfix) with ESMTP id 07E883E28; Sun, 8 Jul 2001 01:31:06 -0700 (PDT) To: David Malone Cc: arch@freebsd.org Subject: Re: Peer credentials on a Unix domain socket In-Reply-To: <200107041056.aa84171@salmon.maths.tcd.ie>; from dwmalone@maths.tcd.ie on "Wed, 04 Jul 2001 10:56:02 +0100" Date: Sun, 08 Jul 2001 01:31:05 -0700 From: Dima Dorfman Message-Id: <20010708083106.07E883E28@bazooka.unixfreak.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG David Malone writes: > > Here's one example use: http://www.superscript.com/ucspi-ipc/intro.html. > > This author actually provides patches for *BSD to implement getpeereid(), > > and I believe--although I haven't checked--that OpenBSD just took his > > patch. (And as I said before, I really think a system call is overdoing it > > for something like this, esp. when there's already a nice socket option > > interface.) > > Interesting - I guess this is a little like the inetd unix domain > socket stuff, only it sets some extra environment variables. I > guess it would make sense to have inetd set these variables too. > > I see some mention of SO_PEERCRED for Linux - we should probably > find out what was done here and impliment something compatable? I looked at what Linux does today (via code inspection only; I don't have spare hardware for a Linux box). Essentially it's what I implemented; the SO_PEERCRED socket option transfers the pid, uid, and gid to the peer. The credentials are set on connect(2) *and* listen(2); this means that both sides can get each other's credentials. I didn't implement this, but it might be nice. > (Least we be accused of suffering from NIH). We could then also > impliment getpeercred in terms of this It's getpeereid, and it's quite trivial. > and impliment the BSDI socket > option. This shouldn't be very hard, either. > That should cover most bases. > > > > Do we know the intended uses of any of other options which > > > people have implimented? > > > AFAIK, they aren't using it (read: I haven't seen any commit logs that > > suggest they're using it, although OpenBSD's commit logs are > > notoriously terse), and I don't know what their intented uses are. > > I'll try grepping for it in the OpenBSD CVS tree and see. I grep'd a day ago; they're not using it. So, I think the best course of action is to (1) extend my implementation to work for the connect(2) caller as well (i.e., allow the client to verify the server's credentials), (2) implement getpeereid, and (3) add the LOCAL_CREDS option (note that NetBSD has this, too). I'll do (1) and (2) in a day or so; would you like to do (3), or shall I? As an aside, any ETA on those af_unix fixes you mentioned? Thanks, Dima Dorfman dima@unixfreak.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 8 1:46:11 2001 Delivered-To: freebsd-arch@freebsd.org Received: from london.physics.purdue.edu (london.physics.purdue.edu [128.210.67.35]) by hub.freebsd.org (Postfix) with ESMTP id C4BAA37B401; Sun, 8 Jul 2001 01:46:04 -0700 (PDT) (envelope-from will@physics.purdue.edu) Received: from bohr.physics.purdue.edu (bohr.physics.purdue.edu [128.210.67.12]) by london.physics.purdue.edu (8.8.8/8.8.8) with ESMTP id DAA28014; Sun, 8 Jul 2001 03:20:01 -0500 (EST) Received: by bohr.physics.purdue.edu (Postfix, from userid 12409) id 6681C5BB5; Sun, 8 Jul 2001 03:20:02 -0500 (EST) Date: Sun, 8 Jul 2001 03:20:02 -0500 From: Will Andrews To: Jason Evans Cc: Dag-Erling Smorgrav , Bill Fenner , arch@FreeBSD.org Subject: Re: nvi maintainer? Message-ID: <20010708032002.D97456@bohr.physics.purdue.edu> Reply-To: Will Andrews Mail-Followup-To: Jason Evans , Dag-Erling Smorgrav , Bill Fenner , arch@FreeBSD.org References: <200107072203.PAA09299@windsor.research.att.com> <20010708005155.J8775@canonware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: <20010708005155.J8775@canonware.com>; from jasone@canonware.com on Sun, Jul 08, 2001 at 12:51:55AM -0700 X-Operating-System: FreeBSD 4.3-STABLE i386 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG [ moving from developers@ to arch@ ] On Sun, Jul 08, 2001 at 12:51:55AM -0700, Jason Evans (jasone@canonware.com) wrote: > This unfortunately means that FreeBSD will not be able to use the next > release of nvi as part of the base system. In other words, we're going to > have to fork nvi. Yuck. OR... import Vim and get rid of nvi? :-) http://www.vim.org/ --- COPYING Vim is Charityware. You can use and copy it as much as you like, but you are encouraged to make a donation to orphans in Uganda. Please read the file "doc/uganda.txt" for details. There are no restrictions on distributing an unmodified copy of Vim. Parts of Vim may also be distributed, but this text must always be included. You are allowed to include executables that you made from the unmodified Vim sources, your own usage examples and Vim scripts. If you distribute a modified version of Vim, you are encouraged to send the maintainer a copy, including the source code. Or make it available to the maintainer through ftp; let him know where it can be found. If the number of changes is small (e.g., a modified Makefile) e-mailing the diffs will do. When the maintainer asks for it (in any way) you must make your changes, including source code, available to him. The maintainer reserves the right to include any changes in the official version of Vim. This is negotiable. You are not allowed to distribute a modified version of Vim when you are not willing to make the source code available to the maintainer. The current maintainer is Bram Moolenaar . If this changes, it will be announced in appropriate places (most likely www.vim.org and comp.editors). When it is completely impossible to contact the maintainer, the obligation to send him modified source code ceases. It is not allowed to remove these restrictions from the distribution of the Vim sources or parts of it. These restrictions may also be used for previous Vim releases instead of the text that was included with it. --- What do you say? 8) -- wca To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 8 2:37:48 2001 Delivered-To: freebsd-arch@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [65.0.135.147]) by hub.freebsd.org (Postfix) with ESMTP id 242D137B403 for ; Sun, 8 Jul 2001 02:37:46 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f689bkM77362 for ; Sun, 8 Jul 2001 02:37:46 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id DB2303811; Sun, 8 Jul 2001 02:37:45 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Will Andrews Cc: Jason Evans , Dag-Erling Smorgrav , Bill Fenner , arch@FreeBSD.ORG Subject: Re: nvi maintainer? In-Reply-To: <20010708032002.D97456@bohr.physics.purdue.edu> Date: Sun, 08 Jul 2001 02:37:45 -0700 From: Peter Wemm Message-Id: <20010708093745.DB2303811@overcee.netplex.com.au> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Will Andrews wrote: > [ moving from developers@ to arch@ ] > > On Sun, Jul 08, 2001 at 12:51:55AM -0700, Jason Evans (jasone@canonware.com) wrote: > > This unfortunately means that FreeBSD will not be able to use the next > > release of nvi as part of the base system. In other words, we're going to > > have to fork nvi. Yuck. > > OR... import Vim and get rid of nvi? :-) > > http://www.vim.org/ > What do you say? 8) I'm beginning to wonder.. The real question is whether it is a faithful enough drop-in replacement for nvi. I'll alias it on some of my machines and see if it bites me or not. The next thing is that moving a port to the base system usually has a pretty chilling effect on the package.. Is that going to OK with regular vim users who are used to having a dynamic, regularly updated port? Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 8 3:26:35 2001 Delivered-To: freebsd-arch@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id 6CF4937B406 for ; Sun, 8 Jul 2001 03:26:31 -0700 (PDT) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 8 Jul 2001 11:26:30 +0100 (BST) To: Dima Dorfman Cc: arch@freebsd.org Subject: Re: Peer credentials on a Unix domain socket In-reply-to: Your message of "Sun, 08 Jul 2001 01:31:05 PDT." <20010708083106.07E883E28@bazooka.unixfreak.org> X-Request-Do: Date: Sun, 08 Jul 2001 11:26:30 +0100 From: David Malone Message-ID: <200107081126.aa31994@salmon.maths.tcd.ie> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > So, I think the best course of action is to (1) extend my > implementation to work for the connect(2) caller as well (i.e., allow > the client to verify the server's credentials), (2) implement > getpeereid, and (3) add the LOCAL_CREDS option (note that NetBSD has > this, too). I'll do (1) and (2) in a day or so; would you like to do > (3), or shall I? I'll have a go at 3 - it probably fits into the stuff I've been working on more obviously. > As an aside, any ETA on those af_unix fixes you mentioned? Hopefully I'll have something by the end of the day. I have some corrections to do on a paper and I plan on working on it once I've finished those. David. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 8 7:30:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id B410E37B401 for ; Sun, 8 Jul 2001 07:30:17 -0700 (PDT) (envelope-from Cy.Schubert@uumail.gov.bc.ca) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id HAA11222; Sun, 8 Jul 2001 07:28:39 -0700 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda11220; Sun Jul 8 07:28:35 2001 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.4/8.9.1) id f68ESJ502891; Sun, 8 Jul 2001 07:28:19 -0700 (PDT) Received: from UNKNOWN(10.1.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdzy2885; Sun Jul 8 07:27:47 2001 Received: (from uucp@localhost) by cwsys.cwsent.com (8.11.4/8.9.1) id f68ER8P03582; Sun, 8 Jul 2001 07:27:08 -0700 (PDT) Message-Id: <200107081427.f68ER8P03582@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdeR3573; Sun Jul 8 07:26:18 2001 X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-Sender: schubert To: Peter Wemm Cc: Will Andrews , Jason Evans , Dag-Erling Smorgrav , Bill Fenner , arch@FreeBSD.ORG Subject: Re: nvi maintainer? In-reply-to: Your message of "Sun, 08 Jul 2001 02:37:45 PDT." <20010708093745.DB2303811@overcee.netplex.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 08 Jul 2001 07:26:18 -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20010708093745.DB2303811@overcee.netplex.com.au>, Peter Wemm writes : > Will Andrews wrote: > > [ moving from developers@ to arch@ ] > > > > On Sun, Jul 08, 2001 at 12:51:55AM -0700, Jason Evans (jasone@canonware.com > ) > wrote: > > > This unfortunately means that FreeBSD will not be able to use the next > > > release of nvi as part of the base system. In other words, we're going t > o > > > have to fork nvi. Yuck. > > > > OR... import Vim and get rid of nvi? :-) > > > > http://www.vim.org/ > > > What do you say? 8) > > I'm beginning to wonder.. The real question is whether it is a faithful > enough drop-in replacement for nvi. I'll alias it on some of my machines > and see if it bites me or not. > > The next thing is that moving a port to the base system usually has a > pretty chilling effect on the package.. Is that going to OK with regular > vim users who are used to having a dynamic, regularly updated port? At one time I had replaced vi (renamed vi and symlinked vim in its place) on a few FreeBSD, Solaris, and DEC UNIX systems. There was one feature of vim that confused me and another that I did not care about. Sometimes when I edit a file I might make a change then compare the change with what was before, using the undo ("u") function as a toggle between old and new. I suppose I could have used undo and redo under vim, however with many other systems I was maintaining at the time still using the vendor's original vi, of which I could not replace because of customers, retraining myself to instinctively use one approach on one set of systems and another on another set of systems caused some confusion, as I'd have to stop and think, "which system was I on?" My solution, set undolevels=0 Setting undolevels=0 causes vim to have the same undo/redo behaviour as vendor vi and nvi. Vim creates a backup file when saving edits to a file. The disks on those systems with vim installed had backup copies peppered everywhere within the filesystems of those systems that had it installed. One solution was to create a cron job to delete the backup files after a predetermined number of days. The solution I finally used was, set nobackup Other than the above two complaints I found that vim was the same as vendor vi and nvi. If you're looking for a faithful enough replacement for nvi, I suppose undolevels=0 and nobackup could be the default behaviour under FreeBSD. What about PicoBSD and small embedded applications of FreeBSD? -r-xr-xr-x 6 root wheel 283300 Jun 7 09:39 /usr/bin/vi -rwxr-xr-x 1 root wheel 1016184 May 28 08:16 /usr/local/bin/vim On RH 7.1 vim without the GUI is, -rwxr-xr-x 1 root root 377404 Apr 2 06:24 /bin/vi Lately I've been using gvim (the GUI vim). It has the advantage of being able to cut and paste files, like syslog.conf that have tab characters, into Xterm sessions with tab characters intact, e.g. not expanded to spaces. If we do go ahead and replace nvi with vim, whomever does the work, please include gvim in the base distribution. I would hate to have vim in the base system only to install the vim port just to get gvim. (Of course this is a major cause of the bloat I complained about above -- a make.conf option maybe?) :/ You also raise a good point about packages being chilled in the base system. I've upgraded packages in the base system, when I've needed the upgrade before FreeBSD has had it available by replacing whatever is in /usr/src/contrib with the new package, in the past namely, amd, bind, cvs, ipfilter, isc-dhcp, and sendmail. Usually its just a drop in replacement and rebuild the various bits and pieces, and occasionally a minor patch to a makefile or two or a buildworld. For those who cannot wait, this approach is definitely an option. Alternatively have no vi or vim in the base system at all. Sysinstall could make it mandatory to install one of the vim packages for you while buildworld could build vim in ports. (OK, it's an off the wall idea but hey, it's an option). > > Cheers, > -Peter > -- > Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au > "All of this is for nothing if we don't go to the stars" - JMS/B5 Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/Alpha Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 8 7:35:50 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 1995D37B401 for ; Sun, 8 Jul 2001 07:35:47 -0700 (PDT) (envelope-from des@ofug.org) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id QAA52009; Sun, 8 Jul 2001 16:34:52 +0200 (CEST) (envelope-from des@ofug.org) 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: Cy Schubert - ITSD Open Systems Group Cc: Peter Wemm , Will Andrews , Jason Evans , Bill Fenner , arch@FreeBSD.ORG Subject: Re: nvi maintainer? References: <200107081427.f68ER8P03582@cwsys.cwsent.com> From: Dag-Erling Smorgrav Date: 08 Jul 2001 16:34:52 +0200 In-Reply-To: <200107081427.f68ER8P03582@cwsys.cwsent.com> Message-ID: Lines: 10 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Cy Schubert - ITSD Open Systems Group writes: > Setting undolevels=0 causes vim to have the same undo/redo behaviour as > vendor vi and nvi. Nope, nvi has multiple undo levels (not sure how many), press '.' after pressing 'u' to undo additional levels. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 8 8:28:58 2001 Delivered-To: freebsd-arch@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id D267337B407 for ; Sun, 8 Jul 2001 08:28:52 -0700 (PDT) (envelope-from Cy.Schubert@uumail.gov.bc.ca) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id IAA11467; Sun, 8 Jul 2001 08:27:21 -0700 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda11462; Sun Jul 8 08:27:05 2001 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.4/8.9.1) id f68FR0Q03325; Sun, 8 Jul 2001 08:27:00 -0700 (PDT) Received: from UNKNOWN(10.1.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdNH3318; Sun Jul 8 08:26:10 2001 Received: (from uucp@localhost) by cwsys.cwsent.com (8.11.4/8.9.1) id f68FQ9203949; Sun, 8 Jul 2001 08:26:09 -0700 (PDT) Message-Id: <200107081526.f68FQ9203949@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdVw3938; Sun Jul 8 08:25:35 2001 X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-Sender: schubert To: Will Andrews , Jason Evans Cc: Dag-Erling Smorgrav , Bill Fenner , arch@FreeBSD.ORG Subject: Re: nvi maintainer? In-reply-to: Your message of "Sun, 08 Jul 2001 03:20:02 CDT." <20010708032002.D97456@bohr.physics.purdue.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 08 Jul 2001 08:25:35 -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20010708032002.D97456@bohr.physics.purdue.edu>, Will Andrews writes : > [ moving from developers@ to arch@ ] > > On Sun, Jul 08, 2001 at 12:51:55AM -0700, Jason Evans (jasone@canonware.com) > wrote: > > This unfortunately means that FreeBSD will not be able to use the next > > release of nvi as part of the base system. In other words, we're going to > > have to fork nvi. Yuck. > > OR... import Vim and get rid of nvi? :-) > > http://www.vim.org/ Obviously some change in license terms prompted this. Would you mind posting the URL or comment that initiated this thread on -developers? Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/Alpha Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 8 8:29: 1 2001 Delivered-To: freebsd-arch@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id 5357437B406 for ; Sun, 8 Jul 2001 08:28:53 -0700 (PDT) (envelope-from Cy.Schubert@uumail.gov.bc.ca) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id IAA11468; Sun, 8 Jul 2001 08:27:21 -0700 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda11463; Sun Jul 8 08:27:06 2001 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.4/8.9.1) id f68FR1S03329; Sun, 8 Jul 2001 08:27:01 -0700 (PDT) Received: from UNKNOWN(10.1.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdTQ3319; Sun Jul 8 08:26:11 2001 Received: (from uucp@localhost) by cwsys.cwsent.com (8.11.4/8.9.1) id f68FQAU03953; Sun, 8 Jul 2001 08:26:10 -0700 (PDT) Message-Id: <200107081526.f68FQAU03953@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdaD3944; Sun Jul 8 08:25:58 2001 X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-Sender: schubert To: Dag-Erling Smorgrav Cc: Cy Schubert - ITSD Open Systems Group , Peter Wemm , Will Andrews , Jason Evans , Bill Fenner , arch@FreeBSD.ORG Subject: Re: nvi maintainer? In-reply-to: Your message of "08 Jul 2001 16:34:52 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 08 Jul 2001 08:25:58 -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message , Dag-Erling Smorgrav writes: > Cy Schubert - ITSD Open Systems Group writes: > > Setting undolevels=0 causes vim to have the same undo/redo behaviour as > > vendor vi and nvi. > > Nope, nvi has multiple undo levels (not sure how many), press '.' > after pressing 'u' to undo additional levels. Cool. It supports multiple undo levels without breaking compatibility with vendor vi. This is like having my cake and eating it too. Vim and vendor vi repeat the last non-undo command. In this regard vim is compatible with vendor vi while nvi by default is not, which IMO is a bug in the original (and vendor) vi, but then who am I to say? After a little research, nvi can be fully vendor vi and vim compatible (IMO buggy) in this regard using the "set edcompatible" command. It's amazing how much a person can learn just by subscribing to these lists. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/Alpha Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 8 8:32:43 2001 Delivered-To: freebsd-arch@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id C847037B401 for ; Sun, 8 Jul 2001 08:32:40 -0700 (PDT) (envelope-from gibbs@scsiguy.com) Received: from scsiguy.com (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.2/8.9.3) with ESMTP id f68FVfU90366; Sun, 8 Jul 2001 09:31:41 -0600 (MDT) (envelope-from gibbs@scsiguy.com) Message-Id: <200107081531.f68FVfU90366@aslan.scsiguy.com> To: Dag-Erling Smorgrav Cc: Cy Schubert - ITSD Open Systems Group , Peter Wemm , Will Andrews , Jason Evans , Bill Fenner , arch@FreeBSD.ORG Subject: Re: nvi maintainer? In-Reply-To: Your message of "08 Jul 2001 16:34:52 +0200." Date: Sun, 08 Jul 2001 09:31:41 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG >Cy Schubert - ITSD Open Systems Group writes: >> Setting undolevels=0 causes vim to have the same undo/redo behaviour as >> vendor vi and nvi. > >Nope, nvi has multiple undo levels (not sure how many), press '.' >after pressing 'u' to undo additional levels. I'm forced to use VIM under Linux and personally think that VIM just doesn't cut it. :split instead of :E, the funky undo behavior, the format of the status line, etc, etc. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 8 8:38:51 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 9C6AA37B401 for ; Sun, 8 Jul 2001 08:38:48 -0700 (PDT) (envelope-from des@ofug.org) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id RAA52328; Sun, 8 Jul 2001 17:37:55 +0200 (CEST) (envelope-from des@ofug.org) 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: Cy Schubert - ITSD Open Systems Group Cc: Will Andrews , Jason Evans , Bill Fenner , arch@FreeBSD.ORG Subject: Re: nvi maintainer? References: <200107081526.f68FQ9203949@cwsys.cwsent.com> From: Dag-Erling Smorgrav Date: 08 Jul 2001 17:37:54 +0200 In-Reply-To: <200107081526.f68FQ9203949@cwsys.cwsent.com> Message-ID: Lines: 11 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Cy Schubert - ITSD Open Systems Group writes: > Obviously some change in license terms prompted this. Would you mind > posting the URL or comment that initiated this thread on -developers? To summarize, the next release of nvi will require SleepyCat DB3, which is not backwards compatible with DB1 or DB2, and may not be redistributed for a fee. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 8 9: 9:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id 18CDA37B405 for ; Sun, 8 Jul 2001 09:09:21 -0700 (PDT) (envelope-from Cy.Schubert@uumail.gov.bc.ca) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id JAA11632; Sun, 8 Jul 2001 09:07:42 -0700 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda11630; Sun Jul 8 09:07:30 2001 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.4/8.9.1) id f68G7PG03617; Sun, 8 Jul 2001 09:07:25 -0700 (PDT) Received: from UNKNOWN(10.1.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdpu3615; Sun Jul 8 09:07:13 2001 Received: (from uucp@localhost) by cwsys.cwsent.com (8.11.4/8.9.1) id f68G7Cw04170; Sun, 8 Jul 2001 09:07:12 -0700 (PDT) Message-Id: <200107081607.f68G7Cw04170@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdMX4164; Sun Jul 8 09:06:46 2001 X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-Sender: schubert To: "Justin T. Gibbs" Cc: Dag-Erling Smorgrav , Cy Schubert - ITSD Open Systems Group , Peter Wemm , Will Andrews , Jason Evans , Bill Fenner , arch@FreeBSD.ORG Subject: Re: nvi maintainer? In-reply-to: Your message of "Sun, 08 Jul 2001 09:31:41 MDT." <200107081531.f68FVfU90366@aslan.scsiguy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 08 Jul 2001 09:06:46 -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <200107081531.f68FVfU90366@aslan.scsiguy.com>, "Justin T. Gibbs" wri tes: > >Cy Schubert - ITSD Open Systems Group writes: > >> Setting undolevels=0 causes vim to have the same undo/redo behaviour as > >> vendor vi and nvi. > > > >Nope, nvi has multiple undo levels (not sure how many), press '.' > >after pressing 'u' to undo additional levels. > > I'm forced to use VIM under Linux and personally think that VIM > just doesn't cut it. :split instead of :E, the funky undo behavior, > the format of the status line, etc, etc. I'd be just as happy if we forked our copy of nvi, now that I've learned how to use the funky new (to myself) undo behaviour. For that matter this affects all of the *BSD's. Could we just collaborate with NetBSD and OpenBSD to maintain a single version of nvi or an unencumbered version of DB3 across the *BSD's? I'm sure the other BSD projects are considering their options too. OpenSSH is a good example of this. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/Alpha Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 8 9: 9:56 2001 Delivered-To: freebsd-arch@freebsd.org Received: from scientia.demon.co.uk (scientia.demon.co.uk [212.228.14.13]) by hub.freebsd.org (Postfix) with ESMTP id 010E637B401 for ; Sun, 8 Jul 2001 09:09:54 -0700 (PDT) (envelope-from ben@FreeBSD.org) Received: from strontium.shef.vinosystems.com ([192.168.91.36] ident=root) by scientia.demon.co.uk with esmtp (Exim 3.30 #1) id 15JH7z-000Oh5-00; Sun, 08 Jul 2001 17:09:47 +0100 Received: (from ben@localhost) by strontium.shef.vinosystems.com (8.11.4/8.11.4) id f68G9ll28965; Sun, 8 Jul 2001 17:09:47 +0100 (BST) (envelope-from ben@FreeBSD.org) X-Authentication-Warning: strontium.shef.vinosystems.com: ben set sender to ben@FreeBSD.org using -f Date: Sun, 8 Jul 2001 17:09:47 +0100 From: Ben Smithurst To: Peter Wemm Cc: Will Andrews , Jason Evans , Dag-Erling Smorgrav , Bill Fenner , arch@FreeBSD.ORG Subject: Re: nvi maintainer? Message-ID: <20010708170947.G289@strontium.shef.vinosystems.com> References: <20010708032002.D97456@bohr.physics.purdue.edu> <20010708093745.DB2303811@overcee.netplex.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010708093745.DB2303811@overcee.netplex.com.au> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Peter Wemm wrote: > I'm beginning to wonder.. The real question is whether it is a faithful > enough drop-in replacement for nvi. I'll alias it on some of my machines > and see if it bites me or not. Here's one thing that annoys me: $ crontab -e crontab: temp file must be edited in place the solut^W kludge I use (EDITOR=nvi crontab -e) is easier than finding out how to configure Vim to avoid this, but I'm sure there's a way. -- Ben Smithurst / ben@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 8 9:11:49 2001 Delivered-To: freebsd-arch@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [64.0.106.45]) by hub.freebsd.org (Postfix) with ESMTP id 35F1737B406 for ; Sun, 8 Jul 2001 09:11:46 -0700 (PDT) (envelope-from scanner@jurai.net) Received: from localhost (scanner@localhost) by sasami.jurai.net (8.9.3/8.8.7) with ESMTP id MAA00658; Sun, 8 Jul 2001 12:10:19 -0400 (EDT) Date: Sun, 8 Jul 2001 12:10:19 -0400 (EDT) From: To: Dag-Erling Smorgrav Cc: Cy Schubert - ITSD Open Systems Group , Will Andrews , Jason Evans , Bill Fenner , arch@FreeBSD.ORG Subject: Re: nvi maintainer? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > To summarize, the next release of nvi will require SleepyCat DB3, > which is not backwards compatible with DB1 or DB2, and may not be > redistributed for a fee. Considering who the authors are someone might be able to get a copy of DB3 under a BSDL to be imported. As for compatability... thats another story. ============================================================================= -Chris Watson (316) 326-3862 | Sr. Unix Administrator Work: chris.watson@twa.com | Trans World Airlines, Kansas City, MO Home: scanner@jurai.net | http://www.twa.com ============================================================================= WINDOWS: "Where do you want to go today?" LINUX: "Where do you want to go tomorrow?" BSD: "Are you guys coming or what?" ============================================================================= irc.openprojects.net #FreeBSD -Join the revolution! ICQ: 20016186 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 8 12:57: 9 2001 Delivered-To: freebsd-arch@freebsd.org Received: from shell.futuresouth.com (shell.futuresouth.com [198.78.58.28]) by hub.freebsd.org (Postfix) with ESMTP id 9F2C137B401 for ; Sun, 8 Jul 2001 12:57:06 -0700 (PDT) (envelope-from fullermd@futuresouth.com) Received: (from fullermd@localhost) by shell.futuresouth.com (8.11.1/8.11.1) id f68JudS02714; Sun, 8 Jul 2001 14:56:39 -0500 (CDT) Date: Sun, 8 Jul 2001 14:56:39 -0500 From: "Matthew D. Fuller" To: Peter Wemm Cc: Will Andrews , Jason Evans , Dag-Erling Smorgrav , Bill Fenner , arch@FreeBSD.ORG Subject: Re: nvi maintainer? Message-ID: <20010708145639.G10713@futuresouth.com> References: <20010708032002.D97456@bohr.physics.purdue.edu> <20010708093745.DB2303811@overcee.netplex.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010708093745.DB2303811@overcee.netplex.com.au>; from peter@wemm.org on Sun, Jul 08, 2001 at 02:37:45AM -0700 X-OS: FreeBSD Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Jul 08, 2001 at 02:37:45AM -0700, a little birdie told me that Peter Wemm remarked > > I'm beginning to wonder.. The real question is whether it is a faithful > enough drop-in replacement for nvi. I'll alias it on some of my machines > and see if it bites me or not. > > The next thing is that moving a port to the base system usually has a > pretty chilling effect on the package.. Is that going to OK with regular > vim users who are used to having a dynamic, regularly updated port? FWIW, vim on various Linux boxes has puked many times in the past on my rather basic .exrc (last line edited for readability): set tabstop=4 set shiftwidth=4 set wraplen=73 set ai set ruler map ^R !}fmt 71 wraplen, as I recall didn't work right, and I think one or two other parts failed. I never did figure out how to set the wrap width. And don't even get me started on the damn syntax highlighting... watch the whole screen change color/darkness as I write a printf() depending on when the ()'s, ""'s, etc., are open. *shudder* -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Unix Systems Administrator | fullermd@futuresouth.com Specializing in FreeBSD | http://www.over-yonder.net/ "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 8 14:54:45 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id D711637B401 for ; Sun, 8 Jul 2001 14:54:41 -0700 (PDT) (envelope-from des@ofug.org) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id XAA53856; Sun, 8 Jul 2001 23:54:40 +0200 (CEST) (envelope-from des@ofug.org) 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: arch@freebsd.org Subject: Type differences From: Dag-Erling Smorgrav Date: 08 Jul 2001 23:54:40 +0200 Message-ID: Lines: 23 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG des@des /usr/src/sys% grep 'define.*BSD_SIZE_T' {i386,alpha}/include/ansi.h i386/include/ansi.h:#define _BSD_SIZE_T_ unsigned int /* sizeof() */ alpha/include/ansi.h:#define _BSD_SIZE_T_ unsigned long /* sizeof() */ des@des /usr/src/sys% grep 'define.*BSD_OFF_T' {i386,alpha}/include/ansi.h i386/include/ansi.h:#define _BSD_OFF_T_ __int64_t /* file offset */ alpha/include/ansi.h:#define _BSD_OFF_T_ long /* file offset */ What's the idea here? off_t is the exact same size and signedness on both platforms, so why not use the same definition for both? And why make size_t an int on i386 but a long on alpha, when on both these platforms int and long are identical? Also, gcc (correctly) complains about a "comparison between signed and unsigned" when you try to compare a size_t to an off_t on alpha - but doesn't complain on i386. What gives? And while we're on this subject, what's the Officially Approved way of printf()ing an off_t or a size_t so it does not generate warnings on either platform? DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 8 16:51:15 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 2E7A237B401 for ; Sun, 8 Jul 2001 16:51:12 -0700 (PDT) (envelope-from des@ofug.org) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id BAA54334; Mon, 9 Jul 2001 01:51:10 +0200 (CEST) (envelope-from des@ofug.org) 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: arch@FreeBSD.ORG Subject: Re: Type differences References: From: Dag-Erling Smorgrav Date: 09 Jul 2001 01:51:10 +0200 In-Reply-To: Message-ID: Lines: 13 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Dag-Erling Smorgrav writes: > What's the idea here? off_t is the exact same size and signedness on > both platforms, so why not use the same definition for both? And why > make size_t an int on i386 but a long on alpha, when on both these > platforms int and long are identical? Umm, diregard the size_t bit - I thought the Alpha was ILP64, but it's I32LP64. It would still be possible to change size_t to unsigned long on the i386, though. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 8 17:30:27 2001 Delivered-To: freebsd-arch@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [65.0.135.147]) by hub.freebsd.org (Postfix) with ESMTP id 01FD037B401 for ; Sun, 8 Jul 2001 17:30:25 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f690UOM79576 for ; Sun, 8 Jul 2001 17:30:24 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id CD99C3811; Sun, 8 Jul 2001 17:30:24 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Dag-Erling Smorgrav Cc: arch@FreeBSD.ORG Subject: Re: Type differences In-Reply-To: Date: Sun, 08 Jul 2001 17:30:24 -0700 From: Peter Wemm Message-Id: <20010709003024.CD99C3811@overcee.netplex.com.au> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Dag-Erling Smorgrav wrote: > Dag-Erling Smorgrav writes: > > What's the idea here? off_t is the exact same size and signedness on > > both platforms, so why not use the same definition for both? And why > > make size_t an int on i386 but a long on alpha, when on both these > > platforms int and long are identical? > > Umm, diregard the size_t bit - I thought the Alpha was ILP64, but it's > I32LP64. It would still be possible to change size_t to unsigned long > on the i386, though. And remember that i386 can be compiled fir IP32L64 so that long == 64 bit. Our i386 definitions have token support for that.. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 8 19:11:39 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id C481437B405 for ; Sun, 8 Jul 2001 19:11:35 -0700 (PDT) (envelope-from des@ofug.org) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id EAA55033; Mon, 9 Jul 2001 04:11:34 +0200 (CEST) (envelope-from des@ofug.org) 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: arch@freebsd.org Subject: -fno-builtin From: Dag-Erling Smorgrav Date: 09 Jul 2001 04:11:34 +0200 Message-ID: Lines: 9 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --=-=-= I'd like to commit the attached patch, which adds -fno-builtin to CFLAGS when WARNS is set. Any objections? DES -- Dag-Erling Smorgrav - des@ofug.org --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=builtin.diff Index: bsd.sys.mk =================================================================== RCS file: /home/ncvs/src/share/mk/bsd.sys.mk,v retrieving revision 1.3 diff -u -r1.3 bsd.sys.mk --- bsd.sys.mk 2001/05/19 23:32:19 1.3 +++ bsd.sys.mk 2001/07/09 02:01:57 @@ -12,7 +12,7 @@ CFLAGS += -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith # XXX Delete -Wuninitialized by default for now -- the compiler doesn't # XXX always get it right. -CFLAGS += -Wno-uninitialized +CFLAGS += -Wno-uninitialized -fno-builtin . if !defined(NO_WERROR) CFLAGS += -Werror . endif --=-=-=-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 8 20:13:34 2001 Delivered-To: freebsd-arch@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id C276A37B403 for ; Sun, 8 Jul 2001 20:13:32 -0700 (PDT) (envelope-from obrien@nuxi.ucdavis.edu) Received: from dragon.nuxi.com (root@trang.nuxi.com [206.40.252.115]) by relay.nuxi.com (8.11.2/8.11.2) with ESMTP id f693DVR25114; Sun, 8 Jul 2001 20:13:31 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f693DUY85354; Sun, 8 Jul 2001 20:13:30 -0700 (PDT) (envelope-from obrien) Date: Sun, 8 Jul 2001 20:13:29 -0700 From: "David O'Brien" To: Jason Evans , Dag-Erling Smorgrav , Bill Fenner , arch@FreeBSD.org Subject: Re: nvi maintainer? Message-ID: <20010708201329.A85258@dragon.nuxi.com> Reply-To: obrien@FreeBSD.org References: <200107072203.PAA09299@windsor.research.att.com> <20010708005155.J8775@canonware.com> <20010708032002.D97456@bohr.physics.purdue.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010708032002.D97456@bohr.physics.purdue.edu>; from will@physics.purdue.edu on Sun, Jul 08, 2001 at 03:20:02AM -0500 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 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Jul 08, 2001 at 03:20:02AM -0500, Will Andrews wrote: > OR... import Vim and get rid of nvi? :-) ..snip.. > The maintainer reserves the right to include any changes in the official > version of Vim. This is negotiable. You are not allowed to distribute a > modified version of Vim when you are not willing to make the source code > available to the maintainer. Uh... did you read this part __carefully__?? > What do you say? 8) Uh.. NO. -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 8 21:25:17 2001 Delivered-To: freebsd-arch@freebsd.org Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by hub.freebsd.org (Postfix) with ESMTP id 5FAE837B407; Sun, 8 Jul 2001 21:25:15 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.11.3/8.11.3) id f694PEl96521; Sun, 8 Jul 2001 21:25:14 -0700 (PDT) (envelope-from sgk) Date: Sun, 8 Jul 2001 21:25:14 -0700 From: Steve Kargl To: "David O'Brien" Cc: Jason Evans , Dag-Erling Smorgrav , Bill Fenner , arch@FreeBSD.ORG Subject: Re: nvi maintainer? Message-ID: <20010708212514.A94382@troutmask.apl.washington.edu> References: <200107072203.PAA09299@windsor.research.att.com> <20010708005155.J8775@canonware.com> <20010708032002.D97456@bohr.physics.purdue.edu> <20010708201329.A85258@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010708201329.A85258@dragon.nuxi.com>; from obrien@FreeBSD.ORG on Sun, Jul 08, 2001 at 08:13:29PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Jul 08, 2001 at 08:13:29PM -0700, David O'Brien wrote: > On Sun, Jul 08, 2001 at 03:20:02AM -0500, Will Andrews wrote: > > OR... import Vim and get rid of nvi? :-) > ..snip.. > > The maintainer reserves the right to include any changes in the official > > version of Vim. This is negotiable. You are not allowed to distribute a > > modified version of Vim when you are not willing to make the source code > > available to the maintainer. > > Uh... did you read this part __carefully__?? > What's the problem, david? The FreeBSD source tree is available to the vim maintainer. OTOH, has anyone ask Sleepycat about including DB3 so nvi will work? I'm sure I read some place on www.openoffice.org that Sleepcat has granted OpenOffice (i.e., Sun) permission to include berkeleydb (I don't recall which version) in their source tree? -- Steve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 8 21:29:39 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (dhcp44-21.dis.org [216.240.44.21]) by hub.freebsd.org (Postfix) with ESMTP id 9548237B401 for ; Sun, 8 Jul 2001 21:29:35 -0700 (PDT) (envelope-from msmith@mass.dis.org) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.4/8.11.3) with ESMTP id f694hEn00946; Sun, 8 Jul 2001 21:43:15 -0700 (PDT) (envelope-from msmith@mass.dis.org) Message-Id: <200107090443.f694hEn00946@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Steve Kargl Cc: arch@FreeBSD.ORG Subject: Re: nvi maintainer? In-reply-to: Your message of "Sun, 08 Jul 2001 21:25:14 PDT." <20010708212514.A94382@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 08 Jul 2001 21:43:14 -0700 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > OTOH, has anyone ask Sleepycat about including DB3 so nvi > will work? I'm sure I read some place on www.openoffice.org > that Sleepcat has granted OpenOffice (i.e., Sun) permission to > include berkeleydb (I don't recall which version) in their > source tree? This has just been discussed; the Sleepycat license isn't compatible with FreeBSD. Please don't rehash the discussion *again*. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 8 21:32:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 66FEC37B40A for ; Sun, 8 Jul 2001 21:32:25 -0700 (PDT) (envelope-from obrien@nuxi.ucdavis.edu) Received: from dragon.nuxi.com (root@trang.nuxi.com [206.40.252.115]) by relay.nuxi.com (8.11.2/8.11.2) with ESMTP id f694WCR25622; Sun, 8 Jul 2001 21:32:12 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f694VvA88245; Sun, 8 Jul 2001 21:31:57 -0700 (PDT) (envelope-from obrien) Date: Sun, 8 Jul 2001 21:31:49 -0700 From: "David O'Brien" To: Peter Wemm Cc: Will Andrews , Jason Evans , Dag-Erling Smorgrav , Bill Fenner , arch@FreeBSD.ORG Subject: Re: nvi maintainer? Message-ID: <20010708213149.A88227@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <20010708032002.D97456@bohr.physics.purdue.edu> <20010708093745.DB2303811@overcee.netplex.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010708093745.DB2303811@overcee.netplex.com.au>; from peter@wemm.org on Sun, Jul 08, 2001 at 02:37:45AM -0700 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 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Jul 08, 2001 at 02:37:45AM -0700, Peter Wemm wrote: > The next thing is that moving a port to the base system usually has a > pretty chilling effect on the package.. Is that going to OK with regular > vim users who are used to having a dynamic, regularly updated port? Don't worry, if it goes into the base system, I will keep vim as up to date as I current do the port. -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 8 21:34:35 2001 Delivered-To: freebsd-arch@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 05B6737B401 for ; Sun, 8 Jul 2001 21:34:30 -0700 (PDT) (envelope-from obrien@nuxi.ucdavis.edu) Received: from dragon.nuxi.com (root@trang.nuxi.com [206.40.252.115]) by relay.nuxi.com (8.11.2/8.11.2) with ESMTP id f694YTR25634; Sun, 8 Jul 2001 21:34:29 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f694YSs88302; Sun, 8 Jul 2001 21:34:28 -0700 (PDT) (envelope-from obrien) Date: Sun, 8 Jul 2001 21:34:28 -0700 From: "David O'Brien" To: "Justin T. Gibbs" Cc: Dag-Erling Smorgrav , Cy Schubert - ITSD Open Systems Group , Peter Wemm , Will Andrews , Jason Evans , Bill Fenner , arch@FreeBSD.ORG Subject: Re: nvi maintainer? Message-ID: <20010708213428.B88227@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <200107081531.f68FVfU90366@aslan.scsiguy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200107081531.f68FVfU90366@aslan.scsiguy.com>; from gibbs@scsiguy.com on Sun, Jul 08, 2001 at 09:31:41AM -0600 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 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Jul 08, 2001 at 09:31:41AM -0600, Justin T. Gibbs wrote: > >Nope, nvi has multiple undo levels (not sure how many), press '.' > >after pressing 'u' to undo additional levels. > > I'm forced to use VIM under Linux and personally think that VIM > just doesn't cut it. :split instead of :E, the funky undo behavior, > the format of the status line, etc, etc. Of course I feel the same about nvi's split screen handling -- I find it unintuitive and can never remember that :E splits the screen. -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 8 21:37: 1 2001 Delivered-To: freebsd-arch@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 7B60937B401 for ; Sun, 8 Jul 2001 21:36:59 -0700 (PDT) (envelope-from obrien@nuxi.ucdavis.edu) Received: from dragon.nuxi.com (root@trang.nuxi.com [206.40.252.115]) by relay.nuxi.com (8.11.2/8.11.2) with ESMTP id f694atR25645; Sun, 8 Jul 2001 21:36:55 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f694ape88342; Sun, 8 Jul 2001 21:36:51 -0700 (PDT) (envelope-from obrien) Date: Sun, 8 Jul 2001 21:36:50 -0700 From: "David O'Brien" To: "Matthew D. Fuller" Cc: Peter Wemm , Will Andrews , Jason Evans , Dag-Erling Smorgrav , Bill Fenner , arch@FreeBSD.ORG Subject: Re: nvi maintainer? Message-ID: <20010708213650.C88227@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <20010708032002.D97456@bohr.physics.purdue.edu> <20010708093745.DB2303811@overcee.netplex.com.au> <20010708145639.G10713@futuresouth.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010708145639.G10713@futuresouth.com>; from fullermd@futuresouth.com on Sun, Jul 08, 2001 at 02:56:39PM -0500 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 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Jul 08, 2001 at 02:56:39PM -0500, Matthew D. Fuller wrote: > set wraplen=73 set textwidth=73 > wraplen, as I recall didn't work right, and I think one or two other > parts failed. I never did figure out how to set the wrap width. And > don't even get me started on the damn syntax highlighting... watch the > whole screen change color/darkness as I write a printf() depending on > when the ()'s, ""'s, etc., are open. *shudder* Normal Vim does not do that unless you have a fancy .vimrc or .gvimrc or vimrc system-wide file. -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 8 21:38:49 2001 Delivered-To: freebsd-arch@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 2B13C37B403 for ; Sun, 8 Jul 2001 21:38:46 -0700 (PDT) (envelope-from obrien@nuxi.ucdavis.edu) Received: from dragon.nuxi.com (root@trang.nuxi.com [206.40.252.115]) by relay.nuxi.com (8.11.2/8.11.2) with ESMTP id f694cjR25654; Sun, 8 Jul 2001 21:38:45 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f694ciS88358; Sun, 8 Jul 2001 21:38:44 -0700 (PDT) (envelope-from obrien) Date: Sun, 8 Jul 2001 21:38:44 -0700 From: "David O'Brien" To: Steve Kargl Cc: Jason Evans , Dag-Erling Smorgrav , Bill Fenner , arch@FreeBSD.ORG Subject: Re: nvi maintainer? Message-ID: <20010708213844.D88227@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <200107072203.PAA09299@windsor.research.att.com> <20010708005155.J8775@canonware.com> <20010708032002.D97456@bohr.physics.purdue.edu> <20010708201329.A85258@dragon.nuxi.com> <20010708212514.A94382@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010708212514.A94382@troutmask.apl.washington.edu>; from sgk@troutmask.apl.washington.edu on Sun, Jul 08, 2001 at 09:25:14PM -0700 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 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Jul 08, 2001 at 09:25:14PM -0700, Steve Kargl wrote: > On Sun, Jul 08, 2001 at 08:13:29PM -0700, David O'Brien wrote: > > On Sun, Jul 08, 2001 at 03:20:02AM -0500, Will Andrews wrote: > > > OR... import Vim and get rid of nvi? :-) > > ..snip.. > > > The maintainer reserves the right to include any changes in the official > > > version of Vim. This is negotiable. You are not allowed to distribute a > > > modified version of Vim when you are not willing to make the source code > > > available to the maintainer. > > > > Uh... did you read this part __carefully__?? > > > > What's the problem, david? The FreeBSD source tree is available > to the vim maintainer. I wish the meat of this disussion was not occuring on a closed mailing list. *sigh* *ANOTHER* abuse of that list and a prime reason why this type of abuse isn't good for us. I'll try to bounce the emails addressing this exact issue here. -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 8 21:41:41 2001 Delivered-To: freebsd-arch@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 072F737B409 for ; Sun, 8 Jul 2001 21:41:39 -0700 (PDT) (envelope-from obrien@nuxi.ucdavis.edu) Received: from dragon.nuxi.com (root@trang.nuxi.com [206.40.252.115]) by relay.nuxi.com (8.11.2/8.11.2) with ESMTP id f694fcR25669; Sun, 8 Jul 2001 21:41:38 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f694fcE88395; Sun, 8 Jul 2001 21:41:38 -0700 (PDT) (envelope-from obrien) Date: Sun, 8 Jul 2001 21:41:38 -0700 From: arch@freebsd.org To: Dag-Erling Smorgrav Cc: arch@freebsd.org Subject: Re: -fno-builtin Message-ID: <20010708214137.E88227@dragon.nuxi.com> Reply-To: arch@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from des@ofug.org on Mon, Jul 09, 2001 at 04:11:34AM +0200 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 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Jul 09, 2001 at 04:11:34AM +0200, Dag-Erling Smorgrav wrote: > I'd like to commit the attached patch, which adds -fno-builtin to > CFLAGS when WARNS is set. Any objections? No. We might as well as totally turn builtins off since the goal is to have the whole tree under WARNS=2. Since you want to change functionality, the burdon is on you to convince us why you want to do this -- which you have not. -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 8 21:44:43 2001 Delivered-To: freebsd-arch@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 664) id 7EB0737B405; Sun, 8 Jul 2001 21:44:41 -0700 (PDT) Date: Sun, 8 Jul 2001 21:44:41 -0700 From: arch@hub.freebsd.org To: arch@freebsd.org Subject: (FWD) Re: nvi maintainer? Message-ID: <20010708214441.A90759@hub.freebsd.org> Reply-To: arch@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Operating-System: FreeBSD 4.3-STABLE 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 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG ----- Forwarded message from Mike Smith ----- Date: Sun, 08 Jul 2001 16:18:48 -0700 > The bottom line for Sleepycat is we're happy to have any open source > project use our software in any way they find useful. Or, to put it > more simply, if we get to use your stuff, you get to use our stuff. > We're pretty much willing to sign on for any arrangement that follows > that rule. > > > It would be really nice if we could replace the libc DB routines > > with newer ones since you've indicated that the DBv1 stuff is > > somehow flawed, but I don't know that this license exclusion > > would work for libc. > > As I said, this comes up every 4-6 months, I make the same offer, > it gets discussed, and it dies for another few months. :-) The sticking point with this is that FreeBSD is not just a "free OS"; it's commonly reused in non-free contexts, and it's an important concern to us that this should continue to be possible. We just can't do that with the Sleepycat license; you're trying to make a living off your code, and we're trying to give ours away. Both goals are worthwhile, but not necessarily compatible. Regards, Mike -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E ----- End forwarded message ----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 8 21:45:11 2001 Delivered-To: freebsd-arch@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 664) id 2248337B401; Sun, 8 Jul 2001 21:45:07 -0700 (PDT) Date: Sun, 8 Jul 2001 21:45:07 -0700 From: arch@hub.freebsd.org To: arch@hub.freebsd.org Subject: (FWD) Re: nvi maintainer? Message-ID: <20010708214507.B90759@hub.freebsd.org> Reply-To: arch@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Operating-System: FreeBSD 4.3-STABLE 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 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG ----- Forwarded message from Jordan Hubbard ----- Date: Sun, 08 Jul 2001 20:42:40 -0700 From: Keith Bostic Subject: Re: nvi maintainer? Date: Sun, 8 Jul 2001 18:51:15 -0400 (EDT) > The bottom line for Sleepycat is we're happy to have any open source > project use our software in any way they find useful. Or, to put it > more simply, if we get to use your stuff, you get to use our stuff. > We're pretty much willing to sign on for any arrangement that follows > that rule. I think the principle concern here is that any arrangement "the project" enters into be transferrable to its user base. In other words, it would do no good for the project to get redistribution rights limited to the project but not to 3rd parties who want to further redistribute FreeBSD bits. Perhaps what you've been willing to offer every 4-6 months takes care of this issue, but I'm sadly unable to remember any of the text from the last time you did. :) Perhaps we could revisit this One More Time in a little Keith to Core pow-wow? I don't think we're going to settle this in a multi-hundred-way discussion, but we might in a smaller working group. - Jordan ----- End forwarded message ----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 8 21:45:35 2001 Delivered-To: freebsd-arch@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 664) id 0E58B37B401; Sun, 8 Jul 2001 21:45:33 -0700 (PDT) Date: Sun, 8 Jul 2001 21:45:33 -0700 From: arch@hub.freebsd.org To: arch@hub.freebsd.org Subject: (FWD) Re: nvi maintainer? Message-ID: <20010708214532.C90759@hub.freebsd.org> Reply-To: arch@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Operating-System: FreeBSD 4.3-STABLE 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 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG ----- Forwarded message from Mike Smith ----- Date: Sun, 08 Jul 2001 21:26:07 -0700 > >> As I said, this comes up every 4-6 months, I make the same offer, > >> it gets discussed, and it dies for another few months. :-) > > > > The sticking point with this is that FreeBSD is not just a "free OS"; > > it's commonly reused in non-free contexts, and it's an important concern > > to us that this should continue to be possible. > > Yes, but is it a concern that people be able to use it in non-FreeBSD > contexts? What counts as a "FreeBSD context"? If someone recycles code from FreeBSD into a product, like, say Apple into Darwin, is this still a "FreeBSD context"? When they sell it as OS X, is that still a "FreeBSD context"? Looking at it from your point of view, I'd have to say that it isn't, and that's the rub. > I'm happy to allow any FreeBSD use -- what you're protecting here is > the ability of a downstream vendor to extract a single piece of the > code and use it independently of FreeBSD, and I don't understand why > that's important to you. Because this is one of the things that FreeBSD offers the rest of the world; not just a complete operating system, but an excellent source of tested, maintained software that can be reused in any context, for any purpose. While we stick to that as part of our goals, we can't compromise our license criteria. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E ----- End forwarded message ----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 8 23:11:14 2001 Delivered-To: freebsd-arch@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id B99DE37B403 for ; Sun, 8 Jul 2001 23:11:12 -0700 (PDT) (envelope-from julian@elischer.org) Received: from elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id AAA46350 for ; Mon, 9 Jul 2001 00:43:05 -0700 (PDT) Message-ID: <3B494657.D3B7BF48@elischer.org> Date: Sun, 08 Jul 2001 22:51:19 -0700 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: arch@freebsd.org Subject: help needed in threads.. (Signals) Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Can someone tell me if an alarm() call that sets an alarm signal for some time in the futire (in a threaded environment, has teh signal delivered to the process (an random thread), the same thread that made the request, or a predesignated thread.. I just can't work out what the right way to handle it in the code is.. posix? Julian -- +------------------------------------+ ______ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ julian@elischer.org +------>x USA \ a very strange | ( OZ ) \___ ___ | country ! +- X_.---._/ presently in San Francisco \_/ \\ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 8 23:21:41 2001 Delivered-To: freebsd-arch@freebsd.org Received: from magnesium.net (toxic.magnesium.net [207.154.84.15]) by hub.freebsd.org (Postfix) with SMTP id C7FCD37B401 for ; Sun, 8 Jul 2001 23:21:38 -0700 (PDT) (envelope-from jasone@magnesium.net) Received: (qmail 70320 invoked by uid 1142); 9 Jul 2001 06:22:16 -0000 Date: 8 Jul 2001 23:22:15 -0700 Date: Sun, 8 Jul 2001 23:21:31 -0700 From: Jason Evans To: Julian Elischer Cc: arch@freebsd.org Subject: Re: help needed in threads.. (Signals) Message-ID: <20010708232131.O8775@canonware.com> References: <3B494657.D3B7BF48@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B494657.D3B7BF48@elischer.org>; from julian@elischer.org on Sun, Jul 08, 2001 at 10:51:19PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Jul 08, 2001 at 10:51:19PM -0700, Julian Elischer wrote: > Can someone tell me if an alarm() call that sets an alarm signal for > some time in the futire (in a threaded environment, has teh signal delivered > to the process (an random thread), the same thread that made the request, > or a predesignated thread.. I just can't work out > what the right way to handle it in the code is.. > > posix? Bwahaha, signals and threads. Each thread has its own signal mask. A signal sent to the process is delivered to a thread that doesn't have the signal masked (if any). If more than one thread has the signal unmasked, which thread receives the signal is undefined. That's what happens (or is supposed to happen). If you want to know the right way to do signal handling in threaded programs, that requires more explanation. Bwahaha. Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 8 23:22: 0 2001 Delivered-To: freebsd-arch@freebsd.org Received: from softweyr.com (softweyr.com [208.247.99.111]) by hub.freebsd.org (Postfix) with ESMTP id 38F3E37B405; Sun, 8 Jul 2001 23:21:56 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from localhost.softweyr.com ([127.0.0.1] helo=softweyr.com ident=a09535e9dcb6d9f1a10e28450400896e) by softweyr.com with esmtp (Exim 3.16 #1) id 15JSvS-0000hn-00; Sun, 08 Jul 2001 22:45:38 -0600 Message-ID: <3B4936F2.72D7C1C7@softweyr.com> Date: Sun, 08 Jul 2001 22:45:38 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: obrien@FreeBSD.org Cc: Jason Evans , Dag-Erling Smorgrav , Bill Fenner , arch@FreeBSD.org Subject: Re: nvi maintainer? References: <200107072203.PAA09299@windsor.research.att.com> <20010708005155.J8775@canonware.com> <20010708032002.D97456@bohr.physics.purdue.edu> <20010708201329.A85258@dragon.nuxi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG David O'Brien wrote: > > On Sun, Jul 08, 2001 at 03:20:02AM -0500, Will Andrews wrote: > > OR... import Vim and get rid of nvi? :-) > ..snip.. > > The maintainer reserves the right to include any changes in the official > > version of Vim. This is negotiable. You are not allowed to distribute a > > modified version of Vim when you are not willing to make the source code > > available to the maintainer. > > Uh... did you read this part __carefully__?? I don't see a problem there. It's not like we're going to hide the source to FreeBSD from the vim maintainer. OTOH, I don't really think we need a "better" vi bad enough to lump in vim. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 8 23:23:12 2001 Delivered-To: freebsd-arch@freebsd.org Received: from softweyr.com (softweyr.com [208.247.99.111]) by hub.freebsd.org (Postfix) with ESMTP id AB52C37B401 for ; Sun, 8 Jul 2001 23:23:01 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from localhost.softweyr.com ([127.0.0.1] helo=softweyr.com ident=2945b2298c8e2b063b1d9e91e999fdbc) by softweyr.com with esmtp (Exim 3.16 #1) id 15JSfR-0000hR-00; Sun, 08 Jul 2001 22:29:05 -0600 Message-ID: <3B493311.E4DAE613@softweyr.com> Date: Sun, 08 Jul 2001 22:29:05 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Cy Schubert - ITSD Open Systems Group Cc: arch@FreeBSD.ORG Subject: Re: nvi maintainer? References: <200107081607.f68G7Cw04170@cwsys.cwsent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Cy Schubert - ITSD Open Systems Group wrote: > > I'd be just as happy if we forked our copy of nvi, now that I've > learned how to use the funky new (to myself) undo behaviour. > > For that matter this affects all of the *BSD's. Could we just > collaborate with NetBSD and OpenBSD to maintain a single version of nvi > or an unencumbered version of DB3 across the *BSD's? I'm sure the > other BSD projects are considering their options too. OpenSSH is a > good example of this. OpenVI.org hasn't been registered -- yet. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 8 23:23:49 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.newgold.net (mail.newgold.net [209.42.222.44]) by hub.freebsd.org (Postfix) with SMTP id AE8F737B63B for ; Sun, 8 Jul 2001 23:23:33 -0700 (PDT) (envelope-from jmallett@xMach.org) Received: (qmail 23422 invoked by uid 1000); 9 Jul 2001 06:23:32 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 9 Jul 2001 06:23:32 -0000 Date: Mon, 9 Jul 2001 06:23:32 +0000 (GMT) From: Joseph Mallett X-X-Sender: To: Wes Peters Cc: , Jason Evans , Dag-Erling Smorgrav , Bill Fenner , Subject: Re: nvi maintainer? In-Reply-To: <3B4936F2.72D7C1C7@softweyr.com> Message-ID: <20010709062257.S22389-100000@Aphex.NewGold.NET> Organization: xMach Core Team [ http://www.xMach.org/ ] MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > I don't see a problem there. It's not like we're going to hide the source > to FreeBSD from the vim maintainer. OTOH, I don't really think we need > a "better" vi bad enough to lump in vim. The issues deal with the next version of nvi introducing licensing conflicts, and looking for a wholly free alternative so we don't have to work. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 8 23:25:34 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.newgold.net (mail.newgold.net [209.42.222.44]) by hub.freebsd.org (Postfix) with SMTP id 06B0037B403 for ; Sun, 8 Jul 2001 23:25:30 -0700 (PDT) (envelope-from jmallett@xMach.org) Received: (qmail 23478 invoked by uid 1000); 9 Jul 2001 06:25:28 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 9 Jul 2001 06:25:28 -0000 Date: Mon, 9 Jul 2001 06:25:28 +0000 (GMT) From: Joseph Mallett X-X-Sender: To: Wes Peters Cc: Subject: Re: nvi maintainer? In-Reply-To: <20010709062257.S22389-100000@Aphex.NewGold.NET> Message-ID: <20010709062501.Q22389-100000@Aphex.NewGold.NET> Organization: xMach Core Team [ http://www.xMach.org/ ] MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > The issues deal with the next version of nvi introducing licensing > conflicts, and looking for a wholly free alternative so we don't have to > work. > fork*. Didn't mean to imply laziness :) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 8 23:40: 4 2001 Delivered-To: freebsd-arch@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 7963537B403 for ; Sun, 8 Jul 2001 23:40:00 -0700 (PDT) (envelope-from obrien@nuxi.ucdavis.edu) Received: from dragon.nuxi.com (root@trang.nuxi.com [206.40.252.115]) by relay.nuxi.com (8.11.2/8.11.2) with ESMTP id f696dqR26102; Sun, 8 Jul 2001 23:39:52 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f696dqV90189; Sun, 8 Jul 2001 23:39:52 -0700 (PDT) (envelope-from obrien) Date: Sun, 8 Jul 2001 23:39:51 -0700 From: "David O'Brien" To: Wes Peters Cc: arch@FreeBSD.org Subject: Re: nvi maintainer? Message-ID: <20010708233951.B90028@dragon.nuxi.com> Reply-To: obrien@FreeBSD.org References: <200107072203.PAA09299@windsor.research.att.com> <20010708005155.J8775@canonware.com> <20010708032002.D97456@bohr.physics.purdue.edu> <20010708201329.A85258@dragon.nuxi.com> <3B4936F2.72D7C1C7@softweyr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B4936F2.72D7C1C7@softweyr.com>; from wes@softweyr.com on Sun, Jul 08, 2001 at 10:45:38PM -0600 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 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Jul 08, 2001 at 10:45:38PM -0600, Wes Peters wrote: > David O'Brien wrote: > > > > On Sun, Jul 08, 2001 at 03:20:02AM -0500, Will Andrews wrote: > > > OR... import Vim and get rid of nvi? :-) > > ..snip.. > > > The maintainer reserves the right to include any changes in the official > > > version of Vim. This is negotiable. You are not allowed to distribute a > > > modified version of Vim when you are not willing to make the source code > > > available to the maintainer. > > > > Uh... did you read this part __carefully__?? > > I don't see a problem there. It's not like we're going to hide the source > to FreeBSD from the vim maintainer. OTOH, I don't really think we need > a "better" vi bad enough to lump in vim. I am very surprised to hear this coming from you -- a commercial embedded developer. Remember, FreeBSD isn't the end of all -- rather we offer something others can take, modify, commercialize, propietize, and not give away the crown jewels. -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 9 0: 5:52 2001 Delivered-To: freebsd-arch@freebsd.org Received: from softweyr.com (softweyr.com [208.247.99.111]) by hub.freebsd.org (Postfix) with ESMTP id 45C9237B409; Mon, 9 Jul 2001 00:05:49 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from localhost.softweyr.com ([127.0.0.1] helo=softweyr.com ident=bf605f45b4c16ff79bcff88172b590b0) by softweyr.com with esmtp (Exim 3.16 #1) id 15JVCN-0000mS-00; Mon, 09 Jul 2001 01:11:15 -0600 Message-ID: <3B495913.89A8C1C2@softweyr.com> Date: Mon, 09 Jul 2001 01:11:15 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: obrien@FreeBSD.org Cc: arch@FreeBSD.org Subject: Re: nvi maintainer? References: <200107072203.PAA09299@windsor.research.att.com> <20010708005155.J8775@canonware.com> <20010708032002.D97456@bohr.physics.purdue.edu> <20010708201329.A85258@dragon.nuxi.com> <3B4936F2.72D7C1C7@softweyr.com> <20010708233951.B90028@dragon.nuxi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG David O'Brien wrote: > > On Sun, Jul 08, 2001 at 10:45:38PM -0600, Wes Peters wrote: > > David O'Brien wrote: > > > > > > On Sun, Jul 08, 2001 at 03:20:02AM -0500, Will Andrews wrote: > > > > OR... import Vim and get rid of nvi? :-) > > > ..snip.. > > > > The maintainer reserves the right to include any changes in the official > > > > version of Vim. This is negotiable. You are not allowed to distribute a > > > > modified version of Vim when you are not willing to make the source code > > > > available to the maintainer. > > > > > > Uh... did you read this part __carefully__?? > > > > I don't see a problem there. It's not like we're going to hide the source > > to FreeBSD from the vim maintainer. OTOH, I don't really think we need > > a "better" vi bad enough to lump in vim. > > I am very surprised to hear this coming from you -- a commercial embedded > developer. Remember, FreeBSD isn't the end of all -- rather we offer > something others can take, modify, commercialize, propietize, and not give > away the crown jewels. But the likelihood of putting vi on an embedded system is low, and the likelihood of putting a modified vi on an embedded system is very very small. The likelihood of putting a 1.2 megabyte vi on *my* embedded system is so small science has not yet invented an instrument that can measure it. What I'm saying is there are better arguments against vim than the license. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 9 0:50:36 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 6765737B403 for ; Mon, 9 Jul 2001 00:50:32 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id RAA22830; Mon, 9 Jul 2001 17:50:24 +1000 Date: Mon, 9 Jul 2001 17:48:19 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Dag-Erling Smorgrav Cc: arch@FreeBSD.ORG Subject: Re: Type differences In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 8 Jul 2001, Dag-Erling Smorgrav wrote: > des@des /usr/src/sys% grep 'define.*BSD_SIZE_T' {i386,alpha}/include/ansi.h > i386/include/ansi.h:#define _BSD_SIZE_T_ unsigned int /* sizeof() */ > alpha/include/ansi.h:#define _BSD_SIZE_T_ unsigned long /* sizeof() */ > des@des /usr/src/sys% grep 'define.*BSD_OFF_T' {i386,alpha}/include/ansi.h > i386/include/ansi.h:#define _BSD_OFF_T_ __int64_t /* file offset */ > alpha/include/ansi.h:#define _BSD_OFF_T_ long /* file offset */ > > What's the idea here? off_t is the exact same size and signedness on > both platforms, so why not use the same definition for both? The idea is that _BSD_FOO_T_ should have a basic (ISO C90) type so that doesn't have convoluted dependencies on the files that declare typedefed types. This is not possible for _BSD_OFF_T_, so it is handled specially (see rev.15 of the i386 version). > And why > make size_t an int on i386 but a long on alpha, when on both these > platforms int and long are identical? _BSD_SIZE_T_ is different because it _is_ different. 1. int and long aren't identical. The difference may be just in their spelling, but it affects the whole type system. 2. int and long don't even have the same size on alphas under FreeBSD. 3. doesn't get to choose the type of _BSD_SIZE_T_. It must match the type of the compiler's sizeof() operator. This is specified by the SIZE_TYPE macro in gcc/cppdefault.h and gcc/config/${MACHINE_ARCH}/*. It defaults to "long unsigned int", but for historical reasons it is "unsigned int" on i386's. > Also, gcc (correctly) complains about a "comparison between signed and > unsigned" when you try to compare a size_t to an off_t on alpha - but > doesn't complain on i386. What gives? On i386's, size_t is 32 bits unsigned. For the comparison, size_t's are promoted to a common type. off_t is longer, so size_t is first promoted to 64 bits signed (it loses its unsignedness due to ISO C's (BAD) value-preserving (signedness-clobbering) promotion rule). off_t is also 64 bit signed, so no further promotion occurs. Both operands are now signed, so gcc doesn't complain. Not that there is still a bug if it is possible for the off_t to have a negative value; signedness-clobbering promotion has mainly broken the warning for i386's. > And while we're on this subject, what's the Officially Approved way of > printf()ing an off_t or a size_t so it does not generate warnings on > either platform? Implement the ISO C99 [u]intmax_t and %j[diouxX] and use them. You could also implement and use %z[diouxX] for size_t's and %t[diouxX] for ptrdiff_t's. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 9 2: 7: 5 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 2DB9337B405 for ; Mon, 9 Jul 2001 02:07:02 -0700 (PDT) (envelope-from des@ofug.org) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id LAA56581; Mon, 9 Jul 2001 11:07:01 +0200 (CEST) (envelope-from des@ofug.org) 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: arch@FreeBSD.ORG Subject: Re: -fno-builtin References: <20010708214137.E88227@dragon.nuxi.com> From: Dag-Erling Smorgrav Date: 09 Jul 2001 11:07:00 +0200 In-Reply-To: <20010708214137.E88227@dragon.nuxi.com> Message-ID: Lines: 17 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG arch@FreeBSD.ORG writes: > No. We might as well as totally turn builtins off since the goal is to > have the whole tree under WARNS=2. Since you want to change > functionality, the burdon is on you to convince us why you want to do this > -- which you have not. The alternatives - just to get it to build - are to turn off -Wshadow, or rename every single local variable in the tree that shadows a builtin (and believe me, there are *tons* of these). In addition, there's the issue of errors that -fno-builtin hides - many of those have been fixed already, but I don't know how many remain (or how many will be introduced in the future). DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 9 2:51: 2 2001 Delivered-To: freebsd-arch@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id CB77F37B401 for ; Mon, 9 Jul 2001 02:50:59 -0700 (PDT) (envelope-from julian@elischer.org) Received: from elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id EAA47180; Mon, 9 Jul 2001 04:20:44 -0700 (PDT) Message-ID: <3B49794F.5123170F@elischer.org> Date: Mon, 09 Jul 2001 02:28:47 -0700 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Jason Evans Cc: arch@freebsd.org Subject: Re: help needed in threads.. (Signals) References: <3B494657.D3B7BF48@elischer.org> <20010708232131.O8775@canonware.com> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Jason Evans wrote: > > On Sun, Jul 08, 2001 at 10:51:19PM -0700, Julian Elischer wrote: > > Can someone tell me if an alarm() call that sets an alarm signal for > > some time in the futire (in a threaded environment, has teh signal delivered > > to the process (an random thread), the same thread that made the request, > > or a predesignated thread.. I just can't work out > > what the right way to handle it in the code is.. > > > > posix? > > Bwahaha, signals and threads. > > Each thread has its own signal mask. A signal sent to the process is > delivered to a thread that doesn't have the signal masked (if any). If > more than one thread has the signal unmasked, which thread receives the > signal is undefined. > > That's what happens (or is supposed to happen). If you want to know the > right way to do signal handling in threaded programs, that requires more > explanation. here's where I'm having problems... I can pass the signal to the UTS, but I don't know what to do about the threads that are doing 'uninterruptable sleeps' in the kernel. Should the UTS give me back a list of threads to kick? that would satisfy the posix semantics. I guess I should ignore all signals when in KSE mode and just pass them up as an upcall. (The kernel interface and the user interface need not be the same). This indicates that a signal pre-empts whatever is running to do an upcall rather than waiting until i gets a chance that may never happen. (hmmmmm I need to think about this more... off to bed..)  > > Bwahaha. > > Jason -- +------------------------------------+ ______ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ julian@elischer.org +------>x USA \ a very strange | ( OZ ) \___ ___ | country ! +- X_.---._/ presently in San Francisco \_/ \\ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 9 4:15:34 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id F364537B401 for ; Mon, 9 Jul 2001 04:15:29 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id VAA12787; Mon, 9 Jul 2001 21:15:22 +1000 Date: Mon, 9 Jul 2001 21:13:17 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Dag-Erling Smorgrav Cc: arch@FreeBSD.ORG Subject: Re: -fno-builtin In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 9 Jul 2001, Dag-Erling Smorgrav wrote: > arch@FreeBSD.ORG writes: > > No. We might as well as totally turn builtins off since the goal is to > > have the whole tree under WARNS=2. Since you want to change > > functionality, the burdon is on you to convince us why you want to do this > > -- which you have not. > > The alternatives - just to get it to build - are to turn off -Wshadow, > or rename every single local variable in the tree that shadows a > builtin (and believe me, there are *tons* of these). > > In addition, there's the issue of errors that -fno-builtin hides - > many of those have been fixed already, but I don't know how many > remain (or how many will be introduced in the future). I think gcc gets this backwards. I think it should warn about builtins shadowing local variables only if the relevant header is included, and it should warn about missing prototypes for builtins unless the relevarnt is included. Possible work-around: make -fno-builtin the default, and re-implement all of the builtin functions that you want using macros or inline functions. E.g.: --- #include static __inline size_t strlen(const char *s) { return (__builtin_strlen(s)); } --- Unfortunately, the inline function version doesn't work right, at least on i386's: __builtin_strlen("foo") gives code that loads the constant result 3, but the inline strlen("foo") gives code that scans the string. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 9 4:35:34 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 1CF4437B405 for ; Mon, 9 Jul 2001 04:35:31 -0700 (PDT) (envelope-from des@ofug.org) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id NAA57188; Mon, 9 Jul 2001 13:35:26 +0200 (CEST) (envelope-from des@ofug.org) 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: Bruce Evans Cc: arch@FreeBSD.ORG Subject: Re: -fno-builtin References: From: Dag-Erling Smorgrav Date: 09 Jul 2001 13:35:26 +0200 In-Reply-To: Message-ID: Lines: 14 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Bruce Evans writes: > Unfortunately, the inline function version doesn't work right, at least > on i386's: __builtin_strlen("foo") gives code that loads the constant > result 3, but the inline strlen("foo") gives code that scans the string. What about a macro? #define strlen(s) __builtin_strlen(s) Would this work? DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 9 5:11:55 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 733DC37B405 for ; Mon, 9 Jul 2001 05:11:52 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id WAA16973; Mon, 9 Jul 2001 22:11:46 +1000 Date: Mon, 9 Jul 2001 22:09:41 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Dag-Erling Smorgrav Cc: arch@FreeBSD.ORG Subject: Re: -fno-builtin In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 9 Jul 2001, Dag-Erling Smorgrav wrote: > Bruce Evans writes: > > Unfortunately, the inline function version doesn't work right, at least > > on i386's: __builtin_strlen("foo") gives code that loads the constant > > result 3, but the inline strlen("foo") gives code that scans the string. > > What about a macro? > > #define strlen(s) __builtin_strlen(s) > > Would this work? I think it would work right except in broken code which "knows" that strlen isn't a macro, e.g.: size_t (*p)(const char *s) = strlen; and in non-broken code that avoids the macro, e.g.: size_t foo = (strlen)("123"); It only loses the optimization (if any) of using the builtin for non-broken code. This is only practical because there aren't many builtins for standard functions. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 9 5:23: 8 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by hub.freebsd.org (Postfix) with ESMTP id D6D5637B405 for ; Mon, 9 Jul 2001 05:23:04 -0700 (PDT) (envelope-from brandt@fokus.gmd.de) Received: from beagle (beagle [193.175.132.100]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id OAA17296; Mon, 9 Jul 2001 14:22:51 +0200 (MET DST) Date: Mon, 9 Jul 2001 14:22:51 +0200 (CEST) From: Harti Brandt To: Bruce Evans Cc: Subject: Re: -fno-builtin In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 9 Jul 2001, Bruce Evans wrote: BE>On 9 Jul 2001, Dag-Erling Smorgrav wrote: BE> BE>> Bruce Evans writes: BE>> > Unfortunately, the inline function version doesn't work right, at least BE>> > on i386's: __builtin_strlen("foo") gives code that loads the constant BE>> > result 3, but the inline strlen("foo") gives code that scans the string. BE>> BE>> What about a macro? BE>> BE>> #define strlen(s) __builtin_strlen(s) BE>> BE>> Would this work? BE> BE>I think it would work right except in broken code which "knows" that BE>strlen isn't a macro, e.g.: BE> BE> size_t (*p)(const char *s) = strlen; Why is that broken? My last copy of the ISO-C draft specifically states, that strlen is a function. (Not that I intend to use that construct. Just beeing curious). harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.gmd.de, harti@begemot.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 9 5:46:37 2001 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 3C8B237B406 for ; Mon, 9 Jul 2001 05:46:33 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id IAA18854; Mon, 9 Jul 2001 08:45:49 -0400 (EDT) Date: Mon, 9 Jul 2001 08:45:49 -0400 (EDT) From: Daniel Eischen To: Jason Evans Cc: Julian Elischer , arch@FreeBSD.ORG Subject: Re: help needed in threads.. (Signals) In-Reply-To: <20010708232131.O8775@canonware.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 8 Jul 2001, Jason Evans wrote: > On Sun, Jul 08, 2001 at 10:51:19PM -0700, Julian Elischer wrote: > > Can someone tell me if an alarm() call that sets an alarm signal for > > some time in the futire (in a threaded environment, has teh signal delivered > > to the process (an random thread), the same thread that made the request, > > or a predesignated thread.. I just can't work out > > what the right way to handle it in the code is.. > > > > posix? > > Bwahaha, signals and threads. > > Each thread has its own signal mask. A signal sent to the process is > delivered to a thread that doesn't have the signal masked (if any). If > more than one thread has the signal unmasked, which thread receives the > signal is undefined. > > That's what happens (or is supposed to happen). If you want to know the > right way to do signal handling in threaded programs, that requires more > explanation. > > Bwahaha. :-) Here is part of a log from a commit to uthread.c: Modify the search for a thread to which a signal is delivered. The search algorithm is now: o First thread found in sigwait() with signal in wait mask. o First thread found sigsuspend()'d on the signal. o Current thread if signal is unmasked. o First thread found with signal unmasked. Note that the signal handler is not called if the thread is in sigwait, but only called for the last 3 bullets. If a thread isn't found that can handle the signal, then the signal gets marked as pending for the process, and will be delivered to the first thread to sigwait/sigsuspend on it, or to unmask the signal. For pthread_kill(), the signal is directed to a specific thread. If the signal is masked in the thread, then it is marked as pending for that thread and will be delivered when the thread sigwaits/sigsuspends on it or unmasks it. If the process action is SIG_DFL for the signal, then the signal also gets delivered to the process. This surprises a few people when their program aborts ;-) You can use both sigprocmask and pthread_sigmask to set the signal mask of the current thread; they both behave the same way in a threaded environment. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 9 5:59: 3 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id B637A37B403 for ; Mon, 9 Jul 2001 05:58:57 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id WAA19888; Mon, 9 Jul 2001 22:58:50 +1000 Date: Mon, 9 Jul 2001 22:56:45 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Harti Brandt Cc: arch@FreeBSD.ORG Subject: Re: -fno-builtin In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 9 Jul 2001, Harti Brandt wrote: > On Mon, 9 Jul 2001, Bruce Evans wrote: > > BE>I think it would work right except in broken code which "knows" that > BE>strlen isn't a macro, e.g.: > BE> > BE> size_t (*p)(const char *s) = strlen; > > Why is that broken? My last copy of the ISO-C draft specifically states, > that strlen is a function. (Not that I intend to use that construct. Just > beeing curious). Does it really? Almost any library function can be implemented as a (safe) macro (see section 7.1.4). I can't find any exception for strlen. This possibility is not completely transparent to applications. Code like the above should be aware of it. Workarounds are easy in the above (just used "&strlen" or "(strlen)". Section 7.1.4 documents these. Howver, I now remember a nasty example which shows why implementations should not do this: len = strlen( #ifdef FOO "foo" #else "default" #endif ); This causes errors like: z.c:11: warning: preprocessing directive not recognized within macro arg z.c:11: warning: preprocessing directive not recognized within macro arg z.c:11: warning: preprocessing directive not recognized within macro arg z.c: In function `main': z.c:6: undefined or invalid # directive z.c:8: undefined or invalid # directive z.c:10: undefined or invalid # directive I only learned of this example a weeks or two ago. gcc-3.0 was reported to make a very fundamental function (printf?) a macro. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 9 6: 6:59 2001 Delivered-To: freebsd-arch@freebsd.org Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by hub.freebsd.org (Postfix) with ESMTP id 6843B37B401 for ; Mon, 9 Jul 2001 06:06:56 -0700 (PDT) (envelope-from ticso@mail.cicely.de) Received: from mail.cicely.de (cicely20 [10.1.1.22]) by srv1.cosmo-project.de (8.11.0/8.11.0) with ESMTP id f69D6rV36953; Mon, 9 Jul 2001 15:06:53 +0200 (CEST) Received: (from ticso@localhost) by mail.cicely.de (8.11.0/8.11.0) id f69D7eT23521; Mon, 9 Jul 2001 15:07:40 +0200 (CEST) Date: Mon, 9 Jul 2001 15:07:39 +0200 From: Bernd Walter To: Will Andrews Cc: Jason Evans , Dag-Erling Smorgrav , Bill Fenner , arch@FreeBSD.ORG Subject: Re: nvi maintainer? Message-ID: <20010709150739.A23210@cicely20.cicely.de> References: <200107072203.PAA09299@windsor.research.att.com> <20010708005155.J8775@canonware.com> <20010708032002.D97456@bohr.physics.purdue.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010708032002.D97456@bohr.physics.purdue.edu>; from will@physics.purdue.edu on Sun, Jul 08, 2001 at 03:20:02AM -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Jul 08, 2001 at 03:20:02AM -0500, Will Andrews wrote: > [ moving from developers@ to arch@ ] > > On Sun, Jul 08, 2001 at 12:51:55AM -0700, Jason Evans (jasone@canonware.com) wrote: > > This unfortunately means that FreeBSD will not be able to use the next > > release of nvi as part of the base system. In other words, we're going to > > have to fork nvi. Yuck. > > OR... import Vim and get rid of nvi? :-) What is wrong with nvi? The current nvi seems to work and nearly all files havn't been changed for years which mean there isn't much to maintain. Is there realy a reason to have the latest version? I personaly don't like vim because it's different undo, mysterious window and multiple file management and would like to stay with nvi. As an example I'm used to open a new window with :N or Prev. I never understood how to add and remove filenames to vim list while there wasn't a problem to learn how nvi does. > If you distribute a modified version of Vim, you are encouraged to send the > maintainer a copy, including the source code. Or make it available to the > maintainer through ftp; let him know where it can be found. If the number of > changes is small (e.g., a modified Makefile) e-mailing the diffs will do. > When the maintainer asks for it (in any way) you must make your changes, > including source code, available to him. Is the last sentence that different from the DB3 licence where you have to distribute the source of your product? You have the make sources available any way. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 9 6:17:40 2001 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 90D7337B405 for ; Mon, 9 Jul 2001 06:17:36 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id JAA23628; Mon, 9 Jul 2001 09:16:49 -0400 (EDT) Date: Mon, 9 Jul 2001 09:16:49 -0400 (EDT) From: Daniel Eischen To: Julian Elischer Cc: Jason Evans , arch@FreeBSD.ORG Subject: Re: help needed in threads.. (Signals) In-Reply-To: <3B49794F.5123170F@elischer.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 9 Jul 2001, Julian Elischer wrote: > Jason Evans wrote: > > > > On Sun, Jul 08, 2001 at 10:51:19PM -0700, Julian Elischer wrote: > > > Can someone tell me if an alarm() call that sets an alarm signal for > > > some time in the futire (in a threaded environment, has teh signal delivered > > > to the process (an random thread), the same thread that made the request, > > > or a predesignated thread.. I just can't work out > > > what the right way to handle it in the code is.. > > > > > > posix? > > > > Bwahaha, signals and threads. > > > > Each thread has its own signal mask. A signal sent to the process is > > delivered to a thread that doesn't have the signal masked (if any). If > > more than one thread has the signal unmasked, which thread receives the > > signal is undefined. > > > > That's what happens (or is supposed to happen). If you want to know the > > right way to do signal handling in threaded programs, that requires more > > explanation. > > here's where I'm having problems... > I can pass the signal to the UTS, but I don't know what to do about the > threads that are doing 'uninterruptable sleeps' in the kernel. > Should the UTS give me back a list of threads to kick? > that would satisfy the posix semantics. The UTS needs tell the kernel to interrupt a specific blocked thread. If the ksectx is not interruptable at its current point, then the kernel needs to mark it as having a signal pending on it so that the signal handler (or upcall) can be called when it either becomes interruptable or is ready to return to userland. The UTS cannot deliver the signal until the kernel tells it that the ksectx is either interruptable or completed. I'm not quite sure what happens in a normal trampoline; if a signal handler completes normally, does it go back to the same spot in the kernel to finish its work (assume SA_RESTART is set)? If so, I think the interrupted ksectx needs to be set to the current ksectx when the interruption occurs. The UTS has no idea whether the invoked signal handler is going to return normally or not. (If the signal handler longjmps out of the handler, you need to make sure the ksectx isn't left forever in the kernel.) > I guess I should ignore all signals when in KSE mode and just pass them up > as an upcall. > (The kernel interface and the user interface need not be the same). > > This indicates that a signal pre-empts whatever is running to do an upcall > rather than > waiting until i gets a chance that may never happen. > (hmmmmm I need to think about this more... off to bed..) On a related note, the UTS needs another system call to send a message from one KSE to another (possibly set of) KSEs. The UTS does direct handoff of mutexes, condition variables, and other things. If the handoff is to a thread running (now waiting) on another KSE or KSEG, then the we need to be able to "signal" it that that thread should now be runnable. A similar thing for signals. If the thread that needs the signal dispatched is scheduled on another KSE, then we need to send that KSE a message to inform it of that. I say "possibly set of" KSEs because of pthread_cond_broadcast(). -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 9 6:56:47 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by hub.freebsd.org (Postfix) with ESMTP id 4673837B405 for ; Mon, 9 Jul 2001 06:56:41 -0700 (PDT) (envelope-from brandt@fokus.gmd.de) Received: from beagle (beagle [193.175.132.100]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id PAA00599; Mon, 9 Jul 2001 15:56:29 +0200 (MET DST) Date: Mon, 9 Jul 2001 15:56:29 +0200 (CEST) From: Harti Brandt To: Bruce Evans Cc: Subject: Re: -fno-builtin In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 9 Jul 2001, Bruce Evans wrote: BE>On Mon, 9 Jul 2001, Harti Brandt wrote: BE> BE>> On Mon, 9 Jul 2001, Bruce Evans wrote: BE>> BE>> BE>I think it would work right except in broken code which "knows" that BE>> BE>strlen isn't a macro, e.g.: BE>> BE> BE>> BE> size_t (*p)(const char *s) = strlen; BE>> BE>> Why is that broken? My last copy of the ISO-C draft specifically states, BE>> that strlen is a function. (Not that I intend to use that construct. Just BE>> beeing curious). BE> BE>Does it really? Almost any library function can be implemented as a BE>(safe) macro (see section 7.1.4). I can't find any exception for BE>strlen. This possibility is not completely transparent to applications. BE>Code like the above should be aware of it. Workarounds are easy in BE>the above (just used "&strlen" or "(strlen)". Section 7.1.4 documents Well, hmmm, yes. The section on string.h states, that string.h contains ONE type and ONE macro and several functions, but 7.1.4 allows all functions to be macros. This means, that to take the address of ANY library function you have to do either: # undef func p = func; or p = (func); And p = &func; does not help. BE>these. Howver, I now remember a nasty example which shows why BE>implementations should not do this: BE> BE> len = strlen( BE>#ifdef FOO BE> "foo" BE>#else BE> "default" BE>#endif BE> ); BE> BE>This causes errors like: BE> BE>z.c:11: warning: preprocessing directive not recognized within macro arg BE>z.c:11: warning: preprocessing directive not recognized within macro arg BE>z.c:11: warning: preprocessing directive not recognized within macro arg BE>z.c: In function `main': BE>z.c:6: undefined or invalid # directive BE>z.c:8: undefined or invalid # directive BE>z.c:10: undefined or invalid # directive BE> BE>I only learned of this example a weeks or two ago. gcc-3.0 was reported BE>to make a very fundamental function (printf?) a macro. len = (strlen)( #ifdef FOO "foo" #else "default" #endif ); should work then. Thanks for the clarification, harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.gmd.de, harti@begemot.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 9 7:58:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by hub.freebsd.org (Postfix) with ESMTP id 67A3A37B403 for ; Mon, 9 Jul 2001 07:58:20 -0700 (PDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.11.3/8.11.3) id f69EwDm27345; Mon, 9 Jul 2001 09:58:13 -0500 (CDT) (envelope-from dan) Date: Mon, 9 Jul 2001 09:58:12 -0500 From: Dan Nelson To: Bruce Evans Cc: Harti Brandt , arch@FreeBSD.ORG Subject: Re: -fno-builtin Message-ID: <20010709095812.A20489@dan.emsphone.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.19i X-OS: FreeBSD 5.0-CURRENT Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In the last episode (Jul 09), Bruce Evans said: > len = strlen( > #ifdef FOO > "foo" > #else > "default" > #endif > ); > > This causes errors like: > > z.c:11: warning: preprocessing directive not recognized within macro arg > z.c:11: warning: preprocessing directive not recognized within macro arg > z.c:11: warning: preprocessing directive not recognized within macro arg > z.c: In function `main': > z.c:6: undefined or invalid # directive > z.c:8: undefined or invalid # directive > z.c:10: undefined or invalid # directive > > I only learned of this example a week or two ago. gcc-3.0 was > reported to make a very fundamental function (printf?) a macro. glibc, actually. Do a google search for "glibc printf macro" and you'll see a couple threads discussing it. -- Dan Nelson dnelson@emsphone.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 9 8:59: 8 2001 Delivered-To: freebsd-arch@freebsd.org Received: from sneakerz.org (sneakerz.org [216.33.66.254]) by hub.freebsd.org (Postfix) with ESMTP id 68F7F37B401 for ; Mon, 9 Jul 2001 08:59:03 -0700 (PDT) (envelope-from bright@sneakerz.org) Received: by sneakerz.org (Postfix, from userid 1092) id C612D5D020; Mon, 9 Jul 2001 10:59:02 -0500 (CDT) Date: Mon, 9 Jul 2001 10:59:02 -0500 From: Alfred Perlstein To: Julian Elischer Cc: Jason Evans , arch@freebsd.org Subject: Re: help needed in threads.. (Signals) Message-ID: <20010709105902.E1894@sneakerz.org> References: <3B494657.D3B7BF48@elischer.org> <20010708232131.O8775@canonware.com> <3B49794F.5123170F@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <3B49794F.5123170F@elischer.org>; from julian@elischer.org on Mon, Jul 09, 2001 at 02:28:47AM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Julian Elischer [010709 04:51] wrote: > > here's where I'm having problems... > I can pass the signal to the UTS, but I don't know what to do about the > threads that are doing 'uninterruptable sleeps' in the kernel. > Should the UTS give me back a list of threads to kick? > that would satisfy the posix semantics. > > I guess I should ignore all signals when in KSE mode and just pass them up > as an upcall. > (The kernel interface and the user interface need not be the same). > > This indicates that a signal pre-empts whatever is running to do an upcall > rather than > waiting until i gets a chance that may never happen. > (hmmmmm I need to think about this more... off to bed..) I'm quite sure this is basically what Sun had to do to get signals working properly under thier implementation, the only problem is that you need a way to send a signal to a blocked instance of a thread to interrupt its sleep. Probably any externally generated signals should be delivered to the UTS, and the UTS can request that blocked doohickeys(*) be interrupted and have thier tsleep() return EINTR. (*) whatever the blockable contexts are called. -- -Alfred Perlstein [alfred@freebsd.org] Ok, who wrote this damn function called '??'? And why do my programs keep crashing in it? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 9 10:31: 3 2001 Delivered-To: freebsd-arch@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 70D0837B435 for ; Mon, 9 Jul 2001 10:30:58 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA48809; Mon, 9 Jul 2001 12:05:04 -0700 (PDT) Date: Mon, 9 Jul 2001 12:05:03 -0700 (PDT) From: Julian Elischer To: Alfred Perlstein Cc: Jason Evans , arch@freebsd.org Subject: Re: help needed in threads.. (Signals) In-Reply-To: <20010709105902.E1894@sneakerz.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 9 Jul 2001, Alfred Perlstein wrote: > > Probably any externally generated signals should be delivered to > the UTS, and the UTS can request that blocked doohickeys(*) be > interrupted and have thier tsleep() return EINTR. > > (*) whatever the blockable contexts are called. blockable contexts are called.... (drumroll).... "threads" julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 9 11:17:28 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by hub.freebsd.org (Postfix) with ESMTP id 57CFC37B406 for ; Mon, 9 Jul 2001 11:17:25 -0700 (PDT) (envelope-from fenner@research.att.com) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id AC4971E83A; Mon, 9 Jul 2001 14:17:20 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id OAA07556; Mon, 9 Jul 2001 14:17:16 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id LAA16879; Mon, 9 Jul 2001 11:17:16 -0700 (PDT) Message-Id: <200107091817.LAA16879@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: ticso@mail.cicely.de Subject: Re: nvi maintainer? Cc: arch@freebsd.org References: <200107072203.PAA09299@windsor.research.att.com> <20010708005155.J8775@canonware.com> <20010708032002.D97456@bohr.physics.purdue.edu> <20010709150739.A23210@cicely20.cicely.de> Date: Mon, 9 Jul 2001 11:17:16 -0700 Versions: dmail (solaris) 2.2g/makemail 2.9a Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG >What is wrong with nvi? Two things that are wrong with what we have: - "vi -r" failures, such as "failed to recover line NNNN". I think this is the bug that Keith says required DB3 to fix. - Dumping core when the information about the user running vi goes away between starting vi and making the first change requiring creation of a recovery file (see FreeBSD PR 3170). I run into the first one way too often. The second one isn't much of a problem for me any more since our NIS servers at AT&T are pretty reliable. Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 9 14:47:19 2001 Delivered-To: freebsd-arch@freebsd.org Received: from draco.over-yonder.net (draco.over-yonder.net [198.78.58.61]) by hub.freebsd.org (Postfix) with ESMTP id 1B30B37B403 for ; Mon, 9 Jul 2001 14:47:17 -0700 (PDT) (envelope-from gh@over-yonder.net) Received: by draco.over-yonder.net (Postfix, from userid 1012) id AC3EB62D0A; Mon, 9 Jul 2001 16:47:15 -0500 (CDT) Date: Mon, 9 Jul 2001 16:47:15 -0500 From: GH To: Bill Fenner Cc: ticso@mail.cicely.de, arch@freebsd.org Subject: Re: nvi maintainer? Message-ID: <20010709164715.F85805@over-yonder.net> References: <200107072203.PAA09299@windsor.research.att.com> <20010708005155.J8775@canonware.com> <20010708032002.D97456@bohr.physics.purdue.edu> <20010709150739.A23210@cicely20.cicely.de> <200107091817.LAA16879@windsor.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200107091817.LAA16879@windsor.research.att.com>; from fenner@research.att.com on Mon, Jul 09, 2001 at 11:17:16AM -0700 X-OS: FreeBSD Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Jul 09, 2001 at 11:17:16AM -0700, some SMTP stream spewed forth: > > >What is wrong with nvi? > > Two things that are wrong with what we have: > - "vi -r" failures, such as "failed to recover line NNNN". I think this > is the bug that Keith says required DB3 to fix. > - Dumping core when the information about the user running vi goes away > between starting vi and making the first change requiring creation of > a recovery file (see FreeBSD PR 3170). > > I run into the first one way too often. The second one isn't much of a > problem for me any more since our NIS servers at AT&T are pretty reliable. How are people planning to maintain functional and semantic compatible with nvi upon switching to a new 'vi'? 'nvi' and I have become very close friends and it troubles me to think of what would happen to anyone coming between us. > Bill gh -- > What, no one sings along with Ricky Martin anymore? My kid sister does (but then, she prefers pico to vi ...) -- Suresh Ramasubramanian, alt.sysadmin.recovery To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 9 18:10:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id C174237B401 for ; Mon, 9 Jul 2001 18:10:23 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id TAA50635; Mon, 9 Jul 2001 19:41:10 -0700 (PDT) Date: Mon, 9 Jul 2001 19:41:09 -0700 (PDT) From: Julian Elischer To: Daniel Eischen Cc: Jason Evans , arch@FreeBSD.ORG Subject: Re: help needed in threads.. (Signals) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG BTW have settled on names... ksec is gone.. please use "thread" ksegrp and kse remain. proc ksegrp kse thread After I started looking at what I was going to need to do it became obvious that the term "thread" was going to make the most sense here. (it has a 1:1 correspondence with user level threads too) On Mon, 9 Jul 2001, Daniel Eischen wrote: > The UTS needs tell the kernel to interrupt a specific blocked thread. > If the ksectx is not interruptable at its current point, then the > kernel needs to mark it as having a signal pending on it so that the > signal handler (or upcall) can be called when it either becomes > interruptable or is ready to return to userland. In my plan, the signal will be delivered on the next upcall (which could be immediatly) on ANY KSE in the process. If there are no runnable KSEs on the process, one will be made runnable to force an upcall. It will be up to you to decide what to do with it. You will have tools to help you with this, which include: 1/ The ability to pre-empt a given thread in user mode (on another processor obviously, as if it were on the same processor then it obviously has already been pre-empted. 2/ The ability to (try) abort with a signal, any thread that is blocked in the kernel. 3/ The ability to make a thread yield and do an upcall on return from a non-blocking syscall. (these may be the same call) As I see it, a thread is in 4 states: 1/ In userspace, Not running 2/ In userspace, running 3/ In kernel, blocked 4/ In kernel, running (Only in SMP, on another processor) transitional states are not considered as they should be locked.. #1 requires no assistance #2,3,4 require kernel asistance to ensure that the UTS can take control of the thread to ensure it receives the signal. > > The UTS cannot deliver the signal until the kernel tells it that the > ksectx is either interruptable or completed. I'm not quite sure what > happens in a normal trampoline; if a signal handler completes > normally, does it go back to the same spot in the kernel to finish its > work (assume SA_RESTART is set)? No, the syscall is restarted from the beginning I think. I'll check. the whole restart thing is a can of worms Does the posix threads spec say that syscalls should be restartable? Maybe we can say "no, not under threads they aren't". > If so, I think the interrupted > ksectx needs to be set to the current ksectx when the interruption > occurs. The UTS has no idea whether the invoked signal handler is > going to return normally or not. (If the signal handler longjmps out > of the handler, you need to make sure the ksectx isn't left forever in > the kernel.) I would say that the thread always returns all the way out of the kernel, and if the library wants it to be restartable, it can do it itself. Basically the syscall returns and is 'yield()ed as normal, and then an upcall occurs with notification about the signal. > > > I guess I should ignore all signals when in KSE mode and just pass them up > > as an upcall. > > (The kernel interface and the user interface need not be the same). > > > > This indicates that a signal pre-empts whatever is running to do an upcall > > rather than > > waiting until i gets a chance that may never happen. > > (hmmmmm I need to think about this more... off to bed..) > > On a related note, the UTS needs another system call to send a > message from one KSE to another (possibly set of) KSEs. The > UTS does direct handoff of mutexes, condition variables, and > other things. If the handoff is to a thread running (now > waiting) on another KSE or KSEG, then the we need to be able > to "signal" it that that thread should now be runnable. > A similar thing for signals. If the thread that needs the > signal dispatched is scheduled on another KSE, then we > need to send that KSE a message to inform it of that. I > say "possibly set of" KSEs because of pthread_cond_broadcast(). The waiting thread is not going to be in kernel space.. It will be waiting in userspace. All that will be needed is a call to bring back to life any previously surplus KSEs. I'm not sure how the kernel gets involved here.. > > -- > Dan Eischen > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 9 18:15:54 2001 Delivered-To: freebsd-arch@freebsd.org Received: from magnesium.net (toxic.magnesium.net [207.154.84.15]) by hub.freebsd.org (Postfix) with SMTP id 1C27137B403 for ; Mon, 9 Jul 2001 18:15:52 -0700 (PDT) (envelope-from jasone@magnesium.net) Received: (qmail 16433 invoked by uid 1142); 10 Jul 2001 01:16:34 -0000 Date: 9 Jul 2001 18:16:34 -0700 Date: Mon, 9 Jul 2001 18:15:42 -0700 From: Jason Evans To: Julian Elischer Cc: Daniel Eischen , arch@FreeBSD.ORG Subject: Re: help needed in threads.. (Signals) Message-ID: <20010709181542.E8775@canonware.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from julian@elischer.org on Mon, Jul 09, 2001 at 07:41:09PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Jul 09, 2001 at 07:41:09PM -0700, Julian Elischer wrote: > > > > The UTS cannot deliver the signal until the kernel tells it that the > > ksectx is either interruptable or completed. I'm not quite sure what > > happens in a normal trampoline; if a signal handler completes > > normally, does it go back to the same spot in the kernel to finish its > > work (assume SA_RESTART is set)? > > No, the syscall is restarted from the beginning I think. > I'll check. > > the whole restart thing is a can of worms > Does the posix threads spec say that syscalls should be restartable? > Maybe we can say "no, not under threads they aren't". I don't think we can do that. A program should be able to rely on system calls being interrupted as part of its signal recovery logic. Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 9 19:30:35 2001 Delivered-To: freebsd-arch@freebsd.org Received: from shell.futuresouth.com (shell.futuresouth.com [198.78.58.28]) by hub.freebsd.org (Postfix) with ESMTP id CC5E737B401 for ; Mon, 9 Jul 2001 19:30:22 -0700 (PDT) (envelope-from tim@futuresouth.com) Received: (from tim@localhost) by shell.futuresouth.com (8.11.1/8.11.1) id f6A2U8n19385; Mon, 9 Jul 2001 21:30:08 -0500 (CDT) Date: Mon, 9 Jul 2001 21:30:08 -0500 From: Tim To: GH Cc: Bill Fenner , ticso@mail.cicely.de, arch@FreeBSD.ORG Subject: Re: nvi maintainer? Message-ID: <20010709213007.A18204@futuresouth.com> References: <200107072203.PAA09299@windsor.research.att.com> <20010708005155.J8775@canonware.com> <20010708032002.D97456@bohr.physics.purdue.edu> <20010709150739.A23210@cicely20.cicely.de> <200107091817.LAA16879@windsor.research.att.com> <20010709164715.F85805@over-yonder.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="ZPt4rx8FFjLCG7dd" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010709164715.F85805@over-yonder.net>; from grasshacker@over-yonder.net on Mon, Jul 09, 2001 at 04:47:15PM -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --ZPt4rx8FFjLCG7dd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline % alias vi vim I think 99% of the people wouldn't notice if you just put vim in place of vi. I don't claim to know or have used most of vi's features, but I have used vi on a near daily basis for over ten years and put in the above alias about a year ago. Haven't noticed any problems of note. Check out the vi maze solver attached (edit the maze4vi file, or include output from the popular maze program, :source vi-mazer, and type "g") - nvi and vim both run it fine. Tim On Mon, Jul 09, 2001 at 04:47:15PM -0500, GH wrote: > On Mon, Jul 09, 2001 at 11:17:16AM -0700, some SMTP stream spewed forth: > > >What is wrong with nvi? > > > > Two things that are wrong with what we have: > > - "vi -r" failures, such as "failed to recover line NNNN". I think this > > is the bug that Keith says required DB3 to fix. > > - Dumping core when the information about the user running vi goes away > > between starting vi and making the first change requiring creation of > > a recovery file (see FreeBSD PR 3170). > > > > I run into the first one way too often. The second one isn't much of a > > problem for me any more since our NIS servers at AT&T are pretty reliable. > > How are people planning to maintain functional and semantic compatible > with nvi upon switching to a new 'vi'? 'nvi' and I have become very close > friends and it troubles me to think of what would happen to anyone coming > between us. > > > Bill > > gh > > -- > > What, no one sings along with Ricky Martin anymore? > My kid sister does (but then, she prefers pico to vi ...) > -- Suresh Ramasubramanian, alt.sysadmin.recovery > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message --ZPt4rx8FFjLCG7dd Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=maze4vi ._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._ | ._| . . ._| | |_._._. . ._|_._._._._. ._|_. ._|_._. ._| | . ._|_. | . ._._. . | ._|_| |_. | | | | ._._|_._|_._. . |_. | | | ._._| |_._._._| | ._. ._| . . |_| |_._._._. | ._|_. ._._._. | | ._. |_._. . | ._._| |_. | . ._._._. |_. | |_|_| | | | . |_._| . ._._._| ._._. ._._| | | |_| . | |_. . ._|_|_| ._._. |_._|_| . | | |_._|_._._._|_._._._|_|_._._._|_._|_._._._|_._._._|_._._._._|_._._._._._._|_._| | --ZPt4rx8FFjLCG7dd Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=vi-mazer Content-Transfer-Encoding: quoted-printable " These macros 'solve' any maze produced by the a-maze-ing maze.c program. "=20 " First, a bit of maze theory. " If you were put into a maze, a guaranteed method of finding your way " out of the maze is to put your left hand onto a wall and just keep walkin= g, " never taking your hand off the wall. This technique is only guaranteed to " work if the maze does not have any 'islands', or if the 'exit' is on the " same island as your starting point. These conditions hold for the mazes " under consideration. "=20 " Assuming that the maze is made up of horizontal and vertical walls spaced " one step apart and that you can move either north, south, east or west, " then you can automate this procedure by carrying out the following steps. "=20 " 1. Put yourself somewhere in the maze near a wall. " 2. Check if you have a wall on your left. If so, go to step 4. " 3. There is no wall on your left, so turn on the spot to your left and st= ep " forward by one step and repeat step 2. " 4. Check what is directly in front of you. If it is a wall, turn on the " spot to your right by 90 degrees and repeat step 4. " 5. There is no wall in front of you, so step forward one step and " go to step 2. "=20 " In this way you will cover all the corridors of the maze (until you get b= ack " to where you started from, if you do not stop). "=20 " By examining a maze produced by the maze.c program you will see that=20 " each square of the maze is one character high and two characters wide. " To go north or south, you move by a one character step, but to move east = or " west you move by a two character step. Also note that in any position " there are four places where walls could be put - to the north, to the sou= th, " to the east and to the west. " A wall exists to the north of you if the character to the north of " you is a _ (otherwise it is a space). " A wall exists to the east of you if the character to the east of you " is a | (otherwise it is a .). " A wall exists to the west of you if the character to the west of you " is a | (otherwise it is a .). " A wall exists to the south of you if the character where you are " is a _ (otherwise it is a space). "=20 " Note the difference for direction south, where we must examine the charac= ter " where the cursor is rather than an adjacent cell. "=20 " If you were implementing the above procedure is a normal computer language " you could use a loop with if statements and continue statements,=20 " However, these constructs are not available in vi macros so I have used " a state machine with 8 states. Each state signifies the direction you " are going in and whether or not you have checked if there is a wall on " your left. "=20 " The transition from state to state and the actions taken on each transiti= on " are given in the state table below. " The names of the states are N1, N2, S1, S2, E1, E2, W1, W2, where each le= tter " stands for a direction of the compass, the number 1 indicates that the we " have not yet checked to see if there is a wall on our left and the number= 2 " indicates that we have checked and there is a wall on our left. "=20 " For each state we must consider the existence or not of a wall in a " particular direction. This direction is given in the following table. "=20 " NextChar table: " state direction vi commands " N1 W hF " N2 N kF " S1 E lF " S2 S F " E1 N kF " E2 E lF " W1 S F " W2 W hF "=20 " where F is a macro which yanks the character under the cursor into " the NextChar register (n). "=20 " State table: " In the 'vi commands' column is given the actions to carry out when in " this state and the NextChar is as given. The commands k, j, ll, hh move " the current position north, south, east and west respectively. The " command mm is used as a no-op command. " In the 'next state' column is given the new state of the machine after " the action is carried out. "=20 " current state NextChar vi commands next state " N1 . hh W1 " N1 | mm N2 " N2 _ mm E1 " N2 space k N1 " S1 . ll E1 " S1 | mm S2 " S2 _ mm W1 " S2 space j S1 " E1 space k N1 " E1 _ mm E2 " E2 | mm S1 " E2 . ll E1 " W1 space j S1 " W1 _ mm W2 " W2 | mm N1 " W2 . hh W1 " "=20 " Complaint about vi macros: " It seems that you cannot have more than one 'undo-able' vi command " in the one macro, so you have to make lots of little macros and " put them together. " " I'll explain what I mean by an example. Edit a file and " type ':map Q rXY'. This should map the Q key to 'replace the " character under the cursor with X and yank the line'. " But when I type Q, vi tells me 'Can't yank inside global/macro' and " goes into ex mode. However if I type ':map Q rXT' and ':map T Y', " everything is OK. I`m doing all this on a Sparcstation. " If anyone reading this has an answer to this problem, the author would " love to find out. Mail to gregm@otc.otca.oz.au. " " The macros: " The macro to run the maze solver is 'g'. This simply calls two other " macros: I, to initialise everything, and L, to loop forever running " through the state table. " Both of these macros are long sequences of calls to other macros. All " of these other macros are quite simple and so to understand how this " works, all you need to do is examine macros I and L and learn what they " do (a simple sequence of vi actions) and how L loops (by calling U, which " simply calls L again). " " Macro I sets up the state table and NextChar table at the end of the file. " Macro L then searches these tables to find out what actions to perform and " what state changes to make. " " The entries in the state table all begin with a key consisting of the " letter 's', the current state and the NextChar. After this is the " action to take in this state and after this is the next state to change t= o. " " The entries in the NextChar table begin with a key consisting of the " letter 'n' and the current state. After this is the action to take to " obtain NextChar - the character that must be examined to change state. " " One way to see what each part of the macros is doing is to type in the " body of the macros I and L manually (instead of typing 'g') and see " what happens at each step. " " Good luck. " " Registers used by the macros: " s (State) - holds the state the machine is in " c (Char) - holds the character under the current position " m (Macro) - holds a vi command string to be executed later " n (NextChar) - holds the character we must examine to change state " r (Second Macro) - holds a second vi command string to be executed later " set remap set nomagic set noterse set wrapscan " "=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D " g - go runs the whole show " I - initialise " L - then loop forever map g IL " "=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D " I - initialise everything before running the loop " G$?.^M - find the last . in the maze " ^ - replace it with an X (the goal) " GYKeDP - print the state table and next char table at the end of the fi= le " 0S - initialise the state of the machine to E1 " 2Gl - move to the top left cell of the maze map I G$?.=0D^GYKeDP0S2Gl " "=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D " L - the loop which is executed forever " Q - save the current character in the Char register " A - replace the current character with an 'O' " ma - mark the current position with mark 'a' " GNB - on bottom line, create a command to search the NextChar table " for the current state " 0M0E@m^M - yank the command into the Macro register and execute it " wX - we have now found the entry in the table, now yank the " following word into the Macro register " `a@m - go back to the current position and execute the macro, this wi= ll " yank the NextChar in register n " GT$B$R - on bottom line, create a command to search the state table " for the current state and NextChar " 0M0E@m^M - yank the command into the Macro register and execute it " 2WS - we have now found the entry in the table, now yank the " next state into the State macro " bX - and yank the action corresponding to this state table entry " into the Macro register " GVJ - on bottom line, create a command to restore the current charac= ter " 0H - and save the command into the second Macro register " `a@r - go back to the current position and exectute the macro to rest= ore " the current character " @m - execute the action associated with this state " U - and repeat map L QAmaGNB0M0E@m=0DwX`a@mGT$B$R0M0E@m=0D2WSbXGVJ0H`a@r@mU " "=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D " U - no tail recursion allowed in vi macros so cheat and set U =3D L map U L " "=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D " S - yank the next two characters into the State register map S "sy2l " "=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D " Q - save the current character in the Char register map Q "cyl " "=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D " A - replace the current character with an 'O' map A rO " "=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D " N - replace this line with the string 'n' map N C/n=1B " "=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D " B - put the current state map B "sp " "=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D " M - yank this line into the Macro register map M "my$ " "=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D " E - delete to the end of the line map E d$ " "=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D " X - yank this word into the Macro register map X "myt=20 " "=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D " T - replace this line with the string 's' map T C/s=1B " "=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D " R - put NextChar map R "np " "=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D " V - add the letter 'r' (the replace vi command) map V ar=1B " "=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D " J - restore the current character map J "cp " "=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D " H - yank this line into the second Macro register map H "ry$ " "=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D " F - yank NextChar (this macro is called from the Macro register) map F "nyl " "=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D " ^ - replace the current character with an 'X' map ^ rX " "=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D " YKeDP - create the state table, NextChar table and initial state " Note that you have to escape the bar character, since it is special to " the map command (it indicates a new line). map Y osE1 k N1 sE1_ mm E2 sE2=16| mm S1 sE2. ll E1=1B map K osW1 j S1 sW1_ mm W2 sW2=16| mm N1 sW2. hh W1=1B map e osN1. hh W1 sN1=16| mm N2 sN2 k N1 sN2_ mm E1=1B map D osS1. ll E1 sS1=16| mm S2 sS2 j S1 sS2_ mm W1=1B map P onE1 kF nE2 lF nW1 G$JF nW2 hF nN1 hF nN2 kF nS1 lF nS2 G$JF =0DE1= =1B --ZPt4rx8FFjLCG7dd-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 9 21:24:33 2001 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id CCA3637B401 for ; Mon, 9 Jul 2001 21:24:27 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id AAA10229; Tue, 10 Jul 2001 00:23:40 -0400 (EDT) Date: Tue, 10 Jul 2001 00:23:40 -0400 (EDT) From: Daniel Eischen To: Julian Elischer Cc: Jason Evans , arch@FreeBSD.ORG Subject: Re: help needed in threads.. (Signals) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 9 Jul 2001, Julian Elischer wrote: > > BTW have settled on names... > ksec is gone.. please use "thread" > ksegrp and kse remain. OK, but it is confusing to refer to thread in userland and thread (context) in kernel. It's not immediately obvious which one is being referred to. > On Mon, 9 Jul 2001, Daniel Eischen wrote: > > > The UTS needs tell the kernel to interrupt a specific blocked thread. > > If the ksectx is not interruptable at its current point, then the > > kernel needs to mark it as having a signal pending on it so that the > > signal handler (or upcall) can be called when it either becomes > > interruptable or is ready to return to userland. > > In my plan, the signal will be delivered on > the next upcall (which could be immediatly) > on ANY KSE in the process. If there are no runnable KSEs > on the process, one will be made runnable to force an upcall. Yes, I think we've talked about that. I don't have any problem with it. I'm now only concerned about how to deliver the signal to the correct thread (after the original upcall). > It will be up to you to decide what to do with it. > You will have tools to help you with this, which include: > 1/ The ability to pre-empt a given thread in user mode (on another > processor obviously, as if it were on the same processor then it obviously > has already been pre-empted. Does each KSE always start (after being preempted) with an upcall? We don't want to use the Linux method of communication between threads (using signals). I just want to make sure that we have all the tools necessary to make this work. > 2/ The ability to (try) abort with a signal, any thread that is blocked in > the kernel. > 3/ The ability to make a thread yield and do an upcall > on return from a non-blocking syscall. > (these may be the same call) > > As I see it, a thread is in 4 states: > 1/ In userspace, Not running > 2/ In userspace, running > 3/ In kernel, blocked > 4/ In kernel, running (Only in SMP, on another processor) > > transitional states are not considered as they should be locked.. > #1 requires no assistance > #2,3,4 require kernel asistance to ensure that the UTS can > take control of the thread to ensure it receives the signal. > > The UTS cannot deliver the signal until the kernel tells it that the > > ksectx is either interruptable or completed. I'm not quite sure what > > happens in a normal trampoline; if a signal handler completes > > normally, does it go back to the same spot in the kernel to finish its > > work (assume SA_RESTART is set)? > > No, the syscall is restarted from the beginning I think. > I'll check. > > the whole restart thing is a can of worms > Does the posix threads spec say that syscalls should be restartable? > Maybe we can say "no, not under threads they aren't". I don't think it wise to go down this road. If at all possible, and I don't see why it would be that difficult, we should make system calls behave the same in a threaded program as they would in an unthreaded program. We already handle this in an unthreaded environment. I don't think POSIX makes an exception for this in a threaded environment; I'll check to make sure. We also don't want to have the threads library wrap these system calls to produce the correct behaviour. > > If so, I think the interrupted > > ksectx needs to be set to the current ksectx when the interruption > > occurs. The UTS has no idea whether the invoked signal handler is > > going to return normally or not. (If the signal handler longjmps out > > of the handler, you need to make sure the ksectx isn't left forever in > > the kernel.) > > I would say that the thread always returns all the way out of the > kernel, and if the library wants it to be restartable, it can do it > itself. I don't agree with this. The kernel knows whether the system call is restartable. We don't want to do this in the threads library (see above). All we basically need to do is the same thing we do in an unthreaded application, except that we do it under direction of the UTS (via a new system call). The sigacts can even be used to pull out the address of the handler since it will be unused for normal (initial) signal delivery. Here's what I'd like to see: __sys_kse_kill(int kse_id, int sig) If the kse_id (or thread id, whatever we use to identify the thread blocked in the kernel) is interruptible, the kernel makes the thread (kse context) current, copies out the trampoline code as it would in an unthreaded environment (ignoring sigstack and using the threads user stack), and returns to the installed signal handler. If the kse_id (thread) is not interruptible, it marks the signal as pending (only on that thread) and returns an appropriate error to denote that the thread is busy and will be interrupted as soon as possible. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 9 23:10:13 2001 Delivered-To: freebsd-arch@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 3BE1937B406 for ; Mon, 9 Jul 2001 23:10:07 -0700 (PDT) (envelope-from julian@elischer.org) Received: from elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id AAA51657; Tue, 10 Jul 2001 00:56:43 -0700 (PDT) Message-ID: <3B4A9AC1.BE93ECCF@elischer.org> Date: Mon, 09 Jul 2001 23:03:45 -0700 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Daniel Eischen Cc: Jason Evans , arch@FreeBSD.ORG Subject: Re: help needed in threads.. (Signals) References: Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Daniel Eischen wrote: > > On Mon, 9 Jul 2001, Julian Elischer wrote: > > > > BTW have settled on names... > > ksec is gone.. please use "thread" > > ksegrp and kse remain. > > OK, but it is confusing to refer to thread in userland and > thread (context) in kernel. It's not immediately obvious > which one is being referred to. They bare the same relationship to each other as a proc in user mode and a proc in the kernel.. i.e they are the same thing.. When a user thread crosses into the kernel, it is represented by the kernel 'thread' structure. > > > On Mon, 9 Jul 2001, Daniel Eischen wrote: > > > > > The UTS needs tell the kernel to interrupt a specific blocked thread. > > > If the ksectx is not interruptable at its current point, then the > > > kernel needs to mark it as having a signal pending on it so that the > > > signal handler (or upcall) can be called when it either becomes > > > interruptable or is ready to return to userland. > > > > In my plan, the signal will be delivered on > > the next upcall (which could be immediatly) > > on ANY KSE in the process. If there are no runnable KSEs > > on the process, one will be made runnable to force an upcall. > > Yes, I think we've talked about that. I don't have any problem > with it. I'm now only concerned about how to deliver the signal > to the correct thread (after the original upcall). > > > It will be up to you to decide what to do with it. > > You will have tools to help you with this, which include: > > 1/ The ability to pre-empt a given thread in user mode (on another > > processor obviously, as if it were on the same processor then it obviously > > has already been pre-empted. > > Does each KSE always start (after being preempted) with an upcall? This is up for discussion but generally: yes > > We don't want to use the Linux method of communication between > threads (using signals). I just want to make sure that we have > all the tools necessary to make this work. > how threads communicate with each other when they are on different processors is tricky.. what is wrong with 'shared memory'? All that a signal can do is leave a flag for the mainline to find which is effectively shared memory anyhow.. > I don't think it wise to go down this road. If at all possible, > and I don't see why it would be that difficult, we should make > system calls behave the same in a threaded program as they would > in an unthreaded program. We already handle this in an unthreaded > environment. I don't think POSIX makes an exception for this in > a threaded environment; I'll check to make sure. I'm still trying to work out how exactly restartable syscalls are achieved. > > We also don't want to have the threads library wrap these system > calls to produce the correct behaviour. that's a good point. > > > > If so, I think the interrupted > > > ksectx needs to be set to the current ksectx when the interruption > > > occurs. The UTS has no idea whether the invoked signal handler is > > > going to return normally or not. (If the signal handler longjmps out > > > of the handler, you need to make sure the ksectx isn't left forever in > > > the kernel.) > > > > I would say that the thread always returns all the way out of the > > kernel, and if the library wants it to be restartable, it can do it > > itself. > > I don't agree with this. The kernel knows whether the system call > is restartable. We don't want to do this in the threads library > (see above). All we basically need to do is the same thing we > do in an unthreaded application, except that we do it under direction > of the UTS (via a new system call). The sigacts can even be used > to pull out the address of the handler since it will be unused > for normal (initial) signal delivery. > > Here's what I'd like to see: > > __sys_kse_kill(int kse_id, int sig) > > If the kse_id (or thread id, whatever we use to identify the thread > blocked in the kernel) is interruptible, the kernel makes the thread > (kse context) current, copies out the trampoline code as it would in > an unthreaded environment (ignoring sigstack and using the threads > user stack), and returns to the installed signal handler. If the > kse_id (thread) is not interruptible, it marks the signal as pending > (only on that thread) and returns an appropriate error to denote that > the thread is busy and will be interrupted as soon as possible. my head hurts trying to figure out how to do that but I'll work on it.. > > -- > Dan Eischen -- +------------------------------------+ ______ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ julian@elischer.org +------>x USA \ a very strange | ( OZ ) \___ ___ | country ! +- X_.---._/ presently in San Francisco \_/ \\ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 10 5:24:22 2001 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 3B9AD37B403 for ; Tue, 10 Jul 2001 05:24:17 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id IAA07387; Tue, 10 Jul 2001 08:23:34 -0400 (EDT) Date: Tue, 10 Jul 2001 08:23:33 -0400 (EDT) From: Daniel Eischen To: Julian Elischer Cc: Jason Evans , arch@FreeBSD.ORG Subject: Re: help needed in threads.. (Signals) In-Reply-To: <3B4A9AC1.BE93ECCF@elischer.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 9 Jul 2001, Julian Elischer wrote: > Daniel Eischen wrote: > > > > Does each KSE always start (after being preempted) with an upcall? > > This is up for discussion but generally: > yes OK, good. This allows the upcall to look for any pending messages (from other KSEs) before it resumes/starts a thread. > > We don't want to use the Linux method of communication between > > threads (using signals). I just want to make sure that we have > > all the tools necessary to make this work. > > > > how threads communicate with each other when they are on different processors > is tricky.. > what is wrong with 'shared memory'? > > All that a signal can do is leave a flag for the mainline to find > which is effectively shared memory anyhow.. Right, it just makes it harder because you may have to use locks to protect this 'shared memory', and you'll be doing this from the UTS (upcall). If there was a general way to send messages between KSEs, I think it would be a lot cleaner. But if each each KSE is always started with an upcall, then that gives it a chance to look for any pending messages. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 10 14:28:39 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 9C1A237B407 for ; Tue, 10 Jul 2001 14:28:34 -0700 (PDT) (envelope-from des@ofug.org) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id XAA65413; Tue, 10 Jul 2001 23:28:28 +0200 (CEST) (envelope-from des@ofug.org) 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: Tim Cc: GH , Bill Fenner , ticso@mail.cicely.de, arch@FreeBSD.ORG Subject: Re: nvi maintainer? References: <200107072203.PAA09299@windsor.research.att.com> <20010708005155.J8775@canonware.com> <20010708032002.D97456@bohr.physics.purdue.edu> <20010709150739.A23210@cicely20.cicely.de> <200107091817.LAA16879@windsor.research.att.com> <20010709164715.F85805@over-yonder.net> <20010709213007.A18204@futuresouth.com> From: Dag-Erling Smorgrav Date: 10 Jul 2001 23:28:27 +0200 In-Reply-To: <20010709213007.A18204@futuresouth.com> Message-ID: Lines: 10 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Tim writes: > I think 99% of the people wouldn't notice if you just put vim in place > of vi. Wrong. The different undo semantics would surprise (and piss off) a lot of people. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 10 14:39:15 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by hub.freebsd.org (Postfix) with ESMTP id 41DB837B405 for ; Tue, 10 Jul 2001 14:39:13 -0700 (PDT) (envelope-from fenner@research.att.com) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 848FB4D3A8 for ; Tue, 10 Jul 2001 17:39:09 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id RAA08975 for ; Tue, 10 Jul 2001 17:39:08 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id OAA24593; Tue, 10 Jul 2001 14:39:07 -0700 (PDT) Message-Id: <200107102139.OAA24593@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: arch@freebsd.org Subject: Re: nvi maintainer? References: <200107072203.PAA09299@windsor.research.att.com> <20010708005155.J8775@canonware.com> <20010708032002.D97456@bohr.physics.purdue.edu> <20010709150739.A23210@cicely20.cicely.de> <200107091817.LAA16879@windsor.research.att.com> <20010709164715.F85805@over-yonder.net> <20010709213007.A18204@futuresouth.com> Date: Tue, 10 Jul 2001 14:39:07 -0700 Versions: dmail (solaris) 2.2g/makemail 2.9a Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Dag-Erling Smorgrav said: >Tim writes: >> I think 99% of the people wouldn't notice if you just put vim in place >> of vi. > >Wrong. The different undo semantics would surprise (and piss off) a >lot of people. Indeed. The two things that I notice most about vim vs vi are: - Different undo semantics. I can never remember vim's so I always revert to single-level undo when using vim. - Different split-screen modes, both in how to split and how to navigate. I can usually manage to handle this one on the fly, usually by getting an error or two and then switching brain modes. Having these semantics change when just upgrading the OS would be sure to piss people off. I was sure pissed when csh stopped paying attention to the werase character by virtue of quietly becoming tcsh. Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 10 15:43:32 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 8124837B409 for ; Tue, 10 Jul 2001 15:43:29 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.3/8.11.2) id f6AMgoO20085; Tue, 10 Jul 2001 15:42:50 -0700 (PDT) (envelope-from dillon) Date: Tue, 10 Jul 2001 15:42:50 -0700 (PDT) From: Matt Dillon Message-Id: <200107102242.f6AMgoO20085@earth.backplane.com> To: Dag-Erling Smorgrav Cc: Tim , GH , Bill Fenner , ticso@mail.cicely.de, arch@FreeBSD.ORG Subject: Re: nvi maintainer? References: <200107072203.PAA09299@windsor.research.att.com> <20010708005155.J8775@canonware.com> <20010708032002.D97456@bohr.physics.purdue.edu> <20010709150739.A23210@cicely20.cicely.de> <200107091817.LAA16879@windsor.research.att.com> <20010709164715.F85805@over-yonder.net> <20010709213007.A18204@futuresouth.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :Tim writes: :> I think 99% of the people wouldn't notice if you just put vim in place :> of vi. : :Wrong. The different undo semantics would surprise (and piss off) a :lot of people. : :DES :-- :Dag-Erling Smorgrav - des@ofug.org I live for undo. vim doesn't do it right. Also, vim creates '.BLAH.swp' files in the same directory as the file you are editing, even if you do not modify the file, which are unbelievably annoying. And vim's split screen stuff is aweful. It is far too easy to accidently get into split screen mode. I would be very pissed if someone ripped out nvi. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 10 15:48:36 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [206.40.252.115]) by hub.freebsd.org (Postfix) with ESMTP id 48BBC37B409 for ; Tue, 10 Jul 2001 15:48:32 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f6AMmQH99580; Tue, 10 Jul 2001 15:48:26 -0700 (PDT) (envelope-from obrien) Date: Tue, 10 Jul 2001 15:48:26 -0700 From: "David O'Brien" To: Matt Dillon Cc: arch@FreeBSD.ORG Subject: Re: nvi maintainer? Message-ID: <20010710154825.B98432@dragon.nuxi.com> Reply-To: arch@FreeBSD.ORG References: <200107072203.PAA09299@windsor.research.att.com> <20010708005155.J8775@canonware.com> <20010708032002.D97456@bohr.physics.purdue.edu> <20010709150739.A23210@cicely20.cicely.de> <200107091817.LAA16879@windsor.research.att.com> <20010709164715.F85805@over-yonder.net> <20010709213007.A18204@futuresouth.com> <200107102242.f6AMgoO20085@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200107102242.f6AMgoO20085@earth.backplane.com>; from dillon@earth.backplane.com on Tue, Jul 10, 2001 at 03:42:50PM -0700 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 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Jul 10, 2001 at 03:42:50PM -0700, Matt Dillon wrote: > I live for undo. vim doesn't do it right. Blah. Vim does it *TOTALLY CORRECT*. nvi's sucks. > And vim's split screen stuff is aweful. It is far too easy to accidently > get into split screen mode. See above correcting your backwards statements of vim vs. nvi. -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 10 16: 6:42 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id BFEB037B409 for ; Tue, 10 Jul 2001 16:06:40 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.3/8.11.2) id f6AN6e820560; Tue, 10 Jul 2001 16:06:40 -0700 (PDT) (envelope-from dillon) Date: Tue, 10 Jul 2001 16:06:40 -0700 (PDT) From: Matt Dillon Message-Id: <200107102306.f6AN6e820560@earth.backplane.com> To: "David O'Brien" Cc: arch@FreeBSD.ORG Subject: Re: nvi maintainer? References: <200107072203.PAA09299@windsor.research.att.com> <20010708005155.J8775@canonware.com> <20010708032002.D97456@bohr.physics.purdue.edu> <20010709150739.A23210@cicely20.cicely.de> <200107091817.LAA16879@windsor.research.att.com> <20010709164715.F85805@over-yonder.net> <20010709213007.A18204@futuresouth.com> <200107102242.f6AMgoO20085@earth.backplane.com> <20010710154825.B98432@dragon.nuxi.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG : :On Tue, Jul 10, 2001 at 03:42:50PM -0700, Matt Dillon wrote: :> I live for undo. vim doesn't do it right. : :Blah. Vim does it *TOTALLY CORRECT*. nvi's sucks. : :> And vim's split screen stuff is aweful. It is far too easy to accidently :> get into split screen mode. : :See above correcting your backwards statements of vim vs. nvi. : :-- :-- David (obrien@FreeBSD.org) I'm sorry Dave, but it's a matter of opinion. I strongly believe that vim does it incorrectly. You can believe otherwise, but that's doesn't mean my statement is backwards any more then yours is. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 10 16:10:39 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [206.40.252.115]) by hub.freebsd.org (Postfix) with ESMTP id 8C96437B408 for ; Tue, 10 Jul 2001 16:10:37 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f6ANAao00115; Tue, 10 Jul 2001 16:10:36 -0700 (PDT) (envelope-from obrien) Date: Tue, 10 Jul 2001 16:10:36 -0700 From: arch@FreeBSD.ORG To: Matt Dillon Cc: arch@FreeBSD.ORG Subject: Re: nvi maintainer? Message-ID: <20010710161036.C98432@dragon.nuxi.com> Reply-To: arch@FreeBSD.ORG References: <20010708005155.J8775@canonware.com> <20010708032002.D97456@bohr.physics.purdue.edu> <20010709150739.A23210@cicely20.cicely.de> <200107091817.LAA16879@windsor.research.att.com> <20010709164715.F85805@over-yonder.net> <20010709213007.A18204@futuresouth.com> <200107102242.f6AMgoO20085@earth.backplane.com> <20010710154825.B98432@dragon.nuxi.com> <200107102306.f6AN6e820560@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200107102306.f6AN6e820560@earth.backplane.com>; from dillon@earth.backplane.com on Tue, Jul 10, 2001 at 04:06:40PM -0700 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 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Jul 10, 2001 at 04:06:40PM -0700, Matt Dillon wrote: > I'm sorry Dave, "David" please. :-) > but it's a matter of opinion. .. > but that's doesn't > mean my statement is backwards any more then yours is. Exactly! :-) I was hoping people would get that idea and stop arging on the issue of split screen and undo. 40% of us feel nvi gets it wrong, another 40% feel vim gets it wrong, and the other 20% have never used multiple windows in any flavor of vi. -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 10 16:20:10 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id AE4DC37B405 for ; Tue, 10 Jul 2001 16:20:07 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.3/8.11.2) id f6ANK7020780; Tue, 10 Jul 2001 16:20:07 -0700 (PDT) (envelope-from dillon) Date: Tue, 10 Jul 2001 16:20:07 -0700 (PDT) From: Matt Dillon Message-Id: <200107102320.f6ANK7020780@earth.backplane.com> To: arch@FreeBSD.ORG Subject: Re: nvi maintainer? References: <20010708005155.J8775@canonware.com> <20010708032002.D97456@bohr.physics.purdue.edu> <20010709150739.A23210@cicely20.cicely.de> <200107091817.LAA16879@windsor.research.att.com> <20010709164715.F85805@over-yonder.net> <20010709213007.A18204@futuresouth.com> <200107102242.f6AMgoO20085@earth.backplane.com> <20010710154825.B98432@dragon.nuxi.com> <200107102306.f6AN6e820560@earth.backplane.com> <20010710161036.C98432@dragon.nuxi.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :On Tue, Jul 10, 2001 at 04:06:40PM -0700, Matt Dillon wrote: :> I'm sorry Dave, : :"David" please. :-) : :> but it's a matter of opinion. :.. :> but that's doesn't :> mean my statement is backwards any more then yours is. : :Exactly! :-) I was hoping people would get that idea and stop arging on :the issue of split screen and undo. 40% of us feel nvi gets it wrong, :another 40% feel vim gets it wrong, and the other 20% have never used :multiple windows in any flavor of vi. : :-- :-- David (obrien@FreeBSD.org) Well, ah, David, that simply argues for the status-quo, yes? Perhaps the correct solution is to introduce a PREFER_VIM make.conf variable so when you install the port (or buildworld if we incorporated vim's sources into contrib), you get vi hardlinked to vim instead of nvi. I've personally used at least four different vi's, possibly five or six. Linuxized, nvi, vim, the original vi (CSRG era), and one or two other knockoffs. nvi is closest to the original in terms of avoiding finger foulups. The rest do all sorts of weird things. The Linuxized vi uses the alternative terminal screen switch that drives me absolutely nuts, vim turns simple finger foulups into disasters and creates working files in the wrong place, and the other knockoffs skip many of the shortcuts the original vi had, like d/, G, etc etc etc. Yuch, Ich, Bleh, sputter. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 10 18:18:35 2001 Delivered-To: freebsd-arch@freebsd.org Received: from abyssinian.sleepycat.com (abyssinian.sleepycat.com [199.103.241.218]) by hub.freebsd.org (Postfix) with ESMTP id 6F55D37B403 for ; Tue, 10 Jul 2001 18:18:30 -0700 (PDT) (envelope-from bostic@abyssinian.sleepycat.com) Received: (from bostic@localhost) by abyssinian.sleepycat.com (8.10.1/8.10.1) id f6B1IQE24540; Tue, 10 Jul 2001 21:18:26 -0400 (EDT) Date: Tue, 10 Jul 2001 21:18:26 -0400 (EDT) From: Keith Bostic Message-Id: <200107110118.f6B1IQE24540@abyssinian.sleepycat.com> To: karels@bsdi.com Subject: Re: nvi maintainer? Cc: arch@hub.freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > I just re-subscribed to freebsd-arch, and to my surprise there is a current > discussion on nvi (the first message saying "no, people would object if we > switched to vim"). Are you on this list? Peripherally -- I'm not on the list, but I've been participating in the discussion via email. This happens every 4-6 months and it's become pretty predictable: Step 1: A FreeBSD person says "We should put DB 3.X into the system, DB 1.85 has known bugs and isn't maintained by Sleepycat." Step 2: I say, "I'd love it, I think it's a great idea, here are the issues." Step 3: Someone else says "That's bad, we can't do that, it would be a problem for our embedded users." Step 4: Someone else says "Nvi will require DB 3 in the next release, so we'll have to switch to DB 3 in the C library." Step 5: Someone asks "Could we switch to gdbm or vim/elvis/whatever?" Step 6: Editor religious wars begin. [Everyone: shock, horror, dismay, flaming.] I think that FreeBSD should leave DB 1.85 in the C library, and when (if?) nvi finally upgrades to DB 3, simply load nvi & DB 3 as a single executable and ship it that way. Problem solved. :-) I'm copying arch, but I doubt I'll be able to post -- feel free to forward. --keith =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Keith Bostic Sleepycat Software Inc. bostic@sleepycat.com 118 Tower Rd. +1-781-259-3139 Lincoln, MA 01773 http://www.sleepycat.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 10 18:19:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 5B3D037B405 for ; Tue, 10 Jul 2001 18:19:18 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.11.3/8.11.3) with ESMTP id f6B1JHq23414; Tue, 10 Jul 2001 21:19:17 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20010710161036.C98432@dragon.nuxi.com> References: <20010708005155.J8775@canonware.com> <20010708032002.D97456@bohr.physics.purdue.edu> <20010709150739.A23210@cicely20.cicely.de> <200107091817.LAA16879@windsor.research.att.com> <20010709164715.F85805@over-yonder.net> <20010709213007.A18204@futuresouth.com> <200107102242.f6AMgoO20085@earth.backplane.com> <20010710154825.B98432@dragon.nuxi.com> <200107102306.f6AN6e820560@earth.backplane.com> <20010710161036.C98432@dragon.nuxi.com> Date: Tue, 10 Jul 2001 21:19:15 -0400 To: arch@FreeBSD.ORG, Matt Dillon From: Garance A Drosihn Subject: Re: nvi maintainer? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 4:10 PM -0700 7/10/01, arch@FreeBSD.ORG wrote: >On Tue, Jul 10, 2001 at 04:06:40PM -0700, Matt Dillon wrote: >> I'm sorry Dave, > >"David" please. :-) > >> but it's a matter of opinion. >.. >> but that's doesn't >> mean my statement is backwards any more then yours is. > >Exactly! :-) I was hoping people would get that idea and stop arging on >the issue of split screen and undo. 40% of us feel nvi gets it wrong, >another 40% feel vim gets it wrong, and the other 20% have never used >multiple windows in any flavor of vi. The point is that someone explicitly suggested that 'vim' should replace 'nvi'. (Will Andrews did, and other messages have implied that switch). No one is suggesting 'nvi' replace 'vim'. Given those facts, Matt's post makes sense and is on topic. We were not arguing "split vs undo", we were discussing options for 'nvi'. -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 10 18:32:16 2001 Delivered-To: freebsd-arch@freebsd.org Received: from canonware.com (dsl081-058-209.dsl-isp.net [64.81.58.209]) by hub.freebsd.org (Postfix) with ESMTP id D413537B405 for ; Tue, 10 Jul 2001 18:32:14 -0700 (PDT) (envelope-from jasone@canonware.com) Received: by canonware.com (Postfix, from userid 1001) id EE34CC7; Tue, 10 Jul 2001 18:32:27 -0700 (PDT) Date: Tue, 10 Jul 2001 18:32:27 -0700 From: Jason Evans To: Keith Bostic Cc: karels@bsdi.com, arch@hub.freebsd.org Subject: Re: nvi maintainer? Message-ID: <20010710183227.D22464@canonware.com> References: <200107110118.f6B1IQE24540@abyssinian.sleepycat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200107110118.f6B1IQE24540@abyssinian.sleepycat.com>; from bostic@sleepycat.com on Tue, Jul 10, 2001 at 09:18:26PM -0400 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Jul 10, 2001 at 09:18:26PM -0400, Keith Bostic wrote: > > I think that FreeBSD should leave DB 1.85 in the C library, and > when (if?) nvi finally upgrades to DB 3, simply load nvi & DB 3 > as a single executable and ship it that way. Problem solved. :-) I think most people have dropped out of the conversation at this point, having realized that your above suggestion is a perfectly acceptable way of proceeding. Let the editor wars[*] continue. Jason [*]: Emacs does the dishes for you! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 10 20:49:15 2001 Delivered-To: freebsd-arch@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 88A5737B405 for ; Tue, 10 Jul 2001 20:49:07 -0700 (PDT) (envelope-from julian@elischer.org) Received: from elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id WAA56560; Tue, 10 Jul 2001 22:23:47 -0700 (PDT) Message-ID: <3B4BC829.C3879AF2@elischer.org> Date: Tue, 10 Jul 2001 20:29:46 -0700 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Daniel Eischen Cc: Jason Evans , arch@FreeBSD.ORG Subject: Re: help needed in threads.. (Signals) References: Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Daniel Eischen wrote: > Ok so I think I have it 'kinda' worked out in my head.. there are some loose ends however that depend on how the interrupt masks etc are handled... In KSE mode: 1/ is there still a "per process" signal mask, and set of handler addresses? Or just separate ones per thread? 2/ are there separate handlers registerable per thread? (i.e. if thread A gets a SIGHUP call hangup() but if thread B gets a SIGHUP, call reload()) 3/ Is it possible that each thread has a mask but that the handlers are shared? (by mask I mean a block mask, and an IGN mask at least.) If all threads block an interrupt, does the process then block it? (or does it still get to the UTS? Does the UTS have to block it fo the whole process explicitly if it doesn't want to see it? If a thread is designated to take an interrupt and it is blocked in the kernel, then the same rules apply as for a current process. however is the fact that a syscall is restartable, a process wide setting or a thread-specific setting? To make sense I think the flags SA_NOCLDSTOP, SA_NOCLDWAIT are definitly per process. The SA_RESTART could have arguments each way, and similarly SA_ONSTACK ans SA_NODEFER and SA_RESETHAND might also be per thread. Certainly If you are nominating a thread to take each kind of interrupt then it makes no sense to have per-thread values for these. but if the threads declare their own interest, then they could have their own masks etc. In that case it makes sense to deliver the signal to ALL threads that express an interest in a particular signal. (I could imagine for example that two threads may want to know about the SIGHUP that indicates a restart of a daemon). Similarly a SIGTSTP should be sent to all threads in the default case because you want the entire program to suspend, Similarly you want SIGCONT to continue all threads. What semantics are we looking for? Julian. -- +------------------------------------+ ______ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ julian@elischer.org +------>x USA \ a very strange | ( OZ ) \___ ___ | country ! +- X_.---._/ presently in San Francisco \_/ \\ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 10 21:24:43 2001 Delivered-To: freebsd-arch@freebsd.org Received: from canonware.com (dsl081-058-209.dsl-isp.net [64.81.58.209]) by hub.freebsd.org (Postfix) with ESMTP id A3EE837B401 for ; Tue, 10 Jul 2001 21:24:39 -0700 (PDT) (envelope-from jasone@canonware.com) Received: by canonware.com (Postfix, from userid 1001) id 242A1C9; Tue, 10 Jul 2001 21:24:54 -0700 (PDT) Date: Tue, 10 Jul 2001 21:24:53 -0700 From: Jason Evans To: Julian Elischer Cc: Daniel Eischen , arch@FreeBSD.ORG Subject: Re: help needed in threads.. (Signals) Message-ID: <20010710212453.E22464@canonware.com> References: <3B4BC829.C3879AF2@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B4BC829.C3879AF2@elischer.org>; from julian@elischer.org on Tue, Jul 10, 2001 at 08:29:46PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Jul 10, 2001 at 08:29:46PM -0700, Julian Elischer wrote: > Daniel Eischen wrote: > > > Ok so I think I have it 'kinda' worked out in my head.. > there are some loose ends however that depend on how the interrupt masks etc are > handled... > > In KSE mode: > 1/ is there still a "per process" signal mask, and set of handler > addresses? Or just separate ones per thread? There still can be (and probably should be) a per-process signal mask. IIRC, under normal circumstances, a threaded program shouldn't use it, but doing so isn't strictly forbidden. > 2/ are there separate handlers registerable per thread? (i.e. if thread A gets > a SIGHUP call hangup() but if thread B gets a SIGHUP, call reload()) Yes, there are separare handlers per thread. However, I think this is strictly a concern of the UTS, isn't it? > 3/ Is it possible that each thread has a mask but that the handlers are shared? That would be evil programming practice, but AFAIK, nothing should prevent a program from doing that. > (by mask I mean a block mask, and an IGN mask at least.) > > If all threads block an interrupt, does the process then block it? > (or does it still get to the UTS? Does the UTS have to block it fo the > whole process explicitly if it doesn't want to see it I think we could go either way on this. It may make sense for the UTS to block it for the whole process for efficiency reasons (but I can't think of an example where it would be important to do so). > If a thread is designated to take an interrupt and it is blocked in > the kernel, then the same rules apply as for a current process. > however is the fact that a syscall is restartable, a process wide > setting or a thread-specific setting? > > To make sense I think the flags SA_NOCLDSTOP, SA_NOCLDWAIT are definitly > per process. The SA_RESTART could have arguments each way, and similarly > SA_ONSTACK ans SA_NODEFER and SA_RESETHAND might also be per thread. I don't know for sure off the top of my head, but I think it is a process wide setting. > Certainly If you are nominating a thread to take each kind of interrupt > then it makes no sense to have per-thread values for these. Proper programming practice says that at most one thread should have a particular signal unmasked. Furthermore, it is generally best to use sigwait(3). > but if the threads declare their own interest, then they could > have their own masks etc. In that case it makes sense to deliver the > signal to ALL threads that express an interest in a particular signal. > > (I could imagine for example that two threads may want to know about the > SIGHUP that indicates a restart of a daemon). > Similarly a SIGTSTP should be sent to all threads in the default case > because you want the entire program to suspend, Similarly you want SIGCONT > to continue all threads. POSIX says that only one thread gets the signal. I recently went through great pain to make a threaded program work with SIGTSTP and SIGCONT, but that's the way things are supposed to work, so we need to do it that way. > What semantics are we looking for? POSIX. If you don't already have a copy of Butenhof's "Programming with POSIX Threads", get a copy; it's a wonderful book. Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 10 22: 9:15 2001 Delivered-To: freebsd-arch@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 578B237B408 for ; Tue, 10 Jul 2001 22:09:10 -0700 (PDT) (envelope-from julian@elischer.org) Received: from elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id XAA56821; Tue, 10 Jul 2001 23:47:11 -0700 (PDT) Message-ID: <3B4BDBB1.AF248E58@elischer.org> Date: Tue, 10 Jul 2001 21:53:05 -0700 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Daniel Eischen , Jason Evans , arch@FreeBSD.ORG Subject: Re: help needed in threads.. (Signals) References: <3B4BC829.C3879AF2@elischer.org> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Julian Elischer wrote: > > Daniel Eischen wrote: > > > Ok so I think I have it 'kinda' worked out in my head.. > there are some loose ends however that depend on how the interrupt masks etc are > handled... > > In KSE mode: > 1/ is there still a "per process" signal mask, and set of handler > addresses? Or just separate ones per thread? > > 2/ are there separate handlers registerable per thread? (i.e. if thread A gets > a SIGHUP call hangup() but if thread B gets a SIGHUP, call reload()) > > 3/ Is it possible that each thread has a mask but that the handlers are shared? > > (by mask I mean a block mask, and an IGN mask at least.) > > If all threads block an interrupt, does the process then block it? > (or does it still get to the UTS? Does the UTS have to block it fo the > whole process explicitly if it doesn't want to see it? > > If a thread is designated to take an interrupt and it is blocked in > the kernel, then the same rules apply as for a current process. > however is the fact that a syscall is restartable, a process wide > setting or a thread-specific setting? > > To make sense I think the flags SA_NOCLDSTOP, SA_NOCLDWAIT are definitly > per process. The SA_RESTART could have arguments each way, and similarly > SA_ONSTACK ans SA_NODEFER and SA_RESETHAND might also be per thread. > > Certainly If you are nominating a thread to take each kind of interrupt > then it makes no sense to have per-thread values for these. > > but if the threads declare their own interest, then they could > have their own masks etc. In that case it makes sense to deliver the > signal to ALL threads that express an interest in a particular signal. > > (I could imagine for example that two threads may want to know about the > SIGHUP that indicates a restart of a daemon). > Similarly a SIGTSTP should be sent to all threads in the default case > because you want the entire program to suspend, Similarly you want SIGCONT > to continue all threads. > > What semantics are we looking for? to continue my own thoughts: The reasoning for interrupting syscalls is so that a program can decide to abort or do other syscalls, because there is no sureness that the syscall doesnt hold resources. In our case if we run the signal handler in a separate kernel thread (an upcall) we really don't care what the other syscalls are doing in fact if we didcare it would be a bug. ( If it comes to the user boundary before doing the signal then it has cleaned everything up and cannot be holding resources.) The only reason that a user would want a signal sent to a particular thread in this case would be toachieve what was originally the side effect of interrupting the syscall. The handler could be run from any thread's stack as long as it could do it's work. I think therefore that one way to do what we want would be to simply do the handler directly from the upcall, and then interrupt the appropriate thread if it happens to be in the kernel. In other words we explicitly create the side-effect if asked to do so. I guess that the restartabiliy is so that arbitrary unaltered programs can be stopped with SIGSTOP and restarted with SIGCONT, without needing to handle these situations. A restartable syscall in threads is easy.... don't interrupt it in the first place!. If the thread decides to do something that causes teh program to exit, then that syscall will have to be cleaned up in exactly the same manner as all the others. (which brings up the case of what to do if one thread is in an UNINTERRUPTABLE syscall when another does an exit().) In non threaded mode, if a signal handler is invoked during a SA_RESTART able syscall, is there any way it can abort that syscall and stop it from restarting? (I gotta go read code).  > > Julian. > > -- > +------------------------------------+ ______ _ __ > | __--_|\ Julian Elischer | \ U \/ / hard at work in > | / \ julian@elischer.org +------>x USA \ a very strange > | ( OZ ) \___ ___ | country ! > +- X_.---._/ presently in San Francisco \_/ \\ > v > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message -- +------------------------------------+ ______ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ julian@elischer.org +------>x USA \ a very strange | ( OZ ) \___ ___ | country ! +- X_.---._/ presently in San Francisco \_/ \\ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 10 22:48:55 2001 Delivered-To: freebsd-arch@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id E551537B403 for ; Tue, 10 Jul 2001 22:48:53 -0700 (PDT) (envelope-from julian@elischer.org) Received: from elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id AAA56972 for ; Wed, 11 Jul 2001 00:25:00 -0700 (PDT) Message-ID: <3B4BE48C.6906C997@elischer.org> Date: Tue, 10 Jul 2001 22:30:52 -0700 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: arch@freebsd.org Subject: FSU Pthreads (POSIX Threads) Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I just came across this.. anyone examined it? Has FreeBSD support. http://www.informatik.hu-berlin.de/~mueller/pthreads/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 10 23: 9: 1 2001 Delivered-To: freebsd-arch@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 43BBD37B406 for ; Tue, 10 Jul 2001 23:08:59 -0700 (PDT) (envelope-from julian@elischer.org) Received: from elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id AAA57032; Wed, 11 Jul 2001 00:48:38 -0700 (PDT) Message-ID: <3B4BEA15.19BD060@elischer.org> Date: Tue, 10 Jul 2001 22:54:29 -0700 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Jason Evans Cc: Daniel Eischen , arch@FreeBSD.ORG Subject: Re: help needed in threads.. (Signals) References: <3B4BC829.C3879AF2@elischer.org> <20010710212453.E22464@canonware.com> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Jason Evans wrote: > > > POSIX. If you don't already have a copy of Butenhof's "Programming with > POSIX Threads", get a copy; it's a wonderful book. thanks for the reference. I've lost my copy of the posix threads docs in the move and I need to get another. does anyone have an online reference to the posix threads extension? > > Jason > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message -- +------------------------------------+ ______ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ julian@elischer.org +------>x USA \ a very strange | ( OZ ) \___ ___ | country ! +- X_.---._/ presently in San Francisco \_/ \\ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 10 23:35:59 2001 Delivered-To: freebsd-arch@freebsd.org Received: from sneakerz.org (sneakerz.org [216.33.66.254]) by hub.freebsd.org (Postfix) with ESMTP id 48E8737B401 for ; Tue, 10 Jul 2001 23:35:57 -0700 (PDT) (envelope-from bright@sneakerz.org) Received: by sneakerz.org (Postfix, from userid 1092) id C9DA65D01F; Wed, 11 Jul 2001 01:35:56 -0500 (CDT) Date: Wed, 11 Jul 2001 01:35:56 -0500 From: Alfred Perlstein To: Julian Elischer Cc: arch@freebsd.org Subject: Re: FSU Pthreads (POSIX Threads) Message-ID: <20010711013556.G1894@sneakerz.org> References: <3B4BE48C.6906C997@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <3B4BE48C.6906C997@elischer.org>; from julian@elischer.org on Tue, Jul 10, 2001 at 10:30:52PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Julian Elischer [010711 00:49] wrote: > I just came across this.. anyone examined it? Has FreeBSD support. > > http://www.informatik.hu-berlin.de/~mueller/pthreads/ It's not free software (it's LGPL'd), so it's not really an option. -- -Alfred Perlstein [alfred@freebsd.org] Ok, who wrote this damn function called '??'? And why do my programs keep crashing in it? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jul 11 5: 4:35 2001 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id B0D7A37B405 for ; Wed, 11 Jul 2001 05:04:28 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id IAA19775; Wed, 11 Jul 2001 08:03:43 -0400 (EDT) Date: Wed, 11 Jul 2001 08:03:43 -0400 (EDT) From: Daniel Eischen To: Julian Elischer Cc: Jason Evans , arch@FreeBSD.ORG Subject: Re: help needed in threads.. (Signals) In-Reply-To: <3B4BC829.C3879AF2@elischer.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 10 Jul 2001, Julian Elischer wrote: > Daniel Eischen wrote: > > > Ok so I think I have it 'kinda' worked out in my head.. > there are some loose ends however that depend on how the interrupt masks etc are > handled... > > In KSE mode: > 1/ is there still a "per process" signal mask, and set of handler > addresses? Or just separate ones per thread? There is a per process signal mask, but it isn't directly accessable by the application since sigprocmask gets and sets the _thread_ signal mask. sigprocmask() is wrapped by the UTS which will call __sys_sigprocmask if necessary. Right now (libc_r), the threads library installs a signal handler for every signal that can be handled. The threads library also keeps track of any handlers that the application installs (sigaction is also wrapped by the threads library). If the action is SIG_DFL or SIG_IGN, the threads library will pass that to the kernel. This is really the only way that a threaded application (currently) can affect the process signal mask. > 2/ are there separate handlers registerable per thread? (i.e. if thread A gets > a SIGHUP call hangup() but if thread B gets a SIGHUP, call reload()) No, there is only one set of application handlers which the UTS keeps track of. The handler (there is only 1 handler for all signals) that actually gets installed into the process is the UTS signal handler. The UTS handler does some initial setup and calls the application handler. When the application handler returns, there may be some cleanup needed. > 3/ Is it possible that each thread has a mask but that the handlers are shared? Yes, this is how libc_r currently behaves. > (by mask I mean a block mask, and an IGN mask at least.) All you need is a block mask per thread. > If all threads block an interrupt, does the process then block it? > (or does it still get to the UTS? Does the UTS have to block it fo the > whole process explicitly if it doesn't want to see it? It still gets sent to the UTS. Yes, the UTS will have to block it for the whole process explicitly if it doesn't want to see it. BTW, we also have to worry about queueing signals eventually. > If a thread is designated to take an interrupt and it is blocked in > the kernel, then the same rules apply as for a current process. > however is the fact that a syscall is restartable, a process wide > setting or a thread-specific setting? Since there is only one set of installed handlers, the sa_flags are process wide. The application can set these when it calls sigaction, and the UTS will look at these flags and apply them to the process signal handler if necessary. libc_r currently doesn't allow the application to set the sa_flags in the kernels copy of sigacts, but that is because the threads library wraps blockable system calls and checks for EINTR. > To make sense I think the flags SA_NOCLDSTOP, SA_NOCLDWAIT are definitly > per process. The SA_RESTART could have arguments each way, and similarly > SA_ONSTACK ans SA_NODEFER and SA_RESETHAND might also be per thread. > > Certainly If you are nominating a thread to take each kind of interrupt > then it makes no sense to have per-thread values for these. Right. I think we only want per-process sigacts. > but if the threads declare their own interest, then they could > have their own masks etc. In that case it makes sense to deliver the > signal to ALL threads that express an interest in a particular signal. > > (I could imagine for example that two threads may want to know about the > SIGHUP that indicates a restart of a daemon). > Similarly a SIGTSTP should be sent to all threads in the default case > because you want the entire program to suspend, Similarly you want SIGCONT > to continue all threads. > > What semantics are we looking for? Use the rules that I posted before. There can only ever be 1 thread that gets a signal. In the case of a thread waiting in sigwait(), no handler is even called. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jul 11 5:11:53 2001 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 2C73937B405 for ; Wed, 11 Jul 2001 05:11:51 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id IAA20730; Wed, 11 Jul 2001 08:11:08 -0400 (EDT) Date: Wed, 11 Jul 2001 08:11:08 -0400 (EDT) From: Daniel Eischen To: Jason Evans Cc: Julian Elischer , arch@FreeBSD.ORG Subject: Re: help needed in threads.. (Signals) In-Reply-To: <20010710212453.E22464@canonware.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 10 Jul 2001, Jason Evans wrote: > On Tue, Jul 10, 2001 at 08:29:46PM -0700, Julian Elischer wrote: > > > 2/ are there separate handlers registerable per thread? (i.e. if thread A gets > > a SIGHUP call hangup() but if thread B gets a SIGHUP, call reload()) > > Yes, there are separare handlers per thread. However, I think this is > strictly a concern of the UTS, isn't it? I don't think this is true, at least that's not the way it currently is implemented in libc_r. But even if there were to be separate handlers per thread, I agree that it can be handled by the UTS. > > 3/ Is it possible that each thread has a mask but that the handlers are > shared? > > That would be evil programming practice, but AFAIK, nothing should prevent > a program from doing that. Actually, this is the way it works now. The only evil thing is trying to get more than 1 thread to handle the same signal. > > Certainly If you are nominating a thread to take each kind of interrupt > > then it makes no sense to have per-thread values for these. > > Proper programming practice says that at most one thread should have a > particular signal unmasked. Furthermore, it is generally best to use > sigwait(3). Yes! > > What semantics are we looking for? > > POSIX. If you don't already have a copy of Butenhof's "Programming with > POSIX Threads", get a copy; it's a wonderful book. You can also get a copy of the draft Austin (new POSIX) spec by registering as a reviewer (www.opengroup.org). There are more requirements that affect threads in there :( -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jul 11 5:42:32 2001 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id B8FC237B401 for ; Wed, 11 Jul 2001 05:42:20 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id IAA24609; Wed, 11 Jul 2001 08:41:37 -0400 (EDT) Date: Wed, 11 Jul 2001 08:41:37 -0400 (EDT) From: Daniel Eischen To: Julian Elischer Cc: Jason Evans , arch@FreeBSD.ORG Subject: Re: help needed in threads.. (Signals) In-Reply-To: <3B4BDBB1.AF248E58@elischer.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 10 Jul 2001, Julian Elischer wrote: > Julian Elischer wrote: > to continue my own thoughts: > > The reasoning for interrupting syscalls is so that a program can decide to > abort or do other syscalls, because there is no sureness that the syscall > doesnt hold resources. In our case if we run the signal handler in a separate > kernel thread (an upcall) we really don't care what the other syscalls are doing > in fact if we didcare it would be a bug. > > ( If it comes to the user boundary before doing the signal then > it has cleaned everything up and cannot be holding resources.) > > The only reason that a user would want a signal sent to a particular thread > in this case would be toachieve what was originally the side effect of > interrupting > the syscall. The handler could be run from any thread's stack as long as it > could do it's work. I think therefore that one way to do what we want would be > to > simply do the handler directly from the upcall, and then interrupt > the appropriate thread if it happens to be in the kernel. In other words > we explicitly create the side-effect if asked to do so. > > I guess that the restartabiliy is so that arbitrary unaltered programs > can be stopped with SIGSTOP and restarted with SIGCONT, without > needing to handle these situations. A restartable syscall in threads is easy.... > don't interrupt it in the first place!. If the thread decides to do something > that > causes teh program to exit, then that syscall will have to be cleaned up in > exactly the same manner as all the others. > (which brings up the case of what to do if one thread is in an UNINTERRUPTABLE > syscall when another does an exit().) You can't really handle the signal in _any_ stack or thread. It really has to be handled in the one thread that should get the signal. And if that thread is blocked in the kernel, then you need to make its context current before running the handler. Please remember that the UTS does _not_ know if the thread has longjmp'd (or equivalent) out of the handler. static int some_rtn(int fd) { char buf[1024]; int ret; jmp_buf jb; if (setjmp(jb) == 0) ret = read(fd, buf, sizeof(buf)); else ret = -1; return (ret); } Now substitute a compiler generated __builtin_setjmp() instead of setjmp (in case you were to argue that the threads library could wrap setjmp/longjmp). I know that the Ada compiler (GNAT) uses this for implementing exception blocks, and I had to make libc_r work so that it did not have to know if a signal handler did an abnormal return. In the example above, read() is reading into a stack variable. You can't run the handler while the kernel is potentially corrupting the stack. The blocked thread in the kernel _must_ be suspended. And what happens if you don't make the blocked thread (context) in the kernel current before running the handler? Since the blocked thread (in the kernel) can't be resumed until the handler returns, and since the UTS may have no idea if the handler has abnormally returned via some type of longjmp, the blocked thread in the kernel can be there until the application ends. And this can happen repeatedly. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jul 11 5:43:19 2001 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 0FDCB37B405 for ; Wed, 11 Jul 2001 05:43:15 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id IAA24716; Wed, 11 Jul 2001 08:42:32 -0400 (EDT) Date: Wed, 11 Jul 2001 08:42:32 -0400 (EDT) From: Daniel Eischen To: Julian Elischer Cc: arch@FreeBSD.ORG Subject: Re: FSU Pthreads (POSIX Threads) In-Reply-To: <3B4BE48C.6906C997@elischer.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 10 Jul 2001, Julian Elischer wrote: > I just came across this.. anyone examined it? Has FreeBSD support. > > http://www.informatik.hu-berlin.de/~mueller/pthreads/ Yes, it's pretty basic. Our libc_r is more full-featured. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jul 11 10:18: 2 2001 Delivered-To: freebsd-arch@freebsd.org Received: from green.bikeshed.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id E936437B401; Wed, 11 Jul 2001 10:17:58 -0700 (PDT) (envelope-from green@green.bikeshed.org) Received: from localhost (green@localhost) by green.bikeshed.org (8.11.2/8.11.1) with ESMTP id f6BHHr445606; Wed, 11 Jul 2001 13:17:54 -0400 (EDT) (envelope-from green@green.bikeshed.org) Message-Id: <200107111717.f6BHHr445606@green.bikeshed.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Jason Evans Cc: Keith Bostic , karels@bsdi.com, arch@hub.freebsd.org Subject: Re: nvi maintainer? In-Reply-To: Message from Jason Evans of "Tue, 10 Jul 2001 18:32:27 PDT." <20010710183227.D22464@canonware.com> From: "Brian F. Feldman" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 11 Jul 2001 13:17:52 -0400 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Jason Evans wrote: > On Tue, Jul 10, 2001 at 09:18:26PM -0400, Keith Bostic wrote: > > > > I think that FreeBSD should leave DB 1.85 in the C library, and > > when (if?) nvi finally upgrades to DB 3, simply load nvi & DB 3 > > as a single executable and ship it that way. Problem solved. :-) > > I think most people have dropped out of the conversation at this point, > having realized that your above suggestion is a perfectly acceptable way of > proceeding. > > Let the editor wars[*] continue. > > Jason > > [*]: Emacs does the dishes for you! Let's just plan on doing that, then. It wasn't said that libc HAD to contain a new version of DB, since nvi will, when it depends on DB3, be using the new interface anyway. So that leaves us with the situation that we have the same old DB in libc, plus all the bugfixes for it we accumulate (because it's certainly true that we are continuing to maintain it to this day), so noone is surprised there, and adding DB3 to our libraries, separately. The sheer number of people that would hate any switch in the base system's vi to another that didn't work in exactly the same way is much larger than anyone likely can estimate. -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jul 11 19:34:35 2001 Delivered-To: freebsd-arch@freebsd.org Received: from redrock.eng.bsdi.com (redrock.eng.bsdi.com [206.196.45.2]) by hub.freebsd.org (Postfix) with ESMTP id AE70237B401 for ; Wed, 11 Jul 2001 19:34:32 -0700 (PDT) (envelope-from karels@redrock.eng.bsdi.com) Received: from redrock.eng.bsdi.com (karels@localhost.BSDI.COM [127.0.0.1]) by redrock.eng.bsdi.com (8.10.1/8.10.1) with ESMTP id f6C2YLC14835 for ; Wed, 11 Jul 2001 21:34:21 -0500 (CDT) Message-Id: <200107120234.f6C2YLC14835@redrock.eng.bsdi.com> To: arch@freebsd.org From: Mike Karels Reply-To: karels@bsdi.com Subject: syscall numbering Date: Wed, 11 Jul 2001 21:34:17 -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I am sending this message at Jordan's suggestion after corresponding with him. The subject is coordination of system call numbers. As some of you probably know, the syscall.master file in Berkeley BSD releases had some ranges reserved for "vendors". Unfortunately, both BSDI (now Wind River) and their customers were "vendors", and there have been some collisions. I would now like to reserve another range of system calls for those customers. This would not be of interest to FreeBSD, except that BSD/OS also picks up system calls from FreeBSD, and FreeBSD has a number of BSD/OS-compatible calls as well as other entries for compatibility with NetBSD and/or OpenBSD. In theory, it would be nice to coordinate all of this globally, but I understand that NetBSD doesn't even have consistent numbering across all of their platforms. I'm sure we won't be able to prevent conflicts completely, but it is convenient that we can mostly use a single system call table. For now, I'm tempted to reserve 400-449 for BSD/OS customers. FreeBSD seems to be using 300 up, to 374 currently, and BSD/OS calls are all below that. Does this sound plausible? Does that leave enough for FreeBSD expansion? I'm happy to consider other suggestions, including some larger level of coordination. Feel free to contact me directly, off the list. Mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jul 12 3: 9: 7 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.13]) by hub.freebsd.org (Postfix) with SMTP id EBA5337B408 for ; Thu, 12 Jul 2001 03:08:52 -0700 (PDT) (envelope-from roam@orbitel.bg) Received: (qmail 584 invoked by uid 1000); 12 Jul 2001 10:13:06 -0000 Date: Thu, 12 Jul 2001 13:13:06 +0300 From: Peter Pentchev To: arch@FreeBSD.org Cc: audit@FreeBSD.org Subject: Re: A slight improvement of the rc system Message-ID: <20010712131306.A554@ringworld.oblivion.bg> Mail-Followup-To: arch@FreeBSD.org, audit@FreeBSD.org References: <20010704124334.F653@ringworld.oblivion.bg> <20010705174409.A15136@dragon.nuxi.com> <20010706092624.A3782@ringworld.oblivion.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010706092624.A3782@ringworld.oblivion.bg>; from roam@orbitel.bg on Fri, Jul 06, 2001 at 09:26:24AM +0300 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, Jul 06, 2001 at 09:26:24AM +0300, Peter Pentchev wrote: > On Thu, Jul 05, 2001 at 05:44:10PM -0700, David O'Brien wrote: > > On Wed, Jul 04, 2001 at 12:43:34PM +0300, Peter Pentchev wrote: > > > +script_name_sep=" " # Change if your startup scripts' names contain spaces > > > > Uh... ever heard of "over engineering"? I think we can assume scripts > > don't have spaces in their names. Anyone trying and has the ability to > > change this knob knows enought to just not use spaces in a script's name. > > This is UNIX. > > Yep, this is Unix, and Unix has no arbitrary restrictions on filenames. > It does not have a 8.3 restriction, or a caps-only restriction; so why > should a *part* of the system place a no-spaces restriction on filenames? > Just about all the filesystems supported by FreeBSD allow filenames to > contain spaces; it's only logical to give the user the ability to use > them, if she so desires. > > It's not overcomplicating the code, either - the IFS shell variable > is standardized and used, which means that the shell was written with > this in mind; not allowing it is just that - not using the shell's > capabilities the way they were meant to be used. OK, so - does anyone have any other comments on the patch that a) allows specifying a script name separator != ' ', and b) runs the shutdown scripts in reverse order, so dependent services are shut down before the services they depend on? G'luck, Peter -- "yields falsehood, when appended to its quotation." yields falsehood, when appended to its quotation. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jul 12 13: 4:14 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-73.dsl.lsan03.pacbell.net [63.207.60.73]) by hub.freebsd.org (Postfix) with ESMTP id B1BC237B403 for ; Thu, 12 Jul 2001 13:04:11 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 52F4C66BA6; Thu, 12 Jul 2001 13:04:10 -0700 (PDT) Date: Thu, 12 Jul 2001 13:04:09 -0700 From: Kris Kennaway To: Mike Karels Cc: arch@FreeBSD.ORG Subject: Re: syscall numbering Message-ID: <20010712130408.A6850@xor.obsecurity.org> References: <200107120234.f6C2YLC14835@redrock.eng.bsdi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="h31gzZEtNLTqOjlF" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200107120234.f6C2YLC14835@redrock.eng.bsdi.com>; from karels@bsdi.com on Wed, Jul 11, 2001 at 09:34:17PM -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --h31gzZEtNLTqOjlF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Jul 11, 2001 at 09:34:17PM -0500, Mike Karels wrote: > For now, I'm tempted to reserve 400-449 for BSD/OS customers. FreeBSD > seems to be using 300 up, to 374 currently, and BSD/OS calls are all > below that. Does this sound plausible? Does that leave enough for > FreeBSD expansion? Hmm, with only 25 unallocated in that window (300-399) it seems like it may not be enough to account for future kernel interface bloat over the lifetime of FreeBSD. e.g. suppose someone implements a new set of syscalls providing a new class of kernel interface -- something like AIO in existing FreeBSD which requires a number of syscalls, or the future kernel threads implementation, or expanded TrustedBSD support - there's only room in that window for another 2-3 or so sets and we'd have to expand downwards or something. Kris --h31gzZEtNLTqOjlF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE7TgK3Wry0BWjoQKURAtq/AJ9YiI7RssmoRVDmvmHwFJwGggl1egCdHAkC aRiBIPGfSuU6NmoirbpCZPQ= =bcMG -----END PGP SIGNATURE----- --h31gzZEtNLTqOjlF-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jul 12 13:14:35 2001 Delivered-To: freebsd-arch@freebsd.org Received: from sneakerz.org (sneakerz.org [216.33.66.254]) by hub.freebsd.org (Postfix) with ESMTP id 181C137B407 for ; Thu, 12 Jul 2001 13:14:33 -0700 (PDT) (envelope-from bright@sneakerz.org) Received: by sneakerz.org (Postfix, from userid 1092) id B40E95D01F; Thu, 12 Jul 2001 15:14:32 -0500 (CDT) Date: Thu, 12 Jul 2001 15:14:32 -0500 From: Alfred Perlstein To: Kris Kennaway Cc: Mike Karels , arch@FreeBSD.ORG Subject: Re: syscall numbering Message-ID: <20010712151432.F4589@sneakerz.org> References: <200107120234.f6C2YLC14835@redrock.eng.bsdi.com> <20010712130408.A6850@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20010712130408.A6850@xor.obsecurity.org>; from kris@obsecurity.org on Thu, Jul 12, 2001 at 01:04:09PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Kris Kennaway [010712 15:04] wrote: > On Wed, Jul 11, 2001 at 09:34:17PM -0500, Mike Karels wrote: > > > For now, I'm tempted to reserve 400-449 for BSD/OS customers. FreeBSD > > seems to be using 300 up, to 374 currently, and BSD/OS calls are all > > below that. Does this sound plausible? Does that leave enough for > > FreeBSD expansion? > > Hmm, with only 25 unallocated in that window (300-399) it seems like > it may not be enough to account for future kernel interface bloat over > the lifetime of FreeBSD. e.g. suppose someone implements a new set of > syscalls providing a new class of kernel interface -- something like > AIO in existing FreeBSD which requires a number of syscalls, or the > future kernel threads implementation, or expanded TrustedBSD support - > there's only room in that window for another 2-3 or so sets and we'd > have to expand downwards or something. I really don't see a problem if we make sure that at a later date we revisit the issue and ask for another window to be reserved for our usage. Let's accept this for the time being and update our syscalls.master to remind people not to infringe upon the BSD/os reserved syscall space. -- -Alfred Perlstein [alfred@freebsd.org] Ok, who wrote this damn function called '??'? And why do my programs keep crashing in it? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jul 13 6:55:48 2001 Delivered-To: freebsd-arch@freebsd.org Received: from bazooka.unixfreak.org (bazooka.unixfreak.org [63.198.170.138]) by hub.freebsd.org (Postfix) with ESMTP id C5C2C37B405 for ; Fri, 13 Jul 2001 06:55:25 -0700 (PDT) (envelope-from dima@unixfreak.org) Received: from hornet.unixfreak.org (hornet [63.198.170.140]) by bazooka.unixfreak.org (Postfix) with ESMTP id 37C293E2F for ; Fri, 13 Jul 2001 06:55:25 -0700 (PDT) To: arch@freebsd.org Subject: Getting rid of libgmp Date: Fri, 13 Jul 2001 06:55:25 -0700 From: Dima Dorfman Message-Id: <20010713135525.37C293E2F@bazooka.unixfreak.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi folks, A week or so ago there was a thread on -current about removing libgmp. It was generally agreed that this was a good idea, but (as usual) somebody has to do the work, and some people wanted FreeBSD to continue to supply a libmp-compatible interface. To satisfy both groups, I propose that we import a libmp that is implemented in terms of the OpenSSL BIGNUM library. Attached below is a sharball of such an implementation. I couldn't find very good documentation on the libmp interface, but I've tested this with most[1] of the software in FreeBSD that uses libmp, and all programs work as well as they did before. The library is quite small; all functions except msqrt() have a BIGNUM equivilent. It requires that the program using it be linked with -lcrypto[2]. Comments? Suggestions? Thanks, Dima Dorfman dima@unixfreak.org [1] I wasn't able to test Kerberized telnet, but it looks like it uses the same code as the non-Kerberized one, so I don't think there will be a problem. [2] Someone said it was possible to factor out the BIGNUM bits out of libcrypto; this is obviously possible, but they depend on so many other parts of the OpenSSL library (e.g., its elaborate error mechanism, BIO, etc.) that I think it isn't worth it. That said, it's something somebody might want to look into later. # This is a shell archive. Save it in a file, remove anything before # this line, and then unpack it by entering "sh file". Note, it may # create directories; files and directories will be owned by you and # have default permissions. # # This archive contains: # # libmp # libmp/Makefile # libmp/mp.h # libmp/mpasbn.c # echo c - libmp mkdir -p libmp > /dev/null 2>&1 echo x - libmp/Makefile sed 's/^X//' >libmp/Makefile << 'END-of-libmp/Makefile' X# $FreeBSD$ X XLIB= mp XCFLAGS+= -ansi -pedantic XWARNS?= 2 XNO_WERROR= yes XSHLIB_MAJOR= 4 XSRCS= mpasbn.c X Xbeforeinstall: X ${INSTALL} -C -o ${BINOWN} -g ${BINGRP} -m 444 \ X ${.CURDIR}/mp.h ${DESTDIR}/usr/include X X.include END-of-libmp/Makefile echo x - libmp/mp.h sed 's/^X//' >libmp/mp.h << 'END-of-libmp/mp.h' X#ifndef _MP_H_ X#define _MP_H_ X X#include X Xtypedef struct _mint { X BIGNUM *bn; X} MINT; X X Xvoid gcd(const MINT *, const MINT *, MINT *); XMINT *itom(short); Xvoid madd(const MINT *, const MINT *, MINT *); Xint mcmp(const MINT *, const MINT *); Xvoid mdiv(const MINT *, const MINT *, MINT *, MINT *); Xvoid mfree(MINT *); Xvoid min(MINT *); Xvoid mout(const MINT *); Xvoid move(const MINT *, MINT *); Xvoid msqrt(const MINT *, MINT *, MINT *); Xvoid msub(const MINT *, const MINT *, MINT *); Xchar *mtox(const MINT *); Xvoid mult(const MINT *, const MINT *, MINT *); Xvoid pow(const MINT *, const MINT *, const MINT *, MINT *); Xvoid rpow(const MINT *, short, MINT *); Xvoid sdiv(const MINT *, short, MINT *, short *); XMINT *xtom(const char *); X X#endif /* !_MP_H_ */ END-of-libmp/mp.h echo x - libmp/mpasbn.c sed 's/^X//' >libmp/mpasbn.c << 'END-of-libmp/mpasbn.c' X/* X * Copyright (c) 2001, Dima Dorfman. X * All rights reserved. X * X * Redistribution and use in source and binary forms, with or without X * modification, are permitted provided that the following conditions X * are met: X * 1. Redistributions of source code must retain the above copyright X * notice, this list of conditions and the following disclaimer. X * 2. Redistributions in binary form must reproduce the above copyright X * notice, this list of conditions and the following disclaimer in the X * documentation and/or other materials provided with the distribution. X * X * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND X * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE X * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE X * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE X * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL X * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS X * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) X * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT X * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY X * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF X * SUCH DAMAGE. X */ X X/* X * This is the traditional Berkeley MP library implemented in terms of X * the OpenSSL BIGNUM library. It was written to replace libgmp, and X * is meant to be as compatible with the latter as feasible. X * X * There seems to be a lack of documentation for the Berkeley MP X * interface. All I could find was libgmp documentation (which didn't X * talk about the semantics of the functions) and an old SunOS 4.1 X * manual page from 1989. The latter wasn't very detailed, either, X * but at least described what the function's arguments were. In X * general the interface seems to be archaic, somewhat poorly X * designed, and poorly, if at all, documented. It is considered X * harmful. X * X * Miscellaneous notes on this implementation: X * X * - The SunOS manual page mentioned above indicates that if an error X * occurs, the library should "produce messages and core images." X * Given that most of the functions don't have return values (and X * thus no sane way of alerting the caller to an error), this seems X * reasonable. The MPERR and MPERRX macros call warn and warnx, X * respectively, then abort(). X * X * - All the functions which take an argument to be "filled in" X * assume that the argument has been initialized by one of the *tom() X * routines before being passed to it. I never saw this documented X * anywhere, but this seems to be consistent with the way this X * library is used. X * X * - msqrt() is the only routine which had to be implemented which X * doesn't have a close counterpart in the OpenSSL BIGNUM library. X * It was implemented by hand using Newton's recursive formula. X * Doing it this way, although more error-prone, has the positive X * sideaffect of testing a lot of other functions; if msqrt() X * produces the correct results, most of the other routines will as X * well. X * X * - Internal-use-only routines (i.e., those defined here statically X * and not in mp.h) have an underscore prepended to their name (this X * is more for aesthetical reasons than technical). All such X * routines take an extra argument, 'msg', that denotes what they X * should call themselves in an error message. This is so a user X * doesn't get an error message from a function they didn't call. X */ X X#ifndef lint Xstatic const char rcsid[] = X "$FreeBSD$"; X#endif /* not lint */ X X#include X#include X#include X#include X#include X#include X X#include X#include X#include X X#include "mp.h" X X#define MPERR(s) do { warn s; abort(); } while (0) X#define MPERRX(s) do { warnx s; abort(); } while (0) X#define BN_ERRCHECK(msg, expr) do { \ X if (!(expr)) _bnerr(msg); \ X} while (0) X Xstatic void _bnerr(const char *); Xstatic MINT *_dtom(const char *, const char *); Xstatic MINT *_itom(const char *, short); Xstatic void _madd(const char *, const MINT *, const MINT *, MINT *); Xstatic int _mcmpa(const char *, const MINT *, const MINT *); Xstatic void _mdiv(const char *, const MINT *, const MINT *, MINT *, MINT *); Xstatic void _mfree(const char *, MINT *); Xstatic void _moveb(const char *, const BIGNUM *, MINT *); Xstatic void _movem(const char *, const MINT *, MINT *); Xstatic void _msub(const char *, const MINT *, const MINT *, MINT *); Xstatic char *_mtod(const char *, const MINT *); Xstatic char *_mtox(const char *, const MINT *); Xstatic void _mult(const char *, const MINT *, const MINT *, MINT *); Xstatic void _sdiv(const char *, const MINT *, short, MINT *, short *); Xstatic MINT *_xtom(const char *, const char *); X X/* X * Report an error from one of the BN_* functions using MPERRX. X */ Xstatic void X_bnerr(const char *msg) X{ X X ERR_load_crypto_strings(); X MPERRX(("%s: %s", msg, ERR_reason_error_string(ERR_get_error()))); X} X X/* X * Convert a decimal string to an MINT. X */ Xstatic MINT * X_dtom(const char *msg, const char *s) X{ X MINT *mp; X X mp = malloc(sizeof(*mp)); X if (mp == NULL) X MPERR(("%s", msg)); X mp->bn = BN_new(); X if (mp->bn == NULL) X _bnerr(msg); X BN_ERRCHECK(msg, BN_dec2bn(&mp->bn, s)); X return (mp); X} X X/* X * Compute the greatest common divisor of mp1 and mp2; result goes in rmp. X */ Xvoid Xgcd(const MINT *mp1, const MINT *mp2, MINT *rmp) X{ X BIGNUM b; X BN_CTX c; X X BN_CTX_init(&c); X BN_init(&b); X BN_ERRCHECK("gcd", BN_gcd(&b, mp1->bn, mp2->bn, &c)); X _moveb("gcd", &b, rmp); X BN_free(&b); X BN_CTX_free(&c); X} X X/* X * Make an MINT out of a short integer. Return value must be mfree()'d. X */ Xstatic MINT * X_itom(const char *msg, short n) X{ X MINT *mp; X char *s; X X asprintf(&s, "%x", n); X if (s == NULL) X MPERR(("%s", msg)); X mp = _xtom(msg, s); X free(s); X return (mp); X} X XMINT * Xitom(short n) X{ X X return (_itom("itom", n)); X} X X/* X * Compute rmp=mp1+mp2. X */ Xstatic void X_madd(const char *msg, const MINT *mp1, const MINT *mp2, MINT *rmp) X{ X BIGNUM b; X X BN_init(&b); X BN_ERRCHECK(msg, BN_add(&b, mp1->bn, mp2->bn)); X _moveb(msg, &b, rmp); X BN_free(&b); X} X Xvoid Xmadd(const MINT *mp1, const MINT *mp2, MINT *rmp) X{ X X _madd("madd", mp1, mp2, rmp); X} X X/* X * Return -1, 0, or 1 if mp1mp2, respectivley. X */ Xint Xmcmp(const MINT *mp1, const MINT *mp2) X{ X X return (BN_cmp(mp1->bn, mp2->bn)); X} X X/* X * Same as mcmp but compares absolute values. X */ Xstatic int X_mcmpa(const char *msg __unused, const MINT *mp1, const MINT *mp2) X{ X X return (BN_ucmp(mp1->bn, mp2->bn)); X} X X/* X * Compute qmp=nmp/dmp and rmp=nmp%dmp. X */ Xstatic void X_mdiv(const char *msg, const MINT *nmp, const MINT *dmp, MINT *qmp, MINT *rmp) X{ X BIGNUM q, r; X BN_CTX c; X X BN_CTX_init(&c); X BN_init(&r); X BN_init(&q); X BN_ERRCHECK(msg, BN_div(&q, &r, nmp->bn, dmp->bn, &c)); X _moveb(msg, &q, qmp); X _moveb(msg, &r, rmp); X BN_free(&q); X BN_free(&r); X BN_CTX_free(&c); X} X Xvoid Xmdiv(const MINT *nmp, const MINT *dmp, MINT *qmp, MINT *rmp) X{ X X _mdiv("mdiv", nmp, dmp, qmp, rmp); X} X X/* X * Free memory associated with an MINT. X */ Xstatic void X_mfree(const char *msg __unused, MINT *mp) X{ X X BN_clear(mp->bn); X BN_free(mp->bn); X free(mp); X} X Xvoid Xmfree(MINT *mp) X{ X X _mfree("mfree", mp); X} X X/* X * Read an integer from standard input and stick the result in mp. X * The input is treated to be in base 10. This must be the silliest X * API in existence; why can't the program read in a string and call X * xtom()? (Or if base 10 is desires, perhaps dtom() could be X * exported.) X */ Xvoid Xmin(MINT *mp) X{ X MINT *rmp; X char *line, *nline; X size_t linelen; X X line = fgetln(stdin, &linelen); X if (line == NULL) X MPERR(("min")); X nline = malloc(linelen); X if (nline == NULL) X MPERR(("min")); X strncpy(nline, line, linelen); X nline[linelen] = '\0'; X rmp = _dtom("min", nline); X _movem("min", rmp, mp); X _mfree("min", rmp); X free(nline); X} X X/* X * Print the value of mp to standard output in base 10. See blurb X * above min() for why this is so useless. X */ Xvoid Xmout(const MINT *mp) X{ X char *s; X X s = _mtod("mout", mp); X printf("%s", s); X free(s); X} X X/* X * Set the value of tmp to the value of smp (i.e., tmp=smp). X */ Xvoid Xmove(const MINT *smp, MINT *tmp) X{ X X _movem("move", smp, tmp); X} X X X/* X * Internal routine to set the value of tmp to that of sbp. X */ Xstatic void X_moveb(const char *msg, const BIGNUM *sbp, MINT *tmp) X{ X X BN_ERRCHECK(msg, BN_copy(tmp->bn, sbp)); X} X X/* X * Internal routine to set the value of tmp to that of smp. X */ Xstatic void X_movem(const char *msg, const MINT *smp, MINT *tmp) X{ X X BN_ERRCHECK(msg, BN_copy(tmp->bn, smp->bn)); X} X X/* X * Compute the square root of nmp and put the result in xmp. The X * remainder goes in rmp. Should satisfy: rmp=nmp-(xmp*xmp). X * X * Note that the OpenSSL BIGNUM library does not have a square root X * function, so this had to be implemented by hand using Newton's X * recursive formula: X * X * x = (x + (n / x)) / 2 X * X * where x is the square root of the positive number n. In the X * beginning, x should be a reasonable guess, but the value 1, X * although suboptimal, works, too; this is that is used below. X */ Xvoid Xmsqrt(const MINT *nmp, MINT *xmp, MINT *rmp) X{ X MINT *tolerance; X MINT *ox, *x; X MINT *z1, *z2, *z3; X short i; X X tolerance = _itom("msqrt", 1); X x = _itom("msqrt", 1); X ox = _itom("msqrt", 0); X z1 = _itom("msqrt", 0); X z2 = _itom("msqrt", 0); X z3 = _itom("msqrt", 0); X do { X _movem("msqrt", x, ox); X _mdiv("msqrt", nmp, x, z1, z2); X _madd("msqrt", x, z1, z2); X _sdiv("msqrt", z2, 2, x, &i); X _msub("msqrt", ox, x, z3); X } while (_mcmpa("msqrt", z3, tolerance) == 1); X _movem("msqrt", x, xmp); X _mult("msqrt", x, x, z1); X _msub("msqrt", nmp, z1, z2); X _movem("msqrt", z2, rmp); X _mfree("msqrt", tolerance); X _mfree("msqrt", ox); X _mfree("msqrt", x); X _mfree("msqrt", z1); X _mfree("msqrt", z2); X _mfree("msqrt", z3); X} X X/* X * Compute rmp=mp1-mp2. X */ Xstatic void X_msub(const char *msg, const MINT *mp1, const MINT *mp2, MINT *rmp) X{ X BIGNUM b; X X BN_init(&b); X BN_ERRCHECK(msg, BN_sub(&b, mp1->bn, mp2->bn)); X _moveb(msg, &b, rmp); X BN_free(&b); X} X Xvoid Xmsub(const MINT *mp1, const MINT *mp2, MINT *rmp) X{ X X _msub("msub", mp1, mp2, rmp); X} X X/* X * Return a decimal representation of mp. Return value must be X * free()'d. X */ Xstatic char * X_mtod(const char *msg, const MINT *mp) X{ X char *s, *s2; X X s = BN_bn2dec(mp->bn); X if (s == NULL) X _bnerr(msg); X asprintf(&s2, "%s", s); X if (s2 == NULL) X MPERR(("%s", msg)); X OPENSSL_free(s); X return (s2); X} X X/* X * Return a hexadecimal representation of mp. Return value must be X * free()'d. X */ Xstatic char * X_mtox(const char *msg, const MINT *mp) X{ X char *p, *s, *s2; X int len; X X s = BN_bn2hex(mp->bn); X if (s == NULL) X _bnerr(msg); X asprintf(&s2, "%s", s); X if (s2 == NULL) X MPERR(("%s", msg)); X OPENSSL_free(s); X X /* X * This is a kludge for libgmp compatibility. The latter's X * implementation of this function returns lower-case letters, X * but BN_bn2hex returns upper-case. Some programs (e.g., X * newkey(1)) are sensitive to this. Although it's probably X * their fault, it's nice to be compatible. X */ X len = strlen(s2); X for (p = s2; p < s2 + len; p++) X *p = tolower(*p); X X return (s2); X} X Xchar * Xmtox(const MINT *mp) X{ X X return (_mtox("mtox", mp)); X} X X/* X * Compute rmp=mp1*mp2. X */ Xstatic void X_mult(const char *msg, const MINT *mp1, const MINT *mp2, MINT *rmp) X{ X BIGNUM b; X BN_CTX c; X X BN_CTX_init(&c); X BN_init(&b); X BN_ERRCHECK(msg, BN_mul(&b, mp1->bn, mp2->bn, &c)); X _moveb(msg, &b, rmp); X BN_free(&b); X BN_CTX_free(&c); X} X Xvoid Xmult(const MINT *mp1, const MINT *mp2, MINT *rmp) X{ X X _mult("mult", mp1, mp2, rmp); X} X X/* X * Compute rmp=(bmp^emp)mod mmp. (Note that here and above rpow() '^' X * means 'raise to power', not 'bitwise XOR'.) X */ Xvoid Xpow(const MINT *bmp, const MINT *emp, const MINT *mmp, MINT *rmp) X{ X BIGNUM b; X BN_CTX c; X X BN_CTX_init(&c); X BN_init(&b); X BN_ERRCHECK("pow", BN_mod_exp(&b, bmp->bn, emp->bn, mmp->bn, &c)); X _moveb("pow", &b, rmp); X BN_free(&b); X BN_CTX_free(&c); X} X X/* X * Compute rmp=bmp^e. (See note above pow().) X */ Xvoid Xrpow(const MINT *bmp, short e, MINT *rmp) X{ X MINT *emp; X BIGNUM b; X BN_CTX c; X X BN_CTX_init(&c); X BN_init(&b); X emp = _itom("rpow", e); X BN_ERRCHECK("rpow", BN_exp(&b, bmp->bn, emp->bn, &c)); X _moveb("rpow", &b, rmp); X _mfree("rpow", emp); X BN_free(&b); X BN_CTX_free(&c); X} X X/* X * Compute qmp=nmp/d and ro=nmp%d. X */ Xstatic void X_sdiv(const char *msg, const MINT *nmp, short d, MINT *qmp, short *ro) X{ X MINT *dmp, *rmp; X BIGNUM q, r; X BN_CTX c; X char *s; X X BN_CTX_init(&c); X BN_init(&q); X BN_init(&r); X dmp = _itom(msg, d); X rmp = _itom(msg, 0); X BN_ERRCHECK(msg, BN_div(&q, &r, nmp->bn, dmp->bn, &c)); X _moveb(msg, &q, qmp); X _moveb(msg, &r, rmp); X s = _mtox(msg, rmp); X errno = 0; X *ro = strtol(s, NULL, 16); X if (errno != 0) X MPERR(("%s underflow or overflow", msg)); X free(s); X _mfree(msg, dmp); X _mfree(msg, rmp); X BN_free(&r); X BN_free(&q); X BN_CTX_free(&c); X} X Xvoid Xsdiv(const MINT *nmp, short d, MINT *qmp, short *ro) X{ X X _sdiv("sdiv", nmp, d, qmp, ro); X} X X/* X * Convert a hexadecimal string to an MINT. X */ Xstatic MINT * X_xtom(const char *msg, const char *s) X{ X MINT *mp; X X mp = malloc(sizeof(*mp)); X if (mp == NULL) X MPERR(("%s", msg)); X mp->bn = BN_new(); X if (mp->bn == NULL) X _bnerr(msg); X BN_ERRCHECK(msg, BN_hex2bn(&mp->bn, s)); X return (mp); X} X XMINT * Xxtom(const char *s) X{ X X return (_xtom("xtom", s)); X} END-of-libmp/mpasbn.c exit To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jul 13 11:39:15 2001 Delivered-To: freebsd-arch@freebsd.org Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.121.50]) by hub.freebsd.org (Postfix) with ESMTP id 2017337B403 for ; Fri, 13 Jul 2001 11:39:13 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.130.157.Dial1.SanJose1.Level3.net [209.245.130.157]) by avocet.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id LAA14315; Fri, 13 Jul 2001 11:38:53 -0700 (PDT) Message-ID: <3B4F4062.1B661B6D@mindspring.com> Date: Fri, 13 Jul 2001 11:39:30 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Dima Dorfman Cc: arch@FreeBSD.ORG Subject: Re: Getting rid of libgmp References: <20010713135525.37C293E2F@bazooka.unixfreak.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Dima Dorfman wrote: > > Hi folks, > > A week or so ago there was a thread on -current about removing libgmp. > It was generally agreed that this was a good idea, but (as usual) > somebody has to do the work, and some people wanted FreeBSD to > continue to supply a libmp-compatible interface. > > To satisfy both groups, I propose that we import a libmp that is > implemented in terms of the OpenSSL BIGNUM library. Attached below is > a sharball of such an implementation. I couldn't find very good > documentation on the libmp interface, but I've tested this with > most[1] of the software in FreeBSD that uses libmp, and all programs > work as well as they did before. > > The library is quite small; all functions except msqrt() have a BIGNUM > equivilent. It requires that the program using it be linked with > -lcrypto[2]. > > Comments? Suggestions? Benchmarks, proving that you increased, or at least did not injure performance with this change? -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jul 14 1:53:20 2001 Delivered-To: freebsd-arch@freebsd.org Received: from bazooka.unixfreak.org (bazooka.unixfreak.org [63.198.170.138]) by hub.freebsd.org (Postfix) with ESMTP id 8C8FB37B401 for ; Sat, 14 Jul 2001 01:53:17 -0700 (PDT) (envelope-from dima@unixfreak.org) Received: from hornet.unixfreak.org (hornet [63.198.170.140]) by bazooka.unixfreak.org (Postfix) with ESMTP id 13FCB3E2F; Sat, 14 Jul 2001 01:53:17 -0700 (PDT) To: tlambert2@mindspring.com Cc: arch@FreeBSD.ORG Subject: Re: Getting rid of libgmp In-Reply-To: <3B4F4062.1B661B6D@mindspring.com>; from tlambert2@mindspring.com on "Fri, 13 Jul 2001 11:39:30 -0700" Date: Sat, 14 Jul 2001 01:53:16 -0700 From: Dima Dorfman Message-Id: <20010714085317.13FCB3E2F@bazooka.unixfreak.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Terry Lambert writes: > Dima Dorfman wrote: > > > > Hi folks, > > > > A week or so ago there was a thread on -current about removing libgmp. > > It was generally agreed that this was a good idea, but (as usual) > > somebody has to do the work, and some people wanted FreeBSD to > > continue to supply a libmp-compatible interface. > > > > To satisfy both groups, I propose that we import a libmp that is > > implemented in terms of the OpenSSL BIGNUM library. Attached below is > > a sharball of such an implementation. I couldn't find very good > > documentation on the libmp interface, but I've tested this with > > most[1] of the software in FreeBSD that uses libmp, and all programs > > work as well as they did before. > > > > The library is quite small; all functions except msqrt() have a BIGNUM > > equivilent. It requires that the program using it be linked with > > -lcrypto[2]. > > > > Comments? Suggestions? > > Benchmarks, proving that you increased, or at least did not > injure performance with this change? My wrapper around OpenSSL's BIGNUM library doesn't introduce any performance penalties beyond one or two more 'call' instructions. If OpenSSL's BIGNUM library is slower than libgmp (and it probably is), then someone just needs to fix that. The fact that I decided to write a wrapper around BIGNUM instead of converting all the programs which use libmp to use BIGNUM is better from a performance point of view; at least this way it's easier to change to another BIGNUM implementation (you'd only have to change this library instead of all those programs). Besides, as has been discussed before, all the applications this is used for in FreeBSD are not performance-critical. Dima Dorfman dima@unixfreak.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jul 14 6: 7:21 2001 Delivered-To: freebsd-arch@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [24.14.150.180]) by hub.freebsd.org (Postfix) with ESMTP id 9FE0937B406 for ; Sat, 14 Jul 2001 06:07:15 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f6ED7FM05259 for ; Sat, 14 Jul 2001 06:07:15 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 6A27738FD; Sat, 14 Jul 2001 06:07:15 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: tlambert2@mindspring.com Cc: Dima Dorfman , arch@FreeBSD.ORG Subject: Re: Getting rid of libgmp In-Reply-To: <3B4F4062.1B661B6D@mindspring.com> Date: Sat, 14 Jul 2001 06:07:15 -0700 From: Peter Wemm Message-Id: <20010714130715.6A27738FD@overcee.netplex.com.au> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Terry Lambert wrote: > Dima Dorfman wrote: > > > > Hi folks, > > > > A week or so ago there was a thread on -current about removing libgmp. > > It was generally agreed that this was a good idea, but (as usual) > > somebody has to do the work, and some people wanted FreeBSD to > > continue to supply a libmp-compatible interface. > > > > To satisfy both groups, I propose that we import a libmp that is > > implemented in terms of the OpenSSL BIGNUM library. Attached below is > > a sharball of such an implementation. I couldn't find very good > > documentation on the libmp interface, but I've tested this with > > most[1] of the software in FreeBSD that uses libmp, and all programs > > work as well as they did before. > > > > The library is quite small; all functions except msqrt() have a BIGNUM > > equivilent. It requires that the program using it be linked with > > -lcrypto[2]. > > > > Comments? Suggestions? > > Benchmarks, proving that you increased, or at least did not > injure performance with this change? This isn't really relevant. There are only a couple of things that use it. Namely the secure rpc key generators, the secure diffie hellman rpc key exchange, and telnet SRA key exchange at startup. None of these use it more than once (or once per connection). telnet is already linked against libcrypto. It should be using that for bignum support instead of libmp. libmp is dead. libcrypto is the interface of choice to use these days, or libgmp. Nothing in our tree uses libgmp. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jul 14 6:23:49 2001 Delivered-To: freebsd-arch@freebsd.org Received: from bazooka.unixfreak.org (bazooka.unixfreak.org [63.198.170.138]) by hub.freebsd.org (Postfix) with ESMTP id 0F70837B403 for ; Sat, 14 Jul 2001 06:23:47 -0700 (PDT) (envelope-from dima@unixfreak.org) Received: from hornet.unixfreak.org (hornet [63.198.170.140]) by bazooka.unixfreak.org (Postfix) with ESMTP id 704753E2F; Sat, 14 Jul 2001 06:23:43 -0700 (PDT) To: Peter Wemm Cc: arch@FreeBSD.ORG Subject: Re: Getting rid of libgmp In-Reply-To: <20010714130715.6A27738FD@overcee.netplex.com.au>; from peter@wemm.org on "Sat, 14 Jul 2001 06:07:15 -0700" Date: Sat, 14 Jul 2001 06:23:43 -0700 From: Dima Dorfman Message-Id: <20010714132343.704753E2F@bazooka.unixfreak.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Peter Wemm writes: > libmp is dead. libcrypto is the interface of choice to use these days, > or libgmp. Nothing in our tree uses libgmp. libmp certainly isn't a good interface, and nobody should be using it for new projects, but since it's so trivial to support in terms of other libraries I think we should keep it. Of course, libgmp is an infected beast, and it should die :-). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jul 14 7:48:25 2001 Delivered-To: freebsd-arch@freebsd.org Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by hub.freebsd.org (Postfix) with ESMTP id F106237B406 for ; Sat, 14 Jul 2001 07:48:22 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.11.3/8.11.3) id f6EEmG503995; Sat, 14 Jul 2001 07:48:16 -0700 (PDT) (envelope-from sgk) Date: Sat, 14 Jul 2001 07:48:16 -0700 From: Steve Kargl To: Dima Dorfman Cc: tlambert2@mindspring.com, arch@FreeBSD.ORG Subject: Re: Getting rid of libgmp Message-ID: <20010714074816.A3942@troutmask.apl.washington.edu> References: <3B4F4062.1B661B6D@mindspring.com> <20010714085317.13FCB3E2F@bazooka.unixfreak.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010714085317.13FCB3E2F@bazooka.unixfreak.org>; from dima@unixfreak.org on Sat, Jul 14, 2001 at 01:53:16AM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, Jul 14, 2001 at 01:53:16AM -0700, Dima Dorfman wrote: > Terry Lambert writes: > > > > Benchmarks, proving that you increased, or at least did not > > injure performance with this change? > > My wrapper around OpenSSL's BIGNUM library doesn't introduce any > performance penalties beyond one or two more 'call' instructions. If > OpenSSL's BIGNUM library is slower than libgmp (and it probably is), > then someone just needs to fix that. The fact that I decided to write > a wrapper around BIGNUM instead of converting all the programs which > use libmp to use BIGNUM is better from a performance point of view; at > least this way it's easier to change to another BIGNUM implementation > (you'd only have to change this library instead of all those > programs). > > Besides, as has been discussed before, all the applications this is > used for in FreeBSD are not performance-critical. > The version of libgmp in the base system isn't that fast (see ChangeLog for libgmp verssion 3.1.1). If you want a better performance MP library, you'll install libgmp from the ports collection. -- Steve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message