<wleslie>how does one configure the keyboard in guix-hurd? ***Server sets mode: +nt
<youpi>wleslie: I guess you mean the image mentioned previously. It's a debian-based actually, so use dpkg-reconfigure keyboard-configuration and reboot <wleslie>oh, I should have picked that up, thanks! <wleslie>hmm, even after reboot my hurd console is still querty <youpi>which layout did you ask for? <wleslie>I'm going to see if I can interactively start a hurd console with dvorak layout (might be I need the xkb driver) and if so adjust /etc/defaults/hurd-console <youpi>Mmm, perhaps the "variant" parameter is not supported by the hurd console xkb driver <damo22>youpi: im guessing these three lines must be on the first grub "module" regardless of what it is: <damo22> --multiboot-command-line='\${kernel-command-line}' \\ <damo22> --host-priv-port='\${host-port}' \\ <damo22> --device-master-port='\${device-port}' \\ <youpi>they must be given to whatever module needs them <youpi>the kernel command line is for the / filesystem, which gives it to the startup translator <youpi>the priv-port is needed for ext2fs to know what being "root" means for the kernel <youpi>the device-port is needed for ext2fs too to know what having access to the hardware means for the kernel <youpi>the last two are needed because it's the / translator that hands them to the root-owned processes <youpi>the first is because it just happens that it's also the / translator that hands it to the startup <damo22>im guessing for ext2fs, device port is no longer needed, but it needs a rump device instead <youpi>actually possibly it needs both <youpi>because there's the port it uses for its own device_open <youpi>and there's the port it hands to root-owned processes <youpi>we could just use the rumpdisk device port for both <youpi>and make rumpdisk forward the device_open() calls to the kernel's device port when it gets ENODEV from its drivers <youpi>otherwise I'm not sure how we'll easily make /dev/hd0 entries get to open rumpdisk devices <youpi>since we'd have to somehow designate "use the master device of that module that got loaded from grub" <youpi>it's simpler to just make all processes use the rumpdisk device port <damo22>part:2:device:@/dev/rump:/dev/wd0 <youpi>yes, but how do you make /dev/rump magically designate the port of the rumpdisk module? <damo22>dont you pass root= to gnumach and the grub driver mounts the disk to get the kernel out <youpi>I'm here talking about userland translators <youpi>they'd try to open /dev/rump <damo22>oh right, how do you attach rumpdisk to /dev/rump without settrans <youpi>and for the / translator, using @/dev/rump won't work actually, since there's no filesystem yet, that's why we use device: designation, which makes libstore use the device port to open the device <damo22>yeah theres no way to open the device port with rumpdisk <youpi>thus getting it from device-master-port <youpi>which used to be used only for mach-provided devices <youpi>but it makes sense to use it also for other things that don't appear in the FS <youpi>all that being said, yes it would make sense to use an initrd approach, with an initial pseudo filesystem in which the ports of the modules would appear, and then somehow attach them to the real / filesystem <youpi>but I'd say that's for later work, in the meanwhile making rumpdisk forward open_device() requests to gnumach is simple <damo22>ok i think i get it, but im not sure <youpi>don't hesitate to ask questions :) <damo22>rumpdisk will be changed to forward open_device requests to gnumach, what will gnumach do with a open_device request? <damo22>but we dont want to use gnumach disk drivers <youpi>but there are other drivers than just disks <youpi>and the device master port is also used for them <youpi>so we have to keep that working <youpi>interestingly, this approach does work with subhurds too <damo22>so we call into gnumach to get a device master port <youpi>if you give access to a PCI card to a subhurd, you can run a rumpdisk there, and let an ext2fs access it as usual <youpi>rumpdisk just needs to be passed it over <youpi>it's the ${device-port} variable <youpi>actually it'll have to hvae it to be able to enable I/O access <youpi>so you'd have to pass it to pci-arbiter so it can access PCI <youpi>and pass it as well to rumpdisk so it can forward device_open requests <youpi>and to ext2fs, instead of passing it ${device-port}, pass it the master port of rumpdisk <damo22>why do we need to forward device_open requests <damo22>we'll talk tomorrow i have to sleep now <youpi>which will call device_open() on the master device port it got from ext2fs <youpi>if we make that port the rumpdisk port only, the mem device name won't be found <youpi>so in libmachdev's ds_device_open, after drivers failing to open the device, call device_open() on the master device port of the kernel <youpi>and there the mem driver will succeed ***rekado_ is now known as rekado
<civodul>there's actual work to support GNU/Hurd in Guix <almuhs>but not as a replacement for linux <civodul>as for deprecating Linux-libre, it's probably not going to happen anytime soon :-) <civodul>but some of us would like to make it a viable option <almuhs>Guix Hurd can be an interesting port <almuhs>now I'm busy, but I want to continue my SMP work, in a better way ***alone is now known as ghost_wander
<gnu_srs1>youpi: Any ideas? KVM: entry failed, hardware error 0x80000021, latest hurd and gnumach from git! <gnu_srs1>The git versions being OK are from git log: gnumach: Tue Jan 28, hurd: Sat Feb 15. nOK ones: gnumach: Tue Mar 31 hurd: Mon Mar 30 <gnu_srs1>Any ideas how to bisect? Can I check out gnumach and hurd versions from a specific date? <almuhs>gnu_srs1: I remember that It's not recommended compile hurd from upstream <almuhs>because this lacks of many things added in Debian patches <gnu_srs1>almuhs: FYI: Compiling from upstream worked until the latest upstream commits. <almuhs>gnu_srs1: hurd upstream with mach upstream? <youpi>but for a start, try latest gnumach with known-to-work hurd, and vice-versa <youpi>to determine which one needs to be bisected <gnu_srs1>can I git checkout or git clone from a specific version/date/tag etc? <youpi>you can specify a commit yes