From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dl1-f47.google.com (mail-dl1-f47.google.com [74.125.82.47]) (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 0189F2F6573 for ; Thu, 5 Feb 2026 17:46:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.47 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770313616; cv=none; b=AOfRBuMA3dBoO+QybXjtOQco7ScYHIcleN/emz6G9ftMcUMl0t7vkdgyQEv7+SHiITq9SC+zn0pcdg4vnCnvflHhxkDgWiGwZF1tklbMt/pytsFOMto1Yzdkl9ODONYYXwKTvjLuXQ5TFhfT4OGDzUgcSS3zYu8b19MIPToRL8U= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770313616; c=relaxed/simple; bh=wnjtBBK0iqB1VvqUAEVJlOibMNEC4vdMhgnCkZgThn4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=dd1KJ8AJlhdUkidT5zMsBQt0a24efj5v2sfxBQzJlA2AfoVtVEgOehYpY25h09hfr0QA9BTQkQhwKXSUvj+fMAre7BQg/t6B0SYAT0Oc5rFx0Uj3dNDQnI3C3tGg8Vo4TJeANSJOpXjQZeO9qN3riIqqYRpxHx8rdDEZto1SVfw= 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=k1SWEf6f; arc=none smtp.client-ip=74.125.82.47 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="k1SWEf6f" Received: by mail-dl1-f47.google.com with SMTP id a92af1059eb24-1249b9f5703so1956566c88.0 for ; Thu, 05 Feb 2026 09:46:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770313615; x=1770918415; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=knM2pU/+KZzHJ5cQexzMehGAL415Q9KWhsuFhvbNK0A=; b=k1SWEf6f+dgqM7ER+/qK/Q/rGo16QQDaicchHm4Ot9ZpSzHbYT+lgLQU3WNScz1bz9 toeAlLsh+Gx43O2C6IP3WKuFvubDK7yfr/bVUKu29JPl9Z3GOw1bUlIK/cU4xahNp3yQ f09YivlRorLc5b3Ty/IhHR3OC1aREYGx0FNJABeyuogwhNVYtG8rfREaX7R3TJ/AwsKF rfEQwaexWqKri9N4HKvouNhVrNEo8/2uKqVjajHNNza05ltyn7S5joaLA4zGMO2xLZN/ GaH0cfKs2FEWMNJwRs4TX6kEIVEeM8DRAgsRoZbSLKvhCG0Qj0RcDhgfh7mcBwHjT+iG duTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770313615; x=1770918415; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=knM2pU/+KZzHJ5cQexzMehGAL415Q9KWhsuFhvbNK0A=; b=Ia477XqxSdovSxyTXHZYRw2TzwbaMJz9Ge69zq9Me/cnTHVn5G0Ni+h5aTEZ2J928i tuoiySKdzTUMtx0TT5N5GCb4LGH+H4iJGL81G/Rz4M24VdUvcAm51rpPEbbmxdUdH04L a4J8PeSbO4dcnjgFzpyuTco0TGz3j7yhbG3YM0Xa6ypvCyjv4vuRuB8fJObSiOifLRs0 trA9iCZjutCxcO/rt2ofMWs95MwvbMmpxnDK7Tg50OrBtJcOvlT1Xo88Yujh/c6oUzRc gH/uvlsuRqmIkEJPY8TaopQKPZGWdlbchSB4QMEM4Jcm/lMHtMoZQf/ZgEoFwxj5qZXt 5Y9A== X-Forwarded-Encrypted: i=1; AJvYcCV9EWc1qoPndbf++WsdnOT8gzw1DYzsZNel8QjH4mFFXiUys3PSx+6yWNMrX2PheEsF7JWadbTjo4wy6f4=@vger.kernel.org X-Gm-Message-State: AOJu0YxNB/DQIj+666S6gZuiAL+LiLl5PALF7YwzIvRlic65t7w8B9i5 67PHLUt5IyjbT/gD6TGOk8HJ+KLhMNnOmrq/lmi985IHdV6pkotoTgjT X-Gm-Gg: AZuq6aKtwic0BU1vsaol7O6WpnHKJjfHd/xBNK84zWdFAELqh1dA/dqB6lj2GBdqgG4 1CVYuKlpk0qeY4MVv83mTp1Bjwxc4dmtb4KxCQbuMzqdRiqwBW/x+d6ad/4KKuKxAMZqP0Inqut UL151V9hyOUOE+NPJBH1OvgeQCMgFXy3lsOcXy49yVvVdsq66ZY+KtGCVvALRxh8U1qbPybq7jA BfYUyW4iaBmM77c3ty8dnZHV0qLQv2iED3pliXiT3Lrfl9Q1XqQxlnxhw80ZxfSo21FhQB6SDxu E5/bg8RxonWhKgyAkEv6wcDl/igejVBi6QZ6Kgw2p5pc9PbpViE6XTqTzmwgCaNMcnA1iY8TFCC sO3LluuxfAdQWGIzlzfevUlyhvloFdz9U1wl2ZIPMX3UIN5RppibzzAa7mNQbOS7X7MjLqeNn0g mypqQK7A+0prelyZkb/w== X-Received: by 2002:a05:7022:a86:b0:123:330b:398 with SMTP id a92af1059eb24-12703f51b55mr30556c88.19.1770313615063; Thu, 05 Feb 2026 09:46:55 -0800 (PST) Received: from deathstar ([2600:1700:22f5:908f:1457:7499:d258:358f]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-126f4e04467sm4152626c88.2.2026.02.05.09.46.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 Feb 2026 09:46:54 -0800 (PST) Date: Thu, 5 Feb 2026 09:46:52 -0800 From: Matthew Wood To: Andreas Hindborg , Breno Leitao Cc: Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , linux-kernel@vger.kernel.org, hch@infradead.org, jlbec@evilplan.org, linux-fsdevel@vger.kernel.org, netdev@vger.kernel.org, gustavold@gmail.com, asantostc@gmail.com, calvin@wbinvd.org, kernel-team@meta.com Subject: Re: [PATCH RFC 0/2] configfs: enable kernel-space item registration Message-ID: References: <20251202-configfs_netcon-v1-0-b4738ead8ee8@debian.org> <878qfgx25r.fsf@t14s.mail-host-address-is-not-set> <-6hh70JX5nq4ruTMbNQPMoUi6wz8vmM2MQxqB3VNK3Zt97c-oxWOo3y0cQ7_h6BSfcp78fR9GmzxcTQb_WB-XA==@protonmail.internalid> <875xakwwvz.fsf@t14s.mail-host-address-is-not-set> 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=us-ascii Content-Disposition: inline In-Reply-To: <875xakwwvz.fsf@t14s.mail-host-address-is-not-set> Hi Breno and Andreas, I'm in favor of this RFC as I think the current flow of needing to create the cmdline0 dir in the netconsole configfs (when DYNAMIC config is enabled) prior to modifying the values is not ideal. I think there are good points shared about sysfs vs. configfs being used for the cmdline target modification and wanted to add my thoughts. On Fri, Dec 05, 2025 at 08:29:04PM +0100, Andreas Hindborg wrote: > "Breno Leitao" writes: > > > Hello Andreas, > > > > On Fri, Dec 05, 2025 at 06:35:12PM +0100, Andreas Hindborg wrote: > >> "Breno Leitao" writes: > >> > >> > This series introduces a new kernel-space item registration API for configfs > >> > to enable subsystems to programmatically create configfs items whose lifecycle > >> > is controlled by the kernel rather than userspace. > >> > > >> > Currently, configfs items can only be created via userspace mkdir operations, > >> > which limits their utility for kernel-driven configuration scenarios such as > >> > boot parameters or hardware auto-detection. > >> > >> I thought sysfs would handle this kind of scenarios? > > > > sysfs has gaps as well, to manage user-create items. > > > > Netconsole has two types of "targets". Those created dynamically > > (CONFIG_NETCONSOLE_DYNAMIC), where user can create and remove as many > > targets as it needs, and netconsole would send to it. This fits very > > well in configfs. > > > > mkdir /sys/kernel/config/netconsole/mytarget > > .. manage the target using configfs items/files > > rmdir /sys/kernel/config/netconsole/mytarget > > > > This is a perfect fit for configfs, and I don't see how it would work > > with sysfs. > > Right, these go in configfs, we are on the same page about that. > > > > > On top of that, there are netconsole targets that are coming from > > cmdline (basically to cover while userspace is not initialized). These > > are coming from cmdline and its life-cycle is managed by the kernel. > > I.e, the kernel knows about them, and wants to expose it to the user > > (which can even disable them later). This is the problem I this patch > > addresses (exposing them easily). > > I wonder if these entries could be exposed via sysfs? You could create > the same directory structure as you have in configfs for the user > created devices, so the only thing user space has to do is to point at a > different directory. > Although technically feasible, this approach leads to an inconsistent and confusing management of the netconsole targets. A configfs path for user-space created targets and a sysfs path for the cmdline initiated target that can also be modified from userspace (e.g. to update remote_ip or userdata fields). I think Breno's approach sets up for the most intuitive user experience. The cmdline config for netconsole is also user-provided, so it seems like it should behave as a pre-populated configfs target that happens to pass from cmdline through netconsole module init to the current configfs interface. The initial values are not determined by the kernel itself. > > Best regards, > Andreas Hindborg > > >