IRC channel logs
2024-01-14.log
back to list of logs
<damo22>some of the early console is set up at 9600 baud?? <damo22>and then it switches to 115200 ? <damo22>if i set the destination baud to 9600 i can read most of the early console except the bit i need <damo22>if i set it to 115200 it doesnt print anything <damo22>can we just hardcode the baud to 115200? <solid_black>what would y'all think about adding UEFI boot support to gnumach? <youpi>you still mean via grub, right? <youpi>I mean: it's not useful to implement the pieces which are already in grub <youpi>multiboot is a way to do that on legacy x86 <solid_black>yes, but it doesn't look like multiboot exists on arm? <solid_black>perhaps porting multiboot to arm would be a simpler way <youpi>possibly it's uefi, I just mean we don't need to implement more than the equivalent of multiboot <solid_black>as far as I can see, there are two ways Linux on arm can be entered, and it's either through uefi, or through a simple linux-specific boot protocol <youpi>does xen not define some multiboot protocol for its guest support? <youpi>we don't really need two ways :) <solid_black>I don't mean implementing lots of efi functionality, we'd only need to build gnumach into something that looks like a PE, and perhaps to fetch the initial modules via the EFI calls <solid_black>but 🤔️, maybe we don't need the two ways indeed, and if something does UEFI, we can throw GRUB at it <solid_black>unrelated: is there a reason why we don't use "libc ABIs" (as in glibc:libc-abis file, and EI_ABIVERSION)? <youpi>most probably because nobody had a look at it yet <Arsen>porting multiboot to arm and amd64 would be nice <Arsen>please do take that task up if you can <youpi>solid_black: I don't actually know the consequences <solid_black>hmm, I must have mixed something up, we do have the overall mechanism, and UNIQUE ABSOLUTE are there, but not IFUNC <solid_black>the trouble with booting via the linux boot protocol is the way initrd is passed <solid_black>namely, it's loaded into memory, and then the info is encoded into the deivce tree <solid_black>under chosen, via linux,initrd-start / linux,initrd-end <solid_black>which is cool, but that seems to only support a single initrd, and no argv for it <solid_black>looks like I can no longer reliably reproduce your pipe/echo/[ failure, I don't know why <solid_black>I've tried to see if I can reproduce it without kvm (and maybe record it with record-replay), and whther it reproduces on a simpler C program that does all the same pipe/fork/write/read/handle SIGCHLD/wait things <solid_black>haven't succeeded in reproducing in either case, but the original test doesn't seem to reproduce this anymore either <solid_black>so I'm at a bit of a loss for what to do about it next <gnu_srs1> Hi any ideas on how to do diff -ur /dev/null <directory>. Or do I have to got through all files manually "for filename in <directory>do ; diff -u /dev/null <directory>/fillename; done"? <youpi>diff -urN olddir <directory> <youpi>or else the question wasn't precise enough to understand what you actually wanted to do <azeem>I think he wants to have a diff which creates a new directory hiearachy <gnucode>nikolar: I'm about to send in the 2023 q3 qoth. <gnucode>if you go to hurd.gnu.org there's a new news article that I wrote. Samuel probably did some edits to it. <gnucode>Yeah, apparently Phoronix.com wrote an article about it. It really is helpful to put out that qoth. <gnucode>ok, I apparently installed netsurf-common last time. netsurf-gtk is soooo much faster! <gnucode>now I just need to port it so others can play with it. 