Segmented VFS: Is this a good design?

[Clover5411]

Hello. As you all know, there is a notable difference between how Windows and Linux approach VFS. One uses drive letters, and the other puts everything under a single root directory. Lately, I've been thinking of a potential design for my OS that is a mixture of the two; and was partly inspired by x86 segmentation.

Here is what I am thinking. Firstly, there will be linear pathnames which work similarly to Linux. E.g. /Homes/User1/My File.txt
These will be used internally by the VFS; and won't be exposed directly to applications.

Then there are segmented pathnames, which are exposed to the applications. They look like Windows pathnames, but the drive letter is replaced by a segment name. E.g. User1:/My File.txt
A special segment can be used to allow applications to access linear pathnames; e.g. Linear:/Homes/User1/My File.txt

Upon receiving the segmented pathname, VFS will first start by searching for the segment among a list of segments. The segment will simply match with a directory in the linear pathname, and that will be concatenated with the rest of the pathname. Now that it has the linear pathname, it will search for the mount that contains the file, possibly via a list of mount points or a node tree. Finally, it will pass the request to the correct filesystem driver.

Here's what I intend to do with this system:

1) Have a simple permission system: In this system, User1 may only be allowed to access User1:/ segment, while User2 would only be allowed to access User2:/ segment. This is simple enough to implement. Obviously, ACLs are much better, but those sound a bit complicated at this stage (I need to use a filesystem that supports ACLs). Once my OS reaches maturity, I plan to add support for ACLs, then I have two permission systems

2) Have near pathnames: Consider the following pathname, /src/code.c, this could be a near pathname. Depending on the current working segment, it could be My Project:/src/code.c or Your Project:/src/code.c
I think these could be useful, maybe with stuff like symlinks, or some applications.

3) Make a user-friendly file explorer without sacrificing utility for advanced users: For example, one thing I want to do is; if the user loads their home directory, instead of showing all the stuff there as is (which could contain directories like Desktop, Documents, or Downloads), I could show a special stripped down interface that's more accessible. However, this may annoy advanced users who want to see their files directly. Here's how I could solve this problem with the above VFS: If a user explores their home segment (e.g. User1:/), show the simplified UI. If they explore the linear segment, or some other segment (e.g. Linear:/Homes/User1/); show the advanced UI.

EDIT: After thinking a bit more, choosing between simple and advanced views by segment might be a bad idea. What if User1 doesn't have permission to access Linear:/ segment?

There could also be a prompt for accessing certain segments, such as Linear:/ or System:/. Something like: You are trying to access a protected segment. Messing with such a segment could potentially damage your system. It is recommended to turn back. Continue anyway? (Yes/No) ...Ok, I should try to rephrase that later, I don't think it came out good

4) Possibly have process-local segments: A segment like AppData:/ could resolve to different linear pathnames depending on the process. For this to work, AppData:/ would have to be a process-local segment. I want to prevent untrusted applications from accessing anything but their own data without permissions. This can be done by restricting access to global segments, and instead having special local segments for the processes to use. For example; AppFiles:/ for accessing their own installed files, AppData:/ for accessing a special directory where the application can save stuff, and Temp:/ for accessing a directory that will be deleted when the process is shut down.

There will be some need for shared segments. For example, say I have the following 3 processes:

• MyGame.exe
• MyGameMapEditor.exe (1)
• MyGameMapEditor.exe (2)

In this situation:
1) All of these processes should share AppData:/
2) MyGameMapEditor.exe (1) and MyGameMapEditor.exe (2) should share AppFiles:/
3) All three processes should have their own local Temp:/

Global segments could be implemented as local segments that are shared by every process upon startup. Haven't decided on that yet.

So yeah, that's my VFS design. I haven't committed to it yet though. I am looking for advice. Would you recommend me to continue with this system? Are there any potential traps I should watch out for? And what are the ways I can improve this?

[rdos]

How the various partitions are linked in the namespace is of minor importance. In Windows, but also in my OS, driver letters are assigned to partitions. However, I could also link the partitions within the namespace like Linux does, and absolute pathnames could then access all the partitions without a drive letter. Consider that the "Windows" design judges /somedir relative to the current drive, but if the partitions are linked within the namesspace, then everything can be accessed without driver letters.

