From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 9945FE748ED for ; Sun, 1 Oct 2023 09:52:00 +0000 (UTC) Received: from localhost ([::1] helo=shelob.surriel.com) by shelob.surriel.com with esmtp (Exim 4.96) (envelope-from ) id 1qmt6i-0001Ax-2w; Sun, 01 Oct 2023 05:51:24 -0400 Received: from wout1-smtp.messagingengine.com ([64.147.123.24]) by shelob.surriel.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1qmt6V-0001AJ-12 for kernelnewbies@kernelnewbies.org; Sun, 01 Oct 2023 05:51:20 -0400 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 0A63732011CE; Sun, 1 Oct 2023 05:50:48 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Sun, 01 Oct 2023 05:50:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kroah.com; h=cc :cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm2; t=1696153848; x=1696240248; bh=Zz BSKJAgnW+fr2BmAHHa5su6zSaz8P4yM/WxmjZctXU=; b=e5Ed5c6+Nfda+vxOYX +T5QFGiQccIE6+auhxqtbvOzLtGXVLzZmTy86+gkgvJwvEmVZ21Tm4c0SrapwgyD /qtAq5wKuZTYQLYvE8hpTFprVt0DoVUFG6Q1WveewZ2qv9GGtpL2CABsVuTwsPHc dnzJnXcW1/mWxWGG1TpP/RAYksF7ucTSb5DH7IKsWvHjrdTvOVm7MzHXgW4uUA4B Oped28kdD5Q9fHPWMqnwTCRTmUVLyVHaVxC6aqOrDys5lP+WjpIJWmApbzzaw6gE AsId5r2awNX3E45M2sHMqfCPqt2yQsC4pjCV+mIg4DA9RddAeZH3ZQaTNMrM81ly aL/w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; t=1696153848; x=1696240248; bh=ZzBSKJAgnW+fr 2BmAHHa5su6zSaz8P4yM/WxmjZctXU=; b=jFYxaW2Q35/ShQATVqbsgJOTN9qIh mlmXhzlgURKLEaiBEspaKpWbztGl+wggoI8F8v4rc5upJAu9GkOHlTrY/9GmzRBY I+lx1UrLTG8hiFWtPHFP/oxyeAeeuGHHbIn+Ey3YyRUsleowzo12N2WN4b7t5CFR qcubqI4N3EC0tmx3zjbM1g+GnRpH3M2bWnKPRM48szk1YocPDTLufgju2DfNOAGo 22UA92gLmbwn2b0t3ffCMCKvfzZW7fbo/qJfScdgyA38NfrsQ0n38J7mrQd25OiN dRPDFkLICs/TCWj5y8wlkJsvxcxH5Z01OvNYuIXXXwgqOUFRyNAMOysQw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudelgddulecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffhvfevuffkfhggtggujgesthdtre dttddtvdenucfhrhhomhepifhrvghgucfmjfcuoehgrhgvgheskhhrohgrhhdrtghomheq necuggftrfgrthhtvghrnhepheegvdevvdeljeeugfdtudduhfekledtiefhveejkeejue fhtdeufefhgfehkeetnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghi lhhfrhhomhepghhrvghgsehkrhhorghhrdgtohhm X-ME-Proxy: Feedback-ID: i787e41f1:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 1 Oct 2023 05:50:47 -0400 (EDT) Date: Sun, 1 Oct 2023 11:50:46 +0200 From: Greg KH To: Richard Subject: Re: ktypes vs. devices classes (struct class) Message-ID: <2023100146-storm-unsmooth-d18c@gregkh> References: <9644b2e3-acaf-c26b-0ec2-9a6c9cb23977@systemli.org> <2023093017-overdraft-umbrella-9ad9@gregkh> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: Cc: kernelnewbies@kernelnewbies.org X-BeenThere: kernelnewbies@kernelnewbies.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Learn about the Linux kernel List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kernelnewbies-bounces@kernelnewbies.org On Sat, Sep 30, 2023 at 08:17:26PM +0200, Richard wrote: > Hi, > > I appreciate your answer, thank you for your time. > > > > > Look closer. Tell me what "struct class" is for vs. what "struct > > kobj_type" is for and see if they both could be used for the same thing? > > I've looked at the definitions in include/linux and thought a bit about the > semantics. > > struct kobj_type defines behaviour (sysfs_ops and default_attrs) that is > common for multiple kobjects. But those kobjects could be embedded in > drivers, devices or a bus. > > I think one core difference is that "struct class" is strictly for devices > so it's more specific and contains a lot of members that are only relevant > for devices. Close. "struct class" represents how userspace interacts with a device (tty / input / block / etc.) "struct kobj_type" is needed to describe what "type" of struct kobject a specific kobject is. It defines a number of operations that handle the lifespan of the kobject. > My digging however has brought me to a few new questions: > > Do all devices (their kobjects to be more precise) in one class (e.g. > /sys/class/net ) belong to the same ktype? ktype is "lower" than classes. ktype is not used for things in the driver model, it's used for things "lower" than the driver model (and to implement the driver model itself.) So no driver should ever be messing with a ktype. If you want to have a different "type" of device on the same bus or class, use "struct device_type" as that's what that is for. > Is it possible that one device belongs to several classes? No. > I've seen struct class defines **class_groups, but (contrary to struct > kobj_type) not the corresponding struct sysfs_ops, why? Where is it then? groups are used to define attributes (i.e. sysfs files). sysfs_ops is much "lower" in the stack. I think the description of how the driver model works in the book, Linux Device Drivers, 3rd edition, free online, should still represent how things work on this layer pretty well, although we have changed things in places over time since the book was written. Try looking that first. > > When we implemented them, we didn't think so but maybe something has > > changed to now allow this? If so, great, please send us patches to do > > so! > > Oh please don't misunderstand me, even if we had come to an agreement that > this architecture was unelegent (which it isn't I see the point now), I > don't think that would have been reason enough to change it. Change is good if it is needed, that's how code evolves, based on new ideas and use cases. So that's fine if needed. hope this helps, greg k-h _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies