[PATCH 07/10] backports: backport define of SIOCGHWTSTAMP

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxx>
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@xxxxxxxxxxxxxx>

Signed-off-by: Luis R. Rodriguez <mcgrof@xxxxxxxxxxxxxxxx>
---
 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

--
To unsubscribe from this list: send the line "unsubscribe backports" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux