IRC.

1 files changed, 127 insertions, 3 deletions

diff --git a/open_issues/mig_portable_rpc_declarations.mdwn b/open_issues/mig_portable_rpc_declarations.mdwn
index ecfa06ae..f5f18880 100644
--- a/open_issues/mig_portable_rpc_declarations.mdwn
+++ b/open_issues/mig_portable_rpc_declarations.mdwn
@@ -1,4 +1,5 @@
-[[!meta copyright="Copyright © 2011, 2013 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2011, 2012, 2013, 2014 Free Software Foundation,
+Inc."]]
 
 [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
 id="license" text="Permission is granted to copy, distribute and/or modify this
@@ -10,8 +11,35 @@ License|/fdl]]."]]"""]]
 
 [[!tag open_issue_mig]]
 
+[[!toc]]
 
-# IRC, freenode, #hurd, 2011-11-14
+
+# 32-Bit vs. 64-Bit Interfaces
+
+## IRC, freenode, #hurd, 2011-10-16
+
+    <braunr> i guess it wouldn't be too hard to have a special mach kernel for
+      64 bits processors, but 32 bits userland only
+    <youpi> well, it means tinkering with mig
+    <braunr> like old sparc systems :p
+    <youpi> to build the 32bit interface, not the 64bit one
+    <braunr> ah yes
+    <braunr> hm
+    <braunr> i'm not sure
+    <braunr> mig would assume a 32 bits kernel, like now
+    <youpi> and you'll have all kinds of discrepancies in vm_size_t & such
+    <braunr> yes
+    <braunr> the 64 bits type should be completely internal
+    <braunr> types*
+    <braunr> but it would be far less work than changing all the userspace bits
+      for 64 bit (ofc we'll do that some day but in the meanwhile ..)
+    <youpi> yes
+    <youpi> and it'd boost userland addrespace to 4GiB
+    <braunr> yes
+    <youpi> leaving time for a 64bit userland :)
+
+
+## IRC, freenode, #hurd, 2011-11-14
 
     <braunr> also, what's the best way to deal with types such as
     <braunr> type cache_info_t = struct[23] of integer_t;
@@ -58,7 +86,103 @@ License|/fdl]]."]]"""]]
     <antrik> (which I still need to follow up on... [sigh])
 
 
-# IRC, freenode, #hurd, 2013-06-25
+## IRC, freenode, #hurd, 2012-12-12
+
+In context of [[microkernel/mach/gnumach/memory_management]].
+
+    <tschwinge> Or with a 64-bit one?  ;-P
+    <braunr> tschwinge: i think we all had that idea in mind :)
+    <pinotree> tschwinge: patches welcome :P
+    <youpi> tschwinge: sure, please help us settle down with the mig stuff
+    <youpi> what was blocking me was just deciding how to do it
+    <braunr> hum, what's blocking x86_64, except time to work on it ?
+    <youpi> deciding the mig types & such things
+    <youpi> i.e. the RPC ABI
+    <braunr> ok
+    <braunr> easy answer: keep it the same
+    <youpi> sorry, let me rephrase
+    <youpi> decide what ABI is supposed to be on a 64bit system, so as to know
+      which way to rewrite the types of the kernel MIG part to support 64/32
+      conversion
+    <braunr> can't this be done in two steps ?
+    <youpi> well, it'd mean revamping the whole kernel twice
+    <youpi> as the types at stake are referenced in the whole RPC code
+    <braunr> the first step i imagine would simply imply having an x86_64
+      kernel for 32-bits userspace, without any type change (unless restricting
+      to 32-bits when a type is automatically enlarged on 64-bits)
+    <youpi> it's not so simple
+    <youpi> the RPC code is tricky
+    <youpi> and there are alignments things that RPC code uses
+    <youpi> which become different when build with a 64bit compiler
+    <pinotree> there are also things like int[N] for io_stat_struct and so on
+    <braunr> i see
+    <youpi> making the code wrong for 32
+    <youpi> thus having to change the types
+    <youpi> pinotree: yes
+    <pinotree> (doesn't mig support structs, or it is too clumsy to be used in
+      practice?)
+    <braunr> pinotree: what's the problem with that (i explcitely said changing
+      int to e.g. int32_t)
+    <youpi> that won't fly for some of the calls
+    <youpi> e.g. getting a thread state
+    <braunr> pinotree: no it doesn't support struct
+    <pinotree> braunr: that some types in struct stat are long, for instance
+    <braunr> pinotree: same thing with longs
+    <braunr> youpi: why wouldn't it ?
+    <youpi> that wouldn't work on a 64bit system
+    <youpi> so we can't make it int32_t in the interface definition
+    <braunr> i understand the alignment issues and that the mig code adjusts
+      the generated code, but not the content of what is transfered
+    <braunr> well of course
+    <braunr> i'm talking about the first step here
+    <braunr> which targets a 32-bits userspace only
+    <youpi> ok, so we agree
+    <youpi> the second step would have to revamp the whole RPC code again
+    <braunr> i imagine the first to be less costly
+    <braunr> well, actually no
+    <braunr> you're right, the mig stuff would be easy on the application side,
+      but more complicated on the kernel side, since it would really mean
+      dealing with 64-bits values there
+    <braunr> (unless we keep a 3/1 split instead of giving the full 4g to
+      applications)
+
+See also [[microkernel/mach/gnumach/memory_management]].
+
+    <youpi> (I don't see what that changes)
+    <braunr> if the kernel still runs with 32-bits addresses, everything it
+      recevies from or sends through mig can be stored with the user side
+      32-bits types
+    <youpi> err, ok, but what's the point of the 64bit kernel then ? :)
+    <braunr> and it simply uses 64-bits addresses to deal with physical memory
+    <youpi> ok
+    <youpi> that could even be a 3.5/0.5 split then
+    <braunr> but the memory model forces us to run either at the low 2g or the
+      highest ones
+    <youpi> but linux has 3/1, so we don't need that
+    <braunr> otherwise we need an mcmodel=medium
+    <braunr> we could do with mcmodel=medium though, for a time
+    <braunr> hm actually no, it would require mcmodel=large
+    <braunr> hum, that's stupid, we can make the kernel run at -2g, and use 3g
+      up to the sign extension hole for the kernel map
+
+
+## IRC, freenode, #hurd, 2013-12-03
+
+    <azeem> I believe the main issue is redoing the RPCs in 64bit, i.e. the
+      Mach/Hurd interface
+    <braunr> mach has always been 64-bits capable
+    <braunr> the problem is both mach and the hurd
+    <braunr> it's at the system interface (the .defs of the RPCs)
+    <braunr> azeem: ah, actually that's why you also say
+    <braunr> but i consider it to be a hurd problem
+    <braunr> the hurd itself is defined as being a set of interfaces and
+      servers implementing them, i wouldn't exclude the interfaces
+    <braunr> that's what*
+
+
+# Structured Data
+
+## IRC, freenode, #hurd, 2013-06-25
 
     <teythoon> is there a nice way to get structured data through mig that I
       haven't found yet?