[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20080603100215.5789bf06@extreme>
Date: Tue, 3 Jun 2008 10:02:15 -0700
From: Stephen Hemminger <shemminger@...tta.com>
To: "Subbu Seetharaman" <subbus@...verengines.com>
Cc: netdev@...r.kernel.org
Subject: Re: [PATCH 3/12] BE NIC driver - net_object i/f functions, Makefile
> +/*
> +
> +@...e
> + bni.c
> +
> +@...ef
> + This file contains finctions that will be used by the BladeEngine
> + Network drivers to access BladeEngine Hardware. All code in
> + this file must be completely OS neutral.
> +
> +*/
> +
> +#include "bni.h"
> +
> +/*!
> + This function initializes the data structures in BNI / BECLIB for network
> + operation. The OSM driver must call this function before making any other
> + BNI call.
> +
> + If this functions succeeds, the caller must call bni_cleanup() as part
> + of driver cleanup procedure.
> +
> +@...am
> + chipobj - Address of the space allocated by OSM for chip object
> + (struct be_chip_object). The space for this is
> + allocated by OSM, but this object is maintained
> + by BECLIB and is opaque to OSM.
> +@...urn
> + BESTATUS - (0 if successful, non-zero status code if not successful)
> +
> + */
You commenting standard is similar but not compatiable with kernel docboock.
But I don't consider this a blocker to inclusion, just a nuisance.
> +BESTATUS bni_init(struct be_chip_object *chipobj)
> +{
> + int r;
> + r = be_initialize_library();
> + if (r != BE_SUCCESS)
> + goto error;
> + r = be_chip_object_create(chipobj);
> + if (r != BE_SUCCESS)
> + goto error;
> +error:
> + return (r);
> +}
But this overly verbose code style is the style of code which should be cleaned
up (after inclusion). It is the reason that kernel developers hate drivers that
try to be OS independent. They end up looking like the kind of rubbish written
by contracting software houses that are paid by the line of code.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists