***Server sets mode: +nt
***Server sets mode: +nt
***dingenskirchen1 is now known as dingenskirchen
<jakelp>I have zero experience with kernel programming, so sorry if this is a stupid question, but could anyone give me a high-level overview of what porting the Hurd to x86_64 would involve? Like, is the problem mostly with Mach? Or is there a lot of architecture-specific code in the Hurd? Why is porting not mostly a compiler thing (if most of the code is C)? Are there lots of assumptions about data type sizes and the like that have to <jrtc27>kernel is pretty easy, userspace is pretty easy in general, as you say, most is just "recompile as 64-bit" <jrtc27>the hard part is hurd's RPC mechanism <jrtc27>there needs to be a 64-bit interface defined and implemented, plus the 32-bit one needs to work on a 64-bit kernel (both for ease of bootstrapping a 64-bit userspace and because it's generally good to support 32-bit userspace on a 64-bit kernel for compatibility) <jakelp>Thanks for the answer! How is the RPC interface defined? Would making a 64-bit interface be a really big job? <jakelp>Got it, thanks for the references <youpi>I wouldn't say the kernel part is pretty easy, since that source code was never built on 64bit systems at all :) <youpi>for userland, glibc etc. was on linux of course, hurd wasn't, but in general has proper typing <jrtc27>well, my point is, it's a known problem that's "just" filling in the gaps <jrtc27>whereas the mig stuff is far more unknown territory/here be dragons