Stories
Slash Boxes
Comments

SoylentNews is people

posted by Fnord666 on Sunday June 06 2021, @05:51PM   Printer-friendly
from the 640k-is-more-memory-than-anyone-will-ever-need dept.

Linux x86/x86_64 Will Now Always Reserve The First 1MB Of RAM - Phoronix:

The Linux x86/x86_64 kernel code already had logic in place for reserving portions of the first 1MB of RAM to avoid the BIOS or kernel potentially clobbering that space among other reasons while now Linux 5.13 is doing away with that "wankery" and will just unconditionally always reserve the first 1MB of RAM.

[...] The motivation now for Linux 5.13 in getting that 1MB unconditional reservation in place for Linux x86/x86_64 stems from a bug report around an AMD Ryzen system being unbootable on Linux 5.13 since the change to consolidate their early memory reservations handling. Just unconditionally doing the first 1MB makes things much simpler to handle.

The change was sent in this morning as part of x86/urgent. "Do away with all the wankery of reserving X amount of memory in the first megabyte to prevent BIOS corrupting it and simply and unconditionally reserve the whole first megabyte."

no more wankery


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 1, Interesting) by Anonymous Coward on Tuesday June 08 2021, @01:38AM (1 child)

    by Anonymous Coward on Tuesday June 08 2021, @01:38AM (#1142989)

    Yes, there can be problems using a libc that the person didn't test against. Most people use glibc but usually stick to the standard, which means that problems don't happen even if they switch to another. However within the libc arena, you have behaviors that are not dictated by the specification and developers may expect the behavior they got in testing. There are also things that musl doesn't implement or does erroneously that can also cause problems. Additionally, there are things that glibc, the most common libc, does wrong but developers may also wrongly depend on that behavior without realizing it is technically a bug in glibc.

    There are ways around it. You can statically compile, using virtualization, using a compatibility layer, root separation or sandboxing, compiling it yourself, fixing the problematic code, and probably more that don't immediately come to mind. But not all of those are options in every situation; and not all are a solution in every situation, And others require extra work on top of using Alpine that can be fixed in the same or less work by not using Alpine in the first place as your distro.

    As I said, we'd love to love alpine, but having been "fooled" before we are not looking forward to being fooled again because then it is our fault.

    Starting Score:    0  points
    Moderation   +1  
       Interesting=1, Total=1
    Extra 'Interesting' Modifier   0  

    Total Score:   1  
  • (Score: 2) by RS3 on Wednesday June 09 2021, @02:43AM

    by RS3 (6367) on Wednesday June 09 2021, @02:43AM (#1143402)

    Thank you so much. Very interesting perspective. It's interesting that you feel "fooled". I've found Alpine to be so good, stable, fast, efficient, that for me, it's the standard of excellence. But I understand what you mean. It's certainly a learning (eye-opening) experience.

    Again, I have not tried to run any apps outside of what you can get from Alpine.

    But I've had your problem with many applications for many distros, and I'm trying to think about what I've done with other distros. I think I usually get the distro-specific apps. If I need something that isn't available for the OS platform, I've probably gotten source and compiled. But that doesn't always work, and although I've done some SW development, I usually don't have the patience to figure it out and fix it. All depends on what the bug is, of course.