Re: Inquiry: Should we remove "isolcpus= kernel boot option? (may have realtime uses)

[Paul Jackson <pj@sgi.com>]

Max wrote:
> So I expect two ACKs for isolcpu= removal from both of you, in bold please :)

Not from me, anyway.

I've seen enough replies (thanks!) from users of isolcpus=
to be quite certain that we should not just remove it outright.

I will NAQ such proposals.

And until, and unless, someone comes up with a persuasive answer
to Nick's question:

> is there a real reason _to_ remove it?

I'll probably NAQ proposals to deprecate it as well.

Max ... I think one place where you and I disagree is on whether
it is a good idea to have multiple ways to accomplish the same
thing.

As Ingo Oeser pointed out:
> The initrd is from the distribution. I have no sane way to change it

Even if you do find a way that seems sane to you, that's not the point,
in my view.  Further, given the constraints on producing product that
will fit in with multiple distributions, I doubt that the alternatives
you suggest to Info Oeser would work well for him anyway.

A key reason that Linux has succeeded is that it actively seeks to work
for a variety of people, purposes and products.  One operating system is
now a strong player in  the embedded market, the real time market, and
the High Performance Computing market, as well as being an important
player in a variety of other markets.  That's a rather stunning success.

If you went to your local grocery store with your (if you have one)
young child, and found that they had no Lucky Charms breakfast cereal
(your childs favorite) you would not be pleased if the store manager
tried to sell you Fruit Loops instead ... just as much sugar and food
coloring.

If we have features that seem to duplicate functionality, in a
different way, and that aren't causing us substantial grief to
maintain, and that aren't significantly hurting our performance or
robustness or security or seriously getting in the way of further
development, then we usually leave those features in.

Please understand, Max, that for every kernel hacker working in this
corner of the Linux kernel, there are a hundred or a thousand users
depending on what we do, and who will have to adapt to any incompatible
changes we make.  If we save ourselves an hour by removing "unnecessary"
features, we can cost a hundred others each some time adapting to this
change.  A few of those others may get hit for substantial effort, if
the change catches them unawares at the wrong time and place.

As good citizens of the universe, we should seek to optimize the
aggregate effort we spend to obtain a particular level of quality and
functionality.

Saving yourself an hour while you cost a hundred others ten minutes
each is not a net gain.  Sometimes this means not enforcing a "one way,
and one way only, to do any given task." I wouldn't go as far as Perl
does in this regard, but we do run a more polyglot product than say
Python.

Try thinking a little more like a WalMart product manager than a
Ferrari designer.  If it is currently selling to our customers, and if
we can fit it into our supply and distribution chain, and if we can
continue to make an adequate profit per foot of shelf space, then
continue to buy it, stock it, ship it, and sell it.

Thanks.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.940.382.4214