linux-kernel - Re: [RFC PATCHv2 1/4] drivers/otp: add initial support for OTP memory

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20110325232847.GA5551@suse.de>
Date:	Fri, 25 Mar 2011 16:28:47 -0700
From:	Greg KH <gregkh@...e.de>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	Jamie Iles <jamie@...ieiles.com>, linux-kernel@...r.kernel.org,
	vapier@...too.org
Subject: Re: [RFC PATCHv2 1/4] drivers/otp: add initial support for OTP memory

On Fri, Mar 25, 2011 at 11:01:56PM +0100, Arnd Bergmann wrote:
> On Friday 25 March 2011 22:12:46 Greg KH wrote:
> > > Why is this a bus? You don't have any device matching code or similar,
> > > and the devices typically are on an existing bus_type (e.g. platform_bus).
> > > I think it would make more sense to do this as a class.
> > 
> > No, for new things, we want to use busses instead of classes please.
> > Especially as this does create devices, which are best put on a bus
> > somewhere.
> 
> I don't understand. Isn't that rather inconsistent?
> 
> I realize the same thing came up with the IIO subsystem, where I also
> didn't understand it.
> 
> In my mental model of Linux drivers, a bus is something that physically
> connects devices and the bus code matches devices with drivers, while a
> class groups logical devices that get created by the driver itself.

Yes, that is how it used to be, but then it turns out that both of them
are really just "subsystems" as far as it all goes.  They are just ways
that devices are bound to drivers in a logical manner.  We have patches
floating around that get rid of both busses and classes to merge them
together, which is the end goal here.  I know Kay has posted detailed
reasons for why this all is on lkml in the past, and had working code
about 5 years ago, it's just been slow going...

So we recommend all new subsystems use the bus code, it's simple and
works well.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/