User Tools

Site Tools


wishlist:david

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
Last revision Both sides next revision
wishlist:david [2016/06/23 15:42]
dcvmoole add item about redesigning the DS pub/sub API
wishlist:david [2017/04/09 12:28]
dcvmoole another new todo item
Line 177: Line 177:
   * note: libsys should probably have a DS notification dispatcher, possibly as part of SEF   * note: libsys should probably have a DS notification dispatcher, possibly as part of SEF
   * note: this probably a good time to introduce a system-wide constant for service label sizes   * note: this probably a good time to introduce a system-wide constant for service label sizes
 +
 +=== Make the MIB service'​s RMIB calls asynchronous ===
 +
 +  * reason: a RMIB call to a deadlocked service may currently deadlock MIB, and with that the entire system
 +  * complication:​ this may or may not require the MIB service to sign up for PM process events
 +  * note: this depends on RMIB being notified about service deaths through DS, rather than via ipc_sendrec()
 +
 +=== Extend RMIB functionality/​robustness to match service requirements ===
 +
 +  * problem: it is not possible to modify (= bump the version number of) already-mounted RMIB subtrees (e.g., net.interface)
 +  * problem: it is not possible to mount RMIB subtrees using a name only (e.g. minix.lwip)
 +  * problem: it is currently possible to mess up the MIB tree with bad name+id combos in RMIB mount requests
 +
 +=== Disallow killing processes in an uninterruptible system call ===
 +
 +  * reason: processes may currently be terminated while in an uninterruptible system call, possibly triggering poorly-tested scenarios in other services (safecopy failures, etc)
 +  * complication:​ this will require changes to the PM signal state machine, with subtle side effects
 +  * complication:​ involving all user-facing system services in exit notification is a performance problem
 +  * note: the most obvious solution would be kernel support for notification (to PM) when a process system call has completed, comparable to SIGNDELAY, and a PREEXIT process state in PM
 +  * note: ideally the same idea would be applied to signal handler invocation, because the current approach makes dangerous and already-incorrect(?​) assumptions about "​retreg"​ there
 +
 +=== Add support for pselect(2) ===
 +
 +  * reason: pselect(2) is required by dhcpcd(8) and various other parts of userland
 +  * complication:​ pselect(2) is supposed to be atomic and thus cannot be implemented as a select(2) wrapper
 +  * complication:​ a proper implementation will require a non-trivial extension to the PM/VFS protocol
 +  * subsequent project: also implement paccept(2); this will require storing more call state in VFS
  
 === Move the BSD socket API into VFS === === Move the BSD socket API into VFS ===
  
-  * status: **IN PROGRESS**+  * status: **PULL REQUEST FILED**
   * reason: libc should not need to test or track socket types, it violates the light-libc minix philosophy   * reason: libc should not need to test or track socket types, it violates the light-libc minix philosophy
   * reason: the individual writes to implement sendto (etc) probably violate posix signal atomicity   * reason: the individual writes to implement sendto (etc) probably violate posix signal atomicity
wishlist/david.txt · Last modified: 2017/10/11 18:13 by dcvmoole