4 ms·
Some neat ideas, but > As long as the OS stays compatible with the old stuff in the context, it can add new functionalities for other App by just appending to
by danhau 3y ago
Some neat ideas, but
> As long as the OS stays compatible with the old stuff in the context, it can add new functionalities for other App by just appending to the context the new functions
Welcome to backwards compatibility hell. You're boxing yourself in this way because you're forbidding yourself to remove old / defunct entries from the Context struct.
I think a better approach would be to introduce some kind of semantic versioning between OS and app. The app declares, somehow, what version of the OS it was built against or depends on. The OS then can check if the app is compatible and can pass a version of the Context struct that fits. This doesn't get rid of most backwards compatibility problems, but you keep the Context struct clean by effectively having multiple structs in the kernel, one for each major / minor version.
- Ruddle 3y agoAuthor here, that's a neat idea. However I also like the simplicity in having only one runtime interface. If the OS has to handle every version anyway, an app in the future could just use padding to feel like it is "clean". struct Context{ padding: [u8;256], // old stuff ctx: ContextV42 } Just typing that felt a bit wrong though. On the other hand the app declaring what version it is feels like what executable formats (like elf) already solve. I am trying alternatives.