From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Eric Paris <eparis@redhat.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@sophos.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
agruen@suse.de
Subject: Re: Linux 2.6.36-rc7
Date: Thu, 7 Oct 2010 19:07:41 +0100 [thread overview]
Message-ID: <20101007190741.2dc62626@lxorguk.ukuu.org.uk> (raw)
In-Reply-To: <1286472835.2656.15.camel@dhcp231-98.rdu.redhat.com>
> 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
next prev parent reply other threads:[~2010-10-07 17:42 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-06 21:45 Linus Torvalds
2010-10-07 0:49 ` Stephen Rothwell
2010-10-08 15:05 ` James Bottomley
2010-10-07 16:10 ` Tvrtko Ursulin
2010-10-07 17:15 ` Tvrtko Ursulin
2010-10-07 17:33 ` Eric Paris
2010-10-07 18:07 ` Alan Cox [this message]
2010-10-07 17:49 ` Eric Paris
2010-10-08 12:06 ` Andreas Gruenbacher
2010-10-08 16:33 ` David Daney
2010-10-08 21:50 ` Andreas Gruenbacher
2010-10-08 21:59 ` H. Peter Anvin
2010-10-11 22:13 ` fanotify: disable fanotify syscalls Eric Paris
2010-10-08 16:38 ` Linux 2.6.36-rc7 Eric Paris
2010-10-08 21:45 ` Andreas Gruenbacher
2010-10-07 20:55 ` John Stoffel
2010-10-07 21:24 ` Eric Paris
2010-10-08 15:42 ` John Stoffel
2010-10-08 16:17 ` Tvrtko Ursulin
2010-10-08 16:41 ` Eric Paris
2010-10-18 11:01 ` Tvrtko Ursulin
2010-10-08 16:54 ` John Stoffel
2010-10-08 21:03 ` Andreas Gruenbacher
2010-10-09 0:46 ` John Stoffel
2010-10-07 19:28 ` Tejun Heo
2010-10-07 20:13 ` [dm-devel] " Milan Broz
2010-10-08 17:02 ` Tejun Heo
2010-10-10 11:56 ` Torsten Kaiser
2010-10-11 10:09 ` [PATCH wq#for-next] workqueue: fix HIGHPRI handling in keep_working() Tejun Heo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20101007190741.2dc62626@lxorguk.ukuu.org.uk \
--to=alan@lxorguk.ukuu.org.uk \
--cc=agruen@suse.de \
--cc=eparis@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=tvrtko.ursulin@sophos.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®