From owner-freebsd-arch@FreeBSD.ORG Sun Aug 28 01:09:15 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 286D91065673 for ; Sun, 28 Aug 2011 01:09:15 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (pancho.soaustin.net [76.74.250.40]) by mx1.freebsd.org (Postfix) with ESMTP id 085668FC0C for ; Sun, 28 Aug 2011 01:09:14 +0000 (UTC) Received: by mail.soaustin.net (Postfix, from userid 502) id B58805619E; Sat, 27 Aug 2011 19:53:48 -0500 (CDT) Date: Sat, 27 Aug 2011 19:53:48 -0500 From: Mark Linimon To: Garrett Cooper Message-ID: <20110828005348.GA18026@lonesome.com> References: <1314473398.47547.YahooMailClassic@web113509.mail.gq1.yahoo.com> <4E594D6A.9060407@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: ohauer@freebsd.org, freebsd-arch@freebsd.org, giffunip@tutopia.com, Eitan Adler Subject: Re: How about finally replacing GNATS? (was Re: FreeBSD problems and preliminary ways to solve) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Aug 2011 01:09:15 -0000 On Sat, Aug 27, 2011 at 01:11:42PM -0700, Garrett Cooper wrote: > (I remember several times that spammers tried pounding the crud > out of GNATS with useless requests). We now have countermeasures. mcl From owner-freebsd-arch@FreeBSD.ORG Sun Aug 28 07:22:34 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 304A3106566C for ; Sun, 28 Aug 2011 07:22:34 +0000 (UTC) (envelope-from ohauer@FreeBSD.org) Received: from p578be941.dip0.t-ipconnect.de (p578be941.dip0.t-ipconnect.de [87.139.233.65]) by mx1.freebsd.org (Postfix) with ESMTP id C8AA08FC1B for ; Sun, 28 Aug 2011 07:22:33 +0000 (UTC) Received: from [192.168.0.100] (cde1100.uni.vrs [192.168.0.100]) (Authenticated sender: ohauer) by p578be941.dip0.t-ipconnect.de (Postfix) with ESMTPSA id 51C5720820; Sun, 28 Aug 2011 09:22:27 +0200 (CEST) Message-ID: <4E59ECB5.6060307@FreeBSD.org> Date: Sun, 28 Aug 2011 09:22:29 +0200 From: Olli Hauer User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: freebsd-arch@freebsd.org References: <201108272157.p7RLuwK5047179@fire.js.berklix.net> In-Reply-To: <201108272157.p7RLuwK5047179@fire.js.berklix.net> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: "Julian H. Stacey" Subject: Re: How about finally replacing GNATS? (was Re: FreeBSD problems and preliminary ways to solve) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ohauer@FreeBSD.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Aug 2011 07:22:34 -0000 On 2011-08-27 23:56, Julian H. Stacey wrote: > Benjamin Kaduk wrote: >> We have used JIRA, Trac, and Request Tracker ... > > Might there be another newish/ interesting bug tracker here ? > http://gforge.cs.vu.nl/gf/project/minix/tracker/ [snip ..] This is the gforge tracker http://gforge.org/ The older gforge versions are based on the public sf.net sources, newer version are rewritten but using ionCube to crypt parts of the php sources. An older version (4.5.19) is in the ports tree (www/gforge). The new (actual) sf.net portal/tracker is known as Allura. - http://sourceforge.net/blog/an-open-forge/ - http://sourceforge.net/p/allura/ From owner-freebsd-arch@FreeBSD.ORG Sun Aug 28 09:25:58 2011 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 911591065677; Sun, 28 Aug 2011 09:25:58 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id AB17D8FC13; Sun, 28 Aug 2011 09:25:57 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA13524; Sun, 28 Aug 2011 12:25:55 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Qxbcp-000ODl-4f; Sun, 28 Aug 2011 12:25:55 +0300 Message-ID: <4E5A099F.4060903@FreeBSD.org> Date: Sun, 28 Aug 2011 12:25:51 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0) Gecko/20110819 Thunderbird/6.0 MIME-Version: 1.0 To: freebsd-arch@FreeBSD.org, Hans Petter Selasky References: <4E53986B.5000804@FreeBSD.org> In-Reply-To: <4E53986B.5000804@FreeBSD.org> X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: skipping locks, mutex_owned, usb X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Aug 2011 09:25:58 -0000 on 23/08/2011 15:09 Andriy Gapon said the following: > This "XXX cludge" [sic] pattern is scattered around a few functions in the ukbd > code and perhaps other usb code: > func() > { > if (!mtx_owned(&Giant)) { > mtx_lock(&Giant); > func(); > mtx_unlock(&Giant); > return; > } > > // etc ... > } Ohhh, nothing seems simple with the USB code: /* make sure that the BUS mutex is not locked */ drop_bus = 0; while (mtx_owned(&xroot->udev->bus->bus_mtx)) { mtx_unlock(&xroot->udev->bus->bus_mtx); drop_bus++; } /* make sure that the transfer mutex is not locked */ drop_xfer = 0; while (mtx_owned(xroot->xfer_mtx)) { mtx_unlock(xroot->xfer_mtx); drop_xfer++; } So many unconventional tricks. -- Andriy Gapon From owner-freebsd-arch@FreeBSD.ORG Sun Aug 28 09:30:19 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1429106566C; Sun, 28 Aug 2011 09:30:19 +0000 (UTC) (envelope-from hselasky@freebsd.org) Received: from swip.net (mailfe07.c2i.net [212.247.154.194]) by mx1.freebsd.org (Postfix) with ESMTP id 1BC328FC0A; Sun, 28 Aug 2011 09:30:18 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=We2KpSpXIp7zua8olfHtbA6oPL2p8ijoExYxXUNIRvU= c=1 sm=1 a=SvYTsOw2Z4kA:10 a=ni9ZY7ZFbhgA:10 a=dBRESv0yCI8A:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=Ixxbx_S_ukA7SaRvA8wA:9 a=wPNLvfGTeEIA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe07.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 171642795; Sun, 28 Aug 2011 11:30:16 +0200 Received-SPF: softfail receiver=mailfe07.swip.net; client-ip=188.126.198.129; envelope-from=hselasky@freebsd.org From: Hans Petter Selasky To: freebsd-arch@freebsd.org Date: Sun, 28 Aug 2011 11:27:44 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: <4E53986B.5000804@FreeBSD.org> <4E5A099F.4060903@FreeBSD.org> In-Reply-To: <4E5A099F.4060903@FreeBSD.org> X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq, NwSZ4V"|LR.+tj}g5 %V,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( :AuzV9:.hESm-x4h240C`9=w MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201108281127.44696.hselasky@freebsd.org> Cc: Andriy Gapon Subject: Re: skipping locks, mutex_owned, usb X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Aug 2011 09:30:19 -0000 On Sunday 28 August 2011 11:25:51 Andriy Gapon wrote: > on 23/08/2011 15:09 Andriy Gapon said the following: > > This "XXX cludge" [sic] pattern is scattered around a few functions in > > the ukbd code and perhaps other usb code: > > func() > > { > > > > if (!mtx_owned(&Giant)) { > > > > mtx_lock(&Giant); > > > > func(); > > mtx_unlock(&Giant); > > > > return; > > > > } > > > > // etc ... > > > > } > > Ohhh, nothing seems simple with the USB code: > > /* make sure that the BUS mutex is not locked */ > drop_bus = 0; > while (mtx_owned(&xroot->udev->bus->bus_mtx)) { > mtx_unlock(&xroot->udev->bus->bus_mtx); > drop_bus++; > } > > /* make sure that the transfer mutex is not locked */ > drop_xfer = 0; > while (mtx_owned(xroot->xfer_mtx)) { > mtx_unlock(xroot->xfer_mtx); > drop_xfer++; > } > > So many unconventional tricks. Similar code is used in the DROP_GIANT and PICKUP_GIANT macros. You might want to check all references to mtx_owned() in the kernel, and make a set of exceptions for post-panic code execution. --HPS From owner-freebsd-arch@FreeBSD.ORG Sun Aug 28 12:34:22 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A6E6D1065672 for ; Sun, 28 Aug 2011 12:34:22 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 696548FC0A for ; Sun, 28 Aug 2011 12:34:22 +0000 (UTC) Received: by vxh11 with SMTP id 11so4755246vxh.13 for ; Sun, 28 Aug 2011 05:34:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=KtggdQlFi8TTbMMTGTG4mOB4Nd31yFrK/UidSGbed14=; b=OJuGLVRJg+jjQgE3aMXojSDvIGF+d0P1MavDpDHb5US2mSLYDtLg3+kTmN0eIYTO7X 6SvmBfWdYDsVs7r2sQsDv7iLsnlQrbORfRnx/7pyAjAKzX767Zt1wa/AxvkX2tkzNK8E NAeeiqameuSYfxA1AAUfXLNWlZXf0Y1B6e840= MIME-Version: 1.0 Received: by 10.220.115.205 with SMTP id j13mr1010671vcq.136.1314533116908; Sun, 28 Aug 2011 05:05:16 -0700 (PDT) Sender: kmacybsd@gmail.com Received: by 10.52.186.163 with HTTP; Sun, 28 Aug 2011 05:05:16 -0700 (PDT) Date: Sun, 28 Aug 2011 14:05:16 +0200 X-Google-Sender-Auth: ACptGEbjTx8f31inLoD2WVJ7sJI Message-ID: From: "K. Macy" To: arch@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Prefixing system calls to eliminate namespace collisions between kernel and libc X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Aug 2011 12:34:22 -0000 This change was motivated by a library that I have written which is, in effect, a run-time environment for running the freebsd kernel network stack in userspace. With the exception of a small change to makesyscalls.sh, this change is entirely mechanical. All non-compatibility kernel entry points (e.g. not linux_, freebsd32_, freebsd6_, etc.) are prefixed with sys_ to eliminate collisions between system call implementations and their libc names. NetBSD long ago made this change as well. and for linux this may always have been the case. Linking POSIX programs against parts of the kernel can actually be done just by mangling things during dynamic linking, so doesn't require the above, but it is certainly easier and more portable with the above. Ultimately I would like my userspace network stack to be able to run on windows as well. I don't think that I have the same flexibility there with regards to linker scripts. My userspace stack could ease networking code development by allowing initial work to take place in userspace. syscalls.master is unchanged: 97 AUE_SOCKET STD { int socket(int domain, int type, \ int protocol); } Only the source function changes name: diff --git a/sys/kern/uipc_syscalls.c b/sys/kern/uipc_syscalls.c index 0e5efe6..3b83e1c 100644 --- a/sys/kern/uipc_syscalls.c +++ b/sys/kern/uipc_syscalls.c @@ -171,7 +171,7 @@ getsock_cap(struct filedesc *fdp, int fd, cap_rights_t rights, #endif int -socket(td, uap) +sys_socket(td, uap) struct thread *td; struct socket_args /* { int domain; @@ -210,7 +210,7 @@ socket(td, uap) Please see: http://pastebin.com/PpC5uThs From owner-freebsd-arch@FreeBSD.ORG Sun Aug 28 14:34:27 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18CD61065679; Sun, 28 Aug 2011 14:34:27 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id E95648FC22; Sun, 28 Aug 2011 14:34:26 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 769C546B1A; Sun, 28 Aug 2011 10:34:26 -0400 (EDT) Date: Sun, 28 Aug 2011 15:34:26 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: "K. Macy" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org Subject: Re: Prefixing system calls to eliminate namespace collisions between kernel and libc X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Aug 2011 14:34:27 -0000 On Sun, 28 Aug 2011, K. Macy wrote: > NetBSD long ago made this change as well. and for linux this may always have > been the case. Linking POSIX programs against parts of the kernel can > actually be done just by mangling things during dynamic linking, so doesn't > require the above, but it is certainly easier and more portable with the > above. Ultimately I would like my userspace network stack to be able to run > on windows as well. I don't think that I have the same flexibility there > with regards to linker scripts. This seems pretty reasonable to me. The reason I have considered similar changes in the past was the additional case you cite above: it makes it a bit easier to link a POSIX-based application directly into the FreeBSD kernel. As you point out, we could address that problem by teaching our kernel linker about different namespaces, handling mangling at load-time. However, I think your approach works better as it avoids the need for "special" linkage. There are a number of other potential areas of collisions that I'm aware of: (1) libc-like interfaces such as malloc(9), which differs observably from malloc(3); libkern is mostly the same (and often literally the same code) but it could be other tweaks are required. One fix here is to move to calling our kernel malloc kmalloc(9). I see that as a somewhat larger change though, but perhaps less pressing as it's a very small number of collisions that we can handle explicitly. (2) Other libraries that are derived from or share code with the kernel, but that might have interfaces with different semantics. libsbuf and libbsm come particularly to mind, but there might well be others. I think these can be fixed without too much trouble, and I'm happy to ponder the libbsm case myself. (3) The kernel RPC code, which uses interfaces very much like userspace. It could be that, in fact, they are the same APIs in userspace, but we will need to check as that's a non-trivial part of the symbol namespace. This might be particularly relevant if you want userspace RPC code to be able to use your userspace instance of the network stack. Possibly prefixing 'k' in front of a lot of things would be useful here as well... In general, consider me supportive of this cleanup -- it would make a number of things I'd like to do much easier. Abstractly, it seems like we should treat the two namespaces as being completely independent (hence thoughts of symbol mangling in the linker), but in practical terms it should be quite useful and might prevent having to solve much harder problems. On a semi-related note: it would be nice if the kernel had an explicit symbol export list for kernel symbols, as our modules themselves support. This would make it easier to discourage third parties from using "less public" interfaces in kernel modules, which tends to make those kernel modules fragile in the presence of regular baseline development... Robert From owner-freebsd-arch@FreeBSD.ORG Sun Aug 28 20:12:34 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62E6B106564A for ; Sun, 28 Aug 2011 20:12:34 +0000 (UTC) (envelope-from freebsd-arch@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 1462D8FC12 for ; Sun, 28 Aug 2011 20:12:33 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Qxlia-0005go-Ew for freebsd-arch@freebsd.org; Sun, 28 Aug 2011 22:12:32 +0200 Received: from 208.88.188.90.adsl.tomsknet.ru ([90.188.88.208]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 28 Aug 2011 22:12:32 +0200 Received: from vadim_nuclight by 208.88.188.90.adsl.tomsknet.ru with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 28 Aug 2011 22:12:32 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-arch@freebsd.org From: Vadim Goncharov Date: Sun, 28 Aug 2011 20:12:18 +0000 (UTC) Organization: Nuclear Lightning @ Tomsk, TPU AVTF Hostel Lines: 21 Message-ID: References: <35765857-1314243257-cardhu_decombobulator_blackberry.rim.net-329610575-@b2.c15.bise7.blackberry> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 208.88.188.90.adsl.tomsknet.ru X-Comment-To: Jonathan Anderson User-Agent: slrn/0.9.9p1 (FreeBSD) Subject: Re: Official git export X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vadim_nuclight@mail.ru List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Aug 2011 20:12:34 -0000 Hi Jonathan Anderson! On Fri, 26 Aug 2011 11:04:32 +0100; Jonathan Anderson wrote about 'Re: Official git export (was: Re: FreeBSD problems and preliminary ways to solve)': > One of the downsides of using git-svn is that some things (e.g. "make > sysent") expect the $FreeBSD$ in our header files to be expanded to > something SVN-ey, but Git believes that it shouldn't munge source > code: it's an immutable blob. So, when changing syscalls, one needs to > check out syscalls.master using freebsd-subversion, copy it to the Git > repo, run "make sysent" and then finally revert syscalls.master to > what Git expects it to be (just "$FreeBSD$" at the top). There's a > viable argument to be had here as to whether this is a Git problem or > an assumption-that-the-script-makes problem, but it is a nit to be > aware of. Given thar Mercurial (hg), being a Git-like DVCS, has a plugin to do $Id$ conversions, it's definetely Git problem. -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Anti-Greenpeace][Sober FreeBSD zealot][http://nuclight.livejournal.com] From owner-freebsd-arch@FreeBSD.ORG Sun Aug 28 20:24:09 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 611D1106564A for ; Sun, 28 Aug 2011 20:24:09 +0000 (UTC) (envelope-from freebsd-arch@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id D54F68FC12 for ; Sun, 28 Aug 2011 20:24:08 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Qxltn-0000no-Jw for freebsd-arch@freebsd.org; Sun, 28 Aug 2011 22:24:07 +0200 Received: from 208.88.188.90.adsl.tomsknet.ru ([90.188.88.208]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 28 Aug 2011 22:24:07 +0200 Received: from vadim_nuclight by 208.88.188.90.adsl.tomsknet.ru with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 28 Aug 2011 22:24:07 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-arch@freebsd.org From: Vadim Goncharov Date: Sun, 28 Aug 2011 20:23:53 +0000 (UTC) Organization: Nuclear Lightning @ Tomsk, TPU AVTF Hostel Lines: 42 Message-ID: References: <20110821110521.GA48820@server.vk2pj.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 208.88.188.90.adsl.tomsknet.ru X-Comment-To: Marcin Wisnicki User-Agent: slrn/0.9.9p1 (FreeBSD) Subject: Re: FreeBSD problems and preliminary ways to solve X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vadim_nuclight@mail.ru List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Aug 2011 20:24:09 -0000 Hi Marcin Wisnicki! On Mon, 22 Aug 2011 18:33:45 +0000 (UTC); Marcin Wisnicki wrote about 'Re: FreeBSD problems and preliminary ways to solve': >>>1) No pkg and pkg-devel versions. The -devel version is headers, static >>> libs, programmer examples, etc. not needed in production (we could >>> say this part is what is actually depended on in B-deps). >> >> Xorg is partially broken up in this way. In general, it is up to the >> ports' maintainers to do this - the FreeBSD project just hosts the ports >> infrastructure, it's up to maintainers to supply and maintain the actual >> ports. Note that requiring both pkg and pkg-devel versions of ports >> significantly increases maintainer effort for little (to them) perceived >> value. Also, I find having separate pkg and pkg-devel versions a real >> PITA - I regularly find that information i need is missing from the pkg >> file and I have to dig out the missing files. >> >> Out of interest, what is the rationale behind this requirement. > I too find lack of -devel packages as one of freebsd strengths not > weaknesses. > Such separation is also very specific to certain languages like C/C++. > However to provide a middle-ground solution I once proposed installation > filters based on patterns, which would give ability to not have unwanted > files essentially for free (just small changes in pkg_* and ports/Mk). > For example there could be a standard filter group called "devel" that > includes "include/**" and "lib/**.a". That's simple, but won't work for all cases. For example, aforementioned example of glib and perl will nit be catched. Also, this exclusion is blind: it's better for maintainer to flag group of files as not needed. > Packages would have ability to exclude/include additional files to any > group if needed using pkg-plist directives. > Similar patterns could be defined for docs, localizations, etc. > User would set which groups of files he wants to exclude during > installation or after it. That's sounds more like OPTIONS and more likely will work. -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Anti-Greenpeace][Sober FreeBSD zealot][http://nuclight.livejournal.com] From owner-freebsd-arch@FreeBSD.ORG Sun Aug 28 21:18:46 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E1203106564A for ; Sun, 28 Aug 2011 21:18:46 +0000 (UTC) (envelope-from freebsd-arch@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 6DBBC8FC13 for ; Sun, 28 Aug 2011 21:18:46 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Qxmke-0008TC-SC for freebsd-arch@freebsd.org; Sun, 28 Aug 2011 23:18:44 +0200 Received: from 208.88.188.90.adsl.tomsknet.ru ([90.188.88.208]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 28 Aug 2011 23:18:44 +0200 Received: from vadim_nuclight by 208.88.188.90.adsl.tomsknet.ru with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 28 Aug 2011 23:18:44 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-arch@freebsd.org From: Vadim Goncharov Date: Sun, 28 Aug 2011 21:18:32 +0000 (UTC) Organization: Nuclear Lightning @ Tomsk, TPU AVTF Hostel Lines: 31 Message-ID: References: <35765857-1314243257-cardhu_decombobulator_blackberry.rim.net-329610575-@b2.c15.bise7.blackberry> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 208.88.188.90.adsl.tomsknet.ru X-Comment-To: Robert Watson User-Agent: slrn/0.9.9p1 (FreeBSD) Subject: Re: Official git export X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vadim_nuclight@mail.ru List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Aug 2011 21:18:47 -0000 Hi Robert Watson! On Fri, 26 Aug 2011 10:06:32 +0100 (BST); Robert Watson wrote about 'Official git export (was: Re: FreeBSD problems and preliminary ways to solve)': > One way to do this is to make "more official" our output if git exports of the > repository -- something that many other Subversion-based projects do: > Chromium, clang/LLVM, Tor, etc. Folk like Ulrich have been doing this on a > casual basis for some time, but I think we need to formalise this and provide > end-user documentation on how to use git to track FreeBSD, contribute patches, > etc. There are a number of hitches people have to know about: the potential > impact of obliteration, how to handle $FreeBSD$ correctly for system call > additions, and so on. Simply writing them down and having an official > git.FreeBSD.org (or even gitsvn.FreeBSD.org) would go a long way. Is it only the git what is considered? Mercurial (hg) has a plugin for $Id$ conversion and is popular enough, too. > I have to admit I've always preferred Perforce to git, simply because it > strikes me as a more structured approach, partial checkouts (but especially > composition of different depot pieces in a single checkout to create hybrid > trees), etc. But git is widely used, and quite effectively used, by large > communities. We need to support those communities better. I haven't worked with Perforce, do you mean I could checkout at once several directories e.g. sbin/ipfw and sys/netinet/ipfw in my working copy? If so, sounds good. May be FreeBSD should really write it's own VCS, just as Git was modelled after proprietary BitKeeper?.. -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Anti-Greenpeace][Sober FreeBSD zealot][http://nuclight.livejournal.com] From owner-freebsd-arch@FreeBSD.ORG Sun Aug 28 22:44:49 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F893106566C for ; Sun, 28 Aug 2011 22:44:49 +0000 (UTC) (envelope-from freebsd-arch@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id B539D8FC08 for ; Sun, 28 Aug 2011 22:44:48 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Qxo5v-0005Yq-QQ for freebsd-arch@freebsd.org; Mon, 29 Aug 2011 00:44:47 +0200 Received: from 208.88.188.90.adsl.tomsknet.ru ([90.188.88.208]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 29 Aug 2011 00:44:47 +0200 Received: from vadim_nuclight by 208.88.188.90.adsl.tomsknet.ru with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 29 Aug 2011 00:44:47 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-arch@freebsd.org From: Vadim Goncharov Date: Sun, 28 Aug 2011 22:44:33 +0000 (UTC) Organization: Nuclear Lightning @ Tomsk, TPU AVTF Hostel Lines: 79 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 208.88.188.90.adsl.tomsknet.ru X-Comment-To: All User-Agent: slrn/0.9.9p1 (FreeBSD) Subject: FreeBSD problems/solutions: to actions X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vadim_nuclight@mail.ru List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Aug 2011 22:44:49 -0000 Hi, There were many talks about problems, possible solutions, etc. But these are still talks. Just words with no value. Ten days ago I've posted a message with some proposals, the subject was "FreeBSD problems/solutions: voting system & marketing surveys". ``Two times he called to, but silence was the answer. And the last, third time...'' I could say it my own words, but I'll better quote experts: | A terribly common error is having a debate over how something should | be designed, and then *never resolving the debate*. Brian | Valentine, the lead developer on Windows 2000, was famous for his | motto "Decisions in 10 minutes or less, or the next one is free." | | In too many programming organizations, every time there's a design | debate, nobody ever manages to make a *decision*, usually for | political reasons. So the programmers only work on uncontroversial | stuff. As time goes on, all the hard decisions are pushed to the | end. *These are the most likely projects to fail*. | -- Joel Spolsky "Please provide an official reply with opinion of the FreeBSD Project", I've asked. It doesn't matter if this official opinion is actually backed by a consensus in developers@ or core@, from whom it originated, etc. What matters that it is still official (e.g. users see it from one of the Project's authorities) and contains decisions which later spawn things like roadmaps. Don't claim it's impossible - official decisions, followed by everyone staying in the Project, have occured many times in our history, the most remarkable was the way for SMP/5.x. Actions could follow only after decisions, and decision is an equivalent of choice - even if nothing changes, it is still a choice between change and status quo, and it must be approved by decision. The FreeBSD Project's destiny in fact depends only on internal things. No external circumstances could lead to death of the Project, but only the lack of right decisions. And undecisiveness is more harmful than wrong decisions. This is the third, last appeal I write, because there is nothing more an individual could say and do. Group efforts are required now, and actions begin from decisions. Even if there were not enough proposals, still some actions ("bootstrapping") are required to continue constructive work/discussion. I could just say now for myself, and wish a little for whose who hear. Principle is simple: just do what you can. Irreproachability. E.g. if you didn't try another way of doing things (like sorting ideas for Foundation, targeted donations) - then just try. The case of "I tried what I could" vs "I didn't even try 'coz I *thought* it is no sense" (thoughts are not reality, mistakes occur, checks are needed). Personally I will return to: 1) writing network-related code 2) writing articles about FreeBSD (popularizing/introductory to e.g. Netgraph) 3) voting system, if this will be accepted by the Project. I still wait the official answer, may be not to my exact question, but with at least *some* decisions. This is important for all of us. That's natural selection: facing to critical problem, decide or die. -- WBR, Vadim Goncharov, acting as a carmic imperative in 10th house. ...Abyssus ad Abyssum invocat in voce catarractarum Tuarum. Responde profunditatibus glacialibus caliginis impellucidae Tuae. [Anti-Greenpeace][Sober FreeBSD zealot][http://nuclight.livejournal.com] From owner-freebsd-arch@FreeBSD.ORG Mon Aug 29 04:24:34 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8503106566C; Mon, 29 Aug 2011 04:24:34 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 9ABA98FC0C; Mon, 29 Aug 2011 04:24:34 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p7T4BkLX045936 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 28 Aug 2011 21:11:48 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4E5B1194.2020600@freebsd.org> Date: Sun, 28 Aug 2011 21:12:04 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.20) Gecko/20110804 Thunderbird/3.1.12 MIME-Version: 1.0 To: "K. Macy" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org Subject: Re: Prefixing system calls to eliminate namespace collisions between kernel and libc X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 04:24:34 -0000 On 8/28/11 5:05 AM, K. Macy wrote: > This change was motivated by a library that I have written which is, > in effect, a run-time environment for running the freebsd kernel > network stack in userspace. With the exception of a small change to > makesyscalls.sh, this change is entirely mechanical. All > non-compatibility kernel entry points (e.g. not linux_, freebsd32_, > freebsd6_, etc.) are prefixed with sys_ to eliminate collisions > between system call implementations and their libc names. > > NetBSD long ago made this change as well. and for linux this may > always have been the case. Linking POSIX programs against parts of the > kernel can actually be done just by mangling things during dynamic > linking, so doesn't require the above, but it is certainly easier and > more portable with the above. Ultimately I would like my userspace > network stack to be able to run on windows as well. I don't think that > I have the same flexibility there with regards to linker scripts. > > My userspace stack could ease networking code development by allowing > initial work to take place in userspace. > > syscalls.master is unchanged: > 97 AUE_SOCKET STD { int socket(int domain, int type, \ > int protocol); } > > Only the source function changes name: > diff --git a/sys/kern/uipc_syscalls.c b/sys/kern/uipc_syscalls.c > index 0e5efe6..3b83e1c 100644 > --- a/sys/kern/uipc_syscalls.c > +++ b/sys/kern/uipc_syscalls.c > @@ -171,7 +171,7 @@ getsock_cap(struct filedesc *fdp, int fd, > cap_rights_t rights, > #endif > > int > -socket(td, uap) > +sys_socket(td, uap) > struct thread *td; > struct socket_args /* { > int domain; > @@ -210,7 +210,7 @@ socket(td, uap) > > > > Please see: > > http://pastebin.com/PpC5uThs > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > I see no reason to not make this change.. actually I'd be happy making in 9. From owner-freebsd-arch@FreeBSD.ORG Mon Aug 29 04:54:54 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F11C9106564A for ; Mon, 29 Aug 2011 04:54:53 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-yi0-f54.google.com (mail-yi0-f54.google.com [209.85.218.54]) by mx1.freebsd.org (Postfix) with ESMTP id B161F8FC08 for ; Mon, 29 Aug 2011 04:54:53 +0000 (UTC) Received: by yib19 with SMTP id 19so3841695yib.13 for ; Sun, 28 Aug 2011 21:54:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=7BVoqgiVrRucDuCimJuY34oNTXOTnvgIA9dtiPqfnug=; b=AHuv7ss2tv0j8gNWsJSFuOsfuapzVtC2Qqs/qAOxkHpNaQ0B5Y3dCJoTTqMM+fcelX Eubey46XB57/+9oZ/OC/q2w/4S8bRmBrjiEa6yjC8vO/vvgTJNdpR4RXX4nmYgJ6UOZL 2wEN/KpsHMkvPeHYehV6XjRZ4+6qz1ZSuTARc= MIME-Version: 1.0 Received: by 10.151.42.18 with SMTP id u18mr4393083ybj.429.1314592328164; Sun, 28 Aug 2011 21:32:08 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.150.145.21 with HTTP; Sun, 28 Aug 2011 21:32:08 -0700 (PDT) In-Reply-To: <4E5B1194.2020600@freebsd.org> References: <4E5B1194.2020600@freebsd.org> Date: Mon, 29 Aug 2011 12:32:08 +0800 X-Google-Sender-Auth: GipM-a_-5V-uqGjnJaAuxCWvxv4 Message-ID: From: Adrian Chadd To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 Cc: arch@freebsd.org, "K. Macy" Subject: Re: Prefixing system calls to eliminate namespace collisions between kernel and libc X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 04:54:54 -0000 On 29 August 2011 12:12, Julian Elischer wrote: > I see no reason to not make this change.. actually I'd be happy making in 9. (pushes the +1 button somewhere) It'd be nice if other source modules of the kernel could be run in userspace too, like GEOM modules. (I'm not saying this should be part of Kip's goals; I just thought about it whilst Nathan was talking about why partition stuff is written out early during bsdinstall - because he needs the feedback from GEOM.) Adrian From owner-freebsd-arch@FreeBSD.ORG Mon Aug 29 08:10:58 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A4D0106566C for ; Mon, 29 Aug 2011 08:10:58 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id 562628FC16 for ; Mon, 29 Aug 2011 08:10:58 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id p7T8Au83067935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 29 Aug 2011 01:10:57 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id p7T8AulM067934; Mon, 29 Aug 2011 01:10:56 -0700 (PDT) Received: from fbsd81 ([192.168.200.81]) by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA14690; Mon, 29 Aug 11 01:01:28 PDT Date: Mon, 29 Aug 2011 08:01:23 -0700 From: perryh@pluto.rain.com To: vadim_nuclight@mail.ru Message-Id: <4e5ba9c3.bzHIw1KEy8R2QcK7%perryh@pluto.rain.com> References: <35765857-1314243257-cardhu_decombobulator_blackberry.rim.net-329610575-@b2.c15.bise7.blackberry> In-Reply-To: User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: Official git export X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 08:10:58 -0000 Vadim Goncharov wrote: > May be FreeBSD should really write it's own VCS, just as Git was > modelled after proprietary BitKeeper?.. Good luck getting agreement on what to model it on :) Personally I would suggest ClearCase as a model, but that's largely because I'm familiar with it. From owner-freebsd-arch@FreeBSD.ORG Mon Aug 29 08:29:38 2011 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74C91106564A; Mon, 29 Aug 2011 08:29:38 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 894F58FC0A; Mon, 29 Aug 2011 08:29:37 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA28902; Mon, 29 Aug 2011 11:29:36 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1QxxDr-0001Jv-Qi; Mon, 29 Aug 2011 11:29:35 +0300 Message-ID: <4E5B4DEF.9050106@FreeBSD.org> Date: Mon, 29 Aug 2011 11:29:35 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0) Gecko/20110819 Thunderbird/6.0 MIME-Version: 1.0 To: Hans Petter Selasky References: <4E53986B.5000804@FreeBSD.org> <4E5A099F.4060903@FreeBSD.org> <201108281127.44696.hselasky@freebsd.org> In-Reply-To: <201108281127.44696.hselasky@freebsd.org> X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-arch@FreeBSD.org Subject: Re: skipping locks, mutex_owned, usb X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 08:29:38 -0000 on 28/08/2011 12:27 Hans Petter Selasky said the following: > On Sunday 28 August 2011 11:25:51 Andriy Gapon wrote: >> So many unconventional tricks. > > Similar code is used in the DROP_GIANT and PICKUP_GIANT macros. Thank you for pointing this out - I was unfair to the USB code. This changes my perspective of the mtx_owned issue a little bit... OTOH, it looks like DROP_GIANT/PICKUP_GIANT are used in the code paths that should not be exercised in the post-panic / dumping environment. Except, perhaps, for the sync-on-panic option, which needs to be re-worked anyways. > You might want > to check all references to mtx_owned() in the kernel, and make a set of > exceptions for post-panic code execution. $ glimpse mtx_owned | wc -l 152 This looks like a too large plate for me :-( -- Andriy Gapon From owner-freebsd-arch@FreeBSD.ORG Mon Aug 29 08:34:16 2011 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04B42106566B for ; Mon, 29 Aug 2011 08:34:16 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 4970B8FC14 for ; Mon, 29 Aug 2011 08:34:15 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA28950 for ; Mon, 29 Aug 2011 11:34:13 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1QxxIL-0001K3-M1 for freebsd-arch@freebsd.org; Mon, 29 Aug 2011 11:34:13 +0300 Message-ID: <4E5B4F05.4090505@FreeBSD.org> Date: Mon, 29 Aug 2011 11:34:13 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0) Gecko/20110819 Thunderbird/6.0 MIME-Version: 1.0 To: freebsd-arch@FreeBSD.org References: <4E53986B.5000804@FreeBSD.org> <201108230911.09021.jhb@freebsd.org> <4E564F15.3010809@FreeBSD.org> <201108250945.24606.jhb@freebsd.org> <4E57E5D8.3010606@FreeBSD.org> In-Reply-To: <4E57E5D8.3010606@FreeBSD.org> X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: skipping locks, mutex_owned, usb X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 08:34:16 -0000 on 26/08/2011 21:28 Andriy Gapon said the following: > I do not see how internal state of kbd drivers is protected from races between > interrupts and calls from upper layers. The only possibility that I see is that > kbd interrupt handlers do not directly change the driver state but rather "call > back" into the driver via sckbdevent(). Errm, it was pointed out to me that INTR_MPSAFE flag is not passed to bus_setup_intr() for those interrupts, so the interrupt handlers are executed under the Giant -- Andriy Gapon From owner-freebsd-arch@FreeBSD.ORG Mon Aug 29 09:03:57 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46546106566B for ; Mon, 29 Aug 2011 09:03:57 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 017DA8FC15 for ; Mon, 29 Aug 2011 09:03:56 +0000 (UTC) Received: by vws18 with SMTP id 18so5705477vws.13 for ; Mon, 29 Aug 2011 02:03:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=OPbTPP+WuRND1kK07IDxYP4dI5H5V+KFZaJIvKHA23E=; b=YasF0ML/WgNu8GKCGx1E/ztzgwKb2LIHCQY4K2SATL2WOUPfINebs2KszTomkxOEcp oyRByobskgGnjm0FIsqXXcYZaB6/9NL2VFYDhpoG2+un+jcddhxwd5oT/dZh08aaYEfg PE8nld9FxINjlq5LnKGgJvgBxG5OqV9GpJU9s= MIME-Version: 1.0 Received: by 10.220.190.6 with SMTP id dg6mr1020286vcb.153.1314608636198; Mon, 29 Aug 2011 02:03:56 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.52.33.49 with HTTP; Mon, 29 Aug 2011 02:03:56 -0700 (PDT) In-Reply-To: <4e5ba9c3.bzHIw1KEy8R2QcK7%perryh@pluto.rain.com> References: <35765857-1314243257-cardhu_decombobulator_blackberry.rim.net-329610575-@b2.c15.bise7.blackberry> <4e5ba9c3.bzHIw1KEy8R2QcK7%perryh@pluto.rain.com> Date: Mon, 29 Aug 2011 17:03:56 +0800 X-Google-Sender-Auth: TiwU0rVNRC9tkryEm2lT7_njlsc Message-ID: From: Adrian Chadd To: perryh@pluto.rain.com Content-Type: text/plain; charset=ISO-8859-1 Cc: vadim_nuclight@mail.ru, freebsd-arch@freebsd.org Subject: Re: Official git export X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 09:03:57 -0000 On 29 August 2011 23:01, wrote: >> May be FreeBSD should really write it's own VCS, just as Git was >> modelled after proprietary BitKeeper?.. > > Good luck getting agreement on what to model it on :) git but with some better tools for managing a tree as big as ours? :) (eg keep total branch database/metadata, but support sparse checkouts, some better git<->svn integration?) Adrian From owner-freebsd-arch@FreeBSD.ORG Mon Aug 29 09:54:15 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A712F106566C for ; Mon, 29 Aug 2011 09:54:15 +0000 (UTC) (envelope-from freebsd-arch@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 318D78FC0C for ; Mon, 29 Aug 2011 09:54:14 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QxyXj-0000Qv-GP for freebsd-arch@freebsd.org; Mon, 29 Aug 2011 11:54:11 +0200 Received: from 208.88.188.90.adsl.tomsknet.ru ([90.188.88.208]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 29 Aug 2011 11:54:11 +0200 Received: from vadim_nuclight by 208.88.188.90.adsl.tomsknet.ru with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 29 Aug 2011 11:54:11 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-arch@freebsd.org From: Vadim Goncharov Date: Mon, 29 Aug 2011 09:53:57 +0000 (UTC) Organization: Nuclear Lightning @ Tomsk, TPU AVTF Hostel Lines: 29 Message-ID: References: <35765857-1314243257-cardhu_decombobulator_blackberry.rim.net-329610575-@b2.c15.bise7.blackberry> <4e5ba9c3.bzHIw1KEy8R2QcK7%perryh@pluto.rain.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 208.88.188.90.adsl.tomsknet.ru X-Comment-To: Adrian Chadd User-Agent: slrn/0.9.9p1 (FreeBSD) Subject: Own VCS (Was: Official git export) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vadim_nuclight@mail.ru List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 09:54:15 -0000 Hi Adrian Chadd! On Mon, 29 Aug 2011 17:03:56 +0800; Adrian Chadd wrote about 'Re: Official git export': >>> May be FreeBSD should really write it's own VCS, just as Git was >>> modelled after proprietary BitKeeper?.. >> >> Good luck getting agreement on what to model it on :) > git but with some better tools for managing a tree as big as ours? :) > (eg keep total branch database/metadata, but support sparse checkouts, > some better git<->svn integration?) No. Completely own BSD-licensed DVCS designed specifically for FreeBSD, allowing partial checkouts and intended to replace SVN in the future :) If you briefly know the git ot hg architecture, then you may notice that "commit" references "tree", each subdir points to another "tree", so that "tree" is like a directory on a FAT file system: file name directly references file data. So only entire repository could be fetched. If it will be designed like a Unix file systems, then an "inode" object could be separate from "directory", and with a little help partial checkouts are now possible (subset of inodes). Git also doesn't handle renames natively, and with inodes it should be a trivial change in the "directory" file, easily mergeable. -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Anti-Greenpeace][Sober FreeBSD zealot][http://nuclight.livejournal.com] From owner-freebsd-arch@FreeBSD.ORG Mon Aug 29 12:20:16 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74DFF10656D3 for ; Mon, 29 Aug 2011 12:20:16 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2BCD58FC1E for ; Mon, 29 Aug 2011 12:20:16 +0000 (UTC) Received: by vxh11 with SMTP id 11so5386747vxh.13 for ; Mon, 29 Aug 2011 05:20:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=4OzYjNfUBFf9hS6uQXyGF+kIeixwSV+fw5Q2jNJqrGs=; b=Vq0k/tyqLhpA4oJeCtjYp/t9K/DX9l9kOIewWxnFGgnKf2SNOwIH2HMpvjKOKb0VDQ ZF4zdezQUKFsSdfBaR4Bi4Zx6u4pIOFqbGrU97NlRy935OlgrC/PRefU1tzYM5rDXLU/ 3BIAFLUFh/9SQEr+PWMTijmKLW0Yy3jn5SDGw= MIME-Version: 1.0 Received: by 10.220.107.131 with SMTP id b3mr1704218vcp.206.1314618664361; Mon, 29 Aug 2011 04:51:04 -0700 (PDT) Sender: kmacybsd@gmail.com Received: by 10.52.186.163 with HTTP; Mon, 29 Aug 2011 04:51:04 -0700 (PDT) In-Reply-To: References: <35765857-1314243257-cardhu_decombobulator_blackberry.rim.net-329610575-@b2.c15.bise7.blackberry> <4e5ba9c3.bzHIw1KEy8R2QcK7%perryh@pluto.rain.com> Date: Mon, 29 Aug 2011 13:51:04 +0200 X-Google-Sender-Auth: dN1QRBdZR06oxKlpwLc4doNVOdY Message-ID: From: "K. Macy" To: vadim_nuclight@mail.ru Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-arch@freebsd.org Subject: Re: Own VCS (Was: Official git export) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 12:20:16 -0000 On Mon, Aug 29, 2011 at 11:53 AM, Vadim Goncharov wrote: > Hi Adrian Chadd! > > On Mon, 29 Aug 2011 17:03:56 +0800; Adrian Chadd wrote about 'Re: Official git export': > >>>> May be FreeBSD should really write it's own VCS, just as Git was >>>> modelled after proprietary BitKeeper?.. >>> >>> Good luck getting agreement on what to model it on :) >> git but with some better tools for managing a tree as big as ours? :) >> (eg keep total branch database/metadata, but support sparse checkouts, >> some better git<->svn integration?) > > No. Completely own BSD-licensed DVCS designed specifically for FreeBSD, > allowing partial checkouts and intended to replace SVN in the future :) > > If you briefly know the git ot hg architecture, then you may notice that > "commit" references "tree", each subdir points to another "tree", so > that "tree" is like a directory on a FAT file system: file name directly > references file data. So only entire repository could be fetched. > > If it will be designed like a Unix file systems, then an "inode" object > could be separate from "directory", and with a little help partial > checkouts are now possible (subset of inodes). Git also doesn't handle > renames natively, and with inodes it should be a trivial change in the > "directory" file, easily mergeable. > It sounds very cool in the abstract. It also sounds like an unproductive distraction from work that would more readily advance the interests of the FreeBSD community as a whole. What objective are we trying to achieve here? I thought we were discussing how to make FreeBSD developers more productive. If that is indeed the focus, extending the tool that is the closest match, which is probably git, would ultimately be a better way to allocate limited developer time and energy. Cheers From owner-freebsd-arch@FreeBSD.ORG Mon Aug 29 12:34:15 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 347C31065672 for ; Mon, 29 Aug 2011 12:34:15 +0000 (UTC) (envelope-from philip@freebsd.org) Received: from rincewind.paeps.cx (rincewind.paeps.cx [IPv6:2002:596a:f092::149]) by mx1.freebsd.org (Postfix) with ESMTP id CF80A8FC13 for ; Mon, 29 Aug 2011 12:34:14 +0000 (UTC) Received: from luggage.be.softathome.com (94-225-67-130.access.telenet.be [94.225.67.130]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) (Authenticated sender: philip) by rincewind.paeps.cx (Postfix) with ESMTPSA id 0C52FD744E4; Mon, 29 Aug 2011 14:34:11 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Philip Paeps In-Reply-To: <4e5ba9c3.bzHIw1KEy8R2QcK7%perryh@pluto.rain.com> Date: Mon, 29 Aug 2011 14:34:13 +0200 Content-Transfer-Encoding: 7bit Message-Id: <3420B331-C697-468A-80BA-B31C33804710@freebsd.org> References: <35765857-1314243257-cardhu_decombobulator_blackberry.rim.net-329610575-@b2.c15.bise7.blackberry> <4e5ba9c3.bzHIw1KEy8R2QcK7%perryh@pluto.rain.com> To: perryh@pluto.rain.com X-Mailer: Apple Mail (2.1244.3) Cc: vadim_nuclight@mail.ru, freebsd-arch@freebsd.org Subject: Re: Official git export X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 12:34:15 -0000 On 29 Aug 2011, at 17:01, perryh@pluto.rain.com wrote: > Vadim Goncharov wrote: >> May be FreeBSD should really write it's own VCS, just as Git was >> modelled after proprietary BitKeeper?.. > > Good luck getting agreement on what to model it on :) > > Personally I would suggest ClearCase as a model, but that's largely > because I'm familiar with it. Wait... you're familiar with ClearCase and you want something that's modelled like it? Most people familiar with ClearCase consider it to be a dire warning of what a VCS can become, not an example. :) I think any system where the server has to keep track of every client's files is pretty much obsolete in 2011. It scales unbelievably poorly. - Philip -- Philip Paeps Senior Reality Engineer Ministry of Information From owner-freebsd-arch@FreeBSD.ORG Mon Aug 29 12:39:49 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5567B1065670 for ; Mon, 29 Aug 2011 12:39:49 +0000 (UTC) (envelope-from philip@freebsd.org) Received: from rincewind.paeps.cx (rincewind.paeps.cx [IPv6:2002:596a:f092::149]) by mx1.freebsd.org (Postfix) with ESMTP id 9A8478FC16 for ; Mon, 29 Aug 2011 12:39:48 +0000 (UTC) Received: from luggage.be.softathome.com (94-225-67-130.access.telenet.be [94.225.67.130]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) (Authenticated sender: philip) by rincewind.paeps.cx (Postfix) with ESMTPSA id A4434D744E4; Mon, 29 Aug 2011 14:39:45 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Philip Paeps In-Reply-To: Date: Mon, 29 Aug 2011 14:39:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3CE7269E-DDD8-4A28-9FCD-D8FEA3C89089@freebsd.org> References: <35765857-1314243257-cardhu_decombobulator_blackberry.rim.net-329610575-@b2.c15.bise7.blackberry> To: vadim_nuclight@mail.ru X-Mailer: Apple Mail (2.1244.3) Cc: freebsd-arch@freebsd.org Subject: Re: Official git export X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 12:39:49 -0000 On 28 Aug 2011, at 23:18, Vadim Goncharov wrote: > On Fri, 26 Aug 2011 10:06:32 +0100 (BST); Robert Watson wrote about = 'Official git export (was: Re: FreeBSD problems and preliminary ways to = solve)': >> I have to admit I've always preferred Perforce to git, simply because = it=20 >> strikes me as a more structured approach, partial checkouts (but = especially=20 >> composition of different depot pieces in a single checkout to create = hybrid=20 >> trees), etc. But git is widely used, and quite effectively used, by = large=20 >> communities. We need to support those communities better. >=20 > I haven't worked with Perforce, do you mean I could checkout at once = several > directories e.g. sbin/ipfw and sys/netinet/ipfw in my working copy? If = so, > sounds good. Yes. Perforce is 'namespace-based'. You map parts of the repository = namespace into your client namespace and work from there. Branches are free for = most practical purposes and it's reasonably easy to merge between branches. The main downside of Perforce is that the server likes to track every = client's files and that things get very shaky when you try to interfere with that principle. One of my customers uses Perforce without tracking (or tries = to) and it goes horribly wrong in a number of ways (gigantic "p4 have" = databases, which don't reflect reality, accidental "p4 sync -k" locking up the = server for everyone for hours,...). > May be FreeBSD should really write it's own VCS, just as Git was > modelled after proprietary BitKeeper?.. I think git is a very reasonable system and it should be possible to map = the way we work with FreeBSD into git. As has been mentioned elsethread: = things would be a lot easier if we had "official git seeds" to pull from which would make it easy to collaborate and then push things up into SVN. = Also, a page of "rules for things not to do with git" would be helpful. It = would be a bad idea if committers using git pushed changes into Subversion which = made subversion impossible to use (or much harder to use than it currently = is). - Philip --=20 Philip Paeps Senior Reality Engineer Ministry of Information From owner-freebsd-arch@FreeBSD.ORG Mon Aug 29 13:01:19 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37C5B106566B; Mon, 29 Aug 2011 13:01:19 +0000 (UTC) (envelope-from nwhitehorn@banshee.munuc.org) Received: from banshee.munuc.org (cl-106.chi-02.us.sixxs.net [IPv6:2001:4978:f:69::2]) by mx1.freebsd.org (Postfix) with ESMTP id AF3138FC13; Mon, 29 Aug 2011 13:01:18 +0000 (UTC) Received: from nwhitehorn (helo=localhost) by banshee.munuc.org with local-esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Qy1Sn-0001YL-HZ; Mon, 29 Aug 2011 08:01:17 -0500 Date: Mon, 29 Aug 2011 08:01:17 -0500 (CDT) From: Nathan Whitehorn X-X-Sender: nwhitehorn@banshee.munuc.org To: Adrian Chadd In-Reply-To: Message-ID: References: <4E5B1194.2020600@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: Nathan Whitehorn X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: nwhitehorn@banshee.munuc.org X-SA-Exim-Scanned: No (on banshee.munuc.org); SAEximRunCond expanded to false Cc: arch@freebsd.org, "K. Macy" Subject: Re: Prefixing system calls to eliminate namespace collisions between kernel and libc X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 13:01:19 -0000 On Mon, 29 Aug 2011, Adrian Chadd wrote: > On 29 August 2011 12:12, Julian Elischer wrote: > >> I see no reason to not make this change.. actually I'd be happy making in 9. > > (pushes the +1 button somewhere) > > It'd be nice if other source modules of the kernel could be run in > userspace too, like GEOM modules. > (I'm not saying this should be part of Kip's goals; I just thought > about it whilst Nathan was talking about why partition stuff is > written out early during bsdinstall - because he needs the feedback > from GEOM.) Just to clarify: that's not what the problem is with the installer, which does does not write things out early except in one corner case. GEOM supports (quite nicely) making uncommitted changes, which makes all state centrally tracked and makes partitioning work much better than any pure-userland utility I've seen. There are some ways around this corner case I'm currently investigating. -Nathan From owner-freebsd-arch@FreeBSD.ORG Mon Aug 29 13:19:35 2011 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 417ED106564A for ; Mon, 29 Aug 2011 13:19:35 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 86E9C8FC14 for ; Mon, 29 Aug 2011 13:19:33 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA06804; Mon, 29 Aug 2011 16:19:28 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4E5B91E0.6090305@FreeBSD.org> Date: Mon, 29 Aug 2011 16:19:28 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110705 Thunderbird/5.0 MIME-Version: 1.0 To: Hans Petter Selasky References: <4E53986B.5000804@FreeBSD.org> <201108251308.56737.hselasky@c2i.net> <4E562E3A.7030304@FreeBSD.org> <201108251352.31504.hselasky@c2i.net> In-Reply-To: <201108251352.31504.hselasky@c2i.net> X-Enigmail-Version: 1.2pre Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-arch@FreeBSD.org Subject: Re: skipping locks, mutex_owned, usb X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 13:19:35 -0000 on 25/08/2011 14:52 Hans Petter Selasky said the following: >> http://people.freebsd.org/~avg/stop_scheduler_on_panic.diff >> http://people.freebsd.org/~avg/stop_scheduler_on_panic.8.x.diff > > The following patch complements Andriy's patch with regard to USB. Please test > and report back! > > http://hselasky.homeunix.org:8192/usb_scheduler_stopped.patch Here is my take on the issue: http://people.freebsd.org/~avg/ukbd-polling.diff Admittedly it has a few hairy places, but overall it should reduce the number of lines and quirks in the ukbd code. The patch can be logically separated into three parts: - locking Giant around kbdd_poll and scgetc calls in sc_cngetc - SCHEDULER_STOPPED-vs-mutex_owned changes in usb_transfer.c - removing explicit Giant checks and manipulations in ukbd.c I would like to ask for a review of these changes in whole or in parts. Thank you! Further, I think that ideally we should follow bde's suggestion of extending syscons interface to allow explicitly going into and out of the polling mode instead of implicitly doing that for every character. Also, perhaps kernel doesn't always have to use the polling mode - for example I think that the mountroot prompt should do fine in the regular mode. -- Andriy Gapon From owner-freebsd-arch@FreeBSD.ORG Mon Aug 29 14:02:15 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF1CE106566C; Mon, 29 Aug 2011 14:02:15 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe05.c2i.net [212.247.154.130]) by mx1.freebsd.org (Postfix) with ESMTP id 154228FC17; Mon, 29 Aug 2011 14:02:14 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=npWEf5XEtLL8qLh8yAfHNcIa2ktE1/5Qf1/k+5E0ZhU= c=1 sm=1 a=SvYTsOw2Z4kA:10 a=ni9ZY7ZFbhgA:10 a=WQU8e4WWZSUA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=6I5d2MoRAAAA:8 a=N3vH5299AAAA:8 a=NgtFCEsrzr7jmxhDPogA:9 a=_25ACjrlY3KuqGwTwWsA:7 a=wPNLvfGTeEIA:10 a=Zv46p6KrLxFnKoET:21 a=HVLLaQIwngGYuGGz:21 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe05.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 170228985; Mon, 29 Aug 2011 16:02:12 +0200 From: Hans Petter Selasky To: freebsd-arch@freebsd.org Date: Mon, 29 Aug 2011 15:59:39 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: <4E53986B.5000804@FreeBSD.org> <201108251352.31504.hselasky@c2i.net> <4E5B91E0.6090305@FreeBSD.org> In-Reply-To: <4E5B91E0.6090305@FreeBSD.org> X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq, NwSZ4V"|LR.+tj}g5 %V,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( :AuzV9:.hESm-x4h240C`9=w MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201108291559.39440.hselasky@c2i.net> Cc: Andriy Gapon Subject: Re: skipping locks, mutex_owned, usb X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 14:02:15 -0000 On Monday 29 August 2011 15:19:28 Andriy Gapon wrote: > on 25/08/2011 14:52 Hans Petter Selasky said the following: > >> http://people.freebsd.org/~avg/stop_scheduler_on_panic.diff > >> http://people.freebsd.org/~avg/stop_scheduler_on_panic.8.x.diff > > > > The following patch complements Andriy's patch with regard to USB. Please > > test and report back! > > > > http://hselasky.homeunix.org:8192/usb_scheduler_stopped.patch > > Here is my take on the issue: > http://people.freebsd.org/~avg/ukbd-polling.diff > Admittedly it has a few hairy places, but overall it should reduce the > number of lines and quirks in the ukbd code. > The patch can be logically separated into three parts: > - locking Giant around kbdd_poll and scgetc calls in sc_cngetc > - SCHEDULER_STOPPED-vs-mutex_owned changes in usb_transfer.c > - removing explicit Giant checks and manipulations in ukbd.c > Hi, > I would like to ask for a review of these changes in whole or in parts. > Thank you! I am bit worried by all the mtx_lock(&Giant) removal, though if it passes the following tests, it should be OK. The non-ukbd USB part looks fine! Compile a kernel with WITNESS and INVARIANTS options. Test cases: T1) NON-X11 login console: Press SCROLL LOCK. Press PAGE UP to scroll history. Type something or plug another USB device. Does SCROLL lock clear seamlessly when other text is printed on the console? T2) Switching between X11 and text console using ALT+CTRL+FX. Make sure no mutex related errors appear even when pressing keys/SCROLLOCK/NUMLOCK during the switchover. T3) Typing text at mount-root prompt should work without any keys lost. T4) Typing text in KDB should work. T5) Typing text after dump should work when scheduler is stopped. T6) Toggle Num-lock both in X11 and non-X11. > > Further, I think that ideally we should follow bde's suggestion of > extending syscons interface to allow explicitly going into and out of the > polling mode instead of implicitly doing that for every character. > Also, perhaps kernel doesn't always have to use the polling mode - for > example I think that the mountroot prompt should do fine in the regular > mode. Right. --HPS From owner-freebsd-arch@FreeBSD.ORG Mon Aug 29 14:22:22 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E66F106564A for ; Mon, 29 Aug 2011 14:22:22 +0000 (UTC) (envelope-from pcthegreat@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id CFEE88FC18 for ; Mon, 29 Aug 2011 14:22:21 +0000 (UTC) Received: by qyk9 with SMTP id 9so4149479qyk.13 for ; Mon, 29 Aug 2011 07:22:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qAP91K3CL3VSHnJr9WCTW0100T0qNfqjJWDX/gFDmkQ=; b=P73BYSTdY7iZdrN1ZGS6mJ5mKS/9AoQ+Ts60iZ4CFOnv5FzhTUv6dr8ZQ+WJLZE65f Pi4PHyVglyRCQlQdmv1AdG7IOjLtFePwrdS57r+VaKir3S9ch9aqN4aAeBNwiuvPr6Oh 7jZcmdXz6EOZUbKXXkoCEUmKa6GIaxTri2uJo= MIME-Version: 1.0 Received: by 10.142.179.20 with SMTP id b20mr2394453wff.422.1314627740357; Mon, 29 Aug 2011 07:22:20 -0700 (PDT) Received: by 10.68.63.5 with HTTP; Mon, 29 Aug 2011 07:22:19 -0700 (PDT) In-Reply-To: References: Date: Mon, 29 Aug 2011 10:22:19 -0400 Message-ID: From: selven To: vadim_nuclight@mail.ru Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-arch@freebsd.org Subject: Re: FreeBSD problems and preliminary ways to solve X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 14:22:22 -0000 Hi Vadim! > > The real problem here is that they're saying "trouble finding people". > They are *right* here - there is too small number of FreeBSD'ers. That's > our real problem - we should increase our userbase. Our userbase is the > problem, not their's userbase. Until there's more of us, we can't fight > successfully with them, even if our weapon is stronger. > > -- Increasing userbase, that starts with either cool eye candy effects that just eats processing for nothing and gaming which would mean focusing on the desktop and or / console or maybe attach something else which would sound 'cool' to newbies so much that they start to check it out and THEN realize the true difference. I wonder if we start having like a show case of "what can you do with your FreeBSD box" would help or not. Developers are harvested from the population usually, so creating such a buzz might be beneficial for the future. -- *Pirabarlen Cheenaramen *| $3|v3n* * L'escalier, Mauritius /*memory is like prison*/ (user==selven)?free(user):user=malloc(sizeof(brain)); P Save electricity & disk space. Cat this mail to >/dev/null 2>&1 after use. From owner-freebsd-arch@FreeBSD.ORG Mon Aug 29 14:44:16 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D443D106564A for ; Mon, 29 Aug 2011 14:44:16 +0000 (UTC) (envelope-from pcthegreat@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8DF798FC16 for ; Mon, 29 Aug 2011 14:44:16 +0000 (UTC) Received: by qwc9 with SMTP id 9so4132191qwc.13 for ; Mon, 29 Aug 2011 07:44:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=D84RUMCmI/2G5JsFVezH9BLwGlK9TJUXk1V9tNA9tg0=; b=P9I+MJw+LfrpvSFqjpHSdmeV/58jSWicInqCqRbzvUHlG7nlsfVt/wAPmeOQWVlky/ 1GMuiJuvPkioCT/e5qRI4UQF4hJ0I/XabJwyszy38Q6Ni2fkXV5TBcptSSPtVloTS8vY SRjSH2usaqU1FrcV1Gwq5UZZQ6ZKPpG51het4= MIME-Version: 1.0 Received: by 10.142.179.20 with SMTP id b20mr2405253wff.422.1314629055359; Mon, 29 Aug 2011 07:44:15 -0700 (PDT) Received: by 10.68.63.5 with HTTP; Mon, 29 Aug 2011 07:44:15 -0700 (PDT) In-Reply-To: References: <705869186.20110819012421@serebryakov.spb.ru> <04EEADEE-380F-48A0-BBBF-1A1673228F90@cyberlifelabs.com> Date: Mon, 29 Aug 2011 10:44:15 -0400 Message-ID: From: selven To: Brandon Gooch Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Milo Hyson , freebsd-arch@freebsd.org Subject: Re: FreeBSD problems and preliminary ways to solve X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 14:44:16 -0000 Hi Brandon! > > FreeBSD is well documented for an open source project. In particular, > the Handbook serves as an excellent guide and reference for FreeBSD > from an end-user's perspective. But is the documentation for > developers as well-structured? > that's another interesting question I have been asking myself for some years now. I've always tried finding a good book about FreeBSD's internal online (something updated), I never really bumped into any updated ones [4.x something maybe?], most books out there were mainly for sysadmins and for the developers' guide .. nada. (atleast for me, am not a really good developper who could just keep tons in the head, if i need something to change i'll just find /usr/local/src|xargs grep 'whatineed' and from there figure what to change and do it pretty much with trial and error). I believe a really good source and api documentation project would help a lot :p (user level/admin docs are already perfect for FreeBSD). but with the amount of people we can have for that a complete source documentation can definitely do a lot of good and no harm. Someone just needs to break every section up and assign a piece /section to be documented. A bit like this book : http://blog.rlove.org/2010/07/linux-kernel-development-third-edition.html [reading that just made me confident enough to know which is which and what does what internally in linux and even a layman like me was able to know what to modify where]. We lack such good development guides for FreeBSD. > Perhaps the FreeBSD current developer community (see: decades of > experience and knowledge) should focus on the creation (or revision) > of solid, comprehensive documentation for developing software in the > FreeBSD environment. I believe such a project would require only that long time developpers to break the tasks as in set what architecturally stands where, and assigns the 'read the code and figure it out what each piece does' to other people, e.g people who can understand codes but doesn't have much of a clue of the internal api and way of doing things. ( I'll take myself for example while i do code, i can read code, but unless something is assigned, i don't really know what to do and ends up doing other things. /*some people are lazy, unless given something to do*/) > > Imagine a horde of new college graduates, with FreeBSD under their > belts (instead of some Linux distribution), ready to deploy it as soon > as they have the chance in their new roles as system administrators > and engineers -- sounds great to me. > > More bodies, more eyes, more minds -- this brings along with it more > energy. We should focus on making FreeBSD the most developer-friendly > OS out there. > > Nice post Brandon. Explained the problem i had since some years and i wanted to mention that also. -- *Pirabarlen Cheenaramen *| $3|v3n* * L'escalier mobile: +230 49 24 918 email: pcthegeat@gmail.com || god@hackers.mu contact: http://godifiy.me /*memory is like prison*/ (user==selven)?free(user):user=malloc(sizeof(brain)); P Save electricity & disk space. Cat this mail to >/dev/null 2>&1 after use. From owner-freebsd-arch@FreeBSD.ORG Mon Aug 29 15:28:01 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B613106564A for ; Mon, 29 Aug 2011 15:28:01 +0000 (UTC) (envelope-from tomelite82@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0C4B38FC0A for ; Mon, 29 Aug 2011 15:28:00 +0000 (UTC) Received: by ywo32 with SMTP id 32so5781375ywo.13 for ; Mon, 29 Aug 2011 08:28:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Ef2VYwNjHhAhqw4s+LG5h75AVWkb2iPRO7245k3dP7k=; b=HoskvpOUnfxHu/gC8Re1oLIMLWvkHx065o6HgJXV4LYsWet6v5wy1UKwi16xnoAsxU bsSFS+pt2j2+1QiMtNPT9VkoMbgyOYyPTAIqFQ6xjPGvkp7di6P5uK+Bxr2NC+dtIiYJ 4MeI3ldLyYVKEnlvjO4GlAiQ3gwZJZk6FFRtw= MIME-Version: 1.0 Received: by 10.236.190.193 with SMTP id e41mr25168369yhn.118.1314630184758; Mon, 29 Aug 2011 08:03:04 -0700 (PDT) Sender: tomelite82@gmail.com Received: by 10.147.89.17 with HTTP; Mon, 29 Aug 2011 08:03:04 -0700 (PDT) In-Reply-To: References: Date: Mon, 29 Aug 2011 08:03:04 -0700 X-Google-Sender-Auth: FdzWnMTkqzhQAjiHyjTB6qSHoAk Message-ID: From: Qing Li To: vadim_nuclight@mail.ru, qingli@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arch@freebsd.org Subject: Re: FreeBSD problems and preliminary ways to solve X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 15:28:01 -0000 The lack of public support from the commercial world is not necessarily an indication the FreeBSD project is not successful, but obviously the lack of advocating FreeBSD from the vendors publicly is something needing solutions for. Besides fairly good architectures and cleaner code, the BSD license is one main reason why vendors select FBSD. This is a double edged sword because many compani= es will make huge customizations and never contribute a single piece of code b= ack. Also, not all vendors take in FBSD as a whole. A lot of companies incorporate the networking kernel, the file system, or other components into a custom OS. I think this is another difficulty for these vendors to openly advocate FBSD because they are not u= sing all of FBSD. I don't have any real solutions, just offering my observations from the vendor side (of my past and present employers). Perhaps we could collectively solicit vendors for projects that they would benefit from and thus willing to fund. Once the work is done, put the vendor name on the sponsor list. --Qing On Wed, Aug 17, 2011 at 4:10 PM, Vadim Goncharov w= rote: > Hi, > > I have bad news. > > A month ago techlead of Rambler's Mail department declared in his blog > that they begin migration from FreeBSD to Debian/Ubuntu. Comments to the > blog entry (there was much flame) revealed that search department of > Russian search engine #1 Yandex.com also plans to migrate their > search cluster - about 30,000 servers in several DCs (~60% of total > their servers - to Linux. The problem here is that both big companies > were using FreeBSD from the beginning (~1997), so migration will be > rather expensive. > > The official reasons (really semi-official, as these are individual > blogs), in short, were: > =A0* inadequate package manager and huge monolithic base system > =A0* lack of OpenVZ-like virtualization (need CPU limiting) > =A0* a FreeBSD marketshare forecast for 5 years > > Despite of several our committers working for them, the operating > expenses for FreeBSD are considered too high by these companies. They've > not confirmed, but the key problem is probably shortage of FreeBSD > specialists on the market to hire (e.g. Yandex has about 20 FreeBSD > admins and about 84 Linux admins, for all other their services and > 40% of servers). So this is problem of FreeBSD's too low > userbase/marketshare, caused, in turn, by other FreeBSD's problems. > > Given that they is just planning today, but not yet started, we have to > solve our problems or FreeBSD will effectively die[1]. Currently > https://ssl.netcraft.com/ssl-sample-report//CMatch/oscnt_all shows that > still 3% of servers are running FreeBSD. We are currently probably at > the tip of 'hype curve'[2] and then our userbase will begin to shrink, > and the task is to solve problems, so after hard time it will rise again > (hopefully more than it was before). > > =A0 [1] 'Die' means shrinking userbase size to those of NetBSD/OpenBSD. > =A0 [2] http://www.metodolog.ru/01493/2.gif > > Earlier this year in this list marcel@ have said about objective view: > http://lists.freebsd.org/pipermail/freebsd-arch/2011-January/010999.html > from the outside, not FreeBSD people. I have posted a call to Russian > community in my blog (http://nuclight.livejournal.com/128712.html) and > gathered a list of problems along with possible solutions to some of > them. The rest of this message is summary of them. > > In general, people sympathizing FreeBSD agree that there are no fatal > technical problems and that FreeBSD could compete with mainstream Linux. > That said, the 80/20 principle is in effect and 80% losed users for > FreeBSD are caused by 20% problems. The trouble here is that what > "outside" people view as considerable problems, we here inside FreeBSD > view as something insignificant ("do it yourself"). Thus 80% could be > achieved by 20% of work. I have sorted them in order of decreased > importance (priority): > > =A01. Social problems of community (and marketing, docs, ...) > =A02. Lack of drivers and virtualization. > =A03. Ports and packages. > =A04. Base system, closely related with packages. > =A05. Too short major releases' cycle. > =A06. Bug tracker, unicode and other less important trivia. > =A0(bonus) FreeBSD strengths to be concentrated on. > > Now all of them more detailed. > >> 1. Social (psychologic) problems of community (marketing, docs, ...). > > This is the most important one, because all technical problems are just > won't get solved because are even not viewed as problems. The FreeBSD > Project does not listen to users' needs. The typical response when poor > user want something is: "we don't need this, we won't change for you", > with "where are your patches?" at best. Then many users go out when see > such attitude toward them. > > The key points are: > > =A01) *The competent user is not zealot*. > =A02) The system is *for users, not for developers*. > > With first: when user sees the system costs too much time for him, and > that those problems won't get fixed and even considered such - he will > switch to another OS. This may mean that he is able to follow our advice > hoe to do some or another thing (e.g. to recompile all ports), but this > is unacceptable to him because this is too much maintenance (another > system by objectivity requires less work). Many businesses fall into > this category. They will not with FreeBSD by any price just because they > love OS. Unlike ourselves. > > With second: that's simple and not simple. It is simple in that by > nature each person don't make a work just for himself but for all > others, who are now "users" to him, too - just by induction that's not > for developers only. It is not simple due to question "Why do we need > those who don't contribute anything back to us?" which random committer > has right to ask. The answer, in short, is: there tasks which could be > only done by large groups of people, e.g. big corporations. For > corporations to invest and contribute back - the system must be popular > enough. To be popular enough means there must be a big amount of users > who is not contributing anything. It is useful in itself, though, that > some of those users, say 1%, will become contributors, that is, absolute > number of our developers will also benefit from FreeBSD being much more > popular. > > There are opinions in our community like: > > =A0| > Personally I'd like to think that that we write an OS for users. > =A0| > =A0| We write an OS for the people who can and will use an OS written by > =A0| us. > > =A0| FreeBSD is whatever its developers make it be > > These are wrong and harmful nowadays. The world has changed. We have to > admit it or we will die. We have to admit mistakes and *change* some of > the ways we're doing things: any answer like "I don't agree, we don't > need these users/features/etc., we *won't* do this for someone" - is > just another step to grave. > > Of course that doesn't mean to do everything - we often have not enough > time/resources to do. But that's another question and should not be > mixed with attitude - "it's good but we have no resources, will you do?" > vs "we don't need this, go away" (that's not only about features but > about keeping something too). > > So ("system is for users") we need to (re)define who our user is. I view > the current situation as following: > > =A0 =A0 =A0 100% .---------------. =A0 =A0 =A0 The stratification of over= all > =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0Ubuntu =A0 =A0 | =A0 =A0 =A0 our userbase= . Areas are: > =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0target =A0 =A0 | 6 > =A0 =A0 =A0 =A0 =A0 =A0| =A0 audience =A0 =A0| =A0 =A0 =A0 1 - official d= evelopers > =A0expand -> |---------------| > =A0to here =A0 =A0| not our, but =A0| =A0 =A0 =A0 2 - actively participat= ing and > =A0 =A0 =A0 =A0 =A0 =A0| =A0 competent =A0 | 5 =A0 =A0 =A0 =A0 sending pa= tches, contributors > =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 users =A0 =A0 | =A0 =A0 =A0 =A0 =A0 and = other "zealots" (whose > =A0 =A0 =A0 =A0 =A0 =A0|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D| = =A0 =A0 =A0 =A0 =A0 "soul is with FreeBSD") > =A0 =A0 =A0 =A0 =A0 =A0|announce@ only | 4 > =A0 involved |---------------| =A0 =A0 =A0 3 - not so active but discussi= ng > =A0 =A0 =A0 =A0 =A0 =A0| subscribed to | =A0 =A0 =A0 =A0 =A0 in mail list= s, patches go > =A0 =A0 =A0 =A0 =A0 =A0| =A0our mailing =A0| 3 =A0 =A0 =A0 =A0 sometimes > =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0lists =A0 =A0 =A0| > =A0committed |- - - - - - - -| =A0 =A0 =A0 4 - busy with work to read lis= ts > =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 | 2 > =A0 =A0 =A0 =A0 =A0 =A0|_______________| =A0 =A0 =A0 5 - can use, but cos= ts are now high > =A0 =A0 =A0 =A0 =A0 =A0| *@freebsd.org | 1 > =A0 =A0 =A0 =A0 0% `---------------' =A0 =A0 =A0 6 - we'll never want the= m > > The terms "involved" and "committed" were taken from > http://en.wikipedia.org/wiki/The_Chicken_and_the_Pig for those who are > "at the heart" of the community, at "periphery" and all others. > Currently, only those in (1) and partially (2) are listened to, > sometimes with "call for ..." in (3). Meanwhile, the most important of > our users, who are using FreeBSD in production, who are busy with real > work in real world, are in (4) and sometimes (5). Those are largely > ignored by the Project - even messages to announce@ last years are less > about important events and calls for volunteers/money. > > The other social problem is lack of companies which offer commercial > support of FreeBSD like RedHat does. > > As a possible solution to find out what user needs are, and to > compensate the fact that not all users in (4) and (5) care enough about > our principles and spirit, I propose a system for "weighted democracy". > This is a voting system (I could implement it), say, there is a mail > voting@freebsd.org to which users send filled in vote forms, with > selected answers from a survey published in announce@. > > The system has a database where users are recorded given their FreeBSD > activity in mail lists etc., and votes are summed as follows: > > =A0+ 1.00 vote for anyone not in database (not involved to FreeBSD) > =A0+ a decimal logarithm of number of posts to mail lists (2 votes for 10= 0 > =A0 posts, 3 votes for 1000 posts) > =A0+ a binary logarithm of num PRs in GNATS db (6 votes for 64 send-pr's) > =A0+ a proportion (say, N/2) of entries for this person in "svn log" (e.g= . > =A0 in "Submitted by:") > =A0+ an assigned (by core@) number of votes in special exceptional DB (fo= r > =A0 corporation and the like) > > The system then presents results for each answer: 1) how many users > voted, 2) how many votes summed. > > This is by no mean to measure "exact contribution", but to defend from > anonymous users and trolls who not care about amount of work developers > will need to. The results are viewed as a feedback to core team, not as > a final decision - that's all for what marketing is solely exist. There > no adequate feedback from users to developers currently at all - > individual posts in mail lists are too small for statistics (what about > ministat(1) for users, huh?..). > > What is also in this part? Documentation. No, not in that sense. The > observations show that while there are described solutions to problems > in system, it's difficult for users to find it. It's somehow organized > or misorganized that solution is not intuitive for them (e.g. someone > migrating from Windows complained that it was difficult to find 'simply > how to format a flash drive' in Handbook). I don't know how to handle > this properly. May be catalogues with Best Practices howto's pointing to > exact sections of Handbook, FAQ, articles etc.? May be better search > mechanisms?.. > > And the last here about too much conservatism and rigidness in our camp. > As one of the opponents said (roughly translated): > > =A0| FreeBSD, historically, was good system, let's say, "valid system > =A0| for solid people". Pureness, strictness, etc. The base system is > =A0| consequence of this approach. The trouble is, that in 2011 nobody > =A0| needs pureness and strictness. Customers need transparency and fast > =A0| reaction to their requests. If there is no transparency and speed, > =A0| you get CentOS 6 (just released, at last). Or FreeBSD (Gentoo, > =A0| Solaris, you name it). > > I don't agree that those certainly contradicts each other, but we > definitely need to change, er, something. And don't keep something just > because it is tradition, if that tradition has no more technical reasons > for our users. Let's shift conservatism to another field where it is > really needed (e.g. legacy support and other examples below). > > Finally, two more quotes from the arch@freebsd.org archives of last > 2 years: > > =A0| From: Cyrille Lefevre > =A0| [...] however, you answer remember me why I quit FreeBSD, cease > =A0| fire, courtesy is the key > > and > > =A0| From: Julian H. Stacey > =A0| Though I & many others have sent lots of send-pr, contributing even > =A0| a spelling correction to FreeBSD is much harder than to e.g. > =A0| http://wikipedia.org > > The threshold of entering to FreeBSD is too high and should be lowered. > I can confirm the last quote on my own example, 2 months ago. I've > submitted a patch to ipfw, adding call/return rule actions. It allows > to organize rules in somewhat like pf anchors, and, more importantly, > iptables chains, enabling FreeBSD ipfw to compete with Linux at least > partially in this sphere. The patch wasn't taken in maillists, I had > to push it in IRC, and push hard: the whole needed by many big users > thing was deferred (and still not MFCed to 8.x) just because some > #define's and printf's were Not So Proper & Right Way! F*cking shame. > >> 2. Lack of drivers and poor guest virtualization. > > It is known that FreeBSD supports less hardware than competitors. It is, > however, a matter of popularity - the more system will have users, the > more drivers will be created by 3rd parties, so we cannot directly > affect this. It's kind of exclusive circle. > > But there is one area - virtualization - without supporting it the > FreeBSD niche will collapse very fast. It is necessary to say that it is > about guest (para-)virtualization only, not host mode. Host mode market > is already lost for FreeBSD for quite some time, may be something in the > future, but today it will waste of resources. What is needed here is > just analogue to OpenVZ (and jails/rctl already done more than half of > the work here). > > And in guest mode FreeBSD *urgently needs* working drivers/utilities for > all common suits, Citrix XenServer, VMWare vSphere (ESXi), Xen*, > Microsoft Hyper-V, etc. This must be the primary direction for > developers' forces and FreeBSD Foundation's money. We have may be about > 1 year here. Why? =A0Because of cloud computing and VPS/VDS. It's no > matter what OS runs hoster if clients will use FreeBSD and we still have > users. I've been already asked by a customer for which I wrote > a non-portable kqueue-based daemon to rewrite for Linux because they > want to go for Amazon EC2 (it's cheaper as only used resources are > accounted) and FreeBSD there has still many in ISSUES scaring them... > >> 3. Ports and packages. > > What was the main problems with large-scale installations of FreeBSD in > that businesses? In short, that binary packages are not equal in rights > to ports, and that complicates things (i.e. requires too much work) when > one have many (> 10) servers. This was listed to me as: > > 1) No pkg and pkg-devel versions. The -devel version is headers, static > =A0 libs, programmer examples, etc. not needed in production (we could > =A0 say this part is what is actually depended on in B-deps). > > 2) Package name is dependent on options, so packages with another opts > =A0 don't work well when dependencies are rebuilt. > > 3) Conflicts: no way to have apache13 and apache22 the same time. > > 4) No dependence on base system. You may cut out something, recompile > =A0 world, deploy it on cluster and just then see that some packages are > =A0 now don't work. > > 5) Dependencies are badly designed. No version ranges in dependencies, > =A0 no alternative packages, no priorities in package search. > > 6) Update problems. The version is just coded into name of package, and > =A0 dependencies are on the entire name, so there are situations when > =A0 install/upgrade of just one package may require rebuild 3/4 of all > =A0 pkgs. You cannot easiy modify installed package without editing pkgdb > =A0 manually. It is impossible to upgrade/replace package by out of the > =A0 box tools. > > 7) Base system has no "out of the box" tools for package upgrade. Our > =A0 business opponents say this the least problem as one can always > =A0 install portupgrade, but conclude that overall base system concept > =A0 does not play well with full-featured packages (see also next part > =A0 about base system). > > 8) There is no -STABLE supported branches in ports. > > All of this could be avoided (they know about tinderbox etc.) but just > requires too much work, for their basic tasks like automated upgrade of > entire system & packages or reinstall of needed packages. > > That's problems. Next, possible (gathered) solutions. > > It is obvious that current packages are not first-class citizens, in > comparison with ports. They want ba able to run most machines without > a compiling at all (BTW, our desktop users need the same), but setting > build farms when there are many machine roles is hard. > > So packages need to be "equal in rights" in ports. The ports can have > things like this: > > =A0.if ${OSVERSION} < 700104 || ${OSVERSION} >=3D 900000 > > or this: > > =A0LIB_DEPENDS+=3D profiler.1:${PORTSDIR}/devel/google-perftools > > but packages are not so flexible, all you have is: > > =A0@pkgdep perl-5.8.9_2 > > skv@ proposed the following changes: > > =A0* OPTIONS need radio-buttons (e.g. only one of MySQL, PostgreSQL, > =A0 SQLite) and dialog(1) supports it. > > =A0* Options must be included and installed to /var/db/ports/*/options > =A0 (this will allow to rebuild installed binary pkg as port) > > =A0* Info about options must be included to /var/db/pkg/*/+CONTENTS like: > > =A0 =A0 @option WITH_SSL > =A0 =A0 @option WITHOUT_DEBUG > > =A0* Dependencies must be able to specify needed OPTIONS, both required t= o > =A0 set and required to be unset, somewaht like: > > =A0 =A0 RUN_DEPENDS+=3D foobar:${PORTSDIR}/devel/foobar:+SSL:-SQLITE > > =A0 This will allow to detect conflicts with installed packages with > =A0 incompatible options. > > =A0* For the package file names, introduce presets, e.g.: > > =A0 =A0 OPTIONS_PRESETS=3D default "+SSL:-DEBUG" \ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0lite "-SSL:-DEBUG" > > =A0 And preset name could be put to pkg name (may be "" for default). > > =A0* (internal) move away from CVS, rebalance to category-subcategory. > > These ideas in later discussion evolved to another additions. Let say we > are able to use multiple repositories, where "repository" is a variant > of /usr/ports tree and packages built from it. Then, each port allows to > build several packages from it, with different options. Now, if we have > a port called "softina" and user does > > =A0pkg_add -r softina > > then dependency search must be made given needed options. So @pkgdep > consists just of "softina" and versions like ">=3D1.1" and options. Also, > if packages are equal in rights to ports, they need integrity/security > check. So, package file name is now like: > > =A0softina-1.2.3_1:repo.id:1312929890.tbz =A0 =A0# chars allowed by windo= ws > > Here is a repository id, just a hostname like "freebsd.org" for official > ports, and an unique build id in that repo, though it were suggested > that option preset name instead of that name will be better (because > human-readable). And `pkg_add -r' fetches a single file > > =A0softina.pkgmeta > > consisting of sections for each actual package file. Each section has > a copy of what already is in .tbz file: name, comment, options, > dependencies (and their versions and options). And one thing not present > in .tbz - it's digital signature. Fetching pkg_add looks up local key > for given repository id to check. Fetching .pkgmeta beforehand also > allows to calculate if all needed dependencies are present in repo to > not fail in the middle of 100 packages as current pkg_add may do. The > signature is in another file and optional, so user could install the > plain .tbz file manually (it still contains all needed information, > .pkgmeta is only a copy except a signature). > > The one other thing which is also optional to @pkgdep is again > repository id. This is to allow following situation: > > =A0* company has 10 it's own internal projects > =A0* it also has 20 modified ports from original tree > =A0* internal pkgs depend on modified ports, not original > =A0* it's local port tree/pkg repo may hand only those, not full tree > > Then internal pkgs may be depended on modified ports to be not > intermixed by mistake with original versions from official tree. > Repository IDs are used for that, this is optional mechanism, though. > End machines have two repositories in their config files, local and > offical, and all works correct, and local repo doesn't need to be a full > clone of ports tree. > > The problem of -devel ports could be solved by using a global knob like > WITH_DEVEL (analogue of WITHOUT_X11), and options affect parts of > pkg-plist. The solved problem: glib has perl in R-deps, just for one > script, but this script is needed only for _build_ of dependent ports. > Now, if you install irssi, you will always have glib and perl, but you > don't need perl to run irssi. And irssi could have it's build dependence > of glib:+DEVEL and run of just plain glib. > > Of course we don't want to split ports to perl, perl-base, perl-modules, > perl-doc, etc. like in Debian, and options could be solution here - one > port, several packages. Build farm may now build not one, but 2-3 common > option presets. > > Here we go to another related problem, though - ports infrastructure. > I've read 16 chapters of http://www.netbsd.org/docs/pkgsrc/ and found > several interesting moments (let's concentrate on most close sibling of > our ports, though e.g. slots in Gentoo and Arch Linux system are also > worth looking too). They already have many of what we need, and since > pkg_install/ports by Jordan Hubbard is common ancestor, it may be easier > to port from them to us needed features. > > For example, there is problem generating plist for our porters. And what > they have, a program to create port from distfile: > > =A0| Run the program url2pkg, which will ask you for a URL. Enter > =A0| the URL of the distribution file (in most cases a .tar.gz file) and > =A0| watch how the basic ingredients of your package are created > =A0| automatically. > > Just fix oddities later manually, but saves from all boilerplate work! > > Next, skv@ said about radio-buttons, and thay also have it, in two > favors: first with one from group always set, second allowin all clear: > =A0"Exactly one of the following gecko options is required" > =A0"At most one of the following database options may be selected" > > =A0| PKG_OPTIONS_REQUIRED_GROUPS is like PKG_OPTIONS_OPTIONAL_GROUPS, but > =A0| building the packages will fail if no option from the group is > =A0| selected. PKG_OPTIONS_NONEMPTY_SETS is a list of names of sets of > =A0| options. At least one option from each set must be selected. > > The OPTIONS, however, are handled in different way: > > =A0$ grep "PKG.*OPTION" mk.conf > =A0PKG_DEFAULT_OPTIONS=3D =A0 =A0-arts -dvdread -esound > =A0PKG_OPTIONS.kdebase=3D =A0 =A0debug -sasl > =A0PKG_OPTIONS.apache=3D =A0 =A0 suexec > > Dependencies also allow versions: > > =A0BUILD_DEPENDS+=3D lua>=3D5.0:../../lang/lua > =A0DEPENDS+=3D =A0 =A0 =A0 screen-[0-9]*:../../misc/screen > =A0DEPENDS+=3D =A0 =A0 =A0 screen>=3D4.0:../../misc/screen > > Checksum files for packages exist on their own, and only those may be > signed not the packages itself (an alternative to .pkgmeta approach > described above). > > Another useful thing to borrow is patches/* separately from files/* > > The most visible thing in pkgsrc superior to ports, is buildlink3 > framework: > > =A0| Buildlink is a framework in pkgsrc that controls what headers and > =A0| libraries are seen by a package's configure and build processes. > =A0| [...] Please note that the normal system header and library paths, > =A0| e.g. /usr/include, /usr/lib, etc., are always searched -- buildlink3 > =A0| is designed to insulate the package build from non-system-supplied > =A0| software. > =A0| [...] > =A0| Some packages in pkgsrc install headers and libraries that coincide > =A0| with headers and libraries present in the base system. Aside from > =A0| a buildlink3.mk file, these packages should also include a > =A0| builtin.mk file that includes the necessary checks to decide whether > =A0| using the built-in software or the pkgsrc software is appropriate. > =A0| [...] When building packages, it's possible to choose whether to set > =A0| a global preference for using either the built-in (native) version > =A0| or the pkgsrc version of software to satisfy a dependency. This is > =A0| controlled by setting PREFER_PKGSRC and PREFER_NATIVE. > =A0| PREFER_PKGSRC=3D =A0yes > =A0| PREFER_NATIVE=3D =A0getopt skey tcp_wrappers > > There are more automation: > > =A0| Up to now, the file PLIST, which contains a list of the files that > =A0| are installed by the package, is nearly empty. Run > =A0| bmake print-PLIST >PLIST > =A0| to generate a probably correct list. > > Yes, they rely on their derivative of BSD make, bmake, which it itself > worth merging deifferencies to our make (for example, there is a clean > and small alternative to autotools, mk-configure, using bmake and > written in style of .include ). There may be other examples > of userland tools worth porting from NetBSD to us instead of directly > upstream, e.g. awk... but that's another story, let's continue pkg. > > Their developments of pkg_* tools contain facilities to implement a good > package manager out-of-the-box, e.g. pkg_add there has flags: > > =A0| -A =A0 =A0 =A0Mark package as installed automatically, as dependency= of > =A0| =A0 =A0 =A0 =A0 another package. =A0You can use > =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0pkg_admin set automatic=3DYES > =A0| =A0 =A0 =A0 =A0 to mark packages this way after installation, and > =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0pkg_admin unset automatic > =A0| =A0 =A0 =A0 =A0 to remove the mark. =A0If you pkg_add a package with= out > =A0| =A0 =A0 =A0 =A0 specifying =A0-A after it had already been automatic= ally > =A0| =A0 =A0 =A0 =A0 installed, the mark is removed. > =A0| -U =A0 =A0 =A0Replace an already installed version from a package. > =A0| =A0 =A0 =A0 =A0 Implies -u. > =A0| -u =A0 =A0 =A0If the package that's being installed is already insta= lled, > =A0| =A0 =A0 =A0 =A0 an update is performed. > > These are crucial to effective binary package management. > >> 4. Base system, closely related with packages. > > The next in turn was concept of monolithic base system. The troubles > with base system were: > > 1. To change the components of the base you may only recompile it with > =A0 corresponding src.conf(5) options, but there is no track in base > =A0 system which are actually installed now. You cannot binary upgrade > =A0 a custom world, even if it is just unmodified -STABLE instead of > =A0 -RELEASE. > > 2. Consequently, there is no way to check integrity (MD5 etc.) of any > =A0 non-RELEASE variant (freebsd-update IDS is very limited). > > 3. No ties between base system and packages: who knows what previous > =A0 admin has installed, you may have compiler or may not have, etc. > =A0 Packages may silently broke if some part of base system SUDDENLY > =A0 disappears, as no dependency information is recorded. > > 4. Base system is monolithic, so there is no easy way to replace one > =A0 component with another - ports replacing base parts are hemorrhoids. > > So, they conclude, the base system concept should be eliminated and be > split to bare kernel and gazillion of packages. > > But we all know what benefits base system gives to us: it is actually > a *system* where all components are in concordance to each other, not > just a bunch of packages. Also, if it will be all split, this will > require *much more* efforts from our committers to keep everything in > sync. And our resources (efforts) are limited. > > Actually, when you face two contradictory ways, all-or-nothing, both > with pros and cons - you should select neither of them, but try to find > something which will *synthesize* both of them. Such finding is an > interesting engineering (often inventor) task. And dougb@ already said > once that between base as-is and splitting all must be something middle. > It's Cathedral vs Bazaar, after all, and our Cathedral should be updated > and still use it's cathedral benefits. After all, NetBSD has proposal of > syspkg in 2004, and still has older format - just because it is not BSD > way, something new has to be invented. > > The most obvious solution is to split base not to ~500 packages, but to, > say, ~50, and change boundaries. Why should freebsd.org developers place > boundaries in packages between themselves? So most natural solution is > to split packages out of base by the vendor criteria. Luckily, this work > is *already done* to some extent. So this will be minimal efforts > overhead, if any. > > Looking at /usr/src/sontrib and http://wiki.freebsd.org/ContribSoftware > we can identify many of what could became a package. There can be > different approaches to criteria "what is in base system": > > 1. Only what is done on freebsd.org: all contrib must go to pkgs. > > 2. Whose effective vendor is now *@*bsd.org: contrib from other BSDs may > =A0 still live, and those with ceased upstream or renamed > =A0 (non-conflicting with ports) soft like libbsdxml, too. > > 3. Axe out only the most odious contrib parts: BIND (as Peter said in > =A0 archives, host/dig could be resurrected from Attic), sendmail (could > =A0 be replaced by dma) and several others, presumably GCC/binutils & CVS > =A0 (I've also heard about painful Kereberos interferencing with Samba). > > The latter is most probable :-) given known conservatism and parts > inter-dependencies (openssl is required by freebsd-update, and it's not > *@*bsd.org - already an exception). But it still needs clear definition > of what base system is destined for. > > =A0A philosophical observation. The more "fat" base system is, the more > =A0things are supposed about end user (the "WHEREs" in "SELECT"), so the > =A0more narrow target audience is. The more thin base system is, the more > =A0popular OS can be. You elitists may sleep well: FreeBSD will never be > =A0as popular of Linux whose "rod" is just kernel, not base sys. > > So each component of the base must be justified for the task, and for > task we may be should define to which user FreeBSD is targeted. Let it > be, say, task "the fresh setuped machine must be able to connect to > network to download and install binary packages". Then you don't need > GCC but you need editor to edit resolv.conf, less to view man pages, > tcpdump to debug network problems, send-pr to report a bug about > non-installed packages and thus a mail agent able to handle outgoing > report mail and daily periodic scripts to root while you have sex with > this (dma is suitable, sendmail is overkill). And so on. > > Axing out GCC to packages has another benefit: the newer GCC could be > used, and base could be polished to be more compiler-agnostic (hello, > clang). But this requires binary packages to have equal rights with > ports, of course. A base without a compiler is not a dramatic - you > already need some ports to do "make release", and doc team already began > to split docs to packages, that's a right direction. For POLA reasons > all axed out packages (and sendmail too, respect traditions) should be > just packaged on CD1. > > There may be another approach, not package one, but it is still in a fog > (and don't solve ports overriding base well). It's like the kernel and > modules: monolithic base system is just as monolithic kernel before > invention of modules - you the same way don't know what's in. Let's > dream a little - imagine we have our own DVCS, combining benefits of > centralized and distributed one, and not requiring splitting to multiple > repos like git, but allowing to use any given subset of files (not dirs > and subtrees as svn, *any* "inode"-based subset) from central repo > (this one "more equal" from all equal distributed repos). Such system > could be placed instead freebsd-update, binary updates of STABLE etc. > go to special branch, and user updates only those files which he have > on his system, VCS automatically tracks it. > >> 5. Too short major releases' cycle. > > I've once read a thread: > > =A0From: mdf@FreeBSD.org > =A0Subject: Schedule for releases > =A0Date: Tue, 21 Dec 2010 09:47:08 -0800 > > where e.g. julian@ have said: > > =A0| Generally a company wouldn't want to go through the pain of an OS > =A0| upgrade more than about once in three years and often it's longer.. > =A0| It IS a pain for them. > > And many business people reported the same. And it is known many people > are doing backports, testing etc., they should be motivated to give work > back to FreeBSD. While it is more social problem, it is also a > DVCS/bugtracker problem, but more rare major releases would still help > on it's own. > > It is known why the current scheme was adopted: the 4.11/5.3 case, > a horror. But between X.4 and X.11 there are even *several* intermediate > choices. What happens today: many conservative users (or builders of > products) consider -STABLE is really stable at the X.2 release. But just > after than an (X+1).0 is forked and all developers' attention goes to > new branch, X.3 and X.4 are not seriously developed. And due to > timelines described above, many users will then upgrade right away to > (X+2).Y, not (X+1). There are many 6.x and 7.x users in the wild, many > of 7.x users will upgrade directly to 9.x skipping 8.x. Is this good? > No. > > Aside of many branches receive not enought production testing, our > committers must do MFCs to TWO branches, stable/7 and stable/8. While > usualy having no real possibility to test properly. Nonsense. > > Is supporting two stable branches not using more efforts that it was in > 4.x times? Not so? Still could be made better. > > Proposed solution: prolonging major releases fork time a little. Just to > time so only one stable branch will exist. I hope increasing branch > lifetime to one minor release will help: last will be not .4, but .5, > and new .0 fork should occur at least after .3, not .2. We are not > Ubuntu. I understand that pace of changes is high, 3 years for each .0 > may be unacceptable, but waht about at least 2.5 years? Not like 1.8 > years currently. Rememeber, .5 and even .6 is still far from .11. > >> 6. Bug tracker, unicode and other less important trivia. > > GNATS is too old and unfriendly e.g. to user attachments. It has only > one adavantage: user is able to send report from CLI by mail without any > registration. This is essential. May be the good alternative will be RT > used at cpan.org (it also accepts by mail). Hopefully this will help > a little to solving problems. Not sure, though - and unsolved bugs are > also make users to go away from FreeBSD. > > Users also want properly working UTF-8 out-of-the-box. Not only console, > but full collation support, etc. > > There was suggestion about automatic kldloading of drivers, but this > work already began (for USB) in June - more matte of our documentation > and press relations, huh. > > Installer. Must be more featureful and more user friendly :-) This is > often may give negative first impression if installer was unable to do > something even if system after this could work well. > > Other problems, like broken cvsup, are exist, but are not critical to > Project's survival. > >> FreeBSD strengths to be concentrated on. > > The paragraph about virtualization above, as long as points below, are > roughly translated words of one small business representative in Russia, > who often acts as integrator. > > 1. BSD License. Very good for embedded vendors, we should be able to > =A0 compile and work both base and ports without licenses requiring to > =A0 open the sources. It would be good to not loose functionality without > =A0 them. > > 2. Kernel features for storage (ZFS, HAST, GEOM). We need to go to > =A0 NAS/SAN solutions niche while we have ability - it is still, because > =A0 Solaris etc. in unknown state with Oracle, BTRFS still beta. We have > =A0 about 1 year max. It would be nice to roll out "box" solution for a > =A0 failover iSCSI storage (2 PCs with ZFS raids replicated by HAST and > =A0 accessible by iSCSI with automatic role change). > > 3. Kernel features for complex network solutions (netgraph, carp, ipfw). > =A0 The niche for routers & traffic analysis is still ours. It would be > =A0 nice to take e.g. pfSense and agree with some vendor (Netgear, > =A0 D-Link, etc) to put on sale hardware with FreeBSD inside. > > So these are main ways - embedded (NAS & routers). Other market is still > not our, e.g. not an application server until there will be a killer-app > for SCTP. May be also for a DB: Solaris was first recommended for > PostgreSQL, with some efforts we may become the first. Of course, the > main way - if some commercial company will offer FreeBSD. > > We still have some time, but almost no time. We need to take decisions > right now. > > > That's all for today. Thanks to everyone who has patience to carefully > read this all entirely. > > -- > WBR, Vadim Goncharov. ICQ#166852181 =A0 =A0 =A0 mailto:vadim_nuclight@mai= l.ru > [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nucligh= t] > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@FreeBSD.ORG Mon Aug 29 15:51:41 2011 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6E34106566C for ; Mon, 29 Aug 2011 15:51:41 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 3E3C18FC12 for ; Mon, 29 Aug 2011 15:51:40 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA09564; Mon, 29 Aug 2011 18:51:36 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4E5BB588.70602@FreeBSD.org> Date: Mon, 29 Aug 2011 18:51:36 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110705 Thunderbird/5.0 MIME-Version: 1.0 To: Hans Petter Selasky References: <4E53986B.5000804@FreeBSD.org> <201108251352.31504.hselasky@c2i.net> <4E5B91E0.6090305@FreeBSD.org> <201108291559.39440.hselasky@c2i.net> In-Reply-To: <201108291559.39440.hselasky@c2i.net> X-Enigmail-Version: 1.2pre Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-arch@FreeBSD.org Subject: Re: skipping locks, mutex_owned, usb X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 15:51:42 -0000 on 29/08/2011 16:59 Hans Petter Selasky said the following: > T1) NON-X11 login console: > > Press SCROLL LOCK. Press PAGE UP to scroll history. Type something or plug > another USB device. Does SCROLL lock clear seamlessly when other text is > printed on the console? Unfortunately, either I don't understand the description of this test or scroll lock doesn't work this way even without any of my changes. Both in recent head and recent-ish stable/8, both with USB and PS/2 keyboards. If I type something while scroll lock is active, then nothing changes on my screen. As soon as I deactivate the scroll lock, the typed text appears on the screen. If I cause some kernel messages to be printed while scroll lock is active, then those messages appear over whatever I was viewing and the scroll lock is not deactivated. When I deactivate the scroll lock I see that (1) the new messages are nowhere to be found any more and (2) console output is appended with some of the overwritten text. Again, this happens both with and without my patch. If this behavior is incorrect/unexpected, then I am quite sure that it is not me who broke it. Could you please also double-check this behavior? -- Andriy Gapon From owner-freebsd-arch@FreeBSD.ORG Mon Aug 29 15:53:10 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8958A106566B; Mon, 29 Aug 2011 15:53:10 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe04.c2i.net [212.247.154.98]) by mx1.freebsd.org (Postfix) with ESMTP id C65EA8FC08; Mon, 29 Aug 2011 15:53:09 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=nSp/lo0FDChGKjONaW+LFp6gLzUQbrH1VOzHQZWpGes= c=1 sm=1 a=SvYTsOw2Z4kA:10 a=ni9ZY7ZFbhgA:10 a=WQU8e4WWZSUA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=yp9bcz87vElceb3v-T8A:9 a=wPNLvfGTeEIA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe04.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 171995467; Mon, 29 Aug 2011 17:53:07 +0200 From: Hans Petter Selasky To: freebsd-arch@freebsd.org Date: Mon, 29 Aug 2011 17:50:34 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: <4E53986B.5000804@FreeBSD.org> <201108291559.39440.hselasky@c2i.net> <4E5BB588.70602@FreeBSD.org> In-Reply-To: <4E5BB588.70602@FreeBSD.org> X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq, NwSZ4V"|LR.+tj}g5 %V,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( :AuzV9:.hESm-x4h240C`9=w MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201108291750.34501.hselasky@c2i.net> Cc: Andriy Gapon Subject: Re: skipping locks, mutex_owned, usb X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 15:53:10 -0000 On Monday 29 August 2011 17:51:36 Andriy Gapon wrote: > Could you please also double-check this behavior? Where is the latest patch and for 8-stable? --HPS From owner-freebsd-arch@FreeBSD.ORG Mon Aug 29 15:55:41 2011 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B48CE106566C for ; Mon, 29 Aug 2011 15:55:41 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id E2BE68FC0A for ; Mon, 29 Aug 2011 15:55:40 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA09618; Mon, 29 Aug 2011 18:55:36 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4E5BB678.3050504@FreeBSD.org> Date: Mon, 29 Aug 2011 18:55:36 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110705 Thunderbird/5.0 MIME-Version: 1.0 To: Hans Petter Selasky References: <4E53986B.5000804@FreeBSD.org> <201108291559.39440.hselasky@c2i.net> <4E5BB588.70602@FreeBSD.org> <201108291750.34501.hselasky@c2i.net> In-Reply-To: <201108291750.34501.hselasky@c2i.net> X-Enigmail-Version: 1.2pre Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-arch@FreeBSD.org Subject: Re: skipping locks, mutex_owned, usb X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 15:55:41 -0000 on 29/08/2011 18:50 Hans Petter Selasky said the following: > On Monday 29 August 2011 17:51:36 Andriy Gapon wrote: >> Could you please also double-check this behavior? > > Where is the latest patch and for 8-stable? Without any patch. -- Andriy Gapon From owner-freebsd-arch@FreeBSD.ORG Mon Aug 29 20:41:07 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89A2E106566B for ; Mon, 29 Aug 2011 20:41:07 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from thyme.infocus-llc.com (server.infocus-llc.com [206.156.254.44]) by mx1.freebsd.org (Postfix) with ESMTP id 5A60F8FC0C for ; Mon, 29 Aug 2011 20:41:06 +0000 (UTC) Received: from draco.over-yonder.net (c-174-50-4-38.hsd1.ms.comcast.net [174.50.4.38]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by thyme.infocus-llc.com (Postfix) with ESMTPSA id 1EC6D37B49A; Mon, 29 Aug 2011 15:41:06 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 8F60B61C52; Mon, 29 Aug 2011 15:41:05 -0500 (CDT) Date: Mon, 29 Aug 2011 15:41:05 -0500 From: "Matthew D. Fuller" To: Vadim Goncharov Message-ID: <20110829204105.GE2493@over-yonder.net> References: <35765857-1314243257-cardhu_decombobulator_blackberry.rim.net-329610575-@b2.c15.bise7.blackberry> <4e5ba9c3.bzHIw1KEy8R2QcK7%perryh@pluto.rain.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.21-fullermd.4 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97.2 at thyme.infocus-llc.com X-Virus-Status: Clean Cc: freebsd-arch@freebsd.org Subject: Re: Own VCS (Was: Official git export) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 20:41:07 -0000 On Mon, Aug 29, 2011 at 09:53:57AM +0000 I heard the voice of Vadim Goncharov, and lo! it spake thus: > > Git also doesn't handle renames natively, and with inodes it should > be a trivial change in the "directory" file, easily mergeable. We already have that, it's called "bzr" 8-} -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-arch@FreeBSD.ORG Mon Aug 29 21:06:34 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62F951065674; Mon, 29 Aug 2011 21:06:34 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id 3C51C8FC18; Mon, 29 Aug 2011 21:06:34 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id p7TL6WOY046968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 29 Aug 2011 14:06:33 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id p7TL6WkO046967; Mon, 29 Aug 2011 14:06:32 -0700 (PDT) Received: from fbsd81 ([192.168.200.81]) by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA16901; Mon, 29 Aug 11 13:39:15 PDT Date: Mon, 29 Aug 2011 20:39:11 -0700 From: perryh@pluto.rain.com To: philip@freebsd.org Message-Id: <4e5c5b5f.moT7dLemOuteQJ5T%perryh@pluto.rain.com> References: <35765857-1314243257-cardhu_decombobulator_blackberry.rim.net-329610575-@b2.c15.bise7.blackberry> <4e5ba9c3.bzHIw1KEy8R2QcK7%perryh@pluto.rain.com> <3420B331-C697-468A-80BA-B31C33804710@freebsd.org> In-Reply-To: <3420B331-C697-468A-80BA-B31C33804710@freebsd.org> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: vadim_nuclight@mail.ru, freebsd-arch@freebsd.org Subject: Re: Official git export X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 21:06:34 -0000 Philip Paeps wrote: > On 29 Aug 2011, at 17:01, perryh@pluto.rain.com wrote: > > Vadim Goncharov wrote: > >> May be FreeBSD should really write it's own VCS, just as Git was > >> modelled after proprietary BitKeeper?.. > > > > Good luck getting agreement on what to model it on :) > > > > Personally I would suggest ClearCase as a model, but that's > > largely because I'm familiar with it. > > Wait... you're familiar with ClearCase and you want something > that's modelled like it? Most people familiar with ClearCase > consider it to be a dire warning of what a VCS can become, not > an example. :) > > I think any system where the server has to keep track of every > client's files is pretty much obsolete in 2011. It scales > unbelievably poorly. The VOB server does keep track of every view's[1] checkouts, but I consider that a very low-level implementation detail -- there's no reason in principle why that record couldn't be kept in the view instead of in the VOB. (In a distributed system, which is what FreeBSD needs, checkout records _can't_ be maintained centrally.) What I'm advocating is the usage experience. Things like: * Anyone can create a branch, and no one else will be aware of it unless they go looking for it, but all branches are peers. * Checkout, editing, and checkin of directories follows the same workflow as files. * Elements (files, directories) can be moved from one directory to another without losing history. The move is initially visible only on the branch where it is performed, becoming visible on other branches via merging, just as with file edits. * Graphical visualization of any element's branch and version tree, including all merges. * Automatic identification of the common ancestor ("base contributor") version when performing a merge. * The best multi-way merge tool I have seen -- it has issues, but overall I rate it a B+. (I would rate most no higher than a C.) The same merge tool is used for directories as for files, with directory entries being represented textually. ---------- [1] Not every client's -- one view server typically supports multiple clients, and nothing keeps track of _them_. From owner-freebsd-arch@FreeBSD.ORG Tue Aug 30 01:00:46 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 438F4106564A for ; Tue, 30 Aug 2011 01:00:46 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 1ADD98FC0A for ; Tue, 30 Aug 2011 01:00:45 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p7U10fOa051014 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 29 Aug 2011 18:00:44 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4E5C364D.7070904@freebsd.org> Date: Mon, 29 Aug 2011 18:01:01 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.20) Gecko/20110804 Thunderbird/3.1.12 MIME-Version: 1.0 To: perryh@pluto.rain.com References: <35765857-1314243257-cardhu_decombobulator_blackberry.rim.net-329610575-@b2.c15.bise7.blackberry> <4e5ba9c3.bzHIw1KEy8R2QcK7%perryh@pluto.rain.com> <3420B331-C697-468A-80BA-B31C33804710@freebsd.org> <4e5c5b5f.moT7dLemOuteQJ5T%perryh@pluto.rain.com> In-Reply-To: <4e5c5b5f.moT7dLemOuteQJ5T%perryh@pluto.rain.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: vadim_nuclight@mail.ru, freebsd-arch@freebsd.org, philip@freebsd.org Subject: Re: Official git export X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 01:00:46 -0000 On 8/29/11 8:39 PM, perryh@pluto.rain.com wrote: > Philip Paeps wrote: >> On 29 Aug 2011, at 17:01, perryh@pluto.rain.com wrote: >>> Vadim Goncharov wrote: >>>> May be FreeBSD should really write it's own VCS, just as Git was >>>> modelled after proprietary BitKeeper?.. >>> Good luck getting agreement on what to model it on :) >>> >>> Personally I would suggest ClearCase as a model, but that's >>> largely because I'm familiar with it. >> Wait... you're familiar with ClearCase and you want something >> that's modelled like it? Most people familiar with ClearCase >> consider it to be a dire warning of what a VCS can become, not >> an example. :) >> >> I think any system where the server has to keep track of every >> client's files is pretty much obsolete in 2011. It scales >> unbelievably poorly. > The VOB server does keep track of every view's[1] checkouts, but > I consider that a very low-level implementation detail -- there's > no reason in principle why that record couldn't be kept in the view > instead of in the VOB. (In a distributed system, which is what > FreeBSD needs, checkout records _can't_ be maintained centrally.) Having worked with mercurial, I would argue very much teh opposite. With a distributed system one spends all sorts of time making sure that what YOU think is in release X is what the guy you are helping debug thinks is in it.. Gone is the ability to say "That came in with rev 23456 so if you are later than that you have it." p4 does a much better job of merging between branches etc because it has teh big picture. and you always know that if someone has change X that he also has change Y. Eventually one gets around these problems with distributed systems by using the distributed system to simulate a non distributed system. e.g. Only pull from the central source so that you know wht the heck you are working with. but if you are going to do that, then why not actually USE a central source that is built that way. There are some nice features with distributed systems but I think the best system to work with would be one that gives some ability to have local changes and yet KNOWS that it is some part of a hierarchy. It should KNOW what is "from God/linus" and what is from the local mortals. Despite what git and mercurial say, the two are NOT really equivalent. > What I'm advocating is the usage experience. Things like: > > * Anyone can create a branch, and no one else will be aware of it > unless they go looking for it, but all branches are peers. > > * Checkout, editing, and checkin of directories follows the same > workflow as files. > > * Elements (files, directories) can be moved from one directory to > another without losing history. The move is initially visible > only on the branch where it is performed, becoming visible on > other branches via merging, just as with file edits. > > * Graphical visualization of any element's branch and version tree, > including all merges. > > * Automatic identification of the common ancestor ("base contributor") > version when performing a merge. > > * The best multi-way merge tool I have seen -- it has issues, but > overall I rate it a B+. (I would rate most no higher than a C.) > The same merge tool is used for directories as for files, with > directory entries being represented textually. > > ---------- > > [1] Not every client's -- one view server typically supports > multiple clients, and nothing keeps track of _them_. > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@FreeBSD.ORG Tue Aug 30 01:03:35 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E827106564A for ; Tue, 30 Aug 2011 01:03:35 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from thyme.infocus-llc.com (server.infocus-llc.com [206.156.254.44]) by mx1.freebsd.org (Postfix) with ESMTP id CDAAB8FC14 for ; Tue, 30 Aug 2011 01:03:34 +0000 (UTC) Received: from draco.over-yonder.net (c-174-50-4-38.hsd1.ms.comcast.net [174.50.4.38]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by thyme.infocus-llc.com (Postfix) with ESMTPSA id A1BEF37B49C; Mon, 29 Aug 2011 20:03:33 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id F24E961C51; Mon, 29 Aug 2011 20:03:32 -0500 (CDT) Date: Mon, 29 Aug 2011 20:03:32 -0500 From: "Matthew D. Fuller" To: Julian Elischer Message-ID: <20110830010332.GK2493@over-yonder.net> References: <35765857-1314243257-cardhu_decombobulator_blackberry.rim.net-329610575-@b2.c15.bise7.blackberry> <4e5ba9c3.bzHIw1KEy8R2QcK7%perryh@pluto.rain.com> <3420B331-C697-468A-80BA-B31C33804710@freebsd.org> <4e5c5b5f.moT7dLemOuteQJ5T%perryh@pluto.rain.com> <4E5C364D.7070904@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E5C364D.7070904@freebsd.org> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.21-fullermd.4 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97.2 at thyme.infocus-llc.com X-Virus-Status: Clean Cc: vadim_nuclight@mail.ru, philip@freebsd.org, perryh@pluto.rain.com, freebsd-arch@freebsd.org Subject: Re: Official git export X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 01:03:35 -0000 On Mon, Aug 29, 2011 at 06:01:01PM -0700 I heard the voice of Julian Elischer, and lo! it spake thus: > > With a distributed system one spends all sorts of time making sure > that what YOU think is in release X is what the guy you are helping > debug thinks is in it.. > > Gone is the ability to say "That came in with rev 23456 so if you > are later than that you have it." Just because it's true of System X, which is in the class of "distributed systems", doesn't mean it's inherent in the class... -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-arch@FreeBSD.ORG Tue Aug 30 01:05:07 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA366106566B for ; Tue, 30 Aug 2011 01:05:06 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id B92418FC12 for ; Tue, 30 Aug 2011 01:05:06 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p7U154rc051022 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 29 Aug 2011 18:05:05 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4E5C3753.9020001@freebsd.org> Date: Mon, 29 Aug 2011 18:05:23 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.20) Gecko/20110804 Thunderbird/3.1.12 MIME-Version: 1.0 To: perryh@pluto.rain.com References: <35765857-1314243257-cardhu_decombobulator_blackberry.rim.net-329610575-@b2.c15.bise7.blackberry> <4e5ba9c3.bzHIw1KEy8R2QcK7%perryh@pluto.rain.com> <3420B331-C697-468A-80BA-B31C33804710@freebsd.org> <4e5c5b5f.moT7dLemOuteQJ5T%perryh@pluto.rain.com> In-Reply-To: <4e5c5b5f.moT7dLemOuteQJ5T%perryh@pluto.rain.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: vadim_nuclight@mail.ru, freebsd-arch@freebsd.org, philip@freebsd.org Subject: Re: Official git export X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 01:05:07 -0000 On 8/29/11 8:39 PM, perryh@pluto.rain.com wrote: > Philip Paeps wrote: >> On 29 Aug 2011, at 17:01, perryh@pluto.rain.com wrote: >>> Vadim Goncharov wrote: >>>> May be FreeBSD should really write it's own VCS, just as Git was >>>> modelled after proprietary BitKeeper?.. >>> Good luck getting agreement on what to model it on :) >>> >>> Personally I would suggest ClearCase as a model, but that's >>> largely because I'm familiar with it. >> Wait... you're familiar with ClearCase and you want something >> that's modelled like it? Most people familiar with ClearCase >> consider it to be a dire warning of what a VCS can become, not >> an example. :) >> >> I think any system where the server has to keep track of every >> client's files is pretty much obsolete in 2011. It scales >> unbelievably poorly. > The VOB server does keep track of every view's[1] checkouts, but > I consider that a very low-level implementation detail -- there's > no reason in principle why that record couldn't be kept in the view > instead of in the VOB. (In a distributed system, which is what > FreeBSD needs, checkout records _can't_ be maintained centrally.) > > What I'm advocating is the usage experience. Things like: > > * Anyone can create a branch, and no one else will be aware of it > unless they go looking for it, but all branches are peers. not all branches are peers. That's just the way things are in the real world. what follows could be a description of many VCS. > * Checkout, editing, and checkin of directories follows the same > workflow as files. > > * Elements (files, directories) can be moved from one directory to > another without losing history. The move is initially visible > only on the branch where it is performed, becoming visible on > other branches via merging, just as with file edits. > > * Graphical visualization of any element's branch and version tree, > including all merges. p4 can do this really well... a lot of DSCS can't. > * Automatic identification of the common ancestor ("base contributor") > version when performing a merge. > > * The best multi-way merge tool I have seen -- it has issues, but > overall I rate it a B+. (I would rate most no higher than a C.) > The same merge tool is used for directories as for files, with > directory entries being represented textually. ***** I once had to work with clearcase... I swore to never do so again. Never trust a system to hold your files when you can't find where the y really are. (as a user) *** > ---------- > > [1] Not every client's -- one view server typically supports > multiple clients, and nothing keeps track of _them_. > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@FreeBSD.ORG Tue Aug 30 01:57:29 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E847106564A for ; Tue, 30 Aug 2011 01:57:29 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id D5E588FC20 for ; Tue, 30 Aug 2011 01:57:28 +0000 (UTC) Received: by vxh11 with SMTP id 11so6150037vxh.13 for ; Mon, 29 Aug 2011 18:57:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=2xeCquLXx0gqVPxPAlgaCIRkcEb/pD15V5IrYazGYQE=; b=Yk5ZpHMTGs3PZTB2TdvhkFJM9zAkKv39SO/WAmnZYNWiMl0qozKiu4UGqsxv/ZW+uU /woyND9IzWrNsuqT1hTIGSYdzfg3VAw+/t5eHAVH9lsJZVhGDWr2al2C8S2dKtGSEkbw f45cENPKX48A6FJtB6kf1YUVcRC1Qyq4OGszA= MIME-Version: 1.0 Received: by 10.52.75.34 with SMTP id z2mr813751vdv.297.1314669448073; Mon, 29 Aug 2011 18:57:28 -0700 (PDT) Sender: kmacybsd@gmail.com Received: by 10.52.186.163 with HTTP; Mon, 29 Aug 2011 18:57:28 -0700 (PDT) In-Reply-To: <4E5C364D.7070904@freebsd.org> References: <35765857-1314243257-cardhu_decombobulator_blackberry.rim.net-329610575-@b2.c15.bise7.blackberry> <4e5ba9c3.bzHIw1KEy8R2QcK7%perryh@pluto.rain.com> <3420B331-C697-468A-80BA-B31C33804710@freebsd.org> <4e5c5b5f.moT7dLemOuteQJ5T%perryh@pluto.rain.com> <4E5C364D.7070904@freebsd.org> Date: Tue, 30 Aug 2011 03:57:28 +0200 X-Google-Sender-Auth: ofb8PuX85WIroPB10mrNyVF0G14 Message-ID: From: "K. Macy" To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-arch@freebsd.org Subject: Re: Official git export X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 01:57:29 -0000 > With a distributed system one spends all sorts of time making sure that what > YOU think > is in release X is what the guy you are helping debug thinks is in it.. > > Gone is the ability to say "That came in with rev 23456 so if you are later > than that you have it." > > p4 does a much better job of merging between branches etc because it has teh > big picture. > and you always know that if someone has change X that he also has change Y. > > Eventually one gets around these problems with distributed systems > by using the distributed system to simulate a non distributed system. > In order to maximize the value of this discussion it would be helpful to identify what we're collectively seeking to accomplish. The value that I see in git is as a replacement for what FreeBSD developers use / used perforce for: Independent project development outside of the main tree. While svn makes this much easier than CVS ever did, git makes it easier still. Questions of what is canonical or not are irrelevant when the objective is to increase parallelism and small scale coordination between developers. The two problems that I see are: 1) FreeBSD has a lot of history by git standards 2) the /usr/src tree is too inclusive when one's main concern is, say, working on part of the kernel that may break ABIs Being able to control how far back in time one's repo goes and being able to have some control over views would go a long way towards streamlining its use for FreeBSD. Cheers From owner-freebsd-arch@FreeBSD.ORG Tue Aug 30 02:24:40 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 426801065673 for ; Tue, 30 Aug 2011 02:24:40 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-6.mit.edu (DMZ-MAILSEC-SCANNER-6.MIT.EDU [18.7.68.35]) by mx1.freebsd.org (Postfix) with ESMTP id E0B648FC0A for ; Tue, 30 Aug 2011 02:24:39 +0000 (UTC) X-AuditID: 12074423-b7b31ae000000a3c-65-4e5c49e7e9f2 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id B4.E6.02620.7E94C5E4; Mon, 29 Aug 2011 22:24:39 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id p7U2Oc8E025243; Mon, 29 Aug 2011 22:24:38 -0400 Received: from multics.mit.edu (MULTICS.MIT.EDU [18.187.1.73]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p7U2Obtr013642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 29 Aug 2011 22:24:38 -0400 (EDT) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id p7U2Obcc024302; Mon, 29 Aug 2011 22:24:37 -0400 (EDT) Date: Mon, 29 Aug 2011 22:24:36 -0400 (EDT) From: Benjamin Kaduk To: "K. Macy" In-Reply-To: Message-ID: References: <35765857-1314243257-cardhu_decombobulator_blackberry.rim.net-329610575-@b2.c15.bise7.blackberry> <4e5ba9c3.bzHIw1KEy8R2QcK7%perryh@pluto.rain.com> <3420B331-C697-468A-80BA-B31C33804710@freebsd.org> <4e5c5b5f.moT7dLemOuteQJ5T%perryh@pluto.rain.com> <4E5C364D.7070904@freebsd.org> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrOIsWRmVeSWpSXmKPExsUixCmqrPvcM8bPYHefhcXs6dOYLB7v3cLm wOQx49N8lgDGKC6blNSczLLUIn27BK6MtZ+ECk5xV1yae5C1gXEGZxcjJ4eEgInE0dXHWCFs MYkL99azgdhCAvsYJTZ8Ue9i5AKyNzBKTOt7yQrhHGCSuDPxDDuE08AosW/NNkaQFhYBbYmO e6uZQGw2ARWJmW82go0SEVCUOPF3BVADBwezgIzEnNfeIGFhAQWJ/53bmUFsToFAiVUHDoG1 8go4SOx9uBlq/jJWiY/7PrODJEQFdCRW75/CAlEkKHFy5hMwm1nAUuLcn+tsExgFZyFJzUKS WsDItIpRNiW3Sjc3MTOnODVZtzg5MS8vtUjXTC83s0QvNaV0EyMoPNldlHcw/jmodIhRgINR iYf347loPyHWxLLiytxDjJIcTEqivF/cY/yE+JLyUyozEosz4otKc1KLDzFKcDArifDeUAPK 8aYkVlalFuXDpKQ5WJTEeWV2OvgJCaQnlqRmp6YWpBbBZGU4OJQkeBOAcSgkWJSanlqRlplT gpBm4uAEGc4DNDwSpIa3uCAxtzgzHSJ/ilFRSpxXHyQhAJLIKM2D64Wlj1eM4kCvCEO08wBT D1z3K6DBTECDLxlGgwwuSURISTUwtp64bG/CcuJTFP8O/Wtv+FO93l1hSEk9skN32v2KFeV7 rL45S37d6y48784/XuMdHBkPXyoKswlpX66pTGJNcX0u+VH/zJ3erTazr8csOtF/lF95fvjj 9Gcu+eYurzd+vdoYKej2yYBRlXdufM4Exo6KC3xHrgZ1TfCxK+WwPXW66NW8Az8/K7EUZyQa ajEXFScCAKElKAT6AgAA Cc: freebsd-arch@freebsd.org Subject: Re: Official git export X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 02:24:40 -0000 On Tue, 30 Aug 2011, K. Macy wrote: > > The value that I see in git is as a replacement for what FreeBSD > developers use / used perforce for: Independent project development > outside of the main tree. While svn makes this much easier than CVS > ever did, git makes it easier still. Questions of what is canonical or > not are irrelevant when the objective is to increase parallelism and > small scale coordination between developers. The two problems that I > see are: > 1) FreeBSD has a lot of history by git standards > 2) the /usr/src tree is too inclusive when one's main concern is, say, > working on part of the kernel that may break ABIs > > Being able to control how far back in time one's repo goes and being > able to have some control over views would go a long way towards > streamlining its use for FreeBSD. My understanding is that with git it's possible to "graft" one tree onto another, so that most people only have to check out recent history, and can check out a separate ancient history. This has at least been proposed in the context of the net-im/zephyr upstream, where development happened concurrently in multiple trees (in different VCSes) for a period of time maybe ten years ago. Current development is all consolidated in a single subversion tree, and the proposal was to convert that repository now to have something to work with, and worry about getting the ancient history right at a later time. -Ben Kaduk From owner-freebsd-arch@FreeBSD.ORG Tue Aug 30 02:37:35 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D646E106566B for ; Tue, 30 Aug 2011 02:37:35 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8A6DA8FC0A for ; Tue, 30 Aug 2011 02:37:35 +0000 (UTC) Received: by vxh11 with SMTP id 11so6173200vxh.13 for ; Mon, 29 Aug 2011 19:37:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=084C6/kH/GxITbyeqN2icmX6bIsuJujF2JT79vWSU6M=; b=JVRJ0BU17kogzBnSBx+vKfYsuhglicLSW9DfpM2OLNR/0+HvWQ6ftlQmajl8NHw4i5 +4f/iLEjixTszqDqoiLwnxRt7msY7wSgjb65U7R8SUll55Lgooytd5NhvTaTkTaQm0RR 4uHT34WrZ5EPtcAju/VLWeVb2KeWBp0hfJx7Q= MIME-Version: 1.0 Received: by 10.52.20.228 with SMTP id q4mr3553292vde.498.1314671854905; Mon, 29 Aug 2011 19:37:34 -0700 (PDT) Sender: kmacybsd@gmail.com Received: by 10.52.186.163 with HTTP; Mon, 29 Aug 2011 19:37:34 -0700 (PDT) In-Reply-To: References: <35765857-1314243257-cardhu_decombobulator_blackberry.rim.net-329610575-@b2.c15.bise7.blackberry> <4e5ba9c3.bzHIw1KEy8R2QcK7%perryh@pluto.rain.com> <3420B331-C697-468A-80BA-B31C33804710@freebsd.org> <4e5c5b5f.moT7dLemOuteQJ5T%perryh@pluto.rain.com> <4E5C364D.7070904@freebsd.org> Date: Tue, 30 Aug 2011 04:37:34 +0200 X-Google-Sender-Auth: 7uASb9pXsElnEXEKNxwVtG5jGjA Message-ID: From: "K. Macy" To: Benjamin Kaduk Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arch@freebsd.org Subject: Re: Official git export X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 02:37:35 -0000 > My understanding is that with git it's possible to "graft" one tree onto > another, so that most people only have to check out recent history, and c= an > check out a separate ancient history. =A0This has at least been proposed = in > the context of the net-im/zephyr upstream, where development happened > concurrently in multiple trees (in different VCSes) for a period of time > maybe ten years ago. =A0Current development is all consolidated in a sing= le > subversion tree, and the proposal was to convert that repository now to h= ave > something to work with, and worry about getting the ancient history right= at > a later time. > My knowledge of git is limited but I know that git clone has the --depth option for specifying a shallow clone that only goes back N changesets. Git also has "submodule" which provides some functionality for the notion of subprojects which can limit what is enclosed within a given repo to some extent. Cheers From owner-freebsd-arch@FreeBSD.ORG Tue Aug 30 02:41:55 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1AD7D106564A; Tue, 30 Aug 2011 02:41:55 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-5.mit.edu (DMZ-MAILSEC-SCANNER-5.MIT.EDU [18.7.68.34]) by mx1.freebsd.org (Postfix) with ESMTP id 655C38FC08; Tue, 30 Aug 2011 02:41:54 +0000 (UTC) X-AuditID: 12074422-b7ba7ae000000a14-3a-4e5c4debe585 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id BD.89.02580.BED4C5E4; Mon, 29 Aug 2011 22:41:47 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id p7U2frLa022832; Mon, 29 Aug 2011 22:41:53 -0400 Received: from multics.mit.edu (MULTICS.MIT.EDU [18.187.1.73]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p7U2fqjN015316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 29 Aug 2011 22:41:53 -0400 (EDT) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id p7U2fpBM024488; Mon, 29 Aug 2011 22:41:51 -0400 (EDT) Date: Mon, 29 Aug 2011 22:41:51 -0400 (EDT) From: Benjamin Kaduk To: "K. Macy" In-Reply-To: Message-ID: References: <35765857-1314243257-cardhu_decombobulator_blackberry.rim.net-329610575-@b2.c15.bise7.blackberry> <4e5ba9c3.bzHIw1KEy8R2QcK7%perryh@pluto.rain.com> <3420B331-C697-468A-80BA-B31C33804710@freebsd.org> <4e5c5b5f.moT7dLemOuteQJ5T%perryh@pluto.rain.com> <4E5C364D.7070904@freebsd.org> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-38367664-1314672111=:1411" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgleLIzCtJLcpLzFFi42IR4hTV1n3tG+NnMOmKicXs6dOYLB7v3cLm wOQx49N8lgDGKC6blNSczLLUIn27BK6M/ct3sxfc4qvoWb2HrYHxHXcXIyeHhICJxPrOd8wQ tpjEhXvr2boYuTiEBPYxSsy9PpURwtkA5Lx/xAThHGCSOLx2AzuE08Ao0f15PztIP4uAtsS0 LVPZQGw2ARWJmW82gtkiAooSJ/6uAKrh4GAWkJGY89obJCwsoCDxv3M72GpOgUCJRe1fwWxe AQeJYzPOs0LMX8QmceTUdbCEqICOxOr9U1ggigQlTs58AmYzC/hJdO34zDaBUXAWktQsJKlZ YKutJZ6dt4AIa0vcv9nGtoCRZRWjbEpulW5uYmZOcWqybnFyYl5eapGuqV5uZoleakrpJkZQ QLO7KO1g/HlQ6RCjAAejEg/vh3PRfkKsiWXFlbmHGCU5mJREeR/5xPgJ8SXlp1RmJBZnxBeV 5qQWH2KU4GBWEuG9oQaU401JrKxKLcqHSUlzsCiJ83LtdPATEkhPLEnNTk0tSC2CycpwcChJ 8CYAI1dIsCg1PbUiLTOnBCHNxMEJMpwHaHgESA1vcUFibnFmOkT+FKOilDhvGkhCACSRUZoH 1wtLOK8YxYFeEYZo5wEmK7juV0CDmYAGXzKMBhlckoiQkmpgTD+71zWnOVVKfFWN0cOKjxM2 v77/4H8U6yk/fUFbUbHT3sWs+bpT9fr+iSzNs5zZfXynsXdpxjSu3GKp7zt/hOuW+QXyuV0z i7SbzdK+yNLx0IxdD52P/Ji0pSwzRC1I/uAlGe47sh/kGRjDvHZd0Xt+Sb1/2buS258bhA0t e2OtG9ojF55UYinOSDTUYi4qTgQAK1hmsBMDAAA= Cc: freebsd-arch@freebsd.org Subject: Re: Official git export X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 02:41:55 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-38367664-1314672111=:1411 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Tue, 30 Aug 2011, K. Macy wrote: >> My understanding is that with git it's possible to "graft" one tree onto >> another, so that most people only have to check out recent history, and = can >> check out a separate ancient history. =A0This has at least been proposed= in >> the context of the net-im/zephyr upstream, where development happened >> concurrently in multiple trees (in different VCSes) for a period of time >> maybe ten years ago. =A0Current development is all consolidated in a sin= gle >> subversion tree, and the proposal was to convert that repository now to = have >> something to work with, and worry about getting the ancient history righ= t at >> a later time. >> > > My knowledge of git is limited but I know that git clone has the > --depth option for specifying a shallow clone that only goes back N I am pretty sure that this results in a repo that is not very useful for=20 committing to and pushing from (though I have not really used it, myself,= =20 so could be mistaken). > changesets. Git also has "submodule" which provides some functionality > for the notion of subprojects which can limit what is enclosed within > a given repo to some extent. True, but the word on the street around here is that it's kind of a hack,= =20 and it doesn't really feel like it would be appropriate for splitting up=20 things within base. (It would, however, make some amount of sense if we=20 were ever crazy enough to combine two or more of base, doc/www, and=20 ports.) -Ben ---559023410-38367664-1314672111=:1411-- From owner-freebsd-arch@FreeBSD.ORG Tue Aug 30 06:41:17 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 65B861065675 for ; Tue, 30 Aug 2011 06:41:17 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 12F888FC23 for ; Tue, 30 Aug 2011 06:41:16 +0000 (UTC) Received: by vxh11 with SMTP id 11so6294067vxh.13 for ; Mon, 29 Aug 2011 23:41:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Rul/yK7QskDiRR6IsvfJlC0YZ8sac4dxXWYbRmRWB3U=; b=M2VkVZK87JuwrF/9uVW5VBe3+dP6tdKVF8OQCmy4SIaYGxuUHtmsQwG4D/q4jkrPwX mu+aVTghWLjdc1HFShE3O3rHqvfzadpF8N9y1s0a/K6oQd2Qhp4Nc9S//mMgoPi+c3au 4JUxeBuiLSictWo2eHPX5XQzHqaD/Eibx9qEw= MIME-Version: 1.0 Received: by 10.52.90.37 with SMTP id bt5mr958980vdb.364.1314686476121; Mon, 29 Aug 2011 23:41:16 -0700 (PDT) Sender: kmacybsd@gmail.com Received: by 10.52.186.163 with HTTP; Mon, 29 Aug 2011 23:41:16 -0700 (PDT) In-Reply-To: References: <35765857-1314243257-cardhu_decombobulator_blackberry.rim.net-329610575-@b2.c15.bise7.blackberry> <4e5ba9c3.bzHIw1KEy8R2QcK7%perryh@pluto.rain.com> <3420B331-C697-468A-80BA-B31C33804710@freebsd.org> <4e5c5b5f.moT7dLemOuteQJ5T%perryh@pluto.rain.com> <4E5C364D.7070904@freebsd.org> Date: Tue, 30 Aug 2011 08:41:16 +0200 X-Google-Sender-Auth: hBNR4MuX9VJJNWOkL5tnLYOIDV8 Message-ID: From: "K. Macy" To: Benjamin Kaduk Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arch@freebsd.org Subject: Re: Official git export X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 06:41:17 -0000 On Tue, Aug 30, 2011 at 4:41 AM, Benjamin Kaduk wrote: > On Tue, 30 Aug 2011, K. Macy wrote: > >>> My understanding is that with git it's possible to "graft" one tree ont= o >>> another, so that most people only have to check out recent history, and >>> can >>> check out a separate ancient history. =A0This has at least been propose= d in >>> the context of the net-im/zephyr upstream, where development happened >>> concurrently in multiple trees (in different VCSes) for a period of tim= e >>> maybe ten years ago. =A0Current development is all consolidated in a si= ngle >>> subversion tree, and the proposal was to convert that repository now to >>> have >>> something to work with, and worry about getting the ancient history rig= ht >>> at >>> a later time. >>> >> >> My knowledge of git is limited but I know that git clone has the >> --depth option for specifying a shallow clone that only goes back N > > I am pretty sure that this results in a repo that is not very useful for > committing to and pushing from (though I have not really used it, myself,= so > could be mistaken). Why would that be the case? The gitorious repository only goes back to 7 but is very useful. The amount of history one needs to work is usually quite limited. >> changesets. Git also has "submodule" which provides some functionality >> for the notion of subprojects which can limit what is enclosed within >> a given repo to some extent. > > True, but the word on the street around here is that it's kind of a hack, > and it doesn't really feel like it would be appropriate for splitting up > things within base. =A0(It would, however, make some amount of sense if w= e > were ever crazy enough to combine two or more of base, doc/www, and ports= .) Looking at the documentation it is also clear that its applicability is limited as you imply above. Using gitlinks for managing mixed repository state is clearly, if not a hackish design. limited in usability and scope. Cheers From owner-freebsd-arch@FreeBSD.ORG Tue Aug 30 06:49:04 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5815E106566B; Tue, 30 Aug 2011 06:49:04 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id 162238FC19; Tue, 30 Aug 2011 06:49:04 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id p7U6n2wA007114 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 29 Aug 2011 23:49:03 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id p7U6n2x7007113; Mon, 29 Aug 2011 23:49:02 -0700 (PDT) Received: from fbsd81 ([192.168.200.81]) by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA18611; Mon, 29 Aug 11 23:45:52 PDT Date: Tue, 30 Aug 2011 06:45:48 -0700 From: perryh@pluto.rain.com To: julian@freebsd.org Message-Id: <4e5ce98c.oO00IDrFl0/DsNgV%perryh@pluto.rain.com> References: <35765857-1314243257-cardhu_decombobulator_blackberry.rim.net-329610575-@b2.c15.bise7.blackberry> <4e5ba9c3.bzHIw1KEy8R2QcK7%perryh@pluto.rain.com> <3420B331-C697-468A-80BA-B31C33804710@freebsd.org> <4e5c5b5f.moT7dLemOuteQJ5T%perryh@pluto.rain.com> <4E5C3753.9020001@freebsd.org> In-Reply-To: <4E5C3753.9020001@freebsd.org> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: vadim_nuclight@mail.ru, freebsd-arch@freebsd.org, philip@freebsd.org Subject: Re: Official git export X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 06:49:04 -0000 Julian Elischer wrote: > On 8/29/11 8:39 PM, perryh@pluto.rain.com wrote: > > * Anyone can create a branch, and no one else will be aware of > > it unless they go looking for it, but all branches are peers. > not all branches are peers. That's just the way things are in the > real world. Of course I'm referring to the _mechanism_ provided by the VCS, not the administrative _policy_ that a given user community may adopt. If you insist that the VCS itself must enforce a hierarchical policy, that pretty well rules out distributed systems like git or hg AFAIK (making this whole thread pointless). > Never trust a system to hold your files when you can't find where > they really are. (as a user) Actually you _can_ find them without admin privileges, but not all that easily :) I agree that the internal representation of a ClearCase view leaves quite a bit to be desired in terms of transparency. I count that as another implementation detail: we could do that part differently if we were to write a BSD-licensed VCS, even if we modelled its user- level behavior on ClearCase. From owner-freebsd-arch@FreeBSD.ORG Tue Aug 30 08:23:29 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 700DA1065676 for ; Tue, 30 Aug 2011 08:23:29 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (pancho.soaustin.net [76.74.250.40]) by mx1.freebsd.org (Postfix) with ESMTP id 50C4C8FC08 for ; Tue, 30 Aug 2011 08:23:29 +0000 (UTC) Received: by mail.soaustin.net (Postfix, from userid 502) id DDAB45615E; Tue, 30 Aug 2011 03:23:28 -0500 (CDT) Date: Tue, 30 Aug 2011 03:23:28 -0500 From: Mark Linimon To: Vadim Goncharov Message-ID: <20110830082328.GB8085@lonesome.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-arch@freebsd.org Subject: Re: FreeBSD problems and preliminary ways to solve X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 08:23:29 -0000 On Wed, Aug 24, 2011 at 10:20:40PM +0000, Vadim Goncharov wrote: > That's even more strange given that early years, pkg_* tools in NetBSD > (pkgsrc) and FreeBSD got active code exchange. Why has it stopped later?.. Although we do talk to each other e.g. at conferences, each of our projects is sufficiently occupied with current tasks. There are some things that they can do that we can't and vice versa. The codebase divergence is huge, and the target audience is different as well. (For instance, FreeBSD isn't worried about boostrapping on other OSes, as pkgsrc is. Attempting to deal with it is a huge task that would simply give us no benefit.) If you take a look at the codebases, you'll see how big the divergence is now. mcl From owner-freebsd-arch@FreeBSD.ORG Tue Aug 30 04:25:08 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0AE83106566C for ; Tue, 30 Aug 2011 04:25:08 +0000 (UTC) (envelope-from manefestoh@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 997B28FC0A for ; Tue, 30 Aug 2011 04:25:07 +0000 (UTC) Received: by wyh15 with SMTP id 15so5616560wyh.13 for ; Mon, 29 Aug 2011 21:25:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=mTr5E82TCjVFJslBpdp/Uj6IusQw7RsLOY8ymVY2sdM=; b=Ofq/icBDGkexmbqYmJifd5rlEiLGDzf3XsMngruHCpspOl+6QKEY8nPHyV0VF6q6mh isu6sy4P2DYUwmfEFluIYzyAxw4R9osfCcudni+TE3BwL5Eup2V9SKuPo1WQhGJipp7g 6+7lmSd7l4NkWIgfw9KyJN20BupEvYYDiota4= MIME-Version: 1.0 Received: by 10.216.137.22 with SMTP id x22mr4235834wei.88.1314676821668; Mon, 29 Aug 2011 21:00:21 -0700 (PDT) Received: by 10.216.45.141 with HTTP; Mon, 29 Aug 2011 21:00:21 -0700 (PDT) Date: Tue, 30 Aug 2011 10:00:21 +0600 Message-ID: From: =?KOI8-R?B?7cHL08nNIOfPzNXC?= To: freebsd-arch@freebsd.org X-Mailman-Approved-At: Tue, 30 Aug 2011 10:53:08 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: FreeBSD problems and preliminary ways to solve X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 04:25:08 -0000 Hello. I think another problem is the obsolete packages. Packages usually an older version than the ports. You must use a package as base way install software (as done in the Openbsd), but if you want specific compilation options then use the ports. -- Best regard, Golub Maksim From owner-freebsd-arch@FreeBSD.ORG Tue Aug 30 13:37:32 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE49D106564A for ; Tue, 30 Aug 2011 13:37:32 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 7EA538FC08 for ; Tue, 30 Aug 2011 13:37:32 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 0110746B2C; Tue, 30 Aug 2011 09:37:32 -0400 (EDT) Date: Tue, 30 Aug 2011 14:37:31 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Vadim Goncharov In-Reply-To: Message-ID: References: <35765857-1314243257-cardhu_decombobulator_blackberry.rim.net-329610575-@b2.c15.bise7.blackberry> <4e5ba9c3.bzHIw1KEy8R2QcK7%perryh@pluto.rain.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-arch@freebsd.org Subject: Unproductive conversations (was: Re: Own VCS (Was: Official git export)) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 13:37:32 -0000 On Mon, 29 Aug 2011, Vadim Goncharov wrote: > No. Completely own BSD-licensed DVCS designed specifically for FreeBSD, > allowing partial checkouts and intended to replace SVN in the future :) Vadim: I think your post has triggered a number of very productive discussions about improving FreeBSD and how to ensure FreeBSD remains relevant. Unfortunately, I think this is not one of them. The whole world is waiting for a perfect revision control system to turn up, but I think the FreeBSD Project isn't the place to write it. Historically, interestingly, it might have been -- cvsup was a tool developed in the context of the FreeBSD Project on the basis that we effectively needed something as scalable as a DVCS. It's actually one of the reasons it took us so long to switch away from CVS: we made CVS do things no dreamed possibly in terms of scalability. Having made a highly disruptive but ultimately successful switch to Subversion, and considered the pros and cons in the classic revision control and DCVS spaces in the process, I think we should continue to sit on Subversion for the time being. However, the thrust of my comments earlier in this thread about git are about something different: not switching revision control systems, or building the ultimate new one, but instead adapting to the current status quo -- in a world in which there is no perfect system (and in which different desirable features are even mutually exclusive), we need to allow people to use the tool that they find easiest and most comfortable. Which means supporting a large pool of downstream git users *better* than we do today. With so many areas to focus our attention, I honestly think we're better served looking at things like package system architecture, improvements to documentation, support for forthcoming hardware designs, etc, then trying to build yet another DVCS from scratch in the confines of the FreeBSD Project. Robert > > If you briefly know the git ot hg architecture, then you may notice that > "commit" references "tree", each subdir points to another "tree", so > that "tree" is like a directory on a FAT file system: file name directly > references file data. So only entire repository could be fetched. > > If it will be designed like a Unix file systems, then an "inode" object > could be separate from "directory", and with a little help partial > checkouts are now possible (subset of inodes). Git also doesn't handle > renames natively, and with inodes it should be a trivial change in the > "directory" file, easily mergeable. > > -- > WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru > [Anti-Greenpeace][Sober FreeBSD zealot][http://nuclight.livejournal.com] > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@FreeBSD.ORG Tue Aug 30 20:14:00 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC067106564A; Tue, 30 Aug 2011 20:13:59 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 7A5558FC0A; Tue, 30 Aug 2011 20:13:59 +0000 (UTC) Received: from localhost (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by acme.spoerlein.net (8.14.4/8.14.4) with ESMTP id p7UKDwGg087530 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 30 Aug 2011 22:13:58 +0200 (CEST) (envelope-from uqs@spoerlein.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=spoerlein.net; s=dkim200908; t=1314735238; bh=EMC4bBdpAkPG/hvOksFG1f4uhbImlm8Ota8VMPHeKz0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=Vsh7W6iR1eumYDkKpOV9gyoa311PrNSFoPPfXqYHOhJu1cNO0FSQKQc4/tu92pgkI NerK6v8liwzPN6OQDDHPIbO9W76px9P1NaA/KmmtsxLP1p0y25KZ0yhb0fx4JHtTTN ugtMXQlHJOOGlMxL476Hwk5AED+vN8UiHaRkIFcY= Date: Tue, 30 Aug 2011 22:13:57 +0200 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: "K. Macy" Message-ID: <20110830201357.GB58638@acme.spoerlein.net> Mail-Followup-To: "K. Macy" , Julian Elischer , freebsd-arch@freebsd.org References: <4e5ba9c3.bzHIw1KEy8R2QcK7%perryh@pluto.rain.com> <3420B331-C697-468A-80BA-B31C33804710@freebsd.org> <4e5c5b5f.moT7dLemOuteQJ5T%perryh@pluto.rain.com> <4E5C364D.7070904@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arch@freebsd.org Subject: Re: Official git export X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 20:14:00 -0000 On Tue, 2011-08-30 at 03:57:28 +0200, K. Macy wrote: > > With a distributed system one spends all sorts of time making sure that what > > YOU think > > is in release X is what the guy you are helping debug thinks is in it.. > > > > Gone is the ability to say "That came in with rev 23456 so if you are later > > than that you have it." > > > > p4 does a much better job of merging between branches etc because it has teh > > big picture. > > and you always know that if someone has change X that he also has change Y. > > > > Eventually one gets around these problems with distributed systems > > by using the distributed system to simulate a non distributed system. > > > > In order to maximize the value of this discussion it would be helpful > to identify what we're collectively seeking to accomplish. > > The value that I see in git is as a replacement for what FreeBSD > developers use / used perforce for: Independent project development > outside of the main tree. While svn makes this much easier than CVS > ever did, git makes it easier still. Questions of what is canonical or > not are irrelevant when the objective is to increase parallelism and > small scale coordination between developers. The two problems that I > see are: > 1) FreeBSD has a lot of history by git standards > 2) the /usr/src tree is too inclusive when one's main concern is, say, > working on part of the kernel that may break ABIs > > Being able to control how far back in time one's repo goes and being > able to have some control over views would go a long way towards > streamlining its use for FreeBSD. Utterly irrelevant. A partial checkout won't make git noticeably faster, as it is pretty darn fast already. Believe me. A truncated history might save you up to 150MB, also totally not worth the effort, especially because then your custom git repo has different hashes and fetching/merging other peoples branches becomes impossible. Furthermore, the point with git is to have multiple branches in your workspace and switch between them (again, this is frigging fast). I was juggling 8-10 branches at one time and have never had the need to create a second workspace ('git stash' being the keyword here). Please have a look at http://wiki.freebsd.org/GitWorkflow and try it out! Uli From owner-freebsd-arch@FreeBSD.ORG Tue Aug 30 20:20:56 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D432B1065670; Tue, 30 Aug 2011 20:20:56 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6B6B78FC17; Tue, 30 Aug 2011 20:20:56 +0000 (UTC) Received: by qwc9 with SMTP id 9so26303qwc.13 for ; Tue, 30 Aug 2011 13:20:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=BoL4MNGgOc9nj0thnu5NZpscaaiS5DQWYRIaORFd2Go=; b=X56PP0tiAGB8EwTrryki6Ec/9rBmFnsmLZPjp0LC4m+lHZMuYLmQSiZlWk3Y+21Cpi BAQ1RSIs7L5eWVqkpXKBo8BzI3XAhjUJOTsIot2IorwFHpWMflC0xDW4YY+vJKt9iCdB BlQyNrx0ltl+D1HHfLKnM2d22HF+UDQXszmD4= MIME-Version: 1.0 Received: by 10.52.21.129 with SMTP id v1mr1832140vde.163.1314735655713; Tue, 30 Aug 2011 13:20:55 -0700 (PDT) Sender: kmacybsd@gmail.com Received: by 10.52.187.231 with HTTP; Tue, 30 Aug 2011 13:20:55 -0700 (PDT) In-Reply-To: <20110830201357.GB58638@acme.spoerlein.net> References: <4e5ba9c3.bzHIw1KEy8R2QcK7%perryh@pluto.rain.com> <3420B331-C697-468A-80BA-B31C33804710@freebsd.org> <4e5c5b5f.moT7dLemOuteQJ5T%perryh@pluto.rain.com> <4E5C364D.7070904@freebsd.org> <20110830201357.GB58638@acme.spoerlein.net> Date: Tue, 30 Aug 2011 22:20:55 +0200 X-Google-Sender-Auth: 1UyaROPyyqTL5tGP5zk-1wzJp9Q Message-ID: From: "K. Macy" To: "K. Macy" , Julian Elischer , freebsd-arch@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Re: Official git export X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 20:20:56 -0000 w far back in time one's repo goes and being >> able to have some control over views would go a long way towards >> streamlining its use for FreeBSD. > > Utterly irrelevant. A partial checkout won't make git noticeably > faster, as it is pretty darn fast already. Believe me. A truncated > history might save you up to 150MB, also totally not worth the effort, > especially because then your custom git repo has different hashes and > fetching/merging other peoples branches becomes impossible. > > Furthermore, the point with git is to have multiple branches in your > workspace and switch between them (again, this is frigging fast). I was > juggling 8-10 branches at one time and have never had the need to create > a second workspace ('git stash' being the keyword here). > > Please have a look at http://wiki.freebsd.org/GitWorkflow and try it > out! I've been working out of git for the past 15 months: https://www.gitorious.org/~kmm/freebsd/kmm-sandbox I'm afraid that due to time and bandwidth constraints the size of the initial repository is indeed relevant for many of us. From owner-freebsd-arch@FreeBSD.ORG Tue Aug 30 21:42:14 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F6BB106566C for ; Tue, 30 Aug 2011 21:42:14 +0000 (UTC) (envelope-from freebsd-arch@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id BBC0F8FC12 for ; Tue, 30 Aug 2011 21:42:13 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QyW4R-0002q9-BC for freebsd-arch@freebsd.org; Tue, 30 Aug 2011 23:42:11 +0200 Received: from 208.88.188.90.adsl.tomsknet.ru ([90.188.88.208]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 30 Aug 2011 23:42:11 +0200 Received: from vadim_nuclight by 208.88.188.90.adsl.tomsknet.ru with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 30 Aug 2011 23:42:11 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-arch@freebsd.org From: Vadim Goncharov Date: Tue, 30 Aug 2011 21:41:58 +0000 (UTC) Organization: Nuclear Lightning @ Tomsk, TPU AVTF Hostel Lines: 45 Message-ID: References: <35765857-1314243257-cardhu_decombobulator_blackberry.rim.net-329610575-@b2.c15.bise7.blackberry> <4e5ba9c3.bzHIw1KEy8R2QcK7%perryh@pluto.rain.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 208.88.188.90.adsl.tomsknet.ru X-Comment-To: K. Macy User-Agent: slrn/0.9.9p1 (FreeBSD) Subject: Re: Own VCS X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vadim_nuclight@mail.ru List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 21:42:14 -0000 Hi K. Macy! On Mon, 29 Aug 2011 13:51:04 +0200; K. Macy wrote about 'Re: Own VCS (Was: Official git export)': >>>>> May be FreeBSD should really write it's own VCS, just as Git was >>>>> modelled after proprietary BitKeeper?.. >>>> >>>> Good luck getting agreement on what to model it on :) >>> git but with some better tools for managing a tree as big as ours? :) >>> (eg keep total branch database/metadata, but support sparse checkouts, >>> some better git<->svn integration?) >> >> No. Completely own BSD-licensed DVCS designed specifically for FreeBSD, >> allowing partial checkouts and intended to replace SVN in the future :) >> >> If you briefly know the git ot hg architecture, then you may notice that >> "commit" references "tree", each subdir points to another "tree", so >> that "tree" is like a directory on a FAT file system: file name directly >> references file data. So only entire repository could be fetched. >> >> If it will be designed like a Unix file systems, then an "inode" object >> could be separate from "directory", and with a little help partial >> checkouts are now possible (subset of inodes). Git also doesn't handle >> renames natively, and with inodes it should be a trivial change in the >> "directory" file, easily mergeable. >> > It sounds very cool in the abstract. It also sounds like an > unproductive distraction from work that would more readily advance the > interests of the FreeBSD community as a whole. > > What objective are we trying to achieve here? I thought we were > discussing how to make FreeBSD developers more productive. If that is > indeed the focus, extending the tool that is the closest match, which > is probably git, would ultimately be a better way to allocate limited > developer time and energy. No. This is in no way the distraction of developers from more important things. Within the next few years proposed SVN + Git downstream is just fine. This is just an objection against full switch to Git and a try to collect ideas for the more long-term future - when the FreeBSD get over current problems, VCS will become the next bottleneck. -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Anti-Greenpeace][Sober FreeBSD zealot][http://nuclight.livejournal.com] From owner-freebsd-arch@FreeBSD.ORG Tue Aug 30 21:47:54 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 653FB106564A for ; Tue, 30 Aug 2011 21:47:54 +0000 (UTC) (envelope-from freebsd-arch@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 1B8CB8FC0A for ; Tue, 30 Aug 2011 21:47:53 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QyW9x-0005Dk-0A for freebsd-arch@freebsd.org; Tue, 30 Aug 2011 23:47:53 +0200 Received: from 208.88.188.90.adsl.tomsknet.ru ([90.188.88.208]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 30 Aug 2011 23:47:52 +0200 Received: from vadim_nuclight by 208.88.188.90.adsl.tomsknet.ru with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 30 Aug 2011 23:47:52 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-arch@freebsd.org From: Vadim Goncharov Date: Tue, 30 Aug 2011 21:47:40 +0000 (UTC) Organization: Nuclear Lightning @ Tomsk, TPU AVTF Hostel Lines: 46 Message-ID: References: <35765857-1314243257-cardhu_decombobulator_blackberry.rim.net-329610575-@b2.c15.bise7.blackberry> <3CE7269E-DDD8-4A28-9FCD-D8FEA3C89089@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 208.88.188.90.adsl.tomsknet.ru X-Comment-To: Philip Paeps User-Agent: slrn/0.9.9p1 (FreeBSD) Subject: Re: Official git export X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vadim_nuclight@mail.ru List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 21:47:54 -0000 Hi Philip Paeps! On Mon, 29 Aug 2011 14:39:46 +0200; Philip Paeps wrote about 'Re: Official git export': >>> I have to admit I've always preferred Perforce to git, simply because it >>> strikes me as a more structured approach, partial checkouts (but especially >>> composition of different depot pieces in a single checkout to create hybrid >>> trees), etc. But git is widely used, and quite effectively used, by large >>> communities. We need to support those communities better. >> >> I haven't worked with Perforce, do you mean I could checkout at once several >> directories e.g. sbin/ipfw and sys/netinet/ipfw in my working copy? If so, >> sounds good. > Yes. Perforce is 'namespace-based'. You map parts of the repository namespace > into your client namespace and work from there. Branches are free for most > practical purposes and it's reasonably easy to merge between branches. Sounds very cool for Joe Random Contributor. > The main downside of Perforce is that the server likes to track every client's > files and that things get very shaky when you try to interfere with that > principle. One of my customers uses Perforce without tracking (or tries to) > and it goes horribly wrong in a number of ways (gigantic "p4 have" databases, > which don't reflect reality, accidental "p4 sync -k" locking up the server > for everyone for hours,...). That's not cool. I've already prepared to ask how to gain access and use for Joe Random Contributor... :-/ >> May be FreeBSD should really write it's own VCS, just as Git was >> modelled after proprietary BitKeeper?.. > I think git is a very reasonable system and it should be possible to map the > way we work with FreeBSD into git. As has been mentioned elsethread: things > would be a lot easier if we had "official git seeds" to pull from which > would make it easy to collaborate and then push things up into SVN. Also, a > page of "rules for things not to do with git" would be helpful. It would be > a bad idea if committers using git pushed changes into Subversion which made > subversion impossible to use (or much harder to use than it currently is). If the question is "make git officially additional to SVN", I'll vote for it. If the question is "replace SVN completely with Git", then I'll strongly object and better vote for writing FreeBSD's own VCS. -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Anti-Greenpeace][Sober FreeBSD zealot][http://nuclight.livejournal.com] From owner-freebsd-arch@FreeBSD.ORG Tue Aug 30 22:05:13 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9771A1065670 for ; Tue, 30 Aug 2011 22:05:13 +0000 (UTC) (envelope-from freebsd-arch@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 26D918FC12 for ; Tue, 30 Aug 2011 22:05:12 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QyWQg-0003di-Ul for freebsd-arch@freebsd.org; Wed, 31 Aug 2011 00:05:10 +0200 Received: from 208.88.188.90.adsl.tomsknet.ru ([90.188.88.208]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 31 Aug 2011 00:05:10 +0200 Received: from vadim_nuclight by 208.88.188.90.adsl.tomsknet.ru with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 31 Aug 2011 00:05:10 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-arch@freebsd.org From: Vadim Goncharov Date: Tue, 30 Aug 2011 22:04:57 +0000 (UTC) Organization: Nuclear Lightning @ Tomsk, TPU AVTF Hostel Lines: 34 Message-ID: References: <20110830082328.GB8085@lonesome.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 208.88.188.90.adsl.tomsknet.ru X-Comment-To: Mark Linimon User-Agent: slrn/0.9.9p1 (FreeBSD) Subject: Re: FreeBSD problems and preliminary ways to solve X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vadim_nuclight@mail.ru List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 22:05:13 -0000 Hi Mark Linimon! On Tue, 30 Aug 2011 03:23:28 -0500; Mark Linimon wrote about 'Re: FreeBSD problems and preliminary ways to solve': >> That's even more strange given that early years, pkg_* tools in NetBSD >> (pkgsrc) and FreeBSD got active code exchange. Why has it stopped later?.. > Although we do talk to each other e.g. at conferences, each of our projects > is sufficiently occupied with current tasks. There are some things that > they can do that we can't and vice versa. > > The codebase divergence is huge, and the target audience is different as > well. (For instance, FreeBSD isn't worried about boostrapping on other > OSes, as pkgsrc is. Attempting to deal with it is a huge task that would > simply give us no benefit.) If you take a look at the codebases, you'll > see how big the divergence is now. What I have heard from NetBSD engineers is that pkgsrc already bulk-builds more than 7000 packages on FreeBSD without any specific efforts to support it on FreeBSD. And that porting pkgsrc to new platform takes a few months for 1-2 men. That's definitely shows that this system is very effective in terms of maintainership, and thus worth at least looking at. Why can't we take what is best from them? Science research is being done to make more effective ways of doing things in practice, and NetBSD is a research OS. In fact, combining pkgsrc into a single thing with a single team for all *BSDs would be a very great thing, saving many amounts of human work when done. Or even unite *BSDs to split work, e.g. FreeBSD prefers to work on kernel and NetBSD on userland (that's matter of fact what different *BSD developers are preferring just now). It's very sad such things are fantastic now... or is it, for packages? -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Anti-Greenpeace][Sober FreeBSD zealot][http://nuclight.livejournal.com] From owner-freebsd-arch@FreeBSD.ORG Tue Aug 30 22:38:09 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15FA7106566B for ; Tue, 30 Aug 2011 22:38:09 +0000 (UTC) (envelope-from freebsd-arch@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 93CEC8FC0A for ; Tue, 30 Aug 2011 22:38:08 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QyWwZ-0007Gm-2a for freebsd-arch@freebsd.org; Wed, 31 Aug 2011 00:38:07 +0200 Received: from 208.88.188.90.adsl.tomsknet.ru ([90.188.88.208]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 31 Aug 2011 00:38:07 +0200 Received: from vadim_nuclight by 208.88.188.90.adsl.tomsknet.ru with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 31 Aug 2011 00:38:07 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-arch@freebsd.org From: Vadim Goncharov Date: Tue, 30 Aug 2011 22:37:52 +0000 (UTC) Organization: Nuclear Lightning @ Tomsk, TPU AVTF Hostel Lines: 59 Message-ID: References: <35765857-1314243257-cardhu_decombobulator_blackberry.rim.net-329610575-@b2.c15.bise7.blackberry> <4e5ba9c3.bzHIw1KEy8R2QcK7%perryh@pluto.rain.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 208.88.188.90.adsl.tomsknet.ru X-Comment-To: Robert Watson User-Agent: slrn/0.9.9p1 (FreeBSD) Subject: Re: Unproductive conversations X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vadim_nuclight@mail.ru List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 22:38:09 -0000 Hi Robert Watson! On Tue, 30 Aug 2011 14:37:31 +0100 (BST); Robert Watson wrote about 'Unproductive conversations (was: Re: Own VCS (Was: Official git export))': >> No. Completely own BSD-licensed DVCS designed specifically for FreeBSD, >> allowing partial checkouts and intended to replace SVN in the future :) > Vadim: > I think your post has triggered a number of very productive discussions about > improving FreeBSD and how to ensure FreeBSD remains relevant. Unfortunately, > I think this is not one of them. The whole world is waiting for a perfect > revision control system to turn up, but I think the FreeBSD Project isn't the > place to write it. That's right, and I didn't include VCS into my initial post, except of just an imaginary solution (somewhat kind of brainstorm fuse) near the bottom of the list (for the base system updates). > Historically, interestingly, it might have been -- cvsup was a tool developed > in the context of the FreeBSD Project on the basis that we effectively needed > something as scalable as a DVCS. It's actually one of the reasons it took us > so long to switch away from CVS: we made CVS do things no dreamed possibly in > terms of scalability. > Having made a highly disruptive but ultimately successful switch to > Subversion, and considered the pros and cons in the classic revision control > and DCVS spaces in the process, I think we should continue to sit on > Subversion for the time being. However, the thrust of my comments earlier in > this thread about git are about something different: not switching revision > control systems, or building the ultimate new one, but instead adapting to the > current status quo -- in a world in which there is no perfect system (and in > which different desirable features are even mutually exclusive), we need to > allow people to use the tool that they find easiest and most comfortable. > Which means supporting a large pool of downstream git users *better* than we > do today. Sorry that I didn't make it clear (or, looking at julian@ post, may be something was misunderstood, and not only by me) - the "own VCS is better" was an objection to "switch to Git and axe out SVN completely". I am by no means opposed to saving current status quo while "officially approving" Git downstream - this is a very good thing for the near future. > With so many areas to focus our attention, I honestly think we're better > served looking at things like package system architecture, improvements to > documentation, support for forthcoming hardware designs, etc, then trying to > build yet another DVCS from scratch in the confines of the FreeBSD Project. This, in principle, could be put to Project ideas for those volunteers who are currently not otherwise helping, etc., but not to developers, of course. Just a collection of ideas while the topic was touched. You said that FreeBSD did similar thing in the past, and I think this idea could still be pulled from cold reserve into living several years from now, when SVN will become a bottleneck. And getting a rough idea of what developers need from VCS is not bad even now. -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Anti-Greenpeace][Sober FreeBSD zealot][http://nuclight.livejournal.com] From owner-freebsd-arch@FreeBSD.ORG Wed Aug 31 00:26:21 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D3DB0106566B for ; Wed, 31 Aug 2011 00:26:21 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (pancho.soaustin.net [76.74.250.40]) by mx1.freebsd.org (Postfix) with ESMTP id B36BC8FC13 for ; Wed, 31 Aug 2011 00:26:21 +0000 (UTC) Received: by mail.soaustin.net (Postfix, from userid 502) id 0F6805615B; Tue, 30 Aug 2011 19:26:21 -0500 (CDT) Date: Tue, 30 Aug 2011 19:26:21 -0500 From: Mark Linimon To: Vadim Goncharov Message-ID: <20110831002621.GA24932@lonesome.com> References: <20110830082328.GB8085@lonesome.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-arch@freebsd.org Subject: Re: FreeBSD problems and preliminary ways to solve X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 00:26:21 -0000 On Tue, Aug 30, 2011 at 10:04:57PM +0000, Vadim Goncharov wrote: > What I have heard from NetBSD engineers is that pkgsrc already bulk-builds > more than 7000 packages on FreeBSD without any specific efforts to support > it on FreeBSD. There's specific code already in pkgsrc to support FreeBSD (see below). > Why can't we take what is best from them? [...] In fact, combining > pkgsrc into a single thing with a single team for all *BSDs would be > a very great thing [...] I rarely see calls for us to combine, but every week I see calls for testing patches to the FreeBSD ports collection. That's where I've decided to spend my own time as being most effective. Someone else would have to pick up the task of comparing and merging. > saving many amounts of human work when done. Possibly, over a very, very, long period of time. In the meantime, a quick check of the following http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/mk shows _more than 300 files_ in the repo (most of which are *.mk). If we were to move to that, we'd have to retrain hundreds of committers, thousands of maintainers, and tens of thousands of users on that codebase. And that's even after we did the many, many, months of work to add features that our users have come to depend on (e.g. MOVED) into pkgsrc, and adding all the applications that we have that are not yet availble there *. I think you are incredibly, incredibly, underestimating the amount of work that has gone into both of these systems, the amount of time it takes to become familiar with each one, and the amount of time that has been spent to get so many applications ported into each one. There are tens of thousands of lines of code in multiple languages (including make(1) as a language) in each, with multiple interlocking dependencies and the subtleties therein. The amount of work to do this merge would dwarf by orders of mangnitude fixing the problems in our individual ports right now. Having said all that, I would be very interested to see a feature- comparison chart between FreeBSD, pkgsrc, and OpenBSD ports. mcl * pkgsrc: 10086 per ftp://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/README-all.html * FreeBSD: 22758 per http://portsmon.freebsd.org/portsoverall.py From owner-freebsd-arch@FreeBSD.ORG Wed Aug 31 00:44:41 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4CA56106566B for ; Wed, 31 Aug 2011 00:44:41 +0000 (UTC) (envelope-from alex-goncharov@comcast.net) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by mx1.freebsd.org (Postfix) with ESMTP id E9F488FC14 for ; Wed, 31 Aug 2011 00:44:39 +0000 (UTC) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta05.westchester.pa.mail.comcast.net with comcast id SoiE1h0050EZKEL55okgC0; Wed, 31 Aug 2011 00:44:40 +0000 Received: from hanssachs.home ([24.61.85.144]) by omta01.westchester.pa.mail.comcast.net with comcast id Sokd1h00a36qgMk3MokdAu; Wed, 31 Aug 2011 00:44:39 +0000 Received: from algo by hanssachs.home with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QyYuy-0002bj-0u; Tue, 30 Aug 2011 20:44:36 -0400 From: Alex Goncharov To: Mark Linimon In-reply-to: <20110831002621.GA24932@lonesome.com> (message from Mark Linimon on Tue, 30 Aug 2011 19:26:21 -0500) References: <20110830082328.GB8085@lonesome.com> <20110831002621.GA24932@lonesome.com> Message-Id: Sender: Alex Goncharov Date: Tue, 30 Aug 2011 20:44:36 -0400 Cc: freebsd-arch@freebsd.org Subject: Re: FreeBSD problems and preliminary ways to solve X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Goncharov List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 00:44:41 -0000 ,--- You/Mark (Tue, 30 Aug 2011 19:26:21 -0500) ----* | I think you are incredibly, incredibly, underestimating the amount of | work that has gone into both of these systems, (FWIW, I share your thinking; the idea of developing a FreeBSD-special VCS equals this one.) | Having said all that, I would be very interested to see a feature- | comparison chart between FreeBSD, pkgsrc, and OpenBSD ports. You may find this discussion useful: http://mail-index.netbsd.org/netbsd-users/2011/08/04/msg008743.html (referencing probably the most appropriate message in the thread.) -- Alex -- alex-goncharov@comcast.net -- From owner-freebsd-arch@FreeBSD.ORG Wed Aug 31 06:07:18 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E0DC1065672 for ; Wed, 31 Aug 2011 06:07:18 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail12.syd.optusnet.com.au (mail12.syd.optusnet.com.au [211.29.132.193]) by mx1.freebsd.org (Postfix) with ESMTP id EBEFD8FC16 for ; Wed, 31 Aug 2011 06:07:17 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail12.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p7V67EMW026353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 31 Aug 2011 16:07:15 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.4/8.14.4) with ESMTP id p7V67Eoj040495 for ; Wed, 31 Aug 2011 16:07:14 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.4/8.14.4/Submit) id p7V67EpN040494 for freebsd-arch@freebsd.org; Wed, 31 Aug 2011 16:07:14 +1000 (EST) (envelope-from peter) Date: Wed, 31 Aug 2011 16:07:13 +1000 From: Peter Jeremy To: freebsd-arch@freebsd.org Message-ID: <20110831060713.GB37259@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="U+BazGySraz5kW0T" Content-Disposition: inline X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Regularly updated files in /etc X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 06:07:18 -0000 --U+BazGySraz5kW0T Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable FreeBSD has gradually moved "dynamic" files (those that are automously updated during normal system operation) out of /etc. As far as I can see, there are only 3 such files left: 1) /etc/dumpdates This is (optionally) updated by dump(8). 2) /etc/opiekeys This file is opened read-write on every login unless OPIE is disabled and is updated when any OPIE-enabled user logs in. 3) /etc/resolv.conf This is typically updated during DHCP or PPP negotiation. Is there a good reason why these files can't be moved to (eg) /var/db? The benefit is that root can more easily be mounted RO if desired. I don't see any real downsides for the first two: - Moving dumpdates out of root just means a different FS would need te be writable during dumps. - opiekeys is only useful in multiuser mode (you can't use OPIE in single-user mode because root isn't mounted RW) so there's no need for it to be on root. resolv.conf is more problematic: - Potentially, it could be needed to NFS mount /var, though this seems unlikely in practice. - Since there are no standard APIs for updating resolv.conf, there are likely to be lots of home-grown scripts that know where it is. Would it be worthwhile moving these files? --=20 Peter Jeremy --U+BazGySraz5kW0T Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk5dz5EACgkQ/opHv/APuIeHlACfex2Bnm8kiGuWTXgzkcLzkXfS JS4AnjQPrmC7N0FyjuzHdQQW8UfPpZED =GQWv -----END PGP SIGNATURE----- --U+BazGySraz5kW0T-- From owner-freebsd-arch@FreeBSD.ORG Wed Aug 31 07:11:14 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 039771065670 for ; Wed, 31 Aug 2011 07:11:14 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id BED6F8FC16 for ; Wed, 31 Aug 2011 07:11:13 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id p7V7BBtu065849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 31 Aug 2011 00:11:11 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id p7V7BA3Q065848; Wed, 31 Aug 2011 00:11:10 -0700 (PDT) Received: from fbsd81 ([192.168.200.81]) by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA23151; Wed, 31 Aug 11 00:08:36 PDT Date: Wed, 31 Aug 2011 07:08:31 -0700 From: perryh@pluto.rain.com To: peterjeremy@acm.org Message-Id: <4e5e405f.59yZRGyROtIPwuBg%perryh@pluto.rain.com> References: <20110831060713.GB37259@server.vk2pj.dyndns.org> In-Reply-To: <20110831060713.GB37259@server.vk2pj.dyndns.org> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: Regularly updated files in /etc X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 07:11:14 -0000 Peter Jeremy wrote: > - Moving dumpdates out of root just means a different FS would > need te be writable during dumps. Said other FS would also need to be _mounted_ during all dumps that either are incremental or specify -u; and it would ordinarily _not_ be mounted if one were following the classical advice to have the system in single-user mode (with root remounted read/write to enable writing to dumpdates) while running dump(8). Granted that's no longer supposed to be necessary if using -L, but not everyone trusts UFS snapshots. Since anyone who wants to move dumpdates elsewhere can easily enough add -D to their dump(8) scripts, and/or put a symlink to the new location in /etc, I don't know that there's a lot of upside to changing its default location. > resolv.conf is more problematic: > - Potentially, it could be needed to NFS mount /var, though this > seems unlikely in practice. > - Since there are no standard APIs for updating resolv.conf, there > are likely to be lots of home-grown scripts that know where it is. I would be concerned about the first item (chicken-egg problem). There would at least need to be an entry in UPDATING. The last is easy enough to fix by dropping a symlink to the new location into /etc, but as with dumpdates there is nothing stopping someone who wants a read-only root FS -- and who doesn't need an NFS-mounted /var -- from doing it on their own. From owner-freebsd-arch@FreeBSD.ORG Wed Aug 31 07:42:00 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 24BF11065672; Wed, 31 Aug 2011 07:42:00 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id F10BE8FC0A; Wed, 31 Aug 2011 07:41:59 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id p7V7fwj4068372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 31 Aug 2011 00:41:59 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id p7V7fw4L068371; Wed, 31 Aug 2011 00:41:58 -0700 (PDT) Received: from fbsd81 ([192.168.200.81]) by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA23263; Wed, 31 Aug 11 00:30:39 PDT Date: Wed, 31 Aug 2011 07:30:34 -0700 From: perryh@pluto.rain.com To: uqs@spoerlein.net Message-Id: <4e5e458a.Un+VK0itRgItvxbf%perryh@pluto.rain.com> References: <4e5ba9c3.bzHIw1KEy8R2QcK7%perryh@pluto.rain.com> <3420B331-C697-468A-80BA-B31C33804710@freebsd.org> <4e5c5b5f.moT7dLemOuteQJ5T%perryh@pluto.rain.com> <4E5C364D.7070904@freebsd.org> <20110830201357.GB58638@acme.spoerlein.net> In-Reply-To: <20110830201357.GB58638@acme.spoerlein.net> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: kmacy@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Official git export X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 07:42:00 -0000 Ulrich Sp??rlein wrote: > A partial checkout won't make git noticeably > faster, as it is pretty darn fast already. Surely it would be "noticeably faster" to _download_ only (say) /usr/src/sys than all of /usr/src, unless one has an uncommonly fast link? (It would also impose less load on the serving site.) From owner-freebsd-arch@FreeBSD.ORG Wed Aug 31 08:18:17 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4FDA01065796 for ; Wed, 31 Aug 2011 08:18:17 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from thyme.infocus-llc.com (server.infocus-llc.com [206.156.254.44]) by mx1.freebsd.org (Postfix) with ESMTP id 1D0338FC1B for ; Wed, 31 Aug 2011 08:18:16 +0000 (UTC) Received: from draco.over-yonder.net (c-174-50-4-38.hsd1.ms.comcast.net [174.50.4.38]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by thyme.infocus-llc.com (Postfix) with ESMTPSA id E5F7637B4A5; Wed, 31 Aug 2011 03:18:15 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 211A161C51; Wed, 31 Aug 2011 03:18:15 -0500 (CDT) Date: Wed, 31 Aug 2011 03:18:15 -0500 From: "Matthew D. Fuller" To: perryh@pluto.rain.com Message-ID: <20110831081815.GN2493@over-yonder.net> References: <4e5ba9c3.bzHIw1KEy8R2QcK7%perryh@pluto.rain.com> <3420B331-C697-468A-80BA-B31C33804710@freebsd.org> <4e5c5b5f.moT7dLemOuteQJ5T%perryh@pluto.rain.com> <4E5C364D.7070904@freebsd.org> <20110830201357.GB58638@acme.spoerlein.net> <4e5e458a.Un+VK0itRgItvxbf%perryh@pluto.rain.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4e5e458a.Un+VK0itRgItvxbf%perryh@pluto.rain.com> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.21-fullermd.4 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97.2 at thyme.infocus-llc.com X-Virus-Status: Clean Cc: uqs@spoerlein.net, kmacy@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Official git export X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 08:18:17 -0000 On Wed, Aug 31, 2011 at 07:30:34AM -0700 I heard the voice of perryh@pluto.rain.com, and lo! it spake thus: > > Surely it would be "noticeably faster" to _download_ only (say) > /usr/src/sys than all of /usr/src, unless one has an uncommonly fast > link? (It would also impose less load on the serving site.) In the context of most current-gen DVCSen, it's unlikely to be much (or in fact _any_) faster or less data to transfer. It's just less data to blat into the working tree. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-arch@FreeBSD.ORG Wed Aug 31 08:45:45 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00B15106566B; Wed, 31 Aug 2011 08:45:45 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 8413A8FC16; Wed, 31 Aug 2011 08:45:44 +0000 (UTC) Received: from localhost (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by acme.spoerlein.net (8.14.4/8.14.4) with ESMTP id p7V8jhuu002163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 31 Aug 2011 10:45:43 +0200 (CEST) (envelope-from uqs@spoerlein.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=spoerlein.net; s=dkim200908; t=1314780343; bh=MkVnJv+eA74N0Ww0QpLLT6nqDa3RlDsmKtY7YvnEG/4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=qRvQ9TLF5KCUvOH9Wpkr12tfES69jEdWYPA8w/A4RcVo0pfT79c4Ut9rkbsYJT36m 1SJdRNBdvyMEzVQIzDT81tLhZz01Cdt3C6+2tEcO/SXV8MaOiv1kzkCimkrKfmUiRv YaMqyMsHEJzkm1pa40ELi0FMwxGWlyLbdAfVKHhU= Date: Wed, 31 Aug 2011 10:45:42 +0200 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: "K. Macy" Message-ID: <20110831084542.GC58638@acme.spoerlein.net> Mail-Followup-To: "K. Macy" , Julian Elischer , freebsd-arch@freebsd.org References: <4e5ba9c3.bzHIw1KEy8R2QcK7%perryh@pluto.rain.com> <3420B331-C697-468A-80BA-B31C33804710@freebsd.org> <4e5c5b5f.moT7dLemOuteQJ5T%perryh@pluto.rain.com> <4E5C364D.7070904@freebsd.org> <20110830201357.GB58638@acme.spoerlein.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arch@freebsd.org Subject: Re: Official git export X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 08:45:45 -0000 On Tue, 2011-08-30 at 22:20:55 +0200, K. Macy wrote: > w far back in time one's repo goes and being > >> able to have some control over views would go a long way towards > >> streamlining its use for FreeBSD. > > > > Utterly irrelevant. A partial checkout won't make git noticeably > > faster, as it is pretty darn fast already. Believe me. A truncated > > history might save you up to 150MB, also totally not worth the effort, > > especially because then your custom git repo has different hashes and > > fetching/merging other peoples branches becomes impossible. > > > > Furthermore, the point with git is to have multiple branches in your > > workspace and switch between them (again, this is frigging fast). I was > > juggling 8-10 branches at one time and have never had the need to create > > a second workspace ('git stash' being the keyword here). > > > > Please have a look at http://wiki.freebsd.org/GitWorkflow and try it > > out! > > I've been working out of git for the past 15 months: > > https://www.gitorious.org/~kmm/freebsd/kmm-sandbox > > I'm afraid that due to time and bandwidth constraints the size of the > initial repository is indeed relevant for many of us. So the full history for head clocks in around 570MB whereas a history from r225000 onward will take up 164MB of space. I really think that this factor <4x is something people should just accept. It is a one-time thing anyway, and if they managed to download an ISO image of FreeBSD or have Xorg and Firefox installed, they had to download more than that before. Funnily enough, people with time and bandwidth constraints are those that profit from git the most! :) But noone's forcing anybody to use git, so if svn works better for those folk (I can hardly imagine how), just continue using it. It's not going away. Cheers, Uli From owner-freebsd-arch@FreeBSD.ORG Wed Aug 31 09:34:12 2011 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A5E91065672 for ; Wed, 31 Aug 2011 09:34:12 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 3A0B88FC19 for ; Wed, 31 Aug 2011 09:34:10 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA15997 for ; Wed, 31 Aug 2011 12:34:10 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1QyhBR-00083F-Ii for arch@freebsd.org; Wed, 31 Aug 2011 12:34:09 +0300 Message-ID: <4E5E0011.2080402@FreeBSD.org> Date: Wed, 31 Aug 2011 12:34:09 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0) Gecko/20110830 Thunderbird/6.0 MIME-Version: 1.0 To: arch@FreeBSD.org References: <4E5B8ED2.8030109@FreeBSD.org> In-Reply-To: <4E5B8ED2.8030109@FreeBSD.org> X-Enigmail-Version: undefined X-Forwarded-Message-Id: <4E5B8ED2.8030109@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: some syscons ideas X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 09:34:12 -0000 I thought that it would be useful to forward this email here too. The original Bruce's email can be found by its message id or via this link: http://article.gmane.org/gmane.os.freebsd.devel.cvs/437692 -------- Original Message -------- Message-ID: <4E5B8ED2.8030109@FreeBSD.org> Date: Mon, 29 Aug 2011 16:06:26 +0300 From: Andriy Gapon To: Bruce Evans Subject: Re: svn commit: r223989 - head/sys/dev/usb/input References: <201107181610.49443.hselasky@c2i.net> <4E26AFF8.8080107@FreeBSD.org> <201107201249.39550.hselasky@c2i.net> <20110720221325.E1436@besplex.bde.org> In-Reply-To: <20110720221325.E1436@besplex.bde.org> Having got my feet a little bit wet in this code I have only the following to add: on 20/07/2011 18:32 Bruce Evans said the following: [snip] > A non-broken API needs cn_open() and cn_close() functions which would > normally switch the driver in an out of polling mode. Given these > interfaces easy to fix the per-character poll to work as well as before > the multiple console changes, including for multiple active consoles. > Just call cn_open() and cn_close() on every active console around the > whole polling loop. A little more is required to prevent races between > characters, and to avoid the races inherent in the cn_checkc() API. > For multi-char input like that at the mountroot prompt, calling > cn_open() and cn_close() around the loop in gets(9) is adequate. The > functions should be almost no-ops when called nested for things like > this. I completely agree. > BTW, gets(9) is bogusly named. It is not harmful like gets(3), > since it takes a buffer size arg. It is used approximately once, > for mountroot input, so renaming it would be easy. Perhaps it > should be named cn_gets() and be implemented closer to the console > driver, or be implemented closer to printf() (it is now in libkern). Again, I completely agree. Perhaps there should also be a variant that works in an interrupt driven mode, if possible, exactly for the mountroot prompt and similar. > For debugger entry and panics, the whole operation should be wrapped > by cn_open()/cn_close(). This covers most cases. Some console drivers > now sort of work in debugger mode by abusing the kdb_active variable, > or because debugger entry stops interrupts and other CPUs. Yes and yes. [snip] > There should be significant differences, but were only small ones > in practice, between being in debugger mode and being in polling > mode. For example, entering console i/o mode for syscons should > involve switching the video mode and perhaps the frame buffer to > a special one, in case the current one is unusable for some reason > (it might be controlled by X, or in the middle of an initialization, > or you might just want to avoid scribbling on its frame buffer). > Thus, entering console i/o mode might be an extemely heavyweight > operation. You don't want to do it on every entry to debugger mode. > Even if the switch is very fast, it would make the screen flicker > to switch the frame buffer on every entry to the debugger for things > like tracing (but not displaying) every instruction when single > stepping using 'n' in ddb. This is a little bit different from the main topic, but I agree that entering kdb should ensure that the video console is fully usable if it's configured. [snip] So, all in all, just voicing my agreement in a hope that these ideas do not get forgotten again. P.S. I would like to forward this email to arch@ if nobody objects. -- Andriy Gapon From owner-freebsd-arch@FreeBSD.ORG Wed Aug 31 10:55:04 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D7181065672 for ; Wed, 31 Aug 2011 10:55:04 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4A48C8FC15 for ; Wed, 31 Aug 2011 10:55:04 +0000 (UTC) Received: by vxh11 with SMTP id 11so417982vxh.13 for ; Wed, 31 Aug 2011 03:55:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=xPKBsuzkW/KR3WHqYqlIQabjdHpguGKn4yqzqwyu9Ws=; b=BK5jeNgQnrxzfq9A/6dWxl/Q/kiESsia8iVLK3KcYZytT1OboIdlpcHpwg4HoHlNWJ BPMoXHyho7HMi6jF+wmbNzdkuwznEtgqyUB2JpQcNBNlxKbbu32nI0ig/HZn8Opg1UCY MT7KnBeHDp16rXaUYVJnd94rDlpKP9mulhF6g= MIME-Version: 1.0 Received: by 10.52.95.229 with SMTP id dn5mr178635vdb.431.1314788103570; Wed, 31 Aug 2011 03:55:03 -0700 (PDT) Sender: kmacybsd@gmail.com Received: by 10.52.187.231 with HTTP; Wed, 31 Aug 2011 03:55:03 -0700 (PDT) In-Reply-To: <20110831084542.GC58638@acme.spoerlein.net> References: <4e5ba9c3.bzHIw1KEy8R2QcK7%perryh@pluto.rain.com> <3420B331-C697-468A-80BA-B31C33804710@freebsd.org> <4e5c5b5f.moT7dLemOuteQJ5T%perryh@pluto.rain.com> <4E5C364D.7070904@freebsd.org> <20110830201357.GB58638@acme.spoerlein.net> <20110831084542.GC58638@acme.spoerlein.net> Date: Wed, 31 Aug 2011 12:55:03 +0200 X-Google-Sender-Auth: u9IMXMCDsBdzu-suUXCREpm_gE4 Message-ID: From: "K. Macy" To: freebsd-arch@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: Official git export X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 10:55:04 -0000 is indeed relevant for many of us. > > So the full history for head clocks in around 570MB whereas a history > from r225000 onward will take up 164MB of space. I really think that > this factor <4x is something people should just accept. It is a one-time > thing anyway, and if they managed to download an ISO image of FreeBSD or > have Xorg and Firefox installed, they had to download more than that > before. > > Funnily enough, people with time and bandwidth constraints are those > that profit from git the most! :) > > But noone's forcing anybody to use git, so if svn works better for those > folk (I can hardly imagine how), just continue using it. It's not going > away. While I appreciate your evident understanding of git, it would seem that I have not successfully communicated my intent to you. It is possible that my needs and the needs of those with whom I work regularly do not intersect with yours and thus my observations will not seem germane. What *I* am discussing, is not git vs. svn, but the areas which could make git work better for those of us who would like to use it in the way that I have been doing. The full history of HEAD is not useful to most of us. However, the full history of the most recent stable branches, e.g. 7 and 8 is. As far as I understand Fabien had to put in a fair amount of effort to create a git repository of a manageable size. I feel that your either A or B emphasis is diminishing the potential value of this discussion. Cheers From owner-freebsd-arch@FreeBSD.ORG Wed Aug 31 12:45:46 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 621D7106566B; Wed, 31 Aug 2011 12:45:46 +0000 (UTC) (envelope-from fabien.thomas@netasq.com) Received: from work.netasq.com (mars.netasq.com [91.212.116.3]) by mx1.freebsd.org (Postfix) with ESMTP id C15AF8FC16; Wed, 31 Aug 2011 12:45:45 +0000 (UTC) Received: from [10.2.1.1] (unknown [10.2.1.1]) by work.netasq.com (Postfix) with ESMTPSA id 897B8740041; Wed, 31 Aug 2011 14:27:12 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Fabien Thomas In-Reply-To: Date: Wed, 31 Aug 2011 14:27:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <08D86AEA-EA97-4F68-BB96-F9534FE005E2@netasq.com> References: <4e5ba9c3.bzHIw1KEy8R2QcK7%perryh@pluto.rain.com> <3420B331-C697-468A-80BA-B31C33804710@freebsd.org> <4e5c5b5f.moT7dLemOuteQJ5T%perryh@pluto.rain.com> <4E5C364D.7070904@freebsd.org> <20110830201357.GB58638@acme.spoerlein.net> <20110831084542.GC58638@acme.spoerlein.net> To: "K. Macy" X-Mailer: Apple Mail (2.1084) Cc: freebsd-arch@freebsd.org Subject: Re: Official git export X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Fabien Thomas List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 12:45:46 -0000 On Aug 31, 2011, at 12:55 PM, K. Macy wrote: > is indeed relevant for many of us. >>=20 >> So the full history for head clocks in around 570MB whereas a history >> from r225000 onward will take up 164MB of space. I really think that >> this factor <4x is something people should just accept. It is a = one-time >> thing anyway, and if they managed to download an ISO image of FreeBSD = or >> have Xorg and Firefox installed, they had to download more than that >> before. >>=20 >> Funnily enough, people with time and bandwidth constraints are those >> that profit from git the most! :) >>=20 >> But noone's forcing anybody to use git, so if svn works better for = those >> folk (I can hardly imagine how), just continue using it. It's not = going >> away. >=20 > While I appreciate your evident understanding of git, it would seem > that I have not successfully communicated my intent to you. It is > possible that my needs and the needs of those with whom I work > regularly do not intersect with yours and thus my observations will > not seem germane. >=20 > What *I* am discussing, is not git vs. svn, but the areas which could > make git work better for those of us who would like to use it in the > way that I have been doing. The full history of HEAD is not useful to > most of us. However, the full history of the most recent stable > branches, e.g. 7 and 8 is. As far as I understand Fabien had to put in > a fair amount of effort to create a git repository of a manageable > size. My initial concern about full git-svn sync vs only useful branches = (release + stable + head) with full history was to keep the branch namespace clean and to remove = some size (not evaluated). For me the full history is very useful even from r0 to get to the = original commit message for a modification.=20 I'm not a git fan to replace svn for the main repo. At work we use the = same scheme for git: - git for work, shared work, test. - svn for the final commit To sum-up it will be great if the git server appear on freebsd.org. = Today the robot that synchronize from git-svn to git on gitorious is on my my local server that can go down = quite easily :D. Even if only upstream (read only) server is provided this is useful to = populate work area on different git services. Fabien= From owner-freebsd-arch@FreeBSD.ORG Wed Aug 31 14:24:49 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C9FF0106566B; Wed, 31 Aug 2011 14:24:49 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id A18048FC08; Wed, 31 Aug 2011 14:24:49 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 430D346B06; Wed, 31 Aug 2011 10:24:49 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id CB3768A02E; Wed, 31 Aug 2011 10:24:48 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Date: Wed, 31 Aug 2011 09:43:24 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <4E53986B.5000804@FreeBSD.org> <4E5A099F.4060903@FreeBSD.org> <201108281127.44696.hselasky@freebsd.org> In-Reply-To: <201108281127.44696.hselasky@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201108310943.24476.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 31 Aug 2011 10:24:48 -0400 (EDT) Cc: Hans Petter Selasky , Andriy Gapon Subject: Re: skipping locks, mutex_owned, usb X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 14:24:49 -0000 On Sunday, August 28, 2011 5:27:44 am Hans Petter Selasky wrote: > On Sunday 28 August 2011 11:25:51 Andriy Gapon wrote: > > on 23/08/2011 15:09 Andriy Gapon said the following: > > > This "XXX cludge" [sic] pattern is scattered around a few functions in > > > the ukbd code and perhaps other usb code: > > > func() > > > { > > > > > > if (!mtx_owned(&Giant)) { > > > > > > mtx_lock(&Giant); > > > > > > func(); > > > mtx_unlock(&Giant); > > > > > > return; > > > > > > } > > > > > > // etc ... > > > > > > } > > > > Ohhh, nothing seems simple with the USB code: > > > > /* make sure that the BUS mutex is not locked */ > > drop_bus = 0; > > while (mtx_owned(&xroot->udev->bus->bus_mtx)) { > > mtx_unlock(&xroot->udev->bus->bus_mtx); > > drop_bus++; > > } > > > > /* make sure that the transfer mutex is not locked */ > > drop_xfer = 0; > > while (mtx_owned(xroot->xfer_mtx)) { > > mtx_unlock(xroot->xfer_mtx); > > drop_xfer++; > > } > > > > So many unconventional tricks. > > Similar code is used in the DROP_GIANT and PICKUP_GIANT macros. You might want > to check all references to mtx_owned() in the kernel, and make a set of > exceptions for post-panic code execution. Giant is special because it is a hack to let us run non-MPSAFE code. Other locks should not follow its model. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Aug 31 14:34:44 2011 Return-Path: Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98471106564A for ; Wed, 31 Aug 2011 14:34:44 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 591078FC15 for ; Wed, 31 Aug 2011 14:34:44 +0000 (UTC) Received: from [10.0.0.63] (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p7VEVbQk080972 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Wed, 31 Aug 2011 08:31:40 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20110831060713.GB37259@server.vk2pj.dyndns.org> Date: Wed, 31 Aug 2011 08:30:33 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110831060713.GB37259@server.vk2pj.dyndns.org> To: Peter Jeremy X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Wed, 31 Aug 2011 08:31:40 -0600 (MDT) Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Regularly updated files in /etc X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 14:34:44 -0000 On Aug 31, 2011, at 12:07 AM, Peter Jeremy wrote: > I don't see any real downsides for the first two: > - Moving dumpdates out of root just means a different FS would need te > be writable during dumps. The whole reason it is in / is so that when you are doing level 0 dumps = of the entire machine, you only need to have / mounted r/w. Moving it = to /var introduces another moving part into the requirements for dumps = since /var is on another file system. It would likely break backup = scripts. Warner From owner-freebsd-arch@FreeBSD.ORG Wed Aug 31 16:13:25 2011 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2D551065670; Wed, 31 Aug 2011 16:13:25 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 57EC28FC12; Wed, 31 Aug 2011 16:13:23 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA22758; Wed, 31 Aug 2011 19:13:21 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4E5E5DA0.4060003@FreeBSD.org> Date: Wed, 31 Aug 2011 19:13:20 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110705 Thunderbird/5.0 MIME-Version: 1.0 To: John Baldwin , Hans Petter Selasky References: <4E53986B.5000804@FreeBSD.org> <4E5A099F.4060903@FreeBSD.org> <201108281127.44696.hselasky@freebsd.org> <201108310943.24476.jhb@freebsd.org> In-Reply-To: <201108310943.24476.jhb@freebsd.org> X-Enigmail-Version: 1.2pre Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-arch@FreeBSD.org Subject: Re: skipping locks, mutex_owned, usb X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 16:13:25 -0000 on 31/08/2011 16:43 John Baldwin said the following: > On Sunday, August 28, 2011 5:27:44 am Hans Petter Selasky wrote: >> On Sunday 28 August 2011 11:25:51 Andriy Gapon wrote: >>> on 23/08/2011 15:09 Andriy Gapon said the following: >>>> This "XXX cludge" [sic] pattern is scattered around a few functions in >>>> the ukbd code and perhaps other usb code: >>>> func() >>>> { >>>> >>>> if (!mtx_owned(&Giant)) { >>>> >>>> mtx_lock(&Giant); >>>> >>>> func(); >>>> mtx_unlock(&Giant); >>>> >>>> return; >>>> >>>> } >>>> >>>> // etc ... >>>> >>>> } >>> >>> Ohhh, nothing seems simple with the USB code: >>> >>> /* make sure that the BUS mutex is not locked */ >>> drop_bus = 0; >>> while (mtx_owned(&xroot->udev->bus->bus_mtx)) { >>> mtx_unlock(&xroot->udev->bus->bus_mtx); >>> drop_bus++; >>> } >>> >>> /* make sure that the transfer mutex is not locked */ >>> drop_xfer = 0; >>> while (mtx_owned(xroot->xfer_mtx)) { >>> mtx_unlock(xroot->xfer_mtx); >>> drop_xfer++; >>> } >>> >>> So many unconventional tricks. >> >> Similar code is used in the DROP_GIANT and PICKUP_GIANT macros. You might > want >> to check all references to mtx_owned() in the kernel, and make a set of >> exceptions for post-panic code execution. > > Giant is special because it is a hack to let us run non-MPSAFE code. Other > locks should not follow its model. > Hans, actually this makes me wonder... It seems that usbd_transfer_poll() function that utilizes the above code is called from a number of xxx_poll routines in various usb drivers (ukbd, umass and a bunch of serial drivers): $ glimpse -l usbd_transfer_poll | fgrep .c /usr/src/sys/dev/usb/input/ukbd.c /usr/src/sys/dev/usb/usb_transfer.c /usr/src/sys/dev/usb/storage/umass.c /usr/src/sys/dev/usb/serial/ucycom.c /usr/src/sys/dev/usb/serial/umoscom.c /usr/src/sys/dev/usb/serial/umcs.c /usr/src/sys/dev/usb/serial/umodem.c /usr/src/sys/dev/usb/serial/uchcom.c /usr/src/sys/dev/usb/serial/uipaq.c /usr/src/sys/dev/usb/serial/ugensa.c /usr/src/sys/dev/usb/serial/uark.c /usr/src/sys/dev/usb/serial/ufoma.c /usr/src/sys/dev/usb/serial/umct.c /usr/src/sys/dev/usb/serial/ubsa.c /usr/src/sys/dev/usb/serial/uslcom.c /usr/src/sys/dev/usb/serial/uplcom.c /usr/src/sys/dev/usb/serial/uvscom.c /usr/src/sys/dev/usb/serial/uftdi.c /usr/src/sys/dev/usb/serial/ubser.c So why the mutex unwinding/rewinding code is present at all? What kind of situations is it supposed to prevent? Personally I think that we either know that those drivers should not hold the locks in question (bus_mtx and xfer_mtx) or we know that they hold them. I do not see why we have to be conditional here or have a loop even... -- Andriy Gapon From owner-freebsd-arch@FreeBSD.ORG Wed Aug 31 16:40:48 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 607CF106566C; Wed, 31 Aug 2011 16:40:48 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 126F18FC17; Wed, 31 Aug 2011 16:40:47 +0000 (UTC) Received: from [10.30.101.53] ([209.117.142.2]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p7VGX8N0082575 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Wed, 31 Aug 2011 10:33:12 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <4E5E5DA0.4060003@FreeBSD.org> Date: Wed, 31 Aug 2011 10:32:57 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E53986B.5000804@FreeBSD.org> <4E5A099F.4060903@FreeBSD.org> <201108281127.44696.hselasky@freebsd.org> <201108310943.24476.jhb@freebsd.org> <4E5E5DA0.4060003@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Wed, 31 Aug 2011 10:33:12 -0600 (MDT) Cc: Hans Petter Selasky , freebsd-arch@freebsd.org Subject: Re: skipping locks, mutex_owned, usb X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 16:40:48 -0000 On Aug 31, 2011, at 10:13 AM, Andriy Gapon wrote: > on 31/08/2011 16:43 John Baldwin said the following: >> On Sunday, August 28, 2011 5:27:44 am Hans Petter Selasky wrote: >>> On Sunday 28 August 2011 11:25:51 Andriy Gapon wrote: >>>> on 23/08/2011 15:09 Andriy Gapon said the following: >>>>> This "XXX cludge" [sic] pattern is scattered around a few = functions in >>>>> the ukbd code and perhaps other usb code: >>>>> func() >>>>> { >>>>>=20 >>>>> if (!mtx_owned(&Giant)) { >>>>> =09 >>>>> mtx_lock(&Giant); >>>>> =09 >>>>> func(); >>>>> mtx_unlock(&Giant); >>>>> =09 >>>>> return; >>>>> =09 >>>>> } >>>>> =09 >>>>> // etc ... >>>>>=20 >>>>> } >>>>=20 >>>> Ohhh, nothing seems simple with the USB code: >>>>=20 >>>> /* make sure that the BUS mutex is not locked */ >>>> drop_bus =3D 0; >>>> while (mtx_owned(&xroot->udev->bus->bus_mtx)) { >>>> mtx_unlock(&xroot->udev->bus->bus_mtx); >>>> drop_bus++; >>>> } >>>>=20 >>>> /* make sure that the transfer mutex is not locked */ >>>> drop_xfer =3D 0; >>>> while (mtx_owned(xroot->xfer_mtx)) { >>>> mtx_unlock(xroot->xfer_mtx); >>>> drop_xfer++; >>>> } >>>>=20 >>>> So many unconventional tricks. >>>=20 >>> Similar code is used in the DROP_GIANT and PICKUP_GIANT macros. You = might=20 >> want=20 >>> to check all references to mtx_owned() in the kernel, and make a set = of=20 >>> exceptions for post-panic code execution. >>=20 >> Giant is special because it is a hack to let us run non-MPSAFE code. = Other >> locks should not follow its model. >>=20 >=20 > Hans, >=20 > actually this makes me wonder... It seems that usbd_transfer_poll() = function that > utilizes the above code is called from a number of xxx_poll routines = in various > usb drivers (ukbd, umass and a bunch of serial drivers): > $ glimpse -l usbd_transfer_poll | fgrep .c > /usr/src/sys/dev/usb/input/ukbd.c > /usr/src/sys/dev/usb/usb_transfer.c > /usr/src/sys/dev/usb/storage/umass.c > /usr/src/sys/dev/usb/serial/ucycom.c > /usr/src/sys/dev/usb/serial/umoscom.c > /usr/src/sys/dev/usb/serial/umcs.c > /usr/src/sys/dev/usb/serial/umodem.c > /usr/src/sys/dev/usb/serial/uchcom.c > /usr/src/sys/dev/usb/serial/uipaq.c > /usr/src/sys/dev/usb/serial/ugensa.c > /usr/src/sys/dev/usb/serial/uark.c > /usr/src/sys/dev/usb/serial/ufoma.c > /usr/src/sys/dev/usb/serial/umct.c > /usr/src/sys/dev/usb/serial/ubsa.c > /usr/src/sys/dev/usb/serial/uslcom.c > /usr/src/sys/dev/usb/serial/uplcom.c > /usr/src/sys/dev/usb/serial/uvscom.c > /usr/src/sys/dev/usb/serial/uftdi.c > /usr/src/sys/dev/usb/serial/ubser.c >=20 > So why the mutex unwinding/rewinding code is present at all? > What kind of situations is it supposed to prevent? >=20 > Personally I think that we either know that those drivers should not = hold the > locks in question (bus_mtx and xfer_mtx) or we know that they hold = them. > I do not see why we have to be conditional here or have a loop even... Today, I think we know these things. In the past, as the code was = written, there was a lot more special case code needed for giant = cohabitation. Warner= From owner-freebsd-arch@FreeBSD.ORG Wed Aug 31 16:46:29 2011 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A845106564A; Wed, 31 Aug 2011 16:46:29 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 78D4C8FC0C; Wed, 31 Aug 2011 16:46:28 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA23253; Wed, 31 Aug 2011 19:46:23 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4E5E655E.8060505@FreeBSD.org> Date: Wed, 31 Aug 2011 19:46:22 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110705 Thunderbird/5.0 MIME-Version: 1.0 To: Warner Losh References: <4E53986B.5000804@FreeBSD.org> <4E5A099F.4060903@FreeBSD.org> <201108281127.44696.hselasky@freebsd.org> <201108310943.24476.jhb@freebsd.org> <4E5E5DA0.4060003@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.2pre Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Hans Petter Selasky , John Baldwin , freebsd-arch@FreeBSD.org Subject: Re: skipping locks, mutex_owned, usb X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 16:46:29 -0000 on 31/08/2011 19:32 Warner Losh said the following: > > On Aug 31, 2011, at 10:13 AM, Andriy Gapon wrote: >> So why the mutex unwinding/rewinding code is present at all? >> What kind of situations is it supposed to prevent? >> >> Personally I think that we either know that those drivers should not hold the >> locks in question (bus_mtx and xfer_mtx) or we know that they hold them. >> I do not see why we have to be conditional here or have a loop even... > > Today, I think we know these things. In the past, as the code was written, there was a lot more special case code needed for giant cohabitation. Since you chimed in... :-) I have a hard time imagining a situation where that code is useful today or was useful before. Any example, purely hypothetical even, would do. -- Andriy Gapon From owner-freebsd-arch@FreeBSD.ORG Wed Aug 31 17:13:58 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E17271065676; Wed, 31 Aug 2011 17:13:58 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 80F688FC0C; Wed, 31 Aug 2011 17:13:58 +0000 (UTC) Received: from [10.30.101.53] ([209.117.142.2]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p7VGxLtQ082917 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Wed, 31 Aug 2011 10:59:25 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <4E5E655E.8060505@FreeBSD.org> Date: Wed, 31 Aug 2011 10:59:11 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E53986B.5000804@FreeBSD.org> <4E5A099F.4060903@FreeBSD.org> <201108281127.44696.hselasky@freebsd.org> <201108310943.24476.jhb@freebsd.org> <4E5E5DA0.4060003@FreeBSD.org> <4E5E655E.8060505@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Wed, 31 Aug 2011 10:59:26 -0600 (MDT) Cc: Hans Petter Selasky , freebsd-arch@freebsd.org Subject: Re: skipping locks, mutex_owned, usb X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 17:13:59 -0000 On Aug 31, 2011, at 10:46 AM, Andriy Gapon wrote: > on 31/08/2011 19:32 Warner Losh said the following: >>=20 >> On Aug 31, 2011, at 10:13 AM, Andriy Gapon wrote: >>> So why the mutex unwinding/rewinding code is present at all? >>> What kind of situations is it supposed to prevent? >>>=20 >>> Personally I think that we either know that those drivers should not = hold the >>> locks in question (bus_mtx and xfer_mtx) or we know that they hold = them. >>> I do not see why we have to be conditional here or have a loop = even... >>=20 >> Today, I think we know these things. In the past, as the code was = written, there was a lot more special case code needed for giant = cohabitation. >=20 > Since you chimed in... :-) > I have a hard time imagining a situation where that code is useful = today or was > useful before. > Any example, purely hypothetical even, would do. IIRC, and Hans can correct me, this code was put in so that we could run = GIANT locked usb network drivers (or was it TTY drivers). There were = situations where the USB would have a lock held, then need to call into = code that picked up GIANT which then called back into the USB stack = which then would pick up GIANT and make calls to routines to pickup the = USB lock, and fail due to recursion (or was that to prevent a witness = warning about sleeping with malloc, it has been a while and I don't = recall for sure). I'm sure I'm forgetting a detail or two because = re-reading what I just wrote makes me go "what, that doesn't sound quite = right" :) Today, the locking landscape is such that I don't think we still have = the same issues. However, I've not studied the USB code recently, so = hopefully Hans can help sort out the reasons for it. Warner From owner-freebsd-arch@FreeBSD.ORG Wed Aug 31 18:18:21 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 121A61065673; Wed, 31 Aug 2011 18:18:21 +0000 (UTC) (envelope-from hselasky@freebsd.org) Received: from swip.net (mailfe06.c2i.net [212.247.154.162]) by mx1.freebsd.org (Postfix) with ESMTP id 40BB98FC20; Wed, 31 Aug 2011 18:18:19 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=MmhuielNmoAwiWCiiefMnqMoo9XwPcHPH2oGFNV1oLM= c=1 sm=1 a=SvYTsOw2Z4kA:10 a=ni9ZY7ZFbhgA:10 a=dBRESv0yCI8A:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=-G6q7kbFCyEwIIUnyiIA:9 a=H_8iCRKF1ZwUWQpn-5AA:7 a=wPNLvfGTeEIA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe06.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 172612366; Wed, 31 Aug 2011 20:18:17 +0200 Received-SPF: softfail receiver=mailfe06.swip.net; client-ip=188.126.198.129; envelope-from=hselasky@freebsd.org From: Hans Petter Selasky To: freebsd-arch@freebsd.org Date: Wed, 31 Aug 2011 20:15:40 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: <4E53986B.5000804@FreeBSD.org> <4E5E5DA0.4060003@FreeBSD.org> In-Reply-To: X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq, NwSZ4V"|LR.+tj}g5 %V,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( :AuzV9:.hESm-x4h240C`9=w MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201108312015.40791.hselasky@freebsd.org> Cc: Andriy Gapon Subject: Re: skipping locks, mutex_owned, usb X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 18:18:21 -0000 On Wednesday 31 August 2011 18:32:57 Warner Losh wrote: > On Aug 31, 2011, at 10:13 AM, Andriy Gapon wrote: > > on 31/08/2011 16:43 John Baldwin said the following: > >> On Sunday, August 28, 2011 5:27:44 am Hans Petter Selasky wrote: > >>> On Sunday 28 August 2011 11:25:51 Andriy Gapon wrote: > >>>> on 23/08/2011 15:09 Andriy Gapon said the following: > >>>>> This "XXX cludge" [sic] pattern is scattered around a few functions > >>>>> in the ukbd code and perhaps other usb code: > >>>>> func() > >>>>> { > >>>>> > >>>>> if (!mtx_owned(&Giant)) { > >>>>> > >>>>> mtx_lock(&Giant); > >>>>> > >>>>> func(); > >>>>> mtx_unlock(&Giant); > >>>>> > >>>>> return; > >>>>> > >>>>> } > >>>>> > >>>>> // etc ... > >>>>> > >>>>> } > >>>> > >>>> Ohhh, nothing seems simple with the USB code: > >>>> > >>>> /* make sure that the BUS mutex is not locked */ > >>>> drop_bus = 0; > >>>> while (mtx_owned(&xroot->udev->bus->bus_mtx)) { > >>>> > >>>> mtx_unlock(&xroot->udev->bus->bus_mtx); > >>>> drop_bus++; > >>>> > >>>> } > >>>> > >>>> /* make sure that the transfer mutex is not locked */ > >>>> drop_xfer = 0; > >>>> while (mtx_owned(xroot->xfer_mtx)) { > >>>> > >>>> mtx_unlock(xroot->xfer_mtx); > >>>> drop_xfer++; > >>>> > >>>> } > >>>> > >>>> So many unconventional tricks. > >>> > >>> Similar code is used in the DROP_GIANT and PICKUP_GIANT macros. You > >>> might > >> > >> want > >> > >>> to check all references to mtx_owned() in the kernel, and make a set of > >>> exceptions for post-panic code execution. > >> > >> Giant is special because it is a hack to let us run non-MPSAFE code. > >> Other locks should not follow its model. > > > > Hans, > > > > actually this makes me wonder... It seems that usbd_transfer_poll() > > function that utilizes the above code is called from a number of > > xxx_poll routines in various usb drivers (ukbd, umass and a bunch of > > serial drivers): > > $ glimpse -l usbd_transfer_poll | fgrep .c > > /usr/src/sys/dev/usb/input/ukbd.c > > /usr/src/sys/dev/usb/usb_transfer.c > > /usr/src/sys/dev/usb/storage/umass.c > > /usr/src/sys/dev/usb/serial/ucycom.c > > /usr/src/sys/dev/usb/serial/umoscom.c > > /usr/src/sys/dev/usb/serial/umcs.c > > /usr/src/sys/dev/usb/serial/umodem.c > > /usr/src/sys/dev/usb/serial/uchcom.c > > /usr/src/sys/dev/usb/serial/uipaq.c > > /usr/src/sys/dev/usb/serial/ugensa.c > > /usr/src/sys/dev/usb/serial/uark.c > > /usr/src/sys/dev/usb/serial/ufoma.c > > /usr/src/sys/dev/usb/serial/umct.c > > /usr/src/sys/dev/usb/serial/ubsa.c > > /usr/src/sys/dev/usb/serial/uslcom.c > > /usr/src/sys/dev/usb/serial/uplcom.c > > /usr/src/sys/dev/usb/serial/uvscom.c > > /usr/src/sys/dev/usb/serial/uftdi.c > > /usr/src/sys/dev/usb/serial/ubser.c > > > > So why the mutex unwinding/rewinding code is present at all? > > What kind of situations is it supposed to prevent? > > > > Personally I think that we either know that those drivers should not hold > > the locks in question (bus_mtx and xfer_mtx) or we know that they hold > > them. I do not see why we have to be conditional here or have a loop > > even... > > Today, I think we know these things. In the past, as the code was written, > there was a lot more special case code needed for giant cohabitation. What Warner says is correct. The code was written when SCHEDULER_STOPPED() was not implemented. Really the usbd_transfer_poll should simply return if SCHEDULER_STOPPED() is not set. And then those mtx_unlock()/mtx_lock() cases can simply be removed. --HPS From owner-freebsd-arch@FreeBSD.ORG Wed Aug 31 18:18:35 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B57FD106567B; Wed, 31 Aug 2011 18:18:35 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe04.c2i.net [212.247.154.98]) by mx1.freebsd.org (Postfix) with ESMTP id 09CC08FC19; Wed, 31 Aug 2011 18:18:34 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=nSp/lo0FDChGKjONaW+LFp6gLzUQbrH1VOzHQZWpGes= c=1 sm=1 a=ni9ZY7ZFbhgA:10 a=WQU8e4WWZSUA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=-G6q7kbFCyEwIIUnyiIA:9 a=H_8iCRKF1ZwUWQpn-5AA:7 a=wPNLvfGTeEIA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe04.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 173083654; Wed, 31 Aug 2011 20:18:29 +0200 To: freebsd-arch@freebsd.org From: Hans Petter Selasky X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq,NwSZ4V" =?iso-8859-1?q?=7CLR=2E+tj=7Dg5=0A=09=25V?=,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( =?iso-8859-1?q?=0A=09=3AAuzV9=3A=2EhESm-x4h240C=609=3Dw?= Date: Wed, 31 Aug 2011 20:15:54 +0200 MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201108312015.54587.hselasky@c2i.net> Cc: Andriy Gapon Subject: Re: skipping locks, mutex_owned, usb X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 18:18:35 -0000 On Wednesday 31 August 2011 18:32:57 Warner Losh wrote: > On Aug 31, 2011, at 10:13 AM, Andriy Gapon wrote: > > on 31/08/2011 16:43 John Baldwin said the following: > >> On Sunday, August 28, 2011 5:27:44 am Hans Petter Selasky wrote: > >>> On Sunday 28 August 2011 11:25:51 Andriy Gapon wrote: > >>>> on 23/08/2011 15:09 Andriy Gapon said the following: > >>>>> This "XXX cludge" [sic] pattern is scattered around a few functions > >>>>> in the ukbd code and perhaps other usb code: > >>>>> func() > >>>>> { > >>>>> > >>>>> if (!mtx_owned(&Giant)) { > >>>>> > >>>>> mtx_lock(&Giant); > >>>>> > >>>>> func(); > >>>>> mtx_unlock(&Giant); > >>>>> > >>>>> return; > >>>>> > >>>>> } > >>>>> > >>>>> // etc ... > >>>>> > >>>>> } > >>>> > >>>> Ohhh, nothing seems simple with the USB code: > >>>> > >>>> /* make sure that the BUS mutex is not locked */ > >>>> drop_bus = 0; > >>>> while (mtx_owned(&xroot->udev->bus->bus_mtx)) { > >>>> > >>>> mtx_unlock(&xroot->udev->bus->bus_mtx); > >>>> drop_bus++; > >>>> > >>>> } > >>>> > >>>> /* make sure that the transfer mutex is not locked */ > >>>> drop_xfer = 0; > >>>> while (mtx_owned(xroot->xfer_mtx)) { > >>>> > >>>> mtx_unlock(xroot->xfer_mtx); > >>>> drop_xfer++; > >>>> > >>>> } > >>>> > >>>> So many unconventional tricks. > >>> > >>> Similar code is used in the DROP_GIANT and PICKUP_GIANT macros. You > >>> might > >> > >> want > >> > >>> to check all references to mtx_owned() in the kernel, and make a set of > >>> exceptions for post-panic code execution. > >> > >> Giant is special because it is a hack to let us run non-MPSAFE code. > >> Other locks should not follow its model. > > > > Hans, > > > > actually this makes me wonder... It seems that usbd_transfer_poll() > > function that utilizes the above code is called from a number of > > xxx_poll routines in various usb drivers (ukbd, umass and a bunch of > > serial drivers): > > $ glimpse -l usbd_transfer_poll | fgrep .c > > /usr/src/sys/dev/usb/input/ukbd.c > > /usr/src/sys/dev/usb/usb_transfer.c > > /usr/src/sys/dev/usb/storage/umass.c > > /usr/src/sys/dev/usb/serial/ucycom.c > > /usr/src/sys/dev/usb/serial/umoscom.c > > /usr/src/sys/dev/usb/serial/umcs.c > > /usr/src/sys/dev/usb/serial/umodem.c > > /usr/src/sys/dev/usb/serial/uchcom.c > > /usr/src/sys/dev/usb/serial/uipaq.c > > /usr/src/sys/dev/usb/serial/ugensa.c > > /usr/src/sys/dev/usb/serial/uark.c > > /usr/src/sys/dev/usb/serial/ufoma.c > > /usr/src/sys/dev/usb/serial/umct.c > > /usr/src/sys/dev/usb/serial/ubsa.c > > /usr/src/sys/dev/usb/serial/uslcom.c > > /usr/src/sys/dev/usb/serial/uplcom.c > > /usr/src/sys/dev/usb/serial/uvscom.c > > /usr/src/sys/dev/usb/serial/uftdi.c > > /usr/src/sys/dev/usb/serial/ubser.c > > > > So why the mutex unwinding/rewinding code is present at all? > > What kind of situations is it supposed to prevent? > > > > Personally I think that we either know that those drivers should not hold > > the locks in question (bus_mtx and xfer_mtx) or we know that they hold > > them. I do not see why we have to be conditional here or have a loop > > even... > > Today, I think we know these things. In the past, as the code was written, > there was a lot more special case code needed for giant cohabitation. What Warner says is correct. The code was written when SCHEDULER_STOPPED() was not implemented. Really the usbd_transfer_poll should simply return if SCHEDULER_STOPPED() is not set. And then those mtx_unlock()/mtx_lock() cases can simply be removed. --HPS From owner-freebsd-arch@FreeBSD.ORG Wed Aug 31 20:05:13 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8362D106566B for ; Wed, 31 Aug 2011 20:05:13 +0000 (UTC) (envelope-from vicmrml@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1E0678FC12 for ; Wed, 31 Aug 2011 20:05:12 +0000 (UTC) Received: by ewy1 with SMTP id 1so919091ewy.13 for ; Wed, 31 Aug 2011 13:05:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=owJ8etH0SlLW3j7swC2Fj5HUjJkbeVN19pbDU8nrQnA=; b=xpr4CvaOI8qn3t3uid6F/orlUIpA/kEdlOItLibdL+qlMPpDOYlk862g+fGW0UnzEb vmP9NtlYisV3JQcDeVLkl5k3cCthSbykmL+4F6vYgF7SEUGEbgVGKleawmYLPlx/R1u9 hGtYxrpHr433Mk4QanxgGWZDpSbcUg+8M/O04= Received: by 10.14.14.83 with SMTP id c59mr458965eec.180.1314819691984; Wed, 31 Aug 2011 12:41:31 -0700 (PDT) Received: from [127.0.0.1] ([188.123.241.56]) by mx.google.com with ESMTPS id r5sm159730eef.40.2011.08.31.12.41.30 (version=SSLv3 cipher=OTHER); Wed, 31 Aug 2011 12:41:31 -0700 (PDT) Message-ID: <4E5E8E69.1040506@gmail.com> Date: Wed, 31 Aug 2011 23:41:29 +0400 From: Victor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.20) Gecko/20110804 Thunderbird/3.1.12 MIME-Version: 1.0 To: freebsd-arch@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Privileged mode commands in FreeBSD processes X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 20:05:13 -0000 Is it possible to write and start a program in FreeBSD, which could execute processor commands of previleged modes (protection rings), commonly prohibited to a process in the user mode? For example we could permit the process direct access to i/o ports (IN and OUT commands on PC architecture), execution of the software interrupt command with any operand (INT), access to descriptor tables registers (GDT, LDT, etc.) with capability of changing content of both these registers and descriptor tables themselves (situated in the RAM). We could also allow the process to change flag bits in the registers of CPU, responsible for processor modes (memory addressing modes, transition from protected to real mode and vice versa, etc.) In fact, if this feature exists in FreeBSD, it must switch the processor for the time of execution this process to the mode with higher privileges (to the protection ring from 2 to 0, not 3 in x86). I would like to ask the FreeBSD community, does this possibility exist in FreeBSD? I understand the problem can be easily solved by deviding the program into two parts: the process (COFF or ELF file) and the driver. All the code, containing privileged commands, could be placed in the driver, as the rest of the code (its unprivileged part) could be contained in the process. As far as I understand, the driver code is executed in the 0 ring mode, so it has no restrictions. On the other hand it would be interesting to have such an opportunity for common processes in both educational (e. g. studying assembler privileged mode commands) and technical purposes. Of course this feature is a great threat for system safety, and besides programs, using it, can easily completely destroy the system, however it could be useful for some aims. Does anything of such kind exist in FreeBSD? If it does, please give me a reference in the FreeBSD documentation. Victor. From owner-freebsd-arch@FreeBSD.ORG Wed Aug 31 20:26:44 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79B5A1065673 for ; Wed, 31 Aug 2011 20:26:44 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 6B8728FC13 for ; Wed, 31 Aug 2011 20:26:44 +0000 (UTC) Received: by elvis.mu.org (Postfix, from userid 1192) id 445F51A3C46; Wed, 31 Aug 2011 13:10:33 -0700 (PDT) Date: Wed, 31 Aug 2011 13:10:33 -0700 From: Alfred Perlstein To: Victor Message-ID: <20110831201032.GT19022@elvis.mu.org> References: <4E5E8E69.1040506@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E5E8E69.1040506@gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-arch@freebsd.org Subject: Re: Privileged mode commands in FreeBSD processes X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 20:26:44 -0000 You can see i386_get_ldt(2) and io(4) manpages. More privileged opcodes can not be used afaik. * Victor [110831 13:05] wrote: > Is it possible to write and start a program in FreeBSD, which could > execute processor commands of previleged modes (protection rings), > commonly prohibited to a process in the user mode? > > For example we could permit the process direct access to i/o ports (IN > and OUT commands on PC architecture), execution of the software > interrupt command with any operand (INT), access to descriptor tables > registers (GDT, LDT, etc.) with capability of changing content of both > these registers and descriptor tables themselves (situated in the RAM). > We could also allow the process to change flag bits in the registers of > CPU, responsible for processor modes (memory addressing modes, > transition from protected to real mode and vice versa, etc.) In fact, if > this feature exists in FreeBSD, it must switch the processor for the > time of execution this process to the mode with higher privileges (to > the protection ring from 2 to 0, not 3 in x86). I would like to ask the > FreeBSD community, does this possibility exist in FreeBSD? > > I understand the problem can be easily solved by deviding the program > into two parts: the process (COFF or ELF file) and the driver. All the > code, containing privileged commands, could be placed in the driver, as > the rest of the code (its unprivileged part) could be contained in the > process. As far as I understand, the driver code is executed in the 0 > ring mode, so it has no restrictions. On the other hand it would be > interesting to have such an opportunity for common processes in both > educational (e. g. studying assembler privileged mode commands) and > technical purposes. Of course this feature is a great threat for system > safety, and besides programs, using it, can easily completely destroy > the system, however it could be useful for some aims. > > Does anything of such kind exist in FreeBSD? If it does, please give me > a reference in the FreeBSD documentation. > > Victor. > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" -- - Alfred Perlstein .- VMOA #5191, 03 vmax, 92 gs500, 85 ch250, 07 zx10 .- FreeBSD committer From owner-freebsd-arch@FreeBSD.ORG Wed Aug 31 21:06:45 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 43627106564A for ; Wed, 31 Aug 2011 21:06:45 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id D64738FC0A for ; Wed, 31 Aug 2011 21:06:44 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p7VL6fWD042639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Sep 2011 00:06:41 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p7VL6faB053349; Thu, 1 Sep 2011 00:06:41 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p7VL6fbO053348; Thu, 1 Sep 2011 00:06:41 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 1 Sep 2011 00:06:41 +0300 From: Kostik Belousov To: Victor Message-ID: <20110831210641.GJ17489@deviant.kiev.zoral.com.ua> References: <4E5E8E69.1040506@gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YLpLhS3O5DfP4FSt" Content-Disposition: inline In-Reply-To: <4E5E8E69.1040506@gmail.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-arch@freebsd.org Subject: Re: Privileged mode commands in FreeBSD processes X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 21:06:45 -0000 --YLpLhS3O5DfP4FSt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 31, 2011 at 11:41:29PM +0400, Victor wrote: > Is it possible to write and start a program in FreeBSD, which could=20 > execute processor commands of previleged modes (protection rings),=20 > commonly prohibited to a process in the user mode? >=20 > For example we could permit the process direct access to i/o ports (IN=20 > and OUT commands on PC architecture), execution of the software=20 > interrupt command with any operand (INT), access to descriptor tables=20 > registers (GDT, LDT, etc.) with capability of changing content of both=20 > these registers and descriptor tables themselves (situated in the RAM). = =20 > We could also allow the process to change flag bits in the registers of= =20 > CPU, responsible for processor modes (memory addressing modes,=20 > transition from protected to real mode and vice versa, etc.) In fact, if= =20 > this feature exists in FreeBSD, it must switch the processor for the=20 > time of execution this process to the mode with higher privileges (to=20 > the protection ring from 2 to 0, not 3 in x86). I would like to ask the= =20 > FreeBSD community, does this possibility exist in FreeBSD? >=20 > I understand the problem can be easily solved by deviding the program=20 > into two parts: the process (COFF or ELF file) and the driver. All the=20 > code, containing privileged commands, could be placed in the driver, as= =20 > the rest of the code (its unprivileged part) could be contained in the=20 > process. As far as I understand, the driver code is executed in the 0=20 > ring mode, so it has no restrictions. On the other hand it would be=20 > interesting to have such an opportunity for common processes in both=20 > educational (e. g. studying assembler privileged mode commands) and=20 > technical purposes. Of course this feature is a great threat for system= =20 > safety, and besides programs, using it, can easily completely destroy=20 > the system, however it could be useful for some aims. >=20 > Does anything of such kind exist in FreeBSD? If it does, please give me= =20 > a reference in the FreeBSD documentation. You can try to jump into userspace address from the ring 0 (kernel) mode, but there are several reasons already why it will not work on x86 now, and there will be more reasons why it will not work in the future. Kernel often uses the ring bits of the saved %cs to distinguish the source of the trap as being user or kernel mode. This would prevent any trap from being correctly handled by kernel, if the trap happens in this mode of execution. You probably need to wire all the pages that can be accessed by this mode, but other traps cannot be eliminated that easy. Newest Intel CPUs has so-called SMEP facility, that disables execution in ring 0 from any page that has ring-3 access enabled. That will prevent the future exploits and your mode from working. --YLpLhS3O5DfP4FSt Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk5eomAACgkQC3+MBN1Mb4jvcwCfZ28JmHuDYimhlYaTHOPPszeB kFoAoJSBcxaGEvr6QRWrKADRGldrznTu =2Pc9 -----END PGP SIGNATURE----- --YLpLhS3O5DfP4FSt-- From owner-freebsd-arch@FreeBSD.ORG Thu Sep 1 00:12:53 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8E7D106566B; Thu, 1 Sep 2011 00:12:53 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (unknown [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id A74D68FC13; Thu, 1 Sep 2011 00:12:53 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id p810CoVT075138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 31 Aug 2011 17:12:53 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id p810CoZ9075137; Wed, 31 Aug 2011 17:12:50 -0700 (PDT) Received: from fbsd81 ([192.168.200.81]) by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA26348; Wed, 31 Aug 11 17:03:07 PDT Date: Thu, 01 Sep 2011 00:03:02 -0700 From: perryh@pluto.rain.com To: fullermd@over-yonder.net Message-Id: <4e5f2e26.6PQ5d6F3eauFfAcH%perryh@pluto.rain.com> References: <4e5ba9c3.bzHIw1KEy8R2QcK7%perryh@pluto.rain.com> <3420B331-C697-468A-80BA-B31C33804710@freebsd.org> <4e5c5b5f.moT7dLemOuteQJ5T%perryh@pluto.rain.com> <4E5C364D.7070904@freebsd.org> <20110830201357.GB58638@acme.spoerlein.net> <4e5e458a.Un+VK0itRgItvxbf%perryh@pluto.rain.com> <20110831081815.GN2493@over-yonder.net> In-Reply-To: <20110831081815.GN2493@over-yonder.net> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: uqs@spoerlein.net, kmacy@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Official git export X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2011 00:12:54 -0000 "Matthew D. Fuller" wrote: > On Wed, Aug 31, 2011 at 07:30:34AM -0700 I heard the voice of > perryh@pluto.rain.com, and lo! it spake thus: > > Surely it would be "noticeably faster" to _download_ only (say) > > /usr/src/sys than all of /usr/src, unless one has an uncommonly > > fast link? (It would also impose less load on the serving site.) > > In the context of most current-gen DVCSen, it's unlikely to be much > (or in fact _any_) faster or less data to transfer. It's just less > data to blat into the working tree. That makes a certain amount of sense _if_ the VCS considers the entire base system to reside in a single repository, which is why someone was suggesting splitting it into multiple repositories. The question remains: does it really make sense that I must download the entire VCS history for things like cddl, contrib, crypto, games, and kerberos if I only plan to work on the kernel? From owner-freebsd-arch@FreeBSD.ORG Thu Sep 1 01:13:21 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 332741065670 for ; Thu, 1 Sep 2011 01:13:21 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id E01318FC12 for ; Thu, 1 Sep 2011 01:13:20 +0000 (UTC) Received: by qyk9 with SMTP id 9so993439qyk.13 for ; Wed, 31 Aug 2011 18:13:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=dfCZWrdd0UFqnXzvfAnw7QIOalM0cW+qvEcwMf+wgMc=; b=aMCm+1iGBgzHE87vQN0s2K83eXKkxjmzc3Pnqj1CjUukx0WnAlAeLGKGH6OqgQAsG5 ckdZYCWjMv6FeYjHrSw3QJYp0tRhZrlTJRQsyqhxjr8nBEprUwcPs/Jkx9jRcNJwsKud 2p1JVNaZhIOzjPDC4ocLkZ62ZSjETrtpm3WRc= MIME-Version: 1.0 Received: by 10.224.191.202 with SMTP id dn10mr935420qab.42.1314839600052; Wed, 31 Aug 2011 18:13:20 -0700 (PDT) Received: by 10.224.37.83 with HTTP; Wed, 31 Aug 2011 18:13:19 -0700 (PDT) In-Reply-To: <4e5f2e26.6PQ5d6F3eauFfAcH%perryh@pluto.rain.com> References: <4e5ba9c3.bzHIw1KEy8R2QcK7%perryh@pluto.rain.com> <3420B331-C697-468A-80BA-B31C33804710@freebsd.org> <4e5c5b5f.moT7dLemOuteQJ5T%perryh@pluto.rain.com> <4E5C364D.7070904@freebsd.org> <20110830201357.GB58638@acme.spoerlein.net> <4e5e458a.Un+VK0itRgItvxbf%perryh@pluto.rain.com> <20110831081815.GN2493@over-yonder.net> <4e5f2e26.6PQ5d6F3eauFfAcH%perryh@pluto.rain.com> Date: Wed, 31 Aug 2011 18:13:19 -0700 Message-ID: From: Garrett Cooper To: perryh@pluto.rain.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: uqs@spoerlein.net, kmacy@freebsd.org, fullermd@over-yonder.net, freebsd-arch@freebsd.org Subject: Re: Official git export X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2011 01:13:21 -0000 On Thu, Sep 1, 2011 at 12:03 AM, wrote: > "Matthew D. Fuller" wrote: >> On Wed, Aug 31, 2011 at 07:30:34AM -0700 I heard the voice of >> perryh@pluto.rain.com, and lo! it spake thus: >> > Surely it would be "noticeably faster" to _download_ only (say) >> > /usr/src/sys than all of /usr/src, unless one has an uncommonly >> > fast link? =A0(It would also impose less load on the serving site.) >> >> In the context of most current-gen DVCSen, it's unlikely to be much >> (or in fact _any_) faster or less data to transfer. =A0It's just less >> data to blat into the working tree. > > That makes a certain amount of sense _if_ the VCS considers the > entire base system to reside in a single repository, which is why > someone was suggesting splitting it into multiple repositories. > > The question remains: =A0does it really make sense that I must download > the entire VCS history for things like cddl, contrib, crypto, games, > and kerberos if I only plan to work on the kernel? Which is part of the point of modularized (aka componentized by some groups) VCSs. The problem is that you push revisioning // management of the VCSs into components, which might carry its own set of problems when you update revisions of components and there's a ripple effect with what needs to be updated across all components (which in and of itself becomes a management nightmare). Thanks! -Garrett From owner-freebsd-arch@FreeBSD.ORG Thu Sep 1 05:06:41 2011 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C0D71066F39 for ; Thu, 1 Sep 2011 05:06:27 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 1E02D8FC08 for ; Thu, 1 Sep 2011 05:06:25 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id IAA01831; Thu, 01 Sep 2011 08:06:01 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1QyzTV-000BAK-Bb; Thu, 01 Sep 2011 08:06:01 +0300 Message-ID: <4E5F12B6.3090307@FreeBSD.org> Date: Thu, 01 Sep 2011 08:05:58 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0) Gecko/20110830 Thunderbird/6.0 MIME-Version: 1.0 To: perryh@pluto.rain.com References: <4e5ba9c3.bzHIw1KEy8R2QcK7%perryh@pluto.rain.com> <3420B331-C697-468A-80BA-B31C33804710@freebsd.org> <4e5c5b5f.moT7dLemOuteQJ5T%perryh@pluto.rain.com> <4E5C364D.7070904@freebsd.org> <20110830201357.GB58638@acme.spoerlein.net> <4e5e458a.Un+VK0itRgItvxbf%perryh@pluto.rain.com> <20110831081815.GN2493@over-yonder.net> <4e5f2e26.6PQ5d6F3eauFfAcH%perryh@pluto.rain.com> In-Reply-To: <4e5f2e26.6PQ5d6F3eauFfAcH%perryh@pluto.rain.com> X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: uqs@spoerlein.net, kmacy@FreeBSD.org, fullermd@over-yonder.net, freebsd-arch@FreeBSD.org Subject: Re: Official git export X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2011 05:06:41 -0000 on 01/09/2011 10:03 perryh@pluto.rain.com said the following: > "Matthew D. Fuller" wrote: >> On Wed, Aug 31, 2011 at 07:30:34AM -0700 I heard the voice of >> perryh@pluto.rain.com, and lo! it spake thus: >>> Surely it would be "noticeably faster" to _download_ only (say) >>> /usr/src/sys than all of /usr/src, unless one has an uncommonly >>> fast link? (It would also impose less load on the serving site.) >> >> In the context of most current-gen DVCSen, it's unlikely to be much >> (or in fact _any_) faster or less data to transfer. It's just less >> data to blat into the working tree. > > That makes a certain amount of sense _if_ the VCS considers the > entire base system to reside in a single repository, which is why > someone was suggesting splitting it into multiple repositories. > > The question remains: does it really make sense that I must download > the entire VCS history for things like cddl, contrib, crypto, games, > and kerberos if I only plan to work on the kernel? As surprising as it may sound to you, in my opinion, the answer is closer to yes than to no. - try cross-building your kernel changes for different arch(es); you'd be surprised how much you would need for kernel-toolchain from contrib or even games - make changes to anything that interfaces with userland and you'd find yourself needing to change the userland counter-parts and to build world - test your changes by booting your kernel and world - etc :) Not everything is needed from userland bits, of course, and history may be not as useful as the source code itself, but once you need some bits from userland it's hard to separate them. In any case you can run an experiment yourself - do a partial checkout from current svn repository, say only sys subdir, and then try to do anything useful with that and you will see for yourself. -- Andriy Gapon From owner-freebsd-arch@FreeBSD.ORG Thu Sep 1 05:52:51 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B73961065670 for ; Thu, 1 Sep 2011 05:52:51 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (pancho.soaustin.net [76.74.250.40]) by mx1.freebsd.org (Postfix) with ESMTP id 98CC78FC1E for ; Thu, 1 Sep 2011 05:52:51 +0000 (UTC) Received: by mail.soaustin.net (Postfix, from userid 502) id D52985615B; Thu, 1 Sep 2011 00:52:50 -0500 (CDT) Date: Thu, 1 Sep 2011 00:52:50 -0500 From: Mark Linimon To: Vadim Goncharov Message-ID: <20110901055250.GK3376@lonesome.com> References: <20110819154638.GA75879@over-yonder.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-arch@freebsd.org Subject: Re: FreeBSD problems/solutions: voting system & marketing surveys X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2011 05:52:51 -0000 On Wed, Aug 24, 2011 at 09:52:58PM +0000, Vadim Goncharov wrote: > The possible solution is: a developer and company agree privately, then > a company donates needed sum to Foundation, and developer signs contract with > Foundation for the project as usual, just the sum is known to developer as > befor. Foundation does not need to know anything about developer/company > relationship here. My understanding of American law governing non-profits is: they can't do that without risking their non-profit status. > At the very last, if that couldn't be solved with Foundation at all, it is > possible to do alternative solution: a web page (subdomain of freebsd.org?) > where ideas and tasks are sorted by priority, there are listed customers > and volunteers for each, may be price, and of course contacts: way for them > to meet and be paid outside I've hoped that someone independent from the project would step up and do this for many years. Several people have shown an interest, but nothing has ever happened. Perhaps you can finally be the one to make it happen? mcl From owner-freebsd-arch@FreeBSD.ORG Thu Sep 1 07:27:09 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7A74106566B for ; Thu, 1 Sep 2011 07:27:09 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (pancho.soaustin.net [76.74.250.40]) by mx1.freebsd.org (Postfix) with ESMTP id 86C428FC12 for ; Thu, 1 Sep 2011 07:27:09 +0000 (UTC) Received: by mail.soaustin.net (Postfix, from userid 502) id DAFAD5615B; Thu, 1 Sep 2011 02:27:08 -0500 (CDT) Date: Thu, 1 Sep 2011 02:27:08 -0500 From: Mark Linimon To: Alex Goncharov Message-ID: <20110901072708.GL3376@lonesome.com> References: <20110830082328.GB8085@lonesome.com> <20110831002621.GA24932@lonesome.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-arch@freebsd.org Subject: Re: FreeBSD problems and preliminary ways to solve X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2011 07:27:09 -0000 On Tue, Aug 30, 2011 at 08:44:36PM -0400, Alex Goncharov wrote: > You may find this discussion useful: > > http://mail-index.netbsd.org/netbsd-users/2011/08/04/msg008743.html > > (referencing probably the most appropriate message in the thread.) I've gone ahead and put a cross-reference to this into the following wiki page: http://wiki.freebsd.org/PackageSystemsFeatureComparison (It turns out that this information already existed in the wiki but buried in another page, so I created this new page.) That page needs to be updated. I welcome any help to do so. mcl From owner-freebsd-arch@FreeBSD.ORG Thu Sep 1 08:11:32 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 88935106566C; Thu, 1 Sep 2011 08:11:32 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id 5FEEC8FC13; Thu, 1 Sep 2011 08:11:32 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id p818BQBW018859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Sep 2011 01:11:31 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id p818BQwW018858; Thu, 1 Sep 2011 01:11:26 -0700 (PDT) Received: from fbsd81 ([192.168.200.81]) by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA27699; Thu, 1 Sep 11 01:08:56 PDT Date: Thu, 01 Sep 2011 08:08:49 -0700 From: perryh@pluto.rain.com To: avg@freebsd.org Message-Id: <4e5fa001.BTxOKlcJfp7aZ2KE%perryh@pluto.rain.com> References: <4e5ba9c3.bzHIw1KEy8R2QcK7%perryh@pluto.rain.com> <3420B331-C697-468A-80BA-B31C33804710@freebsd.org> <4e5c5b5f.moT7dLemOuteQJ5T%perryh@pluto.rain.com> <4E5C364D.7070904@freebsd.org> <20110830201357.GB58638@acme.spoerlein.net> <4e5e458a.Un+VK0itRgItvxbf%perryh@pluto.rain.com> <20110831081815.GN2493@over-yonder.net> <4e5f2e26.6PQ5d6F3eauFfAcH%perryh@pluto.rain.com> <4E5F12B6.3090307@FreeBSD.org> In-Reply-To: <4E5F12B6.3090307@FreeBSD.org> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: uqs@spoerlein.net, kmacy@freebsd.org, fullermd@over-yonder.net, freebsd-arch@freebsd.org Subject: Re: Official git export X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2011 08:11:32 -0000 Andriy Gapon wrote: > on 01/09/2011 10:03 perryh@pluto.rain.com said the following: > > "Matthew D. Fuller" wrote: > >> On Wed, Aug 31, 2011 at 07:30:34AM -0700 I heard the voice of > >> perryh@pluto.rain.com, and lo! it spake thus: > >>> Surely it would be "noticeably faster" to _download_ only (say) > >>> /usr/src/sys than all of /usr/src, unless one has an uncommonly > >>> fast link? (It would also impose less load on the serving site.) > >> > >> In the context of most current-gen DVCSen, it's unlikely to be > >> much (or in fact _any_) faster or less data to transfer. It's > >> just less data to blat into the working tree. > > > > That makes a certain amount of sense _if_ the VCS considers the > > entire base system to reside in a single repository, which is why > > someone was suggesting splitting it into multiple repositories. > > > > The question remains: does it really make sense that I must > > download the entire VCS history for things like cddl, contrib, > > crypto, games, and kerberos if I only plan to work on the kernel? > > As surprising as it may sound to you, in my opinion, the answer is > closer to yes than to no. > [snip mention of building kernel-toolchain and userland for testing] > > Not everything is needed from userland bits, of course, and > history may be not as useful as the source code itself, but once > you need some bits from userland it's hard to separate them. I don't doubt that one needs to have (whatever version of) the whole source tree, but that was presumably installed from the distribution ISO and kept up to date via csup. I see little point in downloading it all _again_ just to get VCS history -- and ability to check out, branch, etc -- for areas that one doesn't plan to touch. That's why I referred specifically to downloading "the entire VCS history" of such parts. And yes, depending on what part(s) of the kernel I'm working on, I may indeed need to touch some userland code. That still doesn't explain why I should have to import VCS awareness of code that I'm _not_ modifying. From owner-freebsd-arch@FreeBSD.ORG Thu Sep 1 08:53:35 2011 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5450106566B for ; Thu, 1 Sep 2011 08:53:35 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id E643D8FC16 for ; Thu, 1 Sep 2011 08:53:34 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA05025; Thu, 01 Sep 2011 11:53:28 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4E5F4807.6070206@FreeBSD.org> Date: Thu, 01 Sep 2011 11:53:27 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110705 Thunderbird/5.0 MIME-Version: 1.0 To: perryh@pluto.rain.com References: <4e5ba9c3.bzHIw1KEy8R2QcK7%perryh@pluto.rain.com> <3420B331-C697-468A-80BA-B31C33804710@freebsd.org> <4e5c5b5f.moT7dLemOuteQJ5T%perryh@pluto.rain.com> <4E5C364D.7070904@freebsd.org> <20110830201357.GB58638@acme.spoerlein.net> <4e5e458a.Un+VK0itRgItvxbf%perryh@pluto.rain.com> <20110831081815.GN2493@over-yonder.net> <4e5f2e26.6PQ5d6F3eauFfAcH%perryh@pluto.rain.com> <4E5F12B6.3090307@FreeBSD.org> <4e5fa001.BTxOKlcJfp7aZ2KE%perryh@pluto.rain.com> In-Reply-To: <4e5fa001.BTxOKlcJfp7aZ2KE%perryh@pluto.rain.com> X-Enigmail-Version: 1.2pre Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-arch@FreeBSD.org Subject: Re: Official git export X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2011 08:53:35 -0000 on 01/09/2011 18:08 perryh@pluto.rain.com said the following: > I don't doubt that one needs to have (whatever version of) the whole > source tree, but that was presumably installed from the distribution > ISO and kept up to date via csup. I see little point in downloading > it all _again_ just to get VCS history -- and ability to check out, > branch, etc -- for areas that one doesn't plan to touch. That's why > I referred specifically to downloading "the entire VCS history" of > such parts. > > And yes, depending on what part(s) of the kernel I'm working on, > I may indeed need to touch some userland code. That still doesn't > explain why I should have to import VCS awareness of code that I'm > _not_ modifying. It looks like you speak too theoretically. Try doing some non-trivial development and see for yourself. I am sure that keeping parts of the tree checked out via svn and parts updated via csup and then using that all together will be very convenient and a lot of fun. Yeah, and keeping local history is of course not necessary, but when you need to do some serious history analysis it comes extremely convenient. And it costs nothing by today's standards (few hundred MB is nothing for a development environment). So, sorry, doing some non-trivial FreeBSD development myself I do not buy your arguments. -- Andriy Gapon From owner-freebsd-arch@FreeBSD.ORG Thu Sep 1 12:51:01 2011 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 772351065672; Thu, 1 Sep 2011 12:51:01 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 567218FC13; Thu, 1 Sep 2011 12:51:00 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA02083; Thu, 01 Sep 2011 15:50:54 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4E5F7FAE.20503@FreeBSD.org> Date: Thu, 01 Sep 2011 15:50:54 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110705 Thunderbird/5.0 MIME-Version: 1.0 To: Warner Losh , Hans Petter Selasky References: <4E53986B.5000804@FreeBSD.org> <4E5A099F.4060903@FreeBSD.org> <201108281127.44696.hselasky@freebsd.org> <201108310943.24476.jhb@freebsd.org> <4E5E5DA0.4060003@FreeBSD.org> <4E5E655E.8060505@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.2pre Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: John Baldwin , freebsd-arch@FreeBSD.org Subject: Re: skipping locks, mutex_owned, usb X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2011 12:51:01 -0000 on 31/08/2011 19:59 Warner Losh said the following: > There were situations where the USB would have a lock held, then need to call > into code that picked up GIANT which then called back into the USB stack which > then would pick up GIANT and make calls to routines to pickup the USB lock, and > fail due to recursion (or was that to prevent a witness warning about sleeping > with malloc, it has been a while and I don't recall for sure). I'm sure I'm > forgetting a detail or two because re-reading what I just wrote makes me go > "what, that doesn't sound quite right" :) Yeah :-) In a sense that that particular code to which I referred is only called by *_poll routines in a few a drivers. And it's hard for me to imagine how a call from USB would go all the around to a poll routine and then back into USB. Or how a poll call into USB would get out of USB and back into the calling subsystem. Anyway, I think there could have been (or even - is) a legitimate reason to have that code. And I can really believe that that reason may have to do with our current state of panic(9) code where we do not stop other CPUs. I am glad with the reply from Hans that the code can be simplified. -- Andriy Gapon From owner-freebsd-arch@FreeBSD.ORG Thu Sep 1 13:53:42 2011 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D73B1106564A for ; Thu, 1 Sep 2011 13:53:42 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 289CB8FC0A for ; Thu, 1 Sep 2011 13:53:41 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA03108; Thu, 01 Sep 2011 16:53:37 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4E5F8E61.7090701@FreeBSD.org> Date: Thu, 01 Sep 2011 16:53:37 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110705 Thunderbird/5.0 MIME-Version: 1.0 To: Hans Petter Selasky References: <201108312015.54587.hselasky@c2i.net> In-Reply-To: <201108312015.54587.hselasky@c2i.net> X-Enigmail-Version: 1.2pre Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-arch@FreeBSD.org Subject: Re: skipping locks, mutex_owned, usb X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2011 13:53:42 -0000 on 31/08/2011 21:15 Hans Petter Selasky said the following: > What Warner says is correct. The code was written when SCHEDULER_STOPPED() was > not implemented. Really the usbd_transfer_poll should simply return if > SCHEDULER_STOPPED() is not set. Rather than simply return I would instead KASSERT that either kdb_active or SCHEDULER_STOPPED(). > And then those mtx_unlock()/mtx_lock() cases > can simply be removed. Yep. So for now I simply removed those: [wip] usb_transfer: adapt for SCHEDULER_STOPPED() - remove unneeded dropping of locks - check SCHEDULER_STOPPED along with mutex_owned() which may be unreliable after panic Maybe to do: KASSERT that usbd_transfer_poll is called only when kdb_active or SCHEDULER_STOPPED diff --git a/sys/dev/usb/usb_transfer.c b/sys/dev/usb/usb_transfer.c index d4c2408..ef50dc4 100644 --- a/sys/dev/usb/usb_transfer.c +++ b/sys/dev/usb/usb_transfer.c @@ -2150,7 +2150,7 @@ usbd_callback_wrapper(struct usb_xfer_queue *pq) struct usb_xfer_root *info = xfer->xroot; USB_BUS_LOCK_ASSERT(info->bus, MA_OWNED); - if (!mtx_owned(info->xfer_mtx)) { + if (!SCHEDULER_STOPPED() && !mtx_owned(info->xfer_mtx)) { /* * Cases that end up here: * @@ -3094,8 +3094,6 @@ usbd_transfer_poll(struct usb_xfer **ppxfer, uint16_t max) struct usb_device *udev; struct usb_proc_msg *pm; uint16_t n; - uint16_t drop_bus; - uint16_t drop_xfer; for (n = 0; n != max; n++) { /* Extra checks to avoid panic */ @@ -3115,20 +3113,6 @@ usbd_transfer_poll(struct usb_xfer **ppxfer, uint16_t max) if (udev->bus->methods->xfer_poll == NULL) continue; /* no poll method */ - /* make sure that the BUS mutex is not locked */ - drop_bus = 0; - while (mtx_owned(&xroot->udev->bus->bus_mtx)) { - mtx_unlock(&xroot->udev->bus->bus_mtx); - drop_bus++; - } - - /* make sure that the transfer mutex is not locked */ - drop_xfer = 0; - while (mtx_owned(xroot->xfer_mtx)) { - mtx_unlock(xroot->xfer_mtx); - drop_xfer++; - } - /* Make sure cv_signal() and cv_broadcast() is not called */ udev->bus->control_xfer_proc.up_msleep = 0; udev->bus->explore_proc.up_msleep = 0; @@ -3157,14 +3141,6 @@ usbd_transfer_poll(struct usb_xfer **ppxfer, uint16_t max) (pm->pm_callback) (pm); USB_BUS_UNLOCK(xroot->bus); - - /* restore transfer mutex */ - while (drop_xfer--) - mtx_lock(xroot->xfer_mtx); - - /* restore BUS mutex */ - while (drop_bus--) - mtx_lock(&xroot->udev->bus->bus_mtx); } } -- Andriy Gapon From owner-freebsd-arch@FreeBSD.ORG Thu Sep 1 17:28:07 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F41C1065686 for ; Thu, 1 Sep 2011 17:28:07 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-qw0-f49.google.com (mail-qw0-f49.google.com [209.85.216.49]) by mx1.freebsd.org (Postfix) with ESMTP id C02948FC23 for ; Thu, 1 Sep 2011 17:28:06 +0000 (UTC) Received: by qwi2 with SMTP id 2so1438840qwi.8 for ; Thu, 01 Sep 2011 10:28:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=bNotOEBmmDuaOQVFnG6V9ILrMyQgzoKqP6ZgjcXAdcY=; b=U/ApdwbdJp66jotMNkQ7ctasJusOA4QirlH4t6W1E+kHlP26fWoaetbzlK4abfY6W3 o0iUac36p9aN6xtmQ3rpRwjrCLvRCZq0NTWj0tsbO6kuCFt6n5rMdAhJuUI/ebviuuYZ TPn2q6Vfgm2NOlGzBJkG0XlBbYEPoivpTrom4= MIME-Version: 1.0 Received: by 10.224.218.132 with SMTP id hq4mr70460qab.192.1314898086016; Thu, 01 Sep 2011 10:28:06 -0700 (PDT) Received: by 10.224.37.83 with HTTP; Thu, 1 Sep 2011 10:28:05 -0700 (PDT) In-Reply-To: References: <20110819154638.GA75879@over-yonder.net> Date: Thu, 1 Sep 2011 10:28:05 -0700 Message-ID: From: Garrett Cooper To: vadim_nuclight@mail.ru Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arch@freebsd.org Subject: Re: FreeBSD problems/solutions: voting system & marketing surveys X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2011 17:28:07 -0000 On Wed, Aug 24, 2011 at 2:52 PM, Vadim Goncharov w= rote: > Hi Matthew D. Fuller! > > On Fri, 19 Aug 2011 10:46:38 -0500; Matthew D. Fuller wrote about 'Re: Fr= eeBSD problems/solutions: voting system & marketing surveys': > >>> =A0 In other words, Foundation must act as an intermediate party >>> =A0 between those who will work and those who will pay for concrete >>> =A0 tasks set up by e.g. core@ or by user suggestions/need. >>> >>> Why it was not done earlier? >> Actually, it's my understanding that there are significant legal >> issues which prevent the Foundation from acting in this way (taking >> targetted donations, acting as an escrow party on specific bounties). > > If that is the only issue, there must be workaround for this. Circumventi= ng > such legal stoppers for good things is what lawyers are paid for. > > But I am from other country and don't know American law, that is task for > someone living in USA. > > The possible solution is: a developer and company agree privately, then > a company donates needed sum to Foundation, and developer signs contract = with > Foundation for the project as usual, just the sum is known to developer a= s > befor. Foundation does not need to know anything about developer/company > relationship here. > > At the very last, if that couldn't be solved with Foundation at all, it i= s > possible to do alternative solution: a web page (subdomain of freebsd.org= ?) > where ideas and tasks are sorted by priority, there are listed customers > and volunteers for each, may be price, and of course contacts: way for th= em > to meet and be paid outside Contract work (what's being described above) can be done through commercial entities like iXsystems: http://www.ixsystems.com/bsdsupport . Thanks! -Garrett From owner-freebsd-arch@FreeBSD.ORG Sat Sep 3 05:14:19 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 20240106564A; Sat, 3 Sep 2011 05:14:19 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id B13198FC0A; Sat, 3 Sep 2011 05:14:18 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id p835EGAm051679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 2 Sep 2011 22:14:17 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id p835EGk7051678; Fri, 2 Sep 2011 22:14:16 -0700 (PDT) Received: from fbsd81 ([192.168.200.81]) by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA05650; Fri, 2 Sep 11 22:11:15 PDT Date: Sat, 03 Sep 2011 05:11:07 -0700 From: perryh@pluto.rain.com To: avg@freebsd.org Message-Id: <4e62195b.cdaZfeF621ojSqVQ%perryh@pluto.rain.com> References: <4e5ba9c3.bzHIw1KEy8R2QcK7%perryh@pluto.rain.com> <3420B331-C697-468A-80BA-B31C33804710@freebsd.org> <4e5c5b5f.moT7dLemOuteQJ5T%perryh@pluto.rain.com> <4E5C364D.7070904@freebsd.org> <20110830201357.GB58638@acme.spoerlein.net> <4e5e458a.Un+VK0itRgItvxbf%perryh@pluto.rain.com> <20110831081815.GN2493@over-yonder.net> <4e5f2e26.6PQ5d6F3eauFfAcH%perryh@pluto.rain.com> <4E5F12B6.3090307@FreeBSD.org> <4e5fa001.BTxOKlcJfp7aZ2KE%perryh@pluto.rain.com> <4E5F4807.6070206@FreeBSD.org> In-Reply-To: <4E5F4807.6070206@FreeBSD.org> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: Official git export X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Sep 2011 05:14:19 -0000 Andriy Gapon wrote: > ... keeping local history is of course not necessary, but when > you need to do some serious history analysis it comes extremely > convenient. In the area where one is working, certainly, but I don't expect to need the commit history of the contrib tree while working on UFS or gmirror. > few hundred MB is nothing for a development environment. A few hundred MB of disk space is nothing. Having to _download_ a few hundred MB of source code, that one already has, is _not_ "nothing" unless one has a rather large pipe. I'm not the first to raise this point: http://lists.freebsd.org/pipermail/freebsd-arch/2011-August/011595.html http://lists.freebsd.org/pipermail/freebsd-arch/2011-August/011605.html One way to mitigate this would be to provide the ability to download and install VCS metadata (back-deltas, commit comments, etc.) for particular files and directories "as needed". If that level of granularity is problematic, just splitting the metadata into 5 groups would help: group contents size * infrastructure all files directly in /usr/src; and 66 MB subdirs etc, include, lib, libexec, release, rescue, share, tools. contrib /usr/src/contrib 232 MB crypto /usr/src/{crypto,kerberos5,secure} 40 MB kernel /usr/src/sys 143 MB other /usr/src/{bin,cddl,games,gnu, 50 MB sbin,usr.bin,usr.sbin} * size of /usr/src/... reported by "du -s" in 8.1. This is the size of the code, not including any VCS metadata, but it seems likely to give a reasonable idea of the relative metadata sizes (i.e. the size of a group's metadata will be -- very roughly -- proportional to the size of its code). For that matter, FreeBSD could provide the VCS metadata corresponding to each release as a separate ISO, so those who need it can obtain and install it. Those for whom large downloads are a problem could buy it on CD. > ... doing some non-trivial FreeBSD development myself ... Unless you're considerably older than you look in that Flickr photo from about a year ago (in Kiev), I was doing non-trivial OS development before you finished middle school :) From owner-freebsd-arch@FreeBSD.ORG Sat Sep 3 06:47:03 2011 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7255106566C for ; Sat, 3 Sep 2011 06:47:03 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 20DF98FC08 for ; Sat, 3 Sep 2011 06:47:02 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id JAA29023; Sat, 03 Sep 2011 09:46:54 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Qzk0E-000ISx-39; Sat, 03 Sep 2011 09:46:54 +0300 Message-ID: <4E61CD58.40402@FreeBSD.org> Date: Sat, 03 Sep 2011 09:46:48 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0.1) Gecko/20110901 Thunderbird/6.0.1 MIME-Version: 1.0 To: perryh@pluto.rain.com References: <4e5ba9c3.bzHIw1KEy8R2QcK7%perryh@pluto.rain.com> <3420B331-C697-468A-80BA-B31C33804710@freebsd.org> <4e5c5b5f.moT7dLemOuteQJ5T%perryh@pluto.rain.com> <4E5C364D.7070904@freebsd.org> <20110830201357.GB58638@acme.spoerlein.net> <4e5e458a.Un+VK0itRgItvxbf%perryh@pluto.rain.com> <20110831081815.GN2493@over-yonder.net> <4e5f2e26.6PQ5d6F3eauFfAcH%perryh@pluto.rain.com> <4E5F12B6.3090307@FreeBSD.org> <4e5fa001.BTxOKlcJfp7aZ2KE%perryh@pluto.rain.com> <4E5F4807.6070206@FreeBSD.org> <4e62195b.cdaZfeF621ojSqVQ%perryh@pluto.rain.com> In-Reply-To: <4e62195b.cdaZfeF621ojSqVQ%perryh@pluto.rain.com> X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-arch@FreeBSD.org Subject: Re: Official git export X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Sep 2011 06:47:03 -0000 on 03/09/2011 15:11 perryh@pluto.rain.com said the following: > Andriy Gapon wrote: > >> ... keeping local history is of course not necessary, but when >> you need to do some serious history analysis it comes extremely >> convenient. > > In the area where one is working, certainly, but I don't expect to > need the commit history of the contrib tree while working on UFS or > gmirror. Do you know of a tool (VCS or otherwise) that allows to checkout parts of a tree with history and other parts without history? If you talk about using different tool for different parts of the tree, then, well, good luck. >> ... doing some non-trivial FreeBSD development myself ... > > Unless you're considerably older than you look in that Flickr > photo from about a year ago (in Kiev), I was doing non-trivial > OS development before you finished middle school :) What can I say. Perhaps you had a success using your model of different tools per different parts of tree. Maybe it saved you days when you were using a modem for internet access. But I don't see why we have to chose this model now. -- Andriy Gapon From owner-freebsd-arch@FreeBSD.ORG Sat Sep 3 07:18:11 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E289F106564A; Sat, 3 Sep 2011 07:18:10 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by mx1.freebsd.org (Postfix) with ESMTP id 829168FC14; Sat, 3 Sep 2011 07:18:10 +0000 (UTC) Received: by qwg2 with SMTP id 2so2634988qwg.17 for ; Sat, 03 Sep 2011 00:18:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=urAGlsDB/MlfmxVGAhaN2cFhjyANcJdn6/MHwAf25ps=; b=il/C4+fVl3KcqAbtplbTJpyXhl6HirfWazPqdlcWzc6pRdNttAS70MVZQA1rMcN4AY 50ZtU/s70xR1DtFeGOtsbavT4qTAjs/BxeoKidze1jYAqnne6utiCyzh9ihsCxiMgEgQ NFdjibRFxbG5z+h2f7zBP2YKO4AW/IkHJ8vWA= MIME-Version: 1.0 Received: by 10.224.197.71 with SMTP id ej7mr1235262qab.242.1315034289681; Sat, 03 Sep 2011 00:18:09 -0700 (PDT) Received: by 10.224.37.83 with HTTP; Sat, 3 Sep 2011 00:18:09 -0700 (PDT) In-Reply-To: <4E61CD58.40402@FreeBSD.org> References: <4e5ba9c3.bzHIw1KEy8R2QcK7%perryh@pluto.rain.com> <3420B331-C697-468A-80BA-B31C33804710@freebsd.org> <4e5c5b5f.moT7dLemOuteQJ5T%perryh@pluto.rain.com> <4E5C364D.7070904@freebsd.org> <20110830201357.GB58638@acme.spoerlein.net> <4e5e458a.Un+VK0itRgItvxbf%perryh@pluto.rain.com> <20110831081815.GN2493@over-yonder.net> <4e5f2e26.6PQ5d6F3eauFfAcH%perryh@pluto.rain.com> <4E5F12B6.3090307@FreeBSD.org> <4e5fa001.BTxOKlcJfp7aZ2KE%perryh@pluto.rain.com> <4E5F4807.6070206@FreeBSD.org> <4e62195b.cdaZfeF621ojSqVQ%perryh@pluto.rain.com> <4E61CD58.40402@FreeBSD.org> Date: Sat, 3 Sep 2011 00:18:09 -0700 Message-ID: From: Garrett Cooper To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: perryh@pluto.rain.com, freebsd-arch@freebsd.org Subject: Re: Official git export X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Sep 2011 07:18:11 -0000 On Fri, Sep 2, 2011 at 11:46 PM, Andriy Gapon wrote: > on 03/09/2011 15:11 perryh@pluto.rain.com said the following: >> Andriy Gapon wrote: >> >>> ... keeping local history is of course not necessary, but when >>> you need to do some serious history analysis it comes extremely >>> convenient. >> >> In the area where one is working, certainly, but I don't expect to >> need the commit history of the contrib tree while working on UFS or >> gmirror. > > Do you know of a tool (VCS or otherwise) that allows to checkout parts of= a tree > with history and other parts without history? > If you talk about using different tool for different parts of the tree, t= hen, > well, good luck. > >>> ... doing some non-trivial FreeBSD development myself ... >> >> Unless you're considerably older than you look in that Flickr >> photo from about a year ago (in Kiev), I was doing non-trivial >> OS development before you finished middle school :) > > What can I say. > Perhaps you had a success using your model of different tools per differe= nt > parts of tree. =A0Maybe it saved you days when you were using a modem for= internet > access. =A0But I don't see why we have to chose this model now. If git is interrupted with a pull/rebase/etc, I think it will continue to continue loading the metadata from where it left off. git clone is a slightly different story (several people posted that clones can't be interrupted).. Sadly, I do see where Perry is coming from, having to deal with slow downlinks (once or twice a year I go back to rural WA state where they're very much in the digital dark ages) however, there are some major benefits which shouldn't be discounted when using a DCS. One of the great things about FreeBSD is that it's a complete distribution. Given how many additional packages and the like that need to be downloaded on a regular basis, I would think/hope that this would be a small speedbump in the overall scheme of things -- especially because frequent incremental updates are relatively small. Example (using the linux kernel sourcebase -- I did my last pull a 3~4 weeks ago): $ git pull remote: Counting objects: 5052, done. remote: Compressing objects: 100% (949/949), done. remote: Total 3429 (delta 2733), reused 3145 (delta 2459) Receiving objects: 100% (3429/3429), 814.98 KiB, done. Resolving deltas: 100% (2733/2733), completed with 748 local objects. >From http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6 ab7e2db..9e79e3e master -> origin/master >From http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6 * [new tag] v3.1-rc3 -> v3.1-rc3 * [new tag] v3.1-rc4 -> v3.1-rc4 Updating ab7e2db..9e79e3e Fast-forward ... $ Thanks, -Garrett