***Server sets mode: +nt
<damo22>living the dream at home.... two laptops, one for work and one for hurd hacking <jrtc27>surely the dream would be the hurd hacking and work being one and the same? :) <damo22>well yeah, but i doubt i would get paid as much <damo22>its kinda nice to have work and play separate <damo22>its less stressful and more fun to work at your own pace <damo22>dont make your hobby into a job, it loses its fun <jrtc27>as a phd student I disagree somewhat... :P <damo22>ok, but when it comes to write up time, you might have a different opinion <jrtc27>but yeah I take your point, it depends on the person <jrtc27>well, writing up isn't my hobby :) <jrtc27>but I can ignore that bit for a while still... <jrtc27>I do compiler and OS things for a RISC-V version of CHERI <jrtc27>(which is hardware memory capabilities, so bounded, unforgeable pointers with associated permissions, for both fine-grained memory protection and lightweight compartmentalisation) <jrtc27>yeah, and can also be used for microkernels with a single shared address space <jrtc27>there is a hardware-tracked validity bit that you cannot directly set <jrtc27>the only way to get capabilities with that bit set is to derive them from existing ones in ways that do not increase their bounds/permissions <damo22>so you only get access to memory you are supposed to have <jrtc27>makes use of tagged memory (1 bit per capability-sized word) <jrtc27>hence the use for compartmentalisation <jrtc27>it has been a thing I've thought about a bit in the back of my mind, but current hurd is very tied to mach and mach is very traditional unix <jrtc27>but maybe you could map the mach calls to more cheri-like things, idk <jrtc27>someone in the group did their own cherios microkernel from scratch <jrtc27>they got it serving cat pictures via nginx <damo22>youpi: does your latest commits mean DDE will soon be part of upstream hurd? <youpi>honestly I don't think DDE will be part of upstream hurd, since DDE is dormant <damo22>i need to figure out how to use that <youpi>I'd say most useful in the immediate future would be to get rumpdisk to be usable for the / fs <youpi>so we can get rid of the drivers in gnumach <youpi>we'll need that for the 64bit support <youpi>damo22: see Pellescours' messages <youpi>damo22: just realizing... any reason for using cthreads in rumpdisk? <damo22>oh, i just copied the previous version from dde <damo22>youpi: if disk controller is already attached to gnumach, you may get message with rumpdisk like: ahcisata: interrupting at pausebreak.... and the process hangs <damo22>i think it stuffs up the irq and you need to reboot <youpi>it may be useful to add a guard like in netdde's check_kernel.c <damo22>youpi: i noticed you havent touched hurd for 7 hours, should i rebase and keep working on that? ***rekado_ is now known as rekado
<youpi>damo22: that was sleep time indeed :) <youpi>I'm now on work time, so feel free! ***phillid is now known as uh
***Shentino_ is now known as Shentino
<damo22>wd0: drive supports 16-sector PIO transfers, LBA48 addressing <damo22>wd0: 298 GB, 620181 cyl, 16 head, 63 sec, 512 bytes/sect x 625142448 sectors <damo22>youpi: your refactoring is brilliant, i reduced rumpdisk to a little utility and no need for a second library ***slyfox_ is now known as slyfox