On Tue, Oct 06, 2009 at 12:15:23PM -0600, Jerry Jelinek wrote:
> Edward Pilatowicz wrote:
>> On Tue, Oct 06, 2009 at 09:47:40AM -0600, Jerry Jelinek wrote:
>>> 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.)
>>>> - 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