The next commit will make mode_t 32-bits, ino_t 64-bits, nlink_t
32-bits, and off_t 64-bits. However, in the protocol there is no
room for that.
When analyzing the usage of these data types we can see that of
mode_t we currently use 15 bits and that future flags (if copied
from NetBSD) are only of importance to VFS and not to the actual
file system on disk. Therefore we can get away with keeping the
protocol version of mode_t (pmode_t) 16 bits.
At this point it is unlikely that MINIX will support file systems
that can hold more than 2^32 files. Keeping the protocol version of
ino_t (pino_t) 32-bits and exposing it as 64-bits to the rest of the
system is fine.
uid_t and gid_t are already 32-bits, but in behind the scenes they're
16-bits. This is sufficient since we don't support uid/gids larger
than 2^16-1.
off_t will become 64-bits, but the protocol had room reserved
for that since it was revised years ago.
So to make the difference clear between what the protocol supports
and what is exposed to the system, we define protocol version of
these data types.
Change-Id: Ifb883aafb222142e69d6dcc3049a47170b78b3ee
By adding versioning we have a handle on ABI breaking changes in
the protocol or system wide data structures. As of this commit the
protocol version is 0 in order to be compatible with File Servers
that are not yet aware of versioning.
Change-Id: I8f4eca49b506f0c03383c25593e0c44bddac3d66
REQ_PEEK behaves just like REQ_READ except that it does not copy
data anywhere, just obtains the blocks from the FS into the cache.
To be used by the future mmap implementation.
Change-Id: I1b56de304f0a7152b69a72c8962d04258adb44f9
. all invocations were S or D, so can safely be dropped
to prepare for the segmentless world
. still assign D to the SCP_SEG field in the message
to make previous kernels usable
This Shared Folders File System library (libsffs) now contains all the
file system logic originally in HGFS. The actual HGFS server code is
now a stub that passes on all the work to libsffs. The libhgfs library
is changed accordingly.
