On Wednesday 27 February 2008, Bruce M. Simpson wrote:

I am not going to comment on all aspects, just some small notes...

> 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?
>
> 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.
>


Did you check some papers on vimage? It's purpose is virtualise network sta=
ck=20
by extending jails into virtual image... From my experience it has no other=
=20
impact, just enable creation of 'extended jails' with full network stack. I=
=20
may be wrong on this, but this is what my reading and experience show me...

> * 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?
>
> 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.
>


=46rom my, not kernel developer oriented perspective, there is no change at=
all,=20
just bunch of new possibilities. Naturally, there are some changes in kerne=
l,=20
but as far as I can see it, they are well defined and isolated in macros, s=
o=20
this mostly means almost no change, but I am not the right one to comment o=
n=20
this.

> [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?
>
> I am opposed to trial-by-fire.
>
> 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.
>


This work is experimental for more than five years. I am not testing it=20
continually, but as already stated, not only by me, it is really well=20
designed framework and really well coded. I do not remember any flaw or bug=
=20
in my work with it. In my eyes, it is already stable and settled enough to =
be=20
introduced into main tree.

> 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.
>
> * 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?
>
> 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.
>
> 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.
>


Well, I am working with FreeBSD long enough to say there are periods when e=
ven=20
stable or legacy branch breaks. They are rare, to be honest, but still can =
be=20
disturbing. After branching 7.0, this is the right time to introduce anythi=
ng=20
new which can be considered major change, not when preparing 8.0.

Regards,
Milan

=2D-=20
Address this mail is sent from is used only for this mailing list.
Do not send any messages to it directly as a response, reply only
to mailing list. For mail to me personally, use milan in address instead.
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/lis...reebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"