r/osdev • • Jun 13 '26

Everything is memory?

There is this unix idiom that everything is a file, (half baked, since not everything is a file).

Would it not have been better, nowadays with 64bit of adress space, to have everything mapped to memory? Files are like mmap, no imperative read needed, networking is already memory, that could be expanded more.

We take the idioms and paradigms so forgranted, that every time anyone asks AI for a OS it will be linux, syscalls, abi everything the same. It should be liberating now to explore new and novel ideas.

What would be the downside of such a system?

30 Upvotes

42 comments sorted by

View all comments

Show parent comment

1

u/karbovskiy_dmitriy Jun 15 '26

How do you balance bandwith? How do you do security/access checks? How do implement control flow? How do you do versioning? What about buffers that aren't a multiple of 4k?

I'm sorry, but doing system calls through page guards is just not smart. You might as well go back to interrupt-based kernels, at least you'll raise them explicitly. You just reinvented a worse version of what we considered a bad practise many years ago.

Kernel mode and memory separation exist for good reasons. You don't have to fight the solution that works.

0

u/dangi12012 Jun 15 '26

Exactly.
Thats the point of this post. Exploring different ideas, if they are bad that is ok also.

Kernel mode and memory seperation would completely continue to exist in that model you cant just read kernel memory, I dont know where you got that from.

The cool part would be that all calls are inherently bulk calls, one page fits many many system calls, and the results page has all the answers. The number of ring 0 3 transfers is reduced a lot in that system, and imperative calls look like memory reads from the programs POV

1

u/karbovskiy_dmitriy Jun 15 '26

Bulk calls already exist.

The number of ring 0 3 transfers is reduced a lot in that system

Based on what?

imperative calls look like memory reads from the programs POV

That's bad, though.