On Fri, 2010-10-08 at 14:06 +0200, Andreas Gruenbacher wrote: > On Thursday 07 October 2010 19:49:28 Eric Paris wrote: > > The safest thing would probably be to punt the syscalls to 2.6.37. > > Which is sad since I know a number of people are already working against > > them, but maybe that proves it's the best approach? > > I agree with removing the syscalls from 2.6.36 because of the following > reasons: I disagree with all of your reasons and have argued my position on this topic repeatedly and don't see the need to refute your claims again. However, THIS is potentially a real ABI problem and something which deals with the interface. Alan seemed to lean towards pulling the syscalls. It is relatively easily solved without changing the interface or breaking userspace in 2.6.37. We use some set of the flags bits as a priority (we only use 2 of the 32 bits today so we have plenty) and order groups with highest priority first, 0 priority last, and 2+ groups with the same priority have unpredictable ordering. I'd then call priorities other than 0 a 2.6.37 feature. If we do it in flags I think that leaves us with say 8 bits and thus 255 priorities. Maybe people want more, if so, that's a interface change to add a new argument. Now if Alan would still like me to pull, if anyone has any other 11th hour interface problems, or if 255 priorities doesn't seem like enough to someone I am wondering what the best way to unhook is. Just make the functions return -ENOSYS as the first line or actually troll through all of the arches and explicily unhook and rehook to sys_ni_syscall? I started on the latter, but it seems to be a rather large patch at this point... -Eric ------ I said I wouldn't refute your claims but I can't help myself on one account which I think might mislead people. * Some weaknesses in the interface design were only identified and fixed late in the -rc phase, changing the ABI. There may be more issues, like the priority discussion. This might leave us with a broken ABI we would need to support forever. Between rc2 and rc3 we switched the order and size of a couple of fields to help alignment, it did break ABI, but it wasn't an interface failing. See: 0fb85621df4f. It also lead to an interesting idea about a new type for linux/types.h which both fanotify and the networking could make use of (but isn't picked up, I'm not sure we know who is in charge of types.h) I concede the interface may in fact not be perfect for every user. I have ask for ideas and feedback on proposals for literally (not figuratively) years. It has gone through many iterations. The interface has been in Linus's kernel for some months and I know of numerous people who are starting to code to it and haven't (until now) found interface failings. We can talk about how problems might be out there but if they haven't been found after all this time I doubt just waiting longer is going to change anything. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