Anyway, the namespace construction shouldn't matter when you design the VFS. The VFS in both Windows & Linux needs to deal with partitions of different types, so this is what you need to consider in the design. Not how partitions are linked in namespace.

[Clover5411]

Anyway, the namespace construction shouldn't matter when you design the VFS. The VFS in both Windows & Linux needs to deal with partitions of different types, so this is what you need to consider in the design. Not how partitions are linked in namespace.

First of all, thanks for your reply. And yeah, that's another thing I'm thinking about. Passing the requests to relevant filesystem drivers is easy enough, but filesystems differ in their abilities. What if I try to use non-ASCII characters to a filesystem that doesn't support them? What if I try to create hard links in a filesystem that doesn't support them? What if I try to make hidden files in a filesystem that doesn't support them? My best idea for now is this; let the VFS pass the request regardless, and let the driver return an error if it's not possible.

Another thing I'm unsure about is what do I do if a mounted filesystem supports something that my VFS doesn't? For example, let's presume that a semicolon is considered a special character for my VFS, as such, it's not allowed in filenames. What if the user mounts a filesystem that does allow semicolons in filenames? How am I supposed to deal with those?

I will try to make the filesystem as generic as possible, but ultimately, I don't think I can support everything there is. I might be able to support any UTF-8 character, but what about all sorts of special files? Hard-linked directories? File tags? What if there's a filesystem out there that uses a completely different way to identify files, rather than just naming them? At that point, I'm willing to throw in the towel and say "My VFS doesn't support that." Besides the users can still use special programs to access such systems. But even the idea of making a VFS that's generic enough to support all the popular filesystems seems daunting enough.

Another thing I'm struggling with is the concept of "Everything is a file." I like the idea of everything existing within one namespace, but I don't want to force everything to be a file. I have some ideas, strongly inspired by Marionumber1's system as described at viewtopic.php?f=15&t=27544. I'm unsure about the details however.

Once I have a clearer image of how I want to approach those, I'm planning to ask for reviews about those as well

[nullplan]

What if I try to use non-ASCII characters to a filesystem that doesn't support them? What if I try to create hard links in a filesystem that doesn't support them? What if I try to make hidden files in a filesystem that doesn't support them? My best idea for now is this; let the VFS pass the request regardless, and let the driver return an error if it's not possible.

That is pretty much exactly what Linux does. The VFS filters requests that will never make sense, but otherwise forward all requests to the FS drivers, and then those can reject according to ability.

What if the user mounts a filesystem that does allow semicolons in filenames? How am I supposed to deal with those?

Ooh boy, that is exactly the kind of fun you can have in Linux with a FAT file system. FAT allows the forward slash in file names, although Microsoft has been discouraging its use of late. There is at least one type of digital camera that creates file names with forward slashes in them. If you mount their memory cards in Linux, you will get nonsensical read-outs. In Linux, the forward slash is always the directory separator. There is absolutely no way around that. So, the files will exist when you read out the directories, but you can't access them.

The only solution there is to have a program that bypasses the VFS and corrects the faulty file names, such as dosfsck. This seems to be the only way.

Fundamentally, in your OS, you can only decide to either show the file names that can't be accessed, or not show them. The former has the advantage that users will see earlier that something weird is happening. You list a directory and the file mode for some files shows up as question marks. That tends to get noticed.

I might be able to support any UTF-8 character, but what about all sorts of special files? Hard-linked directories? File tags?

What special files do you mean? The typical UNIX ones? In that case, we're talking about sockets, symlinks, character specials, and block specials. The latter two are just entry points for drivers and by definition OS specific, the former is just an entry that you must be able to list and identify. Symlinks are a bit of a problem, since they are automatically dereferenced. But if you don't support them yet, then don't support them yet. Bear in mind, however, that Windows has had symlinks in the form of junctions since Windows 2000 (and in the form of actual symlinks since Windows Vista), so this is not a UNIX-only feature.

Another thing I'm struggling with is the concept of "Everything is a file."

An oft-misunderstood adage. More importantly, everything is a file descriptor. FDs are the handles you use to talk to a resource, and they already have very nice properties that you would have to recreate when making a bespoke object type. They automatically have life-cycle management (all FDs are closed at the end of the process, no matter how the process died). You can send them through UNIX domain sockets, or bestow them to child processes using fork() and on and on. You have access control using normal administrative means. In UNIX, an FD is a capability: If you have it, you can access the resource it represents.

