linux-kernel - Re: Where did find

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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20061121180430.GD5200@stusta.de>
Date:	Tue, 21 Nov 2006 19:04:30 +0100
From:	Adrian Bunk <bunk@...sta.de>
To:	Paul Sokolovsky <pmiscml@...il.com>
Cc:	Greg KH <gregkh@...e.de>, Arjan van de Ven <arjan@...radead.org>,
	Jiri Slaby <jirislaby@...il.com>, linux-kernel@...r.kernel.org,
	kernel-discuss@...dhelds.org
Subject: Re: Where did find_bus() go in 2.6.18?

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