Re: warning of pending commit attempt.

Just to give everone some background:
 I shared an office in Berkeley with Marko for nearly a month 3 years 
ago, working on the same project. I bear him no ill will whatsoever, I'm 
impressed by the work he's done, especially so given he's started a family.

But I do need to wear a black hat in this argument, because there's more 
to FreeBSD than the server space, and the future beckons.

We need to balance the risk of the new feature against its effect on 
current and future development. I still see loose ends which need to be 
tied up before I'm 90% happy. I will never be 100% happy with anything 
in life ever.

Julian Elischer wrote:
> 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.
>
> no it doesn't do machine virtualisation.
>

OK, so the agenda for vimage hasn't fundamentally changed. Thanks for 
clarifying this. I got the impression from your message that the agenda 
had gotten bigger.


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

OK. The presence of jail generally doesn't interfere with things I've 
been looking at.

I don't really have a problem with this as long as it defaults to "off" 
for at least a first release.

I speculate the majority of the user base don't actually need vimage. I 
speculate it isn't an interesting feature in the near future for 
embedded platforms. They may not know they want it (or I for that 
matter) yet. It's a bit like trying to get a child to eat more green 
vegetables.

Of course if vimage touches network interfaces, and can present virtual 
NICs to the stack, then things get more complicated.

This of course is the KitchenSinkBSD issue, how can something be all 
things to all people and yet stay focused and be tight?

> 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.
>
I know --  6 years --  blimey, tell me about it.

But the point I am making is that a lot of that drag could have been 
avoided.

It's not the first time that I've introduced code to the tree, having 
given people plenty of warning (3-6 months), and then experience my 
stress levels surge off the scale as my inbox, and lists, are bombarded 
with messages from people going "WTF?"

And this set of changes wasn't even on the scale of vimage.

It is reminiscent of the opening chapters of Douglas Adams' 
"Hitchhiker's Guide to the Galaxy", where notice of the change, to their 
mind, was posted in a basement filing cabinet behind a locked door with 
a sign saying "Beware of the leopard".

I see problems because people come to expect a higher level of polish 
from FreeBSD as they do from its alternatives, which is why I mention 
regression testing. In many ways there is no real substitute for a 
commercially oriented development model, however as we know that has its 
cons as well as its pros.

Granted, there's infinite demand for free goods and services. 
Unfortunately this is more economically involved than simply saying to 
the world, "Look everyone, I made some cookies. Want some?" -- unless 
it's done on a small scale and the effort is tightly focused. I imagine 
most of us know that real life development of anything is an iterative 
process.

Of course finding people who are willing to be committed to test and 
roll-out is made infinitely easier, if there are other things in it for 
them, and quite often, that boils down to money...

Which leads to a head on collision with the ideological battleground 
that open source sometimes ends up being.

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

Again, I'm trying to underline a point about CVS, p4 and their use 
within the project.

Perforce doesn't really cut it for opening up code to the public at 
large, as we have seen, and has real limitations, both in these terms 
and in terms of its resource use.


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

Of course it's not fair -- I'm playing daemon's advocate here. ;^)

I would be happier to see vimage go in when I see stronger answers to 
the questions which Andre and Kris raise re synchronization overhead.

Again, I'm making the point that more formal software development 
practice wouldn't go amiss, particularly when introducing something with 
wide impact such as vimage.

I'm on an interesting chapter of Douglas Hofstader's "G*del, Escher, 
Bach" which discusses just such interdependence just now.

I'm happy that things aren't specced down to the microsecond in FreeBSD, 
otherwise we'd never get anything done. Folks just have to remember to 
perform appropriate system tuning on their own expectations. ;-)

cheers
BMS