IRC channel logs


back to list of logs

***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
<damo22>in the actual linux kernel
<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>we are doing non-specific
<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>haha this is cool
<damo22>gnu_srs2: its working!
<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
<gnu_srs2>damo22: Congrats :)
<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, -o \
<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/ ../libtrivfs/ \
<damo22> -lpthread -lrump -lrumpdev -lrumpdev_disk -lrumpdev_pci -lrumpvfs -lrumpdev_scsipi -lrumpdev_ahcisata \
<damo22> '-Wl,-)'
<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
<gnu_srs2>and defs
<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>how do i make it resolve the .a
<damo22>eg -lrumpdev_pci should find librumpdev_pci_pic.a
<damo22>and compile it in regardless if the symbols are found or not
<gnu_srs2>--whole-archive, --no-whole-archive?
<damo22>LDLIBS += -L/usr/lib -Wl,--whole-archive -lrump -lrumpdev -lrumpdev_disk -lrumpdev_pci -lrumpvfs -lrumpdev_scsipi -lrumpdev_ahcisata -Wl,--no-whole-archive
<damo22>i tried that
<damo22>it didnt compile them in
<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>so i dont have cdrom support
<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
<damo22>i am missing one symbol dlopen
<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
<damo22>the binary is bigger
<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
<gnu_srs2>I have i586-gnu-pkg-config
<youpi>then that's what configure should be using
<gnu_srs2>in /tools, i.e. the host system.
<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 can ctrl-c it
<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
<damo22>because the cache doesnt sync
<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
<youpi>so it's odd
<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>that could be easier
<youpi>we don't necessarily need to share the code in memory
<youpi>and kernel code is not used to shared linking
<damo22>where is D_SUCCESS defined?
<damo22>i hope it is 0
<youpi>use tags for finding these
<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
<damo22>oh nice
<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>not stripped
<damo22>stripped it goes down to 2.9M
<damo22>same behaviour as the shared libs version
<damo22>AlmuHS: i am working on getting actual patches i can submit
<damo22>but ioapic is also interesting
<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
<jrtc27>that's what it's purpose is :)
<jrtc27>*its -.-
<youpi>not necessarily
<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:// 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.
<AlmuHS>git tag will shows all tags