From owner-freebsd-arch@FreeBSD.ORG Sun Nov 7 02:50:26 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1441E106566B; Sun, 7 Nov 2010 02:50:26 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id C8BDB8FC08; Sun, 7 Nov 2010 02:50:25 +0000 (UTC) Received: by pzk12 with SMTP id 12so205459pzk.13 for ; Sat, 06 Nov 2010 19:50:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent:organization:x-operation-sytem; bh=d3KxkfekhcD4Ndm7Mui5q+PXyovgxlAwzsN5vwlhkk4=; b=lwKjPDe79lOV11qrxB4IgEWQFw/KYK/F2I8svifiFKSagcK4d79dNAlpTi6M76Myu3 IPbziL4qokHZiSs9n/HO8cDcIhCmWnWDviN/MDCUBxisgHMDY79b7GeSFdIeAtWZ0iAO GELpOy3T22ddOlugLZ6VOQqcXQLLVFPsM+aYk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent:organization:x-operation-sytem; b=aDmO7bxkLccsLic4Mb73Zpmjf+3EbBuqKNzeT7GjGEjVi9myZQFBPvGbe8Hd7bIUxZ 4sSWmSMNxv4KUBW1Av1StzoTnSeROYwJ2laY3roX6P+vHv7sWrTNFMZYME8zYLnThiOt vXWuLMgJ1NMHytdg7FNEMI2jxEQrgt+/KNtA0= Received: by 10.142.142.18 with SMTP id p18mr2997649wfd.398.1289096594815; Sat, 06 Nov 2010 19:23:14 -0700 (PDT) Received: from weongyo ([174.35.1.224]) by mx.google.com with ESMTPS id q13sm5017643wfc.5.2010.11.06.19.23.11 (version=SSLv3 cipher=RC4-MD5); Sat, 06 Nov 2010 19:23:12 -0700 (PDT) Received: by weongyo (sSMTP sendmail emulation); Sat, 06 Nov 2010 19:23:18 -0700 From: Weongyo Jeong Date: Sat, 6 Nov 2010 19:23:18 -0700 To: Hans Petter Selasky Message-ID: <20101107022318.GF92881@weongyo> Mail-Followup-To: Hans Petter Selasky , freebsd-current@freebsd.org, freebsd-arch@freebsd.org, Matthew Fleming , freebsd-usb@freebsd.org References: <201011012054.59551.hselasky@c2i.net> <201011051836.39697.hselasky@c2i.net> <201011051930.38530.hselasky@c2i.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201011051930.38530.hselasky@c2i.net> User-Agent: Mutt/1.4.2.3i Organization: CDNetworks. X-Operation-Sytem: FreeBSD Cc: freebsd-current@freebsd.org, Matthew Fleming , freebsd-usb@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Weongyo Jeong List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Nov 2010 02:50:26 -0000 On Fri, Nov 05, 2010 at 07:30:38PM +0100, Hans Petter Selasky wrote: > Hi, > > In the patch attached to this e-mail I included Matthew Fleming's patch > aswell. > > 1) I renamed taskqueue_cancel() into taskqueue_stop(), hence that resembles > the words of the callout and USB API's terminology for doing the same. > > 2) I turns out I need to have code in subr_taskqueue.c to be able to make the > operations atomic. > > 3) I did not update the manpage in this patch. Will do that before a commit. > > 4) My patch implements separate state keeping in "struct task_pair", which > avoids having to change any KPI's for now, like suggested by John Baldwin I > think. > > 5) In my implementation I hard-coded the priority argument to zero, so that > enqueuing is fast. > > Comments are welcome! The patch looks almost you moved usb_process.c code into taskqueue(9) that I means it still follows that a entry which enqueued at last should be executed at last. It seems that at least it's not a general for taskqueue(9). In my humble opinion it looks a trick. I think it'd better to find a general solution to solve it though I used sx(9) lock in my patches. regards, Weongyo Jeong From owner-freebsd-arch@FreeBSD.ORG Sun Nov 7 14:18:06 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A1EE106566B for ; Sun, 7 Nov 2010 14:18:06 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2001:470:9a47::1]) by mx1.freebsd.org (Postfix) with ESMTP id 079AC8FC08 for ; Sun, 7 Nov 2010 14:18:05 +0000 (UTC) Received: from acme.spoerlein.net (localhost.spoerlein.net [IPv6:::1]) by acme.spoerlein.net (8.14.4/8.14.4) with ESMTP id oA7EI4i2094915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 7 Nov 2010 15:18:05 +0100 (CET) (envelope-from uqs@spoerlein.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=spoerlein.net; s=dkim200908; t=1289139485; bh=zPEQO+WRrJNXQGkwQYyo9w2IXSlvun/SIelDdgb6y2c=; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type; b=Z2s791hCB/+fcIHvPgk/YzPgR+gMBqgS7oVtzfLUyGgvsG56xfi9fWPiQ2LNYT4i6 WFLx6Iqr5mo02ETh3arufA4uZdjcftzxPIW4XJi8hfSlySKixsAOaCWO8l8gBytplu 2KZFReW7sEIWWNoBtlgSts4/LjF0CLNBr9T6jfas= Received: (from uqs@localhost) by acme.spoerlein.net (8.14.4/8.14.4/Submit) id oA7EI4Dm094914 for arch@freebsd.org; Sun, 7 Nov 2010 15:18:04 +0100 (CET) (envelope-from uqs@spoerlein.net) Date: Sun, 7 Nov 2010 15:18:04 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: arch@freebsd.org Message-ID: <20101107141804.GN85693@acme.spoerlein.net> Mail-Followup-To: arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: Moving flex and yacc to contrib/, all hell breaks loose? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Nov 2010 14:18:06 -0000 Hoi, To my knowledge, the only "vendor" software in our tree, not yet living under cddl/, contrib/, crypto/ or gnu/ are lib/libc/softfloat lib/libz lib/msun usr.bin/lex usr.bin/unifdef usr.bin/yacc I'm not touching the lib parts for now, and for unifdef, see recent post to current@. So flex and yacc remain (if you know of more sources with an upstream development, not already listed on the Wiki under http://wiki.freebsd.org/ContribSoftware please let me know!) I have an universe-surviving svn tree ready for commit, that moves flex to contrib/flex and only a stub Makefile in usr.bin/lex remains, like we do with all other contributed software. Do you foresee any problems this might cause for our clients or commercial vendors? I'm pretty sure they wouldn't monkey around with our lex/yacc too much, but you never know. They usual argument that will now be brought against this is, that the move should only be done, once a new vendor import is ready, but there are other parts of our tree where imports have been done post-svn and noone thought about moving the parts to the "right" places. So I'd rather get this over with now and worry about the actual code updates later. Also, can someone tell me if I need to svn propdel svn:mergeinfo when using the following steps: $ cd freebsd/head $ svn mv usr.bin/lex contrib/flex $ svn rm contrib/flex/Makefile contrib/flex/lib/Makefile # not needed here $ svn revert usr.bin/lex/Makefile usr.bin/lex/lib/Makefile # need to keep them here (hack the Makefiles) $ svn propdel svn:mergeinfo -R contrib/flex # ??? required? $ svn ci Thanks, Uli From owner-freebsd-arch@FreeBSD.ORG Sun Nov 7 16:25:49 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D4751065670 for ; Sun, 7 Nov 2010 16:25:49 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id ED84A8FC1E for ; Sun, 7 Nov 2010 16:25:48 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id oA7GPgLE094414 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 7 Nov 2010 18:25:42 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id oA7GPgK7082070 for ; Sun, 7 Nov 2010 18:25:42 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id oA7GPgwo082069 for arch@freebsd.org; Sun, 7 Nov 2010 18:25:42 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 7 Nov 2010 18:25:42 +0200 From: Kostik Belousov To: arch@freebsd.org Message-ID: <20101107162542.GT2392@deviant.kiev.zoral.com.ua> References: <20101107141804.GN85693@acme.spoerlein.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="skIwehpLT6l7hZAl" Content-Disposition: inline In-Reply-To: <20101107141804.GN85693@acme.spoerlein.net> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_05, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Subject: Re: Moving flex and yacc to contrib/, all hell breaks loose? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Nov 2010 16:25:49 -0000 --skIwehpLT6l7hZAl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Nov 07, 2010 at 03:18:04PM +0100, Ulrich Sp??rlein wrote: > Hoi, >=20 > To my knowledge, the only "vendor" software in our tree, not yet living > under cddl/, contrib/, crypto/ or gnu/ are >=20 > lib/libc/softfloat > lib/libz > lib/msun > usr.bin/lex > usr.bin/unifdef > usr.bin/yacc >=20 > I'm not touching the lib parts for now, and for unifdef, see recent > post to current@. So flex and yacc remain (if you know of more sources > with an upstream development, not already listed on the Wiki under > http://wiki.freebsd.org/ContribSoftware please let me know!) >=20 > I have an universe-surviving svn tree ready for commit, that moves flex > to contrib/flex and only a stub Makefile in usr.bin/lex remains, like we > do with all other contributed software. Contributed means that there is a project external to FreeBSD that maintains the software. What is the project for yacc ? lex being flex probably deserves move to contrib. --skIwehpLT6l7hZAl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAkzW0wYACgkQC3+MBN1Mb4gTewCgzJPslqFr2239YHH7WTP/xpF7 REMAn0/yVYx84DAMWkKG3pRBubXAhfNd =cKKx -----END PGP SIGNATURE----- --skIwehpLT6l7hZAl-- From owner-freebsd-arch@FreeBSD.ORG Sun Nov 7 21:33:33 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 190F8106566C for ; Sun, 7 Nov 2010 21:33:33 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2001:470:9a47::1]) by mx1.freebsd.org (Postfix) with ESMTP id 8645F8FC0C for ; Sun, 7 Nov 2010 21:33:32 +0000 (UTC) Received: from acme.spoerlein.net (localhost.spoerlein.net [IPv6:::1]) by acme.spoerlein.net (8.14.4/8.14.4) with ESMTP id oA7LXV6x003124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 7 Nov 2010 22:33:31 +0100 (CET) (envelope-from uqs@spoerlein.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=spoerlein.net; s=dkim200908; t=1289165611; bh=qL3nuBO/MlOm9kSmaTTf2ac2qdzTZFviijESFWcbyRk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=q6OjQN8QumTkJO+ID+yhhk4LK86kl8G48feXGY8QMICA5PLZeH7JhxjzyZw45/rSP cJSnBcjzF8ZcDaACZHtoSlHrdAgtlHx2PjtjA370Jiyhb6pfTNKMzpj03ib9W4IceC qYhLNdyx6NjoIov+yMDqBQIFoqbV/6sgYFMGwuCY= Received: (from uqs@localhost) by acme.spoerlein.net (8.14.4/8.14.4/Submit) id oA7LXVok003123; Sun, 7 Nov 2010 22:33:31 +0100 (CET) (envelope-from uqs@spoerlein.net) Date: Sun, 7 Nov 2010 22:33:31 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Kostik Belousov Message-ID: <20101107213331.GQ85693@acme.spoerlein.net> Mail-Followup-To: Kostik Belousov , arch@freebsd.org References: <20101107141804.GN85693@acme.spoerlein.net> <20101107162542.GT2392@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101107162542.GT2392@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: arch@freebsd.org Subject: Re: Moving flex and yacc to contrib/, all hell breaks loose? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Nov 2010 21:33:33 -0000 On Sun, 07.11.2010 at 18:25:42 +0200, Kostik Belousov wrote: > On Sun, Nov 07, 2010 at 03:18:04PM +0100, Ulrich Sp??rlein wrote: > > Hoi, > > > > To my knowledge, the only "vendor" software in our tree, not yet living > > under cddl/, contrib/, crypto/ or gnu/ are > > > > lib/libc/softfloat > > lib/libz > > lib/msun > > usr.bin/lex > > usr.bin/unifdef > > usr.bin/yacc > > > > I'm not touching the lib parts for now, and for unifdef, see recent > > post to current@. So flex and yacc remain (if you know of more sources > > with an upstream development, not already listed on the Wiki under > > http://wiki.freebsd.org/ContribSoftware please let me know!) > > > > I have an universe-surviving svn tree ready for commit, that moves flex > > to contrib/flex and only a stub Makefile in usr.bin/lex remains, like we > > do with all other contributed software. > Contributed means that there is a project external to FreeBSD that > maintains the software. What is the project for yacc ? See the wiki page, it will point you to http://invisible-island.net/byacc/byacc.html where Thomas Dickey has been updating byacc regularly over the past decade. > lex being flex probably deserves move to contrib. So do you see any problem with the svn steps? Uli From owner-freebsd-arch@FreeBSD.ORG Sun Nov 7 21:59:21 2010 Return-Path: Delivered-To: arch@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 664) id 83A171065674; Sun, 7 Nov 2010 21:59:21 +0000 (UTC) Date: Sun, 7 Nov 2010 21:59:21 +0000 From: David O'Brien To: arch@freebsd.org Message-ID: <20101107215921.GA44360@hub.freebsd.org> References: <20101107141804.GN85693@acme.spoerlein.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101107141804.GN85693@acme.spoerlein.net> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 7.3-STABLE Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Cc: Subject: Re: Moving flex and yacc to contrib/, all hell breaks loose? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Nov 2010 21:59:21 -0000 On Sun, Nov 07, 2010 at 03:18:04PM +0100, Ulrich Sp??rlein wrote: > To my knowledge, the only "vendor" software in our tree, not yet living > under cddl/, contrib/, crypto/ or gnu/ are > > lib/libc/softfloat > lib/libz > lib/msun > usr.bin/lex > usr.bin/unifdef > usr.bin/yacc > > I'm not touching the lib parts for now, and for unifdef, see recent > post to current@. So flex and yacc remain (if you know of more sources > with an upstream development, not already listed on the Wiki under > http://wiki.freebsd.org/ContribSoftware please let me know!) > > I have an universe-surviving svn tree ready for commit, that moves flex > to contrib/flex and only a stub Makefile in usr.bin/lex remains, like we > do with all other contributed software. I personally don't see the need to move flex or yacc. Berkley was the original "vendor" for both of these so /usr/src/usr.bin is the correct place. We have 2.5.4 from 11-Sept-1996. Is there some planned update of flex? Ditto for YACC. I am aware of http://invisible-island.net/byacc/byacc.html, but I don't know that I would call Thomas Dickey the official new maintainer of byacc. So I'd prefer to just leave flex and yacc where they have been for 15 years as fingers know to type thost paths. I also note that all the UC Regents' copyrights have been stripped in byacc-20100610. -- -- David (obrien@FreeBSD.org) From owner-freebsd-arch@FreeBSD.ORG Sun Nov 7 22:04:22 2010 Return-Path: Delivered-To: arch@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 664) id 523691065673; Sun, 7 Nov 2010 22:04:22 +0000 (UTC) Date: Sun, 7 Nov 2010 22:04:22 +0000 From: David O'Brien To: Kostik Belousov , arch@freebsd.org Message-ID: <20101107220422.GB44360@hub.freebsd.org> References: <20101107141804.GN85693@acme.spoerlein.net> <20101107162542.GT2392@deviant.kiev.zoral.com.ua> <20101107213331.GQ85693@acme.spoerlein.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101107213331.GQ85693@acme.spoerlein.net> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 7.3-STABLE Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Cc: Subject: Re: Moving flex and yacc to contrib/, all hell breaks loose? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Nov 2010 22:04:22 -0000 On Sun, Nov 07, 2010 at 10:33:31PM +0100, Ulrich Sp??rlein wrote: > See the wiki page, it will point you to > http://invisible-island.net/byacc/byacc.html > where Thomas Dickey has been updating byacc regularly over the past > decade. I just did a diff of /usr/src/usr.bin/yacc and byacc-20100610. The changes aren't that large (when ignoring the deleted copyrights and the code style changes (going away from, not to KNF). I think we should just grab any good changes and leave yacc where it is. > > lex being flex probably deserves move to contrib. > > So do you see any problem with the svn steps? Yes. Do NOT delete svn:mergeinfo properties. (if you were to do the steps you noted) -- -- David (obrien@FreeBSD.org) From owner-freebsd-arch@FreeBSD.ORG Sun Nov 7 22:19:11 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61A76106566C; Sun, 7 Nov 2010 22:19:11 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id B581E8FC0A; Sun, 7 Nov 2010 22:19:10 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id oA7MJ627013437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Nov 2010 00:19:06 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id oA7MJ6UP084924; Mon, 8 Nov 2010 00:19:06 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id oA7MJ6BU084923; Mon, 8 Nov 2010 00:19:06 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 8 Nov 2010 00:19:06 +0200 From: Kostik Belousov To: "David O'Brien" Message-ID: <20101107221906.GZ2392@deviant.kiev.zoral.com.ua> References: <20101107141804.GN85693@acme.spoerlein.net> <20101107215921.GA44360@hub.freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kTLCetkqbH+B3E5g" Content-Disposition: inline In-Reply-To: <20101107215921.GA44360@hub.freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_05, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: arch@freebsd.org Subject: Re: Moving flex and yacc to contrib/, all hell breaks loose? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Nov 2010 22:19:11 -0000 --kTLCetkqbH+B3E5g Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Nov 07, 2010 at 09:59:21PM +0000, David O'Brien wrote: > On Sun, Nov 07, 2010 at 03:18:04PM +0100, Ulrich Sp??rlein wrote: > > To my knowledge, the only "vendor" software in our tree, not yet living > > under cddl/, contrib/, crypto/ or gnu/ are > >=20 > > lib/libc/softfloat > > lib/libz > > lib/msun > > usr.bin/lex > > usr.bin/unifdef > > usr.bin/yacc > >=20 > > I'm not touching the lib parts for now, and for unifdef, see recent > > post to current@. So flex and yacc remain (if you know of more sources > > with an upstream development, not already listed on the Wiki under > > http://wiki.freebsd.org/ContribSoftware please let me know!) > >=20 > > I have an universe-surviving svn tree ready for commit, that moves flex > > to contrib/flex and only a stub Makefile in usr.bin/lex remains, like we > > do with all other contributed software. >=20 > I personally don't see the need to move flex or yacc. > Berkley was the original "vendor" for both of these so /usr/src/usr.bin > is the correct place. >=20 > We have 2.5.4 from 11-Sept-1996. Is there some planned update of flex? See http://flex.sourceforge.net/ Latest release is 2.3.35 from 2008, it seems. I do know about software that indeed requires newer flex then what is in our tree. > Ditto for YACC. >=20 > I am aware of http://invisible-island.net/byacc/byacc.html, but I don't > know that I would call Thomas Dickey the official new maintainer of byacc. I share you sentiments there. With all respect to the ncurses and xterm maintainer, it is not obvious that we must import byacc instead of keeping our yacc, with possible incremental improvements. >=20 > So I'd prefer to just leave flex and yacc where they have been for > 15 years as fingers know to type thost paths. >=20 > I also note that all the UC Regents' copyrights have been stripped in > byacc-20100610. >=20 > --=20 > -- David (obrien@FreeBSD.org) > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" --kTLCetkqbH+B3E5g Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAkzXJdoACgkQC3+MBN1Mb4htKgCgrA9fkAy6lIuI/a0atEN2DZvk m58AoJUa0sFwQTNVpzvhnqokAG2MctKZ =0/vi -----END PGP SIGNATURE----- --kTLCetkqbH+B3E5g-- From owner-freebsd-arch@FreeBSD.ORG Mon Nov 8 07:49:36 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB792106564A for ; Mon, 8 Nov 2010 07:49:36 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 815C88FC14 for ; Mon, 8 Nov 2010 07:49:36 +0000 (UTC) Received: by iwn39 with SMTP id 39so5782141iwn.13 for ; Sun, 07 Nov 2010 23:49:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; bh=yhJkegPC/NxOkbjgm9Y+WGEA4XK20xVKlBTzo3jneDA=; b=boSkIS0jx74y7ZnhVidKeIeZj1khxEahoAcvkoi45r6qXvLorkH9midePYuVyCLr3z mflyOjyihMz7sVdpS35HiI2izfaWgpz6HBr+BaJh6LLDVy5NedqsMo7W9MIs5tPkAqlf VIRHKd01XzONCSITlljYyhbJURBYJoip0CaKc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=xyBBpFsZvkyu+vcw8zMIVbkLzTuiCLCC9MPTd9wvVw1k/29QEpPMjkVYkRpnwTlkqU KHFURH482azja086aWmThWbZ6EzFDFzh99wre44jY+GPcKSEp+zFX+t1m2YvM7bSreh7 y84ySetXIkhKXHwpNApsBkiBH3paE8gJOOOuo= MIME-Version: 1.0 Received: by 10.42.180.131 with SMTP id bu3mr3527887icb.129.1289200704212; Sun, 07 Nov 2010 23:18:24 -0800 (PST) Sender: baptiste.daroussin@gmail.com Received: by 10.231.69.212 with HTTP; Sun, 7 Nov 2010 23:18:24 -0800 (PST) In-Reply-To: <20101107141804.GN85693@acme.spoerlein.net> References: <20101107141804.GN85693@acme.spoerlein.net> Date: Mon, 8 Nov 2010 07:18:24 +0000 X-Google-Sender-Auth: 8B-4VDGkenCM-nqGZkzjxkP8l8o Message-ID: From: Baptiste Daroussin To: arch@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: Moving flex and yacc to contrib/, all hell breaks loose? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2010 07:49:36 -0000 2010/11/7 Ulrich Sp=F6rlein : > Hoi, > > To my knowledge, the only "vendor" software in our tree, not yet living > under cddl/, contrib/, crypto/ or gnu/ are > > lib/libc/softfloat > lib/libz > lib/msun > usr.bin/lex > usr.bin/unifdef > usr.bin/yacc > > I'm not touching the lib parts for now, and for unifdef, see recent > post to current@. So flex and yacc remain (if you know of more sources > with an upstream development, not already listed on the Wiki under > http://wiki.freebsd.org/ContribSoftware please let me know!) > there are also lib/libedit and usr.sbin/makefs that are maintained by NetBS= D. for both of them an upgrade is coming :). regards, bapt From owner-freebsd-arch@FreeBSD.ORG Mon Nov 8 13:47:32 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40A93106566C for ; Mon, 8 Nov 2010 13:47:32 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 00D7B8FC1B for ; Mon, 8 Nov 2010 13:47:31 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 1328C1FFC34 for ; Mon, 8 Nov 2010 13:28:33 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id DBF7A8452F; Mon, 8 Nov 2010 14:28:32 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: arch@freebsd.org References: <20101107141804.GN85693@acme.spoerlein.net> Date: Mon, 08 Nov 2010 14:28:32 +0100 In-Reply-To: <20101107141804.GN85693@acme.spoerlein.net> ("Ulrich =?utf-8?Q?Sp=C3=B6rlein=22's?= message of "Sun, 7 Nov 2010 15:18:04 +0100") Message-ID: <86eiaw0wsf.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: Moving flex and yacc to contrib/, all hell breaks loose? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2010 13:47:32 -0000 Ulrich Sp=C3=B6rlein writes: > To my knowledge, the only "vendor" software in our tree, not yet living > under cddl/, contrib/, crypto/ or gnu/ are > > lib/libc/softfloat > lib/libz > lib/msun > usr.bin/lex > usr.bin/unifdef > usr.bin/yacc I have no opinion on the others, but AFAIK, msun is a mix of unmodified third-party code, locally modified third-party code and locally developed code (which is how my name ended up in the Android credits), and I'm not sure there still is a third-party maintainer for our version of msun. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Mon Nov 8 15:05:08 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0791510656B8; Mon, 8 Nov 2010 15:05:07 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id B8C628FC20; Mon, 8 Nov 2010 15:05:07 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 5C93546B3B; Mon, 8 Nov 2010 10:05:07 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 41E2A8A009; Mon, 8 Nov 2010 10:05:06 -0500 (EST) From: John Baldwin To: Matthew Fleming Date: Mon, 8 Nov 2010 09:47:00 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> <201011061522.26533.hselasky@c2i.net> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011080947.00550.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 08 Nov 2010 10:05:06 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: freebsd-usb@freebsd.org, Weongyo Jeong , freebsd-current@freebsd.org, Andrew Thompson , freebsd-arch@freebsd.org, Hans Petter Selasky Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2010 15:05:08 -0000 On Saturday, November 06, 2010 4:33:17 pm Matthew Fleming wrote: > On Sat, Nov 6, 2010 at 7:22 AM, Hans Petter Selasky wrote: > > Hi, > > > > On Saturday 06 November 2010 14:57:50 Matthew Fleming wrote: > >> > >> I think you're misunderstanding the existing taskqueue(9) implementation. > >> > >> As long as TQ_LOCK is held, the state of ta->ta_pending cannot change, > >> nor can the set of running tasks. So the order of checks is > >> irrelevant. > > > > I agree that the order of checks is not important. That is not the problem. > > > > Cut & paste from suggested taskqueue patch from Fleming: > > > > > +int > >> > +taskqueue_cancel(struct taskqueue *queue, struct task *task) > >> > +{ > >> > + int rc; > >> > + > >> > + TQ_LOCK(queue); > >> > + if (!task_is_running(queue, task)) { > >> > + if ((rc = task->ta_pending) > 0) > >> > + STAILQ_REMOVE(&queue->tq_queue, task, task, > >> > ta_link); + task->ta_pending = 0; > >> > + } else { > >> > + rc = -EBUSY; > > > > What happens in this case if ta_pending > 0. Are you saying this is not > > possible? If ta_pending > 0, shouldn't we also do a STAILQ_REMOVE() ? > > Ah! I see what you mean. > > I'm not quite sure what the best thing to do here is; I agree it would > be nice if taskqueue_cancel(9) dequeued the task, but I believe it > also needs to indicate that the task is currently running. I guess > the best thing would be to return the old pending count by reference > parameter, and 0 or EBUSY to also indicate if there is a task > currently running. > > Adding jhb@ to this mail since he has good thoughts on interfacing. I agree we should always dequeue when possible. I think it should return -EBUSY in that case. That way code that uses 'cancel' followed by a conditional 'drain' to implement a blocking 'cancel' will DTRT. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Mon Nov 8 15:21:54 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CCE751065670 for ; Mon, 8 Nov 2010 15:21:54 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 83AF28FC19 for ; Mon, 8 Nov 2010 15:21:54 +0000 (UTC) Received: by ywh2 with SMTP id 2so3611870ywh.13 for ; Mon, 08 Nov 2010 07:21:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=j7LNfaRpmZWZN/a9BOHl1WDFqcaz+co8vtcWNxjvWwA=; b=MPIBDELihJRhYtRGJgQzaWdcmFspl0U+A05x7+rv0SWF1hD0SMzcdVLBd0DZs5zueK FFyqYHRWAzyX9TTwPgnnPF1Mws3uWvRTXTcULqOOlrqqKkBnA4v4szEFrmzeNfp66FrR OERuiwQ0n9RzEHZZF0gowo7UNFsOudwWXFAH4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=F+1KFT1/Npqzbw4ax+tBgKE/4mgijes1pyVBnbHeX+KFXDlMwTuROL1JwG2yduz0Sm N3xa6o6ssL2bdS6w9qsD/pJ70e6vNLq+7n1n6G6yM+SOLXp/O80desr3kYDzwkILj37t aGADF3H6UpNkaVIvXP0/671qtlzRidCLy8tEI= MIME-Version: 1.0 Received: by 10.42.197.72 with SMTP id ej8mr3717679icb.196.1289229713671; Mon, 08 Nov 2010 07:21:53 -0800 (PST) Sender: baptiste.daroussin@gmail.com Received: by 10.231.69.212 with HTTP; Mon, 8 Nov 2010 07:21:53 -0800 (PST) In-Reply-To: <86vd4ao5o4.fsf@gmail.com> References: <20101106120752.001e92c0@ernst.jennejohn.org> <86vd4ao5o4.fsf@gmail.com> Date: Mon, 8 Nov 2010 16:21:53 +0100 X-Google-Sender-Auth: JQBBGr_nVZTY7ihOzOvJgMXY1x0 Message-ID: From: Baptiste Daroussin To: Anonymous Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-arch@freebsd.org, gljennjohn@googlemail.com Subject: Re: [PATCH] update to the latest libedit version and remove libreadline deps X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2010 15:21:54 -0000 Hi all, I have updated the patch that update libedit, respecting all your remarks. http://people.freebsd.org/~bapt/update-libedit.patch Normally most of our improvements (for bin/sh) are back in the patch, as far as I can test sh works great. I also make libedit install readline/tilde.h and readline/history.h as a symlink on readline/readline.h to avoid patching too much things, now only Makefile and gvinum.c needs patching. for gvinum we only need to add string.h. We also have to think a way to update ports to use devel/readline before breaking lot's of them removing libreadline from base. But I have no idea is there are good procedures for that purpose. regards, Bapt From owner-freebsd-arch@FreeBSD.ORG Mon Nov 8 15:34:35 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E85741065670; Mon, 8 Nov 2010 15:34:34 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7467B8FC18; Mon, 8 Nov 2010 15:34:34 +0000 (UTC) Received: by iwn39 with SMTP id 39so6226556iwn.13 for ; Mon, 08 Nov 2010 07:34:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Q3Yh+Akq1iSym1e61foxgBYYRwPfKywY/6SkwmPImWI=; b=ITcUReiQ1Qq6+npAlu+MYy/C+tV+7hfn9dJFlXSRAgcVYAL6htMDDzjvdP9FBOyCJ3 xqHXQmmg3dZTLffKV2XfMU4aS7YJ0rveLpzy1waUIieiU81hiIUcDvvaoep+vLqDqmsm bSKPQAB0xnd504G9JKn3MLrWA7alfB9GXieq0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=jz8/c6Ax+rXemiy3JRzfAya/R4KsAa/5OBWvkkJi0BUWqPqB+qkt78OocoYx//nSja TsKH6qhsaLl/2Pn6fGTLavzGBkQgub1do2HzdV5WikYJGCr8Gn7fEC1yAFZNvJU0E1dP 74SnrgWFZpxa8AfXuMvNqW4Fzf8Rnx12vmt70= MIME-Version: 1.0 Received: by 10.231.156.139 with SMTP id x11mr4170511ibw.22.1289230473154; Mon, 08 Nov 2010 07:34:33 -0800 (PST) Received: by 10.231.21.35 with HTTP; Mon, 8 Nov 2010 07:34:33 -0800 (PST) In-Reply-To: <201011080947.00550.jhb@freebsd.org> References: <201011012054.59551.hselasky@c2i.net> <201011061522.26533.hselasky@c2i.net> <201011080947.00550.jhb@freebsd.org> Date: Mon, 8 Nov 2010 07:34:33 -0800 Message-ID: From: Matthew Fleming To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-usb@freebsd.org, Weongyo Jeong , freebsd-current@freebsd.org, Andrew Thompson , freebsd-arch@freebsd.org, Hans Petter Selasky Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2010 15:34:35 -0000 On Mon, Nov 8, 2010 at 6:47 AM, John Baldwin wrote: > On Saturday, November 06, 2010 4:33:17 pm Matthew Fleming wrote: >> On Sat, Nov 6, 2010 at 7:22 AM, Hans Petter Selasky w= rote: >> > Hi, >> > >> > On Saturday 06 November 2010 14:57:50 Matthew Fleming wrote: >> >> >> >> I think you're misunderstanding the existing taskqueue(9) implementat= ion. >> >> >> >> As long as TQ_LOCK is held, the state of ta->ta_pending cannot change= , >> >> nor can the set of running tasks. =A0So the order of checks is >> >> irrelevant. >> > >> > I agree that the order of checks is not important. That is not the pro= blem. >> > >> > Cut & paste from suggested taskqueue patch from Fleming: >> > >> > =A0> +int >> >> > +taskqueue_cancel(struct taskqueue *queue, struct task *task) >> >> > +{ >> >> > + =A0 =A0 =A0 int rc; >> >> > + >> >> > + =A0 =A0 =A0 TQ_LOCK(queue); >> >> > + =A0 =A0 =A0 if (!task_is_running(queue, task)) { >> >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if ((rc =3D task->ta_pending) > 0) >> >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 STAILQ_REMOVE(&queue-= >tq_queue, task, task, >> >> > ta_link); + =A0 =A0 =A0 =A0 =A0 =A0 =A0 task->ta_pending =3D 0; >> >> > + =A0 =A0 =A0 } else { >> >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 rc =3D -EBUSY; >> > >> > What happens in this case if ta_pending > 0. Are you saying this is no= t >> > possible? If ta_pending > 0, shouldn't we also do a STAILQ_REMOVE() ? >> >> Ah! =A0I see what you mean. >> >> I'm not quite sure what the best thing to do here is; I agree it would >> be nice if taskqueue_cancel(9) dequeued the task, but I believe it >> also needs to indicate that the task is currently running. =A0I guess >> the best thing would be to return the old pending count by reference >> parameter, and 0 or EBUSY to also indicate if there is a task >> currently running. >> >> Adding jhb@ to this mail since he has good thoughts on interfacing. > > I agree we should always dequeue when possible. =A0I think it should retu= rn > -EBUSY in that case. =A0That way code that uses 'cancel' followed by a > conditional 'drain' to implement a blocking 'cancel' will DTRT. Do we not also want the old ta_pending to be returned? In the case where a task is pending and is also currently running (admittedly a narrow window), how would we do this? This is why I suggested returning the old ta_pending by reference. This also allows callers who don't care about the old pending to pass NULL and ignore it. Thanks, matthew From owner-freebsd-arch@FreeBSD.ORG Mon Nov 8 16:44:11 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DFFAB106564A; Mon, 8 Nov 2010 16:44:10 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 9BB2D8FC0C; Mon, 8 Nov 2010 16:44:10 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 1250E46B35; Mon, 8 Nov 2010 11:44:10 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 0F2B58A009; Mon, 8 Nov 2010 11:44:09 -0500 (EST) From: John Baldwin To: Matthew Fleming Date: Mon, 8 Nov 2010 11:42:45 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> <201011080947.00550.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011081142.46175.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 08 Nov 2010 11:44:09 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: freebsd-usb@freebsd.org, Weongyo Jeong , freebsd-current@freebsd.org, Andrew Thompson , freebsd-arch@freebsd.org, Hans Petter Selasky Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2010 16:44:11 -0000 On Monday, November 08, 2010 10:34:33 am Matthew Fleming wrote: > On Mon, Nov 8, 2010 at 6:47 AM, John Baldwin wrote: > > On Saturday, November 06, 2010 4:33:17 pm Matthew Fleming wrote: > >> On Sat, Nov 6, 2010 at 7:22 AM, Hans Petter Selasky wrote: > >> > Hi, > >> > > >> > On Saturday 06 November 2010 14:57:50 Matthew Fleming wrote: > >> >> > >> >> I think you're misunderstanding the existing taskqueue(9) implementation. > >> >> > >> >> As long as TQ_LOCK is held, the state of ta->ta_pending cannot change, > >> >> nor can the set of running tasks. So the order of checks is > >> >> irrelevant. > >> > > >> > I agree that the order of checks is not important. That is not the problem. > >> > > >> > Cut & paste from suggested taskqueue patch from Fleming: > >> > > >> > > +int > >> >> > +taskqueue_cancel(struct taskqueue *queue, struct task *task) > >> >> > +{ > >> >> > + int rc; > >> >> > + > >> >> > + TQ_LOCK(queue); > >> >> > + if (!task_is_running(queue, task)) { > >> >> > + if ((rc = task->ta_pending) > 0) > >> >> > + STAILQ_REMOVE(&queue->tq_queue, task, task, > >> >> > ta_link); + task->ta_pending = 0; > >> >> > + } else { > >> >> > + rc = -EBUSY; > >> > > >> > What happens in this case if ta_pending > 0. Are you saying this is not > >> > possible? If ta_pending > 0, shouldn't we also do a STAILQ_REMOVE() ? > >> > >> Ah! I see what you mean. > >> > >> I'm not quite sure what the best thing to do here is; I agree it would > >> be nice if taskqueue_cancel(9) dequeued the task, but I believe it > >> also needs to indicate that the task is currently running. I guess > >> the best thing would be to return the old pending count by reference > >> parameter, and 0 or EBUSY to also indicate if there is a task > >> currently running. > >> > >> Adding jhb@ to this mail since he has good thoughts on interfacing. > > > > I agree we should always dequeue when possible. I think it should return > > -EBUSY in that case. That way code that uses 'cancel' followed by a > > conditional 'drain' to implement a blocking 'cancel' will DTRT. > > Do we not also want the old ta_pending to be returned? In the case > where a task is pending and is also currently running (admittedly a > narrow window), how would we do this? This is why I suggested > returning the old ta_pending by reference. This also allows callers > who don't care about the old pending to pass NULL and ignore it. I would be fine with that then. I wonder if taskqueue_cancel() could then return a simple true/false. False if the task is running, and true otherwise? -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Mon Nov 8 16:47:00 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F257B1065679; Mon, 8 Nov 2010 16:46:59 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7E09E8FC14; Mon, 8 Nov 2010 16:46:59 +0000 (UTC) Received: by iwn39 with SMTP id 39so6296735iwn.13 for ; Mon, 08 Nov 2010 08:46:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=bJjeFYGl3fy966B8YB3YJqHzPhP3c+Lix7MzG1/+ZQE=; b=Q4ITzcxHFehpXE+t+L3Lrpu9hqpxX/QIO5DlGo5llXPWNUHtaQUv5Pqtp5s3DE9SKL vP+Mbr65IcOTsMJfFTzn2pBzXwvQM3CraXfenp4idurSIhxDYcNXx4qdrvFixvZuti0x TaCvMMKPd2xNYSVom4M3k7y8Jp9KCq6YKHVbk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=PsxCwpO9RlRHD4yuEXIVTVVCxXH1hig2ucu667KKJbuujS9K4jhltW4i4xLM7lx91H 7Y+N71MIHJQdAhtqiwQpZ7ohASnvPHhSD3CZ2Mxt2IJx9CEdhq8FHTOq4c3TmaRBmnLn HJxaRqiz4ggpL9v0k5+imkOl5RRjkWM2P3ywc= MIME-Version: 1.0 Received: by 10.231.192.73 with SMTP id dp9mr4239441ibb.72.1289234818843; Mon, 08 Nov 2010 08:46:58 -0800 (PST) Received: by 10.231.21.35 with HTTP; Mon, 8 Nov 2010 08:46:58 -0800 (PST) In-Reply-To: <201011081142.46175.jhb@freebsd.org> References: <201011012054.59551.hselasky@c2i.net> <201011080947.00550.jhb@freebsd.org> <201011081142.46175.jhb@freebsd.org> Date: Mon, 8 Nov 2010 08:46:58 -0800 Message-ID: From: Matthew Fleming To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-usb@freebsd.org, Weongyo Jeong , freebsd-current@freebsd.org, Andrew Thompson , freebsd-arch@freebsd.org, Hans Petter Selasky Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2010 16:47:00 -0000 On Mon, Nov 8, 2010 at 8:42 AM, John Baldwin wrote: > On Monday, November 08, 2010 10:34:33 am Matthew Fleming wrote: >> On Mon, Nov 8, 2010 at 6:47 AM, John Baldwin wrote: >> > On Saturday, November 06, 2010 4:33:17 pm Matthew Fleming wrote: >> >> On Sat, Nov 6, 2010 at 7:22 AM, Hans Petter Selasky wrote: >> >> > Hi, >> >> > >> >> > On Saturday 06 November 2010 14:57:50 Matthew Fleming wrote: >> >> >> >> >> >> I think you're misunderstanding the existing taskqueue(9) implemen= tation. >> >> >> >> >> >> As long as TQ_LOCK is held, the state of ta->ta_pending cannot cha= nge, >> >> >> nor can the set of running tasks. =A0So the order of checks is >> >> >> irrelevant. >> >> > >> >> > I agree that the order of checks is not important. That is not the = problem. >> >> > >> >> > Cut & paste from suggested taskqueue patch from Fleming: >> >> > >> >> > =A0> +int >> >> >> > +taskqueue_cancel(struct taskqueue *queue, struct task *task) >> >> >> > +{ >> >> >> > + =A0 =A0 =A0 int rc; >> >> >> > + >> >> >> > + =A0 =A0 =A0 TQ_LOCK(queue); >> >> >> > + =A0 =A0 =A0 if (!task_is_running(queue, task)) { >> >> >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if ((rc =3D task->ta_pending) > 0) >> >> >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 STAILQ_REMOVE(&que= ue->tq_queue, task, task, >> >> >> > ta_link); + =A0 =A0 =A0 =A0 =A0 =A0 =A0 task->ta_pending =3D 0; >> >> >> > + =A0 =A0 =A0 } else { >> >> >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 rc =3D -EBUSY; >> >> > >> >> > What happens in this case if ta_pending > 0. Are you saying this is= not >> >> > possible? If ta_pending > 0, shouldn't we also do a STAILQ_REMOVE()= ? >> >> >> >> Ah! =A0I see what you mean. >> >> >> >> I'm not quite sure what the best thing to do here is; I agree it woul= d >> >> be nice if taskqueue_cancel(9) dequeued the task, but I believe it >> >> also needs to indicate that the task is currently running. =A0I guess >> >> the best thing would be to return the old pending count by reference >> >> parameter, and 0 or EBUSY to also indicate if there is a task >> >> currently running. >> >> >> >> Adding jhb@ to this mail since he has good thoughts on interfacing. >> > >> > I agree we should always dequeue when possible. =A0I think it should r= eturn >> > -EBUSY in that case. =A0That way code that uses 'cancel' followed by a >> > conditional 'drain' to implement a blocking 'cancel' will DTRT. >> >> Do we not also want the old ta_pending to be returned? =A0In the case >> where a task is pending and is also currently running (admittedly a >> narrow window), how would we do this? =A0This is why I suggested >> returning the old ta_pending by reference. =A0This also allows callers >> who don't care about the old pending to pass NULL and ignore it. > > I would be fine with that then. =A0I wonder if taskqueue_cancel() could t= hen > return a simple true/false. =A0False if the task is running, and true > otherwise? Sure, though since we don't really have a bool type in the kernel I'd still prefer to return an int with EBUSY meaning a task was running. Thanks, matthew From owner-freebsd-arch@FreeBSD.ORG Mon Nov 8 17:04:57 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB2A1106564A; Mon, 8 Nov 2010 17:04:57 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8D7E58FC1D; Mon, 8 Nov 2010 17:04:57 +0000 (UTC) Received: by pxi1 with SMTP id 1so1067896pxi.13 for ; Mon, 08 Nov 2010 09:04:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=IMsU0iLLKZy4M0mTial+VDi0L/cNT9Zi3iPWW1QsgJc=; b=mr1oWxGvvUW4yJDDLgR1FTgfiNfmsZZO5/JshKAkYGPblZxo9Zh9pXHkbl6sO5PVQs W0X1RjaDdHGz1RU43pKvaoK+Ym+TRLUXRcc2Dv7L+sKC275FLOAj/zfHoDvbXuhYpsOY oFiNTLGs3AitH1hnF1Yk2MqyOYSQDsrB7Y+RU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=g4PxTTL5VgTQMgwcSJvjADKX5bDc51bPhxWMGxrUx1Gh4dOQFiBRF/vxURoaKE+SWa cCewxnWVoopAgRLU9tK143nQSPCGGnnxDMM4Dpk9d8u9cHlQBkokJXcOkgScFPbKd3cx GLaIJHlxl1ASC8uhDKuR2wuKjvIJ8yTkpaXKo= MIME-Version: 1.0 Received: by 10.42.165.200 with SMTP id l8mr2253305icy.326.1289235894985; Mon, 08 Nov 2010 09:04:54 -0800 (PST) Received: by 10.231.21.35 with HTTP; Mon, 8 Nov 2010 09:04:54 -0800 (PST) In-Reply-To: References: <201011012054.59551.hselasky@c2i.net> <201011080947.00550.jhb@freebsd.org> <201011081142.46175.jhb@freebsd.org> Date: Mon, 8 Nov 2010 09:04:54 -0800 Message-ID: From: Matthew Fleming To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-usb@freebsd.org, Weongyo Jeong , freebsd-current@freebsd.org, Andrew Thompson , freebsd-arch@freebsd.org, Hans Petter Selasky Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2010 17:04:58 -0000 On Mon, Nov 8, 2010 at 8:46 AM, Matthew Fleming wrote: > On Mon, Nov 8, 2010 at 8:42 AM, John Baldwin wrote: >> On Monday, November 08, 2010 10:34:33 am Matthew Fleming wrote: >>> On Mon, Nov 8, 2010 at 6:47 AM, John Baldwin wrote: >>> > On Saturday, November 06, 2010 4:33:17 pm Matthew Fleming wrote: >>> >> On Sat, Nov 6, 2010 at 7:22 AM, Hans Petter Selasky wrote: >>> >> > Hi, >>> >> > >>> >> > On Saturday 06 November 2010 14:57:50 Matthew Fleming wrote: >>> >> >> >>> >> >> I think you're misunderstanding the existing taskqueue(9) impleme= ntation. >>> >> >> >>> >> >> As long as TQ_LOCK is held, the state of ta->ta_pending cannot ch= ange, >>> >> >> nor can the set of running tasks. =A0So the order of checks is >>> >> >> irrelevant. >>> >> > >>> >> > I agree that the order of checks is not important. That is not the= problem. >>> >> > >>> >> > Cut & paste from suggested taskqueue patch from Fleming: >>> >> > >>> >> > =A0> +int >>> >> >> > +taskqueue_cancel(struct taskqueue *queue, struct task *task) >>> >> >> > +{ >>> >> >> > + =A0 =A0 =A0 int rc; >>> >> >> > + >>> >> >> > + =A0 =A0 =A0 TQ_LOCK(queue); >>> >> >> > + =A0 =A0 =A0 if (!task_is_running(queue, task)) { >>> >> >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if ((rc =3D task->ta_pending) > 0= ) >>> >> >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 STAILQ_REMOVE(&qu= eue->tq_queue, task, task, >>> >> >> > ta_link); + =A0 =A0 =A0 =A0 =A0 =A0 =A0 task->ta_pending =3D 0; >>> >> >> > + =A0 =A0 =A0 } else { >>> >> >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 rc =3D -EBUSY; >>> >> > >>> >> > What happens in this case if ta_pending > 0. Are you saying this i= s not >>> >> > possible? If ta_pending > 0, shouldn't we also do a STAILQ_REMOVE(= ) ? >>> >> >>> >> Ah! =A0I see what you mean. >>> >> >>> >> I'm not quite sure what the best thing to do here is; I agree it wou= ld >>> >> be nice if taskqueue_cancel(9) dequeued the task, but I believe it >>> >> also needs to indicate that the task is currently running. =A0I gues= s >>> >> the best thing would be to return the old pending count by reference >>> >> parameter, and 0 or EBUSY to also indicate if there is a task >>> >> currently running. >>> >> >>> >> Adding jhb@ to this mail since he has good thoughts on interfacing. >>> > >>> > I agree we should always dequeue when possible. =A0I think it should = return >>> > -EBUSY in that case. =A0That way code that uses 'cancel' followed by = a >>> > conditional 'drain' to implement a blocking 'cancel' will DTRT. >>> >>> Do we not also want the old ta_pending to be returned? =A0In the case >>> where a task is pending and is also currently running (admittedly a >>> narrow window), how would we do this? =A0This is why I suggested >>> returning the old ta_pending by reference. =A0This also allows callers >>> who don't care about the old pending to pass NULL and ignore it. >> >> I would be fine with that then. =A0I wonder if taskqueue_cancel() could = then >> return a simple true/false. =A0False if the task is running, and true >> otherwise? > > Sure, though since we don't really have a bool type in the kernel I'd > still prefer to return an int with EBUSY meaning a task was running. I'll commit this later today unless there are objections. http://people.freebsd.org/~mdf/0001-Add-a-taskqueue_cancel-9-to-cancel-a-pe= nding-task-wi.patch Thanks, matthew From owner-freebsd-arch@FreeBSD.ORG Mon Nov 8 18:25:00 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D52F2106564A; Mon, 8 Nov 2010 18:25:00 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 88E508FC16; Mon, 8 Nov 2010 18:25:00 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id DC04A46B3B; Mon, 8 Nov 2010 13:24:59 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 954D48A01D; Mon, 8 Nov 2010 13:24:58 -0500 (EST) From: John Baldwin To: Matthew Fleming Date: Mon, 8 Nov 2010 13:24:05 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> <201011081142.46175.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011081324.05514.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 08 Nov 2010 13:24:58 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: freebsd-usb@freebsd.org, Weongyo Jeong , freebsd-current@freebsd.org, Andrew Thompson , freebsd-arch@freebsd.org, Hans Petter Selasky Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2010 18:25:01 -0000 On Monday, November 08, 2010 11:46:58 am Matthew Fleming wrote: > On Mon, Nov 8, 2010 at 8:42 AM, John Baldwin wrote: > > On Monday, November 08, 2010 10:34:33 am Matthew Fleming wrote: > >> On Mon, Nov 8, 2010 at 6:47 AM, John Baldwin wrote: > >> > On Saturday, November 06, 2010 4:33:17 pm Matthew Fleming wrote: > >> >> On Sat, Nov 6, 2010 at 7:22 AM, Hans Petter Selasky wrote: > >> >> > Hi, > >> >> > > >> >> > On Saturday 06 November 2010 14:57:50 Matthew Fleming wrote: > >> >> >> > >> >> >> I think you're misunderstanding the existing taskqueue(9) implementation. > >> >> >> > >> >> >> As long as TQ_LOCK is held, the state of ta->ta_pending cannot change, > >> >> >> nor can the set of running tasks. So the order of checks is > >> >> >> irrelevant. > >> >> > > >> >> > I agree that the order of checks is not important. That is not the problem. > >> >> > > >> >> > Cut & paste from suggested taskqueue patch from Fleming: > >> >> > > >> >> > > +int > >> >> >> > +taskqueue_cancel(struct taskqueue *queue, struct task *task) > >> >> >> > +{ > >> >> >> > + int rc; > >> >> >> > + > >> >> >> > + TQ_LOCK(queue); > >> >> >> > + if (!task_is_running(queue, task)) { > >> >> >> > + if ((rc = task->ta_pending) > 0) > >> >> >> > + STAILQ_REMOVE(&queue->tq_queue, task, task, > >> >> >> > ta_link); + task->ta_pending = 0; > >> >> >> > + } else { > >> >> >> > + rc = -EBUSY; > >> >> > > >> >> > What happens in this case if ta_pending > 0. Are you saying this is not > >> >> > possible? If ta_pending > 0, shouldn't we also do a STAILQ_REMOVE() ? > >> >> > >> >> Ah! I see what you mean. > >> >> > >> >> I'm not quite sure what the best thing to do here is; I agree it would > >> >> be nice if taskqueue_cancel(9) dequeued the task, but I believe it > >> >> also needs to indicate that the task is currently running. I guess > >> >> the best thing would be to return the old pending count by reference > >> >> parameter, and 0 or EBUSY to also indicate if there is a task > >> >> currently running. > >> >> > >> >> Adding jhb@ to this mail since he has good thoughts on interfacing. > >> > > >> > I agree we should always dequeue when possible. I think it should return > >> > -EBUSY in that case. That way code that uses 'cancel' followed by a > >> > conditional 'drain' to implement a blocking 'cancel' will DTRT. > >> > >> Do we not also want the old ta_pending to be returned? In the case > >> where a task is pending and is also currently running (admittedly a > >> narrow window), how would we do this? This is why I suggested > >> returning the old ta_pending by reference. This also allows callers > >> who don't care about the old pending to pass NULL and ignore it. > > > > I would be fine with that then. I wonder if taskqueue_cancel() could then > > return a simple true/false. False if the task is running, and true > > otherwise? > > Sure, though since we don't really have a bool type in the kernel I'd > still prefer to return an int with EBUSY meaning a task was running. The only reason I would prefer the other sense (false if already running) is that is what callout_stop()'s return value is (true if it "stopped" the callout, false if it couldn't stop it)). However, returning EBUSY is ok. One difference is that callout_stop() returns false if the callout is not pending (i.e. not on softclock). Right now taskqueue_cancel() returns 0 in that case (ta_pending == 0), but that is probably fine as long as it is documented. If you wanted to return EINVAL instead, that would be fine, too. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Mon Nov 8 20:37:08 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 473841065672; Mon, 8 Nov 2010 20:37:08 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id C93C28FC24; Mon, 8 Nov 2010 20:37:07 +0000 (UTC) Received: by iwn39 with SMTP id 39so6506949iwn.13 for ; Mon, 08 Nov 2010 12:37:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=I155nDbwEt9h3lLLqiGD6cPgOWFcZiWcgJYvp7RPhsU=; b=RkXnSGymT0weEJez7fPVi2VchCnFcI7CbVq/eXn+fjhtm2TwNQNJE9LwYX9AmxTk8V JpTBvsqdofAU37j2eysXW9lEXoslGeHilZ5TWAlcc1XIGL/7ehMbaA1vA9hl4daEnMsm gqWgXt+U+Tzk4J+3Lb8+U36e1HdDWdUuMpIwQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=W4z+VGmu0W515mdZi+6jYRIUdfkyVjgtTyHgm1out//T3IZkL/su7ShIJSFLDZuyMT YPPt9d/4Dmima9ji7r6BrcJ+HwADcYlx4f0xMgTyLdRFmB5+8rjWjM/oQol5ePxIJwu4 ck22MS1URXyF8oNtwYSSNJ5hIgB/rN1ic9QE0= MIME-Version: 1.0 Received: by 10.231.192.73 with SMTP id dp9mr4536957ibb.72.1289248626670; Mon, 08 Nov 2010 12:37:06 -0800 (PST) Received: by 10.231.21.35 with HTTP; Mon, 8 Nov 2010 12:37:06 -0800 (PST) In-Reply-To: <201011081324.05514.jhb@freebsd.org> References: <201011012054.59551.hselasky@c2i.net> <201011081142.46175.jhb@freebsd.org> <201011081324.05514.jhb@freebsd.org> Date: Mon, 8 Nov 2010 12:37:06 -0800 Message-ID: From: Matthew Fleming To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-usb@freebsd.org, Weongyo Jeong , freebsd-current@freebsd.org, Andrew Thompson , freebsd-arch@freebsd.org, Hans Petter Selasky Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2010 20:37:08 -0000 On Mon, Nov 8, 2010 at 10:24 AM, John Baldwin wrote: > On Monday, November 08, 2010 11:46:58 am Matthew Fleming wrote: >> On Mon, Nov 8, 2010 at 8:42 AM, John Baldwin wrote: >> > On Monday, November 08, 2010 10:34:33 am Matthew Fleming wrote: >> >> On Mon, Nov 8, 2010 at 6:47 AM, John Baldwin wrote: >> >> > On Saturday, November 06, 2010 4:33:17 pm Matthew Fleming wrote: >> >> >> On Sat, Nov 6, 2010 at 7:22 AM, Hans Petter Selasky wrote: >> >> >> > Hi, >> >> >> > >> >> >> > On Saturday 06 November 2010 14:57:50 Matthew Fleming wrote: >> >> >> >> >> >> >> >> I think you're misunderstanding the existing taskqueue(9) imple= mentation. >> >> >> >> >> >> >> >> As long as TQ_LOCK is held, the state of ta->ta_pending cannot = change, >> >> >> >> nor can the set of running tasks. =A0So the order of checks is >> >> >> >> irrelevant. >> >> >> > >> >> >> > I agree that the order of checks is not important. That is not t= he problem. >> >> >> > >> >> >> > Cut & paste from suggested taskqueue patch from Fleming: >> >> >> > >> >> >> > =A0> +int >> >> >> >> > +taskqueue_cancel(struct taskqueue *queue, struct task *task) >> >> >> >> > +{ >> >> >> >> > + =A0 =A0 =A0 int rc; >> >> >> >> > + >> >> >> >> > + =A0 =A0 =A0 TQ_LOCK(queue); >> >> >> >> > + =A0 =A0 =A0 if (!task_is_running(queue, task)) { >> >> >> >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if ((rc =3D task->ta_pending) >= 0) >> >> >> >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 STAILQ_REMOVE(&= queue->tq_queue, task, task, >> >> >> >> > ta_link); + =A0 =A0 =A0 =A0 =A0 =A0 =A0 task->ta_pending =3D = 0; >> >> >> >> > + =A0 =A0 =A0 } else { >> >> >> >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 rc =3D -EBUSY; >> >> >> > >> >> >> > What happens in this case if ta_pending > 0. Are you saying this= is not >> >> >> > possible? If ta_pending > 0, shouldn't we also do a STAILQ_REMOV= E() ? >> >> >> >> >> >> Ah! =A0I see what you mean. >> >> >> >> >> >> I'm not quite sure what the best thing to do here is; I agree it w= ould >> >> >> be nice if taskqueue_cancel(9) dequeued the task, but I believe it >> >> >> also needs to indicate that the task is currently running. =A0I gu= ess >> >> >> the best thing would be to return the old pending count by referen= ce >> >> >> parameter, and 0 or EBUSY to also indicate if there is a task >> >> >> currently running. >> >> >> >> >> >> Adding jhb@ to this mail since he has good thoughts on interfacing= . >> >> > >> >> > I agree we should always dequeue when possible. =A0I think it shoul= d return >> >> > -EBUSY in that case. =A0That way code that uses 'cancel' followed b= y a >> >> > conditional 'drain' to implement a blocking 'cancel' will DTRT. >> >> >> >> Do we not also want the old ta_pending to be returned? =A0In the case >> >> where a task is pending and is also currently running (admittedly a >> >> narrow window), how would we do this? =A0This is why I suggested >> >> returning the old ta_pending by reference. =A0This also allows caller= s >> >> who don't care about the old pending to pass NULL and ignore it. >> > >> > I would be fine with that then. =A0I wonder if taskqueue_cancel() coul= d then >> > return a simple true/false. =A0False if the task is running, and true >> > otherwise? >> >> Sure, though since we don't really have a bool type in the kernel I'd >> still prefer to return an int with EBUSY meaning a task was running. > > The only reason I would prefer the other sense (false if already running) > is that is what callout_stop()'s return value is (true if it "stopped" th= e > callout, false if it couldn't stop it)). I think the symmetry with callout(9) can't go very far, mostly because callout generally takes a specified mtx before calling the callback, and taskqueue(9) does not. That means fundamentally that, when using a taskqueue(9) the consumer has much less knowledge of the exact state of a task. Thanks, matthew > However, returning EBUSY is ok. =A0One difference is that callout_stop() > returns false if the callout is not pending (i.e. not on softclock). =A0R= ight > now taskqueue_cancel() returns 0 in that case (ta_pending =3D=3D 0), but = that is > probably fine as long as it is documented. =A0If you wanted to return EIN= VAL > instead, that would be fine, too. > > -- > John Baldwin > From owner-freebsd-arch@FreeBSD.ORG Mon Nov 8 23:54:06 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 461B9106566B for ; Mon, 8 Nov 2010 23:54:06 +0000 (UTC) (envelope-from ade@FreeBSD.org) Received: from panix.lovett.com (panix.lovett.com [166.84.7.128]) by mx1.freebsd.org (Postfix) with ESMTP id 1BD658FC08 for ; Mon, 8 Nov 2010 23:54:05 +0000 (UTC) Received: from cpe-66-68-128-204.austin.res.rr.com ([66.68.128.204] helo=[172.16.32.150]) by panix.lovett.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PFb2n-0007Vb-2j; Mon, 08 Nov 2010 23:22:33 +0000 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Ade Lovett In-Reply-To: Date: Mon, 8 Nov 2010 17:22:20 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20101106120752.001e92c0@ernst.jennejohn.org> <86vd4ao5o4.fsf@gmail.com> To: Baptiste Daroussin X-Mailer: Apple Mail (2.1081) Cc: Anonymous , gljennjohn@googlemail.com, freebsd-arch@freebsd.org Subject: Re: [PATCH] update to the latest libedit version and remove libreadline deps X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2010 23:54:06 -0000 On Nov 08, 2010, at 09:21 , Baptiste Daroussin wrote: > We also have to think a way to update ports to use devel/readline > before breaking lot's of them removing libreadline from base. But I > have no idea is there are good procedures for that purpose. Easiest solution would be something along the lines of=20 (1) adding the following to ports/Mk/bsd.port.mk .if defined(USE_READLINE) . if ${OSVERSION} >=3D (whatever the number is) LIB_DEPENDS+=3D readline:${PORTSDIR}/devel/readline # other hacks for CFLAGS, LDFLAGS, etc. . endif .endif (2) creating a suitable binary world tarball with the libreadline not = present in base (3) hand (1) and (2) over to portmgr@ for a 9-i386-exp run, see what = breaks, patch ports accordingly by adding USE_READLINE to the Makefile, = rinse, repeat, commit. Have fun. PS: Don't forget the documentation of the USE_READLINE knob PPS: I wouldn't be expecting much to happen here this side of the = upcoming 7.x/8.x releases, since it's going to be relatively invasive = work, and will most likely need repeated package building runs. -aDe From owner-freebsd-arch@FreeBSD.ORG Tue Nov 9 06:02:57 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1DA901065679 for ; Tue, 9 Nov 2010 06:02:57 +0000 (UTC) (envelope-from bounce@bounce.quepasa.com) Received: from sm-70-42-226-216.quepasa.com (sm-70-42-226-216.quepasa.com [70.42.226.216]) by mx1.freebsd.org (Postfix) with ESMTP id CB9B38FC18 for ; Tue, 9 Nov 2010 06:02:56 +0000 (UTC) Received: from localhost.localdomain ([10.42.226.54]) by sm-70-42-226-216.quepasa.com (StrongMail Enterprise 4.1.1(4.1.1-44201)); Mon, 08 Nov 2010 21:02:53 -0700 X-VirtualServer: Default, sm-70-42-226-216.quepasa.com, 70.42.226.216 X-MailingID: 00000::00000::00000::00000::4::5866839 X-SMHeaderMap: mid="X-MailingID" X-Mailer: StrongMail Enterprise 4.1.1(4.1.1-44201) X-Destination-ID: freebsd-arch@freebsd.org X-SMFBL: ZnJlZWJzZC1hcmNoQGZyZWVic2Qub3Jn DomainKey-Signature: a=rsa-sha1; c=nofws; s=sm; d=quepasa.com; q=dns; b=ugBA1JoER1N1WOby2p3gVskvKOn5DGNF4xBErUnqmmwoTe3pYZfSfE9S5rfHlrdI4/EYumiakRnEZHbz4fGtKkLKdaQcGdIiBbD3RPhk6XbjyofLmwOSX5szgiwLZ3hbvPMv4QvV2zKSlGMr1Y8kEWm019kl5J0Po+tfBVcbZIM= DKIM-Signature: v=1; a=rsa-sha1; c=simple; d=quepasa.com; s=sm; i=@quepasa.com; h=To:From:Subject:Date:X-LibVersion:MIME-Version: Content-Type:Content-Transfer-Encoding:X-QPEmailID: X-QPTemplateID:X-MailLocation:X-VirtualServerGroup:X-Client: Return-path:Reply-to:Sender:List-Unsubscribe:Message-ID; bh=8rmo Sksou/AC5Cwgw0njQqiZv58=; b=m/60+FGbNzLU1wU24efX4XXZu4kZvCS6I7E0 uCCn5e/NZcvlK29up3kXUBgiMzaZetn9dTC7r3F5pTvtF50S4q6DLRC510vBA5Kf iE0Inv9gU+oA7lGnoSM3A+gzwCqdIyXmtghIrezpib2WS5uKjl3WXVDzrAp998CK zAHitxI= To: freebsd-arch@freebsd.org From: Jarupon Mahiphot Date: Mon, 08 Nov 2010 21:00:48 -0700 X-LibVersion: 3.3.2 Content-Transfer-Encoding: quoted-printable X-QPEmailID: 15078556621 X-QPTemplateID: 4 X-MailLocation: Strongmail X-VirtualServerGroup: Default X-Client: 0 Sender: info@quepasa.com Message-ID: <20101109040253.27106.1656820838.swift@te-me-001> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format="flowed" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: I added you as a friend on Quepasa.com X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: noreply@quepasa.com List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 06:02:57 -0000 = = From owner-freebsd-arch@FreeBSD.ORG Tue Nov 9 13:23:38 2010 Return-Path: Delivered-To: arch@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id C17641065670; Tue, 9 Nov 2010 13:23:38 +0000 (UTC) Date: Tue, 9 Nov 2010 13:23:38 +0000 From: Alexander Best To: Dag-Erling =?iso-8859-15?Q?Sm=F8rgrav?= Message-ID: <20101109132338.GA70099@freebsd.org> References: <20101107141804.GN85693@acme.spoerlein.net> <86eiaw0wsf.fsf@ds4.des.no> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <86eiaw0wsf.fsf@ds4.des.no> Cc: arch@freebsd.org Subject: Re: Moving flex and yacc to contrib/, all hell breaks loose? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 13:23:38 -0000 On Mon Nov 8 10, Dag-Erling Smørgrav wrote: > Ulrich Spörlein writes: > > To my knowledge, the only "vendor" software in our tree, not yet living > > under cddl/, contrib/, crypto/ or gnu/ are > > > > lib/libc/softfloat > > lib/libz > > lib/msun > > usr.bin/lex > > usr.bin/unifdef > > usr.bin/yacc > > I have no opinion on the others, but AFAIK, msun is a mix of unmodified > third-party code, locally modified third-party code and locally > developed code (which is how my name ended up in the Android credits), > and I'm not sure there still is a third-party maintainer for our version > of msun. i talked to david hough who is working for oracle. he said that oracle has no business interest in libmsun at all! the mailinglist fdlibm-comments@sun.com will be shut down and every issues etc. with libmsun shall now be discussed here: http://mailman.oakapple.net/mailman/listinfo/numeric-interest this message contains a brief statement by oracle [1]. so it seems lib/msun can be moved to the list of third party software with ceased upstream development. cheers. alex [1] http://mailman.oakapple.net/pipermail/numeric-interest/2010-September/002054.html > > DES > -- > Dag-Erling Smørgrav - des@des.no -- a13x From owner-freebsd-arch@FreeBSD.ORG Tue Nov 9 15:48:16 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C741106566B; Tue, 9 Nov 2010 15:48:16 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id 385448FC25; Tue, 9 Nov 2010 15:48:16 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.4/8.14.4) with ESMTP id oA9FmDmb065096; Tue, 9 Nov 2010 07:48:13 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.4/8.14.4/Submit) id oA9FmDsq065095; Tue, 9 Nov 2010 07:48:13 -0800 (PST) (envelope-from sgk) Date: Tue, 9 Nov 2010 07:48:13 -0800 From: Steve Kargl To: Alexander Best Message-ID: <20101109154813.GA64438@troutmask.apl.washington.edu> References: <20101107141804.GN85693@acme.spoerlein.net> <86eiaw0wsf.fsf@ds4.des.no> <20101109132338.GA70099@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101109132338.GA70099@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: Dag-Erling Sm?rgrav , arch@freebsd.org Subject: Re: Moving flex and yacc to contrib/, all hell breaks loose? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 15:48:16 -0000 On Tue, Nov 09, 2010 at 01:23:38PM +0000, Alexander Best wrote: > On Mon Nov 8 10, Dag-Erling Sm?rgrav wrote: > > Ulrich Sp?rlein writes: > > > To my knowledge, the only "vendor" software in our tree, not yet living > > > under cddl/, contrib/, crypto/ or gnu/ are > > > > > > lib/libc/softfloat > > > lib/libz > > > lib/msun > > > usr.bin/lex > > > usr.bin/unifdef > > > usr.bin/yacc > > > > I have no opinion on the others, but AFAIK, msun is a mix of unmodified > > third-party code, locally modified third-party code and locally > > developed code (which is how my name ended up in the Android credits), > > and I'm not sure there still is a third-party maintainer for our version > > of msun. > > i talked to david hough who is working for oracle. he said that oracle has no > business interest in libmsun at all! the mailinglist fdlibm-comments@sun.com > will be shut down and every issues etc. with libmsun shall now be discussed > here: > > http://mailman.oakapple.net/mailman/listinfo/numeric-interest > > this message contains a brief statement by oracle [1]. > > so it seems lib/msun can be moved to the list of third party software with > ceased upstream development. > > cheers. > alex Interesting mailing! I particularly like http://mailman.oakapple.net/pipermail/numeric-interest/2010-September/002057.html which loops back to http://www.freebsd.org/cgi/query-pr.cgi?pr=144306 which is still open some 9 months later. Here's an updated diff that also fixes jnf(). Watch for cut-n-paste corruption of whitespace. -- steve troutmask:root[217] svn diff src/e_jn*c Index: src/e_jn.c =================================================================== --- src/e_jn.c (revision 213691) +++ src/e_jn.c (working copy) @@ -200,7 +200,12 @@ } } } - b = (t*__ieee754_j0(x)/b); + z = __ieee754_j0(x); + w = __ieee754_j1(x); + if (fabs(z) >= fabs(w)) + b = (t*z/b); + else + b = (t*w/a); } } if(sgn==1) return -b; else return b; Index: src/e_jnf.c =================================================================== --- src/e_jnf.c (revision 213691) +++ src/e_jnf.c (working copy) @@ -152,7 +152,12 @@ } } } - b = (t*__ieee754_j0f(x)/b); + z = __ieee754_j0f(x); + w = __ieee754_j1f(x); + if (fabs(z) >= fabs(w)) + b = (t*z/b); + else + b = (t*w/a); } } if(sgn==1) return -b; else return b; -- Steve From owner-freebsd-arch@FreeBSD.ORG Tue Nov 9 16:43:18 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7F39106566B; Tue, 9 Nov 2010 16:43:18 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6E0C48FC15; Tue, 9 Nov 2010 16:43:18 +0000 (UTC) Received: by iwn39 with SMTP id 39so7821114iwn.13 for ; Tue, 09 Nov 2010 08:43:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=CxWAqCkywN3nF/ZZPkHFn+Ognr6wsh+CTcLBxt+ruwg=; b=YUI6ZIhLz346kgzvqRwOSQVqO9WOmFHzSiyeWUemhE/d2H3fqDo2Ox20Uu0aL+ZKgX Im4uJ/AS05gvpyNoOJYEh0g+A0mK6v/n+P3igekXxV8gLwSWoBcnmHPSlx4m1IZeF9Bb X+24ZgoH1PuCZviBuGZsjEnUR9W9zh7Mx0oG4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=NoFTdGUGHv9z2Z0CdX/hBzLEly0Xlgqpe/bdmT6Y1VrN9RrKAko/VU8lOCC2AfICID s+CRTz1g9Vp30Zu9H5s7AIz7nbH0MxqUJShXHFpE41r2LngHtYN5YiYKS8mg7b4eHxS8 fJW7QAkrsPgvriUswBUTiaIUaSsM3sSCsFx2w= MIME-Version: 1.0 Received: by 10.231.169.135 with SMTP id z7mr5441867iby.28.1289320996760; Tue, 09 Nov 2010 08:43:16 -0800 (PST) Sender: baptiste.daroussin@gmail.com Received: by 10.231.180.164 with HTTP; Tue, 9 Nov 2010 08:43:16 -0800 (PST) In-Reply-To: References: <20101106120752.001e92c0@ernst.jennejohn.org> <86vd4ao5o4.fsf@gmail.com> Date: Tue, 9 Nov 2010 17:43:16 +0100 X-Google-Sender-Auth: EQ6vT3m8V_urCIJEbYahgPOlLiY Message-ID: From: Baptiste Daroussin To: Ade Lovett Content-Type: text/plain; charset=ISO-8859-1 Cc: Anonymous , freebsd-hackers@freebsd.org, gljennjohn@googlemail.com, freebsd-arch@freebsd.org Subject: Re: [PATCH] update to the latest libedit version and remove libreadline deps X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 16:43:18 -0000 Yet another version of the patch, I hope the last one http://people.freebsd.org/~bapt/update-libedit.patch Everything should be working as it used to do before. Now gdbtui is almost working. why almost because everything works except Ctrl-D (EOF), I know where the bug is (lib/libedit/read.c : function: FUN(el,gets)(EditLine *el, int *nread), the read pb is in readchar I guess) but I can't find a way to fix it and it seems to me a really minor regression. I think we can live with this as this bug appear only when libedit doesn't directly gets its input but get is through a third party interface (ncurses in that case) and gdbtui is the only program in base working like this. Also thanks for the information about exp-run, if anyone is about to accept this patch and wanted to commit it, I'll follow those informations. regards, Bapt From owner-freebsd-arch@FreeBSD.ORG Thu Nov 11 15:00:44 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF7ED106564A for ; Thu, 11 Nov 2010 15:00:44 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) by mx1.freebsd.org (Postfix) with ESMTP id A89A18FC0A for ; Thu, 11 Nov 2010 15:00:44 +0000 (UTC) Received: from smtp.hudson-trading.com ([209.249.190.9] helo=gnnmac.hudson-trading.com) by vps.hungerhost.com with esmtpa (Exim 4.69) (envelope-from ) id 1PGYdl-0005kv-LQ; Thu, 11 Nov 2010 10:00:43 -0500 From: George Neville-Neil Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 11 Nov 2010 10:00:41 -0500 Message-Id: To: arch@freebsd.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com X-Source: X-Source-Args: X-Source-Dir: Cc: net@freebsd.org Subject: Updated ARP Queue Patch... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 15:00:44 -0000 Howdy, After some excellent comments from Bjoern I've put together the = following patch: http://people.freebsd.org/~gnn/head-arpqueue4.diff Please review and comment. Best, George From owner-freebsd-arch@FreeBSD.ORG Fri Nov 12 01:26:18 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 165211065670 for ; Fri, 12 Nov 2010 01:26:18 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9E6848FC16 for ; Fri, 12 Nov 2010 01:26:17 +0000 (UTC) Received: by wya21 with SMTP id 21so298489wya.13 for ; Thu, 11 Nov 2010 17:26:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=l+TxEDxVKRECPOcmUHMBgRJv1AHh59WVaSSv4pulxdA=; b=IZcD7gAHhkzH+3nMoJUHzb3BLxksXfKlCOZgtm1z7leOVKh4w1dnsidPLsvga/r1xT rvvtJ7sP2DK9BzMMiQqDumWAIaIMolYw9iOw0f0SMs1cVtmjt0CDDPud2A40zD7RxNPr BpJwDLBlEChtZBETF1KYhACIOpgqjSLF9ppno= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=B19zBVZ1znwIPCxWgp7wxvOmKDNQIhbEgEgKo8d+UAGbXAuD9tXhFIAo6MgCIeBi93 5w+9FfmB5eLCDZ9WbQV/Ds1yP0KWxE1Az8VyvWPj7gbSW0lygc5rpDyqyVxFrahMwqef 0VL8iSjzaYPzrd9XNHoGL0AnrQ31sqo28U43M= MIME-Version: 1.0 Received: by 10.216.51.21 with SMTP id a21mr1396637wec.50.1289523659569; Thu, 11 Nov 2010 17:00:59 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.65.210 with HTTP; Thu, 11 Nov 2010 17:00:59 -0800 (PST) In-Reply-To: References: Date: Fri, 12 Nov 2010 09:00:59 +0800 X-Google-Sender-Auth: LJy1JR1RoPOu4kduZOjM-D3oGc8 Message-ID: From: Adrian Chadd To: freebsd-arch@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Fwd: breaking the crunchgen logic into a share/mk file X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 01:26:18 -0000 FYI, I'd like to commit this today if possible. Will this break any kind of builds that I haven't thought of? It's introducing a new mk rule file which needs to be wherever 'make' checks its paths. Thanks, Adrian ---------- Forwarded message ---------- From: Adrian Chadd Date: 5 October 2010 10:36 Subject: breaking the crunchgen logic into a share/mk file To: freebsd-hackers@freebsd.org Hi, I've broken out the crunchgen logic from src/rescue/rescue into a share/mk file - that way it can be reused in other areas. The diff is here: http://people.freebsd.org/~adrian/crunchgen-mk.diff This bsd.crunchgen.mk file is generic enough to use in my busybox-style thing as well as for src/rescue/rescue/. Comments, feedback, etc welcome! Adrian From owner-freebsd-arch@FreeBSD.ORG Fri Nov 12 08:02:56 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E98B4106566B; Fri, 12 Nov 2010 08:02:56 +0000 (UTC) (envelope-from rpaulo@lavabit.com) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by mx1.freebsd.org (Postfix) with ESMTP id A099B8FC12; Fri, 12 Nov 2010 08:02:56 +0000 (UTC) Received: from d.earth.lavabit.com (d.earth.lavabit.com [192.168.111.13]) by karen.lavabit.com (Postfix) with ESMTP id D7AA211B83A; Fri, 12 Nov 2010 01:38:53 -0600 (CST) Received: from 192.168.1.70 (bl17-149-52.dsl.telepac.pt [188.82.149.52]) by lavabit.com with ESMTP id FY3X08BENJVA; Fri, 12 Nov 2010 01:38:53 -0600 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=lavabit; d=lavabit.com; b=lQkE4MYJH5nmOU/Tf8UzQSD68uTHTXDQfGzggJSKAFYBtIC2AUU8Sc8imKLzrIgjuuqIUh1XJW1G2soXldtNbTi46zD7WVVXTBIKM2t/UKUmPHF0yCZNHJL+nY4dn60/DiwpkmEphfzpOWtNVuvPCPW/NVYZL5u1A23RrLXh17o=; h=References:In-Reply-To:Mime-Version:Content-Type:Message-Id:Content-Transfer-Encoding:Cc:From:Subject:Date:To:X-Mailer; References: In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii Message-Id: <1C1981FB-1B67-4873-9B23-39D51B61F5B3@lavabit.com> Content-Transfer-Encoding: quoted-printable From: Rui Paulo Date: Fri, 12 Nov 2010 07:38:50 +0000 To: George Neville-Neil X-Mailer: Apple Mail (2.1082) Cc: arch@freebsd.org, net@freebsd.org Subject: Re: Updated ARP Queue Patch... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 08:02:57 -0000 On Nov 11, 2010, at 3:00 PM, George Neville-Neil wrote: > Howdy, >=20 > After some excellent comments from Bjoern I've put together the = following patch: >=20 > http://people.freebsd.org/~gnn/head-arpqueue4.diff >=20 > Please review and comment. Looks good to me. Regards, -- Rui Paulo