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



\
 
 \ /
  Last update: 2010-10-08 18:41    [W:0.101 / U:0.248 seconds]
©2003-2014 Jasper Spaans. Advertise on this site