Date: Wed, 27 Feb 2008 08:20:25 +0100 From: Milan Obuch <freebsd-current@dino.sk> To: freebsd-current@freebsd.org Cc: FreeBSD Current <current@freebsd.org>, Marko Zec <zec@imunes.net>, Marko Zec <zec@icir.org>, Marko Zec <zec@freebsd.org>, Julian Elischer <julian@elischer.org>, "Bruce M. Simpson" <bms@icir.org> Subject: Re: warning of pending commit attempt. Message-ID: <200802270820.52816.freebsd-current@dino.sk> In-Reply-To: <47C4BB96.80804@icir.org> References: <47C39948.3080907@elischer.org> <47C4BB96.80804@icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200802270820.52816.freebsd-current>