{| class="prettytable"
| <center>'''merging SSC'''</center>
| <center>'''Hrs'''</center>
| <center>'''not merging SSC'''</center>
| <center>'''Hrs'''</center>

|-
| lot of work to vs-ipmd.c and ipmd-lib
| 
| also a lot of work, but different, so would have to be done twice
| 

|-
| removal of mgmt-bus code and conversion of everything that depends on it
| 
| a new user space daemon has to be written to handle all messages coming from SSC, and implement either a pass to the kernel code or implement the required action itself. think of several of the mgmt daemons that exist now combinded together into one, non-stupid, daemon.
| 

|-
| convert mgmt daemons/libs to communicate directly with kernel – possibly just a change to RMC?
| 
| then that has to be thrown away for a merged ssc product
| 

|-
| implementation of resource constraining scheme to keep runaway user space daemons from killing the system like they kill the ssc today

* kernel thread priorities v. user threads

memory allocation constraints on mgmt daemons
| 
| 
| 

|-
| neteee code has to be converted to be essentially 'localhost' equivalent
| 
| 
| 

|-
| integration impact
| 
| Integration impact
| 

|}
Note that the left hand column has to be done '''anyway''' for an x86 outcome.


What that means is that the decision boils down to this:

# we do the right hand column, and then immediately throw it away (perhaps after some testing) and then do the left hand column, OR

we skip the right hand column and just do the left hand column.


It's been said there's risk in doing (b), but actually I believe there isn't, because the time saved by doing (b) pays for itself, for even if everything blows up and it takes longer than we want, it won't take longer than (a).