'td' vs sys/fs/nfsserver/

[Konstantin Belousov]

On Wed, Mar 06, 2019 at 02:25:16PM +0100, Alexander Leidinger via freebsd-fs wrote:
> Hi,
> 
> About code churn:
>  - Does it matter for an end user if the code repo gets bigger?
>  - Will there be an (indirect) benefit for an end user (like code which is 
> more easy to understand and as such less bugs while changing something or 
> more people willing to touch/improve/extend)?
Why does it matter how this affects end users ?

>  - How many developers mirror the repo and are at the same time space 
> limited? = Does it matter for us developers?
Why does it matter at all?

>  - How many developers are network transfer limited and what is the amount 
> of expected change compared to a clang / openssl /.... import?
>  - At which "churn-factor" does it not make sense anymore (and why)?
Repo churn is a situation where developers get significant amount
of mail with changes that they must read, but which does not change
functionality. The changes must be read to understand the current state
of the code after the change, to see that there is no un-intentional or
bad intentional chunks despite the the commit message.

Vcs blame becomes harder to use after the churn because to get down to
the interesting change for the part of the code, you must skip a lot
of no-op commits (and before skipping, reader needs to ensure that the
commits are no-op). Same for vcs log.

Then, when you found older change that is interesting, it does not
matches the current code state due to churn above it.

Repo churn invalidates any out-of-tree patches or development trees
and requires efforts to re-merge.

Lets ignore MFC for a moment.

These are basics why huge style changes alone, or large set of trivial
non-functional changes cause lot of backpressure.  Look at libexec/rtld-elf
for the canonical example of code breaking several important style(9)
rules which are not corrected because that would cause churn.

It should be obvious for anybody actively working with the code.

> 
> 
> To make it explicit what my intend is with those questions: I suggest to 
> look at real numbers and quality, instead of expectations and feelings.
Good luck measuring frustration.

> 
> 
> Bye,
> Alexander.
> 
> 
> -- 
> Send from a mobile device, please forgive brevity and misspellings.
> 
> Am 5. März 2019 21:04:10 schrieb Kirk McKusick <mckusick at mckusick.com>:
> 
> > Let me give a brief historical perspective on how we ended up with
> > td getting passed nearly everywhere. It arose in the early 1980's
> > as I was leading an effort to get rid of kernel global user area.
> >
> > The state of a process was stored in its process entry and its user
> > structure. The state needed only when the process was running was
> > stored in the user structure. State needed when the process was not
> > running was stored in the process structure. Thus the user structure
> > could be swapped out when the process was idle. The idea was to keep
> > the process structure as small as possible. On each context switch,
> > the process' user structure was brought into memory if it had been
> > swapped out and then mapped to the global kernel "u" variable.
> >
> > One of the fields in the user structure was u_error. So functions
> > returned an error by setting u.u_error. If the kernel needed to do
> > an internal I/O operation (say read the contents of a directory
> > block to find an entry), it would need to save u.u_error, do the
> > I/O, check u.u_error to find out if it succeeded, then restore
> > u.u_error.
> >
> > Our goal was to get rid of the user structure. So we made a sweep
> > over the entire kernel to get rid of uses of u.u_* accesses. For
> > u.u_error we changed functions so that they always returned errors.
> >
> > Many of the fields that now appear in the uio structure were in the
> > user area. So we gathered them together to define the uio structure
> > and passed a pointer to a uio structure to functions that needed
> > to use it.
> >
> > Finding out the current process was done using u.u_procp.  We
> > eliminated this by passing the process pointer in as one of the
> > parameters to each system call. Once we moved to threads, the
> > pointer to the process was changed to be a pointer to the thread.
> >
> > Most of these changes were correct and carry over nicely to today.
> > In retrospect, the passing of the thread was not the right approach.
> > It becomes a parameter to near every call and is often just a
> > passthrough. So, if I had a time machine and could go back, I
> > would have dropped the idea of passing the process pointer and
> > just stuck with usng then curproc(), now curthread().
> >
> > So, this is a long-winded way of saying that purging the passing
> > of td seems like a reasonable idea though one has to ask if the
> > cost in code churn is worth the effort.
> >
> > 	Kirk McKusick
> > _______________________________________________
> > freebsd-fs at freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-fs
> > To unsubscribe, send any mail to "freebsd-fs-unsubscribe at freebsd.org"
> 
> 
> 
> _______________________________________________
> freebsd-fs at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe at freebsd.org"