[lkml]   [2010]   [Oct]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Linux 2.6.36-rc7
    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



    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

    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.

     \ /
      Last update: 2010-10-08 18:41    [W:0.044 / U:13.328 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site