:Matthew Dillon wrote:
:>     I'm not interested in using P4.  I think it's a mistake.  That is, I
:>     think it is being severely overused.  At the very least it is preventing
:>     me from comitting simple things to -current because as far as I can tell
:>     when you add up the junk sitting in P4 it touches almost every file
:>     in the kernel tree.  Everything I've tried to work on has some hack
:>     sitting in P4 somewhere that somebody hasn't committed.
:By the same token, you have also stated:
:]     Well... try again.  If something ought to be compatible in a piecemeal
:]    commit and isn't, then something unexpected happened and you need to
:]    find out what it was.  Doing a full-on commit for something like the
:]    proc lock patch is far too dangerous.  It's just too large a patch set
:]    and we know from experience (cam, softupdates, etc...) that having a
:]    small handful of people testing a large private patch is not going to
:]    find all the bugs.
:How do you reconcile these divergent points of view?

    These are not divergent points of view.  I am saying quite clearly that
    the ucred code and proc-locking code can be committed in a piecemeal
    fashion.  In fact, good chunk of the proc locking code already has been
    with no ill effect on the tree - it might not be completely operational
    due to Giant, but just comitting it tests a great deal of infrastructure
    including potential lock order reversals and mismatched locks.  That's
    the whole point of doing things this way.

:What large scale changes are "OK", and what large scale changes
:are "too dangerous"?

    The best example I can think of is Julian's initial KSE commit, where
    he rearranged the proc structure.  The rearrangement touched a huge
    number of files and the commit had to be made all at once, not file by
    file, due to the structural changes. 

:Do you have a set of rules, that would let us look at a patch
:set and instantly decide which of these two categories the
:code fell into?
:I'm not trying to be a jerk, but not everything can be broken
:down into 1 line commits, and not everything can be broken down
:into 8 line commits, or 64 line commits, or 512 line commits,
:etc. (if you'll forgive my proof by induction).
:-- Terry

    This is getting a bit absurd.  I am arguing a general principle here,
    you are not contributing anything by stretching it into an irrational
    statement.  One line commits?  Oh come on!

    I will say that the work *I* am doing on -current is mostly piecemeal
    in nature.  I even expect the VM locking to wind up being piecemeal.
    Everything I have posted to date has been piecemeal.  For example,
    the ucred patchset I posted does not patch all the ucred functions,
    it just patched the read-only functions.  But as a side effect that
    gave me a basis to track down the other uses of Giant in the general
    syscall path.  That was a good demarkation point for me.  It is by
    no means the end... it is, as I have said, piecemeal.

    The result?  I was able to immediately note the use of Giant in
    trap.c (the ucred clearing code) as well as its use in userret(),
    plus I could test a few of the ucred functions like getuid() and test
    the Giant instrumentation.

    So you see, a piecemeal commit can have a great ability to move the
    development process forward.  When you spend weeks or months putting
    together an UBER-patch you do not get any of that... it's all delayed
    and when the patch finally goes in people wind up spending a lot of
    time testing the patch itself rather then working on the ramification
    of what the patch allows you to move on to.

                                        Matthew Dillon 
                                        <[EMAIL PROTECTED]>

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to