merging SSC	Hrs	not merging SSC	Hrs	
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:
a)	we do the right hand column, and then immediately throw it away (perhaps after some testing) and then do the left hand column, OR
b)	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).