5 ms·

The 9P file protocol, he said, comes from the Plan 9 operating system. The kernel has a 9P client, but no 9P server. There is a 9P server in QEMU that can be us

by opless 4y ago

The 9P file protocol, he said, comes from the Plan 9 operating system. The kernel has a 9P client, but no 9P server. There is a 9P server in QEMU that can be used to export host filesystems into a guest. The protocol is simple, Almeida said, defining a set of only ten operations. His 9P server implementation works now, in a read-only mode, and required just over *1,000* lines of code. ... I wonder how many lines of code the Plan9 (C) server takes? (much less I suspect)

deleted 4y ago
[deleted]
tialaramex 4y ago
From previous example drivers, I'd expect that it's not dissimilar overall and mostly the cause will be style preferences e.g. maybe the C programmers loves one-line for loops and the Rust programmer chooses default Rust style which doesn't do that, or contrariwise the C programmer finds it helpful to write out complicated variable types across multiple lines and the Rust programmer was comfortable letting them be inferred instead. If the C ends up hand rolling something Rust just has built-in, that adds up pretty quickly. For example Rust's arrays, strings etc. know how big they are, C's do not and so you need extra code to re-calculate or to explicitly store and retrieve those sizes. On the other hand it may be tempting to express a Rust type as having methods defined over it, rather than as you must in C using only free functions throughout, there's also a Rust discipline of always deriving common traits e.g. Clone, Debug and Eq, when they're appropriate, as a convenience, that's one line extra in typical style.
yencabulator 4y ago
This Linux 9P server is a 9P-to-Linux-VFS translator. No such software component exists in Plan9. You can think of the Plan9 kernel as a 9P multiplexer. 9P in, 9P out. The closest matching thing would be e.g. a 9P-to-ext4-in-a-file translator -- but it's always "9P server talking to $FOO" (or "9P server that makes files up on the fly"). Most of the complexity of this Linux 9P server would be in translating between the unrelated worlds of 9P and Linux VFS. A more apt comparison is the size of this 9P server vs an in-kernel NFS server -- they both translate something unrelated to Linux VFS.

by opless 4y ago

deleted 4y ago

[deleted]

tialaramex 4y ago

From previous example drivers, I'd expect that it's not dissimilar overall and mostly the cause will be style preferences e.g. maybe the C programmers loves one-line for loops and the Rust programmer chooses default Rust style which doesn't do that, or contrariwise the C programmer finds it helpful to write out complicated variable types across multiple lines and the Rust programmer was comfortable letting them be inferred instead. If the C ends up hand rolling something Rust just has built-in, that adds up pretty quickly. For example Rust's arrays, strings etc. know how big they are, C's do not and so you need extra code to re-calculate or to explicitly store and retrieve those sizes. On the other hand it may be tempting to express a Rust type as having methods defined over it, rather than as you must in C using only free functions throughout, there's also a Rust discipline of always deriving common traits e.g. Clone, Debug and Eq, when they're appropriate, as a convenience, that's one line extra in typical style.

yencabulator 4y ago

This Linux 9P server is a 9P-to-Linux-VFS translator. No such software component exists in Plan9. You can think of the Plan9 kernel as a 9P multiplexer. 9P in, 9P out. The closest matching thing would be e.g. a 9P-to-ext4-in-a-file translator -- but it's always "9P server talking to $FOO" (or "9P server that makes files up on the fly"). Most of the complexity of this Linux 9P server would be in translating between the unrelated worlds of 9P and Linux VFS. A more apt comparison is the size of this 9P server vs an in-kernel NFS server -- they both translate something unrelated to Linux VFS.