IRC channel logs
2022-09-12.log
back to list of logs
<zamfofex>I’ve actually been working on establishing a substitute server for Guix on GNU/Hurd! In fact, I found that a problem I was running into seems to be related to a bug in the Hurd. When I set my VM’s disc to 1TiB, the ext2fs translator failed with an error at some point. When I set the disc to a more moderate size, it seemed to work fine. <zamfofex>Ah, fair enough! If possible, I think there should be some kind of error or warning or early error, then. It’s not immediately obvious, I feel. <zamfofex>Is exactly 128 GiB known good, or would it be better to choose a slightly lower quantity to be safe? <youpi>though it's be better to actually test that sector 2^28-1 can indeed be properly accessed <youpi>also, that's only for IDE disks. For SATA we're only limited by the 32bit device interfac <youpi>again, testing wither 2^32-1 can be accessed would be good <youpi>and then it can be added in libstore to check that the extend of the partition is within what the device interface can support <biblio>luckyluke: I tied by setting MIGUSER. But no luck. Also, I could not find these files in other branches as well "/gnumach64-multiboot-files/test1/" <biblio>luckyluke: if you have time could you please check if it is possible to compile and run test from your gitlab repo's WIP. Maybe, some files are missing for tests. <zamfofex>I’ve been reading about Mach lately. How much Mig code is on the Hurd, and how incorporated is it into the servers? I was thinking maybe it could make sense to come up with a new IDL/RPC language and implementation from scratch to replace Mig, since I’ve read it has limitations, and it seems a bit awkward currently. <damo22>zamfofex: that sounds like a lot of work for not much gain <zamfofex>I guess so. It’s just that, at least from what I’ve seen, MIG’s code seems to be unideal, and it also holds back some work such as the x86‐64 port, besides general design issues, such as it not allowing certain compound types to be representable. <zamfofex>Is that a sensible thought, or have I misunderstood something? From what I’ve seen, Apple moved on from MIG, so maybe it’d make sense for GNU to do the same. Since most code is not written for MIG (as it only provides definitions), I feel like it oughtn’t to be too hard to port it to a different language. <damo22>i havent had any trouble with it and im writing new rpcs <zamfofex>I see. Maybe it isn’t so bad, I guess. I suppose people’s notes on the docs made it seem worse than it actually is, and all there is to it is a bit of improvement to be made here and there. <zamfofex>Also: I don’t fully understand the issue holding back x86‐64. It seems to be mostly a matter of coming to a decision by this point, is that right? <damo22>machdev was merged, now i can move ahead with acpi <damo22>youpi: can a process linked to a lib make an RPC to itself from within the lib? <damo22>im trying to figure out how to make libirqhelp call an acpi RPC, but i want to link libirqhelp to acpi translator itself <damo22>or do i do a special case when the library is linked to acpi translator and just call an internal function instead <youpi>damo22: a process can perform an RPC to itself, yes, but only if it's using the multithreaded libports dispatcher <damo22>youpi: i have written libirqhelp, but i fear its going to introduce dependencies that we might not want: libacpica needs to register a handler, so it will be linked to libirqhelp. i have made it not use pciaccess or acpi translator because it already knows the GSI in acpica <damo22>but for all other translators we link libirqhelp to, it will depend on pciaccess and acpi translator <youpi>you can make libirqhelp check whether it's running inside the acpi translator or not <damo22>yes i could do that, but instead i wrote an api that does not require looking up itself for the GSI when it already knows it <damo22>ie, if you pass in a non-negative gsi, it just uses that instead of doing an RPC to find out from acpi <damo22>since the acpica code already knows the gsi at the point it wants to register a handler <damo22>irqhelp_install_interrupt_handler(-1, bus, dev, fun, ...) will look up the gsi from acpi translator <damo22>irqhelp_install_interrupt_handler(gsi, -1, -1, -1 ...) will just use the gsi given (and ignore pci commands) <damo22>startup: notifying acpi of halt...done <damo22>is that because acpi translator got killed? <damo22>how do i keep it around even after startup tells it to die <damo22>or should i mail in these patches first <damo22>i think we have that issue where two pci-arbiters are still needed, and two acpis <damo22>because of that TODO you wrote in the arbiter's main <damo22>i have it booting with acpi bootstrap translator <damo22>ls: cannot access '/servers/acpi': Translator died <youpi>I don't remember how to make acpi survive <damo22>i set the acpi.static translator on /servers/acpi and shutdown worked <youpi>but I'm surprised actually, since as of now in the debian packages, that does work <youpi>so there's probably something there that keeps it <youpi>and for some reason with your chagnes that' doesn't work any more <damo22>i think i forgot to recompile shutdown translator <damo22>/hurd/acpi: symbol lookup error: /hurd/acpi: undefined symbol: machdev_trivfs_server_loop <damo22>it works with the acpi.static binary but not the dynamic one <damo22>ahh i havent installed libmachdev.so <iska>has anyone tested audio on the main branch? <iska>I've tried mounting nfs on a Hurd Debian host, it hangs when doing any operation <iska>searched the logs and mailing lists, I think I'm the first one to find this issue <youpi>extremely few people use nfs on the hurd, so I'm really not surprised <iska>here's the configuration I use: <iska> ("/homeb/nguixb/iskam/.local/src" <iska> "*(ro,insecure,no_subtree_check,crossmnt,fsid=0)")))))) <iska>reproducing shouldn't be hard <youpi>reproducing is not the question, but taking the time to work on it :) <iska>without insecure translator dies, but Linux mounts it fine in both cases...