From owner-freebsd-arch Mon Sep 17 9:17:18 2001 Delivered-To: freebsd-arch@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id BDCAC37B40C; Mon, 17 Sep 2001 09:17:06 -0700 (PDT) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f8HGGwa19460; Mon, 17 Sep 2001 19:16:58 +0300 (EEST) (envelope-from ru) Date: Mon, 17 Sep 2001 19:16:57 +0300 From: Ruslan Ermilov To: arch@FreeBSD.org, freebsd-standards@bostonradio.org Cc: Bruce Evans , Garrett Wollman Subject: Re: Fixing chown(8) and friends to handle symlinks properly Message-ID: <20010917191657.A19072@sunbay.com> References: <20010913202742.C2458@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010913202742.C2458@sunbay.com>; from ru@FreeBSD.org on Thu, Sep 13, 2001 at 08:27:42PM +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 Hi! Unless I hear from somebody that they are wishing to review this patch, I will take it as if noone currently has enough spare time to review this, and will just commit this patch on Thursday, 20th. :-) Thanks, On Thu, Sep 13, 2001 at 08:27:42PM +0300, Ruslan Ermilov wrote: > [Bcc'ed to -current in a hope for a more wider auditory] > > The attached patch fixes the handling of symlinks in chown(8) > and chgrp(1). It is currently broken in many different ways. > Basically, it is broken because -h is not supported with -RH > or -RL. The actual problem lies in the depths of the fts(3) > implementation, in particular, how the `fts_stat' is getting > initialized. The trick in supporting roughly any combination > of command line flags ([-h] [-R [-H | -L | -P]]) was to avoid > looking into the `fts_stat' (as we don't know whether it is > from lstat(2) or stat(2)), and just call chown(2) or lchown(2) > as appropriate. Although it may seem as a big performance > degradation, in fact it isn't, as kernel doesn't modify the > inode if nothing is to be changed. > > This work is based on the latest POSIX drafts, and the > superior NetBSD implementation (which I had to fix in a > number of cases anyway, in particular, handling of dead > symlinks in the -h case). > > The new algorithm of handling a symlink encountered during > a file tree traversal works as follows: > > +-------------+-------------------------------------------------+ > | Options | Action | > +-------------+-------------------------------------------------+ > | -- | chown | > | -h | lchown | > | | Notes: only FTS_SL symlinks may end up here | > +-------------+-------------------------------------------------+ > | -RP | SKIP | > | -RP -h | lchown | > | | Notes: only FTS_SL symlinks may end here | > +-------------+-------------------------------------------------+ > | -RH | SKIP | > | -RH -h | lchown | > | | Notes: both FTS_SL and FTS_SLNONE symlinks | > | | may end up here. FTS_SLNONE's are deadlinks | > | | specified as command line arguments | > +-------------+-------------------------------------------------+ > | -RL | SKIP | > | -RL -h | lchown | > | | Notes: only FTS_SLNONE symlinks may end up here | > +-------------+-------------------------------------------------+ > > Or, in a more compact form: > > : if symlink { > : if -R > : -h ? lchmod : SKIP > : else > : -h ? lchmod : chmod > : } else > : chmod > > For the testing purposes, I'd suggest creating the following > structure, which should be self-explaining: > > afile > alink -> afile > deadlink -> nofile > dir > adir -> dir > dir/afile > dir/alink -> afile > dir/deadlink -> nofile > > PLEASE TEST THIS PATCH THROUGHLY! > > NOTE: This implementation is still not quite POSIX compliant, as > the latter says to follow a symlink (in the -R case) only if it > points to an object of type directory. Our fts(3) routines are > unable of doing this. > > If this patch is accepted, I'm going to revisit and fix the rest > of the fts(3) utilities that are listed on the symlink(7) manpage. -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Sep 17 18: 8:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from atg.aciworldwide.com (h139-142-180-4.gtcust.grouptelecom.net [139.142.180.4]) by hub.freebsd.org (Postfix) with ESMTP id 0FD9337B40B for ; Mon, 17 Sep 2001 18:08:20 -0700 (PDT) Received: from atg.aciworldwide.com (localhost [127.0.0.1]) by atg.aciworldwide.com (8.12.0/8.12.0) with ESMTP id f8I18JaX018507; Mon, 17 Sep 2001 19:08:19 -0600 (MDT) Received: from orthanc.ab.ca (uucp@localhost) by atg.aciworldwide.com (8.12.0/8.12.0.Beta14) with UUCP id f8I18I1X018506; Mon, 17 Sep 2001 19:08:18 -0600 (MDT) Received: from localhost (localhost [127.0.0.1]) by orthanc.ab.ca (8.12.0.Beta6/8.11.2) with ESMTP id f8I0Z2U4034342; Mon, 17 Sep 2001 18:35:08 -0600 (MDT) (envelope-from lyndon@orthanc.ab.ca) Message-Id: <200109180035.f8I0Z2U4034342@orthanc.ab.ca> From: Lyndon Nerenberg Organization: The Frobozz Magic Homing Pigeon Company To: Kris Kennaway Cc: FreeBSD.ORG!arch@orthanc.ab.ca Subject: Re: Moving UUCP to ports In-reply-to: Your message of "Sat, 08 Sep 2001 22:37:23 PDT." <20010908223722.A47449@xor.obsecurity.org> Date: Mon, 17 Sep 2001 18:35:02 -0600 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" == Kris Kennaway writes: Kris> I would like to move the UUCP suite from the base system Kris> into ports. The UUCP utilities have a security hole which Kris> yields user uucp access, which can currently be leverage to Kris> obtain root access by trojaning the uucp binaries. This Kris> security hole is believed to be basically unfixable due to Kris> the design of UUCP: we can limit its impact, but not Kris> eliminate it for all users. What's the specific bug here? It's hard to evaluate your request without knowing the actual problem. Is this related to setuid binaries? If so, would you consider a version of UUCP that doesn't require any setuid binaries? Also, please remember that for those sites relying soley on UUCP for connectivity, building from ports may not be an (easily available) option. --lyndon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Sep 17 18:28:26 2001 Delivered-To: freebsd-arch@freebsd.org Received: from buffoon.automagic.org (buffoon.automagic.org [208.185.30.208]) by hub.freebsd.org (Postfix) with SMTP id E638937B410 for ; Mon, 17 Sep 2001 18:28:23 -0700 (PDT) Received: (qmail 74815 invoked by uid 1000); 18 Sep 2001 01:28:23 -0000 Date: Mon, 17 Sep 2001 21:28:23 -0400 From: Joe Abley To: lyndon@orthanc.ab.ca Cc: kris@obsecurity.org, arch@FreeBSD.ORG Subject: Re: Moving UUCP to ports Message-ID: <20010917212822.B52922@buffoon.automagic.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200109180035.f8I0Z2U4034342@orthanc.ab.ca> User-Agent: Mutt/1.3.22.1i 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 [reposted with corrected recipient addresses; bang-paths from an era long past removed with prejudice] On Mon, Sep 17, 2001 at 06:35:02PM -0600, Lyndon Nerenberg wrote: > >>>>> "Kris" == Kris Kennaway writes: > > Kris> I would like to move the UUCP suite from the base system > Kris> into ports. The UUCP utilities have a security hole which > Kris> yields user uucp access, which can currently be leverage to > Kris> obtain root access by trojaning the uucp binaries. This > Kris> security hole is believed to be basically unfixable due to > Kris> the design of UUCP: we can limit its impact, but not > Kris> eliminate it for all users. > > What's the specific bug here? It's hard to evaluate your request > without knowing the actual problem. UUCP was just (in the past week or so) removed from OpenBSD-current and into ports. I don't mean to suggest that anybody here should jump through hoops just because OpenBSD made a decision to do so; however, since it's a recent event I thought it might be newsworthy. I just saw the CVS log entries pertaining to the deUUCPification. Tracking down openbsd mailing list traffic on the subject might be useful. Joe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Sep 17 18:49:16 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 AD0A337B401 for ; Mon, 17 Sep 2001 18:49:09 -0700 (PDT) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id SAA00519; Mon, 17 Sep 2001 18:49:03 -0700 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda00517; Mon Sep 17 18:48:54 2001 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.6/8.9.1) id f8I1ms802577; Mon, 17 Sep 2001 18:48:54 -0700 (PDT) Received: from UNKNOWN(10.1.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdqw2575; Mon Sep 17 18:48:50 2001 Received: (from smtpd@localhost) by cwsys.cwsent.com (8.11.6/8.9.1) id f8I1mYA61148; Mon, 17 Sep 2001 18:48:34 -0700 (PDT) Message-Id: <200109180148.f8I1mYA61148@cwsys.cwsent.com> X-Authentication-Warning: cwsys.cwsent.com: smtpd set sender to using -f Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdk61144; Mon Sep 17 18:48:23 2001 X-Mailer: exmh version 2.5 07/13/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: Joe Abley Cc: lyndon@orthanc.ab.ca, kris@obsecurity.org, arch@FreeBSD.ORG Subject: Re: Moving UUCP to ports In-reply-to: Your message of "Mon, 17 Sep 2001 21:28:23 EDT." <20010917212822.B52922@buffoon.automagic.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 17 Sep 2001 18:48:23 -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 <20010917212822.B52922@buffoon.automagic.org>, Joe Abley writes: > [reposted with corrected recipient addresses; bang-paths from an > era long past removed with prejudice] > > On Mon, Sep 17, 2001 at 06:35:02PM -0600, Lyndon Nerenberg wrote: > > >>>>> "Kris" == Kris Kennaway writes: > > > > Kris> I would like to move the UUCP suite from the base system > > Kris> into ports. The UUCP utilities have a security hole which > > Kris> yields user uucp access, which can currently be leverage to > > Kris> obtain root access by trojaning the uucp binaries. This > > Kris> security hole is believed to be basically unfixable due to > > Kris> the design of UUCP: we can limit its impact, but not > > Kris> eliminate it for all users. > > > > What's the specific bug here? It's hard to evaluate your request > > without knowing the actual problem. > > UUCP was just (in the past week or so) removed from OpenBSD-current > and into ports. I don't mean to suggest that anybody here should jump > through hoops just because OpenBSD made a decision to do so; however, > since it's a recent event I thought it might be newsworthy. > > I just saw the CVS log entries pertaining to the deUUCPification. > Tracking down openbsd mailing list traffic on the subject might be > useful. A bug was discovered in Taylor UUCP (the UUCP used by most of the UNIX world) and published on BUGTRAQ that users could execute arbitrary commands as the UUCP user. UUCP was designed for a more time and is probably inappropriate for today's world. Hence it should be moved to ports and installed by only those who need its functionality. In an ideal world it would not even be in ports, however there are applications and people who still use and need UUCP, so moving it to ports is probably the most appropriate thing we can do. 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 Ministry of Management Services 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 Mon Sep 17 19:40:48 2001 Delivered-To: freebsd-arch@freebsd.org Received: from atg.aciworldwide.com (h139-142-180-4.gtcust.grouptelecom.net [139.142.180.4]) by hub.freebsd.org (Postfix) with ESMTP id B098C37B405 for ; Mon, 17 Sep 2001 19:40:46 -0700 (PDT) Received: from atg.aciworldwide.com (localhost [127.0.0.1]) by atg.aciworldwide.com (8.12.0/8.12.0) with ESMTP id f8I2eiaX018791; Mon, 17 Sep 2001 20:40:44 -0600 (MDT) Received: (from uucp@localhost) by atg.aciworldwide.com (8.12.0/8.12.0.Beta14) with UUCP id f8I2eaqD018790; Mon, 17 Sep 2001 20:40:36 -0600 (MDT) Received: from localhost (localhost [127.0.0.1]) by orthanc.ab.ca (8.12.0.Beta6/8.11.2) with ESMTP id f8I2ZSXr001395; Mon, 17 Sep 2001 20:35:28 -0600 (MDT) (envelope-from lyndon@orthanc.ab.ca) Message-Id: <200109180235.f8I2ZSXr001395@orthanc.ab.ca> From: Lyndon Nerenberg Organization: The Frobozz Magic Homing Pigeon Company To: Cy Schubert - ITSD Open Systems Group Cc: Joe Abley , kris@obsecurity.org, arch@FreeBSD.ORG Subject: Re: Moving UUCP to ports In-reply-to: Your message of "Mon, 17 Sep 2001 18:48:23 PDT." <200109180148.f8I1mYA61148@cwsys.cwsent.com> Date: Mon, 17 Sep 2001 20:35:28 -0600 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 checked out the bugtraq report. This is far from "unfixable." Just get rid of the (IMO bogus) --config flag on all the UUCP commands. --lyndon (who _thinks_ he's got his sendmail UUCP mailer rules fixed now) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Sep 17 19:45:24 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-64-169-104-168.dsl.lsan03.pacbell.net [64.169.104.168]) by hub.freebsd.org (Postfix) with ESMTP id 839D137B408 for ; Mon, 17 Sep 2001 19:45:20 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 8BAA966D20; Mon, 17 Sep 2001 19:45:19 -0700 (PDT) Date: Mon, 17 Sep 2001 19:45:19 -0700 From: Kris Kennaway To: Lyndon Nerenberg Cc: Cy Schubert - ITSD Open Systems Group , Joe Abley , kris@obsecurity.org, arch@FreeBSD.ORG Subject: Re: Moving UUCP to ports Message-ID: <20010917194519.A39672@xor.obsecurity.org> References: <200109180148.f8I1mYA61148@cwsys.cwsent.com> <200109180235.f8I2ZSXr001395@orthanc.ab.ca> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="6TrnltStXW4iwmi0" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200109180235.f8I2ZSXr001395@orthanc.ab.ca>; from lyndon@orthanc.ab.ca on Mon, Sep 17, 2001 at 08:35:28PM -0600 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 --6TrnltStXW4iwmi0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Sep 17, 2001 at 08:35:28PM -0600, Lyndon Nerenberg wrote: > I checked out the bugtraq report. This is far from "unfixable." Just > get rid of the (IMO bogus) --config flag on all the UUCP commands. That's apparently widely used functionality. My original proposed patch restricted --config/-I to root, but ache told me lots of people need that to work. Kris --6TrnltStXW4iwmi0 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 iD8DBQE7prU+Wry0BWjoQKURAjitAJ90oheq3+Meh0HgTpe/tM6rLvm+xwCeLyrt 24cTBOYmtiITZzdgh2kuBF8= =49dl -----END PGP SIGNATURE----- --6TrnltStXW4iwmi0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Sep 17 23:10:16 2001 Delivered-To: freebsd-arch@freebsd.org Received: from robin.mail.pas.earthlink.net (robin.mail.pas.earthlink.net [207.217.120.65]) by hub.freebsd.org (Postfix) with ESMTP id 5AB9037B401 for ; Mon, 17 Sep 2001 23:10:12 -0700 (PDT) Received: from mindspring.com (dialup-209.245.141.224.Dial1.SanJose1.Level3.net [209.245.141.224]) by robin.mail.pas.earthlink.net (8.11.5/8.9.3) with ESMTP id f8I6A5I00725; Mon, 17 Sep 2001 23:10:06 -0700 (PDT) Message-ID: <3BA6E56C.1121FBB5@mindspring.com> Date: Mon, 17 Sep 2001 23:10:52 -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: Joe Abley Cc: lyndon@orthanc.ab.ca, kris@obsecurity.org, arch@FreeBSD.ORG Subject: Re: Moving UUCP to ports References: <20010917212822.B52922@buffoon.automagic.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 Joe Abley wrote: > UUCP was just (in the past week or so) removed from OpenBSD-current > and into ports. I don't mean to suggest that anybody here should jump > through hoops just because OpenBSD made a decision to do so; however, > since it's a recent event I thought it might be newsworthy. Leave it alone, unless you can identify a vendor who is maintaining it, and we can agree to select that vendor as the "official" vendor of UUCP, from this day forward. Next people will be suggesting that we make /bin/ls a port... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Sep 17 23:18:15 2001 Delivered-To: freebsd-arch@freebsd.org Received: from cain.gsoft.com.au (genesi.lnk.telstra.net [139.130.136.161]) by hub.freebsd.org (Postfix) with ESMTP id A311137B403 for ; Mon, 17 Sep 2001 23:18:05 -0700 (PDT) Received: from cain.gsoft.com.au (root@spare0.gsoft.com.au [203.38.152.114]) by cain.gsoft.com.au (8.8.8/8.8.8) with ESMTP id PAA08230; Tue, 18 Sep 2001 15:47:37 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Message-ID: X-Mailer: XFMail 1.5.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <3BA6E56C.1121FBB5@mindspring.com> Date: Tue, 18 Sep 2001 15:47:37 +0930 (CST) From: "Daniel O'Connor" To: Terry Lambert Subject: Re: Moving UUCP to ports Cc: arch@FreeBSD.ORG, kris@obsecurity.org, lyndon@orthanc.ab.ca, Joe Abley 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 18-Sep-2001 Terry Lambert wrote: > Leave it alone, unless you can identify a vendor who is > maintaining it, and we can agree to select that vendor as > the "official" vendor of UUCP, from this day forward. > > Next people will be suggesting that we make /bin/ls a port... Except that 100% of users use ls. About 0%* use UUCP. * Straw poll from every person I've ever talked to about FreeBSD. --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Sep 17 23:36: 4 2001 Delivered-To: freebsd-arch@freebsd.org Received: from robin.mail.pas.earthlink.net (robin.mail.pas.earthlink.net [207.217.120.65]) by hub.freebsd.org (Postfix) with ESMTP id 052A037B405 for ; Mon, 17 Sep 2001 23:36:02 -0700 (PDT) Received: from mindspring.com (dialup-209.245.141.224.Dial1.SanJose1.Level3.net [209.245.141.224]) by robin.mail.pas.earthlink.net (8.11.5/8.9.3) with ESMTP id f8I6ZXI20428; Mon, 17 Sep 2001 23:35:33 -0700 (PDT) Message-ID: <3BA6EB64.A4F9720C@mindspring.com> Date: Mon, 17 Sep 2001 23:36:20 -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: "Daniel O'Connor" Cc: arch@FreeBSD.ORG, kris@obsecurity.org, lyndon@orthanc.ab.ca, Joe Abley Subject: Re: Moving UUCP to ports References: 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 Daniel O'Connor wrote: > > Leave it alone, unless you can identify a vendor who is > > maintaining it, and we can agree to select that vendor as > > the "official" vendor of UUCP, from this day forward. > > > > Next people will be suggesting that we make /bin/ls a port... > > Except that 100% of users use ls. > About 0%* use UUCP. > > * Straw poll from every person I've ever talked to about FreeBSD. I use UUCP. Unlike fetchmail, delivery of mail via UUCP over TCP does not destroy envelope information, yet permits me to run a server in dialup mode. Another person just recently posted in favor of UUCP. In any case, you have ignored the first argument: if FreeBSD does not maintain UUCP for FreeBSD, who will maintain UUCP for FreeBSD? -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Sep 17 23:54: 3 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-64-169-104-168.dsl.lsan03.pacbell.net [64.169.104.168]) by hub.freebsd.org (Postfix) with ESMTP id 2352437B412 for ; Mon, 17 Sep 2001 23:54:00 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 4516E66D46; Mon, 17 Sep 2001 23:53:57 -0700 (PDT) Date: Mon, 17 Sep 2001 23:53:57 -0700 From: Kris Kennaway To: Terry Lambert Cc: Daniel O'Connor , arch@FreeBSD.ORG Subject: Re: Moving UUCP to ports Message-ID: <20010917235356.A41864@xor.obsecurity.org> References: <3BA6EB64.A4F9720C@mindspring.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="envbJBWh7q8WU6mo" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BA6EB64.A4F9720C@mindspring.com>; from tlambert2@mindspring.com on Mon, Sep 17, 2001 at 11:36:20PM -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 --envbJBWh7q8WU6mo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Sep 17, 2001 at 11:36:20PM -0700, Terry Lambert wrote: > In any case, you have ignored the first argument: if FreeBSD > does not maintain UUCP for FreeBSD, who will maintain UUCP > for FreeBSD? Jeez, Terry..it's times like this I think you say this kind of thing just to be difficult. No-one has been maintaining UUCP in FreeBSD for the past several years (do a quick search on open PRs), but if someone suddenly wanted to they can maintain the port just as easily (easier, since anyone in the world can be a port maintainer, whereas you have to be a committer to maintain code in the base system). I would have thought that to be obvious. Kris --envbJBWh7q8WU6mo 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 iD8DBQE7pu+EWry0BWjoQKURAtAaAJ9wUO8aXKe1JCSRvqYCM+biwHwbIgCggvgZ OUyCfDB98dqTND+sKwTJm6Y= =Tprm -----END PGP SIGNATURE----- --envbJBWh7q8WU6mo-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Sep 18 9:12: 4 2001 Delivered-To: freebsd-arch@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 965F537B403 for ; Tue, 18 Sep 2001 09:06:21 -0700 (PDT) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f8IG2Mr66089; Tue, 18 Sep 2001 19:02:22 +0300 (EEST) (envelope-from ru) Date: Tue, 18 Sep 2001 19:02:22 +0300 From: Ruslan Ermilov To: "Andrey A. Chernov" , Garrett Wollman Cc: arch@FreeBSD.ORG, freebsd-standards@bostonradio.org Subject: Re: Fixing chown(8) and friends to handle symlinks properly Message-ID: <20010918190222.F4648@sunbay.com> References: <20010913202742.C2458@sunbay.com> <20010917191657.A19072@sunbay.com> <200109172143.f8HLhkU41334@khavrinen.lcs.mit.edu> <20010913202742.C2458@sunbay.com> <20010914060800.A27869@nagual.pp.ru> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="DocE+STaALJfprDB" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010914060800.A27869@nagual.pp.ru>; from ache@nagual.pp.ru on Fri, Sep 14, 2001 at 06:08:02AM +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 --DocE+STaALJfprDB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, After re-reading the POSIX.1-200x draft and the symlink(7) manpage, I have developed another patch (the winner!) that implements what I think is required by POSIX, while still preserving the basic ideas of symlink(7). As Garrett properly pointed out, in POSIX, as well as in symlink(7), -h is required to affect the lchown(2)/chown(2) selection only in the non-recursive case. Note also that POSIX differentiates between a symlink referencing a file of type directory and a symlink referencing a non-directory type object. In the -RH case, if symlink to a directory is specified on the command line, POSIX says we should change the ownership of the directory referenced by a symlink and all files in the hierarchy below it. FreeBSD currently follows a symlink referencing a non-directory object as well. In the -RL case, all symlinks to directories, either specified on the command line or encountered during the tree traversal, should be followed. FreeBSD currently follows any symlinks it encounters during the tree traversal, regardless of the type of a file they point to. In the -RP case, no symlinks should be followed and chown(8) should change the ownership of symlinks with lchown(2). This applies to any type of a symlink, whether it points to a directory or not. POSIX doesn't say anything about what to do with symlinks to non-directory objects encountered during a tree traversal in the -RH and -RL cases. Also, it doesn't say what to do with symlinks to directories in the -RH case that were encountered during a tree traversal. The attached patch resolves this as follows. For every symlink that is NOT followed, we call lchown(2). For -RP, this is what is required by POSIX. It is my guess that this is the behavior that was actually planned by the POSIX authors. Note also that we now never follow symlinks to non-directories during the -R traversal. Currently, in the -RL case, FreeBSD follows ALL symlinks. Now, only symlinks to directories are followed, as regulated by -H and -L. This is a good security change, indeed! This patch also restores the optimization based on the contents of the ``fts_statp'' structure member. To summarize, the algorithm operates as follows: +---------+-----------------------+-----------------------+ | Options | Directory symlink | Non-directory symlink | +---------+-----------------------+-----------------------+ | -- | follow | follow | +---------+-----------------------+-----------------------+ | -h | lchown(2) | lchown(2) | +---------+-----------------------+-----------------------+ | -RP | lchown(2) | lchown(2) | +---------+-----------------------+-----------------------+ | -RH | follow if on cmdline, | lchown(2) | | | lchown(2) otherwise | | +---------+-----------------------+-----------------------+ | -RL | follow | lchown(2) | +---------+-----------------------+-----------------------+ Notes for the reviewers. 1. We now always perform the FTS_PHYSICAL search, and only follow symlinks that reference directories, as determined by the -H and -L flags. 2. In the non-recursive case, if the file operand designated a symlink and no -h was specified, we follow it. At first glance it may seem we could just chown(2) it. This would be undesirable for two reasons. First, this would result in a ENOENT (like in the previous version of the patch) if the underlying object does not exist -- OTOH, FreeBSD currently silently ignores this. Second, we need to make sure that ``fts_statp'' is properly initialized by either stat(2) or lstat(2) depending on whether we are going to chown(2) or lchown(2) the object because the heuristic code relies on the contents of ``fts_statp'' to avoid unnecessary syscalls. For non-symlinks this is irrelevant, as chown(2) and lchown(2) return the same information. But in this case we are going to call chown(2) on a symlink, and since we perform a physical search, fts_read() initializes ``fts_statp'' with lchown(2). Here we simply follow it and kill two birds at once -- if the link points to a non-existing object, the next call to fts_read() will return FTS_SLNONE, and we silently skip it, as in the -R case. Otherwise, fts_read() reinitializes the ``fts_statp'' by a call to stat(2), and our heuristics code (commented out in the DEBUG case) can rely on the contents of the ``struct stat'' buffer. On Fri, Sep 14, 2001 at 06:08:02AM +0400, Andrey A. Chernov wrote: > On Thu, Sep 13, 2001 at 20:27:42 +0300, Ruslan Ermilov wrote: > > > NOTE: This implementation is still not quite POSIX compliant, as > > the latter says to follow a symlink (in the -R case) only if it > > points to an object of type directory. Our fts(3) routines are > > unable of doing this. > > > Is there a way to fix fts(3) to implement this? I.e. modify fts(3) to make > directory test before following anywhere. On Mon, Sep 17, 2001 at 05:43:46PM -0400, Garrett Wollman wrote: > < said: > > > Unless I hear from somebody that they are wishing to review > > this patch, I will take it as if noone currently has enough > > spare time to review this, and will just commit this patch > > on Thursday, 20th. :-) > > >> | -RP | SKIP | > >> | -RP -h | lchown | > >> | | Notes: only FTS_SL symlinks may end here | > > This is not right. Draft 7 states: > > -P If the -R option is specified and a symbolic link is specified > on the command line or encountered during the traversal of a > file hierarchy, chown shall change the owner ID (and group ID, > if specified) of the symbolic link if the system supports this > operation. The chown utility shall not follow the symbolic link > to any other part of the file hierarchy. > > That is to say, when `-R -P' is specified, the owner (and group) shall > be changed, regardless of whether `-h' has been specified. > > My interepretation of the description in draft 7 is that `-h' applies > *only* to command-line operands, and is not relevant to recursive > operation, where `-P', and only `-P', can result in lchown(). -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age --DocE+STaALJfprDB Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p Index: chown.c =================================================================== RCS file: /home/ncvs/src/usr.sbin/chown/chown.c,v retrieving revision 1.19 diff -u -p -u -p -r1.19 chown.c --- chown.c 2001/09/13 14:55:59 1.19 +++ chown.c 2001/09/18 15:56:37 @@ -78,8 +78,10 @@ main(argc, argv) FTS *ftsp; FTSENT *p; int Hflag, Lflag, Rflag, fflag, hflag, vflag; - int ch, fts_options, rval; + int ch, rval; char *cp; + struct stat sb; + int (*change_owner) __P((const char *, uid_t, gid_t)); cp = strrchr(argv[0], '/'); cp = (cp != NULL) ? cp + 1 : argv[0]; @@ -121,20 +123,6 @@ main(argc, argv) if (argc < 2) usage(); - if (Rflag) { - fts_options = FTS_PHYSICAL; - if (hflag && (Hflag || Lflag)) - errx(1, "the -R%c and -h options may not be " - "specified together", Hflag ? 'H' : 'L'); - if (Hflag) - fts_options |= FTS_COMFOLLOW; - else if (Lflag) { - fts_options &= ~FTS_PHYSICAL; - fts_options |= FTS_LOGICAL; - } - } else - fts_options = hflag ? FTS_PHYSICAL : FTS_LOGICAL; - uid = (uid_t)-1; gid = (gid_t)-1; if (ischown) { @@ -152,10 +140,11 @@ main(argc, argv) } else a_gid(*argv); - if ((ftsp = fts_open(++argv, fts_options, 0)) == NULL) + if ((ftsp = fts_open(++argv, FTS_PHYSICAL, 0)) == NULL) err(1, NULL); for (rval = 0; (p = fts_read(ftsp)) != NULL;) { + change_owner = chown; switch (p->fts_info) { case FTS_D: /* Change it at FTS_DP. */ if (!Rflag) @@ -171,30 +160,65 @@ main(argc, argv) rval = 1; continue; case FTS_SL: + /* + * If not traversing a file tree and -h was not + * specified, follow symlinks. This is done to + * reinitialize the p->fts_statp with stat(2). + * + * If traversing a file tree, check if we were + * asked to follow symlinks to directories. + */ + if ((!Rflag && !hflag) || + (Rflag && (Lflag || (Hflag && p->fts_level == 0)) && + stat(p->fts_accpath, &sb) == 0 && + S_ISDIR(sb.st_mode))) { + fts_set(ftsp, p, FTS_FOLLOW); + continue; + } + if (hflag || Rflag) + change_owner = lchown; + break; case FTS_SLNONE: /* * The only symlinks that end up here are ones that - * don't point to anything and ones that we found - * doing a physical walk. + * don't point to anything. Note that since we are + * doing a physical walk, we never reach here unless + * we asked to follow explicitly. + * + * When following a symlink to a directory above, + * the directory may be deleted (or renamed) in a + * small window between the calls to fts_set() and + * fts_read(), causing FTS_SLNONE to be returned. */ - if (hflag) - break; - else - continue; + continue; default: break; } +#define DEBUG +#ifdef DEBUG + if ((change_owner == chown ? stat : lstat)(p->fts_accpath, &sb) == -1) + abort(); + if (sb.st_ino != p->fts_statp->st_ino) + abort(); +#else if ((uid == (uid_t)-1 || uid == p->fts_statp->st_uid) && (gid == (gid_t)-1 || gid == p->fts_statp->st_gid)) continue; - if ((hflag ? lchown : chown)(p->fts_accpath, uid, gid) == -1) { +#endif + if ((*change_owner)(p->fts_accpath, uid, gid) == -1) { if (!fflag) { chownerr(p->fts_path); rval = 1; } } else { if (vflag) +#ifdef DEBUG + printf("%s %s\n", + (change_owner == chown) ? "chown" : "lchown", + p->fts_path); +#else printf("%s\n", p->fts_path); +#endif } } if (errno) @@ -275,11 +299,12 @@ usage() if (ischown) (void)fprintf(stderr, "%s\n%s\n", - "usage: chown [-fhv] [-R [-H | -L | -P]] owner[:group]" + "usage: chown [-fv] [-h | -R [-H | -L | -P]] owner[:group]" " file ...", - " chown [-fhv] [-R [-H | -L | -P]] :group file ..."); + " chown [-fv] [-h | -R [-H | -L | -P]] :group" + " file ..."); else (void)fprintf(stderr, "%s\n", - "usage: chgrp [-fhv] [-R [-H | -L | -P]] group file ..."); + "usage: chgrp [-fv] [-h | -R [-H | -L | -P]] group file ..."); exit(1); } Index: chown.8 =================================================================== RCS file: /home/ncvs/src/usr.sbin/chown/chown.8,v retrieving revision 1.17 diff -u -p -u -p -r1.17 chown.8 --- chown.8 2001/09/11 13:07:03 1.17 +++ chown.8 2001/09/18 15:56:38 @@ -32,7 +32,7 @@ .\" @(#)chown.8 8.3 (Berkeley) 3/31/94 .\" $FreeBSD: src/usr.sbin/chown/chown.8,v 1.17 2001/09/11 13:07:03 dd Exp $ .\" -.Dd March 31, 1994 +.Dd September 18, 2001 .Dt CHOWN 8 .Os .Sh NAME @@ -40,59 +40,89 @@ .Nd change file owner and group .Sh SYNOPSIS .Nm -.Op Fl fhv -.Oo -.Fl R -.Op Fl H | Fl L | Fl P -.Oc +.Op Fl fv +.Op Fl h | R Op Fl H | L | P .Ar owner Ns Op : Ns Ar group .Ar .Nm -.Op Fl fhv -.Oo -.Fl R -.Op Fl H | Fl L | Fl P -.Oc +.Op Fl fv +.Op Fl h | R Op Fl H | L | P .No : Ns Ar group .Ar .Sh DESCRIPTION -.Nm Chown -sets the user ID and/or the group ID of the specified files. +The +.Nm +utility changes the user ID and/or the group ID of the specified files. .Pp -The options are as follows: -.Bl -tag -width Ds +The following options are available: +.Bl -tag -width indent .It Fl H If the .Fl R -option is specified, symbolic links on the command line are followed. -(Symbolic links encountered in the tree traversal are not followed.) +option is specified +and a symbolic link +referencing a file of type directory +is specified on the command line, +change the user ID and/or the group ID +of the directory referenced by the link +and all files in the subtree below it. +Otherwise, +change the user ID and/or the group ID +of the link itself +rather than the file that the link points to. .It Fl L If the .Fl R -option is specified, all symbolic links are followed. +option is specified +and a symbolic link +referencing a file of type directory +is specified on the command line +or encountered during the tree traversal, +change the user ID and/or the group ID +of the directory referenced by the link +and all files in the subtree below it. +Otherwise, +change the user ID and/or the group ID +of the link itself +rather than the file that the link points to. .It Fl P If the .Fl R -option is specified, no symbolic links are followed. -This is the default. +option is specified +and a symbolic link +is specified on the command line +or encountered during the tree traversal, +change the user ID and/or the group ID +of the link itself +rather than the file that the link points to. .It Fl R -Change the user ID and/or the group ID for the file hierarchies rooted -in the files instead of just the files themselves. +If +.Ar file +argument designates a directory, +change the user ID and/or the group ID +of the directory +and all files in the subtree below it. .It Fl f -Don't report any failure to change file owner or group, nor modify -the exit status to reflect such failures. +Do not report any failure to +change the user ID and/or the group ID +of the file, +nor modify the exit status to reflect such failures. .It Fl h -If the file is a symbolic link, change the user ID and/or the group ID -of the link itself rather than the file that the link points to. +If the +.Fl R +option is not specified +and +.Ar file +argument is a symbolic link, +change the user ID and/or the group ID +of the link itself +rather than the file that the link points to. .It Fl v -Cause -.Nm -to be verbose, showing files as the owner is modified. +Be verbose, showing files as the owner and/or group is modified. .El .Pp The -.Fl H , -.Fl L +.Fl H , L and .Fl P options are ignored unless the @@ -100,6 +130,9 @@ options are ignored unless the option is specified. In addition, these options override each other and the command's actions are determined by the last one specified. +If none are specified, the +default is +.Fl P . .Pp The .Ar owner @@ -108,7 +141,9 @@ and operands are both optional, however, one must be specified. If the .Ar group -operand is specified, it must be preceded by a colon (``:'') character. +operand is specified, it must be preceded by a colon +.Pq Dq Li \&: +character. .Pp The .Ar owner @@ -128,8 +163,12 @@ obvious security reasons. .Sh COMPATIBILITY Previous versions of the .Nm -utility used the dot (``.'') character to distinguish the group name. -This has been changed to be a colon (``:'') character so that user and +utility used the dot +.Pq Dq Li \&. +character to distinguish the group name. +This has been changed to be a colon +.Pq Dq Li \&: +character so that user and group names may contain the dot character. .Pp On previous versions of this system, symbolic links did not have @@ -143,15 +182,18 @@ option is non-standard and its use in sc .Xr find 1 , .Xr chown 2 , .Xr fts 3 , +.Xr group 5 , +.Xr passwd 5 , .Xr symlink 7 .Sh STANDARDS The .Nm -command is expected to be -.St -p1003.2 +utility is expected to be +.\" .St -p1003.1-200x +.Tn IEEE No Std 1003.1-200x Pq Dq Tn POSIX Ns .1 compliant. .Sh HISTORY A .Nm -command appeared in +utility appeared in .At v1 . Index: chgrp.1 =================================================================== RCS file: /home/ncvs/src/usr.sbin/chown/chgrp.1,v retrieving revision 1.13 diff -u -p -u -p -r1.13 chgrp.1 --- chgrp.1 2001/08/15 09:09:46 1.13 +++ chgrp.1 2001/09/18 15:56:38 @@ -35,7 +35,7 @@ .\" @(#)chgrp.1 8.3 (Berkeley) 3/31/94 .\" $FreeBSD: src/usr.sbin/chown/chgrp.1,v 1.13 2001/08/15 09:09:46 ru Exp $ .\" -.Dd March 31, 1994 +.Dd September 18, 2001 .Dt CHGRP 1 .Os .Sh NAME @@ -43,56 +43,84 @@ .Nd change group .Sh SYNOPSIS .Nm -.Op Fl fhv -.Oo -.Fl R -.Op Fl H | Fl L | Fl P -.Oc +.Op Fl fv +.Op Fl h | R Op Fl H | L | P .Ar group .Ar .Sh DESCRIPTION The .Nm -utility sets the group ID of the file named by each -.Ar file -operand to the -.Ar group -ID specified by the group operand. +utility changes the group ID of the specified files. .Pp The following options are available: .Bl -tag -width indent .It Fl H If the .Fl R -option is specified, symbolic links on the command line are followed. -(Symbolic links encountered in the tree traversal are not followed). +option is specified +and a symbolic link +referencing a file of type directory +is specified on the command line, +change the group ID +of the directory referenced by the link +and all files in the subtree below it. +Otherwise, +change the group ID +of the link itself +rather than the file that the link points to. .It Fl L If the .Fl R -option is specified, all symbolic links are followed. +option is specified +and a symbolic link +referencing a file of type directory +is specified on the command line +or encountered during the tree traversal, +change the group ID +of the directory referenced by the link +and all files in the subtree below it. +Otherwise, +change the group ID +of the link itself +rather than the file that the link points to. .It Fl P If the .Fl R -option is specified, no symbolic links are followed. -This is the default. +option is specified +and a symbolic link +is specified on the command line +or encountered during the tree traversal, +change the group ID +of the link itself +rather than the file that the link points to. .It Fl R -Change the group ID for the file hierarchies rooted -in the files instead of just the files themselves. +If +.Ar file +argument designates a directory, +change the group ID +of the directory +and all files in the subtree below it. .It Fl f -The force option ignores errors, except for usage errors and doesn't -query about strange modes (unless the user does not have proper permissions). +Do not report any failure to +change the group ID +of the file, +nor modify the exit status to reflect such failures. .It Fl h -If the file is a symbolic link, the group ID of the link itself is changed -rather than the file that is pointed to. +If the +.Fl R +option is not specified +and +.Ar file +argument is a symbolic link, +change the group ID +of the link itself +rather than the file that the link points to. .It Fl v -Cause -.Nm -to be verbose, showing files as the group is modified. +Be verbose, showing files as the group is modified. .El .Pp The -.Fl H , -.Fl L +.Fl H , L and .Fl P options are ignored unless the @@ -100,11 +128,13 @@ options are ignored unless the option is specified. In addition, these options override each other and the command's actions are determined by the last one specified. +If none are specified, the +default is +.Fl P . .Pp The .Ar group -operand can be either a group name from the group database, -or a numeric group ID. +may be either a numeric group ID or a group name. If a group name is also a numeric group ID, the operand is used as a group name. .Pp @@ -115,17 +145,19 @@ or be the super-user. .Sh DIAGNOSTICS .Ex -std .Sh COMPATIBILITY -In previous versions of this system, symbolic links did not have groups. +On previous versions of this system, symbolic links did not have +groups. .Pp The .Fl v option is non-standard and its use in scripts is not recommended. .Sh FILES -.Bl -tag -width /etc/group -compact +.Bl -tag -width ".Pa /etc/group" -compact .It Pa /etc/group group ID file .El .Sh SEE ALSO +.Xr find 1 , .Xr chown 2 , .Xr fts 3 , .Xr group 5 , @@ -136,5 +168,6 @@ group ID file The .Nm utility is expected to be -.St -p1003.2 -compatible. +.\" .St -p1003.1-200x +.Tn IEEE No Std 1003.1-200x Pq Dq Tn POSIX Ns .1 +compliant. --DocE+STaALJfprDB-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Sep 18 12:20:52 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp.noos.fr (zola.noos.net [212.198.2.76]) by hub.freebsd.org (Postfix) with ESMTP id 019DD37B416 for ; Tue, 18 Sep 2001 12:20:50 -0700 (PDT) Received: (qmail 4256221 invoked by uid 0); 18 Sep 2001 19:20:48 -0000 Received: from unknown (HELO gits.dyndns.org) ([212.198.231.187]) (envelope-sender ) by 212.198.2.76 (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 18 Sep 2001 19:20:48 -0000 Received: (from root@localhost) by gits.dyndns.org (8.11.6/8.11.6) id f8IJKln67463; Tue, 18 Sep 2001 21:20:47 +0200 (CEST) (envelope-from root) Message-Id: <200109181920.f8IJKln67463@gits.dyndns.org> Subject: Re: Moving UUCP to ports In-Reply-To: <20010917235356.A41864@xor.obsecurity.org> To: Kris Kennaway Date: Tue, 18 Sep 2001 21:20:47 +0200 (CEST) Cc: Terry Lambert , "Daniel O'Connor" , arch@FreeBSD.ORG Reply-To: clefevre@citeweb.net From: Cyrille Lefevre Organization: ACME X-Face: V|+c;4!|B?E%BE^{E6);aI.[<97Zd*>^#%Y5Cxv;%Y[PT-LW3;A:fRrJ8+^k"e7@+30g0YD0*^^3jgyShN7o?a]C la*Zv'5NA,=963bM%J^o]C X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit 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 Kris Kennaway wrote: [snip] > No-one has been maintaining UUCP in FreeBSD for the past several years > (do a quick search on open PRs), but if someone suddenly wanted to > they can maintain the port just as easily (easier, since anyone in the > world can be a port maintainer, whereas you have to be a committer to > maintain code in the base system). IMHO, your assertion is wrong, since anybody could sumbit a PR as anybody do to update a port w/o commiter rights. Cyrille. -- Cyrille Lefevre mailto:clefevre@citeweb.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Sep 18 12:36:11 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-64-169-104-168.dsl.lsan03.pacbell.net [64.169.104.168]) by hub.freebsd.org (Postfix) with ESMTP id A45BC37B40F for ; Tue, 18 Sep 2001 12:36:05 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id E155A66D46; Tue, 18 Sep 2001 12:36:00 -0700 (PDT) Date: Tue, 18 Sep 2001 12:36:00 -0700 From: Kris Kennaway To: Cyrille Lefevre Cc: Kris Kennaway , Terry Lambert , Daniel O'Connor , arch@FreeBSD.ORG Subject: Re: Moving UUCP to ports Message-ID: <20010918123600.A49263@xor.obsecurity.org> References: <20010917235356.A41864@xor.obsecurity.org> <200109181920.f8IJKln67463@gits.dyndns.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="sm4nu43k4a2Rpi4c" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200109181920.f8IJKln67463@gits.dyndns.org>; from clefevre@citeweb.net on Tue, Sep 18, 2001 at 09:20:47PM +0200 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 --sm4nu43k4a2Rpi4c Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 18, 2001 at 09:20:47PM +0200, Cyrille Lefevre wrote: > Kris Kennaway wrote: > [snip] > > No-one has been maintaining UUCP in FreeBSD for the past several years > > (do a quick search on open PRs), but if someone suddenly wanted to > > they can maintain the port just as easily (easier, since anyone in the > > world can be a port maintainer, whereas you have to be a committer to > > maintain code in the base system). >=20 > IMHO, your assertion is wrong, since anybody could sumbit a PR as > anybody do to update a port w/o commiter rights. Isn't that what I said? Kris --sm4nu43k4a2Rpi4c 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 iD8DBQE7p6IgWry0BWjoQKURAtCHAJ4y2hlolvWs2iHCnrGm0zDfpsclMgCgnUGc hvxbARSgwzdO/C6RnZN6QbM= =D9JI -----END PGP SIGNATURE----- --sm4nu43k4a2Rpi4c-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Sep 18 12:41:26 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 634CB37B408 for ; Tue, 18 Sep 2001 12:41:23 -0700 (PDT) Received: from dialup-209.247.143.42.dial1.sanjose1.level3.net ([209.247.143.42] helo=mindspring.com) by avocet.mail.pas.earthlink.net with esmtp (Exim 3.32 #2) id 15jQjy-0001L2-00; Tue, 18 Sep 2001 12:41:06 -0700 Message-ID: <3BA7A37E.93DA21B8@mindspring.com> Date: Tue, 18 Sep 2001 12:41:50 -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: Kris Kennaway Cc: Daniel O'Connor , arch@FreeBSD.ORG Subject: Re: Moving UUCP to ports References: <3BA6EB64.A4F9720C@mindspring.com> <20010917235356.A41864@xor.obsecurity.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 Kris Kennaway wrote: > In any case, you have ignored the first argument: if FreeBSD > > does not maintain UUCP for FreeBSD, who will maintain UUCP > > for FreeBSD? > > Jeez, Terry..it's times like this I think you say this kind of thing > just to be difficult. > > No-one has been maintaining UUCP in FreeBSD for the past several years > (do a quick search on open PRs), but if someone suddenly wanted to > they can maintain the port just as easily (easier, since anyone in the > world can be a port maintainer, whereas you have to be a committer to > maintain code in the base system). > > I would have thought that to be obvious. Except that most of the people in the world don't have an FTP server, and the ISP links that they do have prevent them from running a server at all -- and it is *precisely* these people who need UUCP. To your point about it "not having been maintained": I prefer to think of it as an "if it isn't broke, don't fix it". Can we move on to talking about making sendmail and perl into ports instead? -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Sep 18 12:50:40 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.yadt.co.uk (yadt.demon.co.uk [158.152.4.134]) by hub.freebsd.org (Postfix) with SMTP id A63FC37B405 for ; Tue, 18 Sep 2001 12:50:24 -0700 (PDT) Received: (qmail 34428 invoked from network); 18 Sep 2001 19:50:22 -0000 Received: from gattaca.local.yadt.co.uk (HELO mail.gattaca.yadt.co.uk) (qmailr@10.0.0.2) by xfiles.yadt.co.uk with SMTP; 18 Sep 2001 19:50:22 -0000 Received: (qmail 36278 invoked by uid 1000); 18 Sep 2001 19:50:21 -0000 Date: Tue, 18 Sep 2001 20:50:21 +0100 From: David Taylor To: arch@FreeBSD.ORG Subject: Re: Moving UUCP to ports Message-ID: <20010918205021.B961@gattaca.yadt.co.uk> Mail-Followup-To: arch@FreeBSD.ORG References: <3BA6EB64.A4F9720C@mindspring.com> <20010917235356.A41864@xor.obsecurity.org> <3BA7A37E.93DA21B8@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BA7A37E.93DA21B8@mindspring.com>; from tlambert2@mindspring.com on Tue, Sep 18, 2001 at 12:41:50 -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, 18 Sep 2001, Terry Lambert wrote: > > To your point about it "not having been maintained": I prefer > to think of it as an "if it isn't broke, don't fix it". With the only problem being that it was broken, and included various security problems. -- David Taylor davidt@yadt.co.uk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Sep 18 13:38:28 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 6425937B40B for ; Tue, 18 Sep 2001 13:38:24 -0700 (PDT) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id NAA04779; Tue, 18 Sep 2001 13:37:38 -0700 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda04777; Tue Sep 18 13:37:34 2001 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.6/8.9.1) id f8IKbXd48327; Tue, 18 Sep 2001 13:37:33 -0700 (PDT) Received: from UNKNOWN(10.1.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdZ46110; Tue Sep 18 13:36:37 2001 Received: (from smtpd@localhost) by cwsys.cwsent.com (8.11.6/8.9.1) id f8IKa7365709; Tue, 18 Sep 2001 13:36:07 -0700 (PDT) Message-Id: <200109182036.f8IKa7365709@cwsys.cwsent.com> X-Authentication-Warning: cwsys.cwsent.com: smtpd set sender to using -f Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdD65703; Tue Sep 18 13:35:58 2001 X-Mailer: exmh version 2.5 07/13/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: Kris Kennaway Cc: Terry Lambert , "Daniel O'Connor" , arch@FreeBSD.ORG Subject: Re: Moving UUCP to ports In-reply-to: Your message of "Mon, 17 Sep 2001 23:53:57 PDT." <20010917235356.A41864@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 18 Sep 2001 13:35: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 <20010917235356.A41864@xor.obsecurity.org>, Kris Kennaway writes: > > --envbJBWh7q8WU6mo > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > > On Mon, Sep 17, 2001 at 11:36:20PM -0700, Terry Lambert wrote: > > > In any case, you have ignored the first argument: if FreeBSD > > does not maintain UUCP for FreeBSD, who will maintain UUCP > > for FreeBSD? > > Jeez, Terry..it's times like this I think you say this kind of thing > just to be difficult. > > No-one has been maintaining UUCP in FreeBSD for the past several years > (do a quick search on open PRs), but if someone suddenly wanted to > they can maintain the port just as easily (easier, since anyone in the > world can be a port maintainer, whereas you have to be a committer to > maintain code in the base system). > > I would have thought that to be obvious. A compromise has come to mind. What if we implement your change, wrapped in ifdefs. If someone does want to allow non-privileged users to specify an alternate config file, define a flag in Makfile and rebuild. Otherwise the default would be that only root could specify an alternate config file. Anyhow, it's probably best to move it to ports anyway. 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 Ministry of Management Services 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 Tue Sep 18 16:57:11 2001 Delivered-To: freebsd-arch@freebsd.org Received: from areilly.bpc-users.org (CPE-144-132-234-126.nsw.bigpond.net.au [144.132.234.126]) by hub.freebsd.org (Postfix) with SMTP id 7A33737B412 for ; Tue, 18 Sep 2001 16:57:05 -0700 (PDT) Received: (qmail 14272 invoked by uid 1000); 18 Sep 2001 23:57:04 -0000 From: "Andrew Reilly" Date: Wed, 19 Sep 2001 09:57:04 +1000 To: Terry Lambert Cc: Kris Kennaway , Daniel O'Connor , arch@FreeBSD.ORG Subject: Re: Moving UUCP to ports Message-ID: <20010919095704.A14016@gurney.reilly.home> References: <3BA6EB64.A4F9720C@mindspring.com> <20010917235356.A41864@xor.obsecurity.org> <3BA7A37E.93DA21B8@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BA7A37E.93DA21B8@mindspring.com>; from tlambert2@mindspring.com on Tue, Sep 18, 2001 at 12:41:50PM -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, Sep 18, 2001 at 12:41:50PM -0700, Terry Lambert wrote: > Except that most of the people in the world don't have an FTP > server, and the ISP links that they do have prevent them from > running a server at all -- and it is *precisely* these people > who need UUCP. Is there no possibility that the putative ports-based distribution could live on FreeBSD's FTP server without being part of the main tree? There's sourceforge too, unless that has strings attached that I haven't bothered to investigate. > To your point about it "not having been maintained": I prefer > to think of it as an "if it isn't broke, don't fix it". Isn't the issue that brokenness _has_ been identified? > Can we move on to talking about making sendmail and perl into > ports instead? Yes please. I realize that perl has a lot of support, and that's not really ever going to happen. Sendmail I can already turn off, so that doesn't worry me overly either. Ports dependancy issues and interactions with the main tree are always fun discussion topics, though... :-) -- Andrew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Sep 18 20:29:40 2001 Delivered-To: freebsd-arch@freebsd.org Received: from eumenes.hosting.pacbell.net (eumenes.hosting.pacbell.net [216.100.98.24]) by hub.freebsd.org (Postfix) with ESMTP id 88A1E37B405 for ; Tue, 18 Sep 2001 20:29:37 -0700 (PDT) Received: from c1435077a (adsl-64-172-38-74.dsl.snfc21.pacbell.net [64.172.38.74]) by eumenes.hosting.pacbell.net id XAA06057; Tue, 18 Sep 2001 23:29:35 -0400 (EDT) [ConcentricHost SMTP Relay 1.7] Message-ID: <002e01c140b9$789606b0$4a10a8c0@stcla1.sfba.home.com> Reply-To: "mike varga" From: "mike varga" To: Subject: example kqueue driver support ? Date: Tue, 18 Sep 2001 20:16:26 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002B_01C1407E.CBAD8C50" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 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 This is a multi-part message in MIME format. ------=_NextPart_000_002B_01C1407E.CBAD8C50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Does anyone have an example or documentation=20 on how to use kqueue/kevent, both driver and application? ------=_NextPart_000_002B_01C1407E.CBAD8C50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Does anyone have an example or = documentation=20
on how to use kqueue/kevent, both = driver=20 and
application?
------=_NextPart_000_002B_01C1407E.CBAD8C50-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Sep 18 20:42:16 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-64-169-104-168.dsl.lsan03.pacbell.net [64.169.104.168]) by hub.freebsd.org (Postfix) with ESMTP id 7AAF737B406 for ; Tue, 18 Sep 2001 20:42:12 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id B510566D20; Tue, 18 Sep 2001 20:42:11 -0700 (PDT) Date: Tue, 18 Sep 2001 20:42:11 -0700 From: Kris Kennaway To: Terry Lambert Cc: Kris Kennaway , Daniel O'Connor , arch@FreeBSD.ORG Subject: Re: Moving UUCP to ports Message-ID: <20010918204211.A54489@xor.obsecurity.org> References: <3BA6EB64.A4F9720C@mindspring.com> <20010917235356.A41864@xor.obsecurity.org> <3BA7A37E.93DA21B8@mindspring.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="zhXaljGHf11kAtnf" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BA7A37E.93DA21B8@mindspring.com>; from tlambert2@mindspring.com on Tue, Sep 18, 2001 at 12:41:50PM -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 --zhXaljGHf11kAtnf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 18, 2001 at 12:41:50PM -0700, Terry Lambert wrote: > Kris Kennaway wrote: > > In any case, you have ignored the first argument: if FreeBSD > > > does not maintain UUCP for FreeBSD, who will maintain UUCP > > > for FreeBSD? > >=20 > > Jeez, Terry..it's times like this I think you say this kind of thing > > just to be difficult. > >=20 > > No-one has been maintaining UUCP in FreeBSD for the past several years > > (do a quick search on open PRs), but if someone suddenly wanted to > > they can maintain the port just as easily (easier, since anyone in the > > world can be a port maintainer, whereas you have to be a committer to > > maintain code in the base system). > >=20 > > I would have thought that to be obvious. >=20 > Except that most of the people in the world don't have an FTP > server, and the ISP links that they do have prevent them from > running a server at all -- What does the ability to run an FTP server have to do with anything? Are you somehow confused and think that maintaing a port (which surely would only be one person, not every UUCP user in the world) requires self-hosting of the distfile? > and it is *precisely* these people who need UUCP. How do these people get their copy of the new version of FreeBSD? Any way I can think of allows the possibility of also obtaining a copy of the UUCP package. > To your point about it "not having been maintained": I prefer > to think of it as an "if it isn't broke, don't fix it". And if it's broke... > Can we move on to talking about making sendmail and perl into > ports instead? One thing at a time. Kris --zhXaljGHf11kAtnf 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 iD4DBQE7qBQTWry0BWjoQKURApVWAJiQYbElUJiBbTDjGWuVo98LBl3YAJ9QvwOa REzuBwPf0OTAyw9pM85tuA== =tSHH -----END PGP SIGNATURE----- --zhXaljGHf11kAtnf-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Sep 18 20:45: 6 2001 Delivered-To: freebsd-arch@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 19F0937B401 for ; Tue, 18 Sep 2001 20:45:04 -0700 (PDT) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id UAA16263; Tue, 18 Sep 2001 20:43:13 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.3/8.11.3) id f8J3hC562073; Tue, 18 Sep 2001 20:43:12 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200109190343.f8J3hC562073@arch20m.dellroad.org> Subject: Re: example kqueue driver support ? In-Reply-To: <002e01c140b9$789606b0$4a10a8c0@stcla1.sfba.home.com> "from mike varga at Sep 18, 2001 08:16:26 pm" To: mike varga Date: Tue, 18 Sep 2001 20:43:12 -0700 (PDT) Cc: freebsd-arch@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit 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 mike varga writes: > Does anyone have an example or documentation > on how to use kqueue/kevent, both driver and > application? The tail(1) program is a simple application that uses kqueue. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Sep 19 3:38:52 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.121.85]) by hub.freebsd.org (Postfix) with ESMTP id 2755037B418 for ; Wed, 19 Sep 2001 03:38:49 -0700 (PDT) Received: from mindspring.com (dialup-209.245.133.197.Dial1.SanJose1.Level3.net [209.245.133.197]) by gull.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id DAA20052; Wed, 19 Sep 2001 03:38:36 -0700 (PDT) Message-ID: <3BA875DB.8C1EA468@mindspring.com> Date: Wed, 19 Sep 2001 03:39:23 -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: Andrew Reilly Cc: Kris Kennaway , "Daniel O'Connor" , arch@FreeBSD.ORG Subject: Re: Moving UUCP to ports References: <3BA6EB64.A4F9720C@mindspring.com> <20010917235356.A41864@xor.obsecurity.org> <3BA7A37E.93DA21B8@mindspring.com> <20010919095704.A14016@gurney.reilly.home> 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 Andrew Reilly wrote: > > On Tue, Sep 18, 2001 at 12:41:50PM -0700, Terry Lambert wrote: > > Except that most of the people in the world don't have an FTP > > server, and the ISP links that they do have prevent them from > > running a server at all -- and it is *precisely* these people > > who need UUCP. > > Is there no possibility that the putative ports-based > distribution could live on FreeBSD's FTP server without being > part of the main tree? It already does, as long as you leave it alone. > There's sourceforge too, unless that has strings attached that I > haven't bothered to investigate. To be brutally blunt, sourceforge sucks. In its creation, it has this idealistic belief that open source projects can occur because someone declares an open source project, with nothing else. Even with the primary ingredient as a given, working code (something the Mozilla folks found out that you can't live without), their "infrastructure" system leaves a lot to be desired. Mostly, the cookie-cutter approach to a repository, project area, web pages, discussion groups, and so on, really failt to grasp the idea that open source projects are by their very nature individualistic, and have their own communities. The sourceforge approach is to place all of the projects in some bland "open source surburbia", where all of the houses are alike, with only the colors and minor style variations (which building plan was used for which particular house) are allowed by the restrictive covenants and local zoning laws. Sourceforege is the open source equivalent of the subdivision in the movie "Edward Scissorhands". So, IMO, moving a project to sourceforge is a quick way to kill it off. > > To your point about it "not having been maintained": I prefer > > to think of it as an "if it isn't broke, don't fix it". > > Isn't the issue that brokenness _has_ been identified? A security issue was identified, and is easily fixed, but rather than fixing it (disallowing "--config" except for group "wheel", for example), people now want to exile it to the land of the unmaintained and unmaintainable. If it's moved to ports, it will be about as maintained as the BSD code for various utilities which have had the misfortune to be replaced by GNU equivalents -- tar, diff, etc.. > > Can we move on to talking about making sendmail and perl into > > ports instead? > > Yes please. I realize that perl has a lot of support, and > that's not really ever going to happen. Sendmail I can already > turn off, so that doesn't worry me overly either. Perl belongs much less in the base system than UCP, which, for all it's faults, has a BSD license. UUCP is also very much smaller, and it's where the default terminal program for UNIX comes from, as well. > Ports dependancy issues and interactions with the main tree are > always fun discussion topics, though... :-) Annoying, you mean... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Sep 19 3:48: 9 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.121.85]) by hub.freebsd.org (Postfix) with ESMTP id D0C7437B412 for ; Wed, 19 Sep 2001 03:48:05 -0700 (PDT) Received: from mindspring.com (dialup-209.245.133.197.Dial1.SanJose1.Level3.net [209.245.133.197]) by gull.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id DAA04311; Wed, 19 Sep 2001 03:47:58 -0700 (PDT) Message-ID: <3BA8780D.F1A3A51E@mindspring.com> Date: Wed, 19 Sep 2001 03:48:45 -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: Kris Kennaway Cc: "Daniel O'Connor" , arch@FreeBSD.ORG Subject: Re: Moving UUCP to ports References: <3BA6EB64.A4F9720C@mindspring.com> <20010917235356.A41864@xor.obsecurity.org> <3BA7A37E.93DA21B8@mindspring.com> <20010918204211.A54489@xor.obsecurity.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 Kris Kennaway wrote: [ ... "but if someone suddenly wanted to they can maintain the port just as easily" ... ] > > Except that most of the people in the world don't have an FTP > > server, and the ISP links that they do have prevent them from > > running a server at all -- > > What does the ability to run an FTP server have to do with anything? > Are you somehow confused and think that maintaing a port (which surely > would only be one person, not every UUCP user in the world) requires > self-hosting of the distfile? No, it requires hosting of the project which is to take over the maintenance of UUCP, after FreeBSD throws it out into the cold like the Red Headed Step Child, for having a minor and easily fixed security flaw. > > and it is *precisely* these people who need UUCP. > > How do these people get their copy of the new version of FreeBSD? Any > way I can think of allows the possibility of also obtaining a copy of > the UUCP package. CDROM from the maintainer. Oh yeah... with FreeBSD no longer the maintainer of its own UUCP, it would be obtained from... um... er... the noplace? > > Can we move on to talking about making sendmail and perl into > > ports instead? > > One thing at a time. Good... after all FreeBSD isn't a system, it's a kernel, right? -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Sep 19 4:29:37 2001 Delivered-To: freebsd-arch@freebsd.org Received: from cip1.melaten.rwth-aachen.de (cip1.melaten.RWTH-Aachen.DE [134.130.92.100]) by hub.freebsd.org (Postfix) with ESMTP id 3982237B412 for ; Wed, 19 Sep 2001 04:29:34 -0700 (PDT) Received: from cip12.melaten.rwth-aachen.de (cip12.melaten.RWTH-Aachen.DE [134.130.92.12]) by cip1.melaten.rwth-aachen.de (8.11.5/8.11.1) with ESMTP id f8JBebU44638; Wed, 19 Sep 2001 13:40:37 +0200 (CEST) (envelope-from tg@melaten.rwth-aachen.de) Received: (from tg@localhost) by cip12.melaten.rwth-aachen.de (8.11.3/8.9.3) id f8JBUnv05386; Wed, 19 Sep 2001 13:30:49 +0200 (CEST) (envelope-from tg@melaten.rwth-aachen.de) X-Authentication-Warning: cip12.melaten.rwth-aachen.de: tg set sender to tg@melaten.rwth-aachen.de using -f To: "mike varga" Cc: Subject: Re: example kqueue driver support ? References: <002e01c140b9$789606b0$4a10a8c0@stcla1.sfba.home.com> From: Thomas Gellekum In-Reply-To: "mike varga"'s message of "Tue, 18 Sep 2001 20:16:26 -0700" Date: 19 Sep 2001 13:30:49 +0200 Message-ID: Lines: 11 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Channel Islands) 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 "mike varga" writes: > 1. (*) text/plain ( ) text/html > > Does anyone have an example or documentation > on how to use kqueue/kevent, both driver and > application? tg To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Sep 19 8:36:37 2001 Delivered-To: freebsd-arch@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 3A50937B419 for ; Wed, 19 Sep 2001 08:35:58 -0700 (PDT) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f8JFZqP10569; Wed, 19 Sep 2001 18:35:52 +0300 (EEST) (envelope-from ru) Date: Wed, 19 Sep 2001 18:35:52 +0300 From: Ruslan Ermilov To: arch@FreeBSD.ORG Cc: freebsd-standards@bostonradio.org Subject: Re: Fixing chown(8) and friends to handle symlinks properly Message-ID: <20010919183552.G884@sunbay.com> References: <20010913202742.C2458@sunbay.com> <20010917191657.A19072@sunbay.com> <200109172143.f8HLhkU41334@khavrinen.lcs.mit.edu> <20010913202742.C2458@sunbay.com> <20010914060800.A27869@nagual.pp.ru> <20010918190222.F4648@sunbay.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="2B/JsCI69OhZNC5r" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010918190222.F4648@sunbay.com>; from ru@FreeBSD.org on Tue, Sep 18, 2001 at 07:02:22PM +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 --2B/JsCI69OhZNC5r Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Sep 18, 2001 at 07:02:22PM +0300, Ruslan Ermilov wrote: > Hi, > > After re-reading the POSIX.1-200x draft and the symlink(7) manpage, > I have developed another patch (the winner!) that implements what > I think is required by POSIX, while still preserving the basic > ideas of symlink(7). > Here's a similar patch for chmod(1), for those still interested. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age --2B/JsCI69OhZNC5r Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p Index: chmod.c =================================================================== RCS file: /home/ncvs/src/bin/chmod/chmod.c,v retrieving revision 1.22 diff -u -p -u -p -r1.22 chmod.c --- chmod.c 2001/05/31 11:47:19 1.22 +++ chmod.c 2001/09/19 15:37:29 @@ -32,7 +32,7 @@ */ #ifndef lint -static char const copyright[] = +static const char copyright[] = "@(#) Copyright (c) 1989, 1993, 1994\n\ The Regents of the University of California. All rights reserved.\n"; #endif /* not lint */ @@ -57,8 +57,7 @@ static const char rcsid[] = #include #include -int main __P((int, char *[])); -void usage __P((void)); +void usage __P((void)); int main(argc, argv) @@ -70,27 +69,25 @@ main(argc, argv) mode_t *set; long val; int oct, omode; - int Hflag, Lflag, Pflag, Rflag, ch, fflag, fts_options, hflag, rval; - int vflag; + int Hflag, Lflag, Rflag, fflag, hflag, vflag; + int ch, rval; char *ep, *mode; int newmode; + struct stat sb; int (*change_mode) __P((const char *, mode_t)); - set = NULL; - omode = 0; - Hflag = Lflag = Pflag = Rflag = fflag = hflag = vflag = 0; + Hflag = Lflag = Rflag = fflag = hflag = vflag = 0; while ((ch = getopt(argc, argv, "HLPRXfghorstuvwx")) != -1) switch (ch) { case 'H': Hflag = 1; - Lflag = Pflag = 0; + Lflag = 0; break; case 'L': Lflag = 1; - Hflag = Pflag = 0; + Hflag = 0; break; case 'P': - Pflag = 1; Hflag = Lflag = 0; break; case 'R': @@ -100,14 +97,6 @@ main(argc, argv) fflag = 1; break; case 'h': - /* - * In System V (and probably POSIX.2) the -h option - * causes chmod to change the mode of the symbolic - * link. 4.4BSD's symbolic links didn't have modes, - * so it was an undocumented noop. In FreeBSD 3.0, - * lchmod(2) is introduced and this option does real - * work. - */ hflag = 1; break; /* @@ -136,25 +125,6 @@ done: argv += optind; if (argc < 2) usage(); - if (Rflag) { - fts_options = FTS_PHYSICAL; - if (hflag) - errx(1, - "the -R and -h options may not be specified together."); - if (Hflag) - fts_options |= FTS_COMFOLLOW; - if (Lflag) { - fts_options &= ~FTS_PHYSICAL; - fts_options |= FTS_LOGICAL; - } - } else - fts_options = hflag ? FTS_PHYSICAL : FTS_LOGICAL; - - if (hflag) - change_mode = lchmod; - else - change_mode = chmod; - mode = *argv; if (*mode >= '0' && *mode <= '7') { errno = 0; @@ -173,15 +143,17 @@ done: argv += optind; oct = 0; } - if ((ftsp = fts_open(++argv, fts_options, 0)) == NULL) + if ((ftsp = fts_open(++argv, FTS_PHYSICAL, 0)) == NULL) err(1, NULL); + for (rval = 0; (p = fts_read(ftsp)) != NULL;) { + change_mode = chmod; switch (p->fts_info) { case FTS_D: /* Change it at FTS_DP. */ if (!Rflag) fts_set(ftsp, p, FTS_SKIP); continue; - case FTS_DNR: /* Warn, chmod, continue. */ + case FTS_DNR: /* Warn, chmod. */ warnx("%s: %s", p->fts_path, strerror(p->fts_errno)); rval = 1; break; @@ -190,41 +162,80 @@ done: argv += optind; warnx("%s: %s", p->fts_path, strerror(p->fts_errno)); rval = 1; continue; - case FTS_SL: /* Ignore. */ - case FTS_SLNONE: + case FTS_SL: /* - * The only symlinks that end up here are ones that - * don't point to anything and ones that we found - * doing a physical walk. + * If not traversing a file tree and -h was not + * specified, follow symlinks. This is done to + * reinitialize the p->fts_statp with stat(2). + * + * If traversing a file tree, check if we were + * asked to follow symlinks to directories. */ - if (!hflag) + if ((!Rflag && !hflag) || + (Rflag && (Lflag || (Hflag && p->fts_level == 0)) && + stat(p->fts_accpath, &sb) == 0 && + S_ISDIR(sb.st_mode))) { + fts_set(ftsp, p, FTS_FOLLOW); continue; - /* else */ - /* FALLTHROUGH */ + } + if (hflag || Rflag) + change_mode = lchmod; + break; + case FTS_SLNONE: /* Ignore. */ + /* + * The only symlinks that end up here are ones that + * don't point to anything. Note that since we are + * doing a physical walk, we never reach here unless + * we asked to follow explicitly. + * + * When following a symlink to a directory above, + * the directory may be deleted (or renamed) in a + * small window between the calls to fts_set() and + * fts_read(), causing FTS_SLNONE to be returned. + */ + continue; default: break; } newmode = oct ? omode : getmode(set, p->fts_statp->st_mode); +#define DEBUG +#ifdef DEBUG + if ((change_mode == chmod ? stat : lstat)(p->fts_accpath, &sb) == -1) + abort(); + if (sb.st_ino != p->fts_statp->st_ino) + abort(); +#else if ((newmode & ALLPERMS) == (p->fts_statp->st_mode & ALLPERMS)) continue; - if ((*change_mode)(p->fts_accpath, newmode) && !fflag) { - warn("%s", p->fts_path); - rval = 1; +#endif + if ((*change_mode)(p->fts_accpath, newmode) == -1) { + if (!fflag) { + warn("%s", p->fts_path); + rval = 1; + } } else { if (vflag) - (void)printf("%s\n", p->fts_accpath); +#ifdef DEBUG + printf("%s %s\n", + (change_mode == chmod) ? "chmod" : "lchmod", + p->fts_path); +#else + printf("%s\n", p->fts_path); +#endif } } if (errno) err(1, "fts_read"); - free(set); + if (!oct) + free(set); exit(rval); } void usage() { + (void)fprintf(stderr, - "usage: chmod [-fhv] [-R [-H | -L | -P]] mode file ...\n"); + "usage: chmod [-fv] [-h | -R [-H | -L | -P]] mode file ...\n"); exit(1); } Index: chmod.1 =================================================================== RCS file: /home/ncvs/src/bin/chmod/chmod.1,v retrieving revision 1.27 diff -u -p -u -p -r1.27 chmod.1 --- chmod.1 2001/08/15 09:09:34 1.27 +++ chmod.1 2001/09/19 15:37:30 @@ -35,7 +35,7 @@ .\" @(#)chmod.1 8.4 (Berkeley) 3/31/94 .\" $FreeBSD: src/bin/chmod/chmod.1,v 1.27 2001/08/15 09:09:34 ru Exp $ .\" -.Dd March 31, 1994 +.Dd September 19, 2001 .Dt CHMOD 1 .Os .Sh NAME @@ -43,55 +43,84 @@ .Nd change file modes .Sh SYNOPSIS .Nm -.Op Fl fhv -.Op Fl R Op Fl H | L | P +.Op Fl fv +.Op Fl h | R Op Fl H | L | P .Ar mode .Ar .Sh DESCRIPTION The .Nm -utility modifies the file mode bits of the listed files -as specified by the -.Ar mode -operand. +utility changes the file mode bits of the specified files. .Pp -The options are as follows: -.Bl -tag -width Ds +The following options are available: +.Bl -tag -width indent .It Fl H If the .Fl R -option is specified, symbolic links on the command line are followed. -(Symbolic links encountered in the tree traversal are not followed by -default.) +option is specified +and a symbolic link +referencing a file of type directory +is specified on the command line, +change the mode +of the directory referenced by the link +and all files in the subtree below it. +Otherwise, +change the mode +of the link itself +rather than the file that the link points to. .It Fl L If the .Fl R -option is specified, all symbolic links are followed. +option is specified +and a symbolic link +referencing a file of type directory +is specified on the command line +or encountered during the tree traversal, +change the mode +of the directory referenced by the link +and all files in the subtree below it. +Otherwise, +change the mode +of the link itself +rather than the file that the link points to. .It Fl P If the .Fl R -option is specified, no symbolic links are followed. -This is the default. +option is specified +and a symbolic link +is specified on the command line +or encountered during the tree traversal, +change the mode +of the link itself +rather than the file that the link points to. .It Fl R -Change the modes of the file hierarchies rooted in the files -instead of just the files themselves. +If +.Ar file +argument designates a directory, +change the mode +of the directory +and all files in the subtree below it. .It Fl f -Do not display a diagnostic message if -.Nm -could not modify the mode for -.Va file . +Do not report any failure to +change the mode +of the file, +nor modify the exit status to reflect such failures. .It Fl h -If the file is a symbolic link, change the mode of the link itself +If the +.Fl R +option is not specified +and +.Ar file +argument is a symbolic link, +change the mode +of the link itself rather than the file that the link points to. .It Fl v -Cause -.Nm -to be verbose, showing files as the mode is modified. +Be verbose, showing files as the mode is modified. .El .Pp The -.Fl H , -.Fl L +.Fl H , L and .Fl P options are ignored unless the @@ -99,37 +128,45 @@ options are ignored unless the option is specified. In addition, these options override each other and the command's actions are determined by the last one specified. +If none are specified, the +default is +.Fl P . .Pp Only the owner of a file or the super-user is permitted to change the mode of a file. .Sh DIAGNOSTICS .Ex -std .Sh MODES -Modes may be absolute or symbolic. +The +.Ar mode +argument may be either absolute or symbolic. An absolute mode is an octal number constructed from the sum of one or more of the following values: .Pp -.Bl -tag -width 6n -compact -offset indent +.Bl -tag -width indent -compact -offset indent .It Li 4000 -(the set-user-ID-on-execution bit) Executable files with this bit set -will run with effective uid set to the uid of the file owner. -Directories with the set-user-id bit set will force all files and +(the set-user-ID-on-execution bit) +Executable files with this bit set +will run with effective user ID set to the user ID of the file owner. +Directories with the set-user-ID bit set will force all files and sub-directories created in them to be owned by the directory owner -and not by the uid of the creating process, if the underlying file +and not by the user ID of the creating process, if the underlying file system supports this feature: see .Xr chmod 2 and the -.Ar suiddir +.Cm suiddir option to .Xr mount 8 . .It Li 2000 -(the set-group-ID-on-execution bit) Executable files with this bit set -will run with effective gid set to the gid of the file owner. +(the set-group-ID-on-execution bit) +Executable files with this bit set +will run with effective group ID set to the group ID of the file owner. .It Li 1000 (the sticky bit) When set on a directory, unprivileged users can delete and rename only those files in the directory that are owned by them, regardless of -the permissions on the directory. Under +the permissions on the directory. +Under .Fx , the sticky bit is ignored for executable files and may only be set for directories (see @@ -139,27 +176,30 @@ Allow read by owner. .It Li 0200 Allow write by owner. .It Li 0100 -For files, allow execution by owner. For directories, allow the owner to +For files, allow execution by owner. +For directories, allow the owner to search in the directory. .It Li 0040 Allow read by group members. .It Li 0020 Allow write by group members. .It Li 0010 -For files, allow execution by group members. For directories, allow -group members to search in the directory. +For files, allow execution by group members. +For directories, allow group members to +search in the directory. .It Li 0004 Allow read by others. .It Li 0002 Allow write by others. .It Li 0001 -For files, allow execution by others. For directories allow others to +For files, allow execution by others. +For directories allow others to search in the directory. .El .Pp For example, the absolute mode that permits read, write and execute by the owner, read and execute by group members, read and execute by -others, and no set-uid or set-gid behaviour is 755 +others, and no set-user-ID or set-group-ID behaviour is 755 (400+200+100+040+010+004+001). .Pp The symbolic mode is described by the following grammar: @@ -174,40 +214,52 @@ perm ::= r | s | t | w | x | X | .Pp The .Ar who -symbols ``u'', ``g'', and ``o'' specify the user, group, and other parts +symbols +.Dq Li u , +.Dq Li g , +and +.Dq Li o +specify the user, group, and other parts of the mode bits, respectively. The .Ar who -symbol ``a'' is equivalent to ``ugo''. +symbol +.Dq Li a +is equivalent to +.Dq Li ugo . .Pp The .Ar perm symbols represent the portions of the mode bits as follows: .Pp -.Bl -tag -width Ds -compact -offset indent -.It r +.Bl -tag -width indent -compact -offset indent +.It Li r The read bits. -.It s +.It Li s The set-user-ID-on-execution and set-group-ID-on-execution bits. -.It t +.It Li t The sticky bit. -.It w +.It Li w The write bits. -.It x +.It Li x The execute/search bits. -.It X +.It Li X The execute/search bits if the file is a directory or any of the execute/search bits are set in the original (unmodified) mode. Operations with the .Ar perm -symbol ``X'' are only meaningful in conjunction with the +symbol +.Dq Li X +are only meaningful in conjunction with the .Ar op -symbol ``+'', and are ignored in all other cases. -.It u +symbol +.Dq Li + , +and are ignored in all other cases. +.It Li u The user permission bits in the mode of the original file. -.It g +.It Li g The group permission bits in the mode of the original file. -.It o +.It Li o The other permission bits in the mode of the original file. .El .Pp @@ -215,10 +267,12 @@ The .Ar op symbols represent the operation performed, as follows: .Bl -tag -width 4n -.It + +.It Li + If no value is supplied for .Ar perm , -the ``+'' operation has no effect. +the +.Dq Li + +operation has no effect. If no value is supplied for .Ar who , each permission bit specified in @@ -230,10 +284,12 @@ Otherwise, the mode bits represented by and .Ar perm values are set. -.It \&\- +.It Li \- If no value is supplied for .Ar perm , -the ``\-'' operation has no effect. +the +.Dq Li \- +operation has no effect. If no value is supplied for .Ar who , each permission bit specified in @@ -245,10 +301,12 @@ Otherwise, the mode bits represented by and .Ar perm values are cleared. -.It = +.It Li = The mode bits specified by the .Ar who -value are cleared, or, if no who value is specified, the owner, group +value are cleared, or, if no +.Ar who +value is specified, the owner, group and other mode bits are cleared. Then, if no value is supplied for .Ar who , @@ -270,11 +328,16 @@ bits, and each operation is applied to t order specified. .Pp Operations upon the other permissions only (specified by the symbol -``o'' by itself), in combination with the +.Dq Li o +by itself), in combination with the .Ar perm -symbols ``s'' or ``t'', are ignored. +symbols +.Dq Li s +or +.Dq Li t , +are ignored. .Sh EXAMPLES -.Bl -tag -width "u=rwx,go=u-w" -compact +.Bl -tag -width ".Li u=rwx,go=u-w" -compact .It Li 644 make a file readable by anyone and writable by the owner only. .Pp @@ -301,10 +364,13 @@ clear all mode bits for group and others set the group bits equal to the user bits, but clear the group write bit. .El .Sh BUGS -There's no +There is no .Ar perm option for the naughty bits. .Sh COMPATIBILITY +On previous versions of this system, symbolic links did not have +modes. +.Pp The .Fl v option is non-standard and its use in scripts is not recommended. @@ -328,7 +394,7 @@ utility is expected to be compatible with the exception of the .Ar perm symbol -.Dq t +.Dq Li t which is not included in that standard. .Sh HISTORY A --2B/JsCI69OhZNC5r-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Sep 19 10: 9: 4 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail152.nifty.com (mail152.nifty.com [202.248.37.145]) by hub.freebsd.org (Postfix) with ESMTP id B6B9537B41D for ; Wed, 19 Sep 2001 10:08:59 -0700 (PDT) Received: from chrysanthe.oikumene.gcd.org by mail152.nifty.com (8.11.4+3.4W/3.7W-10/13/99) with SMTP id f8JH8wT15893 for ; Thu, 20 Sep 2001 02:08:58 +0900 Received: (qmail 3862 invoked from network); 19 Sep 2001 17:08:57 -0000 Received: from chrysanthe.oikumene.gcd.org (HELO localhost) (@192.168.0.12) by chrysanthe.oikumene.gcd.org with SMTP; 19 Sep 2001 17:08:57 -0000 To: freebsd-arch@FreeBSD.ORG Subject: Re: Moving UUCP to ports From: Hiroo ONO (=?iso-2022-jp?B?GyRCPi5MbjQyQDgbKEI=?=) In-Reply-To: <20010917194519.A39672@xor.obsecurity.org> References: <20010917194519.A39672@xor.obsecurity.org> X-Mailer: Mew version 1.94.1 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010920020856N.hiroo@oikumene.gcd.org> Date: Thu, 20 Sep 2001 02:08:56 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 28 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 Hello. As one of uucp users, who are supposed to be in the threat of extinction :-), I do not oppose to removing uucp from the base system as long as it remains in the port tree. > That's apparently widely used functionality. My original proposed > patch restricted --config/-I to root, but ache told me lots of people > need that to work. How about making this feature selectable at compile time, as Cy Shubert suggested. If you leave uucp in the base system, the default should be the secure version, but if it is in the port tree, setting the default to current insecure version and just prompting "it has a security hole." and showing how to make the secure version may be sufficient. I think it may be a demerit to uucp user who will have to do a little more operation at install time, but it has the merit that it contents uucp users who still use --config/-I option other than root, and uucp users who do not use this option and want a secure one, and at last non uucp users who do not want security hole in the system they use (except some people who insist on having uucp in the base system if you decide to move the uucp to port :-p). If you remove uucp from the base system and move it to ports, I want to be informed (by UPDATING or/and RELNOTES, etc.), but it is not important whether it is in the base system or in the port tree. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Sep 19 10:40:27 2001 Delivered-To: freebsd-arch@freebsd.org Received: from atg.aciworldwide.com (h139-142-180-4.gtcust.grouptelecom.net [139.142.180.4]) by hub.freebsd.org (Postfix) with ESMTP id 5E4A837B405 for ; Wed, 19 Sep 2001 10:40:24 -0700 (PDT) Received: from atg.aciworldwide.com (localhost [127.0.0.1]) by atg.aciworldwide.com (8.12.0/8.12.0) with ESMTP id f8JHeNaX014438; Wed, 19 Sep 2001 11:40:23 -0600 (MDT) Received: (from uucp@localhost) by atg.aciworldwide.com (8.12.0/8.12.0.Beta14) with UUCP id f8JHeNwB014437; Wed, 19 Sep 2001 11:40:23 -0600 (MDT) Received: from localhost (localhost [127.0.0.1]) by orthanc.ab.ca (8.12.0/8.12.0) with ESMTP id f8JHbJa5015949; Wed, 19 Sep 2001 11:37:19 -0600 (MDT) Message-Id: <200109191737.f8JHbJa5015949@orthanc.ab.ca> From: Lyndon Nerenberg Organization: The Frobozz Magic Homing Pigeon Company To: Hiroo ONO (=?iso-2022-jp?B?GyRCPi5MbjQyQDgbKEI=?=) Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Moving UUCP to ports In-reply-to: Your message of "Thu, 20 Sep 2001 02:08:56 +0900." <20010920020856N.hiroo@oikumene.gcd.org> Date: Wed, 19 Sep 2001 11:37:19 -0600 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 >>>>> ">" == =?iso-2022-jp?B?GyRCPi5MbjQyQDgbKEI=?= writes: >> How about making this feature selectable at compile time, as Cy >> Shubert suggested. If you leave uucp in the base system, the >> default should be the secure version, but if it is in the port >> tree, setting the default to current insecure version and just >> prompting "it has a security hole." and showing how to make the >> secure version may be sufficient. Move it to ports, but don't fix the security problem? That's absurd. (No, that's stupid.) But, one would think that just fixing the bug would suffice ... --lyndon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Sep 19 16:16:44 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by hub.freebsd.org (Postfix) with ESMTP id 7E8CD37B41A; Wed, 19 Sep 2001 16:16:39 -0700 (PDT) Received: from laptop.baldwin.cx ([147.11.46.201]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id QAA02533; Wed, 19 Sep 2001 16:16:38 -0700 (PDT) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Wed, 19 Sep 2001 16:16:25 -0700 (PDT) From: John Baldwin To: julian@FreeBSD.org, arch@FreeBSD.org Subject: sigsuspend() and KSE 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 From the KSE commit the following was added regarding sigsuspend: /* * Suspend process until signal, providing mask to be set * in the meantime. Note nonstandard calling convention: * libc stub passes mask, not pointer, to save a copyin. ***** XXXKSE this doesn't make sense under KSE. ***** Do we suspend the thread or all threads in the process? ***** How do we suspend threads running NOW on another processor? */ Here's my opinion: sigsuspend() just suspends the current thread. When a signal is posted, it wakes up all threads blocked on sigsuspend whose mask matches that signal. I can see it still making sense, but perhaps being of limited usefulness in a threaded program. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.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 Sep 19 16:46:47 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 867C137B409; Wed, 19 Sep 2001 16:46:44 -0700 (PDT) Received: from nomad.yogotech.com (nomad.yogotech.com [206.127.123.131]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id RAA19180; Wed, 19 Sep 2001 17:46:43 -0600 (MDT) (envelope-from nate@nomad.yogotech.com) Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id RAA00967; Wed, 19 Sep 2001 17:46:42 -0600 (MDT) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15273.11874.366229.387658@nomad.yogotech.com> Date: Wed, 19 Sep 2001 17:46:42 -0600 To: John Baldwin Cc: julian@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: sigsuspend() and KSE In-Reply-To: References: X-Mailer: VM 6.95 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) 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 > /* > * Suspend process until signal, providing mask to be set > * in the meantime. Note nonstandard calling convention: > * libc stub passes mask, not pointer, to save a copyin. > ***** XXXKSE this doesn't make sense under KSE. > ***** Do we suspend the thread or all threads in the process? > ***** How do we suspend threads running NOW on another processor? > */ > > Here's my opinion: > > sigsuspend() just suspends the current thread. When a signal is posted, it > wakes up all threads blocked on sigsuspend whose mask matches that signal. I > can see it still making sense, but perhaps being of limited usefulness in a > threaded program. What has limited usefulness? Being able to suspend all threads, or waking up all threads? Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Sep 19 16:56: 2 2001 Delivered-To: freebsd-arch@freebsd.org Received: from antipater.hosting.pacbell.net (antipater.hosting.pacbell.net [216.100.99.13]) by hub.freebsd.org (Postfix) with ESMTP id 062A437B417 for ; Wed, 19 Sep 2001 16:55:54 -0700 (PDT) Received: from c1435077a (adsl-64-172-38-74.dsl.snfc21.pacbell.net [64.172.38.74]) by antipater.hosting.pacbell.net id TAA04339; Wed, 19 Sep 2001 19:55:50 -0400 (EDT) [ConcentricHost SMTP Relay 1.7] Message-ID: <00dd01c14164$c54b3560$4a10a8c0@stcla1.sfba.home.com> Reply-To: "mike varga" From: "mike varga" To: Subject: kevent hangs Date: Wed, 19 Sep 2001 16:42:31 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00DA_01C1412A.137AA080" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 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 This is a multi-part message in MIME format. ------=_NextPart_000_00DA_01C1412A.137AA080 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I opted to break the changelist=20 and eventlist into 2 seperate calls. When I make the first call to add the=20 changelist, the call to kevent hangs. Does anyone know what is wrong? /*****APPLICATION CODE****/ { struct timespec to; int n; struct kevent ke; int data, udata; PKP_kq_handle =3D kqueue(); =20 to.tv_sec =3D 2; /* seconds */ to.tv_nsec =3D 10000; /* and microseconds */ EV_SET(&ke, PKP_driver_handle, EVFILT_READ, EV_ADD, 0,NULL,NULL); =20 /******* HANGS ON THIS CALL *********/ if (kevent(PKP_kq_handle,&ke,1,NULL,0,&to) <=3D 0) { close(PKP_kq_handle); PKP_kq_handle =3D -1; return errno; } else cond_code =3D 0; =20 /******DRIVER CODE*****/ static struct filterops cavium_filtops =3D { 1, NULL, kqdetach, kqfilter }; static int kqfilter(struct knote* kn, long hint) { cavium_softc* sc; DEBUG_PRINT(("CAVIUM kqfilter: 1 called\n")); =20 sc =3D (cavium_softc*)kn->kn_hook; return 1; } static void kqdetach(struct knote* kn) { cavium_softc* sc; =20 DEBUG_PRINT(("CAVIUM kqdetach: 1 called\n")); sc =3D (cavium_softc*)kn->kn_hook; =20 LOCK(sc->cache_lock,sc->cache_slock); SLIST_REMOVE(&sc->klist,kn,knote,kn_selnext); UNLOCK(sc->cache_lock,sc->cache_slock); } int cavium_kqueue(dev_t dev, struct knote* kn) { int unit; cavium_softc* sc; =20 DEBUG_PRINT(("CAVIUM cavium_kqfilter: 1 called\n")); =20 unit =3D UNIT(dev); if (!(sc=3DGET_SOFTC(unit))) { DEBUG_PRINT(("CAVIUM cavium_open: failed\n")); return 1; } switch(kn->kn_filter) { case EVFILT_READ: kn->kn_fop =3D &cavium_filtops; break; default: return 1; } =20 DEBUG_PRINT(("CAVIUM cavium_kqfilter: 2 called\n")); =20 kn->kn_hook =3D (caddr_t)sc;=20 LOCK(sc->cache_lock,sc->cache_slock); SLIST_INSERT_HEAD(&sc->klist,kn,kn_selnext); UNLOCK(sc->cache_lock,sc->cache_slock); =20 DEBUG_PRINT(("CAVIUM cavium_kqfilter: 3 called\n")); return 0; } ------=_NextPart_000_00DA_01C1412A.137AA080 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I opted to break the=20 changelist
and eventlist into 2=20 seperate calls.
 
When I make the first call to add the =
changelist, the call to kevent = hangs.
 
Does anyone know what is wrong?
 
/*****APPLICATION CODE****/
 {
 struct timespec to;
 int = n;
 struct kevent=20 ke;
 int data, udata;

  PKP_kq_handle =3D=20 kqueue();
  
  to.tv_sec =3D=20 2;         /* seconds=20 */
         to.tv_nsec =3D=20 10000;        /* and microseconds = */
 
  EV_SET(&ke, PKP_driver_handle, EVFILT_READ,=20 EV_ADD,
   0,NULL,NULL);
 
/******* HANGS ON THIS CALL *********/
  if=20 (kevent(PKP_kq_handle,&ke,1,NULL,0,&to) <=3D=20 0)
  {
   close(PKP_kq_handle);
 &= nbsp; PKP_kq_handle=20 =3D -1;
   return=20 errno;
  }
  else
   cond_cod= e =3D=20 0;
 
 
 
 
 
/******DRIVER CODE*****/
 
static struct filterops cavium_filtops =3D=20 {
 1,
 NULL,
 kqdetach,
 kqfilter
};
 
static int kqfilter(struct knote* kn, long=20 hint)
{
 cavium_softc* sc;
 DEBUG_PRINT(("CAVIUM = kqfilter: 1=20 called\n"));
 
 sc =3D = (cavium_softc*)kn->kn_hook;
 
 return 1;
}
 
static void kqdetach(struct knote* kn)
{
 cavium_softc*=20 sc;
 
 DEBUG_PRINT(("CAVIUM kqdetach: 1 = called\n"));
 
 sc =3D=20 (cavium_softc*)kn->kn_hook;
 
 LOCK(sc->cache_lock,= sc->cache_slock);
 SLIST_REMOVE(&sc->klist,kn,knote,kn_= selnext);
 UNLOCK(sc->cache_lock,sc->cache_slock);
}
 
int cavium_kqueue(dev_t dev, struct knote* kn)
{
 int=20 unit;
 cavium_softc* sc;
 
 DEBUG_PRINT(("CAVIUM = cavium_kqfilter: 1 called\n"));
 
 unit =3D = UNIT(dev);
 
 if=20 (!(sc=3DGET_SOFTC(unit)))
 {
  DEBUG_PRINT(("CAVIUM = cavium_open: failed\n"));
  return 1;
 }
 
 switch(kn->kn_filter)
 {
  case=20 EVFILT_READ:
   kn->kn_fop =3D=20 &cavium_filtops;
   break;
  default:<= BR>   return=20 1;
 }
 
 DEBUG_PRINT(("CAVIUM cavium_kqfilter: 2 = called\n"));
 
 kn->kn_hook =3D = (caddr_t)sc; 
 
 LOCK(sc->cache_lock,sc->cache_slock);
 SLIST_INS= ERT_HEAD(&sc->klist,kn,kn_selnext);
 UNLOCK(sc->cache_l= ock,sc->cache_slock);
 
 DEBUG_PRINT(("CAVIUM=20 cavium_kqfilter: 3 called\n"));
 return=20 0;
}
------=_NextPart_000_00DA_01C1412A.137AA080-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Sep 19 17:11: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 32D2C37B40B; Wed, 19 Sep 2001 17:11:33 -0700 (PDT) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id UAA19586; Wed, 19 Sep 2001 20:10:37 -0400 (EDT) Date: Wed, 19 Sep 2001 20:10:37 -0400 (EDT) From: Daniel Eischen To: John Baldwin Cc: julian@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: sigsuspend() and KSE 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 Wed, 19 Sep 2001, John Baldwin wrote: > >From the KSE commit the following was added regarding sigsuspend: > > /* > * Suspend process until signal, providing mask to be set > * in the meantime. Note nonstandard calling convention: > * libc stub passes mask, not pointer, to save a copyin. > ***** XXXKSE this doesn't make sense under KSE. > ***** Do we suspend the thread or all threads in the process? > ***** How do we suspend threads running NOW on another processor? > */ > > Here's my opinion: > > sigsuspend() just suspends the current thread. When a signal is posted, it > wakes up all threads blocked on sigsuspend whose mask matches that signal. I > can see it still making sense, but perhaps being of limited usefulness in a > threaded program. Right. sigsuspend should only block the calling thread and result into an upcall into the threads library. This really shouldn't be any different than a thread blocking on I/O. Since signals are sent to the UTS via an upcall, the UTS can direct it to the correct thread (waking up the previously sigsuspend'd thread if necessary). Threads in sigwait have preference over sigsuspend. And a signal posted only wakes up at most 1 thread waiting in sigsuspend (if there are multiple threads waiting for the same signal, only one of them gets woken -- or POSIX says that is undefined, I forget which). -- 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 Sep 19 18:13:39 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 C658737B419; Wed, 19 Sep 2001 18:13:32 -0700 (PDT) Received: from elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id SAA28916; Wed, 19 Sep 2001 18:50:21 -0700 (PDT) Message-ID: <3BA9406D.2BD9DFDF@elischer.org> Date: Wed, 19 Sep 2001 18:03:41 -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: John Baldwin Cc: julian@FreeBSD.org, arch@freebsd.org Subject: Re: cvs commit: src/sys/kern kern_mutex.c 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 John Baldwin wrote: > > On 19-Sep-01 John Baldwin wrote: > > jhb 2001/09/19 15:52:59 PDT > > > > Modified files: > > sys/kern kern_mutex.c > > Log: > > Fix a bug in propagate priority: the kse group pointer wasn't being > > updated in the loop so the new thread always seemd to have the same > > priority as the original thread and no actual priorities were changed. > > As a sort of follow-up, Julian, can you explain why the oncpu == NOCPU test to > see if a thread is currently running (i.e., physically executing thus it's not > on a runqueue and there's nothing we can do to make it run any sooner) is > insufficient per new comments in the code? if (td->td_kse && (td->td_kse->ke_oncpu != NOCPU)) { The above test does not say that the thread is running, only that the KSE is running. Which thread is running needs to be found out from td->td_kse->ke_thread. In the 1:1 case this is enough but when we add code to schedule threads onto KSEs then the test must be expanded if we really want to know whether a thread is running.. It is of course possible that what thread is running is not so important as whether the kse is running. What we need to decide is exactly what happens with proiority chages that are given to a thread.. does the KSE ket itfo rthe entire tick? for just the time that thread (syscall) is running? priority scope is something we have not really discussed yet. > > -- > > John Baldwin -- http://www.FreeBSD.org/~jhb/ > PGP Key: http://www.baldwin.cx/~john/pgpkey.asc > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ -- +------------------------------------+ ______ _ __ | __--_|\ 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 Wed Sep 19 18:33:32 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 B0E3237B419; Wed, 19 Sep 2001 18:33:28 -0700 (PDT) Received: from elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id TAA29023; Wed, 19 Sep 2001 19:19:10 -0700 (PDT) Message-ID: <3BA9472D.9141CE0A@elischer.org> Date: Wed, 19 Sep 2001 18:32: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: John Baldwin Cc: julian@FreeBSD.org, arch@FreeBSD.org Subject: Re: sigsuspend() and KSE 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 John Baldwin wrote: > > >From the KSE commit the following was added regarding sigsuspend: > > /* > * Suspend process until signal, providing mask to be set > * in the meantime. Note nonstandard calling convention: > * libc stub passes mask, not pointer, to save a copyin. > ***** XXXKSE this doesn't make sense under KSE. > ***** Do we suspend the thread or all threads in the process? > ***** How do we suspend threads running NOW on another processor? > */ > > Here's my opinion: > > sigsuspend() just suspends the current thread. When a signal is posted, it > wakes up all threads blocked on sigsuspend whose mask matches that signal. I > can see it still making sense, but perhaps being of limited usefulness in a > threaded program. > > -- > > John Baldwin -- http://www.FreeBSD.org/~jhb/ > PGP Key: http://www.baldwin.cx/~john/pgpkey.asc > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ oops ignore previous mail... got sigsuspend mixed up in my mind with SIGTSTOP :-/ -- +------------------------------------+ ______ _ __ | __--_|\ 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 Wed Sep 19 18:33:46 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 7886437B420; Wed, 19 Sep 2001 18:33:39 -0700 (PDT) Received: from elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id TAA29014; Wed, 19 Sep 2001 19:13:04 -0700 (PDT) Message-ID: <3BA945C0.E4738800@elischer.org> Date: Wed, 19 Sep 2001 18:26:24 -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: Nate Williams Cc: John Baldwin , julian@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: sigsuspend() and KSE References: <15273.11874.366229.387658@nomad.yogotech.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 Nate Williams wrote: > > > /* > > * Suspend process until signal, providing mask to be set > > * in the meantime. Note nonstandard calling convention: > > * libc stub passes mask, not pointer, to save a copyin. > > ***** XXXKSE this doesn't make sense under KSE. > > ***** Do we suspend the thread or all threads in the process? > > ***** How do we suspend threads running NOW on another processor? > > */ > > > > Here's my opinion: > > > > sigsuspend() just suspends the current thread. When a signal is posted, it > > wakes up all threads blocked on sigsuspend whose mask matches that signal. I > > can see it still making sense, but perhaps being of limited usefulness in a > > threaded program. > > What has limited usefulness? Being able to suspend all threads, or > waking up all threads? John: In the big picture, you want a SIGSUSPEND to suspend all the threads on all the processors for that process. The behaviour of a program to ^Z is well defined and people will expect that it just stops.. (not just part of it) > > Nate -- +------------------------------------+ ______ _ __ | __--_|\ 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 Wed Sep 19 21:23: 0 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 CA7F937B421; Wed, 19 Sep 2001 21:22:57 -0700 (PDT) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id AAA23104; Thu, 20 Sep 2001 00:22:02 -0400 (EDT) Date: Thu, 20 Sep 2001 00:21:59 -0400 (EDT) From: Daniel Eischen To: John Baldwin , julian@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: sigsuspend() and KSE 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 Wed, 19 Sep 2001, Daniel Eischen wrote: > On Wed, 19 Sep 2001, John Baldwin wrote: > > >From the KSE commit the following was added regarding sigsuspend: > > > > /* > > * Suspend process until signal, providing mask to be set > > * in the meantime. Note nonstandard calling convention: > > * libc stub passes mask, not pointer, to save a copyin. > > ***** XXXKSE this doesn't make sense under KSE. > > ***** Do we suspend the thread or all threads in the process? > > ***** How do we suspend threads running NOW on another processor? > > */ > > > > Here's my opinion: > > > > sigsuspend() just suspends the current thread. When a signal is posted, it > > wakes up all threads blocked on sigsuspend whose mask matches that signal. I > > can see it still making sense, but perhaps being of limited usefulness in a > > threaded program. > > Right. sigsuspend should only block the calling thread and result > into an upcall into the threads library. This really shouldn't > be any different than a thread blocking on I/O. Since signals [...] Thinking about this a bit more, the threads library already wraps sigsuspend(). I think it might have to for a KSE-based threads library also. The UTS needs to know what the suspended signal mask is in order to properly determine which thread a signal should be sent to. The kernel could pass the suspended signal mask up to the UTS when the calling thread sigsuspends, but this seems a bit too special case for something that is easily (and is already) wrapped by the threads library. So if you wanted to ignore the case of sigsuspend in a multi- threaded process, I don't think it'll be a problem. We do need a way for the KSE to tell the kernel "Hey, I have no more work to do, but may have at some point in the future". If you made sigsuspend/signanosleep on a per-KSE basis, the KSE could use these system calls to do exactly that. You would still need a separate system call to wake them though since kill() operates on the process. -- 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 Sep 19 22:25:53 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.121.85]) by hub.freebsd.org (Postfix) with ESMTP id C19CC37B41D for ; Wed, 19 Sep 2001 22:25:51 -0700 (PDT) Received: from mindspring.com (dialup-209.244.105.62.Dial1.SanJose1.Level3.net [209.244.105.62]) by gull.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id WAA28490; Wed, 19 Sep 2001 22:25:50 -0700 (PDT) Message-ID: <3BA97E0C.7FF390BE@mindspring.com> Date: Wed, 19 Sep 2001 22:26:36 -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: mike varga Cc: freebsd-arch@freebsd.org Subject: Re: kevent hangs References: <00dd01c14164$c54b3560$4a10a8c0@stcla1.sfba.home.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 > mike varga wrote: > > I opted to break the changelist > and eventlist into 2 seperate calls. > > When I make the first call to add the > changelist, the call to kevent hangs. > > Does anyone know what is wrong? Does it hang forever, or does it hang fdor 2 seconds (the timeout you specified)? In general, splitting the calls is probably not a good idea, since it doubles your system call overhead for work you have to do anyway. You might want to try it against /dev/null; it may be that your device driver writes end up being synchronous for the driver you are doing, and they may need to be reworked. The closest drivers to your hardware aren't network cards, they are actually sound card drivers. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Sep 20 9:14:34 2001 Delivered-To: freebsd-arch@freebsd.org Received: from matrix.eurocontrol.fr (matrix.eurocontrol.fr [147.196.254.254]) by hub.freebsd.org (Postfix) with ESMTP id A670C37B415 for ; Thu, 20 Sep 2001 09:14:28 -0700 (PDT) Received: from caerdonn.eurocontrol.fr (caerdonn.eurocontrol.fr [147.196.51.214]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "caerdonn.eurocontrol.fr", Issuer CN "CA ITM" (not verified)) by matrix.eurocontrol.fr (Postfix/TLS) with ESMTP id A063E22D7 for ; Thu, 20 Sep 2001 18:14:24 +0200 (CEST) Received: by caerdonn.eurocontrol.fr (Postfix/TLS, from userid 1193) id A114E109; Thu, 20 Sep 2001 18:14:23 +0200 (CEST) Date: Thu, 20 Sep 2001 18:14:23 +0200 From: Ollivier Robert To: freebsd-arch@freebsd.org Subject: New option for newfs Message-ID: <20010920181423.A99633@caerdonn.eurocontrol.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Operating-System: 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 I want to add a new option to newfs in order to maximise the number of cylinders per cg (to reduce fragmentation and head movement). Right now, one can use '-c' to specify another value but 1. the default is 22 (calculated for a 8k/1k FS) regardless of the FS (i.e. it will still be 22 even though you choose a 16k/2k FS). 2. newfs barfs when '-c' argument is too high. Proposal: a new option ('-M') that says: ignore -c if present, calculate the maxcpg allowed for the given argument to newfs and use that. Here is a diff and and example. Comments ? 662 [18:11] roberto@caerdonn:sbin/newfs> /usr/obj/src/src/sbin/newfs/newfs -M -N -b 16384 -f 4096 -c 20 /dev/da0s1h Warning: -c is ignored when -M is specified Warning: Block size and bytes per inode restrict cylinders per group to 159. Warning: 624 sector(s) in last cylinder unallocated /dev/da0s1h: 9174416 sectors in 2240 cylinders of 1 tracks, 4096 sectors 4479.7MB in 15 cyl groups (159 c/g, 318.00MB/g, 19072 i/g) super-block backups (for fsck -b #) at: 32, 651296, 1302560, 1953824, 2605088, 3256352, 3907616, 4558880, 5210144, 5861408, 6512672, 7163936, 7815200, 8466464, 9117728 Index: mkfs.c =================================================================== RCS file: /home/ncvs/src/sbin/newfs/mkfs.c,v retrieving revision 1.40 diff -u -2 -r1.40 mkfs.c --- mkfs.c 20 Aug 2001 14:53:05 -0000 1.40 +++ mkfs.c 20 Sep 2001 15:51:23 -0000 @@ -91,4 +91,5 @@ * variables set up by front end. */ +extern int Mflag; /* take as many cpg as possible */ extern int Nflag; /* run mkfs without writing file system */ extern int Oflag; /* format as an 4.3BSD file system */ @@ -454,6 +455,11 @@ printf("Bytes per inode restrict"); printf(" cylinders per group to %d.\n", sblock.fs_cpg); - if (cpgflg) - exit(27); + if (Mflag) { + cpg = sblock.fs_cpg; + } + else { + if (cpgflg) + exit(27); + } } sblock.fs_cgsize = fragroundup(&sblock, CGSIZE(&sblock)); Index: newfs.c =================================================================== RCS file: /home/ncvs/src/sbin/newfs/newfs.c,v retrieving revision 1.40 diff -u -2 -r1.40 newfs.c --- newfs.c 19 Aug 2001 08:19:37 -0000 1.40 +++ newfs.c 20 Sep 2001 16:06:07 -0000 @@ -110,4 +110,5 @@ */ #define DESCPG 22 /* desired fs_cpg */ +#define MAXCPG 999 /* unrealistic value */ /* @@ -162,4 +163,5 @@ #define NSECTORS 4096 /* number of sectors */ +int Mflag; /* take as many cpg as you can */ int Nflag; /* run without writing file system */ int Oflag; /* format as an 4.3BSD file system */ @@ -232,7 +234,11 @@ progname = *argv; - opstring = "NOS:T:Ua:b:c:d:e:f:g:h:i:k:l:m:n:o:p:r:s:t:u:vx:"; + opstring = "MNOS:T:Ua:b:c:d:e:f:g:h:i:k:l:m:n:o:p:r:s:t:u:vx:"; while ((ch = getopt(argc, argv, opstring)) != -1) switch (ch) { + case 'M': + Mflag = 1; + cpg = MAXCPG; + break; case 'N': Nflag = 1; @@ -266,4 +272,8 @@ break; case 'c': + if (Mflag) { + printf("Warning: -c is ignored when -M is specified\n"); + break; + } if ((cpg = atoi(optarg)) <= 0) fatal("%s: bad cylinders/group", optarg); @@ -652,4 +662,6 @@ #endif fprintf(stderr, "where fsoptions are:\n"); + fprintf(stderr, + "\t-M use as many cylinders per group as possible (-c is ignored)\n"); fprintf(stderr, "\t-N do not create file system, just print out parameters\n"); -- Ollivier ROBERT -=- Eurocontrol EEC/ITM -=- Ollivier.Robert@eurocontrol.fr FreeBSD caerdonn.eurocontrol.fr 5.0-CURRENT #46: Wed Jan 3 15:52:00 CET 2001 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Sep 20 9:41:46 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id ED50F37B40B for ; Thu, 20 Sep 2001 09:41:44 -0700 (PDT) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id f8KGfVi54936; Thu, 20 Sep 2001 09:41:31 -0700 (PDT) (envelope-from obrien) Date: Thu, 20 Sep 2001 09:41:30 -0700 From: "David O'Brien" To: Ollivier Robert Cc: freebsd-arch@freebsd.org Subject: Re: New option for newfs Message-ID: <20010920094130.A54908@dragon.nuxi.com> Reply-To: obrien@freebsd.org References: <20010920181423.A99633@caerdonn.eurocontrol.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010920181423.A99633@caerdonn.eurocontrol.fr>; from roberto@eurocontrol.fr on Thu, Sep 20, 2001 at 06:14:23PM +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 Thu, Sep 20, 2001 at 06:14:23PM +0200, Ollivier Robert wrote: > Proposal: a new option ('-M') that says: ignore -c if present, calculate > the maxcpg allowed for the given argument to newfs and use that. I like the general idea, but not adding another option (especially one that says to ignore another one). What about chaning -c to accept 0 or -1 and to use the largest maxcpg value possible. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Sep 20 9:47:54 2001 Delivered-To: freebsd-arch@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 20D1D37B419 for ; Thu, 20 Sep 2001 09:47:48 -0700 (PDT) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f8KGlQ662584; Thu, 20 Sep 2001 19:47:26 +0300 (EEST) (envelope-from ru) Date: Thu, 20 Sep 2001 19:47:26 +0300 From: Ruslan Ermilov To: Ollivier Robert Cc: freebsd-arch@FreeBSD.ORG Subject: Re: New option for newfs Message-ID: <20010920194726.A61491@sunbay.com> References: <20010920181423.A99633@caerdonn.eurocontrol.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010920181423.A99633@caerdonn.eurocontrol.fr>; from roberto@eurocontrol.fr on Thu, Sep 20, 2001 at 06:14:23PM +0200 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 Thu, Sep 20, 2001 at 06:14:23PM +0200, Ollivier Robert wrote: > I want to add a new option to newfs in order to maximise the number of > cylinders per cg (to reduce fragmentation and head movement). > > Right now, one can use '-c' to specify another value but > > 1. the default is 22 (calculated for a 8k/1k FS) regardless of the FS > (i.e. it will still be 22 even though you choose a 16k/2k FS). > > 2. newfs barfs when '-c' argument is too high. > > Proposal: a new option ('-M') that says: ignore -c if present, calculate > the maxcpg allowed for the given argument to newfs and use that. > Umm, how about just making ``-c max'' DTRT? You can strcasecmp(optarg, "max") and set Mflag = 1 if it matches. No need for -M and (ugly) MAXCPG then. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Sep 20 10:36:24 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 3D94937B40D; Thu, 20 Sep 2001 10:36:22 -0700 (PDT) Received: (from dillon@localhost) by earth.backplane.com (8.11.6/8.11.2) id f8KHaML63734; Thu, 20 Sep 2001 10:36:22 -0700 (PDT) (envelope-from dillon) Date: Thu, 20 Sep 2001 10:36:22 -0700 (PDT) From: Matt Dillon Message-Id: <200109201736.f8KHaML63734@earth.backplane.com> To: Ruslan Ermilov Cc: Ollivier Robert , freebsd-arch@FreeBSD.ORG Subject: Re: New option for newfs References: <20010920181423.A99633@caerdonn.eurocontrol.fr> <20010920194726.A61491@sunbay.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 :> Proposal: a new option ('-M') that says: ignore -c if present, calculate :> the maxcpg allowed for the given argument to newfs and use that. :> :Umm, how about just making ``-c max'' DTRT? You can strcasecmp(optarg, "max") :and set Mflag = 1 if it matches. No need for -M and (ugly) MAXCPG then. : :Cheers, :-- :Ruslan Ermilov Oracle Developer/DBA, I like the '-c max' idea. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Sep 20 10:38:27 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by hub.freebsd.org (Postfix) with ESMTP id A374337B412 for ; Thu, 20 Sep 2001 10:38:20 -0700 (PDT) Received: (qmail 50528 invoked from network); 20 Sep 2001 17:38:19 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail6.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 20 Sep 2001 17:38:19 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <15273.11874.366229.387658@nomad.yogotech.com> Date: Thu, 20 Sep 2001 10:38:06 -0700 (PDT) From: John Baldwin To: Nate Williams Subject: Re: sigsuspend() and KSE Cc: arch@FreeBSD.ORG, julian@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 On 19-Sep-01 Nate Williams wrote: >> /* >> * Suspend process until signal, providing mask to be set >> * in the meantime. Note nonstandard calling convention: >> * libc stub passes mask, not pointer, to save a copyin. >> ***** XXXKSE this doesn't make sense under KSE. >> ***** Do we suspend the thread or all threads in the process? >> ***** How do we suspend threads running NOW on another processor? >> */ >> >> Here's my opinion: >> >> sigsuspend() just suspends the current thread. When a signal is posted, it >> wakes up all threads blocked on sigsuspend whose mask matches that signal. >> I >> can see it still making sense, but perhaps being of limited usefulness in a >> threaded program. > > What has limited usefulness? Being able to suspend all threads, or > waking up all threads? I'm not sure you would use sigsuspend in the same way in threaded programs, but perhaps I'm wrong. I suppose it also depends on what threading model you are using. > Nate -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Sep 20 10:38:34 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by hub.freebsd.org (Postfix) with ESMTP id A48FF37B40D for ; Thu, 20 Sep 2001 10:38:21 -0700 (PDT) Received: (qmail 50537 invoked from network); 20 Sep 2001 17:38:20 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail6.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 20 Sep 2001 17:38:20 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <3BA9406D.2BD9DFDF@elischer.org> Date: Thu, 20 Sep 2001 10:38:07 -0700 (PDT) From: John Baldwin To: Julian Elischer Subject: Re: cvs commit: src/sys/kern kern_mutex.c Cc: arch@freebsd.org, julian@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 On 20-Sep-01 Julian Elischer wrote: > > John Baldwin wrote: >> >> On 19-Sep-01 John Baldwin wrote: >> > jhb 2001/09/19 15:52:59 PDT >> > >> > Modified files: >> > sys/kern kern_mutex.c >> > Log: >> > Fix a bug in propagate priority: the kse group pointer wasn't being >> > updated in the loop so the new thread always seemd to have the same >> > priority as the original thread and no actual priorities were changed. >> >> As a sort of follow-up, Julian, can you explain why the oncpu == NOCPU test >> to >> see if a thread is currently running (i.e., physically executing thus it's >> not >> on a runqueue and there's nothing we can do to make it run any sooner) is >> insufficient per new comments in the code? > > if (td->td_kse && (td->td_kse->ke_oncpu != NOCPU)) { > > The above test does not say that the thread is running, > only that the KSE is running. Which thread is running needs to be > found out from td->td_kse->ke_thread. In the 1:1 case this is > enough but when we add code to schedule threads onto KSEs > then the test must be expanded if we really want to know whether a > thread is running.. Ah. > It is of course possible that what thread is running is not > so important as whether the kse is running. What we need to decide > is exactly what happens with proiority chages that are given to a thread.. > does the KSE ket itfo rthe entire tick? for just the time that thread > (syscall) > is running? > priority scope is something we have not really discussed yet. Nah, the thread holds the lock, so it is the thread's priority which must be bumped. In this sense, bumping the kse group priority is wrong. Qutie possibly what should happen is that the the pri_native and pri_user priorities should be in the ksegroup but that the actual priority should be in the thread since priority propagation just wants to ensure that the thread holding a resource we need will run soon. If other threads from the same ksegroup run first that doesn't really help. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Sep 20 11:16: 2 2001 Delivered-To: freebsd-arch@freebsd.org Received: from beastie.mckusick.com (beastie.mckusick.com [209.31.233.184]) by hub.freebsd.org (Postfix) with ESMTP id 5293637B415; Thu, 20 Sep 2001 11:15:59 -0700 (PDT) Received: from beastie.mckusick.com (localhost [127.0.0.1]) by beastie.mckusick.com (8.11.4/8.9.3) with ESMTP id f8KIFQh33875; Thu, 20 Sep 2001 11:15:26 -0700 (PDT) (envelope-from mckusick@beastie.mckusick.com) Message-Id: <200109201815.f8KIFQh33875@beastie.mckusick.com> To: Ollivier Robert Subject: Re: New option for newfs Cc: freebsd-arch@FreeBSD.ORG, obrien@FreeBSD.ORG In-Reply-To: Your message of "Thu, 20 Sep 2001 09:41:30 PDT." <20010920094130.A54908@dragon.nuxi.com> Date: Thu, 20 Sep 2001 11:15:26 -0700 From: Kirk McKusick 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 > Date: Thu, 20 Sep 2001 09:41:30 -0700 > From: "David O'Brien" > To: Ollivier Robert > Cc: freebsd-arch@FreeBSD.ORG > Subject: Re: New option for newfs > > On Thu, Sep 20, 2001 at 06:14:23PM +0200, Ollivier Robert wrote: > > Proposal: a new option ('-M') that says: ignore -c if present, calculate > > the maxcpg allowed for the given argument to newfs and use that. > > I like the general idea, but not adding another option (especially one > that says to ignore another one). What about chaning -c to accept 0 or > -1 and to use the largest maxcpg value possible. I like the idea, but also do not like the implementation. I would propose an even simpler change. If -c is not specified, have it select the maximum possible rather than the current default value of 22. Users that do not want the maximum possible can over-ride that default by using -c. Kirk McKusick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Sep 20 11:59: 9 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 ABDD737B403 for ; Thu, 20 Sep 2001 11:59:06 -0700 (PDT) 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 EAA24941; Fri, 21 Sep 2001 04:58:59 +1000 Date: Fri, 21 Sep 2001 04:58:31 +1000 (EST) From: Bruce Evans X-X-Sender: To: Ollivier Robert Cc: Subject: Re: New option for newfs In-Reply-To: <20010920181423.A99633@caerdonn.eurocontrol.fr> Message-ID: <20010921044949.M70097-100000@delplex.bde.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 On Thu, 20 Sep 2001, Ollivier Robert wrote: > I want to add a new option to newfs in order to maximise the number of > cylinders per cg (to reduce fragmentation and head movement). > > Right now, one can use '-c' to specify another value but > > 1. the default is 22 (calculated for a 8k/1k FS) regardless of the FS > (i.e. it will still be 22 even though you choose a 16k/2k FS). > > 2. newfs barfs when '-c' argument is too high. > > Proposal: a new option ('-M') that says: ignore -c if present, calculate > the maxcpg allowed for the given argument to newfs and use that. My version defaults to using the maximum. This is usually the best possible value since the best value is usually much larger (but impossible). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Sep 20 11:59:59 2001 Delivered-To: freebsd-arch@freebsd.org Received: from antipater.hosting.pacbell.net (antipater.hosting.pacbell.net [216.100.99.13]) by hub.freebsd.org (Postfix) with ESMTP id D5CB237B416 for ; Thu, 20 Sep 2001 11:59:53 -0700 (PDT) Received: from c1435077a (adsl-64-172-38-74.dsl.snfc21.pacbell.net [64.172.38.74]) by antipater.hosting.pacbell.net id OAA03815; Thu, 20 Sep 2001 14:59:31 -0400 (EDT) [ConcentricHost SMTP Relay 1.7] Message-ID: <005b01c14204$8b49b350$4a10a8c0@stcla1.sfba.home.com> Reply-To: "mike varga" From: "mike varga" To: Subject: Fw: kevent hangs Date: Thu, 20 Sep 2001 11:46:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 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 ----- Original Message ----- From: "mike varga" To: "Jonathan Lemon" Sent: Thursday, September 20, 2001 11:28 AM Subject: Re: kevent hangs > I did some remote debuging > and found that the hanging was > coming from the repeated call of > kevent with 0 changes and 0 > events. > > I see the first call to add a change list > but there is some infinite loop > calling kevent with 0 changes and 0 > events. So my application never returns. > > It makes sense because the system > utilization went to 100% with > neerly half split across user and > system. > > > ----- Original Message ----- > From: "Jonathan Lemon" > To: "mike varga" > Sent: Wednesday, September 19, 2001 6:12 PM > Subject: Re: kevent hangs > > > > Hmm. If wchan is '-', then the process is not sleeping in the kernel. > > That's puzzling. The fact that you're able to kill the application > > indicates that a signal is delivered. Signals are only delivered when > > the process calls tsleep(), or is about to return to userland. > > > > Are you sure that the kevent() call never is returning? You could > > check this with ktrace. Otherwise, I don't know what is going on, > > I would suggest breaking out the kernel debugger and traceing the > > flow of execution. > > -- > > Jonathan > > > > > > On Wed, Sep 19, 2001 at 05:48:21PM -0700, mike varga wrote: > > > The WCHAN is "-". > > > > > > ----- Original Message ----- > > > From: "Jonathan Lemon" > > > To: "mike varga" > > > Sent: Wednesday, September 19, 2001 5:33 PM > > > Subject: Re: kevent hangs > > > > > > > > > > That looks right, and I don't see anything obviously wrong > > > > with the code. The same sequence works here (for a normal fd). > > > > > > > > If you do a 'ps -axl' on the machine, what WCHAN does it > > > > show the process in? > > > > -- > > > > Jonathan > > > > > > > > > > > > On Wed, Sep 19, 2001 at 05:01:10PM -0700, mike varga wrote: > > > > > > > > > > I see "cavium_kqfilter: 1 called", "cavium_kqfilter: 2 called", > > > > > "cavium_kqfilter: 3 called". > > > > > > > > > > I also see "kqfilter: 1 called". > > > > > > > > > > After I cancel the application, I > > > > > see "kqdetach: 1 called". > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > From: "Jonathan Lemon" > > > > > To: "mike varga" > > > > > Sent: Wednesday, September 19, 2001 5:06 PM > > > > > Subject: Re: kevent hangs > > > > > > > > > > > > > > > > On Wed, Sep 19, 2001 at 04:42:31PM -0700, mike varga wrote: > > > > > > > I opted to break the changelist > > > > > > > and eventlist into 2 seperate calls. > > > > > > > > > > > > > > When I make the first call to add the > > > > > > > changelist, the call to kevent hangs. > > > > > > > > > > > > > > Does anyone know what is wrong? > > > > > > > > > > > > You don't say which (if any) of the kernel printfs are being hit, > > > > > > so it is hard to tell. > > > > > > -- > > > > > > Jonathan > > > > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Sep 20 12: 7:13 2001 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id CC2DE37B413 for ; Thu, 20 Sep 2001 12:07:11 -0700 (PDT) Received: by elvis.mu.org (Postfix, from userid 1192) id 93A9281D01; Thu, 20 Sep 2001 14:07:06 -0500 (CDT) Date: Thu, 20 Sep 2001 14:07:06 -0500 From: Alfred Perlstein To: mike varga Cc: freebsd-arch@freebsd.org Subject: Re: Fw: kevent hangs Message-ID: <20010920140706.Y61456@elvis.mu.org> References: <005b01c14204$8b49b350$4a10a8c0@stcla1.sfba.home.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <005b01c14204$8b49b350$4a10a8c0@stcla1.sfba.home.com>; from mike.varga@cavium.com on Thu, Sep 20, 2001 at 11:46:02AM -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 Grr.. Please provide a stripped down C program to demonstrate how you're incorrectly using the kqueue API. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Sep 20 12:22:30 2001 Delivered-To: freebsd-arch@freebsd.org Received: from tara.freenix.org (keltia.freenix.org [62.4.20.87]) by hub.freebsd.org (Postfix) with ESMTP id 4CBF937B401; Thu, 20 Sep 2001 12:22:27 -0700 (PDT) Received: by tara.freenix.org (Postfix/TLS, from userid 101) id 30F89108; Thu, 20 Sep 2001 21:22:26 +0200 (CEST) Date: Thu, 20 Sep 2001 21:22:26 +0200 From: Ollivier Robert To: Kirk McKusick Cc: freebsd-arch@FreeBSD.ORG, obrien@FreeBSD.ORG Subject: Re: New option for newfs Message-ID: <20010920212226.A28322@tara.freenix.org> References: <20010920094130.A54908@dragon.nuxi.com> <200109201815.f8KIFQh33875@beastie.mckusick.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200109201815.f8KIFQh33875@beastie.mckusick.com>; from mckusick@mckusick.com on Thu, Sep 20, 2001 at 11:15:26AM -0700 X-Operating-System: FreeBSD 5.0-CURRENT K6-3D/266 & 2x PPro/200 SMP 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 According to Kirk McKusick: > I would propose an even simpler change. If -c is not specified, > have it select the maximum possible rather than the current > default value of 22. Users that do not want the maximum possible > can over-ride that default by using -c. That's probably the best option, I'll resubmit a diff for that. Apparently the largest allowable value is found by trial and error, I'll keep the same algorithm. Thanks to all for your comments! -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 5.0-CURRENT #80: Sun Jun 4 22:44:19 CEST 2000 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Sep 20 12:59:45 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 7F6DF37B409; Thu, 20 Sep 2001 12:59:39 -0700 (PDT) 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 FAA27519; Fri, 21 Sep 2001 05:59:21 +1000 Date: Fri, 21 Sep 2001 05:58:53 +1000 (EST) From: Bruce Evans X-X-Sender: To: Kirk McKusick Cc: Ollivier Robert , , Subject: Re: New option for newfs In-Reply-To: <200109201815.f8KIFQh33875@beastie.mckusick.com> Message-ID: <20010921054417.Q70596-100000@delplex.bde.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 On Thu, 20 Sep 2001, Kirk McKusick wrote: > > From: "David O'Brien" > > ... > > On Thu, Sep 20, 2001 at 06:14:23PM +0200, Ollivier Robert wrote: > > > Proposal: a new option ('-M') that says: ignore -c if present, calculate > > > the maxcpg allowed for the given argument to newfs and use that. > > > > I like the general idea, but not adding another option (especially one > > that says to ignore another one). What about chaning -c to accept 0 or > > -1 and to use the largest maxcpg value possible. > > I like the idea, but also do not like the implementation. > I would propose an even simpler change. If -c is not specified, > have it select the maximum possible rather than the current > default value of 22. Users that do not want the maximum possible > can over-ride that default by using -c. I have used this change for almost a year. IIRC, just changing DESCPG to a huge value is sufficient (newfs reduces from the default to the maximum if the default is larger). The ncyls stuff is to fix (?) the cosmetic (?) problem that bogus warnings are printed for vary small disks (ones where there are more cpg's than cylinders). The patch is missing the manpage changes. %%% Index: newfs.c =================================================================== RCS file: /home/ncvs/src/sbin/newfs/newfs.c,v retrieving revision 1.40 diff -u -2 -r1.40 newfs.c --- newfs.c 19 Aug 2001 08:19:37 -0000 1.40 +++ newfs.c 20 Sep 2001 18:55:28 -0000 @@ -105,9 +97,8 @@ * Cylinder groups may have up to many cylinders. The actual * number used depends upon how much information can be stored - * on a single cylinder. The default is to use 22 cylinders - * per group, which seems to be the largest value allowed given - * all the other default values. + * on a single cylinder. The default is to use as many as possible + * cylinders per group. */ -#define DESCPG 22 /* desired fs_cpg */ +#define DESCPG 65536 /* desired fs_cpg ("infinity") */ /* @@ -168,4 +159,5 @@ int ntracks = NTRACKS; /* # tracks/cylinder */ int nsectors = NSECTORS; /* # sectors/track */ +int ncyls; /* # complete cylinders */ int nphyssectors; /* # sectors/track including spares */ int secpercyl; /* sectors per cylinder */ @@ -181,5 +173,5 @@ int fsize = 0; /* fragment size */ int bsize = 0; /* block size */ -int cpg = DESCPG; /* cylinders/cylinder group */ +int cpg = 0; /* cylinders/cylinder group */ int cpgflg; /* cylinders/cylinder group flag was given */ int minfree = MINFREE; /* free space threshold */ @@ -546,4 +538,15 @@ } #endif + ncyls = fssize / secpercyl; + if (ncyls == 0) + ncyls = 1; /* XXX */ + if (cpg == 0) + cpg = DESCPG < ncyls ? DESCPG : ncyls; + else if (cpg > ncyls) { + cpg = ncyls; + printf( + "Number of cylinders restricts cylinders per group to %d.\n", + cpg); + } mkfs(pp, special, fsi, fso); #ifdef tahoe %%% Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Sep 20 14:10:15 2001 Delivered-To: freebsd-arch@freebsd.org Received: from tara.freenix.org (keltia.freenix.org [62.4.20.87]) by hub.freebsd.org (Postfix) with ESMTP id 94C9837B418; Thu, 20 Sep 2001 14:10:04 -0700 (PDT) Received: by tara.freenix.org (Postfix/TLS, from userid 101) id A181B108; Thu, 20 Sep 2001 23:10:03 +0200 (CEST) Date: Thu, 20 Sep 2001 23:10:03 +0200 From: Ollivier Robert To: Bruce Evans Cc: Kirk McKusick , freebsd-arch@FreeBSD.ORG, obrien@FreeBSD.ORG Subject: Re: New option for newfs Message-ID: <20010920231003.B28322@tara.freenix.org> Mail-Followup-To: Bruce Evans , Kirk McKusick , freebsd-arch@FreeBSD.ORG, obrien@FreeBSD.ORG References: <200109201815.f8KIFQh33875@beastie.mckusick.com> <20010921054417.Q70596-100000@delplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010921054417.Q70596-100000@delplex.bde.org>; from bde@zeta.org.au on Fri, Sep 21, 2001 at 05:58:53AM +1000 X-Operating-System: FreeBSD 5.0-CURRENT K6-3D/266 & 2x PPro/200 SMP 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 According to Bruce Evans: > I have used this change for almost a year. Why haven't you committed it before ? grrr :) > The patch is missing the manpage changes. I can do them. Please commit it (or I can do it if you want). -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 5.0-CURRENT #80: Sun Jun 4 22:44:19 CEST 2000 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Sep 20 14:52:35 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 BEE1437B40E; Thu, 20 Sep 2001 14:52:31 -0700 (PDT) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id PAA33236; Thu, 20 Sep 2001 15:30:58 -0700 (PDT) Date: Thu, 20 Sep 2001 15:30:57 -0700 (PDT) From: Julian Elischer To: John Baldwin Cc: arch@freebsd.org, julian@FreeBSD.org Subject: Re: cvs commit: src/sys/kern kern_mutex.c 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 Thu, 20 Sep 2001, John Baldwin wrote: > > On 20-Sep-01 Julian Elischer wrote: > > > It is of course possible that what thread is running is not > > so important as whether the kse is running. What we need to decide > > is exactly what happens with proiority chages that are given to a thread.. > > does the KSE get it for the entire tick? for just the time that > > thread > > (syscall) > > is running? > > priority scope is something we have not really discussed yet. > > Nah, the thread holds the lock, so it is the thread's priority which must be > bumped. In this sense, bumping the kse group priority is wrong. Qutie > possibly what should happen is that the the pri_native and pri_user priorities > should be in the ksegroup but that the actual priority should be in the thread > since priority propagation just wants to ensure that the thread holding a > resource we need will run soon. If other threads from the same ksegroup run > first that doesn't really help. This is all uncharter water... Some of the possibilities are: 1/ Actual priority is boosted to that of teh thread when the thread is run 2/ The KSE priority is boosted to the priority of the highest priority thread assigned to it.. (for the entire tick, or until it enters user space.) 3/ The kse orders the threads to run in priority order, and reduces it's own priority each time it runs a new thread.. (losing it's tick if it reduces it below the priority of another KSE wanting to run..) 4/ Other ideas acceptable > > -- > > John Baldwin -- http://www.FreeBSD.org/~jhb/ > PGP Key: http://www.baldwin.cx/~john/pgpkey.asc > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Sep 20 23:42:47 2001 Delivered-To: freebsd-arch@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id EF83637B40A; Thu, 20 Sep 2001 23:42:37 -0700 (PDT) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f8L6fda28896; Fri, 21 Sep 2001 09:41:39 +0300 (EEST) (envelope-from ru) Date: Fri, 21 Sep 2001 09:41:39 +0300 From: Ruslan Ermilov To: Bruce Evans Cc: Kirk McKusick , Ollivier Robert , freebsd-arch@FreeBSD.ORG, obrien@FreeBSD.ORG Subject: Re: New option for newfs Message-ID: <20010921094139.C27714@sunbay.com> References: <200109201815.f8KIFQh33875@beastie.mckusick.com> <20010921054417.Q70596-100000@delplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010921054417.Q70596-100000@delplex.bde.org>; from bde@zeta.org.au on Fri, Sep 21, 2001 at 05:58:53AM +1000 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, Sep 21, 2001 at 05:58:53AM +1000, Bruce Evans wrote: [...] > I have used this change for almost a year. > > IIRC, just changing DESCPG to a huge value is sufficient (newfs reduces > from the default to the maximum if the default is larger). The ncyls > stuff is to fix (?) the cosmetic (?) problem that bogus warnings are > printed for vary small disks (ones where there are more cpg's than > cylinders). > > The patch is missing the manpage changes. > > %%% > Index: newfs.c > =================================================================== > RCS file: /home/ncvs/src/sbin/newfs/newfs.c,v > retrieving revision 1.40 > diff -u -2 -r1.40 newfs.c > --- newfs.c 19 Aug 2001 08:19:37 -0000 1.40 > +++ newfs.c 20 Sep 2001 18:55:28 -0000 > @@ -105,9 +97,8 @@ > * Cylinder groups may have up to many cylinders. The actual > * number used depends upon how much information can be stored > - * on a single cylinder. The default is to use 22 cylinders > - * per group, which seems to be the largest value allowed given > - * all the other default values. > + * on a single cylinder. The default is to use as many as possible > + * cylinders per group. > */ > -#define DESCPG 22 /* desired fs_cpg */ > +#define DESCPG 65536 /* desired fs_cpg ("infinity") */ > Shouldn't that be INT_MAX? Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Sep 21 1: 0:10 2001 Delivered-To: freebsd-arch@freebsd.org Received: from matrix.eurocontrol.fr (matrix.eurocontrol.fr [147.196.254.254]) by hub.freebsd.org (Postfix) with ESMTP id 8FED637B429; Fri, 21 Sep 2001 01:00:08 -0700 (PDT) Received: from caerdonn.eurocontrol.fr (caerdonn.eurocontrol.fr [147.196.51.214]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "caerdonn.eurocontrol.fr", Issuer CN "CA ITM" (not verified)) by matrix.eurocontrol.fr (Postfix/TLS) with ESMTP id DD9D422D6; Fri, 21 Sep 2001 10:00:07 +0200 (CEST) Received: by caerdonn.eurocontrol.fr (Postfix/TLS, from userid 1193) id 4F288109; Fri, 21 Sep 2001 10:00:06 +0200 (CEST) Date: Fri, 21 Sep 2001 10:00:06 +0200 From: Ollivier Robert To: Ruslan Ermilov Cc: Bruce Evans , Kirk McKusick , freebsd-arch@FreeBSD.ORG, obrien@FreeBSD.ORG Subject: Re: New option for newfs Message-ID: <20010921100006.B1829@caerdonn.eurocontrol.fr> References: <200109201815.f8KIFQh33875@beastie.mckusick.com> <20010921054417.Q70596-100000@delplex.bde.org> <20010921094139.C27714@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010921094139.C27714@sunbay.com>; from ru@FreeBSD.ORG on Fri, Sep 21, 2001 at 09:41:39AM +0300 X-Operating-System: 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 According to Ruslan Ermilov: > > -#define DESCPG 22 /* desired fs_cpg */ > > +#define DESCPG 65536 /* desired fs_cpg ("infinity") */ > > > Shouldn't that be INT_MAX? As the way to find the maxcpg is to iterate from DESCPG down to that maxcpg, I think that 65536 is enough. No need to go from 2^31-1 down to something that will seldom be more than 1000 (or even 10000). -- Ollivier ROBERT -=- Eurocontrol EEC/ITM -=- Ollivier.Robert@eurocontrol.fr FreeBSD caerdonn.eurocontrol.fr 5.0-CURRENT #46: Wed Jan 3 15:52:00 CET 2001 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Sep 21 1: 4:54 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ringworld.nanolink.com (straylight.ringlet.net [217.75.134.254]) by hub.freebsd.org (Postfix) with SMTP id E0D1E37B428 for ; Fri, 21 Sep 2001 01:04:47 -0700 (PDT) Received: (qmail 10207 invoked by uid 1000); 21 Sep 2001 08:04:05 -0000 Date: Fri, 21 Sep 2001 11:04:05 +0300 From: Peter Pentchev To: Alfred Perlstein Cc: mike varga , freebsd-arch@freebsd.org Subject: Re: Fw: kevent hangs Message-ID: <20010921110405.A9870@ringworld.oblivion.bg> Mail-Followup-To: Alfred Perlstein , mike varga , freebsd-arch@freebsd.org References: <005b01c14204$8b49b350$4a10a8c0@stcla1.sfba.home.com> <20010920140706.Y61456@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010920140706.Y61456@elvis.mu.org>; from bright@mu.org on Thu, Sep 20, 2001 at 02:07:06PM -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 Thu, Sep 20, 2001 at 02:07:06PM -0500, Alfred Perlstein wrote: > Grr.. > > Please provide a stripped down C program to demonstrate how you're > incorrectly using the kqueue API. He did, on -arch, yesterday. Message-ID: <00dd01c14164$c54b3560$4a10a8c0@stcla1.sfba.home.com> G'luck, Peter -- I've heard that this sentence is a rumor. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Sep 21 7:41:58 2001 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id 08CF937B413 for ; Fri, 21 Sep 2001 07:41:56 -0700 (PDT) Received: by elvis.mu.org (Postfix, from userid 1192) id D5C5381D01; Fri, 21 Sep 2001 09:41:50 -0500 (CDT) Date: Fri, 21 Sep 2001 09:41:50 -0500 From: Alfred Perlstein To: Peter Pentchev Cc: mike varga , freebsd-arch@freebsd.org Subject: Re: Fw: kevent hangs Message-ID: <20010921094150.L61456@elvis.mu.org> References: <005b01c14204$8b49b350$4a10a8c0@stcla1.sfba.home.com> <20010920140706.Y61456@elvis.mu.org> <20010921110405.A9870@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: <20010921110405.A9870@ringworld.oblivion.bg>; from roam@ringlet.net on Fri, Sep 21, 2001 at 11:04:05AM +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 * Peter Pentchev [010921 03:05] wrote: > On Thu, Sep 20, 2001 at 02:07:06PM -0500, Alfred Perlstein wrote: > > Grr.. > > > > Please provide a stripped down C program to demonstrate how you're > > incorrectly using the kqueue API. > > He did, on -arch, yesterday. > Message-ID: <00dd01c14164$c54b3560$4a10a8c0@stcla1.sfba.home.com> > Please try to compile the code contained in that message. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Sep 21 21:53:31 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail2out.giga.net.tw (mail2out.giga.net.tw [203.133.1.11]) by hub.freebsd.org (Postfix) with ESMTP id D23BE37B405 for ; Fri, 21 Sep 2001 21:53:22 -0700 (PDT) Received: from index (u24-164.u203-203.giga.net.tw [203.203.24.164]) by mail2out.giga.net.tw (Postfix) with SMTP id 737B21368B for ; Sat, 22 Sep 2001 12:53:17 +0800 (CST) To: From: gd168@24k.com.tw Subject: 環保雷射碳粉匣專題研究報告 Date: 星期六, 22 九月 2001 12:51:21 +0800 Message-Id: <37156.535670370374400.125540@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=big5 Content-Transfer-Encoding: 8bit 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 受文者:呈 國立台灣大學暨所屬行政學術研究單位/       全國各級機關團體/公司行號/公會或個人 請鑒核! 發文者:企龍辦公用品有限公司 電話:(02)2701-2000 主 旨:使用〔環保雷射碳粉匣〕之優點及採購要點。 說 明:環保雷射碳粉匣之專題研究報告 (一)前言      近年來,由於各項相關技術成熟,配合半導體產業篷勃發展    使得雷射印表機價格大幅下滑,各廠商無不壓低價格,以擴大市    場佔有率,再以後續的耗材賺回其利潤,您花在碳粉匣的費用,    長期而言實在是一筆可觀的支出。         〔使用環保雷射碳粉匣之三大理由〕      (1)技術上已突破:有鑑於碳粉匣和墨水匣需求量不斷成長,    國人五年前開始著手,針對雷射印表機電子寫真技術及碳粉感光    體,進行相關研發工作,研發小組成員皆為博碩士學歷,研發小    組成員針對各大廠牌機器精密結構,已有深度了解,掌握許多相    關技術,對碳粉匣的材料及製程參數有若干改進,以適應台灣亞    熱帶高溫潮濕的氣候環境,經嚴格品管控制,國人所生產的環保    雷射碳粉匣,列印品質和原廠同樣清晰,且不會傷害機器。      (2)為環保盡心力:碳粉匣造成對環境的污染與日俱增,人類    應反省覺悟,我們只有一個地球,為全人類及後代子孫,保留一    個乾淨的生存環境,已到刻不容緩的地步!讓我們從校園做起,    一起來回收並使用環保雷射碳粉匣。      (3)節省列印費用:根據工商時報 90年4月12日報導指出,用    環保雷射碳粉匣可節省4成左右的費用,不必多花錢。 (二)全球趨勢分析      1999年碳粉卡匣再生回收使用比較:    歐美市場再生回收卡匣使用率 30% (約1/3)    台灣市場再生回收卡匣使用率  5%    (資料來源:Recharger期刊)      台灣約有50萬台雷射印表機,預估每年使用約100∼200萬支    雷射碳粉匣,製造出約2000∼2500公噸固體廢棄物,並且每年這    個數目正在成長。而這些塑膠廢棄物須要超過十個世紀來分解,    對台灣三萬六千平方公里的土地上,造成嚴重的負荷。      歐美各國相關環保法令強制規定製造廠商的回收比率,已行    之多年,對於回收業者也有對應的輔助政策,並不斷的教育使用    者回收、減量再利用(Recycle, Reduce, Reuse)的觀念。      事實證明,此舉不僅有助於環保且能降低支出,美國已明令    聯邦政府的各單位必須使用環保碳粉匣。 (三)對環境保護及資源回收再利用,具有正面意義       如果製造每個卡匣需要超過三夸脫油,那麼台灣每年就會    用掉近100 萬加崙的石油。如果您換買環保碳粉匣,很明確地,    您已經對保護環境做出貢獻了,因為我們的圾圾場可以減少一個    空間來存放您的卡匣。      以台灣目前使用量愈來愈多的雷射印表機而言,每天丟棄的    碳粉匣不知多少,而這些碳粉匣裡的碳粉色劑微粒,尺寸約6-12    微米,卻會滲入地下水,污染水源,若想從水中除去這些碳粉微    粒,就必須加裝特殊濾水設備,因此無論公司企業或學校及個人    都有責任一起來防止碳粉匣污染環境的工作,碳粉匣的回收再利    用,是目前的唯一途徑。 (四)環保碳粉匣之採購要點      由於市售環保碳粉匣,供應商過多,各家的品質參差不齊,    敬請認明企龍代理的環保碳粉匣,為目前台灣唯一專業導向之環    保雷射碳粉匣,品質滿意保證,不滿包退,確保消費權益,避免    買到劣質品,選擇企龍,品質有保障!    採購前務必詢問下列重要參考依據:    1.環保雷射碳粉匣,是否完全以標準製程製造? 製程中,廢碳     粉槽及相關零件是否清理乾淨並檢試元件性能?    2.儲粉槽是否完全清潔乾淨後,才重新裝填全新碳粉?    3.所充填之碳粉,是否為國際間知名碳粉廠出品?    4.所有儲粉槽,是否以封條密封,完整交付使用人?    5.碳粉匣是否通過完整而嚴格品管測試後才出廠?    6.測試用之碳粉是否為外加? 所充填的碳粉數量和原廠碳粉匣     容量是否相同,會不會短少?    7.充填之碳粉是否經過精密測試,確認比標準值高才裝填?    8.所更換之感光鼓是否為國際間知名之高科技廠牌產品?    9.碳粉匣成品是否以黑色塑膠紙實施避光包裝後,並以氣泡袋或     特殊襯墊保護,再裝入保護槽,以確保運輸途中乃至使用前,     不受任何光線其他物理性,化學性傷害?     企龍代理的環保雷射碳粉匣業已全數通過上述測試,全面實施     品質滿意保證再訂購,不滿意保證退貨! (五)價格資訊:環保雷射碳粉匣之價格已公布於網站,歡迎上網查詢         網址:http://clik.to/96969180 (六)聯絡資訊:以上資料由企龍辦公用品有限公司所提供,如需訂購         請電:(02)2701-2000我們熱誠的同仁為您服務。 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message