<junlingm>If a device is opened by a program, and then the program died without closing the device, it seems that the device remains open, am I right? ***Server sets mode: +nt
<youpi>although it seems by design that device_open/close calls increment/decrement the open count <youpi>I don't know the rationale for this <junlingm>I think it is a simply refcount, so that the underlying device does not have to worry about being opened twice. <junlingm>I am not sure which port to monitor though. Is it the one that is used to open the device? <youpi>I'd rather say to monitor the port returned by device_open <youpi>yes, sure the rationale for the refcount itself makes sense <youpi>but I don't see why one would use device_close instead of just closing the port and letting mach notice that <youpi>or possibly they didn't have port death notification, and thus introducing a device_close was a lazy way to get things working <junlingm>ok, I will monitor that returned port and see how it works. Thanks! <jrtc27>youpi: re (s)brk, it's a shame you can't enter the brk-free future like FreeBSD/arm64 and FreeBSD/riscv <jrtc27>brk is a complete stupid historical PITA <youpi>the hurd itself is actually completely brk-free <youpi>it's completely implemented within libc <youpi>it just so happens that some applications use it instead of malloc so we have to provide it <jrtc27>yes I mean don't even bother implementing it <jrtc27>FreeBSD doesn't on Arm64 or RISC-V <jrtc27>you're stuck now because of binary compatibility <jrtc27>but it's nice to not have that wart of an interface still around :) ***jma is now known as junlingm
<damo22>rumpdisk booting off / boots on native x200 laptop <damo22>youpi: when i install the machdev_ctl port as a translator on /dev/rumpdisk it looks like it mounts / on /dev/rumpdisk <damo22> part:2:device:/dev/wd0 / ext2fs writable,store-type=typed 0 0 <damo22> part:2:device:/dev/wd0 /dev/rumpdisk ext2fs writable,store-type=typed 0 0 <damo22>and i cant use it as a translator to mount another partition <damo22>jlledom[m]: hi, i think i have rumpdisk working without the pci-arbiter, do you know how we can make pci devices available through the arbiter without a root file system? <damo22>i think i need to compile pci-arbiter.static and launch it as a bootstrap task <damo22>but it usually exposes its device nodes on /servers/bus/pci <damo22>before the root filesystem is available, there is no /servers/... <damo22>its going to need to be redesigned (again) i think lol <youpi>damo22: how did you try to use rumpdisk as a translator? you need to open it as a master device, with the @ notation that was introduced lately <damo22>-T typed part:3:device:@/dev/rumpdisk:/dev/wd0 <youpi>damo22: exposing pci-arbiter will be the same <youpi>I'm not sure it's the ctl port that should be put on /dev/rumpdisk though <youpi>(since it did something and didn't crash it seems to be okay, just want to make sure) <youpi>err, machdev_ctl, what is it actually? <youpi>is that what you got from fsys_startup? <youpi>that's the ctl port of ext2fs <youpi>what you want is a control port of the machdev-based translator itself <youpi>the ctl port from ext2fs is only to be set for CRDIR and CWDIR <youpi>what you want to set on /dev/rumpdisk is a port from the trivfs_cntl_class class <youpi>see what other translators are doing when using file_set_translator, they create a port of their control class <damo22>lol i installed the ext2fs ctl port onto the /dev/rumpdisk, which was equivalent of mounting / on /dev/rumpdisk <jrtc27>but there is another real reason why I'm anti-sbrk <jrtc27>(you _could_ make it work but software would need significant changes to do so, and at that point you might as well sanitise it and use mmap) <jrtc27>heck glibc says "Avoid using brk() and sbrk()" <jrtc27>and it was removed in POSIX.1-2001 <youpi>sure but a lot has been removed from posix and there is still software using it