Log services: Difference between revisions
No edit summary |
|||
| (7 intermediate revisions by 3 users not shown) | |||
| Line 2: | Line 2: | ||
This is "nn::lm::ILogService". | This is "nn::lm::ILogService". | ||
This service is stubbed on retail, with all the commands/interfaces being present but returning success and doing | This service is stubbed on retail, with all the commands/interfaces being present but returning success and doing nothing. | ||
{| class="wikitable" border="1" | {| class="wikitable" border="1" | ||
| Line 51: | Line 51: | ||
|- | |- | ||
| 1 || [3.0.0+] [[#SetDestination]] | | 1 || [3.0.0+] [[#SetDestination]] | ||
|- | |||
| 2 || [20.0.0+] TransmitHashedLog | |||
|- | |||
| 3 || [20.0.0+] DevNotify | |||
|} | |} | ||
| Line 60: | Line 64: | ||
== SetDestination == | == SetDestination == | ||
Takes an input u32 mask value indicating the logging destinations to send incoming log messages to. The mask entries are as follows: | Takes an input u32 mask value indicating the logging destinations to send incoming log messages to. This is stored as a global value. The mask entries are as follows: | ||
{| class="wikitable" border="1" | {| class="wikitable" border="1" | ||
| Line 66: | Line 70: | ||
! Value || Description | ! Value || Description | ||
|- | |- | ||
| 1 || | | 1 || TMA | ||
|- | |||
| 2 || UART | |||
|- | |||
| 4 || UART when sleeping | |||
|- | |- | ||
| | | 0xFFFF || Log to all destinations | ||
|} | |} | ||
| Line 196: | Line 204: | ||
LogManager uses two separate threads: a flushing thread and a htcs thread (main thread is handling both IPC and PM module requests): | LogManager uses two separate threads: a flushing thread and a htcs thread (main thread is handling both IPC and PM module requests): | ||
* The flushing calls Flush() on the "LogBuffer" object, which is the object responsible for flushing logged data though the other objects, and sends a LogPacketDropCount packet via the | * The flushing calls Flush() on the "LogBuffer" object, which is the object responsible for flushing logged data though the other objects, and sends a LogPacketDropCount packet via the EventLogTransmitter object (see below) if there any dropped packets and the flushing succeeds - this is done in a loop, waiting until the process starts finalization. | ||
* The htcs thread continously reads from the server connection, and will close and reopen the client socket if the connection happened to be lost - this is done in a loop, waiting until the process starts finalization. | * The htcs thread continously reads from the server connection, and will close and reopen the client socket if the connection happened to be lost - this is done in a loop, waiting until the process starts finalization. | ||
| Line 209: | Line 217: | ||
* LogServerProxy object - sends log data via HTCS (see [[TMA_services]]) | * LogServerProxy object - sends log data via HTCS (see [[TMA_services]]) | ||
* | * CustomSinkBuffer object - retains log data which can be later retrieved by [[#lm:get]]: | ||
** When processes log via [[#lm]] service, some code analyzes the log packet, locates the TextLog ([[#LogDataChunkKey]]) chunk (if present) and saves it's contents in a global buffer (therefore, only the actual log message gets retained). | ** When processes log via [[#lm]] service, some code analyzes the log packet, locates the TextLog ([[#LogDataChunkKey]]) chunk (if present) and saves it's contents in a global buffer (therefore, only the actual log message gets retained). | ||
** Log packets are only analyzed/retained after enabling it (by calling [[#StartLogging]]), and the [[#GetLog]] command just reads data from the global buffer. | ** Log packets are only analyzed/retained after enabling it (by calling [[#StartLogging]]), and the [[#GetLog]] command just reads data from the global buffer. | ||
| Line 218: | Line 226: | ||
** When an [[#ILogger]] gets created, this object will send a packet containing the logger's process ID and a LogSessionBegin chunk, telling the remote connection that a new process has started logging. Analogously, when the logger gets destroyed, a simple packet with the process ID and a LogSessionEnd chunk gets sent, telling the remote connection that the process has stopped logging. | ** When an [[#ILogger]] gets created, this object will send a packet containing the logger's process ID and a LogSessionBegin chunk, telling the remote connection that a new process has started logging. Analogously, when the logger gets destroyed, a simple packet with the process ID and a LogSessionEnd chunk gets sent, telling the remote connection that the process has stopped logging. | ||
** As mentioned above, the flush thread will tell this object to send a simple packet with a LogPacketDropCount chunk after flushing succeeds (and if there any dropped packets). | ** As mentioned above, the flush thread will tell this object to send a simple packet with a LogPacketDropCount chunk after flushing succeeds (and if there any dropped packets). | ||
** These event log packets are logged via the LogBuffer object, like process logs, but they are not analized by the | ** These event log packets are logged via the LogBuffer object, like process logs, but they are not analized by the CustomSinkBuffer object since they have no text to be saved. | ||
* LogBuffer object - responsible for flushing log packets: | * LogBuffer object - responsible for flushing log packets: | ||