![]() | |||||||||||||
Messages in this thread |
> -----Original Message----- > From: Greg KH [mailto:greg@kroah.com] > Sent: Sunday, February 08, 2004 8:30 AM > > On Sun, Feb 08, 2004 at 12:31:56AM -0800, Fab Tillier wrote: > > > > I think there is value in allowing the code to be shared between > > kernel mode and user mode. Would using a macro that resolve to the > > native kernel spin lock structure and functions be acceptable? > > Probably not, just use the in-kernel call, and be done with it. If you > _really_ want to share code between userspace and the kernel, keep a > different version of it somewhere else. Are you suggesting branching the user mode code from the kernel mode code? Duplication is not the same as sharing code - you have twice the number of places that require fixing in the event of a bug. If we can help it, we'd like to avoid this. > > Why do you want to run your code in both places? Does this mean that it > doesn't even really need to be in the kernel as it works just fine in > userspace? IBAL provides APIs for accessing InfiniBand resources in both the kernel and in user-mode. Those APIs are identical, and many of the files are shared between user and kernel mode. In the kernel, storage drivers, network drivers, and SDP interface to the kernel IBAL driver. In user mode, the subnet manager, uDAPL, MPI, and other IB-enabled applications interface to the user-mode IBAL library. The reason a user-mode library is provided is that InfiniBand provides mechanisms to bypass the kernel for speed path operations - send, receive, and completion processing - similarly to VI. Bypassing the kernel for these operations helps provide higher bandwidths and lower latencies to applications. The user-mode IBAL library depends on the kernel mode IBAL driver to setup InfiniBand resources for use, and for the operations that can't be offloaded, like memory registrations. Further, the kernel IBAL driver tracks user-mode resources on a per-process basis to ensure they are freed if an application seg faults. This is a must so that things like memory registrations get cleaned up and the associated memory unlocked even in abnormal application termination situations. I hope this clears up why code is shared between user-mode and kernel mode. - Fab - 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/ | ||||||||||||
| Last update: 2005-03-22 14:00 [from the cache] ©2003-2008 | |||||||||||||