lkml.org 
[lkml]   [2010]   [Oct]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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


\
 
 \ /
  Last update: 2010-10-07 19:45    [W:1.859 / U:0.468 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site