From owner-svn-src-head@freebsd.org Fri Feb 19 05:37:08 2016 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C888DAADB51 for ; Fri, 19 Feb 2016 05:37:08 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 76AC715BA for ; Fri, 19 Feb 2016 05:37:08 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-wm0-x231.google.com with SMTP id b205so53642672wmb.1 for ; Thu, 18 Feb 2016 21:37:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sippysoft-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=Kos7ewz6iG8bCIF30kNGqereIc6v4cKrK8YS6U71Co8=; b=fs1B53GJoJxtjrmdKnRbox1S3sV6YYSLBvcAxRjT9SBCXsVHh+elBdMt0U7F3tPttL qerNLpg/xhdx3g9ex/0ywnxzKOug3L2MfD16UXEgth+KsPQZcZqZKtlmQHckRDms4OaC icPG8jVg9kNUKLFjIfEiFixTRuylCPdJYhQJDUw4eiwtXVeN5bvu7fVN8Bk1O7dqDfSi Xu3Ka6G2q8DyRCW2stH87aEsZ6dDmIGuCg9pQBDBZwRnJ0wLclofcl4qKmMb+ij3CbzD xDWaiUuMK8NVfZuO9JddedWw6EqpYTLr1mSZyVTH2Cu7E2s17Sp02q2ze5UmVnPM4/5Z P0dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Kos7ewz6iG8bCIF30kNGqereIc6v4cKrK8YS6U71Co8=; b=gRgpIVYeroKZNlpy313bc4mN+GkZ+4TrbljzzbLgOcEUWmRwiHIMPgTCyx56figZFE quGLhzhmgsYe4ArZ2DGRq055y+dDPdHm2S1JdVo9ZFhvRTAwVO32XLQX7HsSwBYfr5sn DDnvag72deESpRbgLUVCe/8FmvHEK4XM4EmxpLVSBSSylwyRSdcFK4e2cA5OZn2dXuKJ 07S0OFHaLnB5FLJpYpBiH3cak+xRaPqCLfgo/soeBq3otAQx2V5HkexI6Yb0hungEhcr yen8BOVXWyYv1hxSmfs6w+sVMX/Dla6drEEqOx6z6qEOc9haDyUONnOrk0AvspxAmpfZ 0uRQ== X-Gm-Message-State: AG10YOQlyjdtMQKZZk9zHbeD3/gyPQdUIahNe51cqSVnI0vRZmFqNaULJMYl6PhzF7cTgJCKlsuay76fZXT8+1Cz MIME-Version: 1.0 X-Received: by 10.28.97.135 with SMTP id v129mr7180956wmb.90.1455860226859; Thu, 18 Feb 2016 21:37:06 -0800 (PST) Sender: sobomax@sippysoft.com Received: by 10.27.218.12 with HTTP; Thu, 18 Feb 2016 21:37:06 -0800 (PST) In-Reply-To: References: <56C66415.7040407@FreeBSD.org> Date: Thu, 18 Feb 2016 21:37:06 -0800 X-Google-Sender-Auth: 7cWa-0PwXZCPssRey5QE1BjVhAk Message-ID: Subject: Re: svn commit: r229537 - in head/sys: conf geom/uncompress modules/geom/geom_uncompress From: Maxim Sobolev To: Adrian Chadd Cc: Bryan Drewery , Aleksandr Rybalko , "src-committers@freebsd.org" , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 05:37:09 -0000 Also in purely technical department, that fork should have been done using svn copy for all code, manpages etc, not svn add, so that we would keep all history associated with the code going back to 2004. This would also make it more prominent that the code is really very similar to anyone just reading svn logs. Right now we have two disjoint histories, so once we merge both into a single entity some of it would unavoidably get lost. Yes, it's all just my rant at this point, but perhaps there are some lessons to be learned from this incident. On Thu, Feb 18, 2016 at 9:20 PM, Maxim Sobolev wrote: > Well, what about "do it once, do it right" motto and ongoing code > maintenance cost? Don't you think there should be a balance between those? > Considering how similar the code really is what we've gained in "immediate > availability" department we've already lost since in the time people spend > doing cross merges between those two since 2011. Not even to mention time > wasted by users of the feature dealing with bugs already fixed in the twin > implementation and associated frustration. All that would be eliminated had > this fork never happened. > > On Thu, Feb 18, 2016 at 8:53 PM, Adrian Chadd wrote: > >> It passed the "it's working code and it's immediately useful" filter. >> >> I'd love to see them both unified somehow. I really would! >> >> >> -a >> >> >> On 18 February 2016 at 17:28, Maxim Sobolev >> wrote: >> > Sigh, I don't now how it managed to sleep through usually tight FreeBSD >> > peer-review process. It would be interesting to hear some comments from >> @ray >> > and @adrian, perhaps there were some reasons for it being done this way, >> > although I cannot see any in a hindsight. >> > >> > I am just in the middle of rather substantial overhaul of both kernel >> and >> > userland part here: >> > >> > https://reviews.freebsd.org/D5333 >> > >> > And once that committed it will take them apart again. I've also spend >> quite >> > lot of time testing my change set, which would with very little effort >> have >> > covered both formats had I started with unified code base. :( >> > >> > I also plan on making further improvement into kernel module, as it is >> right >> > now both g_uzip and g_uncompress basically piggyback single "g_up" >> thread, >> > so you cannot use multiple cores even for different instances, let >> alone one >> > instance being accessed by multiple readers. And it also can delay other >> > unrelated I/O requests by maxing out CPU time slice available for the >> g_up. >> > >> > On Thu, Feb 18, 2016 at 4:38 PM, Bryan Drewery >> wrote: >> >> >> >> On 2/18/2016 3:57 PM, Maxim Sobolev wrote: >> >> > Aleksandr, Adrian, >> >> > >> >> > I know it's 3 years later, but I really don't know why it's been done >> >> > this way. Take a GEOM module and associated usr.bin utility, copy it >> >> > verbatim add few lines of code and re-add that as a new module seems >> >> > like just laziness and attempt to avoid doing extra work on making >> >> > unified code. The same goes for the mkulzma, which is almost 1:1 >> copy of >> >> > the mkuzip. Now people are merging back and forth and I've just spent >> >> > few days testing some rather major rework of geom_uzip / mkuzip code >> not >> >> > even realizing that there is its evil twin in the tree. :( >> >> >> >> r283104 is an example of one of these problems. It was a catch-up of >> >> uzip's r268986 done almost a year before. I did comparisons before >> using >> >> uzip last summer and ran across that one. >> >> >> >> > >> >> > https://reviews.freebsd.org/D5333 >> >> > >> >> > I suggest functionality from both geom_uncompress / mkulzma are >> folded >> >> > now back into geom_uzip / mkuzip and geom_uncompress / mkulzma are >> nuked >> >> > afterwards. >> >> > >> >> > Thanks! >> >> > >> >> > >> >> > >> >> > Author: ray >> >> > Date: Wed Jan 4 23:39:11 2012 >> >> > New Revision: 229537 >> >> > URL: http://svn.freebsd.org/changeset/base/229537 >> >> > Log: >> >> > GEOM_UNCOMPRESS module, can be used with uzip images and with new >> >> > ulzma images. >> >> > Approved by: adrian (mentor) >> >> > Added: >> >> > head/sys/geom/uncompress/ >> >> > head/sys/geom/uncompress/g_uncompress.c (contents, props changed) >> >> > head/sys/modules/geom/geom_uncompress/ >> >> > head/sys/modules/geom/geom_uncompress/Makefile (contents, props >> >> > changed) >> >> > Modified: >> >> > head/sys/conf/files >> >> > head/sys/conf/options >> >> > >> >> > >> >> >> >> >> >> -- >> >> Regards, >> >> Bryan Drewery >> >> >> > >> > >> > >> > -- >> > Maksym Sobolyev >> > Sippy Software, Inc. >> > Internet Telephony (VoIP) Experts >> > Tel (Canada): +1-778-783-0474 >> > Tel (Toll-Free): +1-855-747-7779 >> > Fax: +1-866-857-6942 >> > Web: http://www.sippysoft.com >> > MSN: sales@sippysoft.com >> > Skype: SippySoft >> > >