On Tue, Nov 21, 2006 at 05:08:46PM +0200, Paul Sokolovsky wrote:
> Hello Adrian,
Hello Paul,
> Monday, November 20, 2006, 7:35:50 PM, you wrote:
>
> []
>
> >> And suddenly - oops, in 2.6.18 we lose ability to query the highest
> >> level of hierarchy, namely bus set.
>
> []
>
> > As Documentation/stable_api_nonsense.txt explains, there is no stable
> > kernel API.
>
> Thanks, Adrian, from the first mail I really counted which reply #
> (if I would get them at all) will point me to that "bible" of kernel
> developers, and just wondered, would it be too ugly to ask for an answer
> which wouldn't recourse to that doc.
>
> But now that you mentioned it, let me make you laugh at jaundiced
> eye's look on the issue: it appears it's just itch for kernel
> developers to make APIs not stable. When some API is stable, because
> it's both trivial and complete (like that bus methods which are just
> based on generic container object idea - you can't add or take from
> that), some artificial criteria are employed, like "unused", to still
> find a way to destabilize API ;-).
if API changes in the kernel break external modules that's not
intentional, but a positive side effect reminding people that they
should submit their modules for inclusion in mainline.
> > If you don't want to get the APIs your driver uses
> > changed/removed you should really try to get it merged into mainline.
>
> Would this really be the case? I guess, most people would think that
> getting something into mainline is indeed the end of battle. And yet
> for others, it may be the case that single driver using some API is
> almost just the same as 0 drivers doing that. If 1001 is almost 1000,
> why 1 can't be almost 0? Why this would be worse than "Well, noone
> uses that call now - let's make noone use it ever, at all."
The rule is roughly:
If you change/remove a kernel API, you have to fix all in-kernel
users.
As an example, the irqreturn_t change in 2.6.19 will require changes to
your driver. It also broke at about 1000 in-kernel drivers, but all of
them have been fixed as part of the change (the commit changed 1079
different files).
> So that's what I'm trying to argue - let the change which needs to
> be done, be based on the high-level ideas of the meaning of the thing
> being changed, not on purely quantitative, and thus, subject to
> separate interpretation, parameters.
>...
Many people are still using kernel 2.4 for new kernel development
because kernel 2.6 images are significantly bigger. Every unused byte
removed from the kernel images makes this space regression smaller.
> > The find_bus() case is even more interesting since you are using it in a
> > driver although it has never been exported to modules. Considering that
> > you anyway have to patch the kernel for getting your driver running
> > (since it won't run as a module against an unmodified kernel), you could
> > simply undo my patch locally until you submit your driver for inclusion
> > in mainline.
>
> Well, I believe you expected and cared to get such feedback, because
> otherwise, you wouldn't use #if 0, but killed unlucky function
> completely ;-(. I don't hold breath for those #if 0 to be removed
> based on the above right now, but I hope the function at least won't
> be removed completely for now, to indeed let whoever may have need for
> it still use it somehow (and submit code to mainline, if that is what
> actually would take to have the issue resolved).
>
> As for EXPORT's, indeed, mainline kernel lacks quite a few
> which are useful. But obviously, I won't argue for adding them now,
> out of context - that would be just as random change, as, IMHO, and
> sorry, removing find_bus() from use.
It's an integral part of the Linux development model that any kind of
in-kernel API changes are always possible.
There's a choice between stable APIs on the one side and speed of
development and smaller kernel images on the other side, and the Linux
kernel prefers the latter.
> Best regards,
> Paul
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
