Date: Thu, 06 Jan 2011 11:46:37 -0700 From: Warner Losh <imp@bsdimp.com> To: freebsd-arch@FreeBSD.org Subject: Re: Linux kernel compatability Message-ID: <4D260E0D.8080003@bsdimp.com> In-Reply-To: <20110106140722.E14966@maildrop.int.zabbadoz.net> References: <82826.1294088199@critter.freebsd.dk> <alpine.BSF.2.00.1101031343210.1450@desktop> <20110106140722.E14966@maildrop.int.zabbadoz.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 01/06/2011 07:17, Bjoern A. Zeeb wrote: > On Mon, 3 Jan 2011, Jeff Roberson wrote: > >> Unfortunately it would create quite a lot of code churn as there are >> relatively few that are minorly different. You can page through the >> wrapper code if you're interested. >> >> http://svn.freebsd.org/viewvc/base/projects/ofed/head/sys/ofed/include/linux/ >> > > One thing I am not too sure about is sys/ofed. Given the entire > discussions it might well be better suited in sys/contrib/ofed under > the assumtion that the code is mostly maintained outside our tree and > we get in occational updates. If you look at what Jeff has done, you'll see that the external code follows our standards of residing in sys/contrib/ofed, while the code that glues it into the tree is in sys/ofed. > I hadn't quite liked the sys/cddl but given that we had sys/gnu as > well. And then there is sys/compat. A slight case could be made for sys/compat/linux, but that is already taken. > I wonder if you could still or maybe not make the shim layer something > like it's own .ko kind of like opensolaris.ko (you cannot name it > linux.ko though;) I'd actually prefer that we not do this. opensolaris.ko made sense because we have zfs and dtrace, and even that causes problems as we get version skew between them... > I guess similarly things in user space might go to contrib as well? src/contrib is for code that's maintained outside the source tree that we adapt. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4D260E0D.8080003>