On Wed, Sep 17, 2008 at 11:18 PM, John Forte <John.Forte at sun.com> wrote:
> It wasn't meant to be a review of the code, only a representation of where
> the code will reside and a review for the new and modified makefiles. The
> code itself was reviewed as each project integrated. In a lot of cases, that
> is many years ago.
>
> Sorry if I caused any confusion here. This a merge effort to consolidate the
> consolidations, not a new project(s) integration.
>

So should the issues I pointed out be addressed, postponed or ignored ?


> - John
>
> Cyril Plisko wrote:
>>
>> On Wed, Sep 17, 2008 at 9:26 PM, John Forte <John.Forte at sun.com> wrote:
>>
>>>
>>> Apologies all. The target did indeed change. It is now build 100. Sorry
>>> about the lack of update on status.
>>>
>>> There is a webrev now available at:
>>>
>>> http://cr.opensolaris.org/~jforte/6745433/
>>>
>>
>>
>> Man, that is a big one. I am not sure how it is expected to be
>> reviewed, bearing in mind the amount of code.
>> Nevertheless here is a quasi-random shot at stmf_sbd driver.
>>
>> usr/src/uts/common/io/comstar/lu/stmf_sbd/sbd.c:137
>>   _init() doesn't return DDI_FAILURE. It returns 0 on success
>>   or error number on failure. DDI_FAILURE isn't actually
>>   an error number.
>>
>> usr/src/uts/common/io/comstar/lu/stmf_sbd/sbd.c:202
>>
>>   This is really a bad one. The first argument to getinfo() entry point
>> (dip)
>>   is _not_ to be used. The getinfo(9E) manual page describes that
>>   in the case of DDI_INFO_DEVT2INSTANCE the `arg' is actually a dev_t
>>   and it should be used to extract the minor number to be mapped back
>>   to the instance.
>>
>> Quick check reveals that at least fct and stmf drivers suffer from the
>> same problem
>> in their getinfo(9E) entry point.
>>
>> This is by no means should be considered a full review neither for the
>> whole webrev, nor
>> for the sbd driver. I just happened to be a little bit acquanted with
>> the sbd code due to my
>> recent interest in it.
>>
>>
>> --
>> Regards,
>> Cyril
>>
>
>



-- 
Regards,
 Cyril

Reply via email to