Sure the file interface like read() and write() is a poor fit for most devices (e.g. it doesn't make sense for the RTC), but that is what ioctl() is for.

[Clover5411]

Thanks for your reply, nullplan!

What if I try to use non-ASCII characters to a filesystem that doesn't support them? What if I try to create hard links in a filesystem that doesn't support them? What if I try to make hidden files in a filesystem that doesn't support them? My best idea for now is this; let the VFS pass the request regardless, and let the driver return an error if it's not possible.

That is pretty much exactly what Linux does. The VFS filters requests that will never make sense, but otherwise forward all requests to the FS drivers, and then those can reject according to ability.

I see. Thanks a lot! Now I have a bit more confidence

What if the user mounts a filesystem that does allow semicolons in filenames? How am I supposed to deal with those?

Ooh boy, that is exactly the kind of fun you can have in Linux with a FAT file system. FAT allows the forward slash in file names, although Microsoft has been discouraging its use of late. There is at least one type of digital camera that creates file names with forward slashes in them. If you mount their memory cards in Linux, you will get nonsensical read-outs. In Linux, the forward slash is always the directory separator. There is absolutely no way around that. So, the files will exist when you read out the directories, but you can't access them.

ohnoes! I didn't know about this. Thankfully I've never been in this situation before, and I would never want to be. Even thinking about it is scary

The only solution there is to have a program that bypasses the VFS and corrects the faulty file names, such as dosfsck. This seems to be the only way.

Fundamentally, in your OS, you can only decide to either show the file names that can't be accessed, or not show them. The former has the advantage that users will see earlier that something weird is happening. You list a directory and the file mode for some files shows up as question marks. That tends to get noticed.

I feel like I would not even prefer to mount the filesystem at all. Or at least, make sure the user reads a warning prompt before confirming to continue.

I might be able to support any UTF-8 character, but what about all sorts of special files? Hard-linked directories? File tags?

What special files do you mean? The typical UNIX ones? In that case, we're talking about sockets, symlinks, character specials, and block specials. The latter two are just entry points for drivers and by definition OS specific, the former is just an entry that you must be able to list and identify. Symlinks are a bit of a problem, since they are automatically dereferenced. But if you don't support them yet, then don't support them yet. Bear in mind, however, that Windows has had symlinks in the form of junctions since Windows 2000 (and in the form of actual symlinks since Windows Vista), so this is not a UNIX-only feature.

Not necessarily just the UNIX ones. Though, I don't know if it's even worth the hassle to support any non-Windows and non-UNIX special files that may exist out there.

Another thing I'm struggling with is the concept of "Everything is a file."

An oft-misunderstood adage. More importantly, everything is a file descriptor. FDs are the handles you use to talk to a resource, and they already have very nice properties that you would have to recreate when making a bespoke object type. They automatically have life-cycle management (all FDs are closed at the end of the process, no matter how the process died). You can send them through UNIX domain sockets, or bestow them to child processes using fork() and on and on. You have access control using normal administrative means. In UNIX, an FD is a capability: If you have it, you can access the resource it represents.

Sure the file interface like read() and write() is a poor fit for most devices (e.g. it doesn't make sense for the RTC), but that is what ioctl() is for.

I see, I think I understand the concept better now. I remember reading something about ioctl() being bad, but I can't find it, and I don't know how true this is. What are your thoughts over this?

On a related note, what if the basic file functions such as reading and writing were done through ioctl()? Would that have benefits/drawbacks?

[nullplan]

I feel like I would not even prefer to mount the filesystem at all. Or at least, make sure the user reads a warning prompt before confirming to continue.

That would require you to first check all file names on the medium for validity. Depending on medium size, that may take a while. You would be penalizing many users for the actions of a few.

I remember reading something about ioctl() being bad, but I can't find it, and I don't know how true this is. What are your thoughts over this?

ioctl() is an awful hack, but I haven't found anything that can beat it for sheer versatility. The main problem with ioctl() is that that it is a type-unsafe interface. It is defined as

Code: Select all

int ioctl(int fd, unsigned int request, ...)

The ellipsis is filled with a single argument, and that has to fit the request. Oh yes, also there is a war going on about the type of the second argument. POSIX says it's int, Linux source code says it's unsigned int, but the Linux manpage says it's unsigned long. Have fun picking. Although POSIX' choice for type and Linux' choice for the construction of the request constants means that many requests overflow the 31-bit value range, causing warnings.

But there is nothing quite as expedient as it for changing specific attributes of device files. There is an ioctl for changing the window size of a terminal. What alternatives would there be? Possibly something like a /sys pseudo-file, but that means you now have to figure out exactly what terminal an FD is connected to. And how would you do that? On Linux, the ioctl for getting the window size is often used to figure out if an FD is connected to a terminal. The request fails for anything that isn't a terminal.

Now, the alternative is to create bespoke system calls instead of ioctls. However, typically you want to keep the number of syscalls small. For something like terminal requests, it would probably be reasonable to do that, but for all of the drivers? There is an ioctl for sending raw SCSI requests to SCSI devices (even when they are exposed through USB MSC). There is an ioctl to read out RTCs. There is an ioctl to send multiple streams of data to a sound card. If you turn all of these into system calls, you end up with thousands of calls. You also reduce versatility of new interfaces. If a new kind of device driver comes along, you must first add new system calls to do anything with it. The entire Linux I2C stack is implemented as ioctls.

There has been abuse of ioctl in the past. Stuff like setting the IP address through an ioctl (on any socket). That is pretty awful, and something I will try to not repeat. That can legitimately be done with /sys pseudo-files.

In the end, the type-safety problem can be alleviated somewhat by wrapper functions. Something like tcgetattr(), which is implemented in terms of ioctl(), but has explicit types.

On a related note, what if the basic file functions such as reading and writing were done through ioctl()? Would that have benefits/drawbacks?

ioctl is really meant for exchanging small amounts of information with the kernel. In particular, fixed size amounts of data. The window size structure for the terminal is always going to have the same size. Reading and writing, on the other hand, will always exchange variable-length data. You could make the third argument something like a pointer to an iovec, yes, but that adds one more layer of indirection for no reason. So yes, it could be done, but I don't see it as worthwhile.

[Clover5411]

Thanks a lot for the detailed explanation, nullplan! I really appreciate it!

I suppose Marionumber1's system as described in the topic I mentioned before could be considered a type-safe ioctl(). So in this case, I would have three options.

• Come up with a type-safe ioctl-like interface, probably very similar to Marionumber1's system.
• Do the same thing Linux does, and hope it won't turn into a mess.
• Give up on putting everything into one namespace entirely; and have separate domain-specific capability systems.

My instincts tell me to go with number 1, but it also sounds quite complex. I'll have to think about this a bit more.

[rdos]

Anyway, the namespace construction shouldn't matter when you design the VFS. The VFS in both Windows & Linux needs to deal with partitions of different types, so this is what you need to consider in the design. Not how partitions are linked in namespace.

First of all, thanks for your reply. And yeah, that's another thing I'm thinking about. Passing the requests to relevant filesystem drivers is easy enough, but filesystems differ in their abilities. What if I try to use non-ASCII characters to a filesystem that doesn't support them? What if I try to create hard links in a filesystem that doesn't support them? What if I try to make hidden files in a filesystem that doesn't support them? My best idea for now is this; let the VFS pass the request regardless, and let the driver return an error if it's not possible.

I think this can be solved in two different ways. Some things the OS will not support at all. For instance, I will not support access control, and I use UTF-8 for pathnames. If this is not supported by the filesystem, then some files might not be possible to access. On the filesystem side, the driver can decide to compensate for issues (like converting between character sets, ignoring attributes or fail the the request).

Another thing I'm unsure about is what do I do if a mounted filesystem supports something that my VFS doesn't? For example, let's presume that a semicolon is considered a special character for my VFS, as such, it's not allowed in filenames. What if the user mounts a filesystem that does allow semicolons in filenames? How am I supposed to deal with those?

Parsing within the filesystem should be done in the filesystem driver. IOW, you pass part of the pathname through to the VFS and then let the filesystem parse it's part of it. This means that if the filesystem supports semicolon in flenames, the file can be found.

I will try to make the filesystem as generic as possible, but ultimately, I don't think I can support everything there is. I might be able to support any UTF-8 character, but what about all sorts of special files? Hard-linked directories? File tags? What if there's a filesystem out there that uses a completely different way to identify files, rather than just naming them? At that point, I'm willing to throw in the towel and say "My VFS doesn't support that." Besides the users can still use special programs to access such systems. But even the idea of making a VFS that's generic enough to support all the popular filesystems seems daunting enough.

I think the filesystem driver should try it's best to work with the requests it gets, and only fail when this is impossible. Failing for trivial reasons is not user-friendly.

[rdos]

Ooh boy, that is exactly the kind of fun you can have in Linux with a FAT file system. FAT allows the forward slash in file names, although Microsoft has been discouraging its use of late. There is at least one type of digital camera that creates file names with forward slashes in them. If you mount their memory cards in Linux, you will get nonsensical read-outs. In Linux, the forward slash is always the directory separator. There is absolutely no way around that. So, the files will exist when you read out the directories, but you can't access them.

I'd attribute that to poor design of the Linux VFS. The FAT driver should be able to handle forward slash as part of a filename, and parsing of pathnames should not be done by VFS, rather by the relevant filesystem driver.

In my design, I use both / and \ as separators, and so pathnames with / will not create files with / in them.

Another thing I'm struggling with is the concept of "Everything is a file."

An oft-misunderstood adage. More importantly, everything is a file descriptor. FDs are the handles you use to talk to a resource, and they already have very nice properties that you would have to recreate when making a bespoke object type.

To use descriptors (or handles as I call them) for objects in the kernel is a good design, but that doesn't mean handles only have one type (an FD). My handles are typed, and if you open a socket you cannot use the handle to write to a file. Each handle has a set of syscalls associated with it, and a C++ class to document which syscalls are supported. I typically will use the class interface rather than the syscalls.

They automatically have life-cycle management (all FDs are closed at the end of the process, no matter how the process died). You can send them through UNIX domain sockets, or bestow them to child processes using fork() and on and on. You have access control using normal administrative means. In UNIX, an FD is a capability: If you have it, you can access the resource it represents.

So do I. Each handle type has it's own "destructor" in kernel that frees the object when an application exists.

[rdos]

ioctl() is an awful hack, but I haven't found anything that can beat it for sheer versatility.

I'll agree that it is an awful hack, but disagree on it's versatility. I've not yet found any reason to implement ioctl.

The main problem with ioctl() is that that it is a type-unsafe interface.

No, the main problem is that people can create undocumented & unportable interfaces between applications & the driver.

Now, the alternative is to create bespoke system calls instead of ioctls. However, typically you want to keep the number of syscalls small. For something like terminal requests, it would probably be reasonable to do that, but for all of the drivers? There is an ioctl for sending raw SCSI requests to SCSI devices (even when they are exposed through USB MSC). There is an ioctl to read out RTCs. There is an ioctl to send multiple streams of data to a sound card. If you turn all of these into system calls, you end up with thousands of calls. You also reduce versatility of new interfaces. If a new kind of device driver comes along, you must first add new system calls to do anything with it. The entire Linux I2C stack is implemented as ioctls.

Why is there a need to keep number of syscalls small? Syscalls provide excellent documentation of the interface between applications and the kernel, while ioctl and special device names create undocumented "features".

[thewrongchristian]

What if the user mounts a filesystem that does allow semicolons in filenames? How am I supposed to deal with those?

Ooh boy, that is exactly the kind of fun you can have in Linux with a FAT file system. FAT allows the forward slash in file names, although Microsoft has been discouraging its use of late. There is at least one type of digital camera that creates file names with forward slashes in them. If you mount their memory cards in Linux, you will get nonsensical read-outs. In Linux, the forward slash is always the directory separator. There is absolutely no way around that. So, the files will exist when you read out the directories, but you can't access them.

That camera is creating invalid file names, in that case. Slash is explicitly a reserved character in DOS/Windows, and slash is NOT allowed in a FAT or NTFS file name.

Naming Files, Paths, and Namespaces

[AndrewAPrice]

I'm doing something similar in my OS. E.g.

/Application/ links to the currently running application's directory
/Applications/ links to all applications from all disks.
/Libraries/ links to all libraries found all on disks.
/Optical 1/ is the first optical drive, etc.

[eekee]

I'm doing something similar in my OS. E.g.

/Application/ links to the currently running application's directory
/Applications/ links to all applications from all disks.
/Libraries/ links to all libraries found all on disks.
/Optical 1/ is the first optical drive, etc.

Plan 9's window system does something similar, mounting files for the current window on /dev . It uses this to multiplex the window files, mouse console and in 9front, keyb. However, it's a bad implementation in my opinion. Being entirely in user-space, it uses private namespaces to make different processes see different files. Plan 9's private namespace have a strict parent-child inheritance scheme. This means that if you mount a filesystem in one window, none of the other windows can see it.

On the subject of strange characters in filenames, yesterday I saw some DOS driver had an option to translate spaces to _ . It's more common at higher level. Mac OS X GUI allows / but not : in filenames. If you list the files in Terminal, you'll see the slashes replaced by colons. Inferno OS has trfs, an overlay filesystem which can translate any character to any other with a command-line syntax much like Unix tr . But neither of these could deal with an actual / in a filename on disk.

[bellezzasolo]

ioctl() is an awful hack, but I haven't found anything that can beat it for sheer versatility.

I'll agree that it is an awful hack, but disagree on it's versatility. I've not yet found any reason to implement ioctl.

The main problem with ioctl() is that that it is a type-unsafe interface.

No, the main problem is that people can create undocumented & unportable interfaces between applications & the driver.

Now, the alternative is to create bespoke system calls instead of ioctls. However, typically you want to keep the number of syscalls small. For something like terminal requests, it would probably be reasonable to do that, but for all of the drivers? There is an ioctl for sending raw SCSI requests to SCSI devices (even when they are exposed through USB MSC). There is an ioctl to read out RTCs. There is an ioctl to send multiple streams of data to a sound card. If you turn all of these into system calls, you end up with thousands of calls. You also reduce versatility of new interfaces. If a new kind of device driver comes along, you must first add new system calls to do anything with it. The entire Linux I2C stack is implemented as ioctls.

Why is there a need to keep number of syscalls small? Syscalls provide excellent documentation of the interface between applications and the kernel, while ioctl and special device names create undocumented "features".

My main concern with making everything a syscall is that you then need an update to the kernel to support some new feature. In particular, if you think of an industrial setting, it's quite legitimate to have a bespoke application communicating with a bespoke driver for e.g. centrifuges.

Ioctl is versatile - just look at the capability of libusb to write support for bespoke USB devices in userspace. Of course, it's an ugly hack.

What wouldn't be such an ugly hack would be supporting something akin to COM in kernel space. Indeed, a Nano-COM approach is used with Direct3D these days, where you call a single function to get a pointer to an interface (with a stable ABI), on which you can call functions, QueryInterface() for extended features...

Plumbing COM across the kernel/user boundary is an interesting proposition, but should be entirely plausible considering the existence of DCOM, and the result would be an object oriented API.

[rdos]

My main concern with making everything a syscall is that you then need an update to the kernel to support some new feature.

Not in my design. I don't link a huge kernel, rather the bulk of syscalls are implemented in separately linked device drivers. So, if I need a new function, I can add a new device driver and include it in the script used to create the OS binary.

In particular, if you think of an industrial setting, it's quite legitimate to have a bespoke application communicating with a bespoke driver for e.g. centrifuges.

Then you just do a custom device driver that exports the API, add it to the list of drivers, and then let the application use the new device driver syscalls.

Ioctl is versatile - just look at the capability of libusb to write support for bespoke USB devices in userspace. Of course, it's an ugly hack.

It's possible to export an USB API so USB devices can be handled solely in userspace. I have this, but currently only use it for some strange HID hacks.

What wouldn't be such an ugly hack would be supporting something akin to COM in kernel space. Indeed, a Nano-COM approach is used with Direct3D these days, where you call a single function to get a pointer to an interface (with a stable ABI), on which you can call functions, QueryInterface() for extended features...

Plumbing COM across the kernel/user boundary is an interesting proposition, but should be entirely plausible considering the existence of DCOM, and the result would be an object oriented API.

I think that is ok, but you shouldn't export class structures between kernel & userspace. Handles are a kind of object reference, and in my design, operate a bit like objects. I have some 20 different handle types that maps closely to userspace classes. In my classlib, I actually provide C++ classes for userspace to make the OO integration better. However, the syscall interface use a handle to identify the kernel object, and then pass parameters in registers. The userspace object pointer is not sent to kernel space since it easily changes and becomes incompatible.

This way of implementing an OO interface has some definite advantages. It particularly enforces encapsulation since userspace doesn't have access to internal object fields, and these can only be updated with proper methods through syscalls.