IRC channel logs
2024-11-22.log
back to list of logs
<ZhaoM_>I successfully install luakit on Hurd <ZhaoM>Forgot I have opened another IRC window :) <ZhaoM>sneek: later tell gnucode I successfully install luakit in the Hurd on my T60, thanks for reminding me some work is needed <youpi>janneke: git-context only deals with the *context functions, not signal relivery <janneke>youpi: okay...hmm, which patch might i be missing then to have a broken sigreturn.o <janneke>calling raise (SIGABRT) returns non-zero when using my guix-compiled sigreturn.o <janneke>hmm, could be a gnumach or hurd header even, i guess <janneke>ACTION has a statically linked test-sig using guix-crt/sigreturn.o and a test-sig-ok which uses debian-crt/sigreturn.o <janneke>but it seems i cannot get past raise/kill in gdb <janneke>when i run them, test-sig returns nonzero from raise, test-sig-ok returns 0 <janneke>ACTION goes to inspect the sigreturn.o's statically <janneke>well, i can confirm that the get/set/make/swap context patch is not a fix <janneke>ACTION gives up on the issue for now...needs some inspiration <jrtc27>> FWIW, an asm statement that's not marked as 'volatile' and doesn't have useful outputs can be eliminated by the compiler, but it doesn't seem to have happened here. <jrtc27>asm statements with no outputs are implicitly volatile (otherwise they would by definition be useless), and asm goto, FWIW <youpi>I guess by "useful", he meant that the declared outputs are actually used in the program <jrtc27>yeah, but the "useful outputs" was in response to a literal asm ("nop") <jrtc27>now yes, one should be a good person and put the volatile on it explicitly, both to document it and in case it later grows any output operands <jrtc27>but GCC *does* optimise non-volatile asm already, this is just explaining why it didn't optimise this one, and that it is technically guaranteed to behave as desired <slex__>guys i should convert a port that is ipc_port type associated (struct) to a device to a mach_port_t and passing it to a device driver (a simple one in userspace). what is the best way? <sneek>slex__, you have 3 messages! <sneek>slex__, solid_black says: I know next to nothing about driver development (so better ask someone else), but in my understanding, there are 2 (or 3?) fundamental ways software can interact with hardware. The first is dedicated x86 'in'/'out' insturctions, that IIUC read/write to the ISA bus. You can do them from userland just as you would from kernel land, but you need to ask for permission to do that first by calling ioperm(). Second, there <sneek>slex__, damo22 says: there is already a userland block device driver called rumpdisk <sneek>slex__, azert says: it is not clear to me what you want to achieve? What block device? What does it do? <slex__>sneek: I just saw your replies, I don't want to use rumpdisk for now, i'm learning so i want to do some simple stuffs. i'm trying to implement just a simple block disk driver in user space without using existing code like rumpdisk, just interacting with the kernel <azert>sneek: later tell slex__ a driver for what block device?