"use register arguments" option enabled.

[Nicolas Mailhot]

On Mar 17 mai 2005 9:29, Mike Honeyfield a écrit :
> On 5/17/05, Arjan van de Ven <arjanv at redhat.com> wrote:
>> On Tue, 2005-05-17 at 10:45 +1200, Mike Honeyfield wrote:
>> > On 5/17/05, Ignacio Vazquez-Abrams <ivazquez at ivazquez.net> wrote:
>> > > On Tue, 2005-05-17 at 10:29 +1200, Mike Honeyfield wrote:
>> > > > I am just wondering the reasoning behind having the experimental
>> > > > option "Use register arguments" on in the kernel config.
>> > > >
>> > > > It has caused some issues for me, have since fixed it, but was
>> > > > wondering why an experimental feature that could/can break the ABI
>> for
>> > > > 3rd party binary only modules would be enabled?
>> > >
>> > > Speed. Pushing data onto the stack takes longer than just shoving it
>> > > into a register.
>> > >
>> >
>> > So the speed improvement is enough to justify this?
>> >
>> > I could understand Fedora Core's kernels have this feature, but was a
>> > bit suprised to see the same issue in RHEL.
>>
>> why?
>>
>> This only impacts binary modules, and in the process of porting those to
>> 2.6 the vendor needs to "fix" this up just as well. That is the same for
>> FC and RHEL.
>>
>
> So you disagree that this is actually "experimental" as per the kernel
> config?
>
> Doesn't the term experimental indirectly imply possible stability
> issues? Not reasuring IMHO.

Large parts of the Linux kernel are marked "Experimental". It really does
not mean much - people are so conservative removing those warnings they
are kept till the code is old and crufty.

They're about as informative as all the commercial EULAs that say no one
will be held responsible if $BIG_VENDOR_APP eats your data.

> Yes, RH's choice in kernel configure option is theirs and yes, it is
> true, binary only vendor can "fix" (not sure waht the quotes imply),
> we have "fixed" our drivers. Worth noting, our driver was written for
> 2.6 and in RHEL it was broken, but not other platforms we support,
> like debian and suse.

Different linux vendors make changes at a different pace. I'm sure you can
find "experimental" options turned on is Suse that are still disabled in
RHEL (at one point this was the case for ALSA for example)

There is little point complaining about it - something that appears in
RHEL will hit Suse and Debian after a few months too (similarly something
appearing in FC will hit RHEL later)

If you want seamless Linux support you have to make sure your drivers work
on the Distribution development versions (Rawhide->FC->RHEL, Mdk cooker,
etc) not wait till they are deployed on RHEL and big iron. The whole
development process is public - you have no excuse not being ready by RHEL
time.

RHEL is about stability, not stagnation. Stability is achieved by giving
loads of forwarning about what will end up in RHEL so everyone can prepare
for it not by freezing RHEL for a decade. Proprietary vendors that start
looking at the RHEL featureset months after it has been released and blame
RH for they poor support make me mad. (we have costly support, and it will
tell you we're not ready - right)

RHEL release is not the start of the adaptation race. It's the end of it.

-- 
Nicolas Mailhot