From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E4F2B1534E6; Wed, 16 Oct 2024 21:00:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1729112434; cv=none; b=IvZcDguZC2RYRT6PpbHmf/vmlj+oVtp5FH2fmkv5TA23SYh0ABQm6ny3mvZIZd6ACF697BxqLjW+K8hgPRhkLt+Kqovdx8rNbXSrAoVqE7k4M0qlP9DEn+3cDEPEl4NOzKxwHkbZzUKMAWaVgKDo8V/FI8LYNsNC87gqKXKOODc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1729112434; c=relaxed/simple; bh=1pAsDA7PZOVbb9GLjwzKBWAwHWtXQGNuCBsMyCdPVDk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=Fz1jVwGkiStoa24L/gAAnTjLJEXKLK+hrC09ph3aK2W2l0Ag+ZJy2TyAuYPJnEf9kJ4MOJ/qpRK8p+l0bOXyjFQimGhmdCEtvSorvMw9+ub7p1+J/gR9mF0kFgaQ5rzkOyowqGI/Nl0BEZKojEAzx5JO490gcA2V/vjAfTH3UdE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=nX1zh7Af; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=g3RIajQT; arc=none smtp.client-ip=193.142.43.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="nX1zh7Af"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="g3RIajQT" From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1729112431; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=xoaLcJKvIsnthAJTU0diSgpxqnBbNi4e4pwoTtNpLNw=; b=nX1zh7AfxO2eifrROVLWzzxW6Bu1RVj+gIiPqAWAuYVvpG1ucFZ1+6JO37cxZuEldxp3vI 3a+ReYqh/zIdXRwwsOcAfZY0SGX9abb3Pe9bbDv4dsK/XCuwG2knLv5Xt3vXZpR1BvekQY ELDBrCjxmwjRFr/QLYtiXv8DU/DVR/3uMKE08vKB5acLR6O0b3BtgZVJaj1/I+aiVU7QQJ Nb9RJM266/NnPx0E355NKMAruKpQsbKTiYgccjmwYYtX5yzAJ6P72JiZCye9Xg4sw8lm7/ R727jodCP43ftqmKWVxC4zznG3Vs004/jjInE8lVYj9PL6aeOOaOwYqIPBWkgA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1729112431; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=xoaLcJKvIsnthAJTU0diSgpxqnBbNi4e4pwoTtNpLNw=; b=g3RIajQTjPkOnSr7MIboQCHDizU0oU84eKVHhdaNVFgyr41NSzBVPNqdBS3ShTjaXycUyL 0TdB+RD2HN5S2ZDg== To: Boqun Feng Cc: Dirk Behme , Lyude Paul , rust-for-linux@vger.kernel.org, Danilo Krummrich , airlied@redhat.com, Ingo Molnar , Will Deacon , Waiman Long , Peter Zijlstra , linux-kernel@vger.kernel.org, Miguel Ojeda , Alex Gaynor , Wedson Almeida Filho , Gary Guo , =?utf-8?Q?Bj?= =?utf-8?Q?=C3=B6rn?= Roy Baron , Benno Lossin , Andreas Hindborg , Alice Ryhl , Trevor Gross Subject: Re: [PATCH v6 0/3] rust: Add irq abstraction, SpinLockIrq In-Reply-To: References: <20240916213025.477225-1-lyude@redhat.com> <875xpvhlgm.ffs@tglx> Date: Wed, 16 Oct 2024 23:00:30 +0200 Message-ID: <87iktrahld.ffs@tglx> Precedence: bulk X-Mailing-List: rust-for-linux@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain On Sun, Oct 13 2024 at 14:43, Boqun Feng wrote: > On Sun, Oct 13, 2024 at 09:06:01PM +0200, Thomas Gleixner wrote: > But that makes `cv.wait()` not working, because interrtups would be > still disabled when schedule() is called. > > I'm waiting for Lyude's new version (with lock_first(), and > unlock_last()) to see how we can resolve this. We may need to redesign > `CondVar::wait`. Thinking more about this. I think there is a more general problem here. Much of the rust effort today is trying to emulate the existing way how the C implementations work. I think that's fundamentally wrong because a lot of the programming patterns in the kernel are fundamentally wrong in C as well. They are just proliferated technical debt. What should be done is to look at it from the rust perspective in the first place: How should this stuff be implemented correctly? Then you work from there and go the extra mile to create some creative workarounds at the abstraction level instead of trying to mimic the existing C nonsense. Which in turn gives you a way cleaner pattern of implementing stuff in rust. Stop worrying about mostly irrelevant low level details which are not relevant to the primary audience of rust adoption. We can worry about them when we replace the scheduler and the low level interrupt handling code ten years down the road. Please focus on providing a sane and efficient programming environment to get actual stuff (drivers) into the rust domain. Thanks, tglx