Rename posix to more generic name

[rhelmot]

As angr grows to emulate more environments, we need to genericize the ability for a program to interact with its environment.

Two options:

• rename posix to supervisor and allow the plugin to implement its own logic for the things like file read/write, the program break, etc
• rename posix to environment and move all the logic into syscallls, making the plugin a pure storage mechanism. This would involve making library functions that currently call directly into posix for syscall functionality instead of performing a syscall directly, something that I would kind of like to happen anyway.

other options would be appreciated :)

[ltfish]

Why not breaking supervisor into filesystem, networking, etc.?

[zardus]

I'm not sure if it makes much sense to separate filesystem and networking (in terms of sockets and so forth), but I'm also not a big fan of supervisor and environment. What about os or system?

[ltfish]

@zardus There are some systems that model file systems and networks differently. Personally I prefer to have them separate.

[schieb]

@zardus What in particular do you dislike about the two options in the OP and how would os and system be different? Or perhaps you just disliked the names?

[rhelmot]

Additional consideration for a name would be system, I would guess that at some point in angr's development this was the goal, since the class of the de-facto posix plugin is SimSystemPosix

[rhelmot]

Though my preference remains environment -- it works better even in the cases where you're emulating e.g. a kernel, or some firmware. We're interested in storing data about that which exists outside our analysis context, the environment in which this program lives.

[ltfish]

If we go with environment, under which there are filesystem, networking, and other stuff, it might be difficult for users to replace individual components with their own implementation (since filesystem and networking and such are not state plugins anymore, but rather "environment plugins"). What do you think?

[rhelmot]

If we go for environment, then the logic for handling all those individual components will be removed from environment and pushed into syscalls. Users looking to customize environment-handling would do so on a syscall basis, so we would also want to improve our interface for hooking or replacing syscalls. Do you forsee any usability problems with that approach?

[ltfish]

the logic for handling all those individual components will be removed from environment and pushed into syscalls.

Does that prevent us from reusing code (e.g. file system logics) between different platforms, like between Linux and Windows?