[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <bc64b4640804251334j7e2fbf30u358e010bc3e5d5ec@mail.gmail.com>
Date: Sat, 26 Apr 2008 00:34:55 +0400
From: Dmitry <dbaryshkov@...il.com>
To: "Russell King" <rmk+lkml@....linux.org.uk>
Cc: "Pavel Machek" <pavel@....cz>, "Paul Walmsley" <paul@...an.com>,
linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
"Haavard Skinnemoen" <haavard.skinnemoen@...el.com>,
"Paul Mundt" <lethal@...ux-sh.org>,
"pHilipp Zabel" <philipp.zabel@...il.com>, tony@...mide.com,
"David Brownell" <david-b@...bell.net>, hiroshi.DOYU@...ia.com
Subject: Re: [PATCH 0/5] Clocklib: generic clocks framework
Hi,
2008/4/26, Russell King <rmk+lkml@....linux.org.uk>:
> On Fri, Apr 25, 2008 at 12:39:42PM +0200, Pavel Machek wrote:
> > WTF? There are currently around 10 copies of clock code in the tree,
> > every one slightly different. If this can help us get rid of all that
> > crap, that's a GOOD THING, normative or not.
>
>
> At the expense of people going off and inventing their own APIs because
> they find that the "normatived" clock API doesn't do what they need to?
Why? We do already have the API. And it's pretty normative. And the
goal of my framework is to allow me and few other people not to
reinvent the API for non-platform clocks.
> That's what will happen if you try to force a framework on folk which
> they don't agree with.
If you don't want to use it, you are free to do so. E.g. you can use
your own set of functions to implement GPIO api.
--
With best wishes
Dmitry
--
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/
Powered by blists - more mailing lists