[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <E19BB1F6-8749-4EFA-AC6F-F77C0C5BF07C@kloenk.dev>
Date: Thu, 8 Jul 2021 10:29:59 +0200
From: Finn Behrens <finn@...enk.dev>
To: Geert Stappers <stappers@...ppers.nl>
Cc: Matthew Wilcox <willy@...radead.org>,
rust-for-linux <rust-for-linux@...r.kernel.org>,
linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 00/17] Rust support, NVMe
> On 8. Jul 2021, at 08:39, Geert Stappers <stappers@...ppers.nl> wrote:
>
> On Thu, Jul 08, 2021 at 01:58:32AM +0100, Matthew Wilcox wrote:
>> On Wed, Jul 07, 2021 at 10:56:57PM +0200, Finn Behrens wrote:
>>> There is a more general use driver (network dummy) still in the
>>> making, It is fully operational, just the documentation of the rust
>>> bindings are not finished yet, so it is not merged into the rust
>>> tree yet, also I have to rebase it.
>>
>> Why are you so resistant to writing a real driver that deals with actual hardware?
>
> } Why are we so resistant to writing a real driver that deals with actual hardware?
>
> It is not dodging hardware, it is universal available.
>
>
>> A simple NVMe driver is less than a thousand lines of C.
>> I know the one in the kernel now is ridiculously complicated and has
>> been thoroughly messed up with abstractions to support NVMeoF instead
>> of having a separate driver, but it's really a simple interface at heart.
>
> Summary of https://qemu.readthedocs.io/en/latest/system/nvme.html
>
> NVMe hardware is universal available.
>
I actually don’t have a clue how nvme works, that is my reason to not write a nvme driver. But, I’m currently writing a rust version of e1000. This is also available in qemu and is real hardware. This is sadly taking quite some time, as I don’t have a good linux kernel development setup currently.
>
>
>
> Groeten
> Geert Stappers
> --
> Silence is hard to parse
CU,
Finn
Powered by blists - more mailing lists