Re: warning of pending commit attempt.

Bruce M. Simpson wrote:
> Julian Elischer wrote:
>>
>> what do we gain?
>>  Jail on steroids
>>  A framework that can be extended to other virtualisation avenues.
>>  The ability to have full virtual machines on almost any layout
>>  of physical hardware.
> 
> I'm confused by the above statements.
> 
> Also somewhat bemused by them, given that our track record for 
> regression testing and documentation ain't always that great either -- 
> and when bold new ideas are proposed, due diligence often saves the day.
> 
> * Do you mean to say that IMUNES/vimage has expanded beyond merely 
> wrapping the network stack and virtualizing that?

It includes enough of a framework to allow it to cope with loadable 
kernel modules and to integrate with jails. Two important requirements
for its job. This means that this framework is avialable for other 
virtualisation work to use as well.

> 
> If this is the case (it introduces some new virtualization technique on 
> par with the functionality of e.g. Xen) then I outright DISAGREE with 
> its introduction into the source tree on the grounds that it's too 
> experimental.

no it doesn't do machine virtualisation.

> 
> * Also, do the changes which you intend to introduce, allow for code 
> which is currently under development, and which is not aware of 
> vimage/IMUNES in any way, to continue to compile and be usable without 
> additional developer time?

Code not aware of vimage just appears in all virtual machines, just as 
it would appear in all jails. I uses and expands on the jail 
infrastructure.


> 
> I am continually sidetracked from FreeBSD infrastructural work because 
> it just doesn't pay the bills. As a result I have to defer work for up 
> to a year at a time. If there were community funding available this 
> would help, but as it is, I have to keep the plates spinning somehow.
> 
> I usually try to keep my p4 development branches merged and in sync at a 
> minimum, so I can always diff against HEAD.

Marco does a reasonable job of keeping up with head. he syncs it up
every few weeks. I just committed some scripts that should help him do 
that too.


> 
> [Julian, you're not about to give people a real headache with this, are 
> you?]
> 
> * If the objective of the exercise is to expose people to vimage, would 
> it not be wiser to implement vimage as a fork in a more accessible 
> repository format than Perforce? e.g. Mercurial or Git?

no the aim is to integrate it into FreeBSD.


> 
> I am opposed to trial-by-fire.

This is not trial by fire any more than any other code.
However there must be SOME amount of trial by fire in every project..

> 
> I am just as frustrated with the lack of progress which is visible to 
> people on the outside of the development cabal as anybody else (just try 
> to get people to test code in Perforce when they aren't committers, and 
> you'll see EXACTLY what I mean), but I really don't like the idea of 
> experimental work going into CVS.

And there we differ. I think the time for this has come. I'd say about 
6 years is long enough. That is how long people have had to play with 
this and find problems. Anybody who has had anything to do with it
has only sung its praises.


> 
> Whilst CVS is a proven tool, its use in the project, to my mind, seems 
> more geared to delivering production code and tracking changes in 
> production branches, rather than managing fast-moving new development.

Things have to get into it at some stage..

> 
> * Does the vimage code have a full set of regression tests which prove 
> that its introduction does not cause the system to behave in an 
> unexpected way? 

no. it has tests for its own functionality.
No other piece of code in the system EVER has had regeression
tests for whole system. Loading this burden on vimage is not a
fair requirement. The aim of vimage is for you to not be able to tell, 
so any deviation form normal behaviour in any part of the
system would be a regression.

> 
> These are very real concerns and they do need to be addressed, otherwise 
> I speculate this is going to be messy, and I don't want to see a repeat 
> of FreeBSD 5.x.

it is not going to be that.. Please read the code and the papers.

> 
> Don't get me wrong, there is excellent reasoning and art behind the work 
> in vimage, but the very real economic difficulties involved in its 
> integration just cannot be ignored as they affect everyone involved with 
> the project.

I' am cerainly not ignoring it.. That's why it is being pushed NOW and 
not 5 years ago in 4.6 when it could have been pushed in.

> 
> best regards,
> BMS