<clarity_>hey, so hurd is cooporative multi-threaded (well, gnu/mach). I'm wondering how this works with the programs running on top of it. From my understanding, the programs need to yield to run in that type of threading system. Is this not the case? <damo22>has anyone heard of Microsoft Pluton? apparently in new x86 pcs there is going to be a TPM built into the CPU that generates a unique serial number on first boot, and its immutable, and they use it to identify with cloud services to lock you out of certain services per serial number <youpi>hurd is *not* cooperative multi-threaded, gnumach preempts threads at will <youpi>(I wonder where "clarity" found it'd not be) <luckyluke>biblio: try with objdump -S to disassemble compiled c code (beware of optimizations) ***roptat is now known as Guest1151
<slex>I think i pushed near the "top" i can obtain without modifying the hurd xD <slex>however i will wait for replies on the mailing list, actually i did pass the exec server from the grub command line <luckyluke>I have some static assert fail when building gnumach for 64 bit after rebasing on latest master, there were some updates and I updated mig also <luckyluke>I guess this mean that I need to fix the types in the headers for 64 bit. Is the target still to keep compatibility with current 32-bit IPC? <luckyluke>btw, I'm building on GNU/Linux currently, I don't know if that can make a difference (I buld mig also from source with my gnumach headers) <youpi>luckyluke: I didn't plan to have a 32bit IPC compatibility for 64bit processes, I don't see any use for this <youpi>I was planning for 32-on-64 compatibility, though <youpi>the 64bit variants of types need to be decided on yes <Curiosa>Will 64 bit clients call into 32 servers through gnumach and vice-versa seamlessly (eg without having to know if the server is 32bit or 64bit)? <youpi>I wasn't planning for full cross-bitness translation <youpi>just making a 32bit translation for the gnumach RPCs <youpi>so it's easier to first work on a 64bit kernel, not having to port all userland <youpi>and then start porting the userland with dumb static binaries that don't use hurd ports, only kernel interfaces <Curiosa>Makes sense, maybe a stupid idea, but for transitioning, one could think of a 64bit abi that needs to long call into a 32bit segment just to perform syscalls a bit like 32bit DJGPP was calling into dos for file operations <youpi>it's not stupid, but it's work <youpi>no, glibc shouldn't have to move <youpi>it's rather an RPC translation layer that'd be needed <youpi>to translate from one RPC ABI to another <youpi>and then both clients and servers don't have to change <youpi>not unrealistic, but still some work <youpi>possibly the 32-on-64 translation in gnumach would be the same work, I don't know <luckyluke>youpi: you mean that the current 32-bit IPC should be usable on a 64 bit kernel? For example, if I take the current ext2fs.static, and run on a 64 bit kernel. <luckyluke>In this case, it seems there's nothing to decide, and "just" translate from one format to the other, with some limitations (e.g. virtual addresses range) <luckyluke>otherwise, we'd need to recompile with the 64-bit gnumach headers <luckyluke>I see that already now rpc_phys_addr_t = uint64_t, so maybe the first option would be doable <youpi>luckyluke: yes, that's the idea, just translating the RPC message <youpi>in principle the .defs files provide the correct information to just generate the translation <youpi>possibly that's a feature that could be just added to mig ***Guest1151 is now known as roptat
<luckyluke>youpi: maybe it's a bit naive... but could the rpc-specific types be extended to all data fields, and not only phisical addresses? The first step would just be a renaming, and then adapting each rpc in gnumach to do the required conversions and checks. <youpi>I don't understand what you mean by "all data fields and not only physcial addresses" <youpi>perhaps you have an example to explicit what you mean? <luckyluke>I mean to have rpc_vm_offset_t, rpc_vm_size_t and so on <youpi>so that when building for 64bit we really have the proper sizes <luckyluke>some would require a bit of work, as in some cases they are directly converted from a pointer (e.g. it seems to be the case for some mach ports) <youpi>to make sure we properly distinguish vm_offset, size, address, etc. <youpi>and probably no actual behavior change