Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 3 Jan 2011 22:01:53 -0500
From:      Alexander Kabaev <kabaev@gmail.com>
To:        Jeff Roberson <jroberson@jroberson.net>
Cc:        arch@freebsd.org
Subject:   Re: Linux kernel compatability
Message-ID:  <20110103220153.69cf59e0@kan.dnsalias.net>
In-Reply-To: <alpine.BSF.2.00.1101031017110.1450@desktop>
References:  <alpine.BSF.2.00.1101031017110.1450@desktop>

next in thread | previous in thread | raw e-mail | index | archive | help
--Sig_/4KhrGAVoBU+Vq5xlvI9K._V
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Mon, 3 Jan 2011 10:31:24 -1000 (HST)
Jeff Roberson <jroberson@jroberson.net> wrote:

> Hello Folks,
>=20
> Some of you may have seen my infiniband work proceed in svn.  It is
> coming to a close soon and I will be integrating it into current.  I
> have a few patches to the kernel to send for review but I wanted to
> bring up the KPI wrapper itself for discussion.
>=20
> The infiniband port has been done by creating a 10,000 line KPI=20
> compatability layer.  With this layer the vast majority of the driver
> code runs unmodified.  The exceptions are anything that interfaces
> with skbs and most of the code that deals with network interfaces.
>=20
> Some examples of things supported by the wrapper:
>=20
> atomics, types, bitops, byte order conversion, character devices, pci=20
> devices, dma, non-device files, idr tables, interrupts, ioremap,
> hashes, kobjects, radix trees, lists, modules, notifier blocks,
> rbtrees, rwlock, rwsem, semaphore, schedule, spinlocks, kalloc, wait
> queues, workqueues, timers, etc.
>=20
> Obviously a complete wrapper is impossible and I only implemented the=20
> features that I needed.  The build is accomplished by pointing the
> linux compatible code at sys/ofed/include/ which has a simulated
> linux kernel include tree.  There are some config(8) changes to help
> this along as well.
>=20
> I have seen that some attempt at similar wrappers has been made
> elsewhere. I wonder if instead of making each one tailored to
> individual components, which mostly seem to be filesystems so far,
> should we put this in a central place under compat somewhere?  Is
> this project doomed to be tied to a single consumer by the specific
> nature of it?
>=20
> Other comments or concerns?
>=20
> Thanks,
> Jeff


This probably will go against popular opinion here, but having 10k
linux emulation layer that _almost_ work in the tree will be an
unfortunate event and will do more damage to FreeBSD as a platform than
good in the long run. I would rather see this code never hit main
repository.=20

--=20
Alexander Kabaev

--Sig_/4KhrGAVoBU+Vq5xlvI9K._V
Content-Type: application/pgp-signature; name=signature.asc
Content-Disposition: attachment; filename=signature.asc

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (FreeBSD)

iD8DBQFNIo2mQ6z1jMm+XZYRAs4GAJ4q/7LNwfJ6QzSFArE6caC3rlniAgCg1w3H
nfyav3zCcGw3RgeK8Bls8kM=
=aeYH
-----END PGP SIGNATURE-----

--Sig_/4KhrGAVoBU+Vq5xlvI9K._V--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110103220153.69cf59e0>