From owner-svn-src-all@freebsd.org Mon Mar 4 19:24:03 2019 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 70DC6151FEAB; Mon, 4 Mar 2019 19:24:03 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-ot1-f47.google.com (mail-ot1-f47.google.com [209.85.210.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0244D833A9; Mon, 4 Mar 2019 19:24:02 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: by mail-ot1-f47.google.com with SMTP id q24so5237984otk.0; Mon, 04 Mar 2019 11:24:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Rpc3+qJDe1k+uwfQYKyN0DdeG5qDN52frZis2ZZ8dkY=; b=kpjjCM+Um7vMGAuKUNMPZw9PsASpLomH7w6iCNrMRQuH8AQqPLVbTh0Z/O0Xw2t3eE zRFzvZU6zv5t0nGc/++0zCyOxg9DOXyN/LVZPz0xGiwi27RDYxLeYk2PXdasZ2ceBWb0 ij5aofK2CpX18ETZzk2O2vKk6XS1cNl4WvdoElLoXDtsv1rV2kwxjBOMORgqFHez58vP 7sm83eGEEpyH6suKmtRP4WHueakEOdo+EH8bWH8kqvj3THthYxqxP+pi+Sw75MnCwcaF bgIHraMFxazkoIK4u3FrnZQ/X41utz0P2cJ8zi+Fpyera7C8ex+GJ4jCpuOvATgH/pB9 ysfw== X-Gm-Message-State: APjAAAWsbCg0AcW3sfds/hypJofz6OedzRYaviTEWHkRHRjxJY0HIVL5 oXxQ4x8Mp1cR9mZJ39uy0t5Lg/EyD7/3E0gfviqSEw== X-Google-Smtp-Source: APXvYqy19rf0pIPheNXhJFmzlxnyOfl8bqIOzCI191/abmW0q7nShYriqXXgZY0W/3bTjSAC6xZVmf86VYreFTKskGs= X-Received: by 2002:a9d:7dcd:: with SMTP id k13mr12096043otn.205.1551713210293; Mon, 04 Mar 2019 07:26:50 -0800 (PST) MIME-Version: 1.0 References: <201903041302.x24D2aG0093620@repo.freebsd.org> <20190304132021.GN68879@kib.kiev.ua> <20190304143021.GO68879@kib.kiev.ua> In-Reply-To: From: Edward Napierala Date: Mon, 4 Mar 2019 15:26:39 +0000 Message-ID: Subject: Re: svn commit: r344758 - in head/sys/fs: nfs nfsserver To: Cy Schubert Cc: Konstantin Belousov , src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 0244D833A9 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.989,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 19:24:03 -0000 pon., 4 mar 2019 o 15:17 Cy Schubert napisa=C5= =82(a): > > On March 4, 2019 6:30:21 AM PST, Konstantin Belousov wrote: > >On Mon, Mar 04, 2019 at 01:31:37PM +0000, Edward Napierala wrote: > >> pon., 4 mar 2019 o 13:20 Konstantin Belousov > >napisa=C5=82(a): > >> > > + p =3D curthread; > >> > Why do you name it 'p', which is typical for process, and not 'td', > >you are > >> > changing most of the code anyway. > >> > >> To keep the diff size smaller. You're right, this touches a lot of > >stuff, > >> but most of those added lines are temporary anyway - they will be > >> removed later, when the td is pushed down even more. > >But if you create code churn, doing it only half way is worse. > > > >> > >> > Also I am curious why. It is certainly fine to remove td when it is > >used > >> > as a formal placeholder argument only. But when the first action in > >the > >> > function is evaluation of curthread() it becomes less obvious. > >> > >> Again, many/most of those are temporary. I'm trying to push td down > >> in small steps, "layer by layer", so it's easy to review. > >> > >> > curthread() become very cheap on modern amd64, I am not so sure > >about > >> > older machines or non-x86 cases. > >> > >> The main reason is readability. Right now there's no easy way to > >tell whether > >> a function can be passed any td, or if it must be curthread. > >I must admit that this is the weirdnest argument against 'td' that I > >ever > >heard. I saw more or less reasonable argumentation > >- that using less arguments make one more register for argument passing > > (amd64 has 6 input arg regs), > >- that less arguments make smaller call code. > >But trust me, in all cases where function can take td !=3D curthread, it > >is > >either obvious or well-known for anybody who works with that code. > > > >Before you start doing a lot of small changes (AKA continous churn) > >please formulate your goals and get some public feedback. My immediate > >question that I want answered before you ever start touching the code, > >is what you plan to do with > > sys_syscall(struct thread *td, uap) > > Agreed on all points. At the very least this group of commits should be r= eviewed on phabricator. It has been, even though they are pretty much mechanical changes. > Can we back all these commits out until there is a proper review, please? The review from the NFS maintainer is not enough?