On Mon, 2008-07-28 at 09:17 -0500, Troy Benjegerdes wrote: > > Maybe a lot less painful for Sun support ;)
No. I specifically meant less painful on the implementer. It's not really any more difficult on Sun for you to use whatever kernel you want to use. > But what if you need a new RDMA NIC > driver that actually *works* in 2.6.26, and is completely busted in a > vendor/distro kernel. Well, that's really no different than any of the rest of the FOSS world. If you want to use bleeding edge hardware, there are always pains associated. There is support in the distro kernels for a good number of working RDMA capable NICs. > Is Debian a supported distro? No. > And if not, why? Simply no customer demand. Like *everything* else in this world, we are a limited resource and we have to allocate that resource where it is most effective. > It seems that making > debian policy compliant Lustre server packages would be a good excercise > for code and packaging quality. Somebody already does that. http://packages.debian.org/source/lenny/lustre http://packages.debian.org/source/sid/lustre > I haven't keep up on linux-kernel lately, but is there some fundamental > reason that Lustre *still* requires kernel patches that don't have a > path into the mainline kernel tree? Yes. Performance and scalability. The mainline kernel lacks a number of facilities we need to achieve the performance and scalability that we do. We have worked toward getting our changes into the kernel in the past but have been continually rejected for one reason or another. I'm not going to speculate why this has been but you can search lkml for the gory details if you like. b.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Lustre-discuss mailing list [email protected] http://lists.lustre.org/mailman/listinfo/lustre-discuss
