[openib-general] iWARP Branch Proposal

Roland Dreier rolandd at cisco.com
Mon Aug 8 06:51:39 PDT 2005


Tom, thanks for posting your device driver so quickly.  I realize that
this is work-in-progress, and with that in mind I skimmed through the
code and came up with some suggestions for your to-do list:

- Kconfig: replace 'mthca' with 'ams1100' in help text :)

- Replace all // comments with /* */.

- Why are members of cc_pci_regs_t and cc_adapter_pci_regs_t volatile?
  Volatile declarations are almost inevitably buggy.  It's better to
  use ordered accessors (readl(), writel(), etc) or insert explicit
  memory barriers.

- Get rid of most typedefs -- for example

	typedef enum {
		...
	} foo_t;

  should become

	enum foo {
        	...
	};

- Can cc_byteorder.h be eliminated?  Most of the wrappers are
  definitely superfluous.  Can the WR byte order ever change?  ie are
  the cpu_to_wrXX() functions actually a useful abstraction?

- Most of cc_common.h can be removed -- eg CC_SLEEP, CC_PRINT are useless

- In ccil_api.h, rather than "#ifdef CC_LITTLE_ENDIAN" just use
  __constant_cpu_to_b32 or whatever.

  Most of the "PACKED" attributes are unnecessary (since the
  structures are already aligned).  They'll lead to horrible code with
  gcc on ia64 etc.

- In general, all the #ifdef X86_64 in the code looks like portability bugs.
  The best solution is just to make the code 32/64 clean, but at least
  we need to replace the test with #ifdef CONFIG_COMPAT

- ccilnet_dbg.c is an awful lot of code just for debugging.

- Get rid of compatibility with Linux 2.4 -- everywhere there's a test
  of LINUX_VERSION_CODE, just take the 2.6 code.

- cc_mq_common.c: BUMP is pretty inefficient, does a divide every time

- cc_qp_common.c: cc_memcpy8 corrupts FPU state, is it really needed?
  it's never called.  Why is it declared in cc_mq_common.c?
  memcpy4 similarly corrupts state.  If it's fixed to save CR0 and do
  clts, is it really faster than a normal memcpy (considering it also
  disables IRQs)?

  This is all utterly non-portably anyway -- there needs to be a
  standard fallback for PPC64, IA64 etc.

- Why is cc_queue.h needed?  What is <linux/list.h> missing?

- cc_types.h: get rid of NULL, TRUE, FALSE defines, cc_bool_t, etc.
  PTR_TO_CTX, CC_PTR_TO_64, etc seem busted on 64-bit archs.
  forget the macros, just cast to/from (unsigned long).

- devccil_adapter.c: adapter_list seems to be a latent bug -- why does
  the driver need to keep a global list of adapters?

- devccil.c: What is 'Static' -- why not 'static'??
  Probably all this code gets replaced by existing uverbs anyway.

- devccil_lock.h: Get rid of lock wrappers, they're just
  obfuscation. And it seems CCTHREADSAFE won't ever be defined??
  The driver should always be threadsafe.

- devccil_mem.c: ccil_big_malloc is horrible -- need a way to use
  non-contig memory.

- devccil_srq.c: CCERR_NOT_IMPLEMENTED stubs not needed -- the
  existing midlayer will return -ENOSYS for unimplemented functions
  (ie NULL pointers in ib_device method table).

- devccil_var.h: Defining your own version of PAGE_SHIFT etc. is just
  obfuscation; <linux/kernel.h> probably has all rounding functions
  you need.  Custom ASSERT() can probably just be replaced with
  standard BUG_ON().



More information about the general mailing list