On Mon, Sep 19, 2016 at 2:10 AM, Waldek Kozaczuk <jwkozac...@gmail.com>
> OSv has already a concept of module but I wonder if its core can be made
> modular as well. For example there could be something like osv.base,
> osv.io (osv.io.read, osv.io.write, etc), osv.net, etc I do not know
> enough it it makes sense but even POSIX systems calls can be grouped into
> modules and then pulled like lego blocks depending on what one needs. I am
> looking at the modularity of Java 9 runtime (http://openjdk.java.net/jeps/
> 220) which I am trying to draw an parallel to.
> Would it be possible? Is it a big effort?
Yes, it is possible to split off many parts of the OSv kernel into separate
shared objects. For example I can imagine moving the entire ZFS code into a
separate zfs.so, and loading this object will cause the ZFS support to be
added to the kernel, the ZFS partition to be mounted, and so on.
However, it will be an effort, and it's not clear what granularity even
makes sense: In your example above, you seems to have split the read() and
write() features to two different shared objects - I'm not sure that is
practical. It's also not clear to me how fine this division should be.
Should each individual function (or several related functions) be in a
separate object? Or just split it into several large ones?
Of course, to make any of this splitting effort worthwhile, one needs to
come up with a scenario where the current on-disk size of OSv is excessive.
You received this message because you are subscribed to the Google Groups "OSv
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.