On Wed, Oct 20, 2004 at 04:04:50PM -0700, David S. Miller wrote: > On Thu, 21 Oct 2004 00:56:25 +0200 > Andi Kleen <ak@xxxxxxx> wrote: > > > I don't think that's a good idea. Normally new system calls > > are relatively obscure and the system works fine without them, > > so urgent action is not needed. > > > > And I think we can trust architecture maintainers to regularly > > sync the system calls with i386. > > I disagree quite strongly. One major frustration for users of > non-x86 platforms is that functionality is often missing for some > time that we can make trivial to keep in sync. I'm not sure really if the users of some embedded platform are all sheering for key management system calls... I guess they will prefer just something that compiles. > > I religiously watch what goes into Linus's tree for this purpose, > but that is kind of a rediculious burdon to expect every platform > maintainer to do. It's not just system calls, we have signal handling > bug fixes, trap handling infrastructure, and now the nice generic > IRQ handling subsystem as other examples. Most of that is optional. When the arch maintainer choses not to use it you have just unnecessarily broken the build. IMHO breaking the build unnecessarily is extremly bad because it will prevent all testing. And would you really want to hold up the whole linux testing machinery just for some obscure system call? IMHO not a good tradeoff. > > Simply put, if you're not watching the tree in painstaking detail > every day, you miss all of these enhancements. I would assume the other maintainers go at least from time to time through the i386 diffs and check if they miss anything (that is what I do). For system calls they do definitely, although it may take some time. > > The knowledge should come from the person putting the changes into > the tree, therefore it gets done once and this makes it so that > the other platform maintainers will find out about it automatically > next time they update their tree. And causing merging headaches and all kind of other problems. -Andi
