Mike, did you actually review the changes? Can I list you as a reviewer
on the RTI?
By the way, I finally got around to updating the review with all of
Richard's feedback. Its at the same place:
http://cr.grommit.com/~gdamore/douglas/
Please give it a look if you have a few moments.
-- Garrett
Mike Kupfer wrote:
"GD" == Garrett D'Amore <[EMAIL PROTECTED]> writes:
Rich> usr/src/uts/sun4u/douglas/Makefile.files
Rich> RL-4: L38 - See, now this *does* reference tadpmu, One or the
Rich> other...
GD> Hrmmm... right now the reference is a harmless stub, because nothing
GD> calls it yet. But once I add tadpmu.c, it will get called. I can
GD> remove it now if it is offensive.
The problem with cruft like this is it makes it harder for people to
understand just what's going on. As a general rule, unused code
(including makefile bits) should be kept out of the gate.
Rich> usr/src/uts/sun4u/douglas/Makefile.targ.shared
Rich> RL-6: Some platforms do this and Makefile.targ, some just the
Rich> latter. Is there a reason for that, I can't see one.
[...]
GD> I copied the current Makefile framework from grover. I noticed the
GD> discrepancy, but I have no idea which is preferred.
The Makefile.*.shared files were introduced to deal with makefile text
that is shared between the open and closed trees.
In the interest of simplicity, platforms that are entirely open-source
should not use the .shared pattern. If there's a reasonable chance
you'll be adding closed code later, I'd leave it as-is. (Teamware
doesn't cope with renaming a file Foo to Foo.shared and then creating a
new Foo. I haven't checked how well Mercurial copes.)
Rich> usr/src/uts/sun4u/douglas/os/douglas.c
Rich> RL-7: #if 0 is evil, don't do it. (see Developing in ON)
GD> Again, this is intended to be very short term.
Historically, there have been problems with project teams promising to
fix something in a followup putback and then not doing so (e.g., the
team gets redirected to work on something else). So there is a strong
preference not to introduce #if 0'd code in the first place.
mike
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
