On Fri, Jun 07, 2024 at 02:36:50PM +0200, Greg KH wrote:> On Fri, Jun 07, 2024 at 09:11:32PM +0900, FUJITA Tomonori wrote:
> > Hi,
> >
> > On Fri, 31 May 2024 11:59:47 +0200
> > Danilo Krummrich <dakr at redhat.com> wrote:
> >
> > > Once we get to a conclusion I can send a series with only the
device and firmare
> > > abstractions such that we can get them in outside of the scope of
the reset of
> > > both series to get your driver going.
> >
> > Since your discussion with Greg seems to continue for a while, let me
> > include the following patch that Greg approved with the next version
> > of the PHY driver patchset.
>
> Yes, please take this one now. We can build on it from there.
This patch still contains the points *you* are discussing on the original one.
Why do I spend my time on this discussion if those points don't seem to
matter
for you now?
Also, why would we want to have this patch (and the firmware one) in two
separate submissions? If we urgently want to land the firmware abstractions I
can send a separate series with just the device and firmware abstraction
patches.
>
> I had a meeting yesterday with a lot of rust kernel and userspace people
> at Microsoft and talked a bunch about this and how to move forward. I
> think we need to take much smaller "steps" and even encourage
most
> drivers to start out as a mix of c and rust as there is no real
> "requirement" that a driver be "pure" rust at all.
This should both
> make the interface logic simpler to start with, AND provide a base so
> that people can just write the majority of their driver logic in rust,
> which is where the language "safety" issues are most needed, not
in the
> lifecycle rules involving the internal driver model infrastructure.
What do you mean by "drivers to start out as mix of C and Rust".
I don' think this is desireable. Writing abstractions for C core
infrastructure
already is a lot of effort and sometimes rather difficult in certain aspects,
(e.g. align lifetimes).
An immediate concern I have is that this is an invitation for drivers to write
their own abstractions, as in interfacing with C core infrastructure in C and
and do a driver specific abstraction.
>
> Anyway, that's all hand-wavy right now, sorry, to get back to the point
> here, again, let's take this, which will allow the firmware bindings to
> be resubmitted and hopefully accepted, and we can move forward from
> there to "real" things like a USB or PCI or even platform device
and
> driver binding stuff.
The abstractions for that are on the list and in the sense of what you say above
for "smaller steps, they are quite minimal. I don't see how we could
break this
down even further.
>
> thanks,
>
> greg k-h
>