***Server sets mode: +nt
<damo22>youpi: it seems that device_open is called 5 times <damo22>it obviously wont work because i hold a lock on the first open <youpi>opening a disk concurrently has to be supported by device drivers, yes <youpi>no, you just don't reopen it <damo22>so if its been opened before, i can use the old fd <damo22>maybe that is the only thing wrong with my driver <damo22>can you assign a copy of a whole struct with one = ? <damo22>or do you have to set the members individually? <youpi>yes, struct assignment works <youpi>only array assignment doesn't <damo22>static struct block_data block = { .opened = false }; <youpi>you can also directly use *bd = {.opened = false}; <youpi>or perhpas you need to use *bd = (struct block_data) {.opened = false } <damo22>ok yea, but i need to mutate it because it needs to build up its state <youpi>I'm surprised that you are making a copy then <damo22>i am keeping the state in a static global <damo22>but device needs to pass it around <youpi>but doesn't it need to be coherent between copies? <youpi>i.e. pass around a pointer to the global struct rather than a copy <youpi>you can re-return the same as before <youpi>see what the in-gnumach linux driver and xen driver do <damo22>maybe i can just use the global directly with a pointer to it <damo22>device_get_status returned EIEIO <damo22>or the translator died after that function ran <damo22>theres DEV_GET_SIZE and DEV_GET_RECORDS for flavor, and i am setting 2x status[] for each <damo22>is DEV_GET_RECORDS_RECORD_SIZE supposed to be the same value as DEV_GET_SIZE_RECORD_SIZE ? <damo22>and then the DEVICE_SIZE is the media total size and DEVICE_RECORDS is the media total size / 512 ? <damo22>hmm device_open succeeded, then device_get_status ran, then: <damo22>ext2fs: /dev/wd0s2: panic: main: device too small for superblock (0 bytes) <damo22>oh no thats because i set active translator and it didnt work <damo22>it just says can't open /dev/wd0s2 EIEIO <damo22>i dont understand why it tries to call rump_sys_open again when ALL GOOD means it just set the bool opened <damo22>could there be a race condition? <damo22>i copied a lot of code from there <damo22>rumpdisk tried to call backtrace <damo22>create_device_port (sizeof (*bd), &bd); <--- is this right? <damo22>why am i creating a device port that is the address of the pointer to the block_data object? <damo22>shouldn't it be create_device_port (sizeof (bd->port), &bd->port); <youpi>damo22: it right, yes, you don't want to create only a port, but a port related to a structure <youpi>note that the struct *has* to start with the port field <youpi>so that the port information is indeed put at the right location <damo22>but when i call ports_port_deref (bd); wont it set bd to NULL ? <damo22>so i cant use the pointer again after that <youpi>ports_port_deref can't set bd to null <damo22>i can dump first sector easily with rump but im having a lot of difficulty making rumpdisk work <damo22>rumpdisk dies after device_get_status <damo22>what am i supposed to do in the case where its already open? just return D_SUCCESS? <damo22>now it goes in a loop forever opening the device <damo22>do i need to deref the port every reopen? <youpi>return sucess, but also fill the port parameter with the existing port <youpi>again, see the existing drivers inside gnumach <youpi>the linux disk glue and the xen block driver <gnu_srs1>youpi: In which order should I upgrade hurd/glibc. I tried to install both on a system with record locking installed but failed. (Had to manually install the packages within Linux) <youpi>normally either way should just work fine <youpi>do you mean you *already* had your hurd & glibc packages for record locking installed? <gnu_srs1>Yes, and the record-locking RPC was at the wrong place. <youpi>so it's not surprising: your package didn't implement the fallback <youpi>you would then need to upgrade libc first <youpi>so as to get something that includes the fallback <youpi>and you can reboot to benefit from the support <youpi>Mmm, that said perhaps the new libc would get an error which is not invalid mig ID, but incoherent message size <youpi>and thus the fallback wouldn't work <youpi>and there is not much to be done about it <youpi>that's why fallback code is important and thinking about compatibility between versions is important <gnu_srs1>So I have to take down all my images without fallback code and install the new code using Linux then. <youpi>you can first downgrade libc and hurd, reboot, and then upgrade again, yes <youpi>(but even downgrading libc&hurd might have compatibilty issues since your patches didn't care at all about that) <gnu_srs1>I'm glad I don't run Hurd on real hardware ;) ***Glider_IRC__ is now known as Glider_IRC