![]() | |||||||||||||
Messages in this thread |
Chris Wedgwood <cw@f00f.org> wrote: > > On Mon, May 10, 2004 at 04:28:18PM -0700, Andrew Morton wrote: > > > If vendors are forced to ship a nasty hack it often points at > > problems in the mainline kernel. Certainly that's true in this > > case. > > Yes, so let's discuss it and think about a nice clean solution rather > than hastily merge something that 'seems to work' without considering > the long term consequences of this. Has been discussed on this list. It requires worrisome changes to the capability system, changes to PAM, changes to login and changes to applications. > > And if we are unable to fix the kernel acceptably then I'd prefer > > that the expedient fix be in the mainstream kernel so as to prevent > > divergence in user-visible features between vendor kernels. > > And when we have a clean solution we will have to live with this hack > too. Maybe that's the price we pay for leaving this problem unsolved for a year. I must say that it's also to some extent a consequence of ISV's and vendors quitely working on problems in little corners. > > And let's remember, code-wise, this is a very small change. > > It's not the code size --- it's the fact we add a strange new semantic > (magic group) without what IMO is sufficient thought and discussion > into a stable kernel series knowing that we will probably *NEVER* be > able to remove this wart once we have a better solution. There is no magic group unless the admin chooses to set the sysctl. > > But it's too late. > > Why? Also, most existing users will be 2.4.x --- why does that not > nee this but 2.6.x _MUST_ had it? > > > This stuff is going out the door to end 2.6 users and that's just > > tough luck. The least we can do is to ensure that it works the same > > across different vendor's kernels. > > When was this issue properly discussed? It seems like it's a new > issue that's be hurried out the door without much consultation. > > It might be my interpretation, but this also reads to me like "I don't > think it's too ugly, it's my party so tough shit if you don't like it" > :) You misunderstand. Nasty workarounds will be shipped to end users by vendors. That's a certainty. We cannot change this now. What I wish to do is to ensure that all users receive the *same* nasty workaround. Call it damage control. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2005-03-22 13:03 [W:0.111 / U:0.090 seconds] ©2003-2008 Jasper Spaans | |||||||||||||