Redesigning KObject

[roblabla]

Right now, both copy and move handles have the same "KObject" type in the SwIPC definitions. This type is extremely vague: not only does it not specify the kind of handle it represents, it isn't enough information to know if it's a move or a copy handle.

Right now, SwIPC uses object for two different things (that share the same IPC message). It represents a moved handle that can either be casted to a kind of kernel handle (NPort, IPipe) or to a service (which is a special-case of IPipe). While it's certainly not wrong at the IPC marshalling level, it makes it hard on the IPC codegen to differentiate the two (we don't necessarily want to return the same types depending of the kind of handle returned).

As such, I'm interested in changing KObject a little. I'm thinking of renaming KObject to KHandle to be closer to the kernel terminology, and give it two template arguments:

• The first specifies if it is a copy or a move object. KHandle<copy> is a copy handle, KHandle<move> is a move handle
• The second specifies the kind of handle.
  • KHandle<_, process> is a process handle. You may pass 0xffff8001
  • KHandle<_, thread> is a thread handle. You may pass 0xffff8000
  • KHandle<_, transfer_memory> is a transfer memory handle.
  • KHandle<_, shared_memory> is a shared memory handle.
  • KHandle<_, port> is a port handle
  • KHandle<_, session> is a session handle
  • KHandle<_, event> is an event handle ?

An object is the same as a KHandle<move, session> as far as the IPC marshalling is concerned, but is additionally given an interface type that the returned session conforms to.

[misson20000]

Probably a copy/paste error but want to make sure it's understood that transfer memory != shared memory. Also, object != KHandle<move, session> in the case of object domains

[roblabla]

Yup, totally a copy pasta error. And I'm still super unclear on how an object domain works, so thanks for the correction :).

Do you have any IPC off the top of your head that return objects as domains instead of sessions ?

[roblabla]

Currently working on this issue, as it is going to be required for my Rust code generator in Megaton Hammer (want to make it as safe as possible).

@hthh In generated_diff (the raw one, not the SDK one), you have "inhandles" and "outhandles", an array of either 1 or 2 - where almost everything uses 1 except the HIPCInterfaces and one method of IProcessManagerInterface, at least on 1.0.0. Here's an example: (careful, this might lag your browser, it's a huge page) https://gist.github.com/hthh/bb896c743878a2c0c337f41febdc0426#file-data1-py-L134.

Am I right that 1 means move handle and 2 means copy handle ? If that's the case, it means I have almost everything I need in there.

[roblabla]

I'm doing some more work on SwIPC for KFS. Here's the full list of handles we need to have AFAIK:

khandleType = { "process" | "thread" | "debug"
              | "code_memory" | "transfer_memory" | "shared_memory"
              | "server_port" | "client_port"
              | "server_session" | "client_session"
              | "server_light_session" | "client_light_session"
              | "readable_event" | "writable_event" | "irq_event"
              | "device_address_space"
}