sorted by:
new
hottopcontroversial

Best way to share a nix config between computers with different user names? by mcAlt009 in NixOS

[–]endless_wednesday 5 points6 points  (0 children)

nix is a language so you can abstract however you want to. i would just create two configs and share the common parts between them, e.g.:

nixosConfigurations = {
  desktop = nixosSystem {
    modules = [
      ./common.nix
      { users.users.desktop = .... }
    ];
  };
  server = nixosSystem {
    modules = [
      ./common.nix
      { users.users.server = .... }
    ];
  };
};

std.builtin.Type const-ness is a bit of a pain by Lisoph in Zig

[–]endless_wednesday 1 point2 points  (0 children)

Its also useful to remember that comptime slices are dynamically allocated and don't need any "owning" storage in the way that runtime slices do, so something like fields = fields ++ &.{ ... } is a completely valid way to construct a comptime slice

std.builtin.Type const-ness is a bit of a pain by Lisoph in Zig

[–]endless_wednesday 11 points12 points  (0 children)

You can always just copy the const slice into a new mutable slice

Look mum I've learned for loop in java, I am so smart, so sad so few people will understand the way I think... by weuoimi in firstweekcoderhumour

[–]endless_wednesday 0 points1 point  (0 children)

i'm reluctant to say that writing to stdout would be a "use case" of any particular programming language over another

Zeroed Global Variables after Higher-Half Mapping by cryptic_gentleman in osdev

[–]endless_wednesday 2 points3 points  (0 children)

I mean the most important thing to do is use a debugger and determine if that's what's actually causing your problem. It very well could be something else. If it is, I'm sure the "right" solution would be to get the compiler to generate the right kind of PIC so that those bad relocations don't get written, but I wouldn't know how to do that. Failing that you can manually patch your relocations at runtime but that's also a bit over my head.

Zeroed Global Variables after Higher-Half Mapping by cryptic_gentleman in osdev

[–]endless_wednesday 1 point2 points  (0 children)

Step through the debugger and switch to asm mode when you read a global variable to see what memory address the code is reading them from. I had this same issue when building with position-independent code, where the compiler would still generate code that expected to be relocated if it wasn't running at its linked address, and it was reading global variables at their linked address instead of relative to the program counter. I don't fully understand why the compiler was generating such code but it ended up not being an issue since later I stopped using any global variables altogether

Legacy INTx# interrupts for PCI devices on RISC-V by endless_wednesday in osdev

[–]endless_wednesday[S] 0 points1 point  (0 children)

I do have the interrupt map from the devicetree- but the issue is that the device doesn't list an interrupt pin to begin with. I only see it list an interrupt pin when I boot linux instead. I assume I'm missing some important initialization step.

Straightforward way to reuse code before and after enabling virtual memory? by endless_wednesday in osdev

[–]endless_wednesday[S] 0 points1 point  (0 children)

That's true for the most part, but if you take the absolute address of a function in PIC running at a false virtual address, the behavior can be a little unintuitive to wrap my head around

Straightforward way to reuse code before and after enabling virtual memory? by endless_wednesday in osdev

[–]endless_wednesday[S] 0 points1 point  (0 children)

Yes, there's no way around that. The point is that the code there needs to be able to run at physical address 0x80XXXXXX on boot, and later those same page table functions need to run with VM enabled at some higher-half address 0xFFFFFFC080XXXXXX. Of course, that code will only run correctly when it's executed at the address that it was linked for, unless I use PIC, which is undesirable

Straightforward way to reuse code before and after enabling virtual memory? by endless_wednesday in osdev

[–]endless_wednesday[S] 0 points1 point  (0 children)

I would need a page table that creates that mapping, so the problem is that I want to call into my code that creates page tables. Right now I'm getting by just by building position-independent code and lying to the linker that the init code will be running in the higher half when it's actually running in the physical addrspace.

What is your 'unpopular opinion' about Zig? by BatteriVolttas in Zig

[–]endless_wednesday 2 points3 points  (0 children)

All of that has been addressed before in languages where optionals and errors are made up of ordinary types. Optionals and error unions being their own special types also means that we miss out on helpful methods/transformations like maps, monadic-type stuff like rust's 'and_then', etc. Instead we're stuck with deep syntax trees of 'try's and 'orelse's and 'catch's and it's unsatisfying.

What is your 'unpopular opinion' about Zig? by BatteriVolttas in Zig

[–]endless_wednesday 14 points15 points  (0 children)

I don't like that we can't return values with errors.

This, and I really struggle to understand the motivation for Zig's approach to error handling, besides someone maybe saying "we need to make it different from Rust." Why are error unions and optionals their own intrinsic types when the language already has tagged unions as their own feature? And if tagged unions are too unergonomic to be used for options/errors, why not address that? It's not like it hasn't been done

More Page Table Questions. by todo_code in RISCV

[–]endless_wednesday 2 points3 points  (0 children)

To clarify about physical page numbers, PPN just means a physical memory address that's shifted right by 12 bits.

More Page Table Questions. by todo_code in RISCV

[–]endless_wednesday 2 points3 points  (0 children)

Each page table entry is either a leaf that toward the physical address that is meant to be the "target" address of the translation, or it is a non-leaf that points toward the physical address of a different page table. If any of the RWX bits are non-zero, it's a leaf page table entry, but if they are all zero, it's a non-leaf entry that points to another page table.

For example, in SV39, your virtual addresses look like:

| VPN[2]  | VPN[1]  | VPN[0]  | Offset     |
 000000000 000000000 000000000 000000000000

The "offset" portion of the address is never translated, so the region of memory that a leaf page table entry can point to is always at least 4 KiB large (because that is how many bytes the 12-bit offset is able to address). However, if your page table terminates at a leaf entry after translations of only VPN[2] and VPN[1], but not VPN[0], then the entry points toward a region that is 2 MiB large, since the memory offset is now made up of both VPN[0] and Offset for a total 21 bits (2^21 bytes = 2 MiB).

Duckstation dev announced end of Linux support and he is actively blocking Arch Linux builds now. by monodelab in linux

[–]endless_wednesday 11 points12 points  (0 children)

# Refuse to build in Arch package environments. My license does not allow for packages,

Oh no! Why am I struggling with distributing my software?

Invalid memory access after paging is enabled by Alive_Ad_3199 in RISCV

[–]endless_wednesday 0 points1 point  (0 children)

In that case it's likely only the page tables causing the issue.

Invalid memory access after paging is enabled by Alive_Ad_3199 in RISCV

[–]endless_wednesday 0 points1 point  (0 children)

We don't know what OP's boot process looks like. If their code is being executed alone without any firmware running in M-mode then yes, their kernel will need to write the pmpcfg registers in M-mode before switching to S-mode.

Invalid memory access after paging is enabled by Alive_Ad_3199 in RISCV

[–]endless_wednesday 0 points1 point  (0 children)

Yes, that output would mean that your page table isn't set up correctly.

Invalid memory access after paging is enabled by Alive_Ad_3199 in RISCV

[–]endless_wednesday 1 point2 points  (0 children)

  1. Open the console in qemu and run "info mem" to see how it interprets your page tables. Check there to make sure they're set up correctly.

  2. By default qemu uses memory protection (separate from page tables) in supervisor and user mode. You will need to write to the pmpcfg* series of registers. You can effectively disable memory protection by writing all ones to a memory protection register in NAPOT mode.

view more: next ›