<div dir="ltr">Hey Zachary,<div><br></div><div>I just started looking at the HostInfo* classes.  I'm a little confused - we are going to want to have Android behavior differ in just a tiny little way from Linux (and POSIX).  So we're going to want to break out some implementation details into some virtual methods that are possibly no-op or different-op on the *largely same* code for POSIX/Linux.  Yet all the calls in these classes are static.</div><div><br></div><div>Why isn't this just a class instance hierarchy?  We're going to want it to be more like that so we can use typical C++ class design patterns like using virtual methods and the like.</div><div><br></div><div>Or did you have some other paradigm in mind for nearly-similar classes that want to share the bulk of the code in these classes?</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 26, 2014 at 1:09 PM, Todd Fiala <span dir="ltr"><<a href="mailto:tfiala@google.com" target="_blank">tfiala@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">>>! In D5495#27, @zturner wrote:<br>
> I'm not seeing the changes to HostInfoPosix and HostThreadPosix that I<br>
> suggested.  Are those still coming in a followup?<br>
<br>
</span>With Android, it's *mostly* Linux (at the kernel level) except we have a whole slew of different runtime libraries that differ.  So, for much of the behavior, it will be like Linux/POSIX, but with certain libc calls and whatnot that just don't exist.  Ideally we minimize how much we differ and only when needed.<br>
<br>
Tong, can you take a look at that?  If we need a Linux-derived Android variant of these classes, this might be a good time to look at those.  Thanks.<br>
<br>
> (paraphrased) how do you launch on Android, then?<br>
<br>
In general you don't.  The Android zygote takes care of launching for userland, and debuggers usually run attach-only.<br>
<br>
That's just a half-truth, though.  We do have low-level, internal capabilities for launching,  but since that is not a supported path for developers, they are not exposed in a way we can access with POSIX-like calls.  The launch code might end up only showing up in an AOSP environment but, in any event, the attach path is the crucial one for Android right now.<br>
<br>
<a href="http://reviews.llvm.org/D5495" target="_blank">http://reviews.llvm.org/D5495</a><br>
<br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><table cellspacing="0" cellpadding="0" style="color:rgb(136,136,136);font-family:'Times New Roman'"><tbody><tr style="color:rgb(85,85,85);font-family:sans-serif;font-size:small"><td nowrap style="border-top-style:solid;border-top-color:rgb(213,15,37);border-top-width:2px">Todd Fiala |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(51,105,232);border-top-width:2px"> Software Engineer |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(0,153,57);border-top-width:2px"> <a href="mailto:tfiala@google.com" style="color:rgb(17,85,204)" target="_blank"><span style="background-color:rgb(255,255,204);color:rgb(34,34,34);background-repeat:initial initial">tfiala@google.com</span></a> |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(238,178,17);border-top-width:2px"><font color="#1155cc"> <a>650-943-3180</a></font></td></tr></tbody></table><br></div>
</div>