Message-ID: <456362DD.8070902@sbcglobal.net>
Date:	Tue, 21 Nov 2006 14:34:37 -0600
From:	Matthew Frost <artusemrys@...global.net>
To:	Paul Sokolovsky <pmiscml@...il.com>
CC:	Evgeniy Polyakov <johnpol@....mipt.ru>,
	Arjan van de Ven <arjan@...radead.org>,
	linux-kernel@...r.kernel.org, Adrian Bunk <bunk@...sta.de>,
	Greg KH <gregkh@...e.de>
Subject: Re: Where did find_bus() go in 2.6.18?

Paul Sokolovsky wrote:
> Hello Evgeniy,
> 
> Tuesday, November 21, 2006, 9:01:50 PM, you wrote:
> 
>> On Tue, Nov 21, 2006 at 12:29:15PM -0600, Matthew Frost (artusemrys@...global.net) wrote:
>>> So you have nested drivers.
> 
>    Matthew, thanks for your help, but it wasn't really my intention to
> waste other people's time with fixing our drivers. We are kernel
> hackers themselves, and eat our dogfood - with each kernel
> release, we have bunch of drivers breaking, and we patiently fix them
> (and yes, with recent releases, number of such drivers reduces, and
> that makes us really happy with recent 2.6 releases).

Alright, you're kernel hackers.  But I'd like to take issue with the mindset
that these drivers are your burden, to bear by yourselves.  It seems to me that
anyone with an iPaq relies upon this code path, or one like it, so you are
supporting a bunch of users by yourselves, and holding up the burden of
compatibility with the mainline kernel at the same time.  Doing twice as much
work, on two moving targets.  That's the waste of time.

>    But, this particular case made me wonder - was it some issue with
> change made in mainline, or there's something wrong with our manner to
> write drivers? And we'd like to be updated in the latter case.

And here's where the recommendation to get your code into mainline comes in.  If
the kernel developers don't know that you're using something, they can't tell
you what it was replaced by, or even that they need to replace it with anything.
 "No mainline users of the code" is a reliable baseline for value, because we
can't go looking for out-of-tree users in any convenient way.  Therefore nobody
tells you it's going to break until you learn the hard way that it broke, and
holler at the list.  Nobody *can* update you.  It isn't malice, it's finity.  If
your code is in mainline, whoever makes a change to mainline has to care,
because there is a legitimate burden of compatibility assurance, and it isn't
yours alone any longer.

> 
> []
> 
>>> (cc: E. Polyakov for the w1 expertise)
> 
>> Hello.
> 
>> If find_bus() will not be resurrected, I can export w1_bus_type or
>> create special helpers to directly access w1 bus master devices.
>> But in that case there is no need to have all driver model in w1
>> subsystem at all...
> 
>   Thanks for your response, Evgeniy!
> 
> 
>   Ok, so now it's not just me, it's the maintainer of a bus subsystem
> in mainline. There's no wonders, and one uncareful change in core API
> will cascade to many other places. Commented out find_bus()? Now need to
> make sure all bus types structures are exported. At least. But maybe
> maintainers will also wonder what happens here, and shouldn't they
> provide adhoc API to query a specific bus? And then indeed, what is
> the use of LDM? Where did go idea of having common, bus- and driver-
> independent API to do consistently all the stuff one *may* need (not
> all feature of which everyone necessarily uses all the time).
> 

I could be wrong, but it doesn't sound like Evgeniy is complaining that this
problem hits him.  The other drivers in w1/slaves don't use find_bus().  He's
offering to give you an export to hook into.  Though I might also look at
Dmitry's suggestion and rework around driver classes.  Which may fit in with
what Evgeniy says about moving the driver model out of w1.

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