393db1e792
A bip-buffer is good for producer/consumer systems, but ideally logs will stay in the buffer until they're ousted because they need to be overwritten. Now they're a regular ring buffer and every entry has an incremental id. Consumers pass in the last id they've seen, and will get the next log in the sequence.
42 lines
1.5 KiB
Modula-2
42 lines
1.5 KiB
Modula-2
# The system object represents a handle to kernel functionality
|
|
# needed by drivers and other priviledged services
|
|
object system : object {
|
|
uid fa72506a2cf71a30
|
|
|
|
capabilities [
|
|
get_log
|
|
bind_irq
|
|
map_phys
|
|
change_iopl
|
|
]
|
|
|
|
# Get the next log line from the kernel log
|
|
method get_log [cap:get_log] {
|
|
param seen uint64 # Last seen log id
|
|
param buffer buffer [out zero_ok] # Buffer for the log message data structure
|
|
}
|
|
|
|
# Ask the kernel to send this process messages whenever
|
|
# the given IRQ fires
|
|
method bind_irq [cap:bind_irq] {
|
|
param dest ref event # Event object that will receive messages
|
|
param irq uint # IRQ number to bind
|
|
param signal uint # Signal number on the event to bind to
|
|
}
|
|
|
|
# Create a VMA and map an area of physical memory into it,
|
|
# also mapping that VMA into the current process
|
|
method map_phys [cap:map_phys] {
|
|
param area ref vma [out] # Receives a handle to the VMA created
|
|
param phys address # The physical address of the area
|
|
param size size # Size of the area, in bytes
|
|
param flags uint32 # Flags to apply to the created VMA
|
|
}
|
|
|
|
# Request the kernel change the IOPL for this process. The only values
|
|
# that make sense are 0 and 3.
|
|
method request_iopl [cap:change_iopl] {
|
|
param iopl uint # The IOPL to set for this process
|
|
}
|
|
}
|