linux-kernel - Re: [PATCH 1/3] Clocklib: add generic framework for managing clocks.

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 for Android: free password hash cracker in your pocket

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

Date:	Wed, 26 Mar 2008 20:09:25 +0000
From:	Russell King <rmk+lkml@....linux.org.uk>
To:	Paul Mundt <lethal@...ux-sh.org>,
	Haavard Skinnemoen <haavard.skinnemoen@...el.com>,
	Dmitry Baryshkov <dbaryshkov@...il.com>,
	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	hskinnemoen@...el.com, domen.puncer@...argo.com, tony@...mide.com,
	paul@...an.com
Subject: Re: [PATCH 1/3] Clocklib: add generic framework for managing clocks.

On Thu, Mar 27, 2008 at 01:14:56AM +0900, Paul Mundt wrote:
> Conversely it also has fields that I don't need. If struct clk could have
> been done generically without growing to insane sizes, it would have been
> done so in linux/clk.h a long time ago. The main thing there is API
> consistency for drivers, leaving the details up to the architecture.
> 
> It's true that there is significant overlap between the different users
> of the clock framework, but it's also not clear that there's any clean
> way to share a common implementation (especially since struct clk means
> totally different things on different architectures). I suspect everyone
> in the CC list has been through this before, also.

That's the exact reason why I never implemented any kind of framework
and just left it as an API for drivers to use.  What's behind the API
is very platform specific, and as can be seen from the comments, trying
to define something common results in something that just doesn't fit
in different ways.

Trying to make it expand to fit someone elses platform makes it unsuitable
for another due to it becoming too heavy weight.

Personally, I don't have much interest in these patches - had I been
interested in having a common framework behind it when I created the
API, I'd have written some code.

However, if folk think that they can solve the complexity problem while
still allowing for simple implementations...

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:
--
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/