Messages in this thread | | | Date | Thu, 7 Oct 2010 19:07:41 +0100 | From | Alan Cox <> | Subject | Re: Linux 2.6.36-rc7 |
| |
> I see two possibilities off the top of my head: > > I could just slap an (unused) priority field onto the end of the > fanotify_init() syscall (assuming Linus doesn't murder me) so we can > build that support out with explicit priorities down the line, which I > think might be overkill, or > > The other option (without breaking ABI as it stands today) is to define > some set of the fanotify_init() flags to be a priority field, we've got > 32 bits and only use 2 of them so giving 4-8 bits of that as a priority > (next cycle) isn't an issue and can be easily backwards compatible.
Except you've then got a magic release that works differently to every other release afterwards and which sods law says will get shipped by some big vendor. Both your proposals are "we got the API wrong, lets have one kernel that is special", that isn't good in the bigger scheme of things and will have if kernel 2.6.blah then crap forced into bits of app/lib code forever.
Given two chunks of "oh dear" last minute stuff would it be safer to simply punt and just pull the syscall/prototype itself (leaving the rest) for the release. That can go into the first pass of the next kernel tree, and if it the fixes and priority bits all work out may well then be tiny enough for -stable.
Alan
| |