Re: Giant instrumentation

:>     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 <[e-mail]>  <><  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 
					<[e-mail]>

To Unsubscribe: send mail to [e-mail]
with "unsubscribe freebsd-smp" in the body of the message