Received: by 2002:a05:6a10:9afc:0:0:0:0 with SMTP id t28csp1561920pxm; Thu, 24 Feb 2022 05:35:37 -0800 (PST) X-Google-Smtp-Source: ABdhPJxGGazrSjsh/Dx6G5gP40DyibOYyHVCJyh4oIQ1pYCUxNamxhJTCJGSb6y76yBjSvZPp5Pq X-Received: by 2002:a17:90a:ea83:b0:1bc:2cb6:78e0 with SMTP id h3-20020a17090aea8300b001bc2cb678e0mr2899234pjz.20.1645709737609; Thu, 24 Feb 2022 05:35:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1645709737; cv=none; d=google.com; s=arc-20160816; b=PXTvqtTOFtvr7dU9PHaPruRIIynunqwbllswSbDUgkB89yc0sU3qJRdu1y0q7MeC+m orBePmvxhkfkGPTM2T0fIM3ANMM5tcUQInpOFuNJSpE0KT8cI6eWt06f8+SEl53bAPHP NNsEsnmF/W9980nzi4V/RyDIo+9qi9JXPqVq/JdR1slSvKvMHVsoRYD+qg52q6BwYVDC BR7FDlJ56pbmYBYUGMChIXmEy7ReleOjJUmil/IIMwiDP2eFARxE7zE7CSH2Ios9LZGZ frSCqD9CbnxWGkCpX5QD16wSTVtIhLgk8Wy/aU6Al9GvhS23NpKXrFzkW9RflzFfH0TP 4GPg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=bmqTGqWk/V1AcHAty5MkYbIYWxEdphX+KA+WD4K5f6w=; b=Lo3sqBnEkvY+ZvktcnaiHoHaBTGhDME8d0clU1jpC7TcBGHWJ25AGqiyaPqVITs9Hu HBmp+sIZwMv8icvVa93qrovs7BbqVJ9Qzr6QVQmY6FbqsPjE1TNZTD+DQMuhv5Nzh6aF PTQ2fdFrKq9/P+U9+nnD1f5yNk1wkLhHNjh0DAV/ssdALSZWmM3+r91YCZeKnQxmAbqt SMErwb343sKgUTy469RvSXWghvAc291C/GFe6WWsHaEOiQdYCRLq5/l/LO1HRjO8oV4c pfzG6i4qlZLlV9j+PjtlXkML9TF8N0f2UBBah/Eotg05JT60dK0ubtGFh3M/41rXFoH4 oHUw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.com header.s=susede1 header.b="G/AL7r3T"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=suse.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id kb18si2576529pjb.136.2022.02.24.05.35.17; Thu, 24 Feb 2022 05:35:37 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.com header.s=susede1 header.b="G/AL7r3T"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=suse.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231701AbiBXMkE (ORCPT + 99 others); Thu, 24 Feb 2022 07:40:04 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43940 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234452AbiBXMkD (ORCPT ); Thu, 24 Feb 2022 07:40:03 -0500 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 862F927FBAF; Thu, 24 Feb 2022 04:39:33 -0800 (PST) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id 3AC5B1F44A; Thu, 24 Feb 2022 12:39:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1645706372; h=from:from:reply-to: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=bmqTGqWk/V1AcHAty5MkYbIYWxEdphX+KA+WD4K5f6w=; b=G/AL7r3T/R1HIU1WsIy1DBghOmtuAQiMFkb59bTNQoeOE1ljAPo1qIYX/itle3BVf1pz/K TdpczjZQvKpiLLwM6MXrlG4pgd2ePfnBH6Sm8lmr7E6RuEVAuWHaMDORwPsE7eNlLcyopc WGr6PJHOk8VlZYZJjw95H2UwXThR1Go= Received: from suse.cz (unknown [10.100.216.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id D6275A3ED1; Thu, 24 Feb 2022 12:39:29 +0000 (UTC) Date: Thu, 24 Feb 2022 13:39:27 +0100 From: Petr Mladek To: Miguel Ojeda Cc: Miguel Ojeda , Linus Torvalds , Greg Kroah-Hartman , rust-for-linux , linux-kernel , Wedson Almeida Filho , Alex Gaynor , Geoffrey Thomas , Finn Behrens , Adam Bratschi-Kaye , Michael Ellerman , Sumera Priyadarsini , Sven Van Asbroeck , Gary Guo , Boris-Chengbiao Zhou , Boqun Feng , Fox Chen , Dan Robertson , Viktor Garske , Dariusz Sosnowski , =?iso-8859-1?B?TOlv?= Lanteri Thauvin , Niklas Mohrin , Gioh Kim , Daniel Xu , Milan Landaverde , Morgan Bartlett , Maciej Falkowski , Jiapeng Chong , Sergey Senozhatsky , Steven Rostedt , John Ogness Subject: Re: [PATCH v4 10/20] rust: add `kernel` crate Message-ID: References: <20220212130410.6901-1-ojeda@kernel.org> <20220212130410.6901-11-ojeda@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue 2022-02-22 13:48:16, Miguel Ojeda wrote: > Hi Petr, > > On Tue, Feb 22, 2022 at 10:06 AM Petr Mladek wrote: > > > > What exactly should we keep in sync, please? > > > > I see only handling of KERN_* prefix in print.rs. I do not see there > > any counter part of LOG_LINE_MAX, CONSOLE_LOG_MAX, or PREFIX_MAX. > > Good catch! We had a buffer on the Rust side in the past, but that is > not the case anymore since commit 9e8bd679ecf2 ("Support Rust > `core::fmt::Argument` in vsprintf") on our side, so we will remove the > comment. Great :-) > > I am sorry but I am not familiar with rust. What are these limits > > 2 and 10 used for, please? > > > > I guess that 2 is the size of a single KERN_* identifier. > > But what is 10? > > > > Note that printk() format prefix is typically just a single KERN_* > > identifier. But there might be more. Well, in practice only the > > following combination makes sense: KERN_CONT + KERN_. > > What we are doing here is generating compile-time format strings that > are then used by the `pr_*!` macros (which call the C side `printk()` > with one of the strings). I see. We are on the safe side then. > In other words, this is not parsing arbitrary `printk()` format > strings (which I am guessing something like that is your concern -- > please let me know if I got it wrong). Yes, this was my concern. > > Finally, is there any way to test whether any change in the printk > > code breaks the rust support? > > One way is to compile the code, e.g. the `assert!`s in the `generate` > function run at compile-time, thus they provide a first layer of > defense. > > Another way is to use `samples/rust/print.rs` which we run in the CI > as a black box test. > > Is that what you had in mind? Or something like unit tests or self tests? I had in mind any tests that I might run [*] to be sure that changes in the native printk code does not break Rust support. The compile test and samples/rust/print.rs do some basic tests and might enough for now. [*] To make it clear. I am not going to run the tests at this stage. But I might be useful once this patchset is accepted upstream. But it also might be enough to wait for results from your CI. I hope that we will not break it that often. Best Regards, Petr