On Tue, Oct 06, 2009 at 12:15:23PM -0600, Jerry Jelinek wrote:
> Ed,
> Edward Pilatowicz wrote:
>> On Tue, Oct 06, 2009 at 09:47:40AM -0600, Jerry Jelinek wrote:
>>> Ed,
>>> Thanks for reviewing this again.  I took most of your
>>> input.  For the questions you had or the things I
>>> didn't take, I have responded below.
>>> Edward Pilatowicz wrote:
>>>> - could you propegate back your common changes to the original file?
>>> I don't want to complicate this project with the additional
>>> changes to the sn1 brand and the corresponding additional testing.
>>> I filed bug:
>>> 6888642 sn1 brand cleanup
>>> so that we can track that work as a separate integration.
>> sigh.  are you commiting to this work?  the sn1 brand always get's
>> neglected (says the guy who spent too much time fixing it up to be a
>> real brand).
> Sure.  I just don't want these coupled together.

then please make sure to update the bug with a detailed list of all the
differences between the two.  (should be easy since i already hilighted
all the differences in my code review comments.)

>>>> ----------
>>>> usr/src/lib/brand/solaris10/s10_brand/common/s10_brand.c
>>>> - in s10_zone, in the ZONE_GETATTR() case, why isn't S10_TRUSS_POINT_5
>>>>   used instead of S10_TRUSS_POINT_3?
>>> Because the first 3 parameters are required for a truss point. That is,
>>> S10_TRUSS_POINT_0 takes 3 parameters, S10_TRUSS_POINT_3 takes 6, which
>>> is the number of parameters we're passing.
>> but i thought the caller passed in 4 parameters. (in addition to the
>> cmd.)  why are you not printing out "buf" and "bufsize"?
> Those parameters aren't that useful for debugging.  I can add them
> if you'd like.

yes please.  otherwise some anal retentive person who is debugging a
problem will get distracted by the fact that the buf pointer and size
values are invalid.

zones-discuss mailing list

Reply via email to