Date: Wed, 06 Mar 2019 14:25:16 +0100 From: Alexander Leidinger <Alexander@Leidinger.net> To: Kirk McKusick <mckusick@mckusick.com>, Edward Napierala <trasz@freebsd.org> Cc: FreeBSD FS <freebsd-fs@freebsd.org> Subject: Re: 'td' vs sys/fs/nfsserver/ Message-ID: <169532d2770.27fa.fa4b1493b064008fe79f0f905b8e5741@Leidinger.net> In-Reply-To: <201903052008.x25K8d4Z011653@chez.mckusick.com> References: <201903052008.x25K8d4Z011653@chez.mckusick.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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)? - How many developers mirror the repo and are at the same time space limited? = Does it matter for us developers? - 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)? 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. Bye, Alexander. -- Send from a mobile device, please forgive brevity and misspellings. Am 5. März 2019 21:04:10 schrieb Kirk McKusick <mckusick@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@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?169532d2770.27fa.fa4b1493b064008fe79f0f905b8e5741>