IRC channel logs
2023-03-12.log
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 <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>basicall y it's upstream hurd, plus some directories from the dde branch <youpi1>(eth-filter, libdde-linux26, libddekit, and libmachdevdde) <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 <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>in any case all the other gnumach traps are already available as rpcs <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* <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 <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>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 <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 <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 <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>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 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