Re: [PATCH 3/3] kthread: Stop abusing TASK_UNINTERRUPTIBLE (INCOMPLETE)

[Wedson Almeida Filho]

On Tue, Jun 28, 2022 at 09:58:43AM +0200, Peter Zijlstra wrote:
> On Tue, Jun 28, 2022 at 12:32:33AM +0000, Wedson Almeida Filho wrote:
> > Peter, I meant to ask in my previous email: setting aside the syntax for
> > a moment, do you have an opinion on the sort of things that Rust allows
> > us to enforce at compile time (as exemplified in the new_paused()
> > fragment)?
> 
> So I used to do quite a lot of C++ in a previous life; I think I'm more
> or less familiar with a lot of the things Rust offers, except it is a
> lot stricter. C++ allows you to do the right thing, but also allows you
> to take your own foot off (a bit like C, except you can make an even
> bigger mess of things), where Rust tries really hard to protect the
> foot.

That's a fair assessment. I'd just like to emphasise one aspect: if I
shoot myself on the foot with Rust, it's either a bug in the compiler or
because I violated a precondition of an unsafe block.

> The one thing I dread is compile times, C++ is bad, but given Rust has
> to do even more compile time enforcement it'll suck worse. And I'm
> already not using clang because it's so much worse than gcc.

Yes, it's definitely going to be slower, but I think this is a good
tradeoff: I'd rather have checks performed when compiling than when
running the kernel.

One thing that may speed things up is to disable the borrow checker when
compiling a known-good revision. I don't think rustc allows this but
rust-gcc doesn't implement borrow checking at all AFAIU, so we could
presumably ask them to add a flag to keep it disabled (when/if they
decide to implement it) in such cases.

> I've just not had *any* time to actually look at Rust in any detail :/
> 
> But given I'm the kind of idiot that does tree-wide cleanups just
> because it's the right thing, I'm bound to run into it sooner rather
> than later, and then I'll curse my way through having to learn it just
> to get crap done I expect ...

Looking forward to this :)

Jokes aside, when the day comes, I'm happy to discuss anything that
doesn't seem to make sense.
 
> Anyway; from what I understand Rust is a fair way away from core code.

Indeed. However, we do want to expose core APIs (like paused thread
creation) to developers writing Rust code, so while the implementation
will remain in C, we'll implement the _API_ for a bunch of core code.

Cheers,
-Wedson