Re: 2.6.6-rc3-mm2 (4KSTACK)

[Bill Davidsen]

On Sun, 9 May 2004, Bartlomiej Zolnierkiewicz wrote:

> On Sunday 09 of May 2004 19:00, Bill Davidsen wrote:
> > No it's not that simple, this has nothing to do with binary modules, and
> > everything to do with not making 4k stack the only available
> > configuration in 2.6. Options are fine, but in a stable kernel series I
> > don't think think that the default should change part way into the
> > series, and certainly the availability of the original functionality
> > shouldn't go away, which is what I read AKPMs original post to state as
> > the goal.
> 
> What functionality are you talking about?
> We don't care about out of tree kernel code (be it GPL or Proprietary).

Let me say this one more time, since you keep changing the topic so you
can say that you don't care about something I never mentioned. I am
**NOT** talking about binary modules, I am **NOT** talking about out of
tree code, I am talking about applications which make calls that cause the
**IN TREE** code to use more than 4k.

> 
> > Making changes to the kernel which will break existing applications
> > seems to be the opposite of "stable." People who want a new kernel for
> > fixes don't usually want to have to upgrade and/or rewrite their
> > applications. The "we change the system interface everything we fix a
> 
> You don't understand what the patch is really about.
> 
> This is kernel stack not the user-space one so
> this change can't brake any application.

Right, the kernel code does not contain any places where the data passed
in a system call isn't reflected in stack usage.

> 
> > bug" approach comes from a well-known software company, but shouldn't be
> > the way *good* software is done.
> 
> It doesn't change any kernel interface visible to user-space
> and stack hungry kernel code needs fixing anyway.

And what better way to detect it than to release it in a stable kernel.
Don't bother to say "don't use -mm" AKPM has said it is intended for the
stable kernel, work or not.

===
Third request for info
===
I still haven't seen any objective data showing that there is any
measureable benefit from this, although I agree that smaller is good
practice, I don't think that throwing in a feature in a stable kernel,
which has been reported by others to corrupt data, is the best way to do
it.

-- 
bill davidsen <davidsen@xxxxxxx>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/