On December 9, 2023 10:21:34 PM PST, Juergen Gross wrote:
>Introduce the macro ALT_NOT_XEN as a short form of
>ALT_NOT(X86_FEATURE_XENPV).
>
>Suggested-by: Peter Zijlstra (Intel)
>Signed-off-by: Juergen Gross
>---
>V3:
>- split off from next patch
>V5:
>- move patch to the start of the series
ovide a *general* solution that fits all
distributions × all boot scenarios.
On April 20, 2021 1:30:07 AM PDT, David Laight wrote:
>From: H. Peter Anvin
>> Sent: 20 April 2021 00:03
>>
>> When compiling on a different machine than the runtime target,
>> including but not
From: "H. Peter Anvin (Intel)"
The image generation scripts in arch/x86/boot are pretty out of date,
except for the isoimage target. Update and clean up the
genimage.sh script, and make it support an arbitrary number of
initramfs files in the image.
Add a "hdimage" target,
From: "H. Peter Anvin (Intel)"
Make it easy to generate a disk image which includes the all-modules
initramfs image.
Signed-off-by: H. Peter Anvin (Intel)
---
arch/x86/Makefile | 3 ++-
arch/x86/boot/Makefile | 20
2 files changed, 18 insertions(+), 5
From: "H. Peter Anvin (Intel)"
Some distributions really cannot be booted without modules
anymore. To allow an externally built kernel to be run, it is handy to
be able to create an initramfs image with all the modules, that can
appended to an existing initramfs image (preferrably w
From: "H. Peter Anvin" (Intel)
When compiling on a different machine than the runtime target,
including but not limited to simulators, it is rather handy to be able
to produce a bootable image. The scripts for that in x86 are
relatively old, and assume a BIOS system.
This adds a bu
From: "H. Peter Anvin" (Intel)
Some distributions really cannot be booted without modules
anymore. To allow an externally built kernel to be run, it is handy to
be able to create an initramfs image with all the modules, that can
appended to an existing initramfs image (preferrably w
From: "H. Peter Anvin" (Intel)
The image generation scripts in arch/x86/boot are pretty out of date,
except for the isoimage target. Update and clean up the
genimage.sh script, and make it support an arbitrary number of
initramfs files in the image.
Add a "hdimage" target,
From: "H. Peter Anvin" (Intel)
When compiling on a different machine than the runtime target,
including but not limited to simulators, it is rather handy to be able
to produce a bootable image. The scripts for that in x86 are
relatively old, and assume a BIOS system.
This adds a bu
From: "H. Peter Anvin" (Intel)
Make it easy to generate a disk image which includes the all-modules
initramfs image.
Signed-off-by: H. Peter Anvin (Intel)
---
arch/x86/Makefile | 3 ++-
arch/x86/boot/Makefile | 11 +++
2 files changed, 13 insertions(+), 1 deletion(-)
On 2020-08-31 22:38, Randy Dunlap wrote:
>
> --- linux-next-20200828.orig/Documentation/admin-guide/svga.rst
> +++ linux-next-20200828/Documentation/admin-guide/svga.rst
> @@ -12,7 +12,7 @@ Intro
> This small document describes the "Video Mode Selection" feature which
> allows the use of
If you are going to fix the language...
On 2020-08-31 22:25, Cao jin wrote:
> Sorry, I mis-copied 2 addresses. make sure they are CCed.
>
> On 9/1/20 11:41 AM, Cao jin wrote:
>> Typo fix & file name update
>>
>> Signed-off-by: Cao jin
>> ---
>> Documentation/x86/boot.rst | 4 ++--
>> 1 file
On 2020-08-14 07:56, Dave Hansen wrote:
>
> From: Dave Hansen
>
> Greg has challenged some recent driver submitters on their license
> choices. He was correct to do so, as the choices in these instances
> did not always advance the aims of the submitters.
>
> But, this left submitters (and the
Rewrite commit message.
>
> Signed-off-by: Uros Bizjak
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Borislav Petkov
> Cc: "H. Peter Anvin"
Reviewed-by: H. Peter Anvin (Intel)
On 2020-08-27 09:49, Uros Bizjak wrote:
> Use XORL r32,r32 for all operand sizes. x86_64 zero extends 32bit
> operations, so for 64bit operands, XORL r32,r32 is functionally
> equal to XORL r64,r64, but avoids a REX prefix byte when legacy
> registers are used.
Please make it clear that this
On 2020-08-24 14:10, Andy Lutomirski wrote:
>
> PTRACE_READ_SEGMENT_DESCRIPTOR to read a segment descriptor.
>
> PTRACE_SET_FS / PTRACE_SET_GS: Sets FS or GS and updates the base accordingly.
>
> PTRACE_READ_SEGMENT_BASE: pass in a segment selector, get a base out.
> You would use this to
On 2020-08-18 13:58, Nick Desaulniers wrote:
> On Tue, Aug 18, 2020 at 1:27 PM Nick Desaulniers
> wrote:
>>
>> On Tue, Aug 18, 2020 at 1:24 PM Arvind Sankar wrote:
>>>
>>> On Tue, Aug 18, 2020 at 12:13:22PM -0700, Linus Torvalds wrote:
>>>> On Tue
On 2020-08-18 10:56, Nick Desaulniers wrote:
>>
>> The problem here is twofold:
>>
>> 1. The user would be expected to know what kind of the optimizations the
>> compiler can do on what function, which is private knowledge to the
>> compiler.
>>
>> 2. The only way to override -fno-builtin is by a
On 2020-08-17 15:02, Nick Desaulniers wrote:
> -ffreestanding typically inhibits "libcall optimizations" where calls to
> certain library functions can be replaced by the compiler in certain
> cases to calls to other library functions that may be more efficient.
> This can be problematic for
On 2020-08-17 15:02, Nick Desaulniers wrote:
> LLVM implemented a recent "libcall optimization" that lowers calls to
> `sprintf(dest, "%s", str)` where the return value is used to
> `stpcpy(dest, str) - dest`. This generally avoids the machinery involved
> in parsing format strings. This
On 2020-07-12 05:59, t...@redhat.com wrote:
> From: Tom Rix
>
> clang static analysis flags this error
>
> lib/decompress_bunzip2.c:671:13: warning: Result of 'malloc' is converted
> to a pointer of type 'unsigned int', which is incompatible with sizeof
> operand type 'int'
On 2020-06-15 05:53, Christoph Hellwig wrote:
> BLKFLSBUF used to be overloaded for the ramdisk driver to free the whole
> ramdisk, which was completely different behavior compared to all other
> drivers. But this magic overload got removed in commit ff26956875c2
> ("brd: remove support for
On 2020-06-22 14:01, Tom Rini wrote:
>
> I'm picky here because, well, there's a whole lot of moving parts in the
> pre-kernel world. In a strict sense, "UEFI" doesn't do anything with
> the kernel but based on hpa's comments I assume that at least the
> in-kernel UEFI stub does what
On 2020-06-22 13:40, Tom Rini wrote:
> On Mon, Jun 22, 2020 at 01:02:16PM -0700, ron minnich wrote:
>
>> The other thing you ought to consider fixing:
>> initrd is documented as follows:
>>
>> initrd= [BOOT] Specify the location of the initial ramdisk
>>
>> for bootloaders only.
On 2020-05-19 07:38, Andreas Rammhold wrote:
> Hi,
>
> I've been running into a weird problem with UMIP on a current Ryzen
> 3900x with kernel 5.6.11 where a process receives a page fault after the
> kernel handled the SLDT (or SIDT) instruction (emulation).
>
> The program I am running is run
Reviewed-by: H. Peter Anvin (Intel)
On 2020-05-08 02:22, Uros Bizjak wrote:
> Current minimum required version of binutils is 2.23,
> which supports INVPCID instruction mnemonic.
>
> Replace the byte-wise specification of INVPCID with
> this proper mnemonic.
>
> Signe
On 2020-05-08 10:21, Nick Desaulniers wrote:
>>
>> One last suggestion. Add the "b" modifier to the mask operand: "orb
>> %b1, %0". That forces the compiler to use the 8-bit register name
>> instead of trying to deduce the width from the input.
>
> Ah right:
>
On 8/24/19 11:19 AM, Pavel Machek wrote:
> On Fri 2019-08-23 01:10:49, tip-bot2 for Tom Lendacky wrote:
>> The following commit has been merged into the x86/urgent branch of tip:
>>
>> Commit-ID: c49a0a80137c7ca7d6ced4c812c9e07a949f6f24
>> Gitweb:
>>
On 7/25/19 3:03 PM, Thomas Gleixner wrote:
> On Thu, 25 Jul 2019, h...@zytor.com wrote:
>> On July 25, 2019 2:48:30 PM PDT, Thomas Gleixner wrote:
>>>
>>> But seriously I think it's not completely insane what they are doing
>>> and the table based approach is definitely more readable and
On 7/25/19 12:22 AM, Thomas Gleixner wrote:
>>
>> The problem with this is that it will break silently when changes are
>> made to this structure.
>
> That's not really the worst problem. Changes to that struct which touch any
> of the to be cleared ranges will break anyway if not handled
to the boot loader.
>
> Suggested-by: H. Peter Anvin
> Signed-off-by: Daniel Kiper
> Reviewed-by: Ross Philipson
> Reviewed-by: Eric Snowberg
> ---
> I know that setup_header2 is not the best name. There were some
> alternatives proposed like setup_header_extra, setup_
On 5/17/19 2:02 PM, Arvind Sankar wrote:
> On Fri, May 17, 2019 at 01:18:11PM -0700, h...@zytor.com wrote:
>>
>> Ok... I just realized this does not work for a modular initramfs, composed
>> at load time from multiple files, which is a very real problem. Should be
>> easy enough to deal with:
On 5/17/19 1:18 PM, h...@zytor.com wrote:
>
> Ok... I just realized this does not work for a modular initramfs, composed at
> load time from multiple files, which is a very real problem. Should be easy
> enough to deal with: instead of one large file, use one companion file per
> source file,
On 3/29/19 2:09 PM, Paul E. McKenney wrote:
>>
>> Note: the atomic versions of these functions obviously need to have
>> "volatile" and the clobber anyway, as they are by definition barriers
>> and moving memory operations around them would be a very serious error.
>
> The atomic functions that
On 3/29/19 8:54 AM, Alexander Potapenko wrote:
>
>> Of course, this would force the compiler to actually compute the
>> offset, which would slow things down. I have no idea whether this
>> would be better or worse than just using the "memory" clobber.
> Just adding the "memory" clobber to
Dumb question: this is basically a pty on steroids. Wouldn't this be
better done by enhancing the pty devices?
-0hpa
On 3/6/19 3:37 PM, Daniel Colascione wrote:
>
> I just don't get the opposition to Joel's work. The rest of the thread
> already goes into detail about the problems with pure-filesystem
> solutions, and you and others are just totally ignoring those
> well-thought-out rationales for the module
On 3/6/19 3:37 PM, Daniel Colascione wrote:
>
> I just don't get the opposition to Joel's work. The rest of the thread
> already goes into detail about the problems with pure-filesystem
> solutions, and you and others are just totally ignoring those
> well-thought-out rationales for the module
On 3/6/19 3:09 PM, Pavel Machek wrote:
> On Fri 2019-01-18 17:55:43, Joel Fernandes wrote:
>> From: "Joel Fernandes (Google)"
>>
>> Introduce in-kernel headers and other artifacts which are made available
>> as an archive through proc (/proc/kheaders.tgz file). This archive makes
>> it possible
On 2/19/19 4:48 AM, Will Deacon wrote:
>
> I think you'll still hate this, but could we not disable preemption during
> the uaccess-enabled region, re-enabling it on the fault path after we've
> toggled uaccess off and disable it again when we return back to the
> uaccess-enabled region? Doesn't
On 2/18/19 6:20 PM, Andy Lutomirski wrote:
>
>
>> On Feb 18, 2019, at 4:24 PM, Linus Torvalds
>> wrote:
>>
>>> On Mon, Feb 18, 2019 at 2:31 PM H. Peter Anvin wrote:
>>>
>>> The question is what "fix it" means. I'm really con
On 2/16/19 2:30 AM, Peter Zijlstra wrote:
> On Fri, Feb 15, 2019 at 08:06:56PM -0800, h...@zytor.com wrote:
>> This implies we invoke schedule -- a restricted operation (consider
>> may_sleep) during execution of STAC-enabled code, but *not* as an
>> exception or interrupt, since those preserve
On 1/16/19 11:54 PM, Masami Hiramatsu wrote:
> On Wed, 16 Jan 2019 16:32:59 -0800
> Rick Edgecombe wrote:
>
>> From: Nadav Amit
>>
>> It seems dangerous to allow code modifications to take place
>> concurrently with module unloading. So take the text_mutex while the
>> memory of the module is
On 1/17/19 10:07 AM, Nadav Amit wrote:
>> On Jan 16, 2019, at 11:54 PM, Masami Hiramatsu wrote:
>>
>> On Wed, 16 Jan 2019 16:32:59 -0800
>> Rick Edgecombe wrote:
>>
>>> From: Nadav Amit
>>>
>>> It seems dangerous to allow code modifications to take place
>>> concurrently with module unloading.
On 1/14/19 9:01 PM, H. Peter Anvin wrote:
>
> This could be as simple as spinning for a limited time waiting for
> states 0 or 3 if we are not the patching CPU. It is also not necessary
> to wait for the mask to become zero for the first sync if we find
> ourselves suddenly in
On 1/14/19 7:05 PM, Andy Lutomirski wrote:
> On Mon, Jan 14, 2019 at 2:55 PM H. Peter Anvin wrote:
>>
>> I think this sequence ought to work (keep in mind we are already under a
>> mutex, so the global data is safe even if we are preempted):
>
> I'm tr
I think this sequence ought to work (keep in mind we are already under a
mutex, so the global data is safe even if we are preempted):
set up page table entries
invlpg
set up bp patching global data
cpu = get_cpu()
bp_old_value = atomic_read(bp_write_addr)
still have to deal
with #MC and what not.)
The fundamental problem here is that we don't see the #BP on the
patching processor, in which case we could simply complete the patching
from the #BP handler on that processor.
On 1/13/19 6:40 PM, H. Peter Anvin wrote:
> On 1/13/19 6:31 PM, H. Pe
On 1/13/19 6:31 PM, H. Peter Anvin wrote:
>
> static cpumask_t text_poke_cpumask;
>
> static void text_poke_sync(void)
> {
> smp_wmb();
> text_poke_cpumask = cpu_online_mask;
> smp_wmb(); /* Should be optional on x86 */
> cpum
On 1/11/19 11:39 AM, Jiri Kosina wrote:
> On Fri, 11 Jan 2019, h...@zytor.com wrote:
>
>> I still don't see why can't simply spin in the #BP handler until the
>> patch is complete.
>
> I think this brings us to the already discussed possible deadlock, when
> one CPU#0 is in the middle of
On 1/10/19 9:31 AM, Linus Torvalds wrote:
> On Wed, Jan 9, 2019 at 2:59 PM Josh Poimboeuf wrote:
>>
>> NOTE: At least experimentally, the call destination writes seem to be
>> atomic with respect to instruction fetching. On Nehalem I can easily
>> trigger crashes when writing a call destination
On 12/3/18 9:32 PM, Juergen Gross wrote:
>
> I'd like to send a followup patch doing that. And I'd like to not only
> test sentinel for being non-zero, but all padding fields as well. This
> should be 4.21 material, though.
>
No, you can't do that. That breaks backwards compatibility.
On 12/3/18 9:32 PM, Juergen Gross wrote:
>
> I'd like to send a followup patch doing that. And I'd like to not only
> test sentinel for being non-zero, but all padding fields as well. This
> should be 4.21 material, though.
>
No, you can't do that. That breaks backwards compatibility.
On 11/23/18 3:57 AM, Julien Thierry wrote:
>
> On x86, the EFLAGS.AC bit is also saved upon exception and I think it is
> cleared upon exception entry so there is implicit exit from the
> user_access mode when taking exception/interrupt.
>
No, it is restored, not cleared.
In summary: on
On 11/23/18 3:57 AM, Julien Thierry wrote:
>
> On x86, the EFLAGS.AC bit is also saved upon exception and I think it is
> cleared upon exception entry so there is implicit exit from the
> user_access mode when taking exception/interrupt.
>
No, it is restored, not cleared.
In summary: on
On 11/26/18 9:49 AM, Sebastian Andrzej Siewior wrote:
> On 2018-11-26 18:27:06 [+0100], Jann Horn wrote:
>> commit 75045f77f7a7 ("x86/extable: Introduce _ASM_EXTABLE_UA for uaccess
>> fixups") incorrectly replaced the fixup entry for XSTATE_OP with a
>> user-#PF-only fixup. However, XRSTOR can
On 11/26/18 9:49 AM, Sebastian Andrzej Siewior wrote:
> On 2018-11-26 18:27:06 [+0100], Jann Horn wrote:
>> commit 75045f77f7a7 ("x86/extable: Introduce _ASM_EXTABLE_UA for uaccess
>> fixups") incorrectly replaced the fixup entry for XSTATE_OP with a
>> user-#PF-only fixup. However, XRSTOR can
On 11/20/18 10:18 AM, Peter Zijlstra wrote:
>>
>> Can't we make this test in text_poke() directly, please?
>
> He does that in 9/10 iirc.
>
No, in 9/10 he does that change locally for the jump_label, but there is
absolutely no reason not to do that test in text_poke() proper, and
simply use
On 11/20/18 10:18 AM, Peter Zijlstra wrote:
>>
>> Can't we make this test in text_poke() directly, please?
>
> He does that in 9/10 iirc.
>
No, in 9/10 he does that change locally for the jump_label, but there is
absolutely no reason not to do that test in text_poke() proper, and
simply use
On 11/13/18 5:07 AM, Nadav Amit wrote:
> There is no apparent reason not to use text_poke_early() while we are
> during early-init and we do not patch code that might be on the stack
> (i.e., we'll return to the middle of the patched code). This appears to
> be the case of jump-labels, so do so.
>
On 11/13/18 5:07 AM, Nadav Amit wrote:
> There is no apparent reason not to use text_poke_early() while we are
> during early-init and we do not patch code that might be on the stack
> (i.e., we'll return to the middle of the patched code). This appears to
> be the case of jump-labels, so do so.
>
On 11/19/18 11:52 AM, Andy Lutomirski wrote:
>
> I thought I benchmarked this on Intel at some point and found the
> LFENCE;RDTSC variant to be slightly faster. But I believe you, so:
>
> Acked-by: Andy Lutomirski
>
As long as the difference isn't significant, the simplicity would seem to be
On 11/19/18 11:52 AM, Andy Lutomirski wrote:
>
> I thought I benchmarked this on Intel at some point and found the
> LFENCE;RDTSC variant to be slightly faster. But I believe you, so:
>
> Acked-by: Andy Lutomirski
>
As long as the difference isn't significant, the simplicity would seem to be
On 11/10/18 1:03 AM, Juergen Gross wrote:
>
> How would that help? The garabge data written could have the correct
> terminal sentinel value by chance.
>
> That's why I re-used an existing field in setup_header (the version) to
> let grub tell the kernel which part of setup_header was written by
On 11/10/18 1:03 AM, Juergen Gross wrote:
>
> How would that help? The garabge data written could have the correct
> terminal sentinel value by chance.
>
> That's why I re-used an existing field in setup_header (the version) to
> let grub tell the kernel which part of setup_header was written by
On 10/23/18 9:31 AM, Kirill A. Shutemov wrote:
>
> It shouldn't be a particularly hot path anyway.
>
That's putting it mildly.
-hpa
On 10/23/18 9:31 AM, Kirill A. Shutemov wrote:
>
> It shouldn't be a particularly hot path anyway.
>
That's putting it mildly.
-hpa
On 10/23/18 09:02, h...@zytor.com wrote:
>>
>> As I think Al's big termios cleanups are going to be hitting Linus's
>> tree soon, do you know how these patches interact with that?
>>
>> This patch seems like it will not, so I'll be glad to queue that up
>> after my first round of patches get
On 10/23/18 09:02, h...@zytor.com wrote:
>>
>> As I think Al's big termios cleanups are going to be hitting Linus's
>> tree soon, do you know how these patches interact with that?
>>
>> This patch seems like it will not, so I'll be glad to queue that up
>> after my first round of patches get
On 10/23/18 11:40, Nick Desaulniers wrote:
> On Mon, Oct 22, 2018 at 10:11 PM Nadav Amit wrote:
>>
>> at 5:37 PM, Nathan Chancellor wrote:
>>
>> Commit 77b0bf55bc67 ("kbuild/Makefile: Prepare for using macros in
>> inline assembly code to work around asm() related GCC inlining bugs")
>> added
On 10/23/18 11:40, Nick Desaulniers wrote:
> On Mon, Oct 22, 2018 at 10:11 PM Nadav Amit wrote:
>>
>> at 5:37 PM, Nathan Chancellor wrote:
>>
>> Commit 77b0bf55bc67 ("kbuild/Makefile: Prepare for using macros in
>> inline assembly code to work around asm() related GCC inlining bugs")
>> added
On 10/15/18 10:23 AM, Paolo Bonzini wrote:
>
> Even for a value from a 32-bit register? That would be _BIT, which
> doesn't exist.
>
Just use _BITUL(). gcc is smart enough to know that that the resulting value
is representable in 32 bits.
Or if you really care, submit a patch to create
On 10/15/18 10:23 AM, Paolo Bonzini wrote:
>
> Even for a value from a 32-bit register? That would be _BIT, which
> doesn't exist.
>
Just use _BITUL(). gcc is smart enough to know that that the resulting value
is representable in 32 bits.
Or if you really care, submit a patch to create
On 10/7/18 6:04 PM, peng.h...@zte.com.cn wrote:
\>
> #define AVIC_LOGICAL_ID_ENTRY_GUEST_PHYSICAL_ID_MASK(0xFF)
> -#define AVIC_LOGICAL_ID_ENTRY_VALID_MASK(1 << 31)
> +#define AVIC_LOGICAL_ID_ENTRY_VALID_MASK(1UL << 31)
>>>
It is reasonable to change to
On 10/7/18 6:04 PM, peng.h...@zte.com.cn wrote:
\>
> #define AVIC_LOGICAL_ID_ENTRY_GUEST_PHYSICAL_ID_MASK(0xFF)
> -#define AVIC_LOGICAL_ID_ENTRY_VALID_MASK(1 << 31)
> +#define AVIC_LOGICAL_ID_ENTRY_VALID_MASK(1UL << 31)
>>>
It is reasonable to change to
On 10/11/18 2:40 PM, Theodore Y. Ts'o wrote:
> On Thu, Oct 11, 2018 at 07:14:30AM -0700, h...@zytor.com wrote:
>>>
>>> I mean - what is the baud rate of a pty ?
>>
>> Whatever the master wants it to be...
>
> I think Alan's point is that it is highly unlikely you would be able
> to push the
On 10/11/18 2:40 PM, Theodore Y. Ts'o wrote:
> On Thu, Oct 11, 2018 at 07:14:30AM -0700, h...@zytor.com wrote:
>>>
>>> I mean - what is the baud rate of a pty ?
>>
>> Whatever the master wants it to be...
>
> I think Alan's point is that it is highly unlikely you would be able
> to push the
On 10/11/18 12:36 PM, Craig Milo Rogers wrote:
> On 18.10.11, Alan Cox wrote:
>> I mean - what is the baud rate of a pty ?
>
> Solaris made the distinction between B0, which means pty hangup mode,
> and any other baud rate:
>
> https://docs.oracle.com/cd/E88353_01/html/E37851/pty-4d.html
On 10/11/18 12:36 PM, Craig Milo Rogers wrote:
> On 18.10.11, Alan Cox wrote:
>> I mean - what is the baud rate of a pty ?
>
> Solaris made the distinction between B0, which means pty hangup mode,
> and any other baud rate:
>
> https://docs.oracle.com/cd/E88353_01/html/E37851/pty-4d.html
On 10/09/18 12:51, Willy Tarreau wrote:
> On Tue, Oct 09, 2018 at 12:19:04PM -0700, H. Peter Anvin wrote:
>> [Resending to a wider audience]
>>
>> In trying to get the termios2 interface actually implemented in glibc,
>> the question came up if we will ever care about b
On 10/09/18 12:51, Willy Tarreau wrote:
> On Tue, Oct 09, 2018 at 12:19:04PM -0700, H. Peter Anvin wrote:
>> [Resending to a wider audience]
>>
>> In trying to get the termios2 interface actually implemented in glibc,
>> the question came up if we will ever care about b
[Resending to a wider audience]
In trying to get the termios2 interface actually implemented in glibc,
the question came up if we will ever care about baud rates in excess of
4 Gbps, even in the relatively remote future.
If this is something we care about *at all*, I would like to suggest
that
[Resending to a wider audience]
In trying to get the termios2 interface actually implemented in glibc,
the question came up if we will ever care about baud rates in excess of
4 Gbps, even in the relatively remote future.
If this is something we care about *at all*, I would like to suggest
that
On 10/8/18 8:38 AM, Johan Hovold wrote:
> On Sun, Oct 07, 2018 at 09:06:19PM -0700, H. Peter Anvin wrote:
>> From: "H. Peter Anvin (Intel)"
>>
>> Alpha has had c_ispeed and c_ospeed, but still set speeds in c_cflags
>> using arbitrary flags. Because BOTHER
On 10/8/18 8:38 AM, Johan Hovold wrote:
> On Sun, Oct 07, 2018 at 09:06:19PM -0700, H. Peter Anvin wrote:
>> From: "H. Peter Anvin (Intel)"
>>
>> Alpha has had c_ispeed and c_ospeed, but still set speeds in c_cflags
>> using arbitrary flags. Because BOTHER
On 10/04/18 13:29, Andy Lutomirski wrote:
>>
>> Wonderful.
>>
>> Here is the horrible code I mentioned yesterday. This is about
>> implementing the immediate-patching framework that Linus and others have
>> discussed (it helps both performance and kernel hardening):
>>
>
> I'm wondering if a
On 10/04/18 13:29, Andy Lutomirski wrote:
>>
>> Wonderful.
>>
>> Here is the horrible code I mentioned yesterday. This is about
>> implementing the immediate-patching framework that Linus and others have
>> discussed (it helps both performance and kernel hardening):
>>
>
> I'm wondering if a
On 10/04/18 15:35, Max Filippov wrote:
>
> Looks good. But why not removing the header entirely and adding
> generic-y += termbits.h
> to arch/xtensa/include/uapi/asm/Kbuild?
>
Good idea. Should do that for others that also have the same #include.
-hpa
On 10/04/18 15:35, Max Filippov wrote:
>
> Looks good. But why not removing the header entirely and adding
> generic-y += termbits.h
> to arch/xtensa/include/uapi/asm/Kbuild?
>
Good idea. Should do that for others that also have the same #include.
-hpa
The MIPS definition of termbits.h is almost identical to the generic
one, so use the generic one and only redefine a handful of constants.
Move TIOCSER_TEMT to ioctls.h where it lives for all other
architectures.
Signed-off-by: H. Peter Anvin (Intel)
Cc: Ralf Baechle
Cc: Paul Burton
Cc: James
The MIPS definition of termbits.h is almost identical to the generic
one, so use the generic one and only redefine a handful of constants.
Move TIOCSER_TEMT to ioctls.h where it lives for all other
architectures.
Signed-off-by: H. Peter Anvin (Intel)
Cc: Ralf Baechle
Cc: Paul Burton
Cc: James
The Xtensa definition of termbits.h is identical to the generic one.
Signed-off-by: H. Peter Anvin (Intel)
Cc: Chris Zankel
Cc: Max Filippov
Cc: Thomas Gleixner
Cc: Greg Kroah-Hartman
Cc: Philippe Ombredanne
Cc: Kate Stewart
Cc:
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
---
arch/xtensa
changed, 27 insertions(+), 824 deletions(-)
Signed-off-by: H. Peter Anvin (Intel)
Cc: "James E.J. Bottomley"
Cc: Arnd Bergmann
Cc: Chris Zankel
Cc: Fenghua Yu
Cc: Greg Kroah-Hartman
Cc: Helge Deller
Cc: James Hogan
Cc: Jiri Slaby
Cc: Kate Stewart
Cc: Max Filippov
Cc: Paul
Some architectures, in this case MIPS, need a couple of legacy alias
constants for bits. There really is no reason why we can't define them
generically for all architectures.
Signed-off-by: H. Peter Anvin (Intel)
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
linux-kernel
Some architectures, in this case MIPS, need a couple of legacy alias
constants for bits. There really is no reason why we can't define them
generically for all architectures.
Signed-off-by: H. Peter Anvin (Intel)
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
linux-kernel
The Xtensa definition of termbits.h is identical to the generic one.
Signed-off-by: H. Peter Anvin (Intel)
Cc: Chris Zankel
Cc: Max Filippov
Cc: Thomas Gleixner
Cc: Greg Kroah-Hartman
Cc: Philippe Ombredanne
Cc: Kate Stewart
Cc:
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
---
arch/xtensa
changed, 27 insertions(+), 824 deletions(-)
Signed-off-by: H. Peter Anvin (Intel)
Cc: "James E.J. Bottomley"
Cc: Arnd Bergmann
Cc: Chris Zankel
Cc: Fenghua Yu
Cc: Greg Kroah-Hartman
Cc: Helge Deller
Cc: James Hogan
Cc: Jiri Slaby
Cc: Kate Stewart
Cc: Max Filippov
Cc: Paul
The IA64 definition of termbits.h is identical to the generic.
Signed-off-by: H. Peter Anvin (Intel)
Cc: Tony Luck
Cc: Fenghua Yu
Cc: Kate Stewart
Cc: Philippe Ombredanne
Cc: Greg Kroah-Hartman
Cc: Thomas Gleixner
Cc:
Cc: Greg Kroah-Hartman
CC: Jiri Slaby
---
arch/ia64/include/uapi/asm
The IA64 definition of termbits.h is identical to the generic.
Signed-off-by: H. Peter Anvin (Intel)
Cc: Tony Luck
Cc: Fenghua Yu
Cc: Kate Stewart
Cc: Philippe Ombredanne
Cc: Greg Kroah-Hartman
Cc: Thomas Gleixner
Cc:
Cc: Greg Kroah-Hartman
CC: Jiri Slaby
---
arch/ia64/include/uapi/asm
The PARISC definition of termbits.h is almost identical to the generic
one, so use the generic one and only redefine a handful of constants.
Signed-off-by: H. Peter Anvin (Intel)
Cc: "James E.J. Bottomley"
Cc: Helge Deller
Cc: Kate Stewart
Cc: Thomas Gleixner
Cc: Philippe Ombr
1 - 100 of 12109 matches
Mail list logo