> The fact is, different people have different needs. YOU only need to care > about yourself. That's not true for a vendor. A single case that doesn't > work ends up either (a) being ignored or (b) costing them money. See the > problem? They can't win. Except by taking small steps, where the breakage > is hopefully small too - and more importantly, because it's spread out > over time, you hopefully know what broke it. > > And when I say RH, I mean "me". That's the reason I personally hate > merging "D-day" things where a lot of things change. I much prefer merging > individual changes in small pieces. When things go wrong - and they will - > you can look at the individual pieces and say "ok, it's definitely not > that one" or "Hmm.. unlikely, but let's ask the reporter to check that > thing anyway" or "ok, that looks suspicious, let's start from there".
this is exactly why the patch series I sent started with 64Kb. In fedora we use 2Mb actually, and I know of some cornercases where that gives issues (and the solution is a bit tricky). 64Kb is a nice safe start, and it means the implementation can be quite simple. Later on, once this patch has been proven solid and not to break stuff, adding a patch to bring it up to 2Mb or so (I don't think more makes much sense, but I'm open to debates about the ideal size for this, it's a tunable) that needs to deal with stack rlimits < 2Mb and such can be done as a separate step. Which then will in itself be quite simple again. - 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/
