Re: Fwd: Adding crates

[Greg KH <gregkh@linuxfoundation.org>]

On Wed, Mar 30, 2022 at 11:03:50AM +1100, Chris Suter wrote:
> Hi Miguel,
> 
> On Wed, Mar 30, 2022 at 2:47 AM Miguel Ojeda
> <miguel.ojeda.sandonis@gmail.com> wrote:
> >
> > On Tue, Mar 29, 2022 at 9:49 AM Chris Suter <chris@sutes.me> wrote:
> > >
> > > I'm interested in quite a few crates but the first and perhaps most
> > > significant would be futures. I'm not necessarily looking for a
> > > "generic" solution at this point, any solution would do — just enough
> > > to help me make a little progress and then maybe I could contribute
> > > back later. I can probably figure it out myself, but I was hoping to
> > > save some time.
> >
> > If you are just looking to experiment with some third-party crates,
> > then as mentioned in the other thread, what you could do is copy and
> > adapt the code. For instance, if the crates you need do not use Cargo
> > build scripts, this may be as simple as copying the sources of the
> > Rust modules into your kernel module (which is a crate), so that you
> > do not need to deal with build systems.
> 
> I'm working with an existing code base and there are quite a few
> crates I need to bring in or find replacements for. I'm hoping to
> minimise or isolate the changes I need to make to the existing code
> base. Obviously, some changes are going to be unavoidable.

What type of existing Rust codebase should be ported to be inside the
kernel?

> > But if you are looking to do something else, then please note there is
> > no plan to add support for building/linking against third-party
> > crates. This is why we ask what crates would be useful and why -- so
> > that we can consider adding similar facilities to the kernel (possibly
> > importing those third-party crates).
> 
> Like I said, I'm interested in futures. Why it's useful: async Rust is
> arguably more common and easier to use than other forms of
> multi-threaded processing. Other crates that I'd like: anyhow,
> bincode, byteorder, log, once_cell, pin-project, rand, serde, slab,
> static_assertions, uuid plus some more esoteric ones.

Almost none of those make sense when you are writing kernel code.  Are
you sure you want all of this within the kernel itself?

What does this codebase do?  Have a link to it anywhere?

thanks,

greg k-h