All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: "Hefty, Sean" <sean.hefty@intel.com>
Cc: linux-kernel@vger.kernel.org, infiniband-general@lists.sourceforge.net
Subject: RE: [Infiniband-general] Getting an Infiniband access layer in theLinux kernel
Date: Mon, 9 Feb 2004 00:43:57 +0100	[thread overview]
Message-ID: <200402090044.14247.arnd@arndb.de> (raw)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 6 Feb 2004, Hefty, Sean wrote:

> We want to continue to discuss specific details about what's needed to
> add the code into the kernel.  Here's a list of modifications that I
> think are needed so far:
>
> * Update the code to make direct calls for atomic operations.
> * Verify the use of spinlock calls.
> * Reformat the code for tab spacing and curly brace usage.
> * Elimination of typedefs.

Some more hints:
* Understand how to use ioctls: Your current code can't possibly
  work in 32 bit emulation mode, e.g. when running i386 libs on ia64.
  You are also completely ignoring the ioctl 'command' argument.
* Try to reduce the number of necessary ioctls: 90 different commands
  for a single device is just overkill.
* Don't try to hide system calls behind a character device (/dev/cl_dev).
  Someone will find it sooner or later.
* Don't reimplement devfs (poorly), what your are trying to achieve is
  far easier done with a misc device and udev. call_user_mode_helper
  should only be used for running hotplug.
* Get rid of IN and OUT in declarations. If a pointer is const, it's an
  input.
* Declare functions static when they are only used in the file they are
  defined in. Put extern declarations into headers.
* put EXPORT_SYMBOL statements right next to the symbol, not in a seperate
  file.
* Information about drivers/devices should go to sysfs instead of procfs.
* Don't use vmalloc. 
* aside from spinlocks and atomics, there are some more files in complib
  that can easily be removed by using linux primitives directly (e.g.
  kmalloc, list_head, semaphore, work_queue)
* Use C99 named struct initializers instead of their deprecated gcc 
  counterparts.

> And, yes, knowing some of these issues up front will save the trouble of
> submitting code that will be immediately rejected.

Right, but that should not stop you from providing a BK tree or a diff
file that lets you build ibal in a linux tree. As a starting point, just
drop all of ibal and complib into some tree so people can look at it
without having to figure out how you are building stuff.

	Arnd <><
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFAJsm/5t5GS2LDRf4RArCIAJ9JEkinmx1yeSZQGS7X6rMaDYjuZwCgl9us
+7w/ZNbFl1ZAiLaIrp/rsso=
=repY
-----END PGP SIGNATURE-----


             reply	other threads:[~2004-02-08 23:49 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-08 23:43 Arnd Bergmann [this message]
  -- strict thread matches above, loose matches on Subject: below --
2004-02-24 17:55 [Infiniband-general] Getting an Infiniband access layer in theLinux kernel Woodruff, Robert J
2004-02-24 18:03 ` Greg KH
     [not found] <mailman.1076018705.12618.linux-kernel2news@redhat.com>
2004-02-09  1:51 ` Pete Zaitcev
2004-02-08 21:36 Woodruff, Robert J
2004-02-06 16:42 Hefty, Sean
2004-02-06 17:05 ` Richard B. Johnson
2004-02-06 17:23   ` Roland Dreier
2004-02-06 18:00     ` Richard B. Johnson
2004-02-06 18:12       ` Måns Rullgård
2004-02-06 18:13       ` Chris Friesen
2004-02-06 18:22       ` Valdis.Kletnieks
2004-02-06 18:50         ` Richard B. Johnson
2004-02-06 19:02           ` Matti Aarnio
2004-02-06 19:11           ` Petr Vandrovec
2004-02-07  3:05             ` Jamie Lokier
2004-02-06 18:54         ` Måns Rullgård
2004-02-06 19:01     ` somenath
2004-02-06 17:27 ` Troy Benjegerdes
2004-02-06 18:51 ` Greg KH
2004-02-08  8:31   ` Fab Tillier
2004-02-08 16:29     ` Greg KH
2004-02-08 16:51       ` Fab Tillier
2004-02-09  2:55         ` Troy Benjegerdes
2004-02-09  2:57         ` Greg KH
2004-02-06  4:07 Perez-Gonzalez, Inaky
2004-02-05 23:09 Woodruff, Robert J
2004-02-05 22:55 Woodruff, Robert J
2004-02-05 22:54 ` Randy.Dunlap
2004-02-05 22:26 Hefty, Sean
2004-02-05 22:40 ` Christoph Hellwig
2004-02-05 22:39   ` Randy.Dunlap
2004-02-05 23:19 ` Greg KH
2004-02-06  1:10 ` Troy Benjegerdes
2004-02-05 22:17 Tillier, Fabian
2004-02-05 22:56 ` Brian Gerst
2004-02-05 22:58 ` Bernd Petrovitsch
2004-02-05 22:02 Tillier, Fabian
2004-02-06  1:57 ` Troy Benjegerdes
2004-02-05 20:32 Tillier, Fabian
2004-02-05 21:27 ` Greg KH
2004-02-05 21:56   ` Chris Friesen
2004-02-06 20:22 ` Bill Davidsen
2004-02-05 19:26 Tillier, Fabian
2004-02-05 20:27 ` Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200402090044.14247.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=infiniband-general@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sean.hefty@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.