Blog Post: Tales of Open Source: vfscore

[Razvan Deaconescu]

Hi.

We posted a blog article on the Unikraft.org website[1] in the "Tales of
Open Source" series, regarding VFScore in Unikraft (virtual filesystem
support). And showing the history of the (open source) code from Prex,
via OSv (Cc: Waldek Kozaczuk) to Unikraft.

It advertises the beauty of the open source model and shows how projects
indirectly cooperate via their source code.

Hope you enjoy it.

A snippet of the article:

"""
So we now have the full story of the origin of Unikraft’s vfscore, based
on the amazing process of reusing open source code. Initially
implemented as part of the filesystem server in the Prex real-time
microkernel, it was then imported as OSv’s vfs and then added to
Unikraft’s vfscore, over the span of about 14 years.
"""

[1] https://unikraft.org/blog/2023-06-09-tales-of-open-source-vfscore/

Razvan

[Nadav Har'El]

On Thu, Jun 15, 2023 at 7:10 AM Razvan Deaconescu <raz...@unikraft.io> wrote:

Hi.

We posted a blog article on the Unikraft.org website[1] in the "Tales of
Open Source" series, regarding VFScore in Unikraft (virtual filesystem
support). And showing the history of the (open source) code from Prex,
via OSv (Cc: Waldek Kozaczuk) to Unikraft.

Very nice.

I like to compare open source evolution to that of organisms: Open-source

software also undergoes "natural selection", where the software that most

fits the environments (the users) gets replicated more and is the software you

see all around you - in computers, phones, servers, and so on.

As in organisms, variants and forks of the original project may compete with it

in the population and ultimately replace it. And what you wrote about now with

the Prex -> OSv -> Unikaft code reuse is analogous to "Horizontal Gene

Transfer" in organisms (https://en.wikipedia.org/wiki/Horizontal_gene_transfer):

Genes (in software - this means pieces of code) may be transplanted from one

software to another one, to give some new software a fully-developed feature

of another project in one fell swoop. 

 

It advertises the beauty of the open source model and shows how projects
indirectly cooperate via their source code.

Exactly.

[Razvan Deaconescu]

I like the comparison and the "natural selection" part and the "natural"
evolution: adaptation to ever-changing conditions.

As new hardware / software / technology / use cases come about, so will
existing software need to adapt; or be replaced. And one way of adapting
is bringing up existing "genes" from other (open source) software
projects.

>> It advertises the beauty of the open source model and shows how projects
>> indirectly cooperate via their source code.
>
> Exactly.

Razvan

[jwkoz...@gmail.com]

Indeed interesting. 

As one can expect some changes to vfs layer also have happened on OSv side as well since it was imported into unikraft:

git log --oneline HEAD...eb28d3bd -- fs/vfs/
9b1e9b0d lazy stack: ensure next stack page statically
9cc49b38 vfs: support mounting ZFS from non-root partition
311d07cb zfs: make mkfs do not depend on OSv C++ api
d1d0dd1a zfs: export symbols needed by libsolaris.so
bcc66b48 syscalls: allocate local iovec copies on the stack instead of the heap
1097dfa0 vfs: implement renameat()
6716ad91 syscall: implement getdents64
504b1bb8 vfs: implement symlinkat
b4512b7f unlinkat: fill the gaps in the implementation
09b88486 vfs: refactor the *at() functions
ffb91b1e build: support driver profiles
317d259a prepare to hide kernel symbols: expose libc symbols in certain files
18555601 vfs: harden drele() to check for null v_op and vop_inactive
5716f8c4 Implement statx() function
b3965a9e fs/vfs/main.cc: fix gcc 11 build error
a0761f8d Fix mkdir syscall issue and implement mkdirat
4499f2c7 vfs: add minimal implementation of unlinkat
81539853 Upgrade musl from 0.9.12 to 1.1.24
f398a3b3 loader: add support for booting from virtio-fs
c04f2261 loader: add rootfs type command line option
c00c74d7 libc: drop 5 more headers with symlinks to musl copies
43939b18 vfs: homogenize mount_rofs_rootfs and mount_zfs_rootfs
c1248bb1 fs:change uiomove() to use size_t in the signature instead of int
b1452f9a loader: add option to mount extra filesystem
4c0bdbc1 pagecache: refactor to allow integration with non-ZFS filesystems
c193437b zfs: modify fsid_guid to store extra bits to allow detecting ZFS in pagecache
4ffb0fa9 fs: move nfs support out of kernel in lieu of a separate pluggable module
bae4381d virtio-fs: initial implementation of read-only subset
474c538d zfs: do not import extra pools unless requested
2b62eac1 vfs: make fcntl() handle F_DUPFD_CLOEXEC
d14a5dca fs: add subset of sysfs implementation needed by numa library
7bc0155d vfs: Harden task_conv() to return EFAULT when cpath argument is null
edcf2593 Enhanced __fxstata to handle AT_SYMLINK_NOFOLLOW
a0dcf853 Tweak open() and sys_open() to return EFAULT error when pathname null
e684397e Add missing readlinkat function and corresponding syscall

I wonder if you can backport some of them or you may have been doing it already.

Regards,

Waldek

[Răzvan Deaconescu]

This is indeed something to look into. We'll probably take a peek of
those in the Unikraft community for backporting (and then write
another blog post :-D). Some of them may have been solved similarly on
our side. Maybe some can be backported to OSv.

I'll make this a task in the Unikraft community; we've had our set of
challenges with vsfcore. And we'll see if / how we can do some "patch
transplanting" from OSv to Unikraft and viceversa.

Razvan

> --
> You received this message because you are subscribed to the Google Groups "Unikernel Alliance" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to unikernel-allia...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/unikernel-alliance/ed973b0b-0643-45b1-abbc-fc34567b6b30n%40googlegroups.com.