IRC channel logs


back to list of logs

***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
<jrtc27>in your dream world you can
<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...
<damo22>what is your phd on
<jrtc27>this project
<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)
<damo22>sounds complex and secure
<jrtc27>yeah, and can also be used for microkernels with a single shared address space
<damo22>what is an unforgeable pointer?
<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>oh thats cool
<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
<damo22>very interesting
<damo22>cheri-hurd :P
<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>sorry gtg back to work
<jrtc27>:) cya
<damo22>youpi: does your latest commits mean DDE will soon be part of upstream hurd?
<damo22>and rump :)
<youpi>libmachdev only for now
<youpi>honestly I don't think DDE will be part of upstream hurd, since DDE is dormant
<youpi>better focus on rump
<damo22>ah ok
<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
<damo22>someone was working on 64 bit?
<youpi>damo22: see Pellescours' messages
<youpi>damo22: just realizing... any reason for using cthreads in rumpdisk?
<youpi>cthreads are not maintained
<damo22>oh, i just copied the previous version from dde
<damo22>from incubator libmachdev
<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!
<damo22>ok nice
***phillid is now known as uh
***Shentino_ is now known as Shentino
<damo22>wd0: <QEMU HARDDISK>
<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
<damo22>jlledom[m]: before i submit this patch upstream, do you agree with it?
***slyfox_ is now known as slyfox