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 5C826E77354 for ; Sat, 30 Sep 2023 06:32:43 +0000 (UTC) Received: from localhost ([::1] helo=shelob.surriel.com) by shelob.surriel.com with esmtp (Exim 4.96) (envelope-from ) id 1qmTVW-0005Zd-0N; Sat, 30 Sep 2023 02:31:18 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]) by shelob.surriel.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1qmTVK-0005Z1-21 for kernelnewbies@kernelnewbies.org; Sat, 30 Sep 2023 02:31:16 -0400 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 858C45C2607; Sat, 30 Sep 2023 02:30:40 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Sat, 30 Sep 2023 02:30:40 -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=1696055440; x=1696141840; bh=RX 3aP8Q0cvS9tHuzGbrbdvpP3v+dh2Y89KDfX8EOgAM=; b=Qau7Y13j6i6n5s6/Bq 9IZbSAyzGAl5n8DgGW1+qQCxFXqVCiI6+7VPETku9bGLvT04t1kFMGsa9372Ed3q NL33tjclTmRzCr8UuDOHrNYFV8R+o1E3N4Mq0awkRUToTwLE/tsyl0hFg5HUgnEB UdMD4KTZLPhJEocLjTb0M0tTdCgKkyHGmyS3PcZD9HTn8Zb6AL0q9dav+n78Uywl kJusj+4chbcvSQaSG3semE3oqHHJGIOnoJRkzkWZh+CAjIAVSlQfvQQAblcIQijX 1WMYVW8ypIM5nY90SIJaR1AkxIyA8txHLycSdfU8EJ043TMCG3d6Vv8HtDuhqHbK GW3w== 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=1696055440; x=1696141840; bh=RX3aP8Q0cvS9t HuzGbrbdvpP3v+dh2Y89KDfX8EOgAM=; b=hVhU8uzV5mK8b9WBeENkYA+mPisdw zgv+1yxNlMVakmmUyRjyuULR1s2//9T7UTSRubExvJVAGgt1uJyZQhM/SNRHtWZP K4qfCQe+B+v819dG/RHX3atVu80oRxYbjlmRoCePlE2sgRFsvZUXOKHoTKXM6/Wk nquM3tEAtp5OJ4uvR5NqdIiSNJcP01z32njp6vGSDS5jUhUv99k1Xzwwb0GUFZ93 7c63LWsNOTieCqoCZqMTaaFF5JkeZJBnru2/K2jDJA2iTJut8iFXLJcMwc+/FhAc Y8A2wo4DNSyaArOcYHStC/ijbeQ3GgBBiEEYjKi0pUYUJDClHrT6J2A2Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrtdekgddtfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffhvfevuffkfhggtggujgesthdtre dttddtvdenucfhrhhomhepifhrvghgucfmjfcuoehgrhgvgheskhhrohgrhhdrtghomheq necuggftrfgrthhtvghrnhepheegvdevvdeljeeugfdtudduhfekledtiefhveejkeejue fhtdeufefhgfehkeetnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghi lhhfrhhomhepghhrvghgsehkrhhorghhrdgtohhm X-ME-Proxy: Feedback-ID: i787e41f1:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 30 Sep 2023 02:30:39 -0400 (EDT) Date: Sat, 30 Sep 2023 08:30:31 +0200 From: Greg KH To: Richard Subject: Re: ktypes vs. devices classes (struct class) Message-ID: <2023093017-overdraft-umbrella-9ad9@gregkh> References: <9644b2e3-acaf-c26b-0ec2-9a6c9cb23977@systemli.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <9644b2e3-acaf-c26b-0ec2-9a6c9cb23977@systemli.org> 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 02:12:41AM +0200, Richard wrote: > Hi all, > > Why do we have ktypes (struct kobj_type) AND device classes (struct class)? Because they are two totally different things. > Don't they serve the same purpose (more or less) and it would be simpler, > clearer and more KISS to only have one? Is this a historically grown thing > or by design? 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? 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! thanks, greg k-h _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies