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]

Date:	Sat, 26 Mar 2011 12:25:03 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	Greg KH <gregkh@...e.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 Saturday 26 March 2011 00:28:47 Greg KH wrote:

> 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...

How will that work? I suppose we can't really change the directory
structure anyway, so to users it will still look like it does today,
even if the kernel just uses the same code for bus and class internally.

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

I'm not worried about the code at all, just how it shows up in
sysfs, which is rather confusing when things become a bus that
are not really buses by any stretch. Obviously there are grey
areas and corner cases where a bus makes as much sense as a class,
but I think this one is not such a case.

	Arnd
--
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/