IRC channel logs


back to list of logs

<luckyluke>If you compile a 32-bit mig then it already target i686, you need to recompile it if you want to target x86_64
<luckyluke>with "target i686" I mean that MIG will generate code for a 32-bit userspace, it's not the .../configure --target=xxx
<luckyluke>although probably it should be, but AFAIK the current MIG has not this flexibility
<luckyluke>i.e. the --target and --host need to be the same
<luckyluke>uhm, apparently also setting only --target=i686-linux-gnu works, but you need to have the 32-bit cross compiler installed, and it will install a i686-linux-gnu-mig
<youpi1>normally mig does support canadian builds
<youpi1>if we broke it we should really fix it
<luckyluke>I just tested it with Debian's gcc-i686-linux-gnu package and seems to work, I compiled gnumach and ran some basic user-space tests
<lissobone>For some unknown reason I have read "GNU MIG is fully compatible with OSF MIG" as "GNU MIG is fully obsolete with OSF MIG".
<jpoiret>i still haven't tried to use a cross building mig, that will come after I build hurd at least once :p but thanks for the pointers
<jpoiret>i see we have dde and netdde in Guix, but they don't seem to build, are they used by Debian as well?
<jpoiret>since i'm not seeing a lot of activity on these branches I want to make sure I'm not going on a wild goose chase
<youpi1>jpoiret: they are used, yes
<jpoiret>Yeah, actually it seems the build failures is on our part
<jpoiret>i'm getting some conflicts between the glibc headers and the linux source in dde
<jpoiret>do you have the Debian build scripts somewhere I can have a look?
<youpi1>you have the tarballs on
<youpi1>basicall y it's upstream hurd, plus some directories from the dde branch
<youpi1>(eth-filter, libdde-linux26, libddekit, and libmachdevdde)
<youpi1>and then we just amend Makefile in
<youpi1>ah, no, there's also the libdde-linux26 build, in
<jpoiret>thanks! That should help me find the right changes to make
<jpoiret>one more question: libdde_linux26's README mentions the toplevel include/ dir is copied over the contrib/include/ in the build directory, overwriting the headers there. But include/linux/autoconf.h has #include_next <linux/autoconf.h> which is supposed to include contrib's. I'm getting a header not found error for that reason
<youpi1>I don't remember about that
<jpoiret>Well, i'll probably have to go down makefile hell then
<gighu>looking at the "x86_64: add 64-bit syscall entry point" patch I'm left wondering of a crazy alternative solution
<gighu>get rid of all gnumach traps, a part of mach_msg
<gighu>pass the 7th argument of mach_msg on rax
<gighu>all the other traps seems like premature optimizations to me
<gighu>what do you guys think of this?
<gighu>on the user side, extern mach_msg_return_t mach_msg could become static inline mach_msg_return_t mach_msg
<gighu>that would be a big win
<gighu>in any case all the other gnumach traps are already available as rpcs
<gighu>what's the point of them?
<gighu>also syscall emulation, is just a retage of msdos for mach
<gighu>it seems crazy to pay for each rpcs (including io!!) for this kind of stuff
<luckyluke>gighu: I'm not sure I understood well... but how would you handle mach_task_self() and such? and where would the optimization be, if mach_msg() would be the only syscall?
<gighu>luckyluke: mach_task_self() can be called as an rpc
<luckyluke>to which remote port? and how do you obtain it?
<gighu>from the parenttask_create maybe
<luckyluke>on the other hand, I think moving everything to mach_msg would allow to virtualize even the rpc usually handled by the kernel, because you could redirect the mach_self_*() rpcs
<gighu>I think I'm miscalculating thing
<luckyluke>it could be something like the kernel task, and it could be passed along by the bootstrap modules
<luckyluke>in the same way as the master device and host ports
<luckyluke>or you could even pass a different port, so e..g subhurds will have a fully virtualized env
<gighu>yes, I'm curious why it is not already like that
<luckyluke>one reason might be performance, or the time to implement it, I'm not sure
<luckyluke>but I guess the mach_self_*() calls can be cached on a task/thread basis
<gighu>sure I don't think it is performances
<gighu>if it was performances then the solution was in the wrong place
<luckyluke>do you think having only mach_msg() would have better performance?
<luckyluke>you'd need to decode the msg before calling the handler
<gighu>with the calculation that a syscall is always expensive
<luckyluke>and I think this is anyway more expensive than reading a parameter from the user stack
<gighu>I understand, but you call mach_self* once
<gighu>while you would rpc for io read and write several time
<gighu>i don't see why you would optimize mach_self*
<luckyluke>how would that change?
<gighu>I understand more the memory allocation optimization
<gighu>if mach_msg is the only syscall, it could be made a tad faster
<luckyluke>how? AFAIK the other syscalls are mostly optimizations for heavily-used rpcs, I don't see the performance advantage of having one single syscall. You might save some instrucitons in demultiplexing the syscall number
<gighu>yes, I agree that the other syscalls are optimizations so losing them might be a looss
<gighu>I understand that
<jpoiret>youpi1: for completeness, libdde_linux26 actually has both include files in build/include/ and build/include/linux-headers. The issue was that there is no dependency between the targets of libdde_linux26, and our make runs with -j8, so it would try building before the headers had been copied
<gighu>luckyluke: i'm just wondering if those were not premature optimization, what is the actual cost of decoding a message? Could some other optimization instead be made in user code to avoid syscalls? Avoiding syscalls would save the most
<jpoiret>btw, eth-filter hasn't been updated to have "const" arguments
<gighu>I can imagine that the only code that would be really syscall heavy could be just the hurd servers
<luckyluke>uhm, it seems mach_self_task/host() are already cached by glibc
<gighu>of course
<gighu>i'm thinking at things like mutexes that are now implemented through mach_msg.. I don't think this has been an issue so far
<gighu>so perhaps haveing mach_msg as the only syscall wouldn't hurt performances that much
<gighu>could it be that mach_self need to be syscalls because of securt
<gighu>security issues otherwise?
<youpi1>RPCs are slower than traps, so better use traps when one doesn't need virtualization
<youpi1>mutexes are not implemented through mach_msg any more
<youpi1>it's the gsync trap
<gighu>ok, then I guess it will stay the same
<luckyluke>gsync seem to be present in include/mach/gnumach.defs but not in mach_trap_table... maybe it could be a new optimization
<youpi1>ah right it's an rpc
<luckyluke>btw, is there already a way to virtualize the task/host/thread ports? I guess for this they shouldn't be obtainable with plain syscalls anymore...
<luckyluke>or maybe that was one of the goals of the emulated syscalls
<gighu>the goal of emulated syscalls was to run binaries compiled for other oses
<gighu>I don't think this fits the GNU philosophy
<Arsen>why not? it extends user freedoms
<gighu>i think it's an outdated mechanism
<gighu>wine doesn't do that on any os
<gighu>wsl doesn't do that on windows
<Arsen>didn't they start adding that to linux
<Arsen>maybe that plan was abandoned
<Arsen>istr one of the bsds doing a similar thing
<gighu>i think there was a discussion and they ended up using PROT_NOSYSCALL or something like that to raise an exceptioj
<gighu>all BSD does similar things
<gighu>but users would be better installing a linux vm
<gighu>linux also has the whole eBPF thing
<gighu>that is available only to superuser
<Arsen>i don't see any NOSYSCALL
<Arsen>i wonder the resolution of that was
<Arsen>but yes, a syscall emulator is at best a "best effort" deal
<gighu>Definitely, if gnu is interested in that, they should probably port qemu and kvm to the hurd