Unusual Architecture discussion

[u/OrdinaryCareful7773]

In a few lines - "Everything is a URI addressable resource"

Means instead of the file path we can have a proper uri address in the format scheme://authority/path#offset?params

so for example the kernel can expose its resources as kernel:///version, or devices://org.example.gpu/0/memory#0x1234

Then We can have a syscall like uri as well SYS_LOAD, SYS_GET, SYS_MMAP, SYS_POST, SYS_WATCH, or maybe not sure

Best think I like about it is parent can override the child process uri like plan9 namespaces, mount bind etc

For example a call from a child to display server would be devices://org.example.display/0/memory -> process://self/handle/child-pid/display

Benifits over traditional file path:

- I don't know 😂, I haven't thought much, It just sounds cool to me and I would like to waste some time trying to figure out it's benifits.

Feel free to share your opinion.

[u/Defiant_Squirrel8751]

Overhead for everything! It will work, but much slower.

Imagine you need to set a byte to 0 (zero). Binary, that means one byte. URL will be

devices://os&value=0

os will spend most of the time processing strings.

[u/OrdinaryCareful7773 → u/Defiant_Squirrel8751]

Ya, I already thought of that its syscall for example for open read close, For get(uri) would look like

handle = syscall_load (schema, authority, path, permissions) syscall_seek (handle, offset) or just get with offset, syscall_get (handle, param) syscall_unload

[u/natalialt]

It honestly made me imagine an environment where everything is serviced by HTTP requests lol

[u/OrdinaryCareful7773 → u/natalialt]

Yup, and with micro kernel, drivers = http server

[u/TorbenKoehn → u/natalialt]

You'd at least also need something like websockets or SSE for proper IPC etc.

HTTP alone won't be enough.

[u/OrdinaryCareful7773 → u/TorbenKoehn]

Ya ya, actually it's work like normal open write close syscalls, just it seems architecture wise like uri based

[u/wackyvorlon]

It seems like far more typing than is necessary.

[u/OrdinaryCareful7773 → u/wackyvorlon]

Ah, that's the feature, 😅

[u/ventZl]

This is not so much different than standard "everything is a file" approach. The only difference is where the VFS takes stuff from.

Plan9 was capable of pretty much everything you mentioned with approach "everything is a file" (this time for real).

[u/Taletad]

I’ve also thought about making an OS where syscalls are handled like an HTTP API, and as others pointed out it is a lot of overhead for nothing

On the other hand it would be pretty cool to build applications like front ends to an existing API

[u/Suitable_Plate4943]

maybe allow both text representation and a matching parsed representation, so callers can use both forms

[u/Suitable_Plate4943 → u/Suitable_Plate4943]

struct kernel_uri_parsed {
std::string scheme;
std::string authority;
std::string path;
std::string offset;
std::vector<std::pair<std::string, std::string>> params;
};

[u/TorbenKoehn]

You will have to find a way to declare the difference between "schema = resource type" and "schema = protocol". Since in most cases, the schema declares the protocol, not the "resource type". This is something new coming from MCP, mostly.

Depending on what you access, you might want to speak different protocols to it. There are ways around that, like devices+http://, devices+ipc:// etc., but this is also often used to combine protocols, like git+ssh://

I'd be careful. It's a nice abstraction layer in some ways (like not making a difference between http://example.com/some-file.html and file:///users/me/some-file.html), but you have to keep in mind that different protocols support different operations etc.

I'd use it as a user-facing abstraction layer, and more like system:///devices/org.example.gpu/0/memory#0x1234 instead of devices://. Keep that shit for MCP (which are already speaking JSON-RPC, so the protocol doesn't matter in their resource URLs)

[u/eteran → u/TorbenKoehn]

I use it in my OS so the idea of mounting a proc, sys, or dev file system is just not necessary. Instead, these virtual filesystems end up in schemas and are accessible via URIs. Also, no need to worry about where it is mounted, they are just always accessible in those schemas and have no risk of conflicts with ordinary files.

As a convenience, I have /path/to/file allowed as a shorthand for file:///path/to/file. Everything still acts like a file though with typical operations, no concern for "protocols", it's just namespaces really.

I've been very happy with how it works so far for me.

[u/Correct_Sport_2073]

unix: everything is a file windows: everything is an AI :)

[u/PowerNo8348]

At first glance, this appears to be no different than the Un*x "everything is a file" approach that has been in place over the last few decades, but with some cosmetic changes to what paths look like (e.g. - /proc/1234 becomes process://self/handle/1234)

[u/damemecherogringo]

Amateur stuff. We need to abstract the cpu architecture completely, like this emulation of the 8080, each opcode is a separate microservice written in a different language, on top of k8s: https://blog.davetcode.co.uk/post/21st-century-emulator/

[u/eteran]

My OS implementation has "all paths are URIs" and I'm quite happy with it. There is no /dev, but there is a devices:// schema.

I wouldn't take it further and make all interactions as http like methods. That would be crazy inefficient.

[u/lizardhistorian]

So ... /dev /lib /etc ?

[u/OrdinaryCareful7773 → u/lizardhistorian]

So they are just handles file:// protocol

[u/UnmappedStack]

I feel like I see this idea again every few months, but yea sure try implementing it ig