IRC channel logs


back to list of logs

***Server sets mode: +nt
<janneke>can't seem to recover my fs from: panic: ext2_free_blocks: freeing blocks in system zones
<janneke>linux and e2fsck seem to think the fs is fine
<youpi>use -f in e2fsck
***gianluca is now known as Guest37462
<damo22>youpi: for trivfs_S_i386_io_perm_create() , do i create a port in the trivfs_protid_class and call i386_io_perm_create() with a new send right as device master?
<damo22>im confused how i can get the "next superior" device master port from inside a S_ calll
<damo22>isnt the next superior master device in libmachdev trivfs, just a port in that bucket?
<youpi>damo22: you just need to use the device priv port from the glibc, call i386_io_perm_create on it, and hand over the returned more with MOVE_SEND
<damo22>im a bit confused because this seems like a kernel api it doesnt have a return msgtype
<damo22>The _S.h stub looks like:
<damo22>kern_return_t S_i386_io_perm_create
<damo22> mach_port_t master_port,
<damo22> io_port_t from,
<damo22> io_port_t to,
<damo22> mach_port_t *io_perm
***rekado_ is now known as rekado
<youpi>damo22: ah, that's because it's a mere out port, not an out poly
<youpi>(i.e. I guess by default COPY_SEND)
<damo22> U S_i386_io_perm_modify
<damo22>how do i resolve those missing symbols? do i define them in the code as EOPNOTSUPP?
<youpi>you can yes
<damo22>ok it compiled but not sure if it worked i just called "return i386_io_perm_create (_hurd_device_master, from, to, ioperm);"
<almuhs>hi. Are there any paper about Hurd (or Mach), which explain any advantage of Hurd (or simply, microkernel architecture) over other systems and architectures?