***Server sets mode: +nt
<youpi>gnu_srs2: that should "just work" because we just use PKG_CHECK_MODULES calls <youpi>if not, be more specific with actual error messages <damo22>youpi: somehow, in linux drivers, when you dont mask/unmask the irqs it fails to trigger the irq at the right time, is there a dummy function i can use in place of the masking that will allow the interrupt to trigger? <damo22>can i just call sti for an unmasking op? <damo22>or can i create a function that masks all irqs and then unmasks them immediately and call it before sending the ahci command? <youpi>damo22: I don't understand what you are looking for. ahci already calls sleep_on. That calls __sleep_on which calls sti(), that will enable interrupts exactly at the right time <youpi>i.e. *after* calling add_wait_queue() <damo22>im wondering if the PIC misses some interrupts if its masks are cleared all the time <youpi>" all the time" would be too much indeed, but provided that sti() is called at least sometimes, that's way enough <damo22>i mean the mask bits not the global flag <youpi>? didn't you get rid of the mask? <damo22>the linux kernel, for example, has special way of sending EOI that sets the mask bits first <youpi>that can probably be get ridden of <youpi>ok but that doesn't mean that it's what we have to use <damo22> * Careful! The 8259A is a fragile beast, it pretty <damo22> * much _has_ to be done exactly like this (mask it <damo22> * first, _then_ send the EOI, and the order of EOI <damo22> * to the two 8259s is important! <damo22>but they are doing eoi for specific interrupts <damo22>but i wonder if we should be masking all of them <damo22>yes i removed the support for masking individual bits, but since then, i can't seem to boot with AHCI <damo22>i am trying something, toggling the masks before sending EOI and unmasking them straight after <damo22>it must be that the pic needs to be cleared so that it doesnt miss any interrupts <damo22>rumpdisk must have a bug because i have got to the point where i can reliably read sector 0 of my HDD from rump <damo22>youpi: when does (*init) get called during device setup <damo22>rumpdisk seems to fail because my init function is not being called before the disk tries to open <damo22>or do i call it explicitly in the device_open <damo22>dang having issues with initrd ext2fs not saving the files when i umount and gzip it <damo22>i have to copy them twice for some reason <damo22>ok the problem is its not linking to the right shared libraries because there dont seem to be any symbols in there that it needs explicitly <damo22>gcc -shared -Wl,-soname=libmachdevrump.so.0.3 -o libmachdevrump.so.0.3 \ <damo22> -L. -L../libps/ -L../libtrivfs/ -L../libihash/ -L../libports/ -L../libbpf/ -L../libcons/ -L../libiohelp/ -L../libdiskfs/ -L../libshouldbeinlibc/ -L../libhurd-slab/ -L../libnetfs/ -L../libftpconn/ -L../libpipe/ -L../libpager/ -L../libhurdbugaddr/ -L../libstore/ -L../libfshelp/ -L../libthreads/ -std=gnu99 -fgnu89-inline -Wall -g -O3 -fno-strict-aliasing -g -O2 \ <damo22> '-Wl,-(' deviceUser_pic.o machUser_pic.o ds_routines_pic.o trivfs_server_pic.o device_replyUser_pic.o deviceServer_pic.o notifyServer_pic.o block_pic.o ../libports/libports.so ../libtrivfs/libtrivfs.so \ <damo22> -lpthread -lrump -lrumpdev -lrumpdev_disk -lrumpdev_pci -lrumpvfs -lrumpdev_scsipi -lrumpdev_ahcisata \ <damo22>how do i force the rump libs to link?' <damo22>it uses DL to load them at runtime but if the symbols are not present it wont even try <gnu_srs2>Direct commands to the linker -Wl,-z,<command> <gnu_srs2>When building Debian packages (usually):<command>=relro, now <damo22>gnu_srs2: actually i want to statically compile some rump libs into a dynamic lib <damo22>so it doesnt need to look for the symbols <damo22>but i dont know where they should live on the system <damo22>ie, i dont want to put hardcoded paths to the libs <damo22>eg -lrumpdev_pci should find librumpdev_pci_pic.a <damo22>and compile it in regardless if the symbols are found or not <damo22>LDLIBS += -L/usr/lib -Wl,--whole-archive -lrump -lrumpdev -lrumpdev_disk -lrumpdev_pci -lrumpvfs -lrumpdev_scsipi -lrumpdev_ahcisata -Wl,--no-whole-archive <damo22>do i need to put the path to the .a in full? <gnu_srs2>Sorry dunno :( From gcc -Wl,-whole-archive, -Wl,-no-whole-archive <damo22>ok linked, but there were duplicate symbols in scsipi <damo22>is there a way to use whole-archive but discard dups? <gnu_srs2>whole-archive can be used more than once <youpi>damo22: you possibly need to sync between umount and gzip, because there is perhaps no synchronization between the page cache and the buffer cache <youpi>damo22: I don't know how init functions get called in rump, possibly through link magics like linux' initcalls <youpi>damo22: you can use -Wl,--no-as-needed <youpi>gnu_srs2: whole-archive only makes sure to try linking in a loop. that won't include objects if nobody references them <gnu_srs2>youpi: Thanks I was searching for as-needed but did not remember the exact name ;) <youpi>man pages are there for finding the exact name ): <gnu_srs2>I was looking in the man page, but was distracted by something else. You beat me to it. <gnu_srs2>youpi: Regarding cross-compiling hurd: Setting PKG_CONFIG=/tools/bin/pkg-config does not work, that is a cross-built binary that is not executable from the build system. Not setting that finds the build version of pkg-config, and there the required *.pc files are not found. <damo22>whole-archive works better than no-as-needed <youpi>gnu_srs2: well, yes, you're supposed to use i686-gnu-pkg-config <youpi>(or whatever triplet you used in your toolchain) <youpi>but ./configure shouldb e automatically using that when you use a cross-compiler <youpi>then that's what configure should be using <damo22>haha i forgot to link to pciaccess <gnu_srs2>on the build system I have: x86_64-linux-gnu-pkg-config and x86_64-pc-linux-gnu-pkg-config <damo22>i can get it to fire irqs now but it wont quite mount the disk <damo22>i get a lot of task /hurd/rumpdisk(2208) deallocating a bogus port 91, most probably a bug <damo22>and then it hangs on the final mount command <damo22>i dont think its the console log slowing it down <damo22>ive seen it spew console and still monut <damo22>maybe block.c is calling the init twice? <damo22>now that i have it linking correctly i can try removing the init call inside open <damo22>its hard to synchronise the code in the initrd with the code i just compiled <youpi>did you try the "sync" command like I wrote ? <damo22>when i mount the initrd inside hurd on a dir it gets corrupt when i save a file in it <youpi>oh but with umount the translator should be gone and the caches up to date <damo22>this is odd, i think rump_init is being called in a separate process? <damo22>rump is complex, i think i should compile rumpdisk as a static binary <youpi>we don't necessarily need to share the code in memory <youpi>and kernel code is not used to shared linking <youpi>vim tells me it's in include/device/device_types.h <damo22>i did, but hurd doesnt know about gnumach <damo22>ext2fs.static: $(boot-store-types:%=../libstore/libstore_%.a) what does this mean? <youpi>it expands the boot-store-types variable, but does string replacement <youpi>for each word (referenced by %) it replaces it with the expanded version where % is replaced by the word <youpi>make has a lot of such text manipulations <damo22>i can build rumpdisk.static a similar way ***Glider_IRC__ is now known as Glider_IRC
<AlmuHS>damo22: in IOAPIC implementation, be careful to keep backwards compatibilty with the PIC. In my code, APIC enumeration is only done when NCPUS > 1 <damo22>13331408 Nov 9 23:26 rumpdisk.static <damo22>same behaviour as the shared libs version <damo22>AlmuHS: i am working on getting actual patches i can submit <damo22>i am simplifying the interrupt handling so ioapic can be smaller patch <damo22>im very close to having a working rump disk driver :| <AlmuHS>damo22: It's great. I've seen your new patch <jrtc27>youpi: whole-archive only makes sure to try linking in a loop. that won't include objects if nobody references them> you're thinking of --begin-group/--end-group <jrtc27>--whole-archive *is* "include the entire contents of any subsequent .a's regardless of if anyone is seemingly using them" <jrtc27>typically for things like .a's with constructors <youpi>ah, right I was thinking of group (like I said, manpages always know better :) ) <youpi>I'm surprised that whole-archive would include the .a even if there is no need for a symbol there <youpi>from the doc I would understand that it only either includes all the .a, or nothing <youpi>you may want to have it all-or-nothing, but not necessarily linked in <jrtc27>"For each archive mentioned on the command line after the --whole-archive option, include every object file in the archive in the link, rather than searching the archive for the required object files." <youpi>the latter being exactly the ponit of no-as-needed <youpi>yes, but the new default as-needed comes in the way <youpi>actually technically as-needed is only about adding the tags <jrtc27>as-needed only talks about DT_NEEDED for shared libraries <youpi>so it doesn't actually come in the way <youpi>but users would think it does <youpi>since they don't know about such ELF details <jrtc27>oh yes users have no clue about any of this, they will just do things until the errors go away ***Glider_IRC_ is now known as Glider_IRC
<gnu_srs2>youpi: is it possible to git clone git://git.savannah.gnu.org/hurd/hurd.git and check out an earlier version: 1:0.9.git20190331-8 <AlmuHS>gnu_srs2: possibly you can do It with "git checkout" or "git branch" <gnu_srs2>AlmuHS: Thank, I'll try to use either. Need to find the right tag/branch to use though. 
