Thread-Index: AcYNakO+oLJSxaLcS7GqR2MdE3kouQ==
Date: Fri, 30 Dec 2005 00:00:02 -0800
Content-Transfer-Encoding: 7bit
From: "Greg KH" <greg@kroah.com>
To: "Bryan O'Sullivan" <bos@pathscale.com>
Cc: <linux-kernel@vger.kernel.org>, <openib-general@openib.org>
Content-Class: urn:content-classes:message
Importance: normal
Subject: Re: [PATCH 0 of 20] [RFC] ipath - PathScale InfiniPath driver
Message-ID: <20051230080002.GA7438@kroah.com>
References: <patchbomb.1135816279@eng-12.pathscale.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <patchbomb.1135816279@eng-12.pathscale.com>
User-Agent: Mutt/1.5.11
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1286
Lines: 35

On Wed, Dec 28, 2005 at 04:31:19PM -0800, Bryan O'Sullivan wrote:
> 
> There are a few requested changes we have chosen to omit for now:
> 
>   - The driver still uses EXPORT_SYMBOL, for consistency with other
>     code in drivers/infiniband

Why would that matter?

>   - Someone asked for the kernel's i2c infrastructure to be used, but
>     our i2c usage is very specialised, and it would be more of a mess
>     to use the kernel's

Why is this?  What is so messy about the in-kernel i2c interfaces?
(yeah, I know that there are some oddities, just want to know what you
specifically are not liking...)

>   - We're still using ioctls instead of sysfs or configfs in some
>     cases, to maintain userspace compatibility

Compatibility with what?  The driver isn't in the kernel tree yet, so
there's no old kernel versions to remain compatibile with :)

I also noticed that you are still using the uint64_t type variable
types, can you please switch to the proper kernel types instead (u64 in
this specific example.)

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/