From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dl1-f49.google.com (mail-dl1-f49.google.com [74.125.82.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7B7E13191C4 for ; Thu, 26 Feb 2026 23:47:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772149660; cv=none; b=GrD8AD3rzCuRbHj44sDBu0HwuENC25JaPv1BPcPgwNIJ+Mue2ESK7VHouNorICd6Goz9xqH8YJnmcGSkiISf4OPGrlAZlNSE4gO5tQDs9nGw4Ddlaz9jEyDUCyxNybPPmBj6tQPFNPLtcPgHc+2uDLIwJCSXRw6+mnDY6t5xBUk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772149660; c=relaxed/simple; bh=2JZ14oqyop+OfbJKe2VgqDVfV2Lq3g8h2Qdja2yt5Oo=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type; b=eUpcTmzRPNmCYzlkjPO9pnfRufKk6R8Yty4dspU2H6kB0V6Qqv57mo4EBS69OTpH2CMmj4f5FelSs/B6MvMlBfn3j12w1yJ748pOag4NBunO/NtL4FGF6cciQ2Qyn1ypT6Mh+CEcqvxY58otrRpoCaDhGu5AnuP6zNI+YOtxBm0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=ENCSd3cU; arc=none smtp.client-ip=74.125.82.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="ENCSd3cU" Received: by mail-dl1-f49.google.com with SMTP id a92af1059eb24-127380532eeso3260940c88.1 for ; Thu, 26 Feb 2026 15:47:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772149658; x=1772754458; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=/k9W3puS9VlvVSvbP2i2HOOhKsYSW79uIt5oIhUdqFY=; b=ENCSd3cUnMGC1ERlOrIePmspmhoZmbfuT66oU4+H3HFMbQ7Zrv5Mi711Y3YzsB2sNn DYJBxyL18UrykZbkVR10gESg6yOhLa0m2itDCSv7rDMyEbQcm5exnfXI6gugOZkFRL+W O4aoALh4Fl303a7aqKCGjyCjtMcfuqvVROO5PGmgXu4UYnb77myZ1Qf5KLVwruvD64Z8 AClqDPXoeIvsA2GAyWstZKGKYyr6dJFaevuWhW2omHdzPgcJ7NJ2JLUxWa5Ot0uvzHI5 ZlUYbeQh6UpwckSfLe0sAKyAHEVsQ36S4BFXERPnsuDXcXJRerPszYJsV/fWWOjU4TK/ rupA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772149658; x=1772754458; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=/k9W3puS9VlvVSvbP2i2HOOhKsYSW79uIt5oIhUdqFY=; b=IkBZTOGerSYVotY12IQCyUghsERi0WYFw/QV4+ig00ZweEGEM2Muv6WMQcDyvJIoHK cxfs2w2RY2cJ3YNCntmujbTmKZ6P0mYgNiphBuEIOCfP4vmCrrzb2/U/xBcfSxuui+ty cTBxkBz9bvtQCdHk887NHmSqRF2O3Kq4pgVCLTHqVvdYJcLKMXO5McsNkuc2kMif0cQ9 weqCWfeCo+FVuRXVi/vueHp0uG3Pbvlm2t8mcW02RV/I17NrcDIjWVaYzoI50hKD+xwQ WyYAgHganvN5jrgddZvRIuCq9iAna32k3N08xGDHnswmkpIHJkGCtBaa+WX6YUKy/CkK l3zQ== X-Forwarded-Encrypted: i=1; AJvYcCUx5n33yQi/eLsOBuq/AIwZu2IEU0nSdnTtTo6DIS9yMCesl95nfLVLHKBPzl9Awey1Z/9w7p4Zu+T9EOA=@vger.kernel.org X-Gm-Message-State: AOJu0Yx/xslggB1oU/UYAge7OggnQbl0C9T1H7TfMWnFxtKfgIcHbnhg hoT5680Nf25BdBDd9GIbBBAPlAkfNzK7QLmvuuDMMP41zPHaDwQEfTR3 X-Gm-Gg: ATEYQzynWy19bKAUYOrX9mMZ2pCE2VNMZCFToii7ppEzSfPZr9/VxFh0napStgwvcQ1 uA1KDIWInTWGbe2WI69roVhYRWj99t1IOnovEk5CMT5WnG2stdboZ2K3R9qsmA7oa6HJjZTSxhJ 9X+2A5NxFH6U/n7tS5j8RcwPHSNIE51aEUYVRvqEjndqQLfKtQwmbeQTC8YGvK8Mub6BUHwJKlF J1EepWCruef5KWRKt9iB6kjD0EIfk0f2aNoDOmwWra0dQCRBFew30mneGdYOEsh+84juFddVtY3 bxST28pnkKPKl0K/3l5VQtnV9FCd3xGL+6SudaZb7wLo8ABuomtYiY12Kwk2bSKsbuHCOGBduTW iuYxhLUKoLoXEvD7Lkk8MZUUJ2LmcW11GWysy25vLrDF/p5j44uYCB5T+nG+x4BdhdCqeAHOpKo /5OxQe89orH+NgHIUuYt0Fgb3mNrXOlKDJi77va4ZtGwUhW9mUOhmjsRdUEiM8lOwwb2SXxWPDG g== X-Received: by 2002:a05:7022:4583:b0:127:5cda:fb7d with SMTP id a92af1059eb24-1278fc2c5fbmr491113c88.6.1772149657533; Thu, 26 Feb 2026 15:47:37 -0800 (PST) Received: from localhost (99-122-55-39.lightspeed.sntcca.sbcglobal.net. [99.122.55.39]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-127899df391sm3990909c88.5.2026.02.26.15.47.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 26 Feb 2026 15:47:37 -0800 (PST) From: Matthew Wood To: Miguel Ojeda , Luis Chamberlain , Petr Pavlu , Daniel Gomez , Sami Tolvanen Cc: Aaron Tomlin , Boqun Feng , Gary Guo , =?UTF-8?q?Bj=C3=B6rn=20Roy=20Baron?= , Benno Lossin , Andreas Hindborg , Alice Ryhl , Trevor Gross , Danilo Krummrich , Tamir Duberstein , David Gow , =?UTF-8?q?Jos=C3=A9=20Exp=C3=B3sito?= , linux-modules@vger.kernel.org, rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH 0/8] rust: module parameter extensions Date: Thu, 26 Feb 2026 15:47:26 -0800 Message-ID: <20260226234736.428341-1-thepacketgeek@gmail.com> X-Mailer: git-send-email 2.52.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This series extends the Rust module! macro with three capabilities that are available to C modules but currently missing from the Rust abstractions: string parameters, early boot command-line parameters, and configurable initcall levels. The existing Rust module parameter infrastructure supports integer types (i8..u64, isize, usize) but has no way to accept string values. Additionally, built-in Rust modules cannot register parameters for early boot command-line parsing (__setup / early_param), and all Rust modules are hard-coded to initcall level 6 (device_initcall) with no way to control initialization ordering. String parameter support (patches 1-3): Introduce StringParam, a Copy wrapper around *const c_char whose memory is managed by the kernel parameter subsystem. Wire it into the module! macro as the `string` parameter type with a dedicated kernel_param_ops (PARAM_OPS_STRING) that stores the pointer directly into a SetOnce container. The rust_minimal sample is updated to demonstrate usage. An earlier implementation of string parameter support was proposed in: https://github.com/Rust-for-Linux/linux/pull/110/ This series takes a different approach for StringParam by storing the raw C string pointer directly rather than copying the string data, since the kernel guarantees the backing memory remains valid for the module's lifetime. This avoids allocation in the parameter setter and keeps StringParam as a simple Copy type consistent with the existing integer parameter design. Early boot parameter support (patches 4-7): Add ObsKernelParam (mirroring the C obs_kernel_param), extend the ModuleParam trait with from_setup_arg() for constructing parameter values from raw __setup callback arguments, and integrate an optional `early_param` field into the module! macro. When specified, the macro emits a __setup entry in the .init.setup ELF section, gated behind #[cfg(not(MODULE))] since this mechanism is only meaningful for built-in modules. Configurable initcall levels (patch 8): Add an optional `initcall` field to the module! macro that accepts any of the eight standard levels (pure through late). The default remains level 6 (device) so existing modules are unaffected. Matthew Wood (8): rust: module_param: add StringParam type for C string parameters rust: module_param: wire StringParam into the module! macro samples: rust_minimal: demonstrate string module parameter rust: module_param: add ObsKernelParam type rust: module_param: add from_setup_arg() to ModuleParam trait rust: macros: add early_param support to module! macro samples: rust_minimal: demonstrate early_param usage rust: macros: add configurable initcall levels to module! macro rust/kernel/module_param.rs | 160 +++++++++++++++++++++++++++++++ rust/macros/lib.rs | 9 ++ rust/macros/module.rs | 179 +++++++++++++++++++++++++++++++++-- samples/rust/rust_minimal.rs | 33 ++++++- 4 files changed, 368 insertions(+), 13 deletions(-) -- 2.52.0