This website requires JavaScript.
About
Status
₊˚⊹Discord
Explore
Register
Sign in
Reference in a new issue
Blame
Copy permalink
Reference in a new issue
Copy permalink
kernel
/
linux
Star
0
Fork
You've already forked linux
0
mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/
synced
2026-11-15 19:56:03 +00:00
Code
Issues
Releases
Packages
Activity
3389648819
linux
/
arch
/
s390
/
include
/
uapi
/
asm
/
ucontext.h
41 lines
1.2 KiB
Raw
Normal View
History
License cleanup: add SPDX license identifier to uapi header files with no license 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: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-01 15:08:43 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
s390: add support for vector extension The vector extension introduces 32 128-bit vector registers and a set of instruction to operate on the vector registers. The kernel can control the use of vector registers for the problem state program with a bit in control register 0. Once enabled for a process the kernel needs to retain the content of the vector registers on context switch. The signal frame is extended to include the vector registers. Two new register sets NT_S390_VXRS_LOW and NT_S390_VXRS_HIGH are added to the regset interface for the debugger and core dumps. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2014-10-06 17:53:53 +02:00
[S390] 64-bit register support for 31-bit processes From: Heiko Carstens <heiko.carstens@de.ibm.com> From: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2009-10-06 10:34:13 +02:00
s390: add support for vector extension The vector extension introduces 32 128-bit vector registers and a set of instruction to operate on the vector registers. The kernel can control the use of vector registers for the problem state program with a bit in control register 0. Once enabled for a process the kernel needs to retain the content of the vector registers on context switch. The signal frame is extended to include the vector registers. Two new register sets NT_S390_VXRS_LOW and NT_S390_VXRS_HIGH are added to the regset interface for the debugger and core dumps. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2014-10-06 17:53:53 +02:00
[S390] 64-bit register support for 31-bit processes From: Heiko Carstens <heiko.carstens@de.ibm.com> From: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2009-10-06 10:34:13 +02:00
s390/compat: correct ucontext layout for high gprs The uc_sigmask definition in the kernel differs from the one in the glibc, the kernel uc_sigmask has 64 bits while the glibc verison is 1024 bits. The extension of the ucontext structure for 64-bit register support for 31-bit compat processes added a new field uc_gprs_high which starts 8 bytes after the uc_sigmask field. As the glibc view of the ucontext assumes a size of 128 bytes for uc_sigmask add a 120 byte padding to the kernel structure ucontext_extended after the 8 byte uc_sigmask. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2014-06-11 16:06:12 +02:00
s390: add support for vector extension The vector extension introduces 32 128-bit vector registers and a set of instruction to operate on the vector registers. The kernel can control the use of vector registers for the problem state program with a bit in control register 0. Once enabled for a process the kernel needs to retain the content of the vector registers on context switch. The signal frame is extended to include the vector registers. Two new register sets NT_S390_VXRS_LOW and NT_S390_VXRS_HIGH are added to the regset interface for the debugger and core dumps. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2014-10-06 17:53:53 +02:00
[S390] 64-bit register support for 31-bit processes From: Heiko Carstens <heiko.carstens@de.ibm.com> From: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2009-10-06 10:34:13 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
s390/compat: correct ucontext layout for high gprs The uc_sigmask definition in the kernel differs from the one in the glibc, the kernel uc_sigmask has 64 bits while the glibc verison is 1024 bits. The extension of the ucontext structure for 64-bit register support for 31-bit compat processes added a new field uc_gprs_high which starts 8 bytes after the uc_sigmask field. As the glibc view of the ucontext assumes a size of 128 bytes for uc_sigmask add a 120 byte padding to the kernel structure ucontext_extended after the 8 byte uc_sigmask. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2014-06-11 16:06:12 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00