Linux kernel API wrapper: using OFED's one in other drivers

[Konstantin Belousov]

On Mon, Sep 08, 2014 at 11:57:37AM +0200, Jean-S??bastien P??dron wrote:
> Hi!
> 
> OFED (sys/ofed) comes with a Linux kernel API wrapper. Beside OFED
> itself, it's currently used in sys/dev/cxgb and sys/dev/cxgbe.
> 
> I'm playing with this wrapper to add a new feature to the i915 GPU
> driver [1]. Don't pay attention to the current patch as this is not the
> final approach I have in mind. However, the idea is there: I'd like to
> use it in sys/dev/drm2.
> 
> The benefit of using such a wrapper in the DRM drivers are obvious:
>     1. It greatly reduces the diff between FreeBSD code and Linux
>        original code.
See below.

>     2. It speeds up the integration of new changes in FreeBSD.
>     3. It eases the report of bugfixes to Linux.
> 
> Those arguments are true for any driver. But in this particular case,
> this would allow us to reduce the gap with Linux in the graphics stack
> area more quickly (and we deeply need that). DragonFlyBSD is already
> doing that.
> 
> Of course, using this wrapper as it is today isn't practicle: the code
> is located in a driver and it's not even part of GENERIC. The proposal
> is to move it outside of OFED and add it to GENERIC.
> 
> I don't have a patch to show yet. I'd like to get feedback first. What
> do you think about that? OFED maintainers, would you be ok?
> 
> [1] https://wiki.freebsd.org/Graphics/Add_HW_context_support_to_i915

My main objections to use OFED wrappers for drm2 are:

1. It tightly binds different drivers with non-coordinating maintainers
   to the version of the Linux KPI.  The Linux drivers interface is not
   known for its stability, and constant drift there in both formal
   spelling of interfaces and in semantic requires to have all drivers
   using the wrapper to be at the same upstream version.

   This objection is not specific to drm code, but so far we only speek
   about infiniband and drm.

2. This cause is probably very drm-specific.  Comparing with infiniband,
   drm integration with very core of the FreeBSD kernel is quite
   significant.  In particular, its coupling with the VM subsystem
   has no prior examples among the drivers, even if you consider the
   removed zero-copy sockets code or any driver providing dev_mmap
   cdevsw method. Even NVidia blob did not got that level of integration
   with the VM, but probably would benefit from it.  The only remotely
   close example is vbox, but I usually avoid reading that code.

   I mean things like managed fictitious pages, new device pager
   page fault handler, or CPU cache management.  All of this is used
   both by i195/GEM and TTM.

   With the use of the listed facilities, ported driver code 'feels' like
   FreeBSD code, not Linux code.  Mix of the Linux KPI-compatible wrappers
   for shallow facilities, and native interfaces for anything more
   involved, makes the code which is hard to understand for either FreeBSD
   or Linux developers.  This was the reason why I selected the
   'no wrappers' approach for initial port of GEM, and continue to
   prefer it now.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20140908/806ac2f1/attachment.sig>