From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
To: backports@vger.kernel.org
Cc: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
Subject: [PATCH 07/10] backports: backport define of SIOCGHWTSTAMP
Date: Fri, 11 Apr 2014 18:34:32 -0700 [thread overview]
Message-ID: <1397266475-14442-8-git-send-email-mcgrof@do-not-panic.com> (raw)
In-Reply-To: <1397266475-14442-1-git-send-email-mcgrof@do-not-panic.com>
Ben added ioctl support for the unprivileged SIOCGHWTSTAMP
which is designed to just get the configuration, unlike
SIOCSHWTSTAMP which requires you to set it and only after
it returns the configuration.
Since we are carrying over a small addition to a UAPI header
without carrying it over completely (we use copy-list to
carry over full UAPI headers) its worth making a design note
about this.
We carry UAPI headers for backports to enable compilation
of kernel / driver code to compile without any changes. If
it so happens that a feature is backported it can be added
here but notice that if full subsystems are backported you
should just include the respective full header onto the
copy-list file so that its copied intact. The strategy on this
patch can be used to either backport a specific feature or
to just avoid having to do ifdef changes to compile kernel
or driver carried over by backports.
Userspace is *not expected* to copy over backports headers
to compile userspace programs, userspace programs can
and should consider carrying over a respective copy-list
of the latest UAPI kernel headers they need in their
upstream sources, the kernel the user uses, whether with
backports or not should be able to return -EOPNOTSUPP if
the feature is not available and let it through if its
supported and meats the expected form.
In this particular case if userspace tries to send the
SIOCGHWTSTAMP they'd end up with -ENOTTY.
mcgrof@ergon ~/linux (git::master)$ git describe --contains fd468c74
v3.14-rc1~94^2~622^2~12
commit fd468c74bd4d6949736810a80d6ca05eb20fba84
Author: Ben Hutchings <bhutchings@solarflare.com>
Date: Thu Nov 14 01:19:29 2013 +0000
net_tstamp: Add SIOCGHWTSTAMP ioctl to match SIOCSHWTSTAMP
SIOCSHWTSTAMP returns the real configuration to the application
using it, but there is currently no way for any other
application to find out the configuration non-destructively.
Add a new ioctl for this, making it unprivileged.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
---
backport/backport-include/uapi/linux/sockios.h | 31 ++++++++++++++++++++++++++
1 file changed, 31 insertions(+)
create mode 100644 backport/backport-include/uapi/linux/sockios.h
diff --git a/backport/backport-include/uapi/linux/sockios.h b/backport/backport-include/uapi/linux/sockios.h
new file mode 100644
index 0000000..6c4febe
--- /dev/null
+++ b/backport/backport-include/uapi/linux/sockios.h
@@ -0,0 +1,31 @@
+#ifndef __BACKPORT_LINUX_SOCKIOS_H
+#define __BACKPORT_LINUX_SOCKIOS_H
+#include_next <linux/sockios.h>
+#include <linux/version.h>
+
+/*
+ * Kernel backports UAPI note:
+ *
+ * We carry UAPI headers for backports to enable compilation
+ * of kernel / driver code to compile without any changes. If
+ * it so happens that a feature is backported it can be added
+ * here but notice that if full subsystems are backported you
+ * should just include the respective full header onto the
+ * copy-list file so that its copied intact. This strategy
+ * is used to either backport a specific feature or to just
+ * avoid having to do ifdef changes to compile.
+ *
+ * Userspace is not expected to copy over backports headers
+ * to compile userspace programs, userspace programs can
+ * and should consider carrying over a respective copy-list
+ * of the latest UAPI kernel headers they need in their
+ * upstream sources, the kernel the user uses, whether with
+ * backports or not should be able to return -EOPNOTSUPP if
+ * the feature is not available and let it through if its
+ * supported and meats the expected form.
+ */
+
+#if LINUX_VERSION_CODE < KERNEL_VERSION(3,14,0)
+#define SIOCGHWTSTAMP 0x89b1 /* get config */
+#endif /* LINUX_VERSION_CODE < KERNEL_VERSION(3,14,0) */
+#endif /* __BACKPORT_LINUX_SOCKIOS_H */
--
1.9.1
next prev parent reply other threads:[~2014-04-12 1:35 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-12 1:34 [PATCH 00/10] backports: catch up to next-20140411 Luis R. Rodriguez
2014-04-12 1:34 ` [PATCH 01/10] backports: add hwsim defconfig Luis R. Rodriguez
2014-04-12 1:34 ` [PATCH 02/10] backports: add napi_gro_flush() Luis R. Rodriguez
2014-04-12 1:34 ` [PATCH 03/10] backports: device: don't redefine DEVICE_ATTR_RO Luis R. Rodriguez
2014-04-12 1:34 ` [PATCH 04/10] backports: drop display output class support Luis R. Rodriguez
2014-04-12 1:34 ` [PATCH 05/10] backports: adjust flow_dissector.patch Luis R. Rodriguez
2014-04-12 1:34 ` [PATCH 06/10] backports: backport dev_consume_skb_any() Luis R. Rodriguez
2014-04-12 1:34 ` Luis R. Rodriguez [this message]
2014-04-12 1:34 ` [PATCH 08/10] backports: bump bluetooth reqs to 3.2 Luis R. Rodriguez
2014-04-12 1:41 ` Luis R. Rodriguez
2014-04-12 3:27 ` Luis R. Rodriguez
2014-04-12 1:34 ` [PATCH 09/10] backports: nuke support for kernels < 3.0 Luis R. Rodriguez
2014-04-12 1:34 ` [PATCH 10/10] backports: refresh patches for next-20140409 and next-20140411 Luis R. Rodriguez
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=1397266475-14442-8-git-send-email-mcgrof@do-not-panic.com \
--to=mcgrof@do-not-panic.com \
--cc=backports@vger.kernel.org \
/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