1. 02 11月, 2017 1 次提交
    • G
      License cleanup: add SPDX license identifier to uapi header files with no license · 6f52b16c
      Greg Kroah-Hartman 提交于
      Many user space API headers are missing licensing information, which
      makes it hard for compliance tools to determine the correct license.
      
      By default are files without license information under the default
      license of the kernel, which is GPLV2.  Marking them GPLV2 would exclude
      them from being included in non GPLV2 code, which is obviously not
      intended. The user space API headers fall under the syscall exception
      which is in the kernels COPYING file:
      
         NOTE! This copyright does *not* cover user programs that use kernel
         services by normal system calls - this is merely considered normal use
         of the kernel, and does *not* fall under the heading of "derived work".
      
      otherwise syscall usage would not be possible.
      
      Update the files which contain no license information with an SPDX
      license identifier.  The chosen identifier is 'GPL-2.0 WITH
      Linux-syscall-note' which is the officially assigned identifier for the
      Linux syscall exception.  SPDX license identifiers are a legally binding
      shorthand, which can be used instead of the full boiler plate text.
      
      This patch is based on work done by Thomas Gleixner and Kate Stewart and
      Philippe Ombredanne.  See the previous patch in this series for the
      methodology of how this patch was researched.
      Reviewed-by: NKate Stewart <kstewart@linuxfoundation.org>
      Reviewed-by: NPhilippe Ombredanne <pombredanne@nexb.com>
      Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6f52b16c
  2. 09 10月, 2012 1 次提交
  3. 05 5月, 2011 1 次提交
    • C
      arch/tile: various header improvements for building drivers · 28d71741
      Chris Metcalf 提交于
      This change adds a number of missing headers in asm (fb.h, parport.h,
      serial.h, and vga.h) using the minimal generic versions.
      
      It also adds a number of missing interfaces that showed up as build
      failures when trying to build various drivers not normally included in the
      "tile" distribution: ioremap_wc(), memset_io(), io{read,write}{16,32}be(),
      virt_to_bus(), bus_to_virt(), irq_canonicalize(), __pte(), __pgd(),
      and __pmd().  I also added a cast in virt_to_page() since not all callers
      pass a pointer.
      
      I fixed <asm/stat.h> to properly include a __KERNEL__ guard for the
      __ARCH_WANT_STAT64 symbol, and <asm/swab.h> to use __builtin_bswap32()
      even for our 64-bit architecture, since the same code is produced.
      
      I added an export for get_cycles(), since it's used in some modules.
      
      And I made <arch/spr_def.h> properly include the __KERNEL__ guard,
      even though it's not yet exported, since it likely will be soon.
      Signed-off-by: NChris Metcalf <cmetcalf@tilera.com>
      28d71741
  4. 02 11月, 2010 1 次提交
    • C
      asm-generic/stat.h: support 64-bit file time_t for stat() · 2c7387ef
      Chris Metcalf 提交于
      The existing asm-generic/stat.h specifies st_mtime, etc., as a 32-value,
      and works well for 32-bit architectures (currently microblaze, score,
      and 32-bit tile).  However, for 64-bit architectures it isn't sufficient
      to return 32 bits of time_t; this isn't good insurance against the 2037
      rollover.  (It also makes glibc support less convenient, since we can't
      use glibc's handy STAT_IS_KERNEL_STAT mode.)
      
      This change extends the two "timespec" fields for each of the three atime,
      mtime, and ctime fields from "int" to "long".  As a result, on 32-bit
      platforms nothing changes, and 64-bit platforms will now work as expected.
      
      The only wrinkle is 32-bit userspace under 64-bit kernels taking advantage
      of COMPAT mode.  For these, we leave the "struct stat64" definitions with
      the "int" versions of the time_t and nsec fields, so that architectures
      can implement compat_sys_stat64() and friends with sys_stat64(), etc.,
      and get the expected 32-bit structure layout.  This requires a
      field-by-field copy in the kernel, implemented by the code guarded
      under __ARCH_WANT_STAT64.
      
      This does mean that the shape of the "struct stat" and "struct stat64"
      structures is different on a 64-bit kernel, but only one of the two
      structures should ever be used by any given process: "struct stat"
      is meant for 64-bit userspace only, and "struct stat64" for 32-bit
      userspace only.  (On a 32-bit kernel the two structures continue to have
      the same shape, since "long" is 32 bits.)
      
      The alternative is keeping the two structures the same shape on 64-bit
      kernels, which means a 64-bit time_t in "struct stat64" for 32-bit
      processes.  This is a little unnatural since 32-bit userspace can't
      do anything with 64 bits of time_t information, since time_t is just
      "long", not "int64_t"; and in any case 32-bit userspace might expect
      to be running under a 32-bit kernel, which can't provide the high 32
      bits anyway.  In the case of a 32-bit kernel we'd then be extending the
      kernel's 32-bit time_t to 64 bits, then truncating it back to 32 bits
      again in userspace, for no particular reason.  And, as mentioned above,
      if we have 64-bit time_t for 32-bit processes we can't easily use glibc's
      STAT_IS_KERNEL_STAT, since glibc's stat structure requires an embedded
      "struct timespec", which is a pair of "long" (32-bit) values in a 32-bit
      userspace.  "Inventive" solutions are possible, but are pretty hacky.
      Signed-off-by: NChris Metcalf <cmetcalf@tilera.com>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      2c7387ef
  5. 05 6月, 2010 1 次提交
  6. 06 7月, 2009 1 次提交
  7. 26 5月, 2009 1 次提交
  8. 27 3月, 2009 1 次提交