Re[2]: Where did find_bus() go in 2.6.18?

[Paul Sokolovsky <pmiscml@gmail.com>]

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@sbcglobal.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).

   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.

[]

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


P.S.
find_bus()is hardly a threat for kernel binary size and for bringing
more 2.4 users to 2.6:
http://lxr.linux.no/source/drivers/base/bus.c?v=2.6.18#L602

Well, I'd actually hardly ventured into arguing that its removal may
be not exactly right, if it wasn't such an obvious case of crippling
API for no real benefit. But it's not long cry for 2 lines of code,
but for understanding of where kernel goes...
  

>> Matt




-- 
Best regards,
 Paul                            mailto:pmiscml@gmail.com