From owner-svn-src-head@FreeBSD.ORG Sun Jun 23 00:44:40 2013 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 252949A5; Sun, 23 Jun 2013 00:44:40 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail104.syd.optusnet.com.au (mail104.syd.optusnet.com.au [211.29.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id D90C116F5; Sun, 23 Jun 2013 00:44:39 +0000 (UTC) Received: from c122-106-156-23.carlnfd1.nsw.optusnet.com.au (c122-106-156-23.carlnfd1.nsw.optusnet.com.au [122.106.156.23]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id 81F154207DF; Sun, 23 Jun 2013 10:44:32 +1000 (EST) Date: Sun, 23 Jun 2013 10:44:28 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Garrett Cooper Subject: Re: svn commit: r252074 - head/sys/fs/nfsclient In-Reply-To: <337C6949-87B6-442A-ADD6-9F12766E9919@gmail.com> Message-ID: <20130623093034.A923@besplex.bde.org> References: <201306212246.r5LMkHBY070137@svn.freebsd.org><20130622042219.GC1888@glenbarber.us> <28B87860D4194B3DA2E6A992537142B1@multiplay.co.uk> <337C6949-87B6-442A-ADD6-9F12766E9919@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=Q6eKePKa c=1 sm=1 a=q5jKLduKGBcA:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=jQqfA_MDNRQA:10 a=1NWOV8S6UX2bKiEduA0A:9 a=CjuIK1q_8ugA:10 a=ebeQFi2P/qHVC0Yw9JDJ4g==:117 Cc: src-committers , svn-src-all , Hiroki Sato , hiren panchasara , Glen Barber , Steven Hartland , svn-src-head , Rick Macklem X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2013 00:44:40 -0000 On Sat, 22 Jun 2013, Garrett Cooper wrote: > On Jun 22, 2013, at 11:22 AM, Steven Hartland wrote: > >> I thought the use of PRIu64 was frowned on? > > It is in FreeBSD, unlike Linux (for better or for worse). It should be cast with either intmax_t or uintmax_t and use %jd or %ju. Do you mean that this mistake is not even possible in Linux (the kernel)? Linux-2.6.10 has no references to PRI* or SCN*. It doesn't even have stdint.h. The PRI* and SCN* bugs are in inttypes.h. In C99, is a historical wrapper for that adds these bugs and prototypes for strtoimax() and friends. In the kernel, these files really shouldn't be used. Even in FreeBSD, it takes extra work to get these bugs. is standard pollution in , but inttypes.h has to be included directly about 30 files in /sys include it under any name. Almost half of these are userland applications so they have the excuse that is a Standard header. Some of the includes, not counted in the 30, are in comments. 1 of the 30 is is an include of the nonstandard header . This file doesn't exist in FreeBSD. Including it only defeats simple greps. It doesn't break the build since the include is in code ifdefed for NetBSD and OpenBSD. sys/inttypes.h existed in FreeBSD until 2001. It was removed then as part of implementing the C99 headers and . I think was the old name, and exists now mainly to hold historical mistakes, while is a C99 invention to clean up some of the mistakes, but unfortunately it wasn't possible to clean them all. Before 2001, FreeBSD used only the older name inttypes.h, but only had the important parts of in it, and of course didn't have PRI* or SCN*. The part of was created essentially by renaming sys/inttypes.h to sys/stdint.h in 2001. This means that there is no supported kernel include file containing the PRI* and SCN* mistakes. But all arches have a for exporting these mistakes to userland. 15 of the 30 files are chummy with this implemntation detail and include directly, presumably so that they can have more style bugs by using PRI*. All 15 of these files are relatively new. was not referenced in the kernel for several years after it was created. Bruce From owner-svn-src-head@FreeBSD.ORG Sun Jun 23 00:56:20 2013 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6B7EAB79; Sun, 23 Jun 2013 00:56:20 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 225B81729; Sun, 23 Jun 2013 00:56:20 +0000 (UTC) Received: by mail-pa0-f42.google.com with SMTP id rl6so9475689pac.1 for ; Sat, 22 Jun 2013 17:56:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=eFLAaNxP6Z7RavqAmDNVBDfso8HaGNueVn315mdXGq4=; b=JESrSD+aosCoqBBncBeBU3DveOPQfTxqR8comRAIgWlvGYSJEWEvDhfpSPDZr8Kv4h sB2FtF5lbP9e1cp/pvWFlUiPTcTdf/iWRIEkJTlMM3Nz+j5qWLlIKVjbRJshLc9HtFXS vB752ccP2PKi4Kc+E99FRF932oNIXhcP4mVVvSaI0m54xMfT2RpTXieQFnzTGpT2xZx/ 3AyCSu25yOX6inp0PxjRnQQI9sOlAhF70nPDf0s5tMwB1Gkd0luTtxnr9oD03k0RH/JM FCFGieuMbogP45cqN1/37f324BNqOZYw5x4ji1N8/BKjPRjreewkjPp6305txMeOTBpN hYeQ== X-Received: by 10.66.122.5 with SMTP id lo5mr6265994pab.175.1371948979980; Sat, 22 Jun 2013 17:56:19 -0700 (PDT) Received: from [192.168.20.5] (c-98-203-241-95.hsd1.wa.comcast.net. [98.203.241.95]) by mx.google.com with ESMTPSA id iq6sm11243699pbc.1.2013.06.22.17.56.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 22 Jun 2013 17:56:19 -0700 (PDT) Subject: Re: svn commit: r252074 - head/sys/fs/nfsclient Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Garrett Cooper In-Reply-To: <20130623093034.A923@besplex.bde.org> Date: Sat, 22 Jun 2013 17:56:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201306212246.r5LMkHBY070137@svn.freebsd.org><20130622042219.GC1888@glenbarber.us> <28B87860D4194B3DA2E6A992537142B1@multiplay.co.uk> <337C6949-87B6-442A-ADD6-9F12766E9919@gmail.com> <20130623093034.A923@besplex.bde.org> To: Bruce Evans X-Mailer: Apple Mail (2.1283) Cc: src-committers , svn-src-all , Hiroki Sato , hiren panchasara , Glen Barber , Steven Hartland , svn-src-head , Rick Macklem X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2013 00:56:20 -0000 On Jun 22, 2013, at 5:44 PM, Bruce Evans wrote: > On Sat, 22 Jun 2013, Garrett Cooper wrote: >=20 >> On Jun 22, 2013, at 11:22 AM, Steven Hartland wrote: >>=20 >>> I thought the use of PRIu64 was frowned on? >>=20 >> It is in FreeBSD, unlike Linux (for better or for worse). It = should be cast with either intmax_t or uintmax_t and use %jd or %ju. >=20 > Do you mean that this mistake is not even possible in Linux (the = kernel)? > Linux-2.6.10 has no references to PRI* or SCN*. It doesn't even have > stdint.h. The PRI* and SCN* bugs are in inttypes.h. In C99, = > is a historical wrapper for that adds these bugs and = prototypes > for strtoimax() and friends. In the kernel, these files really = shouldn't > be used. I meant GNU/Linux, as a distribution, not just the kernel.= From owner-svn-src-head@FreeBSD.ORG Sun Jun 23 02:43:46 2013 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7014AD99; Sun, 23 Jun 2013 02:43:46 +0000 (UTC) (envelope-from gad@FreeBSD.org) Received: from smtp9.server.rpi.edu (gateway.canit.rpi.edu [128.113.2.229]) by mx1.freebsd.org (Postfix) with ESMTP id 287BF1A54; Sun, 23 Jun 2013 02:43:45 +0000 (UTC) Received: from gilead.netel.rpi.edu (gilead.netel.rpi.edu [128.113.124.121]) by smtp9.server.rpi.edu (8.14.3/8.14.3/Debian-9.4) with ESMTP id r5N2hbaX010421; Sat, 22 Jun 2013 22:43:37 -0400 Message-ID: <51C660D9.8080804@FreeBSD.org> Date: Sat, 22 Jun 2013 22:43:37 -0400 From: Garance A Drosehn User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Tijl Coosemans Subject: Re: svn commit: r251886 - in head: contrib/apr contrib/apr-util contrib/serf contrib/sqlite3 contrib/subversion share/mk usr.bin usr.bin/svn usr.bin/svn/lib usr.bin/svn/lib/libapr usr.bin/svn/lib/libap... References: <201306180253.r5I2rj45053959@svn.freebsd.org> <11DA3D8A-AD20-4DE1-B807-D09814F61947@bsdimp.com> <51C1C7BD.9060201@FreeBSD.org> <201306191113.29703.jhb@freebsd.org> <8D00BE2B-FD8E-4E7B-B818-1C4B7F6BB6A5@bsdimp.com> <68D70A89-22F2-412C-BAF4-72BEFE21EB2F@bsdimp.com> <51C5EF15.10305@FreeBSD.org> In-Reply-To: <51C5EF15.10305@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0, tokens from: local, @@RPTN) X-Spam-Score: 3.00 (***) [Hold at 10.10] SPF(softfail:3) X-CanIt-Incident-Id: 02JPCHBTz X-CanIt-Geo: ip=128.113.124.121; country=US; region=NY; city=Troy; postalcode=12180; latitude=42.7495; longitude=-73.5951; metrocode=532; areacode=518; http://maps.google.com/maps?q=42.7495,-73.5951&z=6 X-CanItPRO-Stream: local X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.113.2.229 Cc: src-committers@FreeBSD.org, Andre Oppermann , Peter Wemm , John Baldwin , svn-src-all@FreeBSD.org, David Chisnall , svn-src-head@FreeBSD.org, Warner Losh X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2013 02:43:46 -0000 On 6/22/13 2:38 PM, Tijl Coosemans wrote: > On 2013-06-20 21:34, Warner Losh wrote: >> >> I think insisting on a definitive statement on svn lite's mission >> statement is a way to obstruct progress. Sometimes you just need to >> things because they feel right, not because they have been through a >> 20-step approval process... > > For what it's worth, my reservations have always been because it > didn't feel right. I never asked for an approval process. > > I do think there should be a tool in base that can fetch source > updates and it would be nice if it could roll back changes and > even nicer if it could do bisects. But svn itself is not the > right tool for that. > > For instance, will you allow that svn is updated from version x.y > to x.(y+1) in a stable branch? If yes, then users might have to run > run "svn upgrade" which is a one way process, so how does importing > svn allow you to roll back changes or do bisects then? If no, then > who's volunteering to backport security fixes? What was added to the base system was 'svnlite', not 'svn' from the official subversion project. The distinction is that 'svnlite' is a version meant only for access to the official FreeBSD repositories. 'svnlite' in the base system would only be upgraded when it is needed to match the FreeBSD respository. And if you need to run 'svn upgrade' to access the FreeBSD repository, then it doesn't make much difference if you have to do that with 'svnlite' or via the official 'svn' port. I'm not sure that my comments provide an answer to what you're concerned about, but anyone who wants the latest version of 'svn' to match their own repositories is still going to need to install the port. We're not going to blindly update 'svnlite' every time a new version of 'svn' is released. 'svnlite' is going to be updated on *FreeBSD*'s schedule, not on the schedule of the subversion project. It is true that we're going to have to be careful when it does come time to switch to some new repo-format for the FreeBSD repository. We might find ourselves in some kind of chicken- and-egg situation at that point. And when we do make a significant upgrade to the FreeBSD repository, then we're going to have to upgrade 'svnlite' across multiple FreeBSD branches at the same time, including all -stable branches. But when that issue comes up it'll come up on our schedule, because we'll control both 'svnlite' and the FreeBSD repo. -- Garance Alistair Drosehn = drosih@rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA From owner-svn-src-head@FreeBSD.ORG Sun Jun 23 02:44:43 2013 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DB347F0D; Sun, 23 Jun 2013 02:44:43 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) by mx1.freebsd.org (Postfix) with ESMTP id C682E1A59; Sun, 23 Jun 2013 02:44:43 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.7/8.14.7) with ESMTP id r5N2ihx5066853; Sun, 23 Jun 2013 02:44:43 GMT (envelope-from pfg@svn.freebsd.org) Received: (from pfg@localhost) by svn.freebsd.org (8.14.7/8.14.5/Submit) id r5N2ig2a066840; Sun, 23 Jun 2013 02:44:42 GMT (envelope-from pfg@svn.freebsd.org) Message-Id: <201306230244.r5N2ig2a066840@svn.freebsd.org> From: "Pedro F. Giffuni" Date: Sun, 23 Jun 2013 02:44:42 +0000 (UTC) To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: svn commit: r252103 - head/sys/fs/ext2fs X-SVN-Group: head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2013 02:44:43 -0000 Author: pfg Date: Sun Jun 23 02:44:42 2013 New Revision: 252103 URL: http://svnweb.freebsd.org/changeset/base/252103 Log: Define and use e2fs_lbn_t in ext2fs. In line to what is done in UFS, define an internal type e2fs_lbn_t for the logical block numbers. This change is basically a no-op as the new type is unchanged (int32_t) but it may be useful as bumping this may be required for ext4fs. Also, as pointed out by Bruce Evans: -Use daddr_t for daddr in ext2_bmaparray(). This seems to improve reliability with the reallocblks option. - Add a cast to the fsbtodb() macro as in UFS. Reviewed by: bde MFC after: 3 days Modified: head/sys/fs/ext2fs/ext2_alloc.c head/sys/fs/ext2fs/ext2_balloc.c head/sys/fs/ext2fs/ext2_bmap.c head/sys/fs/ext2fs/ext2_extern.h head/sys/fs/ext2fs/ext2_subr.c head/sys/fs/ext2fs/fs.h head/sys/fs/ext2fs/inode.h Modified: head/sys/fs/ext2fs/ext2_alloc.c ============================================================================== --- head/sys/fs/ext2fs/ext2_alloc.c Sun Jun 23 00:01:28 2013 (r252102) +++ head/sys/fs/ext2fs/ext2_alloc.c Sun Jun 23 02:44:42 2013 (r252103) @@ -165,7 +165,8 @@ ext2_reallocblks(struct vop_reallocblks_ struct ext2mount *ump; struct cluster_save *buflist; struct indir start_ap[NIADDR + 1], end_ap[NIADDR + 1], *idp; - int32_t start_lbn, end_lbn, soff, newblk, blkno; + e2fs_lbn_t start_lbn, end_lbn; + int32_t soff, newblk, blkno; int i, len, start_lvl, end_lvl, pref, ssize; if (doreallocblks == 0) @@ -550,7 +551,7 @@ ext2_dirpref(struct inode *pip) * that will hold the pointer */ int32_t -ext2_blkpref(struct inode *ip, int32_t lbn, int indx, int32_t *bap, +ext2_blkpref(struct inode *ip, e2fs_lbn_t lbn, int indx, int32_t *bap, int32_t blocknr) { int tmp; Modified: head/sys/fs/ext2fs/ext2_balloc.c ============================================================================== --- head/sys/fs/ext2fs/ext2_balloc.c Sun Jun 23 00:01:28 2013 (r252102) +++ head/sys/fs/ext2fs/ext2_balloc.c Sun Jun 23 02:44:42 2013 (r252103) @@ -57,7 +57,7 @@ * the inode and the logical block number in a file. */ int -ext2_balloc(struct inode *ip, int32_t lbn, int size, struct ucred *cred, +ext2_balloc(struct inode *ip, e2fs_lbn_t lbn, int size, struct ucred *cred, struct buf **bpp, int flags) { struct m_ext2fs *fs; Modified: head/sys/fs/ext2fs/ext2_bmap.c ============================================================================== --- head/sys/fs/ext2fs/ext2_bmap.c Sun Jun 23 00:01:28 2013 (r252102) +++ head/sys/fs/ext2fs/ext2_bmap.c Sun Jun 23 02:44:42 2013 (r252103) @@ -99,8 +99,8 @@ ext2_bmaparray(struct vnode *vp, int32_t struct mount *mp; struct vnode *devvp; struct indir a[NIADDR+1], *ap; - int32_t daddr; - long metalbn; + daddr_t daddr; + e2fs_lbn_t metalbn; int error, num, maxrun = 0, bsize; int *nump; @@ -241,7 +241,8 @@ ext2_bmaparray(struct vnode *vp, int32_t int ext2_getlbns(struct vnode *vp, int32_t bn, struct indir *ap, int *nump) { - long blockcnt, metalbn, realbn; + long blockcnt; + e2fs_lbn_t metalbn, realbn; struct ext2mount *ump; int i, numlevels, off; int64_t qblockcnt; Modified: head/sys/fs/ext2fs/ext2_extern.h ============================================================================== --- head/sys/fs/ext2fs/ext2_extern.h Sun Jun 23 00:01:28 2013 (r252102) +++ head/sys/fs/ext2fs/ext2_extern.h Sun Jun 23 02:44:42 2013 (r252103) @@ -49,10 +49,10 @@ struct vnode; int ext2_alloc(struct inode *, int32_t, int32_t, int, struct ucred *, int32_t *); int ext2_balloc(struct inode *, - int32_t, int, struct ucred *, struct buf **, int); + e2fs_lbn_t, int, struct ucred *, struct buf **, int); int ext2_blkatoff(struct vnode *, off_t, char **, struct buf **); void ext2_blkfree(struct inode *, int32_t, long); -int32_t ext2_blkpref(struct inode *, int32_t, int, int32_t *, int32_t); +int32_t ext2_blkpref(struct inode *, e2fs_lbn_t, int, int32_t *, int32_t); int ext2_bmap(struct vop_bmap_args *); int ext2_bmaparray(struct vnode *, int32_t, int32_t *, int *, int *); void ext2_clusteracct(struct m_ext2fs *, char *, int, daddr_t, int); Modified: head/sys/fs/ext2fs/ext2_subr.c ============================================================================== --- head/sys/fs/ext2fs/ext2_subr.c Sun Jun 23 00:01:28 2013 (r252102) +++ head/sys/fs/ext2fs/ext2_subr.c Sun Jun 23 02:44:42 2013 (r252103) @@ -68,7 +68,7 @@ ext2_blkatoff(struct vnode *vp, off_t of struct inode *ip; struct m_ext2fs *fs; struct buf *bp; - int32_t lbn; + e2fs_lbn_t lbn; int bsize, error; ip = VTOI(vp); Modified: head/sys/fs/ext2fs/fs.h ============================================================================== --- head/sys/fs/ext2fs/fs.h Sun Jun 23 00:01:28 2013 (r252102) +++ head/sys/fs/ext2fs/fs.h Sun Jun 23 02:44:42 2013 (r252103) @@ -98,8 +98,8 @@ * Turn file system block numbers into disk block addresses. * This maps file system blocks to device size blocks. */ -#define fsbtodb(fs, b) ((b) << ((fs)->e2fs_fsbtodb)) -#define dbtofsb(fs, b) ((b) >> ((fs)->e2fs_fsbtodb)) +#define fsbtodb(fs, b) ((daddr_t)(b) << (fs)->e2fs_fsbtodb) +#define dbtofsb(fs, b) ((b) >> (fs)->e2fs_fsbtodb) /* get group containing inode */ #define ino_to_cg(fs, x) (((x) - 1) / (fs->e2fs_ipg)) Modified: head/sys/fs/ext2fs/inode.h ============================================================================== --- head/sys/fs/ext2fs/inode.h Sun Jun 23 00:01:28 2013 (r252102) +++ head/sys/fs/ext2fs/inode.h Sun Jun 23 02:44:42 2013 (r252103) @@ -50,6 +50,11 @@ #define NIADDR 3 /* Indirect addresses in inode. */ /* + * The size of physical and logical block numbers and time fields in UFS. + */ +typedef int32_t e2fs_lbn_t; + +/* * The inode is used to describe each active (or recently active) file in the * EXT2FS filesystem. It is composed of two types of information. The first * part is the information that is needed only while the file is active (such @@ -148,7 +153,7 @@ struct inode { * ext2_getlbns and used by truncate and bmap code. */ struct indir { - int32_t in_lbn; /* Logical block number. */ + e2fs_lbn_t in_lbn; /* Logical block number. */ int in_off; /* Offset in buffer. */ }; From owner-svn-src-head@FreeBSD.ORG Sun Jun 23 07:30:14 2013 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B54AE175; Sun, 23 Jun 2013 07:30:14 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 24CD71240; Sun, 23 Jun 2013 07:30:13 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r5N7U5FJ012435; Sun, 23 Jun 2013 10:30:05 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r5N7U5FJ012435 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r5N7U46R012434; Sun, 23 Jun 2013 10:30:04 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 23 Jun 2013 10:30:04 +0300 From: Konstantin Belousov To: Bruce Evans Subject: Re: svn commit: r252032 - head/sys/amd64/include Message-ID: <20130623073004.GX91021@kib.kiev.ua> References: <201306201430.r5KEU4G5049115@svn.freebsd.org> <20130621065839.J916@besplex.bde.org> <20130621081116.E1151@besplex.bde.org> <20130621090207.F1318@besplex.bde.org> <20130621064901.GS1214@FreeBSD.org> <20130621184140.G848@besplex.bde.org> <20130621135427.GA1214@FreeBSD.org> <20130622110352.J2033@besplex.bde.org> <20130622124832.S2347@besplex.bde.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jl/VStiZFoZxPJyo" Content-Disposition: inline In-Reply-To: <20130622124832.S2347@besplex.bde.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, Gleb Smirnoff , src-committers@freebsd.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2013 07:30:14 -0000 --jl/VStiZFoZxPJyo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jun 22, 2013 at 01:37:58PM +1000, Bruce Evans wrote: > On Sat, 22 Jun 2013, I wrote: >=20 > > ... > > Here are considerably expanded tests, with noninline tests dropped. > > Summary of times on Athlon64: > > > > simple increment: 4-7 cycles (1) > > simple increment preceded by feature test: 5-8 cycles (1) > > simple 32-bit increment: 4-7 cycles (2) > > correct 32-bit increment (addl to mem): 5.5-7 cycles (3) > > inlined critical section: 8.5 cycles (4) > > better inlined critical section: 7 cycles (5) > > correct unsigned 32-bit inc of 64-bit counter: 4-7 cycles (6) > > "improve" previous to allow immediate operand: 5+ cycles > > correct signed 32-bit inc of 64-bit counter: 8.5-9 cycles (7) > > correct 64-bit inc of 64-bit counter: 8-9 cycles (8) > > -current method (cmpxchg8b): 18 cycles >=20 > corei7 (freefall) has about the same timing as Athlon64, but core2 > (ref10-i386) is 3-4 cycles slower for the tests that use cmpxchg. You only tested 32 bit, right ? Note that core2-class machines have at least one cycle penalty for decoding any instruction with REX prefix. >=20 > > (4) The critical section method is quite fast when inlined. > > (5) The critical section method is even faster when optimized. This is > > what should be used if you don't want the complications for the > > daemon. >=20 > Oops, I forgot that critical sections are much slower in -current than > in my version. They probably take 20-40 cycles for the best case, and > can't easily be tested in userland since they disable interrupts in > hardware. My versions disable interrupts in software. The critical sections do not disable the interrupts. Only the thread local counter is incremented. Leaving the section could be complicated though. >=20 > > ... > > % % static inline void > > % alt_counter_u64_add(counter_u64_t c, int64_t inc) > > % { > > % #if 1 > > % /* 8.5 cycles on A64. */ > > % td->td_critnest++; > > % __asm __volatile("addl %1,%%ds:%0" : "=3Dm,m" (*c) : "?i,r" (inc)); > > % td->td_critnest++; >=20 > Oops, one increment should be a decrement. >=20 > > % #elif 1 > > % /* 7 cycles on A64. */ > > % uint32_t ocritnest; > > %=20 > > % ocritnest =3D td->td_critnest; > > % td->td_critnest =3D ocritnest + 1; > > % __asm __volatile("addl %1,%%ds:%0" : "=3Dm,m" (*c) : "?i,r" (inc)); > > % td->td_critnest =3D ocritnest; > > % #elif 0 >=20 > Even in my version, I have to check for unmasked interrupts when td_critn= est > is reduced to 0. At least the test for being reduced to 0 can be very fa= st, > since the reduced value is loaded early and can be tested early. >=20 > Further tests confirm that incl and incq are pipelined normally on at > least corei7 and core2. In the loop test, freefall can do 4 independent > addq's to memory faster than it can do 1 :-). It can do 6 independent > addq's to memory in the same time that it can do 1. After that, the > loop overhead prevents geting the complete bandwidth of the memory > system. However, 6 addq's to the same memory location take a little > more than 6 times longer than 1. Multiple increments of the same counter > one after the other are probably rare, but the counter API makes it harder > to coaelsce them if they occur, and the implementation using independent > asms ensures that the compiler cannot coalesce them. I think that the naive looping on Core i7+ to measure the latencies of the instructions simply does not work. The Nehalem hardware started to provide the loop detector for the instruction queue inside the decoder, which essentially makes the short loops executed from the microopcode form. We never use counters in the tight loops. --jl/VStiZFoZxPJyo Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJRxqP8AAoJEJDCuSvBvK1Br7UP+wS+Ts43sFcG9SE4QnbDXwLP AFAaPRnRRqHiP4xkQ4UAW74n/8/X2+yQmYLCH+4EXVjKhovLTWRQJ5DLZeHbFR6I 8f8S6y0VZF4C/hpvq7zrItSmoYHc+H2N6H1KCtuTi2KyqhyZNCA5AgeJiqrdMRs3 DMguAb8wM7cYsmO6VT/A+kQSxeFqIzhtZcQkllKYu405z8R3Q4ihhzBAwb/2VHuT f0Nos1V0ZR9UUWUBe1yRcbZwFMP95FGTpyeTEC+azv+QlIIpZAO4gCQGW7GjtmP/ B5a79puOV9Jsv92v9koHjeXUskFtihO35IAP4ngCZA5A73wu816kWQL9YVPeYHLT Ev29rUnZajYK8JJnTniAgoJpjwaUIm2vDRNDWpv84+I+MDzSvMTkBrzIumSLVQQ+ eqTM6e63k3hTB1rNQp45sPhXRB3gr0OD+3W41odu/1shnfxfKnYSOUTwRc1Zc7Mm 7Evrzg1vN57aDD/9eEWDXjxdmy/gccRYzyLqAqpMK9NChQiRtxd9kOTmaGMBLD5Y 0gGM4Gwwq2BiASv6Zk2klRGJ5FgXp+xVNAMoaVNM+FQMVSIiiuF8UJA9vW43Ttz5 9Mfr4ywTDBhjfx30qDe98aPMht68kGCm8A3KyqkxXESZS2M1pRC/WgAHLSFvCOcS uZ/Bqwwc5bhN/JmD3hZG =eC03 -----END PGP SIGNATURE----- --jl/VStiZFoZxPJyo-- From owner-svn-src-head@FreeBSD.ORG Sun Jun 23 07:33:47 2013 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 615EE30F; Sun, 23 Jun 2013 07:33:47 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id E21691259; Sun, 23 Jun 2013 07:33:46 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r5N7XhG0013437; Sun, 23 Jun 2013 10:33:43 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r5N7XhG0013437 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r5N7Xh9C013436; Sun, 23 Jun 2013 10:33:43 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 23 Jun 2013 10:33:43 +0300 From: Konstantin Belousov To: Bruce Evans Subject: Re: svn commit: r252032 - head/sys/amd64/include Message-ID: <20130623073343.GY91021@kib.kiev.ua> References: <201306201430.r5KEU4G5049115@svn.freebsd.org> <20130621065839.J916@besplex.bde.org> <20130621081116.E1151@besplex.bde.org> <20130621090207.F1318@besplex.bde.org> <20130621064901.GS1214@FreeBSD.org> <20130621184140.G848@besplex.bde.org> <20130621135427.GA1214@FreeBSD.org> <20130622110352.J2033@besplex.bde.org> <20130622124832.S2347@besplex.bde.org> <20130622174921.I3112@besplex.bde.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="to1uSGBmQtEag2WO" Content-Disposition: inline In-Reply-To: <20130622174921.I3112@besplex.bde.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, Gleb Smirnoff , src-committers@freebsd.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2013 07:33:47 -0000 --to1uSGBmQtEag2WO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, Jun 22, 2013 at 06:58:15PM +1000, Bruce Evans wrote: > So the i386 version be simply "addl; adcl" to memory. Each store in > this is atomic at the per-CPU level. If there is no carry, then the > separate stores are equivalent to adding separate nonnegative values and > the counter value is valid at all times. If there is carry, then the > separate stores are equivalent to adding a negative value followed by > a larger positive value. The counter transiently goes backwards, but > no information is lost and the counter is eventually set to the correct > forward-going value. This is quite interesting idea, but I still did not decided if it acceptable. The issue is that we could add the carry to the other processor counter, if the preemption kicks in at right time between two instructions. I did not found any argument why would it be wrong, the races for fetch operation seems to be the same with either local update method. On the other hand, for debugging it would be quite confusing state of the counters array to observe. --to1uSGBmQtEag2WO Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJRxqTWAAoJEJDCuSvBvK1ByLQP/2foifYLfz0tYSdbcwQIGafb iuJYFO2RLJTTA1+doHSOuYV2LlaqOQb/TmdfRWOuXm+XU5p77T/WBqZnXab68GUO /MB7XLCuWl1FNm4zFVV/0VF9aDxY6aJZwTL/t+gsML3huTGJqB04aD0XCmy18TBa fNSiF7KU/EyPeQtY2TR9UYx2fsg7DEnaLFMbyEJR4Adg2mEU0qdheWDO5YhvoS9Z tHiPwC5D8ZGrP9XI3Mb0XUtN74qN8CLbvgylTk/5YWTYAOIlHf9ZzMviExhwkbPs Y1RQxjHOHxw0TKD5OjaVqWaEfHD817VFFDjbkUX9jMaOW+Arrzwik4zC4a6h0ef6 6PviqvuRb0DGO7aXw1qXnm0iUh75U7spiKFlrOA0Nd/OoXAoC8iD/E+LOcoe0mNR N7hPPd1ejqny6suBlOiLNCwQ9jlkGnYkyywkl5suZOKw/KNee9TW1ADhgmpkqhzQ 1vK1YL4syTC8wm+w9MG4xDyh+sNL0hY9z5jfAzfdl/hycUkxORxPLst6lEyYz/97 yhWQ8P7j2MzQ3j9q0x3c6Kkb7f9c6a0YLWS3glHAdGTADnGSXXFdhmvAplRWhgXq zS1FQNMQsQ61CUvu2t302lUucdIAFrB9ZYOHnR1nllO7gVvIPTrGphwQTNzFnPmo /D/a6GERTF/btw0bWj2S =ZPHv -----END PGP SIGNATURE----- --to1uSGBmQtEag2WO-- From owner-svn-src-head@FreeBSD.ORG Sun Jun 23 08:34:05 2013 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E26AFAEA; Sun, 23 Jun 2013 08:34:05 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail107.syd.optusnet.com.au (mail107.syd.optusnet.com.au [211.29.132.53]) by mx1.freebsd.org (Postfix) with ESMTP id 8AC731395; Sun, 23 Jun 2013 08:34:05 +0000 (UTC) Received: from c122-106-156-23.carlnfd1.nsw.optusnet.com.au (c122-106-156-23.carlnfd1.nsw.optusnet.com.au [122.106.156.23]) by mail107.syd.optusnet.com.au (Postfix) with ESMTPS id 3D49ED429F4; Sun, 23 Jun 2013 18:14:41 +1000 (EST) Date: Sun, 23 Jun 2013 18:14:34 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Konstantin Belousov Subject: Re: svn commit: r252032 - head/sys/amd64/include In-Reply-To: <20130623073004.GX91021@kib.kiev.ua> Message-ID: <20130623174151.N2256@besplex.bde.org> References: <201306201430.r5KEU4G5049115@svn.freebsd.org> <20130621065839.J916@besplex.bde.org> <20130621081116.E1151@besplex.bde.org> <20130621090207.F1318@besplex.bde.org> <20130621064901.GS1214@FreeBSD.org> <20130621184140.G848@besplex.bde.org> <20130621135427.GA1214@FreeBSD.org> <20130622110352.J2033@besplex.bde.org> <20130622124832.S2347@besplex.bde.org> <20130623073004.GX91021@kib.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=K8x6hFqI c=1 sm=1 a=0l9hOOMEwYoA:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=gvJhbHXk4isA:10 a=uTAS4SPU5wZF1UJIruoA:9 a=CjuIK1q_8ugA:10 a=ebeQFi2P/qHVC0Yw9JDJ4g==:117 Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, Gleb Smirnoff , src-committers@freebsd.org, Bruce Evans X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2013 08:34:06 -0000 On Sun, 23 Jun 2013, Konstantin Belousov wrote: > On Sat, Jun 22, 2013 at 01:37:58PM +1000, Bruce Evans wrote: >> On Sat, 22 Jun 2013, I wrote: >> >>> ... >>> Here are considerably expanded tests, with noninline tests dropped. >>> Summary of times on Athlon64: >>> >>> simple increment: 4-7 cycles (1) >>> simple increment preceded by feature test: 5-8 cycles (1) >>> simple 32-bit increment: 4-7 cycles (2) >>> correct 32-bit increment (addl to mem): 5.5-7 cycles (3) >>> inlined critical section: 8.5 cycles (4) >>> better inlined critical section: 7 cycles (5) >>> correct unsigned 32-bit inc of 64-bit counter: 4-7 cycles (6) >>> "improve" previous to allow immediate operand: 5+ cycles >>> correct signed 32-bit inc of 64-bit counter: 8.5-9 cycles (7) >>> correct 64-bit inc of 64-bit counter: 8-9 cycles (8) >>> -current method (cmpxchg8b): 18 cycles >> >> corei7 (freefall) has about the same timing as Athlon64, but core2 >> (ref10-i386) is 3-4 cycles slower for the tests that use cmpxchg. > You only tested 32 bit, right ? Note that core2-class machines have > at least one cycle penalty for decoding any instruction with REX prefix. Yes, since the 64-bit case works more or less correctly. I tested the 32-bit binary on 64-bit systems. >>> (4) The critical section method is quite fast when inlined. >>> (5) The critical section method is even faster when optimized. This is >>> what should be used if you don't want the complications for the >>> daemon. >> >> Oops, I forgot that critical sections are much slower in -current than >> in my version. They probably take 20-40 cycles for the best case, and >> can't easily be tested in userland since they disable interrupts in >> hardware. My versions disable interrupts in software. > The critical sections do not disable the interrupts. Only the thread > local counter is incremented. Leaving the section could be complicated > though. Yes, as I noticed later, it was only an old version of FreeBSD that disabled interrupts. The critical section method (or disabling interrupts, which is probably faster) only works for the non-SMP case, but old CPUs that don't have cmpxchg8b probably don't support SMP. >> Further tests confirm that incl and incq are pipelined normally on at >> least corei7 and core2. In the loop test, freefall can do 4 independent >> addq's to memory faster than it can do 1 :-). It can do 6 independent >> addq's to memory in the same time that it can do 1. After that, the >> loop overhead prevents geting the complete bandwidth of the memory >> system. However, 6 addq's to the same memory location take a little >> more than 6 times longer than 1. Multiple increments of the same counter >> one after the other are probably rare, but the counter API makes it harder >> to coaelsce them if they occur, and the implementation using independent >> asms ensures that the compiler cannot coalesce them. > > I think that the naive looping on Core i7+ to measure the latencies > of the instructions simply does not work. The Nehalem hardware started > to provide the loop detector for the instruction queue inside the decoder, > which essentially makes the short loops executed from the microopcode > form. We never use counters in the tight loops. The test results show it working perfectly in the test environment. Any loop detection just does a better job of running all the loop instructions in parallel with the instructions being timed. But even old CPUs can run all the loop instructions in parallel with high-latency instructions like add-to-memory. Also, add-to-memory instructions have strict ordering requirements on x86. The order must be load-modify-store. That's for storing to a single location. This prevents the loop running in parallel with itself, so its latency timing works especially simply. However, the test environment isn't normal. It is important to understand that some of the time is latency that doesn't matter in the normal environment. But in the complicated versions with cmpxchg8b's or critical sections, there are lots of extra instructions and ordering requirements whose latencies can't be hidden. Bruce From owner-svn-src-head@FreeBSD.ORG Sun Jun 23 09:41:48 2013 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 385CD5B8; Sun, 23 Jun 2013 09:41:48 +0000 (UTC) (envelope-from dteske@FreeBSD.org) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) by mx1.freebsd.org (Postfix) with ESMTP id 29C2616B3; Sun, 23 Jun 2013 09:41:48 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.7/8.14.7) with ESMTP id r5N9fmUi085018; Sun, 23 Jun 2013 09:41:48 GMT (envelope-from dteske@svn.freebsd.org) Received: (from dteske@localhost) by svn.freebsd.org (8.14.7/8.14.5/Submit) id r5N9flsQ085016; Sun, 23 Jun 2013 09:41:47 GMT (envelope-from dteske@svn.freebsd.org) Message-Id: <201306230941.r5N9flsQ085016@svn.freebsd.org> From: Devin Teske Date: Sun, 23 Jun 2013 09:41:47 +0000 (UTC) To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: svn commit: r252109 - head/usr.sbin/bsdconfig/share/media X-SVN-Group: head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2013 09:41:48 -0000 Author: dteske Date: Sun Jun 23 09:41:47 2013 New Revision: 252109 URL: http://svnweb.freebsd.org/changeset/base/252109 Log: Fine-tune the parsing of the URL. Re-order, comment, and add debugging to each case of unique URL format. Modified: head/usr.sbin/bsdconfig/share/media/ftp.subr head/usr.sbin/bsdconfig/share/media/httpproxy.subr Modified: head/usr.sbin/bsdconfig/share/media/ftp.subr ============================================================================== --- head/usr.sbin/bsdconfig/share/media/ftp.subr Sun Jun 23 09:34:55 2013 (r252108) +++ head/usr.sbin/bsdconfig/share/media/ftp.subr Sun Jun 23 09:41:47 2013 (r252109) @@ -378,27 +378,62 @@ f_media_set_ftp() local hostname="${url#*://}" port=21 dir=/ case "$hostname" in - "["*"]") + # + # The order in-which the below individual cases appear is important! + # + "["*"]":*/*) # IPv6 address with port and directory + f_dprintf "Looks like an IPv6 addr with port/dir: %s" \ + "$hostname" hostname="${hostname#\[}" - hostname="${hostname%%\]*}" + port="${hostname#*\]:}" + port="${port%%[!0-9]*}" + dir="/${hostname#*/}" + hostname="${hostname%%\]:*}" ;; - "["*"]/"*) + "["*"]":*) # IPv6 address with port + f_dprintf "Looks like an IPv6 addr with port: %s" "$hostname" hostname="${hostname#\[}" - dir="/${hostname#*/}" - hostname="${hostname%%\]*}" + port="${hostname#*\]:}" + port="${port%%[!0-9]*}" + hostname="${hostname%%\]:*}" ;; - *"/"*) + "["*"]"/*) # IPv6 address with directory + f_dprintf "Looks like an IPv6 addr with dir: %s" "$hostname" + hostname="${hostname#\[}" dir="/${hostname#*/}" - hostname="${hostname%%/*}" + hostname="${hostname%%\]*}" ;; - "["*"]:"*) + "["*"]") # IPv6 address + f_dprintf "Looks like an IPv6 addr: %s" "$hostname" hostname="${hostname#\[}" - port="${hostname#*\]:}" + hostname="${hostname%\]}" + ;; + # + # ^^^ IPv6 above / DNS Name or IPv4 below vvv + # + *:*/*) # DNS name or IPv4 address with port and directory + f_dprintf "Looks like a %s with port/dir: %s" \ + "DNS name or IPv4 addr" "$hostname" + port="${hostname#*:}" port="${port%%[!0-9]*}" - hostname="${hostname%%\]:*}" + dir="/${hostname#*/}" + hostname="${hostname%%:*}" + ;; + *:*) # DNS name or IPv4 address with port + f_dprintf "Looks like a DNS name or IPv4 addr with port: %s" \ + "$hostname" + port="${hostname#*:}" + hostname="${hostname%%:*}" ;; - *) + */*) # DNS name or IPv4 address with directory + f_dprintf "Looks like a DNS name or IPv4 addr with dir: %s" \ + "$hostname" + dir="/${hostname#*/}" hostname="${hostname%%/*}" + ;; + *) # DNS name or IPv4 address + f_dprintf "Looks like a DNS name or IPv4 addr: %s" "$hostname" + : leave hostname as-is esac f_dprintf "hostname = \`%s'" "$hostname" Modified: head/usr.sbin/bsdconfig/share/media/httpproxy.subr ============================================================================== --- head/usr.sbin/bsdconfig/share/media/httpproxy.subr Sun Jun 23 09:34:55 2013 (r252108) +++ head/usr.sbin/bsdconfig/share/media/httpproxy.subr Sun Jun 23 09:41:47 2013 (r252109) @@ -77,19 +77,33 @@ f_media_set_http_proxy() local hostname="$proxy" port=3128 case "$hostname" in - "["*"]") - hostname="${hostname#\[}" - hostname="${hostname%\]}" - ;; - "["*"]:"*) + # + # The order in-which the below individual cases appear is important! + # + "["*"]":*) # IPv6 address with port + f_dprintf "Looks like an IPv6 addr with port: %s" "$hostname" hostname="${hostname#\[}" port="${hostname#*\]:}" port="${port%%[!0-9]*}" hostname="${hostname%%\]:*}" ;; - *":"*) + "["*"]") # IPv6 address + f_dprintf "Looks like an IPv6 addr: %s" "$hostname" + hostname="${hostname#\[}" + hostname="${hostname%\]}" + ;; + # + # ^^^ IPv6 above / DNS Name or IPv4 below vvv + # + *:*) # DNS name or IPv4 address with port + f_dprintf "Looks like a DNS name or IPv4 addr with port: %s" \ + "$hostname" port="${hostname#*:}" hostname="${hostname%%:*}" + ;; + *) # DNS name or IPv4 address + f_dprintf "Looks like a DNS name or IPv4 addr: %s" "$hostname" + : leave hostname as-is esac setvar $VAR_HTTP_PROXY_HOST "$hostname" From owner-svn-src-head@FreeBSD.ORG Sun Jun 23 09:58:00 2013 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D780997D; Sun, 23 Jun 2013 09:58:00 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail104.syd.optusnet.com.au (mail104.syd.optusnet.com.au [211.29.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id 548521729; Sun, 23 Jun 2013 09:57:59 +0000 (UTC) Received: from c122-106-156-23.carlnfd1.nsw.optusnet.com.au (c122-106-156-23.carlnfd1.nsw.optusnet.com.au [122.106.156.23]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id E9AE74205F7; Sun, 23 Jun 2013 19:57:57 +1000 (EST) Date: Sun, 23 Jun 2013 19:57:57 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Konstantin Belousov Subject: Re: svn commit: r252032 - head/sys/amd64/include In-Reply-To: <20130623073343.GY91021@kib.kiev.ua> Message-ID: <20130623181458.J2256@besplex.bde.org> References: <201306201430.r5KEU4G5049115@svn.freebsd.org> <20130621065839.J916@besplex.bde.org> <20130621081116.E1151@besplex.bde.org> <20130621090207.F1318@besplex.bde.org> <20130621064901.GS1214@FreeBSD.org> <20130621184140.G848@besplex.bde.org> <20130621135427.GA1214@FreeBSD.org> <20130622110352.J2033@besplex.bde.org> <20130622124832.S2347@besplex.bde.org> <20130622174921.I3112@besplex.bde.org> <20130623073343.GY91021@kib.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=eqSHVfVX c=1 sm=1 a=0l9hOOMEwYoA:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=gvJhbHXk4isA:10 a=7Rx_JezBbeIR9hiCpAQA:9 a=CjuIK1q_8ugA:10 a=ebeQFi2P/qHVC0Yw9JDJ4g==:117 Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, Gleb Smirnoff , src-committers@freebsd.org, Bruce Evans X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2013 09:58:00 -0000 On Sun, 23 Jun 2013, Konstantin Belousov wrote: > On Sat, Jun 22, 2013 at 06:58:15PM +1000, Bruce Evans wrote: >> So the i386 version be simply "addl; adcl" to memory. Each store in >> this is atomic at the per-CPU level. If there is no carry, then the >> separate stores are equivalent to adding separate nonnegative values and >> the counter value is valid at all times. If there is carry, then the >> separate stores are equivalent to adding a negative value followed by >> a larger positive value. The counter transiently goes backwards, but >> no information is lost and the counter is eventually set to the correct >> forward-going value. > > This is quite interesting idea, but I still did not decided if it > acceptable. The issue is that we could add the carry to the other > processor counter, if the preemption kicks in at right time between > two instructions. I did not found any argument why would it be > wrong, the races for fetch operation seems to be the same with either > local update method. I thought about exploiting not-so-strong memory ordering to fix the fetches. On at least x86, stores are not reordered, so if the storer does a simple "addl, adcl", then the order is not much different from load low 32 bits store low 32 bits load high 32 bits store high 32 bits The loads can be in any order, but must be before the stores to the same location. I think the fetching code can depend on this (maybe only on x86, but the fetching code needs to be MD anyway). Thus it can detect most races by simply rereading the counters in almost any order until they don't change. Without this, the fetching code can easily read high and low bits from unrelated stores (when it is preempted, the race window is large), and the sophisticated cmpxchg8b code to make each store atomic is almost useless. The case that can't be fixed by rereading the counters is when fetching code runs in between the stores. If the stores are on a another CPU that is currently executing them, then we can keep checking that the counters don't change for the maximum time that any pair of stores take to complete. This time is quite long and difficult to determine (but it can be bounded by hard-disabling interrupts in the storer, and limited by prefetching). If the stores are on the same CPU, then we have no good way to detect that another thread is in the middle of them, or to switch back to that thread. So we currently prevent this case using slow methods. > On the other hand, for debugging it would be quite confusing state of > the counters array to observe. I thought of lots of variations, but couldn't find one that works perfectly. One idea (that goes with the sign check on the low 32 bits) is to use a misaligned add to memory to copy the 31st bit as a carry bit to the the high word. The value of the counter is supposed to be [unsigned value of low 32 bits] + [unsigned value of next 24 bits] << 31 (high 8 bits not used) at all times, with the 31st bit zero at most times so that the the carry operation is rarely executed. This format is only slightly confusing for debugging (it basically has 2 31st bits, with the one in the low 32 bits rarely used). This format can be updated using something like: addl %1,%%fs:(%0) # only small 32-bit increments supported jns 8f addl $0x80,%%fs:3(%0) # misaligned memory access 8: ; No problem if this is not preempted. The idea of the misaligned memory access is that the CPU needs to make this atomic enough even though it crosses a 32-bit boundary. BTW, is anything guaranteed if the access also crosses a cache line or page boundary? The OS would be involved for page boundaries if there is a page fault. Better not step on bugs in that. What about for misaligned 64-bit or 128-bit stores done by cmpxchg8b or SSE? Counters are 64-bit aligned, so I think that at least CPUs that are basically 64-bit must handle this like I want. The above doesn't work if it is preempted -- then it might add do the carry operation more than once. But it is easy to lock using cmpxchg or disabling interrupts. Disabling interrupts requires only small code: addl %1,%%fs:(%0) # only small 32-bit increments supported jns 8f pushfl cli testb $0x80,%%fs:3(%0) je 1f # carry already done by preemption addl $0x80,%%fs:3(%0) # misaligned memory access 1: popfl 8: ; Another idea is to use the high bits of the high word to encode state. They can be set atomically enough using addl/andl/orl/xorl since they are per-CPU. I couldn't quite get this to work. You could increment them to indicate an update in progress. This only requires 1 extra add to memory if the adcl is always done (e.g., first add 0x0100000000 to the high word; then addl to the low word; then adcl of (inc >> 32) - 0x01000000 to the high word. Increments must be limited to not change the state bits of course. The fetching code can easily examine these bits to learn that there is a problem, but it has no good way of handling the problem. The code that set the bits might have been preempted by the fetching code. It takes something like mutex priority propagation to get back to the code that clears finishes the update and clears the state. But we are intentionally not using full mutexes. Bruce From owner-svn-src-head@FreeBSD.ORG Sun Jun 23 10:04:24 2013 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0CA46BB0; Sun, 23 Jun 2013 10:04:24 +0000 (UTC) (envelope-from dteske@FreeBSD.org) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) by mx1.freebsd.org (Postfix) with ESMTP id F32121761; Sun, 23 Jun 2013 10:04:23 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.7/8.14.7) with ESMTP id r5NA4Nmu090919; Sun, 23 Jun 2013 10:04:23 GMT (envelope-from dteske@svn.freebsd.org) Received: (from dteske@localhost) by svn.freebsd.org (8.14.7/8.14.5/Submit) id r5NA4NB8090918; Sun, 23 Jun 2013 10:04:23 GMT (envelope-from dteske@svn.freebsd.org) Message-Id: <201306231004.r5NA4NB8090918@svn.freebsd.org> From: Devin Teske Date: Sun, 23 Jun 2013 10:04:23 +0000 (UTC) To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: svn commit: r252110 - head/usr.sbin/bsdconfig/share/media X-SVN-Group: head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2013 10:04:24 -0000 Author: dteske Date: Sun Jun 23 10:04:23 2013 New Revision: 252110 URL: http://svnweb.freebsd.org/changeset/base/252110 Log: Implement the $probe_only parameter (previously unimplemented). Modified: head/usr.sbin/bsdconfig/share/media/httpproxy.subr Modified: head/usr.sbin/bsdconfig/share/media/httpproxy.subr ============================================================================== --- head/usr.sbin/bsdconfig/share/media/httpproxy.subr Sun Jun 23 09:41:47 2013 (r252109) +++ head/usr.sbin/bsdconfig/share/media/httpproxy.subr Sun Jun 23 10:04:23 2013 (r252110) @@ -333,8 +333,10 @@ f_media_init_http_proxy() # # Returns data from $file on an FTP server via HTTP proxy using nc(1). Please # note that $device is unused but must be present (even if null). Information -# is instead gathered from the environment. $probe_only is currently unused by -# this media type. +# is instead gathered from the environment. If $probe_only is both present and +# non-NULL, this function exits after receiving the HTTP header response from +# the proxy server (if the HTTP response code is 200, success is returned; +# otherwise failure). # # The variables used to configure the connection are as follows (all of which # are configured by f_media_set_http_proxy above): @@ -425,11 +427,14 @@ f_media_get_http_proxy() [ $rv -ge 300 ] && exit 3 [ $rv -eq 200 ] || exit $FAILURE - cat # output the rest ``as-is'' + if [ ! "$probe_only" ]; then + cat # output the rest ``as-is'' + fi exit 200 ) local retval=$? [ $retval -eq 200 ] && return $SUCCESS + [ "$probe_only" ] && return $FAILURE case "$retval" in 5) f_show_msg "$msg_server_error_when_requesting_url" "$url" ;; From owner-svn-src-head@FreeBSD.ORG Sun Jun 23 10:48:28 2013 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 45D7733F; Sun, 23 Jun 2013 10:48:28 +0000 (UTC) (envelope-from dteske@FreeBSD.org) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) by mx1.freebsd.org (Postfix) with ESMTP id 36D751840; Sun, 23 Jun 2013 10:48:28 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.7/8.14.7) with ESMTP id r5NAmSNA002682; Sun, 23 Jun 2013 10:48:28 GMT (envelope-from dteske@svn.freebsd.org) Received: (from dteske@localhost) by svn.freebsd.org (8.14.7/8.14.5/Submit) id r5NAmQA8002673; Sun, 23 Jun 2013 10:48:26 GMT (envelope-from dteske@svn.freebsd.org) Message-Id: <201306231048.r5NAmQA8002673@svn.freebsd.org> From: Devin Teske Date: Sun, 23 Jun 2013 10:48:26 +0000 (UTC) To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: svn commit: r252112 - in head/usr.sbin/bsdconfig: include share share/media X-SVN-Group: head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2013 10:48:28 -0000 Author: dteske Date: Sun Jun 23 10:48:26 2013 New Revision: 252112 URL: http://svnweb.freebsd.org/changeset/base/252112 Log: Merge r248313 from stable/9 sysinstall(8) to head bsdconfig(8): Add support for installation directly via HTTP. While we're here, remove the menu-item for Passive FTP (since moving to ftp(1) and switching FTPMODE to `auto' by default -- see r251613 -- the single remaining FTP menu-item works for both ftp.f.o and ftp-archive.f.o; previously each requiring separately active versus passive both work with the `auto' setting). In scripting you still have mediaSetFTPActive and mediaSetFTPPassive but the remaining FTP menu-item uses mediaSetFTP which defaults to `auto' (aforementioned SVN r251613). Added: head/usr.sbin/bsdconfig/share/media/http.subr (contents, props changed) Modified: head/usr.sbin/bsdconfig/include/media.hlp head/usr.sbin/bsdconfig/include/messages.subr head/usr.sbin/bsdconfig/share/device.subr head/usr.sbin/bsdconfig/share/media/Makefile head/usr.sbin/bsdconfig/share/media/any.subr head/usr.sbin/bsdconfig/share/media/options.subr head/usr.sbin/bsdconfig/share/script.subr head/usr.sbin/bsdconfig/share/variable.subr Modified: head/usr.sbin/bsdconfig/include/media.hlp ============================================================================== --- head/usr.sbin/bsdconfig/include/media.hlp Sun Jun 23 10:16:14 2013 (r252111) +++ head/usr.sbin/bsdconfig/include/media.hlp Sun Jun 23 10:48:26 2013 (r252112) @@ -25,13 +25,11 @@ You can install from the following types FTP Get the distribution files from an anonymous ftp server (you will be presented with a list). Please note that - you may invoke FTP in "Active" mode, "Passive" mode, or + you may invoke FTP in "Active"/"Passive" auto-mode, or via an HTTP proxy. - Active mode is the standard way of fetching files and - Passive mode is for use when you're behind a firewall or - some other security mechanism that blocks active FTP - connections. Using an HTTP proxy is sometimes necessary + By default, ftp(1) will automatically use the best mode + for the server. Using an HTTP proxy is sometimes necessary for firewalls which block all FTP connections. If you chose to enter your own URL in the FTP menu, please @@ -41,6 +39,14 @@ You can install from the following types Options screen. + HTTP Direct + Get the distribution files directly from an HTTP server. + + If you chose to enter your own URL in the HTTP Direct menu, + please note that all paths are *relative* to the root + directory of the web server. + + NFS Get the distribution files from an NFS server somewhere (make sure that permissions on the server allow this!). If this install method hangs on you or refuses to work Modified: head/usr.sbin/bsdconfig/include/messages.subr ============================================================================== --- head/usr.sbin/bsdconfig/include/messages.subr Sun Jun 23 10:16:14 2013 (r252111) +++ head/usr.sbin/bsdconfig/include/messages.subr Sun Jun 23 10:48:26 2013 (r252112) @@ -87,6 +87,7 @@ msg_could_not_unmount_the_nfs_partition= msg_could_not_unmount_the_ufs_partition="Could not unmount the UFS partition from %s: %s" msg_couldnt_connect_to_ftp_server="Couldn't connect to FTP server" msg_couldnt_connect_to_proxy="Couldn't connect to proxy" +msg_couldnt_connect_to_server="Couldn't connect to server" msg_couldnt_open_ftp_connection="Couldn't open FTP connection to %s:\n %s." msg_created_path="Created %s" msg_croatia="Croatia" @@ -148,7 +149,7 @@ msg_hebrew_desc="Ported software for Heb msg_help="Help" msg_host_name_including_domain="Host name (including domain)" msg_hostname_variable_not_set="WARNING: hostname variable not set and is a non-optional\nparameter. Please add this to your installation script\nor set the netInteractive variable (see bsdconfig man page)" -msg_http="HTTP" +msg_http_direct="HTTP Direct" msg_http_proxy="HTTP Proxy" msg_hungarian_desc="Ported software for the Hungarian market." msg_hungary="Hungary" @@ -161,6 +162,7 @@ msg_install_from_a_usb_drive="Install fr msg_install_from_an_ftp_server="Install from an FTP server" msg_install_from_an_ftp_server_thru_firewall="Install from an FTP server through a firewall" msg_install_from_an_ftp_server_thru_proxy="Install from an FTP server through an HTTP proxy" +msg_install_from_an_http_server="Install from an HTTP server" msg_install_from_the_existing_filesystem="Install from the existing filesystem" msg_install_over_nfs="Install over NFS" msg_installed="Installed" @@ -270,6 +272,7 @@ msg_please_select_a_category_to_display= msg_please_select_a_cd_dvd_drive="FreeBSD can be installed directly from a CD/DVD containing a valid\nFreeBSD distribution. If you are seeing this menu it is because\nmore than one CD/DVD drive was found on your system. Please select\none of the following CD/DVD drives as your installation drive." msg_please_select_a_floppy_drive="You have more than one floppy drive. Please choose which drive\nyou would like to use." msg_please_select_a_freebsd_ftp_distribution_site="Please select a FreeBSD FTP distribution site" +msg_please_select_a_freebsd_http_distribution_site="Please select a FreeBSD HTTP distribution site" msg_please_select_a_usb_drive="You have more than one USB drive. Please choose which drive\nyou would like to use." msg_please_select_dos_partition="FreeBSD can be installed directly from a DOS partition assuming,\nof course, that you have copied the relevant distributions into\nyour DOS partition before starting this installation. If this is\nnot the case then you should reboot DOS at this time and copy the\ndistributions you wish to install into a \"FREEBSD\" subdirectory\non one of your DOS partitions. Otherwise, please select the DOS\npartition containing the FreeBSD distribution files." msg_please_select_ethernet_device_to_configure="Please select the ethernet or PLIP device to configure." @@ -280,6 +283,7 @@ msg_please_specify_the_name_of_the_text_ msg_please_specify_the_number_of_seconds_to_wait="Please specify the number of seconds to wait for slow media:" msg_please_specify_the_release_you_wish_to_load="Please specify the release you wish to load or\n\"any\" for a generic release install:" msg_please_specify_url_of_a_freebsd_distribution="Please specify the URL of a FreeBSD distribution on a\nremote ftp site. This site must accept either anonymous\nftp or you should have set an ftp username and password\nin the Options screen.\n\nA URL looks like this: ftp:///\nWhere is relative to the anonymous ftp directory or the\nhome directory of the user being logged in as." +msg_please_specify_url_of_freebsd_http_distribution="Please specify the URL of a FreeBSD distribution on a\nremote http site.\nA URL looks like this: http:///" msg_poland="Poland" msg_polish_desc="Ported software for the Polish market." msg_ports_mgmt_desc="Utilities for managing ports and packages." @@ -302,6 +306,7 @@ msg_rescan_devices="Re-scan Devices" msg_reset="RESET!" msg_reset_all_values_to_startup_defaults="Reset all values to startup defaults" msg_reuse_old_ftp_site_selection_values="Re-use old FTP site selection values?" +msg_reuse_old_http_site_settings="Re-use old HTTP site settings?" msg_review="Review" msg_review_desc="Review/perform pending actions" msg_review_help="Install, Re-Install, or Un-install selected packages and dependencies" @@ -334,6 +339,7 @@ msg_south_africa="South Africa" msg_spain="Spain" msg_spanish_desc="Ported software for the Spanish market." msg_specify_some_other_ftp_site="Specify some other ftp site by URL" +msg_specify_some_other_http_site="Specify some other http site by URL" msg_sweden="Sweden" msg_switzerland="Switzerland" msg_sysutils_desc="Various system utilities." Modified: head/usr.sbin/bsdconfig/share/device.subr ============================================================================== --- head/usr.sbin/bsdconfig/share/device.subr Sun Jun 23 10:16:14 2013 (r252111) +++ head/usr.sbin/bsdconfig/share/device.subr Sun Jun 23 10:48:26 2013 (r252112) @@ -73,6 +73,7 @@ setvar DEVICE_TYPE_UFS 9 setvar DEVICE_TYPE_NFS 10 setvar DEVICE_TYPE_ANY 11 setvar DEVICE_TYPE_HTTP_PROXY 12 +setvar DEVICE_TYPE_HTTP 13 # # Default behavior is to call f_device_get_all() automatically when loaded. Modified: head/usr.sbin/bsdconfig/share/media/Makefile ============================================================================== --- head/usr.sbin/bsdconfig/share/media/Makefile Sun Jun 23 10:16:14 2013 (r252111) +++ head/usr.sbin/bsdconfig/share/media/Makefile Sun Jun 23 10:48:26 2013 (r252112) @@ -4,8 +4,8 @@ NO_OBJ= FILESDIR= ${SHAREDIR}/bsdconfig/media FILES= any.subr cdrom.subr common.subr directory.subr dos.subr \ - floppy.subr ftp.subr httpproxy.subr network.subr nfs.subr \ - options.subr tcpip.subr ufs.subr usb.subr + floppy.subr ftp.subr http.subr httpproxy.subr network.subr \ + nfs.subr options.subr tcpip.subr ufs.subr usb.subr beforeinstall: mkdir -p ${DESTDIR}${FILESDIR} Modified: head/usr.sbin/bsdconfig/share/media/any.subr ============================================================================== --- head/usr.sbin/bsdconfig/share/media/any.subr Sun Jun 23 10:16:14 2013 (r252111) +++ head/usr.sbin/bsdconfig/share/media/any.subr Sun Jun 23 10:48:26 2013 (r252112) @@ -37,6 +37,7 @@ f_include $BSDCFG_SHARE/media/directory. f_include $BSDCFG_SHARE/media/dos.subr f_include $BSDCFG_SHARE/media/floppy.subr f_include $BSDCFG_SHARE/media/ftp.subr +f_include $BSDCFG_SHARE/media/http.subr f_include $BSDCFG_SHARE/media/httpproxy.subr f_include $BSDCFG_SHARE/media/nfs.subr f_include $BSDCFG_SHARE/media/options.subr @@ -71,9 +72,9 @@ f_media_get_type() local menu_list=" '1 $msg_cd_dvd' '$msg_install_from_a_freebsd_cd_dvd' '2 $msg_ftp' '$msg_install_from_an_ftp_server' - '3 $msg_ftp_passive' - '$msg_install_from_an_ftp_server_thru_firewall' - '4 $msg_http' '$msg_install_from_an_ftp_server_thru_proxy' + '3 $msg_http_proxy' + '$msg_install_from_an_ftp_server_thru_proxy' + '4 $msg_http_direct' '$msg_install_from_an_http_server' '5 $msg_directory' '$msg_install_from_the_existing_filesystem' '6 $msg_nfs' '$msg_install_over_nfs' '7 $msg_dos' '$msg_install_from_a_dos_partition' @@ -123,8 +124,8 @@ f_media_get_type() case "$mtag" in ?" $msg_cd_dvd") f_media_set_cdrom ;; ?" $msg_ftp") f_media_set_ftp ;; - ?" $msg_ftp_passive") f_media_set_ftp_passive ;; - ?" $msg_http") f_media_set_http_proxy ;; + ?" $msg_http_proxy") f_media_set_http_proxy ;; + ?" $msg_http_direct") f_media_set_http ;; ?" $msg_directory") f_media_set_directory ;; ?" $msg_dos") f_media_set_dos ;; ?" $msg_nfs") f_media_set_nfs ;; Added: head/usr.sbin/bsdconfig/share/media/http.subr ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ head/usr.sbin/bsdconfig/share/media/http.subr Sun Jun 23 10:48:26 2013 (r252112) @@ -0,0 +1,635 @@ +if [ ! "$_MEDIA_HTTP_SUBR" ]; then _MEDIA_HTTP_SUBR=1 +# +# Copyright (c) 2012-2013 Devin Teske +# All Rights Reserved. +# +# Redistribution and use in source and binary forms, with or without +# modification, are permitted provided that the following conditions +# are met: +# 1. Redistributions of source code must retain the above copyright +# notice, this list of conditions and the following disclaimer. +# 2. Redistributions in binary form must reproduce the above copyright +# notice, this list of conditions and the following disclaimer in the +# documentation and/or other materials provided with the distribution. +# +# THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND +# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING BUT NOT LIMITED TO, THE +# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE +# ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE +# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL +# DAMAGES (INLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS +# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) +# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT +# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY +# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF +# SUCH DAMAGE. +# +# $FreeBSD$ +# +############################################################ INCLUDES + +BSDCFG_SHARE="/usr/share/bsdconfig" +. $BSDCFG_SHARE/common.subr || exit 1 +f_dprintf "%s: loading includes..." media/http.subr +f_include $BSDCFG_SHARE/device.subr +f_include $BSDCFG_SHARE/dialog.subr +f_include $BSDCFG_SHARE/media/common.subr +f_include $BSDCFG_SHARE/media/tcpip.subr +f_include $BSDCFG_SHARE/strings.subr +f_include $BSDCFG_SHARE/struct.subr +f_include $BSDCFG_SHARE/variable.subr + +BSDCFG_LIBE="/usr/libexec/bsdconfig" +f_include_lang $BSDCFG_LIBE/include/messages.subr + +############################################################ GLOBALS + +HTTP_SKIP_RESOLV= + +URL_MAX=261261 + # NOTE: This is according to actual fetch(1) test-results. We actually + # use nc(1) to retrieve files, but it's still a good idea to keep the + # URLs short enough that fetch(1) won't complain. + +HTTP_DIRS=" + . + releases/$UNAME_P + snapshots/$UNAME_P + pub/FreeBSD + pub/FreeBSD/releases/$UNAME_P + pub/FreeBSD/snapshots/$UNAME_P + pub/FreeBSD-Archive/old-releases/$UNAME_P +" # END-QUOTE + +############################################################ FUNCTIONS + +# f_dialog_menu_media_http +# +# Prompt the user to select from a range of ``built-in'' HTTP servers or +# specify their own. If the user makes a choice and doesn't cancel or press +# Esc, stores the user's choice in VAR_FTP_PATH (see variable.subr) and returns +# success. +# +f_dialog_menu_media_http() +{ + f_dialog_title "$msg_please_select_a_freebsd_http_distribution_site" + local title="$DIALOG_TITLE" btitle="$DIALOG_BACKTITLE" + f_dialog_title_restore + local prompt="$msg_please_select_the_site_closest_to_you_or_other" + local menu_list=" + 'URL' '$msg_specify_some_other_http_site' + " # END-QUOTE + local hline="$msg_select_a_site_thats_close" + + local height width rows + eval f_dialog_menu_size height width rows \ + \"\$title\" \ + \"\$btitle\" \ + \"\$prompt\" \ + \"\$hline\" \ + $menu_list + + local mtag + mtag=$( eval $DIALOG \ + --title \"\$title\" \ + --backtitle \"\$btitle\" \ + --hline \"\$hline\" \ + --ok-label \"\$msg_ok\" \ + --cancel-label \"\$msg_cancel\" \ + --menu \"\$prompt\" \ + $height $width $rows \ + $menu_list \ + 2>&1 >&$DIALOG_TERMINAL_PASSTHRU_FD + ) || return $FAILURE + f_dialog_data_sanitize mtag + + case "$mtag" in + URL) setvar $VAR_HTTP_PATH "other" ;; + *) + local value + value=$( eval f_dialog_menutag2item \"\$mtag\" $menu_list ) + setvar $VAR_HTTP_PATH "http://$value" + esac + + return $SUCCESS +} + +# f_media_set_http +# +# Return success if we both found and set the media type to be an HTTP server. +# +# Variables from variable.subr that can be used to script user input: +# +# VAR_HTTP_PATH +# URL containing host and optionally a target path to the release +# repository on the HTTP server. Valid examples include: +# http://myhost +# http://somename:80/pub/ +# http://192.168.2.3/pub/ +# http://[::1]:8000/ +# The default port if not specified is 80. +# VAR_NAMESERVER [Optional] +# If set, overrides resolv.conf(5) and sets the nameserver that +# is used to convert names into addresses (when a name converts +# into multiple addresses, the first address to successfully +# connect is used). +# +# Meanwhile, the following variables from variable.subr are set after +# successful execution: +# +# VAR_HTTP_HOST +# The HTTP host to connect to, parsed from VAR_HTTP_PATH. In the +# example case of IPv6 where VAR_HTTP_PATH is "http://[::1]" this +# variable will be set to "::1" (the outer brackets are removed). +# VAR_HTTP_PORT +# The TCP port to connect to, parsed from VAR_HTTP_PATH. Usually +# 80 unless VAR_HTTP_PATH was one of the following forms: +# http://hostname:OTHER_PORT +# http://hostname:OTHER_PORT/* +# http://ip:OTHER_PORT +# http://ip:OTHER_PORT/* +# http://[ip6]:OTHER_PORT +# http://[ip6]:OTHER_PORT/* +# VAR_HTTP_DIR +# If VAR_HTTP_PATH contained a directory element (e.g., +# "http://localhost/pub") this variable contains only the +# directory element (e.g., "/pub"). +# +f_media_set_http() +{ + f_media_close + + local url + f_getvar $VAR_HTTP_PATH url + + # If we've been through here before ... + if f_struct device_network && [ "${url#$msg_other}" ]; then + f_dialog_yesno "$msg_reuse_old_http_site_settings" || url= + fi + + if [ ! "$url" ]; then + f_dialog_menu_media_http || return $FAILURE + f_getvar $VAR_HTTP_PATH url + fi + [ "$url" ] || return $FAILURE + + case "$url" in + other) + setvar $VAR_HTTP_PATH "http://" + f_variable_get_value $VAR_HTTP_PATH \ + "$msg_please_specify_url_of_freebsd_http_distribution" + f_getvar $VAR_HTTP_PATH url + if [ ! "${url#http://}" ]; then + unset $VAR_HTTP_PATH + return $FAILURE + fi + if [ ${#url} -gt ${URL_MAX:-261261} ]; then + f_show_msg "$msg_length_of_specified_url_is_too_long" \ + ${#url} ${URL_MAX:-261261} + unset $VAR_HTTP_PATH + return $FAILURE + fi + case "$url" in + http://*) : valid URL ;; + *) + f_show_msg "$msg_sorry_invalid_url" "$url" + unset $VAR_HTTP_PATH + return $FAILURE + esac + esac + case "$url" in + http://*) : valid URL ;; + *) + f_show_msg "$msg_sorry_invalid_url" "$url" + unset $VAR_HTTP_PATH + return $FAILURE + esac + + # Set the name of the HTTP device to the URL + f_struct_new DEVICE device_http + device_http set name "$url" + + if ! f_struct device_network || + ! f_dialog_yesno "$msg_youve_already_done_the_network_configuration" + then + f_struct device_network && + f_device_shutdown network + if ! f_device_select_tcp; then + unset $VAR_HTTP_PATH + return $FAILURE + fi + local dev + f_getvar $VAR_NETWORK_DEVICE dev + f_struct_copy "device_$dev" device_network + fi + if ! f_device_init network; then + f_dprintf "f_media_set_http: %s" "$msg_net_device_init_failed" + unset $VAR_HTTP_PATH + return $FAILURE + fi + + local hostname="${url#*://}" port=80 dir=/ + case "$hostname" in + # + # The order in-which the below individual cases appear is important! + # + "["*"]":*/*) # IPv6 address with port and directory + f_dprintf "Looks like an IPv6 addr with port/dir: %s" \ + "$hostname" + hostname="${hostname#\[}" + port="${hostname#*\]:}" + port="${port%%[!0-9]*}" + dir="/${hostname#*/}" + hostname="${hostname%%\]:*}" + ;; + "["*"]":*) # IPv6 address with port + f_dprintf "Looks like an IPv6 addr with port: %s" "$hostname" + hostname="${hostname#\[}" + port="${hostname#*\]:}" + port="${port%%[!0-9]*}" + hostname="${hostname%%\]:*}" + ;; + "["*"]"/*) # IPv6 address with directory + f_dprintf "Looks like an IPv6 addr with dir: %s" "$hostname" + hostname="${hostname#\[}" + dir="/${hostname#*/}" + hostname="${hostname%%\]*}" + ;; + "["*"]") # IPv6 address + f_dprintf "Looks like an IPv6 addr: %s" "$hostname" + hostname="${hostname#\[}" + hostname="${hostname%\]}" + ;; + # + # ^^^ IPv6 above / DNS Name or IPv4 below vvv + # + *:*/*) # DNS name or IPv4 address with port and directory + f_dprintf "Looks like a %s with port/dir: %s" \ + "DNS name or IPv4 addr" "$hostname" + port="${hostname#*:}" + port="${port%%[!0-9]*}" + dir="/${hostname#*/}" + hostname="${hostname%%:*}" + ;; + *:*) # DNS name or IPv4 address with port + f_dprintf "Looks like a DNS name or IPv4 addr with port: %s" \ + "$hostname" + port="${hostname#*:}" + hostname="${hostname%%:*}" + ;; + */*) # DNS name or IPv4 address with directory + f_dprintf "Looks like a DNS name or IPv4 addr with dir: %s" \ + "$hostname" + dir="/${hostname#*/}" + hostname="${hostname%%/*}" + ;; + *) # DNS name or IPv4 address + f_dprintf "Looks like a DNS name or IPv4 addr: %s" "$hostname" + : leave hostname as-is + esac + + f_dprintf "hostname = \`%s'" "$hostname" + f_dprintf "dir = \`%s'" "$dir" + f_dprintf "port \# = \`%d'" "$port" + + local ns + f_getvar $VAR_NAMESERVER ns + [ "$ns" ] || f_resolv_conf_nameservers ns + if [ "$ns" -a ! "$HTTP_SKIP_RESOLV" ] && ! { + f_validate_ipaddr "$hostname" || + f_validate_ipaddr6 "$hostname" + }; then + f_show_info "$msg_looking_up_host" "$hostname" + f_dprintf "%s: Looking up hostname, %s, using host(1)" \ + "f_media_set_http" "$hostname" + if ! f_quietly f_host_lookup "$hostname"; then + f_show_msg "$msg_cannot_resolve_hostname" "$hostname" + f_struct device_network && + f_device_shutdown network + f_struct_free device_network + unset $VAR_HTTP_PATH + return $FAILURE + fi + f_dprintf "Found DNS entry for %s successfully." "$hostname" + fi + + setvar $VAR_HTTP_HOST "$hostname" + setvar $VAR_HTTP_PORT "$port" + setvar $VAR_HTTP_DIR "$dir" + + device_http set type $DEVICE_TYPE_HTTP + device_http set init f_media_init_http + device_http set get f_media_get_http + device_http set shutdown f_media_shutdown_http + device_http set private network + f_struct_copy device_http device_media + f_struct_free device_http + + return $SUCCESS +} + +# f_http_check_access [$connect_only] +# +# Return success if able list a remote HTTP directory. If $connect_only is +# present and non-null, then returns success if a connection can be made. +# Variables from variable.subr that can be used to script user input: +# +# VAR_HTTP_HOST +# The HTTP server host name, IPv4 address or IPv6 address. +# Valid examples include: +# myhost +# 192.168.2.3 +# ::1 +# VAR_HTTP_PORT +# The TCP port to connect to when communicating with the server. +# VAR_HTTP_PATH +# The HTTP path sent to the server. Unused if $connect_only is +# present and non-NULL. +# +f_http_check_access() +{ + local connect_only="$1" hosts= + + local http_host http_port + f_getvar $VAR_HTTP_HOST http_host + f_getvar $VAR_HTTP_PORT http_port + + if ! { + f_validate_ipaddr "$http_host" || + f_validate_ipaddr6 "$http_host" || + { + f_dprintf "%s: Looking up hostname, %s, using host(1)" \ + "f_http_check_access" "$http_host" + f_host_lookup "$http_host" hosts + } + }; then + # All the above validations failed + [ "$hosts" ] && f_dialog_msgbox "$hosts" + unset $VAR_HTTP_HOST + return $FAILURE + elif [ ! "$hosts" ]; then + # One of the first two validations passed + hosts="$http_host" + fi + + local host connected= + for host in $hosts; do + f_quietly nc -nz "$host" "$http_port" || continue + connected=1; break + done + if [ ! "$connected" ]; then + f_show_msg "$msg_couldnt_connect_to_server http://%s:%s/" \ + "$http_host" "$http_port" + unset $VAR_HTTP_HOST + return $FAILURE + fi + [ "$connect_only" ] && return $SUCCESS + + local http_path + f_getvar $VAR_HTTP_PATH http_path + f_show_info "$msg_checking_access_to" "$http_path" + + local rx + if ! rx=$( + printf "GET /%s/ HTTP/1.0\r\n\r\n" "${http_path%/}" | + nc -n "$host" "$http_port" + ); then + f_show_msg "$msg_couldnt_connect_to_server http://%s:%s/" \ + "$http_host" "$http_port" + unset $VAR_HTTP_HOST + return $FAILURE + fi + + local hdr + hdr=$( echo "$rx" | awk '/^\r$/{exit}{print}' ) + + local http_found=$FAILURE + if echo "$hdr" | awk ' + BEGIN { found = 0 } + /^HTTP.... 200 / { + found = 1 + exit + } + END { exit ! found } + '; then + http_found=$SUCCESS + fi + + return $http_found +} + +# f_media_init_http $device +# +# Initializes the HTTP media device. Returns success if able to confirm the +# existence of at least one known HTTP server release path directly via HTTP +# using f_http_check_access(), above. +# +# Variables from variable.subr that can be used to script user input: +# +# VAR_HTTP_HOST +# The HTTP server to connect to. Must be set. Also see +# f_http_check_access() for additional variables. +# VAR_RELNAME +# Usually set to `uname -r' but can be overridden. +# VAR_HTTP_PATH +# The HTTP path sent to the server. Usually set by calling +# f_media_set_http(). +# +# Meanwhile, after successful execution, the following variables (also from +# variable.subr) are set: +# +# VAR_HTTP_PATH +# The [possibly] adjusted VAR_HTTP_PATH that was found to contain +# a valid FreeBSD repository. +# +f_media_init_http() +{ + local dev="$1" + f_dprintf "Init routine called for HTTP device. dev=[%s]" "$dev" + + # + # First verify access + # + local connect_only=1 + f_http_check_access $connect_only + + local http_host + f_getvar $VAR_HTTP_HOST http_host + while [ ! "$http_host" ]; do + f_media_set_http || return $FAILURE + f_http_check_access $connect_only + f_getvar $VAR_HTTP_HOST http_host + done + + local http_path http_found=$FAILURE + while :; do + # + # Now that we've verified that the path we're given is ok, + # let's try to be a bit intelligent in locating the release we + # are looking for. First off, if the release is specified as + # "__RELEASE" or "any", then just assume that the current + # directory is the one we want and give up. + # + local rel + f_getvar $VAR_RELNAME rel + f_dprintf "f_media_init_http: rel=[%s]" "$rel" + + case "$rel" in + __RELEASE|any) + setvar $VAR_HTTP_PATH "$VAR_HTTP_DIR" + f_http_check_access + http_found=$? + ;; + *) + # + # Ok, since we have a release variable, let's walk + # through the list of directories looking for a release + # directory. First successful path wins. + # + local fdir hp + f_getvar $VAR_HTTP_PATH%/ hp + for fdir in $HTTP_DIRS; do + setvar $VAR_HTTP_PATH "$hp/$fdir/$rel" + if f_http_check_access; then + http_found=$SUCCESS + break + fi + done + esac + + [ $http_found -eq $SUCCESS ] && break + + f_getvar $VAR_HTTP_PATH http_path + f_show_msg "$msg_please_check_the_url_and_try_again" \ + "$http_path" + + unset $VAR_HTTP_PATH + f_media_set_http || break + done + + return $http_found +} + +# f_media_get_http $device $file [$probe_only] +# +# Returns data from $file on an HTTP server using nc(1). Please note that +# $device is unused but must be present (even if null). Information is instead +# gathered from the environment. If $probe_only is both present and non-NULL, +# this function exits after receiving the HTTP header response from the server +# (if the HTTP response code is 200, success is returned; otherwise failure). +# +# The variables used to configure the connection are as follows (all of which +# are configured by f_media_set_http above): +# +# VAR_HTTP_HOST +# HTTP server which to connect. Can be an IPv4 address, IPv6 +# address, or DNS hostname of your choice. +# VAR_HTTP_PORT +# TCP port to connect on; see f_media_set_http above. +# VAR_HTTP_PATH +# Directory prefix to use when requesting $file. Default is `/' +# unless f_media_init_http was able to use f_http_check_access +# to validate one of the defaults in $HTTP_DIRS (see GLOBALS at +# the top of this file); assuming VAR_RELNAME was not set to +# either `__RELEASE' or `any' (indicating that the global set of +# $HTTP_DIRS should be ignored). +# +# See variable.subr for additional information. +# +# Example usage: +# f_media_set_http +# f_media_get_http media $file +# +f_media_get_http() +{ + local dev="$1" file="$2" probe_only="$3" hosts= + + f_dprintf "f_media_get_http: dev=[%s] file=[%s] probe_only=%s" \ + "$dev" "$file" "$probe_only" + + local http_host http_port + f_getvar $VAR_HTTP_HOST http_host + f_getvar $VAR_HTTP_PORT http_port + + if ! { + f_validate_ipaddr "$http_host" || + f_validate_ipaddr6 "$http_host" || + { + f_dprintf "%s: Looking up hostname, %s, using host(1)" \ + "f_media_get_http" "$http_host" + f_host_lookup "$http_host" hosts + } + }; then + # All the above validations failed + [ "$hosts" ] && f_dialog_msgbox "$hosts" + return $FAILURE + elif [ ! "$hosts" ]; then + # One of the first two validations passed + hosts="$http_host" + fi + + local host connected= + for host in $hosts; do + f_quietly nc -nz "$host" "$http_port" || continue + connected=1; break + done + if [ ! "$connected" ]; then + f_show_msg "$msg_couldnt_connect_to_server http://%s:%s/" \ + "$http_host" "$http_port" + return $FAILURE + fi + + local http_path + f_getvar $VAR_HTTP_PATH%/ http_path + local url="/$http_path/$file" rx + + f_dprintf "sending http request for: %s" "$url" + printf "GET %s HTTP/1.0\r\n\r\n" "$url" | nc -n "$host" "$http_port" | + ( + # + # scan the headers of the response + # this is extremely quick'n dirty + # + + rv=0 + while read LINE; do + case "$LINE" in + HTTP*) + f_dprintf "received response: %s" "$LINE" + set -- $LINE; rv=$2 + f_isinteger "$rv" || rv=0 + ;; + *) + [ "${LINE% }" ] || break # End of headers + esac + done + + [ $rv -ge 500 ] && exit 5 + [ $rv -eq 404 ] && exit 44 + [ $rv -ge 400 ] && exit 4 + [ $rv -ge 300 ] && exit 3 + [ $rv -eq 200 ] || exit $FAILURE + + if [ ! "$probe_only" ]; then + cat # output the rest ``as-is'' + fi + exit 200 + ) + local retval=$? + [ $retval -eq 200 ] && return $SUCCESS + [ "$probe_only" ] && return $FAILURE + + case "$retval" in + 5) f_show_msg "$msg_server_error_when_requesting_url" "$url" ;; + 44) f_show_msg "$msg_url_was_not_found" "$url" ;; + 4) f_show_msg "$msg_client_error" ;; + *) f_show_msg "$msg_error_when_requesting_url" "$url" ;; + esac + return $FAILURE +} + +############################################################ MAIN + +f_dprintf "%s: Successfully loaded." media/http.subr + +fi # ! $_MEDIA_HTTP_SUBR Modified: head/usr.sbin/bsdconfig/share/media/options.subr ============================================================================== --- head/usr.sbin/bsdconfig/share/media/options.subr Sun Jun 23 10:16:14 2013 (r252111) +++ head/usr.sbin/bsdconfig/share/media/options.subr Sun Jun 23 10:48:26 2013 (r252112) @@ -158,14 +158,15 @@ f_media_options_menu() case "$cp" in $DEVICE_TYPE_UFS|$DEVICE_TYPE_DISK) cp="$msg_file_system" ;; - $DEVICE_TYPE_DIRECTORY) cp="$msg_directory" ;; - $DEVICE_TYPE_FLOPPY) cp="$msg_floppy" ;; - $DEVICE_TYPE_FTP) cp="$msg_ftp" ;; - $DEVICE_TYPE_HTTP_PROXY) cp="$msg_http_proxy" ;; - $DEVICE_TYPE_CDROM) cp="$msg_cdrom" ;; - $DEVICE_TYPE_USB) cp="$msg_usb" ;; - $DEVICE_TYPE_DOS) cp="$msg_dos" ;; - $DEVICE_TYPE_NFS) cp="$msg_nfs" ;; + $DEVICE_TYPE_DIRECTORY) cp="$msg_directory" ;; + $DEVICE_TYPE_FLOPPY) cp="$msg_floppy" ;; + $DEVICE_TYPE_FTP) cp="$msg_ftp" ;; + $DEVICE_TYPE_HTTP_PROXY) cp="$msg_http_proxy" ;; + $DEVICE_TYPE_HTTP) cp="$msg_http_direct" ;; + $DEVICE_TYPE_CDROM) cp="$msg_cdrom" ;; + $DEVICE_TYPE_USB) cp="$msg_usb" ;; + $DEVICE_TYPE_DOS) cp="$msg_dos" ;; + $DEVICE_TYPE_NFS) cp="$msg_nfs" ;; *) cp="<$msg_unknown>" esac Modified: head/usr.sbin/bsdconfig/share/script.subr ============================================================================== --- head/usr.sbin/bsdconfig/share/script.subr Sun Jun 23 10:16:14 2013 (r252111) +++ head/usr.sbin/bsdconfig/share/script.subr Sun Jun 23 10:48:26 2013 (r252112) @@ -181,8 +181,10 @@ f_resword_new mediaSetFTPActive f_media f_resword_new mediaSetFTPPassive f_media_set_ftp_passive f_resword_new mediaSetFTPUserPass f_media_set_ftp_userpass +# media/http.subr +f_resword_new mediaSetHTTP f_media_set_http + # media/httpproxy.subr -f_resword_new mediaSetHTTP f_media_set_http_proxy f_resword_new mediaSetHTTPProxy f_media_set_http_proxy # packages/packages.subr Modified: head/usr.sbin/bsdconfig/share/variable.subr ============================================================================== --- head/usr.sbin/bsdconfig/share/variable.subr Sun Jun 23 10:16:14 2013 (r252111) +++ head/usr.sbin/bsdconfig/share/variable.subr Sun Jun 23 10:48:26 2013 (r252112) @@ -204,7 +204,11 @@ f_variable_new VAR_FTP_STATE ftpState f_variable_new VAR_FTP_USER ftpUser f_variable_new VAR_GATEWAY defaultrouter f_variable_new VAR_HOSTNAME hostname +f_variable_new VAR_HTTP_DIR httpDirectory f_variable_new VAR_HTTP_FTP_MODE httpFtpMode +f_variable_new VAR_HTTP_HOST httpHost +f_variable_new VAR_HTTP_PATH _httpPath +f_variable_new VAR_HTTP_PORT httpPort f_variable_new VAR_HTTP_PROXY httpProxy f_variable_new VAR_HTTP_PROXY_HOST httpProxyHost f_variable_new VAR_HTTP_PROXY_PATH _httpProxyPath From owner-svn-src-head@FreeBSD.ORG Sun Jun 23 10:51:26 2013 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BB9434DE; Sun, 23 Jun 2013 10:51:26 +0000 (UTC) (envelope-from dteske@FreeBSD.org) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) by mx1.freebsd.org (Postfix) with ESMTP id AE13E1854; Sun, 23 Jun 2013 10:51:26 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.7/8.14.7) with ESMTP id r5NApQku004643; Sun, 23 Jun 2013 10:51:26 GMT (envelope-from dteske@svn.freebsd.org) Received: (from dteske@localhost) by svn.freebsd.org (8.14.7/8.14.5/Submit) id r5NApQHq004642; Sun, 23 Jun 2013 10:51:26 GMT (envelope-from dteske@svn.freebsd.org) Message-Id: <201306231051.r5NApQHq004642@svn.freebsd.org> From: Devin Teske Date: Sun, 23 Jun 2013 10:51:26 +0000 (UTC) To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: svn commit: r252113 - head/usr.sbin/bsdconfig/include X-SVN-Group: head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2013 10:51:26 -0000 Author: dteske Date: Sun Jun 23 10:51:26 2013 New Revision: 252113 URL: http://svnweb.freebsd.org/changeset/base/252113 Log: Add a newline character to the end of the "Check URL again" error message because long URLs do not induce extra height despite wrapping by dialog(1). NOTE: For even longer lines, the cursor up/down keys work to scroll through Modified: head/usr.sbin/bsdconfig/include/messages.subr Modified: head/usr.sbin/bsdconfig/include/messages.subr ============================================================================== --- head/usr.sbin/bsdconfig/include/messages.subr Sun Jun 23 10:48:26 2013 (r252112) +++ head/usr.sbin/bsdconfig/include/messages.subr Sun Jun 23 10:51:26 2013 (r252113) @@ -259,7 +259,7 @@ msg_pear_desc="Software related to the P msg_perl5_desc="Utilities/modules for the PERL5 language." msg_permission_denied="%s: %s: Permission denied" msg_plan9_desc="Software from the Plan9 operating system." -msg_please_check_the_url_and_try_again="No such directory: %s\nplease check the URL and try again." +msg_please_check_the_url_and_try_again="No such directory: %s\nplease check the URL and try again.\n" msg_please_enter_password="Please enter your password for sudo(8):" msg_please_enter_the_address_of_the_http_proxy="Please enter the address of the HTTP proxy in this format:\n hostname:port (the ':port' is optional, default is 3128)" msg_please_enter_the_full_nfs_file_specification="Please enter the full NFS file specification for the remote\nhost and directory containing the FreeBSD distribution files.\nThis should be in the format: hostname:/some/freebsd/dir" From owner-svn-src-head@FreeBSD.ORG Sun Jun 23 12:24:08 2013 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D9BAE63E; Sun, 23 Jun 2013 12:24:08 +0000 (UTC) (envelope-from tijl@freebsd.org) Received: from mailrelay004.isp.belgacom.be (mailrelay004.isp.belgacom.be [195.238.6.170]) by mx1.freebsd.org (Postfix) with ESMTP id 8A0561ADB; Sun, 23 Jun 2013 12:24:07 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlwGADfoxlFR8Y5L/2dsb2JhbABbgwm9RYJrehd0giMBAQVWIxALGAkWBAsJAwIBAgEnHgYNAQcBAYgOuFWOKoElB4NjA5ADgSyXWIFYgTo6gS4 Received: from 75.142-241-81.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([81.241.142.75]) by relay.skynet.be with ESMTP; 23 Jun 2013 14:22:56 +0200 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.14.7/8.14.7) with ESMTP id r5NCMsuT001822; Sun, 23 Jun 2013 14:22:55 +0200 (CEST) (envelope-from tijl@FreeBSD.org) Message-ID: <51C6E89A.6060407@FreeBSD.org> Date: Sun, 23 Jun 2013 14:22:50 +0200 From: Tijl Coosemans User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/20130517 Thunderbird/17.0.6 MIME-Version: 1.0 To: Garance A Drosehn Subject: Re: svn commit: r251886 - in head: contrib/apr contrib/apr-util contrib/serf contrib/sqlite3 contrib/subversion share/mk usr.bin usr.bin/svn usr.bin/svn/lib usr.bin/svn/lib/libapr usr.bin/svn/lib/libap... References: <201306180253.r5I2rj45053959@svn.freebsd.org> <11DA3D8A-AD20-4DE1-B807-D09814F61947@bsdimp.com> <51C1C7BD.9060201@FreeBSD.org> <201306191113.29703.jhb@freebsd.org> <8D00BE2B-FD8E-4E7B-B818-1C4B7F6BB6A5@bsdimp.com> <68D70A89-22F2-412C-BAF4-72BEFE21EB2F@bsdimp.com> <51C5EF15.10305@FreeBSD.org> <51C660D9.8080804@FreeBSD.org> In-Reply-To: <51C660D9.8080804@FreeBSD.org> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----enig2OTBJGBWRTLFVDVLOVEJX" Cc: src-committers@FreeBSD.org, Andre Oppermann , Peter Wemm , John Baldwin , svn-src-all@FreeBSD.org, David Chisnall , svn-src-head@FreeBSD.org, Warner Losh X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2013 12:24:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2OTBJGBWRTLFVDVLOVEJX Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2013-06-23 04:43, Garance A Drosehn wrote: > On 6/22/13 2:38 PM, Tijl Coosemans wrote: >> On 2013-06-20 21:34, Warner Losh wrote: >>> >>> I think insisting on a definitive statement on svn lite's mission >>> statement is a way to obstruct progress. Sometimes you just need to >>> things because they feel right, not because they have been through a >>> 20-step approval process... >> >> For what it's worth, my reservations have always been because it >> didn't feel right. I never asked for an approval process. >> >> I do think there should be a tool in base that can fetch source >> updates and it would be nice if it could roll back changes and >> even nicer if it could do bisects. But svn itself is not the >> right tool for that. >> >> For instance, will you allow that svn is updated from version x.y >> to x.(y+1) in a stable branch? If yes, then users might have to run >> run "svn upgrade" which is a one way process, so how does importing >> svn allow you to roll back changes or do bisects then? If no, then >> who's volunteering to backport security fixes? >=20 > What was added to the base system was 'svnlite', not 'svn' from > the official subversion project. The distinction is that > 'svnlite' is a version meant only for access to the official > FreeBSD repositories. 'svnlite' in the base system would only > be upgraded when it is needed to match the FreeBSD respository. > And if you need to run 'svn upgrade' to access the FreeBSD > repository, then it doesn't make much difference if you have > to do that with 'svnlite' or via the official 'svn' port. >=20 > I'm not sure that my comments provide an answer to what you're > concerned about, but anyone who wants the latest version of > 'svn' to match their own repositories is still going to need > to install the port. We're not going to blindly update > 'svnlite' every time a new version of 'svn' is released. > 'svnlite' is going to be updated on *FreeBSD*'s schedule, > not on the schedule of the subversion project. >=20 > It is true that we're going to have to be careful when it does > come time to switch to some new repo-format for the FreeBSD > repository. We might find ourselves in some kind of chicken- > and-egg situation at that point. And when we do make a > significant upgrade to the FreeBSD repository, then we're > going to have to upgrade 'svnlite' across multiple FreeBSD > branches at the same time, including all -stable branches. > But when that issue comes up it'll come up on our schedule, > because we'll control both 'svnlite' and the FreeBSD repo. It is precisely the other way around. Once you do a FreeBSD release (releng branch) that release will be stuck with the same version of svnlite for years. You will end up with multiple releases with multiple versions of svnlite that you cannot change. You have zero control. A port on the other hand is the same for all branches and releases of FreeBSD. It is a single point where you have total control over the version of svn for all users. Conceptually, a port corresponds to the fact all branches and releases share the same subversion repo. ------enig2OTBJGBWRTLFVDVLOVEJX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iF4EAREIAAYFAlHG6J4ACgkQfoCS2CCgtivXhAD/dN5tQ5jEjT//znZKyAg5EODa /x9nwix90U02zY5MrhwBAIW0biyoD+HZ1KLpQkB/QvyKRusT3yXOAlsSl/Hivs44 =rvdg -----END PGP SIGNATURE----- ------enig2OTBJGBWRTLFVDVLOVEJX-- From owner-svn-src-head@FreeBSD.ORG Sun Jun 23 14:20:55 2013 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 25A15ED8; Sun, 23 Jun 2013 14:20:55 +0000 (UTC) (envelope-from jhibbits@FreeBSD.org) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) by mx1.freebsd.org (Postfix) with ESMTP id F287B1E65; Sun, 23 Jun 2013 14:20:54 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.7/8.14.7) with ESMTP id r5NEKsh2063996; Sun, 23 Jun 2013 14:20:54 GMT (envelope-from jhibbits@svn.freebsd.org) Received: (from jhibbits@localhost) by svn.freebsd.org (8.14.7/8.14.5/Submit) id r5NEKsQg063995; Sun, 23 Jun 2013 14:20:54 GMT (envelope-from jhibbits@svn.freebsd.org) Message-Id: <201306231420.r5NEKsQg063995@svn.freebsd.org> From: Justin Hibbits Date: Sun, 23 Jun 2013 14:20:54 +0000 (UTC) To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: svn commit: r252115 - head/sys/powerpc/ofw X-SVN-Group: head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2013 14:20:55 -0000 Author: jhibbits Date: Sun Jun 23 14:20:54 2013 New Revision: 252115 URL: http://svnweb.freebsd.org/changeset/base/252115 Log: Cache the Open Firmware CPU properties at attach time, so we don't always enter it at runtime to get static data. Modified: head/sys/powerpc/ofw/ofw_cpu.c Modified: head/sys/powerpc/ofw/ofw_cpu.c ============================================================================== --- head/sys/powerpc/ofw/ofw_cpu.c Sun Jun 23 13:27:37 2013 (r252114) +++ head/sys/powerpc/ofw/ofw_cpu.c Sun Jun 23 14:20:54 2013 (r252115) @@ -133,6 +133,11 @@ static int ofw_cpu_attach(device_t); static int ofw_cpu_read_ivar(device_t dev, device_t child, int index, uintptr_t *result); +struct ofw_cpu_softc { + struct pcpu *sc_cpu_pcpu; + uint32_t sc_nominal_mhz; +}; + static device_method_t ofw_cpu_methods[] = { /* Device interface */ DEVMETHOD(device_probe, ofw_cpu_probe), @@ -175,6 +180,15 @@ ofw_cpu_probe(device_t dev) static int ofw_cpu_attach(device_t dev) { + struct ofw_cpu_softc *sc; + uint32_t cell; + + sc = device_get_softc(dev); + OF_getprop(ofw_bus_get_node(dev), "reg", &cell, sizeof(cell)); + sc->sc_cpu_pcpu = pcpu_find(cell); + OF_getprop(ofw_bus_get_node(dev), "clock-frequency", &cell, sizeof(cell)); + sc->sc_nominal_mhz = cell / 1000000; /* convert to MHz */ + bus_generic_probe(dev); return (bus_generic_attach(dev)); } @@ -182,19 +196,16 @@ ofw_cpu_attach(device_t dev) static int ofw_cpu_read_ivar(device_t dev, device_t child, int index, uintptr_t *result) { - uint32_t cell; + struct ofw_cpu_softc *sc; + + sc = device_get_softc(dev); switch (index) { case CPU_IVAR_PCPU: - OF_getprop(ofw_bus_get_node(dev), "reg", &cell, sizeof(cell)); - *result = (uintptr_t)(pcpu_find(cell)); + *result = (uintptr_t)sc->sc_cpu_pcpu; return (0); case CPU_IVAR_NOMINAL_MHZ: - cell = 0; - OF_getprop(ofw_bus_get_node(dev), "clock-frequency", - &cell, sizeof(cell)); - cell /= 1000000; /* convert to MHz */ - *result = (uintptr_t)(cell); + *result = (uintptr_t)sc->sc_nominal_mhz; return (0); } From owner-svn-src-head@FreeBSD.ORG Sun Jun 23 17:12:57 2013 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 818BA50F for ; Sun, 23 Jun 2013 17:12:57 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by mx1.freebsd.org (Postfix) with ESMTP id 4CD391664 for ; Sun, 23 Jun 2013 17:12:57 +0000 (UTC) Received: by mail-ie0-f180.google.com with SMTP id f4so23165047iea.11 for ; Sun, 23 Jun 2013 10:12:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=RYwZQy1WRcNfFXFjDhSiuWdYY2vEapqM4ww2w9Zb6Ko=; b=CdYFHHNdzcFMNfUjfGVwW8nx35SQGiyl9SGaMIgD1IejlxPS66/ucPUOw3wZJsqCSy BaDbf1nU//kvuEK+QAdd7994SLp/vL7/aGiqk+wMDKVdT+kJniK1P/micrxDEAEeT+KH +udntPjUTxYueLidbcsbBmeWk4lPeDEj8CQzf0omsKJXOqBH4v6idM3q0uM8i3p/I1sd YDlxF/6jjtiEMfWXE/x/Zt3H27IK6wC3I9j+57zmnjSxQheNuL4XPj7if9AqUeiCQIfs PvJq+B0HUN0sYmL0vqbLGOZcdl7G1Vu76egf7ULkhJ8bKbkQL0Uh3A/0Vc4dVWz80U2h VBdw== X-Received: by 10.50.101.16 with SMTP id fc16mr1007996igb.49.1372007576977; Sun, 23 Jun 2013 10:12:56 -0700 (PDT) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id nm17sm9453881igb.5.2013.06.23.10.12.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 23 Jun 2013 10:12:56 -0700 (PDT) Sender: Warner Losh Subject: Re: svn commit: r251886 - in head: contrib/apr contrib/apr-util contrib/serf contrib/sqlite3 contrib/subversion share/mk usr.bin usr.bin/svn usr.bin/svn/lib usr.bin/svn/lib/libapr usr.bin/svn/lib/libap... Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <51C6E89A.6060407@FreeBSD.org> Date: Sun, 23 Jun 2013 11:12:53 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <3E89DDCB-38FA-4E7C-8F03-461516DD1871@bsdimp.com> References: <201306180253.r5I2rj45053959@svn.freebsd.org> <11DA3D8A-AD20-4DE1-B807-D09814F61947@bsdimp.com> <51C1C7BD.9060201@FreeBSD.org> <201306191113.29703.jhb@freebsd.org> <8D00BE2B-FD8E-4E7B-B818-1C4B7F6BB6A5@bsdimp.com> <68D70A89-22F2-412C-BAF4-72BEFE21EB2F@bsdimp.com> <51C5EF15.10305@FreeBSD.org> <51C660D9.8080804@FreeBSD.org> <51C6E89A.6060407@FreeBSD.org> To: Tijl Coosemans X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQmVkNUyl5W6zqApa0LYdTKE8XFdXAglXmEc8lehZ/FgkpjYw+AvJ8z2ShqHiGgW6DBmffGd Cc: src-committers@FreeBSD.org, Andre Oppermann , Peter Wemm , John Baldwin , svn-src-all@FreeBSD.org, David Chisnall , Garance A Drosehn , svn-src-head@FreeBSD.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2013 17:12:57 -0000 On Jun 23, 2013, at 6:22 AM, Tijl Coosemans wrote: > On 2013-06-23 04:43, Garance A Drosehn wrote: >> On 6/22/13 2:38 PM, Tijl Coosemans wrote: >>> On 2013-06-20 21:34, Warner Losh wrote: >>>>=20 >>>> I think insisting on a definitive statement on svn lite's mission >>>> statement is a way to obstruct progress. Sometimes you just need to >>>> things because they feel right, not because they have been through = a >>>> 20-step approval process... >>>=20 >>> For what it's worth, my reservations have always been because it >>> didn't feel right. I never asked for an approval process. >>>=20 >>> I do think there should be a tool in base that can fetch source >>> updates and it would be nice if it could roll back changes and >>> even nicer if it could do bisects. But svn itself is not the >>> right tool for that. >>>=20 >>> For instance, will you allow that svn is updated from version x.y >>> to x.(y+1) in a stable branch? If yes, then users might have to run >>> run "svn upgrade" which is a one way process, so how does importing >>> svn allow you to roll back changes or do bisects then? If no, then >>> who's volunteering to backport security fixes? >>=20 >> What was added to the base system was 'svnlite', not 'svn' from >> the official subversion project. The distinction is that >> 'svnlite' is a version meant only for access to the official >> FreeBSD repositories. 'svnlite' in the base system would only >> be upgraded when it is needed to match the FreeBSD respository. >> And if you need to run 'svn upgrade' to access the FreeBSD >> repository, then it doesn't make much difference if you have >> to do that with 'svnlite' or via the official 'svn' port. >>=20 >> I'm not sure that my comments provide an answer to what you're >> concerned about, but anyone who wants the latest version of >> 'svn' to match their own repositories is still going to need >> to install the port. We're not going to blindly update >> 'svnlite' every time a new version of 'svn' is released. >> 'svnlite' is going to be updated on *FreeBSD*'s schedule, >> not on the schedule of the subversion project. >>=20 >> It is true that we're going to have to be careful when it does >> come time to switch to some new repo-format for the FreeBSD >> repository. We might find ourselves in some kind of chicken- >> and-egg situation at that point. And when we do make a >> significant upgrade to the FreeBSD repository, then we're >> going to have to upgrade 'svnlite' across multiple FreeBSD >> branches at the same time, including all -stable branches. >> But when that issue comes up it'll come up on our schedule, >> because we'll control both 'svnlite' and the FreeBSD repo. >=20 > It is precisely the other way around. Once you do a FreeBSD release > (releng branch) that release will be stuck with the same version of > svnlite for years. You will end up with multiple releases with > multiple versions of svnlite that you cannot change. You have zero > control. Then they will never have to do svn update, since their checked out tree = will never be obsolete in relationship to the version that's installed. > A port on the other hand is the same for all branches and releases > of FreeBSD. It is a single point where you have total control over > the version of svn for all users. Conceptually, a port corresponds > to the fact all branches and releases share the same subversion > repo. Except that you still need to do svn update on trees that are checked = out from old repos. I'm having a real hard time seeing this as an issue based on my = experience with the svn port since we made the switch. Then again, I've = been talking to the svn repo over http, which is independent of the = version of the repo on the other end... Warner= From owner-svn-src-head@FreeBSD.ORG Sun Jun 23 17:03:56 2013 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6FF42798; Sun, 23 Jun 2013 17:03:56 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by mx1.freebsd.org (Postfix) with ESMTP id D33351626; Sun, 23 Jun 2013 17:03:54 +0000 (UTC) Received: by mail-wi0-f182.google.com with SMTP id m6so1867506wiv.9 for ; Sun, 23 Jun 2013 10:03:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=X6hKLr2RApL4PD5QTfOPUzCajYgu5MjDiOE6f5z37uM=; b=bDUyugYLkSoMbB2vgFoe1euZEUpfIZ7aPkUKInFrpU3MGx/6KrfLhwx8+O/63dmvno XBNZxZJng4RcMC/psu6heXmnkGQsW7IlGTi4DHAa3hdOQEs0s2BoKJEXFmLx/T05QDSm irUUNUxlmT0txuOhsuwLMyfssTc0uP7yliCnkq1sxJ+kReP3bjY9WfXKPbzTHmXDJrOp d6hjQaHQt43qkTf0BSIil9cqrGoJs3bJS74u13SRtIyam/CeIFQwHECmiHyKvRw2+Ld9 6/yCbmmJ73uHw7lcL09lpSjfHJ+CQoeohrYn6YWAlDD7i75MOcsL8QCte+eOwmnzQLHw nRCw== MIME-Version: 1.0 X-Received: by 10.180.92.226 with SMTP id cp2mr3975076wib.9.1372007033918; Sun, 23 Jun 2013 10:03:53 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.73.202 with HTTP; Sun, 23 Jun 2013 10:03:53 -0700 (PDT) In-Reply-To: <51C6E89A.6060407@FreeBSD.org> References: <201306180253.r5I2rj45053959@svn.freebsd.org> <11DA3D8A-AD20-4DE1-B807-D09814F61947@bsdimp.com> <51C1C7BD.9060201@FreeBSD.org> <201306191113.29703.jhb@freebsd.org> <8D00BE2B-FD8E-4E7B-B818-1C4B7F6BB6A5@bsdimp.com> <68D70A89-22F2-412C-BAF4-72BEFE21EB2F@bsdimp.com> <51C5EF15.10305@FreeBSD.org> <51C660D9.8080804@FreeBSD.org> <51C6E89A.6060407@FreeBSD.org> Date: Sun, 23 Jun 2013 10:03:53 -0700 X-Google-Sender-Auth: MwyFSun-YfPrZIcUrXcIWhj2zbw Message-ID: Subject: Re: svn commit: r251886 - in head: contrib/apr contrib/apr-util contrib/serf contrib/sqlite3 contrib/subversion share/mk usr.bin usr.bin/svn usr.bin/svn/lib usr.bin/svn/lib/libapr usr.bin/svn/lib/libap... From: Adrian Chadd To: Tijl Coosemans Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Sun, 23 Jun 2013 17:40:27 +0000 Cc: src-committers@freebsd.org, Andre Oppermann , John Baldwin , Peter Wemm , svn-src-all@freebsd.org, David Chisnall , Garance A Drosehn , svn-src-head@freebsd.org, Warner Losh X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2013 17:03:56 -0000 You know that there _are_ users that want behaviour (A), and some that want behaviour (B), right? Not everyone wants to run the latest and greatest ports tree on all releases. Adrian On 23 June 2013 05:22, Tijl Coosemans wrote: > On 2013-06-23 04:43, Garance A Drosehn wrote: >> On 6/22/13 2:38 PM, Tijl Coosemans wrote: >>> On 2013-06-20 21:34, Warner Losh wrote: >>>> >>>> I think insisting on a definitive statement on svn lite's mission >>>> statement is a way to obstruct progress. Sometimes you just need to >>>> things because they feel right, not because they have been through a >>>> 20-step approval process... >>> >>> For what it's worth, my reservations have always been because it >>> didn't feel right. I never asked for an approval process. >>> >>> I do think there should be a tool in base that can fetch source >>> updates and it would be nice if it could roll back changes and >>> even nicer if it could do bisects. But svn itself is not the >>> right tool for that. >>> >>> For instance, will you allow that svn is updated from version x.y >>> to x.(y+1) in a stable branch? If yes, then users might have to run >>> run "svn upgrade" which is a one way process, so how does importing >>> svn allow you to roll back changes or do bisects then? If no, then >>> who's volunteering to backport security fixes? >> >> What was added to the base system was 'svnlite', not 'svn' from >> the official subversion project. The distinction is that >> 'svnlite' is a version meant only for access to the official >> FreeBSD repositories. 'svnlite' in the base system would only >> be upgraded when it is needed to match the FreeBSD respository. >> And if you need to run 'svn upgrade' to access the FreeBSD >> repository, then it doesn't make much difference if you have >> to do that with 'svnlite' or via the official 'svn' port. >> >> I'm not sure that my comments provide an answer to what you're >> concerned about, but anyone who wants the latest version of >> 'svn' to match their own repositories is still going to need >> to install the port. We're not going to blindly update >> 'svnlite' every time a new version of 'svn' is released. >> 'svnlite' is going to be updated on *FreeBSD*'s schedule, >> not on the schedule of the subversion project. >> >> It is true that we're going to have to be careful when it does >> come time to switch to some new repo-format for the FreeBSD >> repository. We might find ourselves in some kind of chicken- >> and-egg situation at that point. And when we do make a >> significant upgrade to the FreeBSD repository, then we're >> going to have to upgrade 'svnlite' across multiple FreeBSD >> branches at the same time, including all -stable branches. >> But when that issue comes up it'll come up on our schedule, >> because we'll control both 'svnlite' and the FreeBSD repo. > > It is precisely the other way around. Once you do a FreeBSD release > (releng branch) that release will be stuck with the same version of > svnlite for years. You will end up with multiple releases with > multiple versions of svnlite that you cannot change. You have zero > control. > > A port on the other hand is the same for all branches and releases > of FreeBSD. It is a single point where you have total control over > the version of svn for all users. Conceptually, a port corresponds > to the fact all branches and releases share the same subversion > repo. > From owner-svn-src-head@FreeBSD.ORG Sun Jun 23 19:30:28 2013 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 34868E6E for ; Sun, 23 Jun 2013 19:30:28 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) by mx1.freebsd.org (Postfix) with ESMTP id E329A1A5B for ; Sun, 23 Jun 2013 19:30:27 +0000 (UTC) Received: by mail-qa0-f43.google.com with SMTP id d13so1778502qak.9 for ; Sun, 23 Jun 2013 12:30:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=79PU8c39lPe4Kpd+PgWZreW0ZeC+m2fCy8gKUUSnKPo=; b=q6WFYy518j5hTAV+rTrt9ciJCWg/Ji+i1jj2CDXKZY2j+D/jgmc/GNdO1o58ABVZnA LPA7NVMsWyYGzTPZs6ny+1gZ2BSblTOHQFadoIqeY1cXqXFp8X/OwosDsXn1yAZxYhgL /gTiVGoHHO5bo5dQ9PikVl8bOKwry7I3Dg/Cc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=79PU8c39lPe4Kpd+PgWZreW0ZeC+m2fCy8gKUUSnKPo=; b=CM2M5qXzY4dfbTU1hVOGY13HuP34M45N91hK/LoeU5wpV+XLhjLSdYTa/JClcUa3eu SdI8chiXpcUPghIpHFAMPsev18eWwDHD7PC6WJKTgMPNDkdw8Anmr23jT4UrD6xomOEK KVphny0s82kE5om6Y6pizq/mIty8LlUSsXZxrAPFx8gyZzjjDxexZNJsKeSrXWW36pF1 mj9o9DonQ4g4SLRx43gtGjPklC7n262i0oMFj4e/wSUocJoJbjzPFAm9GEqtyjJ0VyMC plh2qdVz9l0fvNYu7RUBaKFjnGVLs1qZ2qPXgKuMpRd4M3sJVPuFGXCBzVPyTjdAzpyf /uxg== MIME-Version: 1.0 X-Received: by 10.229.165.207 with SMTP id j15mr3567060qcy.92.1372015827343; Sun, 23 Jun 2013 12:30:27 -0700 (PDT) Received: by 10.49.4.196 with HTTP; Sun, 23 Jun 2013 12:30:27 -0700 (PDT) In-Reply-To: <3E89DDCB-38FA-4E7C-8F03-461516DD1871@bsdimp.com> References: <201306180253.r5I2rj45053959@svn.freebsd.org> <11DA3D8A-AD20-4DE1-B807-D09814F61947@bsdimp.com> <51C1C7BD.9060201@FreeBSD.org> <201306191113.29703.jhb@freebsd.org> <8D00BE2B-FD8E-4E7B-B818-1C4B7F6BB6A5@bsdimp.com> <68D70A89-22F2-412C-BAF4-72BEFE21EB2F@bsdimp.com> <51C5EF15.10305@FreeBSD.org> <51C660D9.8080804@FreeBSD.org> <51C6E89A.6060407@FreeBSD.org> <3E89DDCB-38FA-4E7C-8F03-461516DD1871@bsdimp.com> Date: Sun, 23 Jun 2013 12:30:27 -0700 Message-ID: Subject: Re: svn commit: r251886 - in head: contrib/apr contrib/apr-util contrib/serf contrib/sqlite3 contrib/subversion share/mk usr.bin usr.bin/svn usr.bin/svn/lib usr.bin/svn/lib/libapr usr.bin/svn/lib/libap... From: Peter Wemm To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmWIB2ey7O+rVfmw8A/AWimhNQJpdtBJm+o45k7dulUFy+/jrjY86+UclQWery90ngVAJh3 Cc: src-committers@freebsd.org, Andre Oppermann , John Baldwin , svn-src-all@freebsd.org, David Chisnall , Garance A Drosehn , svn-src-head@freebsd.org, Tijl Coosemans X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2013 19:30:28 -0000 On Sun, Jun 23, 2013 at 10:12 AM, Warner Losh wrote: > On Jun 23, 2013, at 6:22 AM, Tijl Coosemans wrote: > > On 2013-06-23 04:43, Garance A Drosehn wrote: > >> On 6/22/13 2:38 PM, Tijl Coosemans wrote: > >>> On 2013-06-20 21:34, Warner Losh wrote: > >>>> > >>>> I think insisting on a definitive statement on svn lite's mission > >>>> statement is a way to obstruct progress. Sometimes you just need to > >>>> things because they feel right, not because they have been through a > >>>> 20-step approval process... > >>> > >>> For what it's worth, my reservations have always been because it > >>> didn't feel right. I never asked for an approval process. > >>> > >>> I do think there should be a tool in base that can fetch source > >>> updates and it would be nice if it could roll back changes and > >>> even nicer if it could do bisects. But svn itself is not the > >>> right tool for that. > >>> > >>> For instance, will you allow that svn is updated from version x.y > >>> to x.(y+1) in a stable branch? If yes, then users might have to run > >>> run "svn upgrade" which is a one way process, so how does importing > >>> svn allow you to roll back changes or do bisects then? If no, then > >>> who's volunteering to backport security fixes? > >> > >> What was added to the base system was 'svnlite', not 'svn' from > >> the official subversion project. The distinction is that > >> 'svnlite' is a version meant only for access to the official > >> FreeBSD repositories. 'svnlite' in the base system would only > >> be upgraded when it is needed to match the FreeBSD respository. > >> And if you need to run 'svn upgrade' to access the FreeBSD > >> repository, then it doesn't make much difference if you have > >> to do that with 'svnlite' or via the official 'svn' port. > >> > >> I'm not sure that my comments provide an answer to what you're > >> concerned about, but anyone who wants the latest version of > >> 'svn' to match their own repositories is still going to need > >> to install the port. We're not going to blindly update > >> 'svnlite' every time a new version of 'svn' is released. > >> 'svnlite' is going to be updated on *FreeBSD*'s schedule, > >> not on the schedule of the subversion project. > >> > >> It is true that we're going to have to be careful when it does > >> come time to switch to some new repo-format for the FreeBSD > >> repository. We might find ourselves in some kind of chicken- > >> and-egg situation at that point. And when we do make a > >> significant upgrade to the FreeBSD repository, then we're > >> going to have to upgrade 'svnlite' across multiple FreeBSD > >> branches at the same time, including all -stable branches. > >> But when that issue comes up it'll come up on our schedule, > >> because we'll control both 'svnlite' and the FreeBSD repo. > > > > It is precisely the other way around. Once you do a FreeBSD release > > (releng branch) that release will be stuck with the same version of > > svnlite for years. You will end up with multiple releases with > > multiple versions of svnlite that you cannot change. You have zero > > control. > > Then they will never have to do svn update, since their checked out tree will never be obsolete in relationship to the version that's installed. > > > A port on the other hand is the same for all branches and releases > > of FreeBSD. It is a single point where you have total control over > > the version of svn for all users. Conceptually, a port corresponds > > to the fact all branches and releases share the same subversion > > repo. > > Except that you still need to do svn update on trees that are checked out from old repos. > > I'm having a real hard time seeing this as an issue based on my experience with the svn port since we made the switch. Then again, I've been talking to the svn repo over http, which is independent of the version of the repo on the other end... > > Warner I've been resisting the urge to dive in. I will say right up front that a drive-by commit like this is Not The Way We Are Supposed To Do Things(TM). I know that I have ruffled some people's feathers, and for that I'm sorry. I've also got a lot of thank-you messages. I'll try and explain myself. [I know this is long. Please don't start replying until you've read it to the end.] The bottom line as to why I did this.. we are an open *source* operating system. After actually working fully from source on the freebsd.org cluster, it has become rather apparent that convenience of working with a pure-source environment has regressed considerably since 2008 when we switched from cvs. As an example of inconvenient, take this clean 24 core system with 24 GB ram. Suppose I have a problem that I want to do a bisection search to see when it first appeared (right there, freebsd-update is excluded). # rm -rf /usr/local/* /var/db/pkg/* /var/db/ports/* then a config-recursive, taking default options to match packages: # cd /usr/ports/devel/subversion; time make config-recursive (immediately hitting enter) 41.693u 4.778s 0:37.12 125.1% 30872+507k 185+13771io 360pf+0w 37 seconds just to configure the build options. # cd /usr/ports/devel/subversion; time make install [...] Installing subversion-1.8.0_1... done 902.035u 213.337s 13:53.08 133.8% 21955+423k 1282+248411io 18705pf+0w 14 minutes, 30 seconds on a reasonably fast system, not counting acquiring/extracting/updating the ports tree in the first place. (portsnap takes over 20 hours just to verify its checksums on my firewall, so please don't tell me portsnap is the solution for everything!) At the end the footprint is: # pkg info apr-1.4.6.1.4.1_3 Apache Portability Library autoconf-2.69 Automatically configure source code on many Un*x platforms autoconf-wrapper-20101119 Wrapper script for GNU autoconf automake-1.12.6 GNU Standards-compliant Makefile generator automake-wrapper-20101119 Wrapper script for GNU automake db42-4.2.52_5 The Berkeley DB package, revision 4.2 dialog4ports-0.1.5 Console Interface to configure ports expat-2.0.1_2 XML 1.0 parser written in C gdbm-1.9.1 GNU database manager gettext-0.18.1.1_1 GNU gettext package gmake-3.82_1 GNU version of 'make' utility help2man-1.43.2 Automatically generating simple manual pages from program output libiconv-1.14_1 A character set conversion library libtool-2.4.2 Generic shared library support script m4-1.4.16_1,1 GNU m4 p5-Locale-gettext-1.05_3 Message handling functions perl-5.14.4 Practical Extraction and Report Language pkg-1.0.14 New generation package manager pkgconf-0.9.2_1 Utility to help to configure compiler and linker flags python27-2.7.5_1 Interpreted object-oriented programming language serf-1.2.1 Serf HTTP client library sqlite3-3.7.17_1 SQL database engine in a C library subversion-1.8.0_1 Version control system highlights: db4.2(!!wtf?), gdbm, perl, python, make, m4 du -sh says: 238M /usr/local The same machine (WITHOUT_CLANG) builds world *and* its kernel in: 3570.850u 845.997s 13:29.91 545.3% 6978+1075k 28182+1449464io 21379pf+0w Same again but with clang enabled (and it's the default compiler. with maximum working -j): 8276.034u 746.466s 31:24.78 478.7% 29824+610k 25348+1683059io 36894pf+0w And svnlite, *with* clang to get the worst case: /usr/src/usr.bin/svn# time make -s -j24 depend all 117.943u 15.330s 0:42.74 311.8% 32804+522k 2+37666io 1231pf+0w du -sh /usr/bin/svnlite* says 18M In summary, on the same machine, no third party binaries: ?? acquire ports tree (talk to my soekris firewall for worst-case examples) ?? deal with perl directory layout changes (actually pretty quick if you just rm -rf /usr/local and start over) 14 minutes 30 seconds to build from svn ports vs 13 minutes 30 seconds to buildworld without clang 31 minutes 24 seconds to buildworld with clang vs 42 seconds to build svnlite (not actually lite, fully functional) Don't get me wrong, I love what pkgng brings to the table. But as a "source code" consumer, it makes my skin crawl each time somebody effectively says "oh, you shouldn't build from source, you should install binaries to solve the problem". Every time I hear that it feels like we're giving up. If I wanted binaries, I'd be running a binary-only OS like Windows, Linux or OSX. As for compatability and old releases: Your svn-1.4 / 1.5 binaries from years ago still work on the project's svn-1.8 infrastructure. svnlite doesn't change what "svn up" does on your $path. svnlite doesn't interfere with ports in ANY WAY. If your perl install broke and don't want to deal with it right now, you don't have to. svnlite doesn't interfere with your 1.5 or 1.6 checkouts unless you type it by name or compile it as "svn" with -DWITH_SVN=yes What it brings: svnlite restores the 'at-your-fingertips' convenience that we kind of lost when we switched from cvs in 2008. You can install an image in a VM or whatever and instantly participate in development. It brings WITH_SVN=yes in make.conf so you can get finger memory compatibility if you wish. I still want svnup to be finished and imported. Just like when we had cvs and csup, they're targeted at different people. If a few extra seconds of buildworld time bother you, there *is* a knob to turn it off. But if we need to talk about that then we also need to talk about multiple compilers, multiple installers, multiple firewalls, multiple command line editors, multiple nfs servers, multiple nfs clients, obsolete dns stacks, etc etc. The bottom line is that this is as close to "free" as it can get. It adds options for people. It does not limit or restrict people's options It does not interfere with people's existing svn checkouts (unless they want to, options!) And I am not willing to back down on it... But I do apologize for the hypocrisy in committing a drive-by and the upset that it caused a few people. I don't know about everyone else but I've now spent more time talking about this than I'll spend waiting for it to compile in the rest of my life using FreeBSD as a source-code-based OS. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV From owner-svn-src-head@FreeBSD.ORG Sun Jun 23 19:48:00 2013 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 19814C37; Sun, 23 Jun 2013 19:48:00 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) by mx1.freebsd.org (Postfix) with ESMTP id 0C35D1AC6; Sun, 23 Jun 2013 19:48:00 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.7/8.14.7) with ESMTP id r5NJlx3C055778; Sun, 23 Jun 2013 19:47:59 GMT (envelope-from gjb@svn.freebsd.org) Received: (from gjb@localhost) by svn.freebsd.org (8.14.7/8.14.5/Submit) id r5NJlxt8055777; Sun, 23 Jun 2013 19:47:59 GMT (envelope-from gjb@svn.freebsd.org) Message-Id: <201306231947.r5NJlxt8055777@svn.freebsd.org> From: Glen Barber Date: Sun, 23 Jun 2013 19:47:59 +0000 (UTC) To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: svn commit: r252119 - head/release/doc/en_US.ISO8859-1/relnotes X-SVN-Group: head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2013 19:48:00 -0000 Author: gjb Date: Sun Jun 23 19:47:59 2013 New Revision: 252119 URL: http://svnweb.freebsd.org/changeset/base/252119 Log: Add missing copyright years. Modified: head/release/doc/en_US.ISO8859-1/relnotes/article.xml Modified: head/release/doc/en_US.ISO8859-1/relnotes/article.xml ============================================================================== --- head/release/doc/en_US.ISO8859-1/relnotes/article.xml Sun Jun 23 16:58:59 2013 (r252118) +++ head/release/doc/en_US.ISO8859-1/relnotes/article.xml Sun Jun 23 19:47:59 2013 (r252119) @@ -25,6 +25,9 @@ 2008 2009 2010 + 2011 + 2012 + 2013 The &os; Documentation Project From owner-svn-src-head@FreeBSD.ORG Sun Jun 23 20:09:47 2013 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 02F67FFD for ; Sun, 23 Jun 2013 20:09:47 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-ve0-x234.google.com (mail-ve0-x234.google.com [IPv6:2607:f8b0:400c:c01::234]) by mx1.freebsd.org (Postfix) with ESMTP id 8AC1E1B49 for ; Sun, 23 Jun 2013 20:09:46 +0000 (UTC) Received: by mail-ve0-f180.google.com with SMTP id pa12so8023689veb.39 for ; Sun, 23 Jun 2013 13:09:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SsMMNaXGRGKzvRZuAhCdCRFKBxtM6XE+v7Dj5u+PLHk=; b=U8RpEY2od1kmVODFp8d7Bf1kfZsYWIWxN/HGCa8kUF3nBgDg3adXAa/RmcK9PhTbur heP3muV4Uizjh9ZDozPSspv9XxsPTpFEE2xZC7eEXrZ/eO2CBAALdoqLEFQjWImAtKin OEIwrl21H7MEhvpyOz7SGIFyc/1vTraeS6f7k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=SsMMNaXGRGKzvRZuAhCdCRFKBxtM6XE+v7Dj5u+PLHk=; b=aOfFwBupHlDkwLA0VptCHeRzVVJ9gM4SYkTVQv+LNyPfgzcYohMwOTGPEYPA/5S8Pe OYHc4plGAz/a1yKyHiULLOxO8gCCb/TuR9pYAr147RkhyaJR6/96hqAZaLzm6ylyr+J1 i1a48mQxSGkQEllfAJzqSAavWILtFuJ6R9a1t0ITKFsCbX6koxN1AYc7jh3V/jqqlSGF HLEWaV7+uaiDujGa109AaN5MiA9/UDUlEf20q3mjQEvnTEVB/F4HFkPHSFVjHWMyFtf5 mctCtHTrYcBbSaqP4KenS48nbuECGbuR2wq613E6t0dL2KTPjklpgvz5qXa0F2bH/BDq TpaQ== MIME-Version: 1.0 X-Received: by 10.59.9.69 with SMTP id dq5mr9818117ved.87.1372018186045; Sun, 23 Jun 2013 13:09:46 -0700 (PDT) Received: by 10.220.20.133 with HTTP; Sun, 23 Jun 2013 13:09:45 -0700 (PDT) In-Reply-To: References: <201306180253.r5I2rj45053959@svn.freebsd.org> <11DA3D8A-AD20-4DE1-B807-D09814F61947@bsdimp.com> <51C1C7BD.9060201@FreeBSD.org> <201306191113.29703.jhb@freebsd.org> <8D00BE2B-FD8E-4E7B-B818-1C4B7F6BB6A5@bsdimp.com> <68D70A89-22F2-412C-BAF4-72BEFE21EB2F@bsdimp.com> <51C5EF15.10305@FreeBSD.org> <51C660D9.8080804@FreeBSD.org> <51C6E89A.6060407@FreeBSD.org> <3E89DDCB-38FA-4E7C-8F03-461516DD1871@bsdimp.com> Date: Sun, 23 Jun 2013 13:09:45 -0700 Message-ID: Subject: Re: svn commit: r251886 - in head: contrib/apr contrib/apr-util contrib/serf contrib/sqlite3 contrib/subversion share/mk usr.bin usr.bin/svn usr.bin/svn/lib usr.bin/svn/lib/libapr usr.bin/svn/lib/libap... From: Peter Wemm To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmK3M4gqNybCKO/Q/i9A+FDgBr1kf1/YqOoCPHQ29htnZbsFf1jDT76EJS/r6YRzmjYaefx Cc: src-committers@freebsd.org, Andre Oppermann , John Baldwin , svn-src-all@freebsd.org, David Chisnall , Garance A Drosehn , svn-src-head@freebsd.org, Tijl Coosemans X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2013 20:09:47 -0000 On Sun, Jun 23, 2013 at 12:30 PM, Peter Wemm wrote: [..] > I still want svnup to be finished and imported. Just like when we > had cvs and csup, they're targeted at different people. One clarification. svnlite is intended to be a lighter weight alternative to the devel/subversion port, not to eliminate the port. Things like svn.freebsd.org and the mirrors could never use "svnlite" and will always run the port because they need the py-subversion API library or the apache DAV plugins. That isn't something I could ever imagine making its way into svnlite - it wasn't the point. For what its worth, the freebsd.org cluster has been mostly running svn-1.8.x for over a week, including svn.freebsd.org and all but one mirror. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV From owner-svn-src-head@FreeBSD.ORG Sun Jun 23 20:19:01 2013 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9E4B176D; Sun, 23 Jun 2013 20:19:01 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) by mx1.freebsd.org (Postfix) with ESMTP id 8FF481BD7; Sun, 23 Jun 2013 20:19:01 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.7/8.14.7) with ESMTP id r5NKJ1jV064813; Sun, 23 Jun 2013 20:19:01 GMT (envelope-from gjb@svn.freebsd.org) Received: (from gjb@localhost) by svn.freebsd.org (8.14.7/8.14.5/Submit) id r5NKJ1GZ064811; Sun, 23 Jun 2013 20:19:01 GMT (envelope-from gjb@svn.freebsd.org) Message-Id: <201306232019.r5NKJ1GZ064811@svn.freebsd.org> From: Glen Barber Date: Sun, 23 Jun 2013 20:19:01 +0000 (UTC) To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: svn commit: r252121 - in head/release/doc: en_US.ISO8859-1/errata share/xml X-SVN-Group: head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2013 20:19:01 -0000 Author: gjb Date: Sun Jun 23 20:19:00 2013 New Revision: 252121 URL: http://svnweb.freebsd.org/changeset/base/252121 Log: Add a new macro, release.current.release, to denote the head/ branch with the -RELEASE suffix. This fixes the incorrect text on the -CURRENT errata page from showing '10.0-CURRENT' followed by 'until 9.1-RELEASE is released.' Modified: head/release/doc/en_US.ISO8859-1/errata/article.xml head/release/doc/share/xml/release.ent Modified: head/release/doc/en_US.ISO8859-1/errata/article.xml ============================================================================== --- head/release/doc/en_US.ISO8859-1/errata/article.xml Sun Jun 23 20:09:58 2013 (r252120) +++ head/release/doc/en_US.ISO8859-1/errata/article.xml Sun Jun 23 20:19:00 2013 (r252121) @@ -57,7 +57,7 @@ &os;. This errata document for &os; &release; - will be maintained until the release of &os; &release.next;. + will be maintained until the release of &os; &release.current.release;. Modified: head/release/doc/share/xml/release.ent ============================================================================== --- head/release/doc/share/xml/release.ent Sun Jun 23 20:09:58 2013 (r252120) +++ head/release/doc/share/xml/release.ent Sun Jun 23 20:19:00 2013 (r252121) @@ -6,7 +6,9 @@ - + + + - - - +