On 11 July 2013 13:30, Jiri Svoboda <[email protected]> wrote: > Hi JZr, > > please see my comments inline. > > > Jiří Zárevúcky wrote: > > [...] > > > First of all, let me explicitly state the "why". My intention behind Go > support is to have a modern, reasonably memory-safe language to write > system components with. > > Regarding that - I have no problems if you want to use it for > experimentation / writing prototypes. Writing HelenOS components in Go is a > different thing altogether. The status quo is that HelenOS is written in C > and IMHO allowing a new language for implementation of the system would > require a broader discussion and concensus. > > > Martin D. expressed similar concern during yesterday hangout. IMO the choice of language is something that cannot easily be discussed as a system-wide directive. Naturally, it makes little sense to rewrite existing stuff in a different language, but the nice property of our multiserver design is that you can actually write a single new driver in Go while leaving everything else untouched. I do not see a reason to expressly require every single piece of system to be C, if another language serves the purpose well.
> > With all that in mind, here is what I have come up with so far: > > lib/gocore: > The basic runtime support (mostly support for important function calls > emitted by the gccgo compiler). As little code as possible if it can be > helped. Non-critical parts of the runtime should be kept in a separate > library if possible. > > (maybe) lib/gomore: > In case some functionality can be stripped down to basics for the default > variant, this library can contain a more complex full-featured > implementation. One example that comes to mind is profiling/debugging > features and such things. > > lib/gomem: > Memory allocator and garbage collector (mostly copied from the official > distribution). This is an important component, but keeping it in a separate > library makes it possible to write different implementation of the same > thing if useful. Not to mention it's a huge piece of code and modularity is > always good. > > lib/gomap: > Hash map implementation. Hash map is a native type in Go, but it is not > critical for anything and still a very complicated piece of code. > > > lib/gochan: > Channel implementation. Same reason as above. > > Firstly, how Go support will exactly be implemented is probable the least > important question to me from the set of questions posed. I will try to > think about it carefully, nevertheless. > > > Let me try to decompose your proposal into atoms. > > You propose: > > 1) to implement Go runtime support in a set of libraries (as opposed to > one library) > > 2) specifically you propose what those libraries are and how the > functionality would be split > > > I am not familiar with Go to be able to comment on #2. As far as #1 is > concerned, I have nothing against the split, I would maybe advise to put > all the libs in one subdir, e.g. lib/go/(go)core, lib/go/(go)more, etc. It > is not clear to me, however, what specific benefit you expect from having > the runtime in multiple parts instead of one? Will that affect the way the > binaries will be linked? If so, how? Will I always link with all the > libraries or just a subset? If I'll link with all of them, isn't that an > unnecessary complication? If I link with just some of them, how will I > figure out which libraries I need to link with? > Specifically the memory allocator is by far the most complex piece of the runtime, and defines dozens of functions, yet only a few are used from other parts of the runtime. Explicitly putting it in another library makes the external interface much clearer. Another reason is, as I have already noted, that one may wish to implement the interface another way. With this separation, switching implementations is as simple as linking with a different library. For the rest of the separation, this largely falls into the "paranoia" category. If a big piece of runtime doesn't need to be used for the program to function correctly, I want to be able to exclude it and be sure that no error in this big chunk can affect me. So from the linking perspective, you usually want to link all of them, but for some programs, there are sound reasons not to. > Cheers, > > Jiri > Thanks for taking the time to answer! -- Jirka Z.
_______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
