xenia-project/xenia

[Code style] Inconsistent kernel notification ID usage

Open

#1852 opened on Jun 26, 2021

View on GitHub
 (1 comment) (0 reactions) (0 assignees)C++ (7,418 stars) (1,077 forks)batch import
good first issuekernel

Description

In Xenia, there are two kinds of declarations of kernel notification IDs:

  • System notifications IDs are used simply as hard-written values, without any enum/consts/#defines, with merely comments indicating their original XN_SYS name.
  • XAM apps (such as XmpApp) have notification IDs declared in their classes, as private static const uint32_t kMsg….

For future convenience especially when we start running the original app executables, we need to clean this up, probably as some kind of an enum with nice k-prefixed names.

We can use one of the two approaches:

  • An enum class XNotificationID containing both system and app notification IDs.
  • A typedef uint32_t XNotificationID, and separate enums for system notifications (declared globally) and for each app (in their headers).

In my opinion, the former is preferable, as if we start running the original XAM apps, it's possible that we won't have our own classes for a subset of them. As each apparently has its own index in the upper bits, there should likely be no collisions, and there's natural namespacing. Also, if I understand correctly, notifications are used for inter-app communication, so conceptually they shouldn't be private. Plus, type safety is somewhat better with an enum class.

Contributor guide