FAQ
Hello.

Ages ago i started working on a Haiku (http://www.haiku-os.org) port of Go.
Due to real life getting in the way, I never really started actually
implementing the runtime support for this platform.

Fast forward to today, we have a student working on this port as part of
GSoC and the current main issue with the port is that the syscall interface
for haiku is not stable so, if at all possible, it would be preferable not
to try top make the syscalls by hand and, instead. go through the userland
interface that is present in a library called libroot (which is linked in
dynamically to all programs that run on haiku anyway).

Is there any precedent for doing something like that in other platforms? Is
it feasible at all or are there any current restrictions in go that would
not allow something like this?

Thanks in advance.

-Bruno

--

---
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Brad Fitzpatrick at May 13, 2014 at 4:31 pm
    The new Solaris port goes through libc to do syscalls, rather than directly.

    Windows is a bit of an oddball, too, but Solaris is probably closer to what
    you'd want to mimic.


    On Tue, May 13, 2014 at 6:00 AM, Bruno Albuquerque wrote:

    Hello.

    Ages ago i started working on a Haiku (http://www.haiku-os.org) port of
    Go. Due to real life getting in the way, I never really started actually
    implementing the runtime support for this platform.

    Fast forward to today, we have a student working on this port as part of
    GSoC and the current main issue with the port is that the syscall interface
    for haiku is not stable so, if at all possible, it would be preferable not
    to try top make the syscalls by hand and, instead. go through the userland
    interface that is present in a library called libroot (which is linked in
    dynamically to all programs that run on haiku anyway).

    Is there any precedent for doing something like that in other platforms?
    Is it feasible at all or are there any current restrictions in go that
    would not allow something like this?

    Thanks in advance.

    -Bruno



    --

    ---
    You received this message because you are subscribed to the Google Groups
    "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Bruno Albuquerque at May 13, 2014 at 4:47 pm
    Great. i will take a look at the Solaris specific code to see how they do
    that. Thanks for your help.

    On Tue May 13 2014 at 1:31:32 PM, Brad Fitzpatrick wrote:

    The new Solaris port goes through libc to do syscalls, rather than
    directly.

    Windows is a bit of an oddball, too, but Solaris is probably closer to
    what you'd want to mimic.


    On Tue, May 13, 2014 at 6:00 AM, Bruno Albuquerque wrote:

    Hello.

    Ages ago i started working on a Haiku (http://www.haiku-os.org) port of
    Go. Due to real life getting in the way, I never really started actually
    implementing the runtime support for this platform.

    Fast forward to today, we have a student working on this port as part of
    GSoC and the current main issue with the port is that the syscall interface
    for haiku is not stable so, if at all possible, it would be preferable not
    to try top make the syscalls by hand and, instead. go through the userland
    interface that is present in a library called libroot (which is linked in
    dynamically to all programs that run on haiku anyway).

    Is there any precedent for doing something like that in other platforms?
    Is it feasible at all or are there any current restrictions in go that
    would not allow something like this?

    Thanks in advance.
    -Bruno

      --
    ---
    You received this message because you are subscribed to the Google Groups
    "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Aram Hăvărneanu at May 13, 2014 at 5:04 pm
    Does Haiku use ELF? If so, your work is significantly easier, because
    the necessary bits to use a dynamically-shared libc were added to
    linker during the Solaris port.

    Please CC me directly in any thread with questions regarding the port,
    otherwise I will probably miss it.

    Also please read https://bitbucket.org/4ad/gofosdem2014 (rather sparse, sorry).

    --
    Aram Hăvărneanu

    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Bruno Albuquerque at May 13, 2014 at 5:13 pm
    Yes, Haiku does use ELF, which definitely makes things easier.

    Thanks for your help. i will make sure to CC you on any future questions.

    On Tue May 13 2014 at 2:04:03 PM, Aram Hăvărneanu wrote:

    Does Haiku use ELF? If so, your work is significantly easier, because
    the necessary bits to use a dynamically-shared libc were added to
    linker during the Solaris port.

    Please CC me directly in any thread with questions regarding the port,
    otherwise I will probably miss it.

    Also please read https://bitbucket.org/4ad/gofosdem2014 (rather sparse,
    sorry).

    --
    Aram Hăvărneanu
    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Aram Hăvărneanu at May 13, 2014 at 5:24 pm
    Good luck.

    --
    Aram Hăvărneanu

    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Han-Wen Nienhuys at May 13, 2014 at 4:34 pm

    On Tue, May 13, 2014 at 3:00 PM, Bruno Albuquerque wrote:
    Hello.

    Ages ago i started working on a Haiku (http://www.haiku-os.org) port of Go.
    Due to real life getting in the way, I never really started actually
    implementing the runtime support for this platform.

    Fast forward to today, we have a student working on this port as part of
    GSoC and the current main issue with the port is that the syscall interface
    for haiku is not stable so, if at all possible, it would be preferable not
    to try top make the syscalls by hand and, instead. go through the userland
    interface that is present in a library called libroot (which is linked in
    dynamically to all programs that run on haiku anyway).

    Is there any precedent for doing something like that in other platforms? Is
    it feasible at all or are there any current restrictions in go that would
    not allow something like this?
    On windows, the syscalls go through the windows32 system DLLs, which
    seems analogous to this.

    --
    Google Germany GmbH - ABC-Str. 19 - 20354 Hamburg
    Registergericht und -nummer: Hamburg, HRB 86891
    Sitz der Gesellschaft: Hamburg - Geschäftsführer: Graham Law,
    Christine Elizabeth Flores

    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-dev @
categoriesgo
postedMay 13, '14 at 4:25p
activeMay 13, '14 at 5:24p
posts7
users4
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase