Re: HEADS UP: Destabilization due to SMP development

[Jason Evans]

On Sun, Aug 20, 2000 at 12:14:05PM +, Nik Clayton wrote:
> On Mon, Jun 19, 2000 at 11:53:30AM -0700, Jason Evans wrote:
> > Summary: -current will be destabilized for an extended period (on the order
> > of months).  A tag (not a branch) will be laid down before the initial
> > checkin, and non-developers should either stick closely to that tag until
> > the kernel stabilizes, or expect large doses of pain.  This tag will be
> > laid down as soon as June 26, 00:00 PST, with a minimum 24 hour warning
> > beforehand.
> 
> Is there any news on this work?  Unless I've missed the significance of
> recent commits, I haven't seen anything approaching this sort of 
> destabilisation in -current.

No, there has not been a commit yet, but we're quite close at this point to
making one.  Chances are good that this will happen within the next two
weeks.

Jason


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: HEADS UP: Destabilization due to SMP development

[John Baldwin]

Nik Clayton wrote:
> On Mon, Jun 19, 2000 at 11:53:30AM -0700, Jason Evans wrote:
> > Summary: -current will be destabilized for an extended period (on the order
> > of months).  A tag (not a branch) will be laid down before the initial
> > checkin, and non-developers should either stick closely to that tag until
> > the kernel stabilizes, or expect large doses of pain.  This tag will be
> > laid down as soon as June 26, 00:00 PST, with a minimum 24 hour warning
> > beforehand.
> 
> Is there any news on this work?  Unless I've missed the significance of
> recent commits, I haven't seen anything approaching this sort of 
> destabilisation in -current.

It's not all that unstable actually.  Well, it currently panics an SMP box
within minutes of starting a make world, but single processor seems to be
relatively stable.  You can get more info at
http://www.freebsd.org/~jasone/smp/.

> N
> -- 
> Internet connection, $19.95 a month.  Computer, $799.95.  Modem, $149.95.
> Telephone line, $24.95 a month.  Software, free.  USENET transmission,
> hundreds if not thousands of dollars.  Thinking before posting, priceless.
> Somethings in life you can't buy.  For everything else, there's MasterCard.
>   -- Graham Reed, in the Scary Devil Monastery

-- 

John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: HEADS UP: Destabilization due to SMP development

[Nik Clayton]

On Mon, Jun 19, 2000 at 11:53:30AM -0700, Jason Evans wrote:
> Summary: -current will be destabilized for an extended period (on the order
> of months).  A tag (not a branch) will be laid down before the initial
> checkin, and non-developers should either stick closely to that tag until
> the kernel stabilizes, or expect large doses of pain.  This tag will be
> laid down as soon as June 26, 00:00 PST, with a minimum 24 hour warning
> beforehand.

Is there any news on this work?  Unless I've missed the significance of
recent commits, I haven't seen anything approaching this sort of 
destabilisation in -current.

N
-- 
Internet connection, $19.95 a month.  Computer, $799.95.  Modem, $149.95.
Telephone line, $24.95 a month.  Software, free.  USENET transmission,
hundreds if not thousands of dollars.  Thinking before posting, priceless.
Somethings in life you can't buy.  For everything else, there's MasterCard.
  -- Graham Reed, in the Scary Devil Monastery


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: HEADS UP: Destabilization due to SMP development

[Matthew Jacob]

On Thu, 22 Jun 2000, Greg Lehey wrote:

> On Thursday, 22 June 2000 at 10:07:38 -0700, Matthew Dillon wrote:
> >
> >> On Mon, Jun 19, 2000 at 05:34:47PM -0700, Matthew Dillon wrote:
> >>>
> >>> Ok, I have put up a web page that will track my efforts.
> >>>
> >>>   http://apollo.backplane.com/FreeBSDSmp/
> >>
> >> Your first patchset contains only i386 code.
> >> What is the timeframe for alpha relative to i386?
> >> Will each i386 code step converted to it a short time later or finally
> >> after the i386 code completely has been stabilized?
> >
> > The alpha code is going to be dealt with by the alpha guys.  I am
> > not an alpha assembly programmer.  There is going to be considerably
> > more breakage for the alpha port in the next month then the i386 port,
> > but hopefully it will get worked out.
> 
> Hmm.  This adds another dependency.  We will really need to get the
> Alpha code in place before we can commit anything.  Is there anybody
> out there who can do this?

If neither Doug nor Andrew have volunteered for this, I'll take it on. 




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: HEADS UP: Destabilization due to SMP development

[Dave Glowacki]

"Daniel C. Sobral" wrote:
> "Jordan K. Hubbard" wrote:
> > 
> > Everyone talks about using bitkeeper but none of the people who
> > recommend it have ever actually tried to use it for anything.
> > Before such recommendations will bear weight, this needs to
> > change. :)
> 
> OCVS? (Or was it OVCS? I can never recall...)

I know of at least 4 open source successors to CVS:

Eivind Eklund's OVCS
http://www.OpenVCS.org/

Josh MacDonald's PRCS
http://www.cs.berkeley.edu/~jmacd/prcs.html

Jonathan Shapiro's DCMS
http://www.eros-os.org/~majordomo/dcms-dev/

tigris.org's Subversion
http://subversion.tigris.org/

Of these, PRCS the only one out of the design phase,
though it doesn't yet have a client-server mode.
Oh yeah, there's Bitkeeper too, but it's not really
open source...


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: HEADS UP: Destabilization due to SMP development

[Marc van Woerkom]

> Using a non opensource commercial version control system is just
> to ask for bad carma, extended murphy fields and whatnot in an
> opensource volounteer project...

I would like to understand the discussed weakness of cvs regarding
branches.

Could someone explain it (in private) or point me to a link?

I ask because I had to work a lot with MKS SI (RCS based) and it was OK
to manage different branches with it.
So I assumed cvs as a kind of successor to rcs is able to do this too.

Or do people just like an improved architecture?
I understand that systems like Perforce are handling diffs to the
code base not file orientated but rather goal orientated which 
might give a much better overview.

Regards,
Marc






To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: HEADS UP: Destabilization due to SMP development

[Adam]

On Wed, 21 Jun 2000, Chuck Robey wrote:

>On Wed, 21 Jun 2000, Mark Murray wrote:
>
>> >Has anyone given any thought to what it would take to create an 
>> > open source version of something similar to perforce?  ;-)
>> 
>> Clearly you have. :-). We await your submissions with baited breath...
>
>I have mixed feelings about that.  The Perforce people have been willing
>for FreeBSD to use it free.  They're really nice about that, it seems more
>than a bit discourteous to try to copy it.  If you'd asked to duplicate

But I thought Imitation was the highest form of flattery :)


>MSWord, they're a unethical monopolist, I wouldn't have any scruples
>attacking them, but I don't like attacking folks who've been displaying
>towards free software such a friendly attitude.
>
>Makes me (and I sure support free software!) feel like a predator when you
>go after folks who've been doing good.
>
>I think, if you want it fixed, you should go fix cvs.
>
>
>Chuck Robey| Interests include C & Java programming, FreeBSD,
>[EMAIL PROTECTED]  | electronics, communications, and signal processing.
>
>New Year's Resolution:  I will not sphroxify gullible people into looking up
>fictitious words in the dictionary.
>
>
>
>
>To Unsubscribe: send mail to [EMAIL PROTECTED]
>with "unsubscribe freebsd-current" in the body of the message
>



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: HEADS UP: Destabilization due to SMP development

[Wilko Bulte]

On Thu, Jun 22, 2000 at 01:56:56PM -0700, Greg Lehey wrote:
> On Thursday, 22 June 2000 at 10:07:38 -0700, Matthew Dillon wrote:
> >
> >> On Mon, Jun 19, 2000 at 05:34:47PM -0700, Matthew Dillon wrote:
> >>>
> >>> Ok, I have put up a web page that will track my efforts.
> >>>
> >>>   http://apollo.backplane.com/FreeBSDSmp/
> >>
> >> Your first patchset contains only i386 code.
> >> What is the timeframe for alpha relative to i386?
> >> Will each i386 code step converted to it a short time later or finally
> >> after the i386 code completely has been stabilized?
> >
> > The alpha code is going to be dealt with by the alpha guys.  I am
> > not an alpha assembly programmer.  There is going to be considerably
> > more breakage for the alpha port in the next month then the i386 port,
> > but hopefully it will get worked out.
> 
> Hmm.  This adds another dependency.  We will really need to get the
> Alpha code in place before we can commit anything.  Is there anybody
> out there who can do this?

I think (but am not sure!) that dfr was working on SMP for axp some time ago?

-- 
Wilko Bulte http://www.freebsd.org  "Do, or do not. There is no try"
[EMAIL PROTECTED]   http://www.nlfug.nl Yoda - The Empire Strikes Back


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: HEADS UP: Destabilization due to SMP development

[Daniel C. Sobral]

"Jordan K. Hubbard" wrote:
> 
> Everyone talks about using bitkeeper but none of the people who
> recommend it have ever actually tried to use it for anything.
> Before such recommendations will bear weight, this needs to
> change. :)

OCVS? (Or was it OVCS? I can never recall...)

-- 
Daniel C. Sobral(8-DCS)
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Windows works, for sufficently small values of "works".



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: HEADS UP: Destabilization due to SMP development

[Greg Lehey]

On Thursday, 22 June 2000 at 10:07:38 -0700, Matthew Dillon wrote:
>
>> On Mon, Jun 19, 2000 at 05:34:47PM -0700, Matthew Dillon wrote:
>>>
>>> Ok, I have put up a web page that will track my efforts.
>>>
>>> http://apollo.backplane.com/FreeBSDSmp/
>>
>> Your first patchset contains only i386 code.
>> What is the timeframe for alpha relative to i386?
>> Will each i386 code step converted to it a short time later or finally
>> after the i386 code completely has been stabilized?
>
> The alpha code is going to be dealt with by the alpha guys.  I am
> not an alpha assembly programmer.  There is going to be considerably
> more breakage for the alpha port in the next month then the i386 port,
> but hopefully it will get worked out.

Hmm.  This adds another dependency.  We will really need to get the
Alpha code in place before we can commit anything.  Is there anybody
out there who can do this?

Greg
--
Finger [EMAIL PROTECTED] for PGP public key
See complete headers for address and phone numbers


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: HEADS UP: Destabilization due to SMP development

[Matthew Dillon]

:On Mon, Jun 19, 2000 at 05:34:47PM -0700, Matthew Dillon wrote:
:> 
:> Ok, I have put up a web page that will track my efforts.
:> 
:>  http://apollo.backplane.com/FreeBSDSmp/
:
:Your first patchset contains only i386 code.
:What is the timeframe for alpha relative to i386?
:Will each i386 code step converted to it a short time later or finally
:after the i386 code completely has been stabilized?
:
:-- 
:B.Walter  COSMO-Project http://www.cosmo-project.de

The alpha code is going to be dealt with by the alpha guys.  I am
not an alpha assembly programmer.  There is going to be considerably
more breakage for the alpha port in the next month then the i386 port,
but hopefully it will get worked out.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: HEADS UP: Destabilization due to SMP development

[Bernd Walter]

On Mon, Jun 19, 2000 at 05:34:47PM -0700, Matthew Dillon wrote:
> 
> Ok, I have put up a web page that will track my efforts.
> 
>   http://apollo.backplane.com/FreeBSDSmp/

Your first patchset contains only i386 code.
What is the timeframe for alpha relative to i386?
Will each i386 code step converted to it a short time later or finally
after the i386 code completely has been stabilized?

-- 
B.Walter  COSMO-Project http://www.cosmo-project.de
[EMAIL PROTECTED] Usergroup   [EMAIL PROTECTED]



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: HEADS UP: Destabilization due to SMP development

[Chuck Robey]

On Wed, 21 Jun 2000, Mark Murray wrote:

> > Has anyone given any thought to what it would take to create an 
> > open source version of something similar to perforce?  ;-)
> 
> Clearly you have. :-). We await your submissions with baited breath...

I have mixed feelings about that.  The Perforce people have been willing
for FreeBSD to use it free.  They're really nice about that, it seems more
than a bit discourteous to try to copy it.  If you'd asked to duplicate
MSWord, they're a unethical monopolist, I wouldn't have any scruples
attacking them, but I don't like attacking folks who've been displaying
towards free software such a friendly attitude.

Makes me (and I sure support free software!) feel like a predator when you
go after folks who've been doing good.

I think, if you want it fixed, you should go fix cvs.


Chuck Robey| Interests include C & Java programming, FreeBSD,
[EMAIL PROTECTED]  | electronics, communications, and signal processing.

New Year's Resolution:  I will not sphroxify gullible people into looking up
fictitious words in the dictionary.




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: HEADS UP: Destabilization due to SMP development

[Brad Knowles]

At 5:00 PM -0400 2000/6/21, Dan Papasian wrote:

>  Eivind Elkund was talking about doing something like
>  this.  He had a pretty nice document about it,
>  too.  If I recall, the name was "OVCS: Open Version Control System"

Hmm.  So far, Google hasn't been particularly useful in trying to 
track this stuff down.  The first page that came up was 
, which is for the "Open Source 
Version Control Software" page (i.e., good ole' CVS itself), and the 
next search turned up , which is the page for 
"Otselic Valley Central School".

Doing a bit more digging, I did finally manage to find 
, and 
although it has his name and the magic "ocvs" characters, I don't 
think this is quite what I'm looking for, either.


So far, the most useful page I've found on this topic is 
, but all it does is mention:

Notes: I'm a FreeBSD developer, presently on sabbatical.
For my sabbatical, I'm working on a new version control
system, aimed at distributed development.


Does anyone have any real information or useful pointers on 
exactly what he's working on right now, and what the current state of 
that project is?  Thanks!

--
   These are my opinions -- not to be taken as official Skynet policy
==
Brad Knowles, <[EMAIL PROTECTED]>|| Belgacom Skynet SA/NV
Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124
Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels
http://www.skynet.be || Belgium


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: HEADS UP: Destabilization due to SMP development

[Brad Knowles]

At 11:09 PM +0200 2000/6/21, Mark Murray wrote:

>>  Has anyone given any thought to what it would take to create an
>>  open source version of something similar to perforce?  ;-)
>
>  Clearly you have. :-). We await your submissions with baited breath...

If you're waiting for me on this, you might want to buy your 
burial plot now and go ahead and make all your final arrangements -- 
you're going to be waiting for a while.  ;-)

--
   These are my opinions -- not to be taken as official Skynet policy
==
Brad Knowles, <[EMAIL PROTECTED]>|| Belgacom Skynet SA/NV
Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124
Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels
http://www.skynet.be || Belgium


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: HEADS UP: Destabilization due to SMP development

[Mark Murray]

>   Has anyone given any thought to what it would take to create an 
> open source version of something similar to perforce?  ;-)

Clearly you have. :-). We await your submissions with baited breath...

M
--
Mark Murray
Join the anti-SPAM movement: http://www.cauce.org


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: HEADS UP: Destabilization due to SMP development

[Dan Papasian]

Eivind Elkund was talking about doing something like
this.  He had a pretty nice document about it,
too.  If I recall, the name was "OVCS: Open Version Control System"

Perhaps someone could fill in the blanks?  I couldn't
find the document at the address I thought it was kept,
http://yes.no/perhaps/

I don't believe he had any code the last time we talked about it.
I do recall reading that he's using his time off to work on 
OVCS.  While I still don't think he has anything usable, 
you'd want to get in touch with him to reduce duplicated
effort.


-Dan

On Wed, Jun 21, 2000 at 09:59:25PM +0200, Brad Knowles wrote:
> At 9:34 PM +0200 2000/6/21, Soren Schmidt wrote:
> 
> >  Using a non opensource commercial version control system is just
> >  to ask for bad carma, extended murphy fields and whatnot in an
> >  opensource volounteer project...
> 
>   Has anyone given any thought to what it would take to create an 
> open source version of something similar to perforce?  ;-)
> 
> --
>These are my opinions -- not to be taken as official Skynet policy
> ==
> Brad Knowles, <[EMAIL PROTECTED]>|| Belgacom Skynet SA/NV
> Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124
> Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels
> http://www.skynet.be || Belgium


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: HEADS UP: Destabilization due to SMP development

[Brad Knowles]

At 9:34 PM +0200 2000/6/21, Soren Schmidt wrote:

>  Using a non opensource commercial version control system is just
>  to ask for bad carma, extended murphy fields and whatnot in an
>  opensource volounteer project...

Has anyone given any thought to what it would take to create an 
open source version of something similar to perforce?  ;-)

--
   These are my opinions -- not to be taken as official Skynet policy
==
Brad Knowles, <[EMAIL PROTECTED]>|| Belgacom Skynet SA/NV
Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124
Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels
http://www.skynet.be || Belgium


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: HEADS UP: Destabilization due to SMP development

[Soren Schmidt]

It seems Warner Losh wrote:
> In message <12213.961613148@localhost> "Jordan K. Hubbard" writes:
> : Everyone talks about using bitkeeper but none of the people who
> : recommend it have ever actually tried to use it for anything.
> : Before such recommendations will bear weight, this needs to
> : change. :)
> 
> In that case, I'd recommend perforce :-)  I used it extensively at
> Pluto while I was there.  I'd love to see FreeBSD use it.  The
> non-open source ness of it is a bummer, but how much pain are we
> willing to tolerate for our ideals? :-)

Alot. 

Using a non opensource commercial version control system is just
to ask for bad carma, extended murphy fields and whatnot in an
opensource volounteer project...

-Søren


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: HEADS UP: Destabilization due to SMP development

[Warner Losh]

In message <12213.961613148@localhost> "Jordan K. Hubbard" writes:
: Everyone talks about using bitkeeper but none of the people who
: recommend it have ever actually tried to use it for anything.
: Before such recommendations will bear weight, this needs to
: change. :)

In that case, I'd recommend perforce :-)  I used it extensively at
Pluto while I was there.  I'd love to see FreeBSD use it.  The
non-open source ness of it is a bummer, but how much pain are we
willing to tolerate for our ideals? :-)

Warner


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: HEADS UP: Destabilization due to SMP development

[Jordan K. Hubbard]

Everyone talks about using bitkeeper but none of the people who
recommend it have ever actually tried to use it for anything.
Before such recommendations will bear weight, this needs to
change. :)

- Jordan


> 
> [EMAIL PROTECTED] said:
> :- "CVS branches suck" is the reason I belive. 
> 
> Bitkeeper?
> 
> -- 
> Robert Withrow -- (+1 978 288 8256)
> [EMAIL PROTECTED]
> 
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: SMP locking primities (was Re: HEADS UP: Destabilization due to SMP development)

[Greg Lehey]

On Tuesday, 20 June 2000 at 11:16:24 +0200, Martin Cracauer wrote:
> In <[EMAIL PROTECTED]>, Poul-Henning Kamp wrote:
>>
>> Am I the only person who miss a brief document which tells what
>> the outcome of the meeting was ?
>
> Who was there, anyway?

>From my trip report.  This can hardly be confidential.

Participants were:

  Don BradyApple Computer   File systems
  Ramesh   Apple Computer
  Ted Walker   Apple Computer   network drivers
  Jeffrey Hsu  FreeBSD project
  Chuck Paterson   BSDi Chief developer
  Jonathan Lemon   Cisco, FreeBSD project
  Matt Dillon  FreeBSD project  VM, NFS
  Paul SaabYahoo!
  Kirk McKusick
  Peter Wemm   Yahoo!
  Jayanth  Yahoo!
  Doug Rabson  FreeBSD project  Alpha port
  Jason Evans  FreeBSD project  kernel threads
  David Greenman   FreeBSD project  chief architect
  Justin Gibbs Adaptec, FreeBSD project SCSI, 0 copy TCP
  Greg Lehey   Linuxcare, FreeBSD project   storage management
  Mike Smith   BSDi, FreeBSD projecthardware, iA64 port
  Alfred Perlstein Wintel, FreeBSD project
  David O'BrienBSDi, FreeBSD projectcompilers, binutils
  Ceren Ercen  LinuxcareDaemon babe

Look also at http://ziplok.dyndns.org/msmith/SMPng/.

Greg
--
Finger [EMAIL PROTECTED] for PGP public key
See complete headers for address and phone numbers


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: HEADS UP: Destabilization due to SMP development

[Greg Lehey]

On Tuesday, 20 June 2000 at 12:57:41 -0600, Warner Losh wrote:
> In message <[EMAIL PROTECTED]> Poul-Henning Kamp writes:
>>  I think core has approved in principle, and several core members
>>  were present at the meeting (at least peter, dg, gibbs, dfr), that
>>  being said, I think we need to see some more concrete info before
>>  we pull the lever, just so we know what to expect.
>
> I'd like to see an explicit vote saying that current can be broken for
> months for SP users so the MP work can go in.  It has often been said
> that individual core members do not speak for core.

I'm quite happy to accept a majority vote of -core.

>>> The instability ni -current for MONTHS is pain not acceptible.
>>
>>  Sorry, Warner, but progress has its price, and this may be it.
>
> I don't think so.  I've done all the NEWCARD work in the tree, and it
> hasn't broken anything else (at least not for more than a few hours
> when I screwed up).  It has been painful for me to do it that way, but
> I think that some consideration should be given for the transition
> period for SP users.
>
> A few days or weeks I don't have a prblem with, but a few months is
> flat not acceptible.  It is too long.  If the code is that green, then
> some other mechanism needs to be used to facilitate collaberative
> working.
>
> I'd rather see a firm deadline proposed (eg, we'll commit the core on
> June 26, and will be done by Aug 26) so that I know what to expect
> rather than having the nebulous a few months phrase kicked around.  I
> expected the newcard stuff to be working in a few months, and it has
> been about 8 so far.

This was one of the points we discussed.  I was very much in favour of
a longer period so that people like you could commit their changes.
On the other hand, I think that the breakage will be relative, and it
will be less for SP systems than for SMP systems.  Certainly I think
that Matt and I need to get our act together (i.e. a system which at
least limps) before we commit anything; possibly people were a little
too optimistic about how quickly we could do things when we broke up
on Friday.

> Also, what if the new MP core goes in and one or more of the key
> players all of a sudden have no time to finish this due to unforseen
> circumstances?  Will the tree remain broken while they sort this
> out?

Maybe.  It depends on the circumstances and the preparedness of others
to fix it.  But I do think that we're entering a new phase of software
development with this project: for the first time we have a project
manager (Jason Evans), and I'd expect him to drum up some support,
from BSDi if necessary.  Note that Chuck Patterson is slated to help
us with 50% of his working time until we get this rickety framework to
fly.

Greg
--
Finger [EMAIL PROTECTED] for PGP public key
See complete headers for address and phone numbers


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: SMP locking primities (was Re: HEADS UP: Destabilization due to SMP development)

[Greg Lehey]

On Tuesday, 20 June 2000 at  9:41:57 +0200, Poul-Henning Kamp wrote:
>
> Am I the only person who miss a brief document which tells what
> the outcome of the meeting was ?

I'm writing up a detailed trip report for my company.  I can't see why
I shouldn't forward it to the SMP list as well, but I suppose I should
check.

> Can we get to see the slides ?

Chuck Patterson has some.  I'm sure we could get him to send the
.pdf's.

> Audio ?

No.

> Video ?

Very patchy.  I started taping about 3 hours into the meeting, and
since I had better things to do than be cameraman, from time to time
we ran out of tape.  I'll make copies when I get back home.  On the
positive side, it's PAL.  But Apple has promised to make an NTSC
conversion.

Greg
--
Finger [EMAIL PROTECTED] for PGP public key
See complete headers for address and phone numbers


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: HEADS UP: Destabilization due to SMP development

[Robert Withrow]

[EMAIL PROTECTED] said:
:- "CVS branches suck" is the reason I belive. 

Bitkeeper?

-- 
Robert Withrow -- (+1 978 288 8256)
[EMAIL PROTECTED]



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: HEADS UP: Destabilization due to SMP development

[Nick Hibma]

CAM is not a valid example. It only touched the disk subsystem.

Merging back changes in blocks might not be possible. As Matthew
mentioned, Chuck's experience should be taken for a fact.

And bounding the amount of breakage is almost impossible without
squeezing the people doing the SMP work really badly. I don't think that
that is reasonable.

Nick

> One could argue that you could merge the changes to FreeBSD 5.X on a
> daily or weekly basis to that branch so that the branch doesn't get
> too far out of what.  Perforce users do this all the time (cf the cam
> project).  The model that I see is that a branch is created for SMP
> work, and that you find a volunteer who has access to SMP machines who 
> will merge from current into the SMP branch once a week and boot the
> resulting kernel.  If it works, he commits it, otherwise he resovles
> the problems.  That way the main developers aren't significantly
> impacted by the merging.
> 
> I'd be a lot happier if there was an upper bound on the length of time 
> that -current would be unstable, if there was a plan in place on what
> to do if that timelimit was exceeded, if there was a roadmap I could
> look at, etc.  Right now the vagueness of it all pushes my panic
> button.  I'm trying to get more information so that I know if I should 
> just calm down and it won't be that bad, or if I should pitch a huge
> fit because it will be too painful to make progress on any other
> front.  Please help me with that.
> 
> I'd also be happy if I could create a newcard branch off the last
> stable version of freebsd 5.0-current.  That way I could continue my
> work with others and the instability wouldn't matter.  All merging, if 
> any, would be my responsibility.  I don't know what the level of pain 
> 
> Of course the same arugment about merging you make could be made for
> new kernel work.  They will either have to live with the pain (which
> is currently ill-defined at best, knowing what the pain would be would 
> help my confort level), or do their work and then redo it on the new
> and improved FreeBSD months later.  Why should SMP force others to do
> that?
> 
> Warner
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
> 

--
[EMAIL PROTECTED]
[EMAIL PROTECTED]  USB project
http://www.etla.net/~n_hibma/



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: HEADS UP: Destabilization due to SMP development

[Nick Hibma]

More over, unlike other big project like CAM, this baby is going to
touch the gut of the OS.

It might be possible however for individual projects to move into a
separate branch.

Nick

> >What about doing the changes on a branch with the understanding that 
> >the branch will *replace* HEAD when it stabilises ?
> 
> "CVS branches suck" is the reason I belive.
> 
> --
> Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
> [EMAIL PROTECTED] | TCP/IP since RFC 956
> FreeBSD coreteam member | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
> 
> 

--
[EMAIL PROTECTED]
[EMAIL PROTECTED]  USB project
http://www.etla.net/~n_hibma/




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: SMP locking primities (was Re: HEADS UP: Destabilization due to SMP development)

[Jason Evans]

On Tue, Jun 20, 2000 at 09:41:57AM +0200, Poul-Henning Kamp wrote:
> 
> Am I the only person who miss a brief document which tells what
> the outcome of the meeting was ?

I'm at USENIX right now, so I'm a bit strapped for time to work on this.
Still, I plan to email a brief summary of the meeting within the next
couple of days.  It won't include all of the gory details, simply because I
don't remember all of them(my notes were mainly for my own benefit, and are
of limited usefulness).

> Can we get to see the slides ?

I have the slides, but need to get them on a web page.  This will also
happen in the next couple of days.

> Audio ?
> 
> Video ?

Greg Lehey has a PAL recording of much of the meeting.  If you want to get
ahold of a copy, talk to him privately to see what arrangements you can
make.

Jason


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: HEADS UP: Destabilization due to SMP development

[Mike Meyer]

Warner Losh writes:
> In message <[EMAIL PROTECTED]> Jason Evans writes:
> : Summary: -current will be destabilized for an extended period (on the order
> : of months).  A tag (not a branch) will be laid down before the initial
> : checkin, and non-developers should either stick closely to that tag until
> : the kernel stabilizes, or expect large doses of pain.  This tag will be
> : laid down as soon as June 26, 00:00 PST, with a minimum 24 hour warning
> : beforehand.
> Thanks for the fair warning.  Now don't do it.  Has core approved
> this?  I don't think so, I've seen nothign from them about it.
>
> The instability ni -current for MONTHS is pain not acceptible.  We've
> never really allowed that in the past.  A CVS branch would be mcuh
> better for this sort of thing.  I know that's a pain as well, but this 
> is just for SMP people and the rest of us shouldn't have to deal with
> the pain.

As someone who does consulting on for release engineering and such
things, I'll comment that that's one of the key uses of branches;
buliding a development branch so that adding major new features
doesn't disrupt other development until they are as stable as the rest
of the project.

If CVS makes merging a branch back in a pain, and there isn't an open
source tool (bitkeeper, maybe?) that solves this problem, then
possibly a compromise can be reached with the folks at
Perforce(*). They're reasonable people, and think highly of the
FreeBSD project. "The Cathederal and the Bazaar" talks about
transitioning from closed to open source, so I'd be very surprised if
they haven't thought about these issues.

As a for instance, possibly they could be talked out of sources for
the client (client libraries, that is - the rest is trivial) and a
spec for talking to the server, on the assumption that the truly
valuable information is in the server. That way, the tools installed
by developers would all be open source. Of course, Perforce may have
no interest in this, but I can't think of anything more likely to
convince them to make such a move than the possibility of the FreeBSD
project moving to Perforce.

> I understand your desire to have it all in a working tree, but causing
> pain for ALL developers for potentially MONTHS isn't a reasonable
> request.

How far can the tag be stretched to make things work? Can CVS tags be
changed to include updates versions of a file, so that there is some
possibility that other developers could work with that tag, instead of
creating another branch?

Re: HEADS UP: Destabilization due to SMP development

[Brian Somers]

> > 
> > What about doing the changes on a branch with the understanding that 
> > the branch will *replace* HEAD when it stabilises ?
> > 
> > This sounds odd at first glance, but it means that others are forced 
> > to MFC into the smp branch - if they don't they lose.
> > 
> > Anybody that's not confident to be able to merge into the smp branch 
> > will simply be in the same position - merge or hold off.  They'd also 
> > be just as likely to break the smp work with their commits as if the 
> > smp work was done in HEAD.
> > 
> 
>  Isn't this the same thing as breaking the head and keeping every thing
> else (that is the pre-broken 5.0) on a branch...
> 
>  Just sorta rotating the tree a little...
> 
>  And, isn't this the same idea as -stable?
> 
>  If that's all true - I'd suggest that those who really want stability
> might be better served with the -stable branch for the interim.  If you
> need a totally-brand-new-feature, then MFC that to -stable and get 
> it there...
[.]
>  I suppose I can sum this up with "isn't this already handled?"

True, if you run current you've gotta be able to cope with the blood. 
However, I don't think it's a good idea to have a single project 
prevent a load of other developers from doing their bits - not if it 
can be helped.

I'm sure SMP is not the only code in -current that's not ready for 
-stable yet.

>   - Dave Rivers -
> 
> --
> [EMAIL PROTECTED] Work: (919) 676-0847
> Get your mainframe (370) `C' compiler at http://www.dignus.com

-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: HEADS UP: Destabilization due to SMP development

[Nick Hibma]

Although I would not like to put it as strongly as Warner does, I would
like to ask how the decision makers expect the rest of the project to
progress (the other 30 or so kernel committers) in a reasonable, not
too time consuming way.

Will there be a general mechanism for making patchsets against
CURRENT-26-JUNE-2000 available?

Will there be moments in time were the tree will be made and kept stable
for a week or so for people to insert their fixes. What about xtra tags
being laid at certain moments in time? Any schedule for that?

Will all the spls in all the drivers be removed and replaced by other
mechanisms by the SMP group in the process? This would create a lot of
extra work if the code is shared between different source trees, for
example between the *BSDs, if the spls/shims will be removed completely.

On the side, I would like to suggest that some sort of posting of
updates (by you, Jason?) is done on a regular basis (bi-weekly or so) to
show progress and to indicate the state of important aspects of the
kernel (VM, kernel threads, API's, etc.), so other people have an
indication of how reliable the system is and when it would be a
reasonable point in time for them to start working their code/fixes back
into the tree again.


I must say that I find it slightly annoying that this aspect is
completely ignored in your initial e-mail and definitely would like to
see this addressed properly before any tag goes down and breakage
occurs. I can see that everybody is very excited about what is going to
happen, but I would like to make sure the rest of us, who will only
participate on the side, are not left in the cold for 2 months or so
while the basic stuff is being done.

In any case, thanks for the work you guys are doing. From what Doug told
me there is a lot of really, really cool stuff coming our way. 

Nick

On Tue, 20 Jun 2000, Warner Losh wrote:

> In message <[EMAIL PROTECTED]> Jason Evans writes:
> : Summary: -current will be destabilized for an extended period (on the order
> : of months).  A tag (not a branch) will be laid down before the initial
> : checkin, and non-developers should either stick closely to that tag until
> : the kernel stabilizes, or expect large doses of pain.  This tag will be
> : laid down as soon as June 26, 00:00 PST, with a minimum 24 hour warning
> : beforehand.
> 
> Thanks for the fair warning.  Now don't do it.  Has core approved
> this?  I don't think so, I've seen nothign from them about it.
> 
> The instability ni -current for MONTHS is pain not acceptible.  We've
> never really allowed that in the past.  A CVS branch would be mcuh
> better for this sort of thing.  I know that's a pain as well, but this 
> is just for SMP people and the rest of us shouldn't have to deal with
> the pain.
> 
> I understand your desire to have it all in a working tree, but causing
> pain for ALL developers for potentially MONTHS isn't a reasonable
> request.
> 
> Warner
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
> 

--
[EMAIL PROTECTED]
[EMAIL PROTECTED]  USB project
http://www.etla.net/~n_hibma/



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: HEADS UP: Destabilization due to SMP development

[Thomas David Rivers]

> 
> What about doing the changes on a branch with the understanding that 
> the branch will *replace* HEAD when it stabilises ?
> 
> This sounds odd at first glance, but it means that others are forced 
> to MFC into the smp branch - if they don't they lose.
> 
> Anybody that's not confident to be able to merge into the smp branch 
> will simply be in the same position - merge or hold off.  They'd also 
> be just as likely to break the smp work with their commits as if the 
> smp work was done in HEAD.
> 

 Isn't this the same thing as breaking the head and keeping every thing
else (that is the pre-broken 5.0) on a branch...

 Just sorta rotating the tree a little...

 And, isn't this the same idea as -stable?

 If that's all true - I'd suggest that those who really want stability
might be better served with the -stable branch for the interim.  If you
need a totally-brand-new-feature, then MFC that to -stable and get 
it there...

 The point of -current is to be breakable - the extent of the breaking
isn't known ahead of time. -current can be broken for a long time by
simply breaking several small things - say, one a day for several months.

 The difference here seems to be the forethought in the announcement;
which I take as good planning... i.e. instead of being broken for
some unknown reasons, we're simply saying that we know it's broken...
If you can't live with a broken situation, then I humbly suggest staying
with -stable.

 I suppose I can sum this up with "isn't this already handled?"

- Dave Rivers -

--
[EMAIL PROTECTED] Work: (919) 676-0847
Get your mainframe (370) `C' compiler at http://www.dignus.com


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: SMP locking primities (was Re: HEADS UP: Destabilization due to SMP development)

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, Jonathan Lemon writes:
>In article [EMAIL PROTECTED]> you write:
>>
>>Am I the only person who miss a brief document which tells what
>>the outcome of the meeting was ?
>
>I believe that Jason Evans already sent a message summarizing the
>meeting, and Matt Dillon's webpage gives a pretty good summary of 
>the work too (at http://apollo.backplane.com/FreeBSDSmp/)

But we're not looking for a summary of the meeting, we're looking
for all the gory details...

--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: HEADS UP: Destabilization due to SMP development

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, Brian Somers writes:

>What about doing the changes on a branch with the understanding that 
>the branch will *replace* HEAD when it stabilises ?

"CVS branches suck" is the reason I belive.

--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: SMP locking primities (was Re: HEADS UP: Destabilization due to SMP development)

[Jonathan Lemon]

In article [EMAIL PROTECTED]> you write:
>
>Am I the only person who miss a brief document which tells what
>the outcome of the meeting was ?

I believe that Jason Evans already sent a message summarizing the
meeting, and Matt Dillon's webpage gives a pretty good summary of 
the work too (at http://apollo.backplane.com/FreeBSDSmp/)


>Can we get to see the slides ?

Chuck Patterson presented a bunch of slides (which was actually a .ps
file that displayed page by page in gv), so perhaps he could be persuaded
to make the entire postscript file available somewhere.


>Audio ?  Video ?

After several mishaps, I believe that Greg finally got a video camera
up and running for most of the session.  I think that it was in PAL format
as well.  Greg has the tapes, so I assume that after he's done with
USENIX, he'll have them available.
--
Jonathan


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: HEADS UP: Destabilization due to SMP development

[Brian Somers]

What about doing the changes on a branch with the understanding that 
the branch will *replace* HEAD when it stabilises ?

This sounds odd at first glance, but it means that others are forced 
to MFC into the smp branch - if they don't they lose.

Anybody that's not confident to be able to merge into the smp branch 
will simply be in the same position - merge or hold off.  They'd also 
be just as likely to break the smp work with their commits as if the 
smp work was done in HEAD.

> :: the kernel stabilizes, or expect large doses of pain.  This tag will be
> :: laid down as soon as June 26, 00:00 PST, with a minimum 24 hour warning
> :: beforehand.
> :
> :Thanks for the fair warning.  Now don't do it.  Has core approved
> :this?  I don't think so, I've seen nothign from them about it.
> :
> :The instability ni -current for MONTHS is pain not acceptible.  We've
> :never really allowed that in the past.  A CVS branch would be mcuh
> :better for this sort of thing.  I know that's a pain as well, but this 
> :is just for SMP people and the rest of us shouldn't have to deal with
> :the pain.
> :
> :I understand your desire to have it all in a working tree, but causing
> :pain for ALL developers for potentially MONTHS isn't a reasonable
> :request.
> :
> :Warner
> 
> The problem is that the changes are simply too extensive to be able
> be able to split them off then merge them back into 5.x N months later.
> Creating another branch will tripple the workload on anyone doing 
> merge work.
> 
> We knew we'd probably have to do it this way months ago, and Chuck
> Paterson of BSDI confirmed it when he related his experiences with
> trying to manage the BSDI 5.x MP stuff as a separate branch.
> In short, it was a complete disaster, and I have no doubts that
> trying to manage it as a separate branch in FreeBSD would also result
> in a complete disaster.
> 
> We've known this day was coming for ages... ever since Jordan announced
> the BSDI merger.  Jordan and other core members have hinted, intimated,
> and outright told people that FreeBSD-current would be used for the BSDI
> merge work.  Well, the time is now folks!
> 
>   -Matt
>   Matthew Dillon 
>   <[EMAIL PROTECTED]>

-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: HEADS UP: Destabilization due to SMP development

[Warner Losh]

In message <[EMAIL PROTECTED]> Matthew Dillon writes:
: The problem is that the changes are simply too extensive to be able
: be able to split them off then merge them back into 5.x N months later.
: Creating another branch will tripple the workload on anyone doing 
: merge work.

One could argue that you could merge the changes to FreeBSD 5.X on a
daily or weekly basis to that branch so that the branch doesn't get
too far out of what.  Perforce users do this all the time (cf the cam
project).  The model that I see is that a branch is created for SMP
work, and that you find a volunteer who has access to SMP machines who 
will merge from current into the SMP branch once a week and boot the
resulting kernel.  If it works, he commits it, otherwise he resovles
the problems.  That way the main developers aren't significantly
impacted by the merging.

I'd be a lot happier if there was an upper bound on the length of time 
that -current would be unstable, if there was a plan in place on what
to do if that timelimit was exceeded, if there was a roadmap I could
look at, etc.  Right now the vagueness of it all pushes my panic
button.  I'm trying to get more information so that I know if I should 
just calm down and it won't be that bad, or if I should pitch a huge
fit because it will be too painful to make progress on any other
front.  Please help me with that.

I'd also be happy if I could create a newcard branch off the last
stable version of freebsd 5.0-current.  That way I could continue my
work with others and the instability wouldn't matter.  All merging, if 
any, would be my responsibility.  I don't know what the level of pain 

Of course the same arugment about merging you make could be made for
new kernel work.  They will either have to live with the pain (which
is currently ill-defined at best, knowing what the pain would be would 
help my confort level), or do their work and then redo it on the new
and improved FreeBSD months later.  Why should SMP force others to do
that?

Warner


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: HEADS UP: Destabilization due to SMP development

[Jacques A . Vidrine]

On Tue, Jun 20, 2000 at 08:49:27PM +0200, Poul-Henning Kamp wrote:
> So:  No I don't like -current being toast anymore than you do, but
> I don't think there is a viable alternative.

Not even a seperate repository, as was done (briefly) for newbus?

Of course, maybe that was done so briefly because it was painful...
-- 
Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: HEADS UP: Destabilization due to SMP development

[Matthew Dillon]

:: the kernel stabilizes, or expect large doses of pain.  This tag will be
:: laid down as soon as June 26, 00:00 PST, with a minimum 24 hour warning
:: beforehand.
:
:Thanks for the fair warning.  Now don't do it.  Has core approved
:this?  I don't think so, I've seen nothign from them about it.
:
:The instability ni -current for MONTHS is pain not acceptible.  We've
:never really allowed that in the past.  A CVS branch would be mcuh
:better for this sort of thing.  I know that's a pain as well, but this 
:is just for SMP people and the rest of us shouldn't have to deal with
:the pain.
:
:I understand your desire to have it all in a working tree, but causing
:pain for ALL developers for potentially MONTHS isn't a reasonable
:request.
:
:Warner

The problem is that the changes are simply too extensive to be able
be able to split them off then merge them back into 5.x N months later.
Creating another branch will tripple the workload on anyone doing 
merge work.

We knew we'd probably have to do it this way months ago, and Chuck
Paterson of BSDI confirmed it when he related his experiences with
trying to manage the BSDI 5.x MP stuff as a separate branch.
In short, it was a complete disaster, and I have no doubts that
trying to manage it as a separate branch in FreeBSD would also result
in a complete disaster.

We've known this day was coming for ages... ever since Jordan announced
the BSDI merger.  Jordan and other core members have hinted, intimated,
and outright told people that FreeBSD-current would be used for the BSDI
merge work.  Well, the time is now folks!

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: HEADS UP: Destabilization due to SMP development

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, Warner Losh writes:
>In message <[EMAIL PROTECTED]> Poul-Henning Kamp writes:
>: I think core has approved in principle, and several core members
>: were present at the meeting (at least peter, dg, gibbs, dfr), that
>: being said, I think we need to see some more concrete info before
>: we pull the lever, just so we know what to expect.
>
>I'd like to see an explicit vote saying that current can be broken for 
>months for SP users so the MP work can go in.  It has often been said
>that individual core members do not speak for core.

I'm certainly not speaking for core, unless you see me saying so
explcitly I never speak officially for core.  I just tried to shed
some light on the current status as best I knew it.

--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: HEADS UP: Destabilization due to SMP development

[Warner Losh]

In message <[EMAIL PROTECTED]> Poul-Henning Kamp writes:
: I think core has approved in principle, and several core members
: were present at the meeting (at least peter, dg, gibbs, dfr), that
: being said, I think we need to see some more concrete info before
: we pull the lever, just so we know what to expect.

I'd like to see an explicit vote saying that current can be broken for 
months for SP users so the MP work can go in.  It has often been said
that individual core members do not speak for core.

: >The instability ni -current for MONTHS is pain not acceptible.
: 
: Sorry, Warner, but progress has its price, and this may be it.

I don't think so.  I've done all the NEWCARD work in the tree, and it
hasn't broken anything else (at least not for more than a few hours
when I screwed up).  It has been painful for me to do it that way, but
I think that some consideration should be given for the transition
period for SP users.

A few days or weeks I don't have a prblem with, but a few months is
flat not acceptible.  It is too long.  If the code is that green, then
some other mechanism needs to be used to facilitate collaberative
working.

I'd rather see a firm deadline proposed (eg, we'll commit the core on
June 26, and will be done by Aug 26) so that I know what to expect
rather than having the nebulous a few months phrase kicked around.  I
expected the newcard stuff to be working in a few months, and it has
been about 8 so far.

: So:  No I don't like -current being toast anymore than you do, but
: I don't think there is a viable alternative.

Sure we do.  They get their patches together, and commit them once
they will cuase less pain.  There's always alternatives.  The issue
here is who has to live with the pain.

The MP guys could easily use perforce for this and then merge once
things are stabilized enough to not impact SP people to the point that 
things won't be usable.  The cam folks did this in the past, and it
worked fairly well.

Also, what if the new MP core goes in and one or more of the key
players all of a sudden have no time to finish this due to unforseen
circumstances?  Will the tree remain broken while they sort this out?

Again, I dont' want to hold up progress, but saying that it must be
done this way and I have to put up with it for the sake of progerss is 
not a good justification.

Warner


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: HEADS UP: Destabilization due to SMP development

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, Warner Losh writes:
>In message <[EMAIL PROTECTED]> Jason Evans writes:
>: Summary: -current will be destabilized for an extended period (on the order
>: of months).  A tag (not a branch) will be laid down before the initial
>: checkin, and non-developers should either stick closely to that tag until
>: the kernel stabilizes, or expect large doses of pain.  This tag will be
>: laid down as soon as June 26, 00:00 PST, with a minimum 24 hour warning
>: beforehand.
>
>Thanks for the fair warning.  Now don't do it.  Has core approved
>this?  I don't think so, I've seen nothign from them about it.

I think core has approved in principle, and several core members
were present at the meeting (at least peter, dg, gibbs, dfr), that
being said, I think we need to see some more concrete info before
we pull the lever, just so we know what to expect.

>The instability ni -current for MONTHS is pain not acceptible.

Sorry, Warner, but progress has its price, and this may be it.

>I understand your desire to have it all in a working tree, but causing
>pain for ALL developers for potentially MONTHS isn't a reasonable
>request.

I belive the only viable alternative, as CVS branches are generally
agreed to be >= 25 megasuckage caliber, is to switch the project
to use Perforce.

Until now at least, we have not done that, because developing open
source with a closed source tool has been too much taboo for us
to bother, and it would (as far as we know) not work with cvsup.

I'm not sure now is the time to do it either.

So:  No I don't like -current being toast anymore than you do, but
I don't think there is a viable alternative.

--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: SMP locking primities (was Re: HEADS UP: Destabilization due to SMP development)

[Warner Losh]

In message <[EMAIL PROTECTED]> Poul-Henning Kamp writes:
: Am I the only person who miss a brief document which tells what
: the outcome of the meeting was ?
: 
: Can we get to see the slides ?
: 
: Audio ?
: 
: Video ?

I know that I'd love to see this.  Steve Passe also is interested.

Warner


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: HEADS UP: Destabilization due to SMP development

[Warner Losh]

In message <[EMAIL PROTECTED]> Jason Evans writes:
: Summary: -current will be destabilized for an extended period (on the order
: of months).  A tag (not a branch) will be laid down before the initial
: checkin, and non-developers should either stick closely to that tag until
: the kernel stabilizes, or expect large doses of pain.  This tag will be
: laid down as soon as June 26, 00:00 PST, with a minimum 24 hour warning
: beforehand.

Thanks for the fair warning.  Now don't do it.  Has core approved
this?  I don't think so, I've seen nothign from them about it.

The instability ni -current for MONTHS is pain not acceptible.  We've
never really allowed that in the past.  A CVS branch would be mcuh
better for this sort of thing.  I know that's a pain as well, but this 
is just for SMP people and the rest of us shouldn't have to deal with
the pain.

I understand your desire to have it all in a working tree, but causing
pain for ALL developers for potentially MONTHS isn't a reasonable
request.

Warner


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: SMP locking primities (was Re: HEADS UP: Destabilization due to SMP development)

[Julian Elischer]

Martin Cracauer wrote:
> 
> In <[EMAIL PROTECTED]>, Poul-Henning Kamp wrote:
> >
> > Am I the only person who miss a brief document which tells what
> > the outcome of the meeting was ?
> 
> Who was there, anyway?

Yeah, those of us who couldn't make it are kinda (to say the least)
interested in what was said/decided...!!

> 
>

-- 
  __--_|\  Julian Elischer
 /   \ [EMAIL PROTECTED]
(   OZ) World tour 2000
 )_.---._/  presently in:  Budapest
v


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: SMP locking primities (was Re: HEADS UP: Destabilization due to SMP development)

[Martin Cracauer]

In <[EMAIL PROTECTED]>, Poul-Henning Kamp wrote: 
> 
> Am I the only person who miss a brief document which tells what
> the outcome of the meeting was ?

Who was there, anyway?

Martin
-- 
%
Martin Cracauer <[EMAIL PROTECTED]> http://www.cons.org/cracauer/
BSD User Group Hamburg, Germany http://www.bsdhh.org/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: SMP locking primities (was Re: HEADS UP: Destabilization due to SMP development)

[Poul-Henning Kamp]

Am I the only person who miss a brief document which tells what
the outcome of the meeting was ?

Can we get to see the slides ?

Audio ?

Video ?

--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: SMP locking primities (was Re: HEADS UP: Destabilization due to SMP development)

[Matthew Dillon]

:On this page, you say:
:
:  The algorithms described on this page are essentially the BSDI algorithms
:  plus accomodations we disussed at the Yahoo SMP meeting. However, I did
:  not do a direct port. I did a from-scratch rewrite because, simply put,
:  it was easier for me. The variables are named differently but I attempt
:  to follow the same API. All the work is subject to change... the point is
:  to make it work first, then clean it up later.
:
:Does this include the locking primitives?  In the case of the locking
:primitives, there is functionality that we definitely need, such as the
:witness code, and it probably would save effort to use the BSD/OS code.
:I'm guessing that you are actually using the BSD/OS code in this case; I'm
:just looking for clarification.
:
:Thanks,
:Jason

The API is very similar, and when I clean it up it should be possible
to make it exactly the same, but SPL/CPL/INTERRUPT considerations 
make using the BSDI code verbatim impossible.

Basically I rewrote the core mutex code but I used *everything* that
was discussed at the meeting in the implementation, so all the features
that we need are there.  Spin locks, blocking locks, Giant lock
save/restore integrated into the scheduler, quick-attempt in an
inline then a call to a real procedure if it fails, using the low 2
bits of the mutex lock field to implement a 'held' bit and a 'contested'
bit (which works really wonderfully, I might add!  I would never have
thought of doing things that way myself!).

I am trying to keep it close enough that we can add the witness code
in, but before I do that I want to get the system semi-stable.
In some respects it's actually easier for us with FreeBSD
because we are keeping the spl*() system intact for a while.

The witness code is going to be critical for the unwinding work (moving
things out of the Giant mutex and into their own mutexes).  It isn't
critical for this first stage which basically just puts everything
under the Giant lock and doesn't *have* any other mutexes beyond 
SchedMutex and GiantMutex.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

SMP locking primities (was Re: HEADS UP: Destabilization due to SMP development)

[Jason Evans]

On Mon, Jun 19, 2000 at 05:34:47PM -0700, Matthew Dillon wrote:
> Ok, I have put up a web page that will track my efforts.
> 
>   http://apollo.backplane.com/FreeBSDSmp/

On this page, you say:

  The algorithms described on this page are essentially the BSDI algorithms
  plus accomodations we disussed at the Yahoo SMP meeting. However, I did
  not do a direct port. I did a from-scratch rewrite because, simply put,
  it was easier for me. The variables are named differently but I attempt
  to follow the same API. All the work is subject to change... the point is
  to make it work first, then clean it up later.

Does this include the locking primitives?  In the case of the locking
primitives, there is functionality that we definitely need, such as the
witness code, and it probably would save effort to use the BSD/OS code.
I'm guessing that you are actually using the BSD/OS code in this case; I'm
just looking for clarification.

