Greg, The component library (the abstraction layer used by IBAL) is in no way tied to InfiniBand. Whatever is in there can be used by any other projects, and there's a lot of useful stuff in there that does provide value. One goal of IBAL is to get InfiniBand support for Linux. As such, it is a higher priority to get things working than to wait for changes to appear in the Linux kernel before making forward progress. Keep in mind also that InfiniBand is not a Linux-only technology. Sharing code between different operating systems accelerates development and reduces the cost of maintenance. Lastly, there are things (like timers) that are blatantly missing from user-mode in Linux, and having an abstraction here allows code to be shared between kernel and user mode. Keep in mind that we're not expecting you or the Linux community to blindly take the code as is. We're looking for constructive feedback to make it so that everyone goes home happy. It's disappointing that the feedback we're getting from you is that any abstractions will be cause for rejection. What are the grounds for this policy? What does it accomplish? Is portable code a problem for the Linux community in general? Removing the abstraction from the IBAL project would require significant rework of the code that would add very little from a functional perspective, and make the code base more complicated and harder to maintain. I think it would help us a lot to understand the motivation behind your opinions so that we can try to meet your expectations. If I've misinterpreted your opinions, please clarify. Thanks, - Fab -----Original Message----- From: Greg KH [mailto:greg _at_ kroah.com] Sent: Thursday, February 05, 2004 10:41 AM To: Tillier, Fabian Cc: Hefty, Sean; linux-kernel _at_ vger.kernel.org; Troy Benjegerdes; Woodruff, Robert J; Magro, Bill; Woodruff, Robert J; infiniband-general _at_ lists.sourceforge.net Subject: Re: [Infiniband-general] Getting an Infiniband access layer in the Linux kernel On Thu, Feb 05, 2004 at 01:31:45PM -0500, Tillier, Fabian wrote: > > Are you suggesting that if there is any abstraction, the code will never > be accepted? Or rather that the abstraction better be correct? I'm > hoping for the latter, however please clarify. The kernel has its own abstractions that seem to be working quite well for all different types of platforms. There is no need for you to create your own, just for a driver subsystem. If you have found any problems with the current locks please let the entire kernel community benefit from your changes, and not relegate them to a infiniband-only section of the kernel. So yes, if you add your own versions of spinlocks and atomic_t types, your code will be rejected, among other things :) thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo _at_ vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Follow-Ups:
- Prev by Date: RE: [Infiniband-general] Getting an Infiniband access layer in the linux kernel
- Next by Date: Re: [PATCH] powernow-k8 max speed sanity check
- Previous by thread: RE: [Infiniband-general] Getting an Infiniband access layer in the linux kernel
- Next by thread: Re: [Infiniband-general] Getting an Infiniband access layer in the Linux kernel
- Indexes:[Main][Thread]