nouveau.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Ilia Mirkin <imirkin@alum.mit.edu>
To: Karol Herbst <kherbst@redhat.com>
Cc: "nouveau@lists.freedesktop.org" <nouveau@lists.freedesktop.org>
Subject: Re: [Nouveau] How to reverse engineer a PCI-Express driver under Linux ?
Date: Wed, 3 Mar 2021 08:09:24 -0500	[thread overview]
Message-ID: <CAKb7UvgDGDJdVW_P_-rZCXqPo9b6yhcTAjCSF2FOOrhJ4ek5xA@mail.gmail.com> (raw)
In-Reply-To: <CACO55tta_jVwHAr3zgE38yJbTUHjcMEmx4kY6cSiRqK8GLe9pQ@mail.gmail.com>

On Wed, Mar 3, 2021 at 5:30 AM Karol Herbst <kherbst@redhat.com> wrote:
>
>
>
> On Wed, Mar 3, 2021 at 11:07 AM Tomek LECOCQ <tomek.lecocq@hotmail.fr> wrote:
>>
>> Hello,
>>
>> I’ve already asked this on the Kernel Newbies mail list, but as developing nouveau seems to be kind of similar to what I want to achieve, I thought it would be a good idea to ask it here as well.
>>
>> I have a PCI-Express video capture card that has a proprietary driver for Linux.
>> I have some experience with programming in C, and so I would like to start a hobby project to develop a free/libre driver for this device for Linux.
>> Of course I don’t have access to any documentation about how to communicate with this device (I’ve tried to contact the company making these, but my hopes are not high), so I think I will need to reverse-engineer the way the existing driver communicates with the hardware. How could I achieve this ?
>>
>
> Usually drivers map PCIe bars into the VM and read/write at certain offsets to do.. stuff. In the linux kernel we have the mmiotrace tracer in order to capture what a driver does with the hardware. You still need to interpret the trace file, but at least this should give you the raw data on what's going on. Hope that helps.

Here's a good guide on how to use mmiotrace. It's nvidia-focused, but
the same steps would apply to any driver:
https://wiki.ubuntu.com/X/MMIOTracing

Basically, start mmiotrace, load target driver, do some stuff, stop
mmiotrace, analyze the resulting trace.

We have some tooling to help with that -- envytools/rnn/demmio will
parse the mmiotrace against a given rnndb (also in envytools). You
won't be able to reuse our rnndb, but you'd be able to build up your
own. You also wouldn't be able to use demmio directly, but you could
see how it works and modify it to your hw's needs. (e.g. it waits for
a read of the "0" mmio reg to determine which chip is being traced,
and loads up the appropriate rnndb settings - that won't work with
your hw out of the box.)

>> Also, the long term goal of this project would be to have this driver merged into mainline, so what is allowed or not while doing this to avoid problematic legal ramifications ?

This isn't legal advice (for that, consult a lawyer), however a few
things that are definitely going to get you into trouble:

 - stealing (or using stolen) documentation
 - de-compiling target driver and copying its implementation (as that
would be subject to copyright)

A semi-common technique is to use a so-called "chinese firewall", e.g.
one person/team de-compiles, writes documentation, and then a second
person/team uses that documentation to implement a driver. That way no
copying of copyright-able content occurs, and no one can claim that
the implementer had access to the copyrighted materials and thus could
copy without even trying to. But it all depends on the target company
(and jurisdictions in question) -- if they're particularly litigious,
they could sue you for breathing air -- doesn't matter that their case
has no merit, you'd still be stuck defending yourself.

Cheers,

  -ilia
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

  reply	other threads:[~2021-03-03 13:09 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-03 10:07 [Nouveau] How to reverse engineer a PCI-Express driver under Linux ? Tomek LECOCQ
2021-03-03 10:30 ` Karol Herbst
2021-03-03 13:09   ` Ilia Mirkin [this message]
2021-03-03 14:44     ` Tomek LECOCQ

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAKb7UvgDGDJdVW_P_-rZCXqPo9b6yhcTAjCSF2FOOrhJ4ek5xA@mail.gmail.com \
    --to=imirkin@alum.mit.edu \
    --cc=kherbst@redhat.com \
    --cc=nouveau@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).