Thanks,
Jason


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: HEADS UP: Destabilization due to SMP development

[Matthew Dillon]

:Summary: -current will be destabilized for an extended period (on the order
:of months).  A tag (not a branch) will be laid down before the initial
:checkin, and non-developers should either stick closely to that tag until
:the kernel stabilizes, or expect large doses of pain.  This tag will be
:laid down as soon as June 26, 00:00 PST, with a minimum 24 hour warning
:beforehand.
:
:---
:
:Last week, approximately 20 BSD developers got together and discussed how
:to move FreeBSD's SMP support to the next level.  Our effort will be
:largely based on the work that has been done in BSD/OS, which should make
:things go much more smoothly than they otherwise might, but we still expect
:-current to be destabilized for an extended period of time.
:
:Matthew Dillon is currently working on the locking primitives, as well as
:some changes to the way our top-level kernel locking works.  His initial
:code will not remove spl()s.  This code will probably be committed as the
:...

Thank you Jason!

Ok, I have put up a web page that will track my efforts.

http://apollo.backplane.com/FreeBSDSmp/

I got a slow start on the weekend, but I expect to have my piece
commitable this week sometime.  When I say committable I mean: won't
crash the system outright but will still probably panic due to legacy
spl*() issues, which we will fix as we see them.

I am making good progress.  In many respects it is actually easier to
get the stuff working on a single-cpu system first since all the MP
mechanisms must now work on a single-cpu system due to the preemptive
kernel scheduling, but I expect I will have both single and multi-cpu
systems working more or less (non-inclusive of interrupt threads, which
is going to be Greg's baby, but hopefully with all the support Greg
needs to implement them) in the next few days.

When I get a little further along I will start making patch sets
available on the same page.  Probably in the next day or two.

:Device driver maintainers will be able to convert device drivers over a
:period of several months.  We expect to have a compatibility shim in place
:initially, but there will be a hard cutoff date sometime before the release
:of FreeBSD 5.0 where the compatibility shim is removed.  Before getting too
:excited about this part of the conversion to a threaded kernel, please keep
:in mind that 1) there will be plenty of time to do this conversion, 2) the
:conversion is pretty trivial for most drivers, and 3) as we get to the
:stage where the conversion becomes possible, there will be much more detail
:about how to do the conversion, as well as the working examples of the
:first drivers to be converted.

I believe I found a way to isolate the legacy spl*() stuff without too 
much interference with the overall design plan (see my document), but
I will be the second to say that the legacy stuff is ALL going to be
ripped out for the 5.0 release.

I would ask that people not commit major changes to the -current sys tree
until after we lay down the tags and get the new MP core in place.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: HEADS UP: Destabilization due to SMP development

[Michael Lucas]

>   On a totally non-technical, but somewhat related note, can anyone 
> give me any kind of idea how often relatively "large scale" changes 
> like this typically occur with FreeBSD?

IIRC, this is the biggest operation of its sort since 2.1.

Can't comment on anything before then, I wasn't around.

==ml


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: HEADS UP: Destabilization due to SMP development

[Brad Knowles]

At 11:53 AM -0700 2000/6/19, Jason Evans wrote:

>  Last week, approximately 20 BSD developers got together and discussed how
>  to move FreeBSD's SMP support to the next level.  Our effort will be
>  largely based on the work that has been done in BSD/OS, which should make
>  things go much more smoothly than they otherwise might, but we still expect
>  -current to be destabilized for an extended period of time.

Wow.  Cool.  Way cool.

My mind is already beginning to boggle, just thinking of what 
very little I know of what must go into a process like this


On a totally non-technical, but somewhat related note, can anyone 
give me any kind of idea how often relatively "large scale" changes 
like this typically occur with FreeBSD?

By the time I came along, I think -CURRENT was already well into 
4.x, so I don't have that kind of history to fall back on.  I'm just 
intensely curious to know how often "revolutions" of this kind of 
scale typically happen within this project.


I can't wait to see the discussions go on with relation to all 
this stuff!  However, if you don't mind I think I'll continue to 
track RELENG_4 and listen over here to get some idea of what may be 
ultimately coming down the pike over there for -STABLE.

--
   These are my opinions -- not to be taken as official Skynet policy
==
Brad Knowles, <[EMAIL PROTECTED]>|| Belgacom Skynet SA/NV
Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124
Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels
http://www.skynet.be || Belgium


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

HEADS UP: Destabilization due to SMP development

[Jason Evans]

Summary: -current will be destabilized for an extended period (on the order
of months).  A tag (not a branch) will be laid down before the initial
checkin, and non-developers should either stick closely to that tag until
the kernel stabilizes, or expect large doses of pain.  This tag will be
laid down as soon as June 26, 00:00 PST, with a minimum 24 hour warning
beforehand.

---

Last week, approximately 20 BSD developers got together and discussed how
to move FreeBSD's SMP support to the next level.  Our effort will be
largely based on the work that has been done in BSD/OS, which should make
things go much more smoothly than they otherwise might, but we still expect
-current to be destabilized for an extended period of time.

Matthew Dillon is currently working on the locking primitives, as well as
some changes to the way our top-level kernel locking works.  His initial
code will not remove spl()s.  This code will probably be committed as the
first step, as soon as June 26, 00:00 PST, and Peter Wemm will lay a tag
down just beforehand.  We will give at least 24 hours notice before the tag
is laid down.  Be forewarned: if you are doing anything with -current
besides FreeBSD development, you will probably want to stop tracking
-current at that point for a while.

Greg Lehey will be working on the initial cutover to interrupt threads (as
well as the lazy interrupt thread context switching code later on).  spl()s
will go away as soon as interrupt threads start working.  Once interrupt
threads are working, most of the remaining work of threading the kernel
will be able to go on in parallel.

Device driver maintainers will be able to convert device drivers over a
period of several months.  We expect to have a compatibility shim in place
initially, but there will be a hard cutoff date sometime before the release
of FreeBSD 5.0 where the compatibility shim is removed.  Before getting too
excited about this part of the conversion to a threaded kernel, please keep
in mind that 1) there will be plenty of time to do this conversion, 2) the
conversion is pretty trivial for most drivers, and 3) as we get to the
stage where the conversion becomes possible, there will be much more detail
about how to do the conversion, as well as the working examples of the
first drivers to be converted.

The addition of kernel support for scheduler activations is generally a
separate project, but there are some interdependencies between the SMP and
scheduler activations changes, especially in the scheduler and the proc
structure.

There are many other SMP-related changes that will be made to the kernel
that are not specifically mentioned in this email, since they are not of
significant interest from a grand overview perspective.  However, there are
many details, and if you want to follow the technical discussions, you will
want to be subscribed to at least the -current and -smp mailing lists.

Finally, here are some notes about the organization of this effort.  I was
cajoled into acting as the manager of this effort.  That doesn't mean I'm
going to do all (or even a major part) of the work; it merely means I'm the
focal point of communications and decisions made with regard to the
project.  Right now, there are at least a dozen highly capable FreeBSD
developers that have taken an interest in working on this project.  We, as
a group, have made a number of decisions about how to attack this project.
If you want to contribute to technical aspects of the project, please jump
in.  However, consider that the general direction we're taking with the SMP
effort is the result of a number of very knowledgeable people hashing this
out over a period of two days; don't expect that direction to change in the
short-term.  So, if you have grievances about the way this project is being
run, complain to me, but please let the other developers work on this in
relative peace.

Jason


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message