Date: Fri, 22 Mar 2002 08:32:47 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: John Baldwin <jhb@FreeBSD.ORG> Cc: smp@FreeBSD.ORG Subject: Re: Giant instrumentation Message-ID: <200203221632.g2MGWlY61491@apollo.backplane.com> References: <XFMail.20020322100519.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:> I know I'm being harsh here, but that is my opinion. : :Er, instead of adding s = mtx_lock_giant()/mtx_unlock_giant() along with having :to possibly rework logic of code, you just add "foo" to a line in :syscalls.giantvars. This is hard? The main difference here is that the :instrumentation code no longer impacts the actual syscall source code thus :keeping the actual syscall code cleaner. Also, in your current implementation :you encourage both safe and unsafe code to be under the sysctl variables :meaning that we can't actually get Giant out from under a subsystem until the :whole thing is done preventing us from incrementally moving things out from :under Giant. : :-- : :John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ First of all, what is this 'possibly rework logic of code' crap? mtx_lock_giant() is no different then what you are doing, except that it's far more obvious to the programmer and far more flexible. I don't encourage anything with this code, it's flexibility is there in case it is needed. That is not encouragement. What you believe to be a plus... hiding the instrumentation from the programmer, I believe to be a strong negative. There is no point in doing the instrumentation at all unless the programmer playing with the syscall code knows what it is doing in the context of whatever he is working on. This code forces the programmer to keep multiple source files open just to see what the hell is going on with a syscall. My code makes the instrumentation extremely plain and obvious without the programmer having to reference multiple source files. It sure as hell does NOT make the syscall code dirty! It makes it more understandable. That isn't dirty. What you believe to be making the syscall code 'clean' is actually obfuscating it instead, make it less effective and less flexible. You also seem to believe that a mere two lines of code in a syscall somehow makes it more difficult for the programmer. You are, and I've seen this before, equating lines of code with difficultly. It is a complete absurd notion to equate lines of code with difficulty. In short, syscalls.giantvars is a bad idea and a hinderance to development rather then an aid. I have no interest whatsoever in it and I am not particularly interested in seeing people rip out my mtx_lock_giant() code and replace it with this junk. -Matt Matthew Dillon <dillon@backplane.com> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200203221632.g2MGWlY61491>