IRC channel logs


back to list of logs

***Server sets mode: +nt
<damo22>youpi: it seems that device_open is called 5 times
<damo22>when i try to mount a disk
<damo22>it obviously wont work because i hold a lock on the first open
<damo22>so i get EIEIO
<youpi>opening a disk concurrently has to be supported by device drivers, yes
<damo22>how should i handle the fd?
<damo22>do i clobber the old fd?
<youpi>no, you just don't reopen it
<youpi>you keep a count
<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>struct block_data *bd;
<damo22>static struct block_data block = { .opened = false };
<damo22>*bd = block;
<youpi>that will work yes
<youpi>you can event make it const
<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
<youpi>if there is state in it
<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
<damo22>device open creates the pointer
<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>ok i wont make copies
<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>both = 512
<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>ok im getting somewhere
<damo22>device_open ALL GOOD!
<damo22>rump_sys_open failure
<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>hmm is libmachdev even used?
<damo22>looks like theres a bug in it
<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
<youpi>if you pass bd and not &bd
<damo22>haha true
<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>I had tested them both
<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>then reboot
<youpi>ah no, not even reboot
<youpi>then upgrade hurd
<youpi>and you can reboot to benefit from the support
<gnu_srs1>OK, thanks :)
<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