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. - 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 >
