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.
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
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
:
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
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,
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
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,
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
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
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
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]
All SMP/FreeBSD/BSDI work should move to the freebsd-smp list.
(I've BCC'd this to -current).
--
I now have mutexes 99% working in an SP build. I will be making
SP (single processor) patch sets available tonight or tomorrow
morning. (99% == I can boot the machine
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
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
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
On Tue, 20 Jun 2000, Warner Losh wrote:
I know that I'd love to see this. Steve Passe also is interested.
I heard that Greg Lehey was videotaping (he's currently at usenix) and
someone else had slides they were going to make available.
Kris
--
In God we Trust -- all others must submit an
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
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
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
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
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
.
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
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
In article local.mail.freebsd-current/[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
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]
In message [EMAIL PROTECTED], Jonathan Lemon writes:
In article local.mail.freebsd-current/[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
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
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
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
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
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
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
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
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
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
: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
the problem. Thanks a lot, SUMITANI-san!
Yes, this fixes panic and even 'halt -p' works as expected. 'zzz'
OK, I think many people will be happy with poweroff on SMP system, so
I'd like to commit this first. Then I'll track it down and try to fix later
in order to support suspend/resume
this and I'll commit MFC this if we have no problem with
this fix.
I love to have APM enabled SMP system with 4.1-RELEASE.
Index: bios.c
===
RCS file: /home/ncvs/src/sys/i386/i386/bios.c,v
retrieving revision 1.32
diff -u -r1.32 bios.c
is a patch to fix the problem. Thanks a lot, SUMITANI-san!
Please test this and I'll commit MFC this if we have no problem with
this fix.
I don't have an SMP + APM system around at the moment, but the
fix does look correct to me, go ahead and commit it. Thanks for
tracking this down!
--
Jonathan
Please test this and I'll commit MFC this if we have no problem with
this fix.
I don't have an SMP + APM system around at the moment, but the
fix does look correct to me, go ahead and commit it. Thanks for
tracking this down!
Thank you for reviewing this. I'm going to comit tomorrow
On Wed, 7 Jun 2000, Mitsuru IWASAKI wrote:
We're having this problem for long time (from the old 4.0-CURRENT
days), but Mr. SUMITANI discovered a bug and fixed it.
The problem was that we got worng gdt pointer for the current cpu,
then panic...
The followings is a patch to fix the problem.
A current kernel just built after a current make world
comes up with this and stops booting:
Programming 24 pins in IOAPIC #0
AP #1 (PHY# 12) failed!
panic y/n [y]
If I type n the kernel boots fine.
doing mptable cause a panic though
Thanks
Manfred
==
||
Can someone responsible for SMP please look at this PR:
http://www.FreeBSD.org/cgi/query-pr.cgi?pr=18524
This is necessary for tools like xosview, ktop etc to display per cpu
stats.
-Arun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" i
with empty bodies. I worry about optimizing for the static UP
kernel because of introducing more SMP and KLD_MODULE ifdefs, possibly it
should just be a function call in all cases.
http://io.yi.org/lock.diff
I will send-pr it if no one has any comments.
It looks quite reasonable to me.
--
D
orry about optimizing for the static UP
kernel because of introducing more SMP and KLD_MODULE ifdefs, possibly it
should just be a function call in all cases.
http://io.yi.org/lock.diff
I will send-pr it if no one has any comments.
Jake
To Unsubscribe: send mail to [EMAIL PROTECTED]
with &q
On Wed, 26 Apr 2000, Daniel O'Connor wrote:
Try buildworld on one machine and installworld on all of your production
boxes.. installworld only takes 10-20 minutes to run on my crappy IDE
disks.
Yes, that's what I'm doing now - so far the best method. But still
requires having N+1 boxes
On 26-Apr-00 Andrzej Bialecki wrote:
Yes, that's what I'm doing now - so far the best method. But still
requires having N+1 boxes (which is not a concern for me, but for someone
having e.g. 2 boxes in production this represents 1/3 increment), plus
topology allowing for using NFS mounts.
On Wed, Apr 26, 2000 at 09:33:46AM +0200, Andrzej Bialecki wrote:
Try buildworld on one machine and installworld on all of your production
boxes.. installworld only takes 10-20 minutes to run on my crappy IDE
disks.
Yes, that's what I'm doing now - so far the best method. But still
On Wed, Apr 26, 2000 at 09:33:46AM +0200, Andrzej Bialecki wrote:
On Wed, 26 Apr 2000, Daniel O'Connor wrote:
Try buildworld on one machine and installworld on all of your production
boxes.. installworld only takes 10-20 minutes to run on my crappy IDE
disks.
Yes, that's what I'm
Hi,
I said:
I am guessing that little of the above will be MFC'd into 4.0. So the issue
of the current SMP patch set should be based on its merits alone. I would
agree that they in themselves are worthy of MFCing. Lets just not kid
Mike Smith replied:
Steve Passe actually argued quite
On Mon, Apr 24, 2000 at 10:55:05PM -0400, "Brandon D. Valentine"
[EMAIL PROTECTED] wrote:
The number one excuse large third party server vendors use to justify
use of NT over Linux on their high end SMP systems is the poor
performance of Linux SMP. This is a tremendous o
On Tue, 25 Apr 2000, Vallo Kallaste wrote:
Fair enough, but as somebody (Greg Lehey if I recall) said it was taken
about 5 years for Sun to develop fine SMP support and we can't expect to
be faster. FreeBSD is quite behind of Linux on the SMP issues currently,
Linux is somewhat behind of NT
On Mon, Apr 24, 2000 at 11:56:50PM -0700, Christopher Nielsen [EMAIL PROTECTED]
wrote:
Solaris is far and away better at SMP than NT. I haven't seen NT running
on 64-cpu machines, and I certainly haven't seen it scaling very nearly
linearly to ~20 CPUs (diminishing returns start to take
: The network stack is equally easy to make MP-safe. In this case we
: have a shared lock to lookup sockets for host/port combinations and
: then fine-grained exclusive locks within those sockets. Route table
: and other high level operations could in fact remain BGL'd without
On Tue, 25 Apr 2000, Boris Popov wrote:
simple_lock* functions has breakage too. They defined as macros
for non-SMP case and as functions for SMP.
This currently apparently affects the following modules:
ccd
cd9660
msdosfs
nfs
ntfs
nwfs
vinum
All
Bill Fumerola wrote:
On Mon, Apr 24, 2000 at 04:46:43AM -0500, Richard Wackerbarth wrote:
From the USER's perspective, anything that requires me to as much as reload
a module/program that I have already installed "breaks" it.
The fact that it is only necessary to recompile it in order
provements to it's SMP get in. On
the other hand, if we can't garantee third party vendors a stable ABI,
we won't get third party vendors.
The number one excuse large third party server vendors use to justify
use of NT over Linux on their high end SMP systems is the poor
performance of
On Tue, 25 Apr 2000, Boris Popov wrote:
simple_lock* functions has breakage too. They defined as macros
for non-SMP case and as functions for SMP.
This currently apparently affects the following modules:
ccd
cd9660
msdosfs
nfs
ntfs
nwfs
vinum
On Tue, 25 Apr 2000, Wilko Bulte wrote:
On a similar note: I think one of serious drawbacks of FreeBSD's model
for updating and bugfixing the stable branch is 'make world'. It's very
inefficient and cumbersome way to do this on production machines. STABLE
is stable enough for us to be
On Tue, Apr 25, 2000 at 01:00:28PM -0500, Richard Wackerbarth wrote:
On Tue, 25 Apr 2000, Wilko Bulte wrote:
On a similar note: I think one of serious drawbacks of FreeBSD's model
for updating and bugfixing the stable branch is 'make world'. It's very
inefficient and cumbersome way to
On Tue, Apr 25, 2000 at 05:54:20PM +0200, Andrzej Bialecki wrote:
On Tue, 25 Apr 2000, Paul Richards wrote:
branch. Most commercial users are not developers, and have no interest
in anything relating to development. Professional sysadmins are
conservative creatures, they expect
On Tue, 25 Apr 2000 20:16:00 +0200, Wilko Bulte [EMAIL PROTECTED] said:
In other words: if people did a local buildworld once on a -release
sourcetree will all the executables have the same MD5 as the ones on
the -release cdrom?
No.
-GAWollman
To Unsubscribe: send mail to [EMAIL
On Tue, Apr 25, 2000 at 02:50:46PM -0400, Garrett Wollman wrote:
On Tue, 25 Apr 2000 20:16:00 +0200, Wilko Bulte [EMAIL PROTECTED] said:
In other words: if people did a local buildworld once on a -release
sourcetree will all the executables have the same MD5 as the ones on
the -release
On Tue, 25 Apr 2000 21:00:17 +0200, Wilko Bulte [EMAIL PROTECTED] said:
I love binary answers :-) Which brings me to my original point: it looks
like you can only do binary patches relative to a -release. Unless
you want to blindly patch and hope for the best. Rather unlikely.
I think you
On Tue, 25 Apr 2000, Wilko Bulte wrote:
In other words: if people did
a local buildworld once on a -release sourcetree will all the executables
have the same MD5 as the ones on the -release cdrom?
If you are using someone's patches, you must be patching the files that they
provided. If you
On Tue, 25 Apr 2000, Wilko Bulte wrote:
OK. But you do have to uniquely identify the binary that needs to be
patched. So, my question is when you generate 10x the same binary, will all
these 10 binaries have the same MD5 checksum? In other words: if people did
a local buildworld once on a
On Tue, 25 Apr 2000, Jake Burkholder wrote:
On Tue, 25 Apr 2000, Boris Popov wrote:
simple_lock* functions has breakage too. They defined as macros
for non-SMP case and as functions for SMP.
This currently apparently affects the following modules:
ccd
cd9660
On Tue, 25 Apr 2000, Wilko Bulte wrote:
OK. But you do have to uniquely identify the binary that needs to be
patched. So, my question is when you generate 10x the same binary, will all
these 10 binaries have the same MD5 checksum? In other words: if people did
a local buildworld once on a
On Tue, 25 Apr 2000, Brandon D. Valentine wrote:
The only way something like this is feasible is if the binaries
themselves contain information about what version they are. In other
words some sort of a header in the binary which contains the RCS version
number the binary was compiled from
On a similar note: I think one of serious drawbacks of FreeBSD's model
for
updating and bugfixing the stable branch is 'make world'. It's very
inefficient and cumbersome way to do this on production machines.
STABLE
is stable enough for us to be able to prepare binary patches, which
be compiled
with null implementations for UP, or the 'lock'ed implementations for SMP.
kobj is a nice interface (I'm converted my NLS kernel module to
use it), but may be unsuitable for lock family functions due to an
additinal overhead invloved in the method call. I think that the
empty
On Tue, 25 Apr 2000, Kris Kennaway wrote:
You've never run ident(1), right? :)
Very cool! No I hadn't. I was working with the assumption that it was
probably possible, but I know very little about how RCS actually works.
I just know that it does work and that's always been enough for me to
The RCS info stored in the binaries is insufficient for this purpose. There is
no record of the versions of all included files. Changes to constants and/or
macros would not be identifiable.
Jim Bloom
[EMAIL PROTECTED]
Kris Kennaway wrote:
On Tue, 25 Apr 2000, Brandon D. Valentine wrote:
:I'm sure that something can be done for the kld compatibility issues
:so that you can have your SMP cake and eat it too. Just give it a bit
:more thought. :)
:
:- Jordan
Thought I have. Time I don't. While I don't particularly see a
problem staying compatible with KLD modules that do
On Mon, 24 Apr 2000, Matthew Dillon wrote:
: However, I consider your SMP changes VERY destablizing; they BREAK
: lots of modules :-(
Huh? No they don't. They simply require recompiling the modules. If
they actually broke the modules I wouldn't be trying to MFC it to
-stable
On Sun, 23 Apr 2000, Matthew Dillon wrote:
:I'm sure that something can be done for the kld compatibility issues
:so that you can have your SMP cake and eat it too. Just give it a bit
:more thought. :)
:
:- Jordan
Thought I have. Time I don't. While I don't particularly see
Richard Wackerbarth wrote:
On Mon, 24 Apr 2000, Matthew Dillon wrote:
: However, I consider your SMP changes VERY destablizing; they BREAK
: lots of modules :-(
Huh? No they don't. They simply require recompiling the modules. If
they actually broke the modules I wouldn't
On Mon, 24 Apr 2000, Jeroen C. van Gelderen wrote:
I don't think it was ever recommended that you upgrade your kernel
without upgrading and rebuilding the modules (better still, world) at
the same time. So this wouldn't really have an adverse effect, would it?
Such a policy is totally
Richard Wackerbarth wrote:
On Mon, 24 Apr 2000, Matthew Dillon wrote:
: However, I consider your SMP changes VERY destablizing; they BREAK
: lots of modules :-(
Huh? No they don't. They simply require recompiling the modules. If
they actually broke the modules I
On Mon, 24 Apr 2000, Kenneth Wayne Culver wrote:
I don't think it was ever recommended that you upgrade your kernel
without upgrading and rebuilding the modules (better still, world) at
the same time. So this wouldn't really have an adverse effect, would it?
I believe that it depends on
"Brandon D. Valentine" wrote:
On Mon, 24 Apr 2000, Alok K. Dhir wrote:
Totally off topic question that I've wondered for some time now - what
does MFC stand for?
According to the FAQ section located on the web @
http://www.freebsd.org/FAQ/misc.html#AEN3908
Q: What does 'MFC' mean?
On Mon, Apr 24, 2000 at 09:27:04AM -0500, Richard Wackerbarth wrote:
On a released system, I may not have the sources to recompile the module.
It might be a proprietary module that I got with the hardware, for example.
How real is this? What modules are we talking about? The last time
I
On Mon, 24 Apr 2000, Kenneth Wayne Culver wrote:
I don't think it was ever recommended that you upgrade your kernel
without upgrading and rebuilding the modules (better still, world) at
the same time. So this wouldn't really have an adverse effect, would it?
I believe that it
in needing to rebuild
modules. The SMP fixes are quite significant and, IMHO, are very worth
the possible short-term instability induced by them. (Although it looks
like they're quite stable.) Consider me a customer that is very interested
in these fixes even though my bread-and-but
On Mon, Apr 24, 2000 at 09:27:04AM -0500, Richard Wackerbarth wrote:
On a released system, I may not have the sources to recompile the module.
It might be a proprietary module that I got with the hardware, for example.
How real is this? What modules are we talking about? The last time
you at any moment.
Er. spl() is a public interface.
5. The SMP stuff is about _internal_ interfaces, not external ones. External
interfaces are the ones that are fixed in any OS, not the internal ones.
Otherwise, how do we make progress? The Linux ABI, btw (to refer to your
:On Mon, Apr 24, 2000 at 09:27:04AM -0500, Richard Wackerbarth wrote:
: On a released system, I may not have the sources to recompile the module.
: It might be a proprietary module that I got with the hardware, for example.
:
:How real is this? What modules are we talking about? The last time
:Because if we do not provide a STABLE ABI, we WON'T get third-party
:(binary only) kernel modules.
:
:I'm very divided in this issue. 4.x has just started, and would be
:seriously impaired if no further improvements to it's SMP get in. On
:the other hand, if we can't garantee third party
to SMP in the future
:will come from:
:
: 1: pushdown of the BGL into the read/write routines.
: 2: kernel threads.
: 3: replacement of spl() with mutex() type protection of data regions.
:
:I am guessing that little of the above will be MFC'd into 4.0. So the issue
:of the current SMP patch set
epends on its interfaces.
4. No system, released or otherwise, is a "stone house." At best it's a
wooden house (to use your terminology), since defect fixes might require
changes to internal interfaces. I know, I do this for a living.
I did too. Only we were never so casual ab
After further review I don't think there are any compatibility problems
with the spl*() mechanisms.
But I must still caution that due to the extensive nature of the
cleanup, despite being mostly internal to the kernel, there could
very well be other things that we have
On Mon, 24 Apr 2000, Alfred Perlstein wrote:
I think as a whole we need to evaluate the use of macros, they're
one of the major problems with changes like this and several people
have come forward over time with strong numbers showing that the
code bloat causes that comes with overuse of
On Mon, Apr 24, 2000 at 04:46:43AM -0500, Richard Wackerbarth wrote:
From the USER's perspective, anything that requires me to as much as reload
a module/program that I have already installed "breaks" it.
The fact that it is only necessary to recompile it in order to fix it only
means that
Matthew Dillon wrote:
So you guys (core) choose -- do you want 4.x to reap the benefits of
further SMP development or not? If you choose no, beware that without
this base cleanup there is *NO* chance whatsoever of any further SMP
work being MFC'd to 4.x. None. Zilch
Gee, is that perhaps because FreeBSD keeps breaking the ABI to modules
so every vendor that has ever tried to use them has been bitten by the
fact that they have to maintain N version for each branch of FreeBSD???
Can you list some specific examples? I'm not trying to be a wise-ass,
I'm
On Mon, 24 Apr 2000, you wrote:
On Mon, Apr 24, 2000 at 04:46:43AM -0500, Richard Wackerbarth wrote:
From the USER's perspective, anything that requires me to as much as
reload
a module/program that I have already installed "breaks" it.
The fact that it is only necessary to recompile
No-one forces you to upgrade you systems. Partial upgrades
are something that are
nice when they work, but understood when they don't.
We don't accept bug reports (typically) when a person hasn't
upgraded their world,
kernel, and modules. I don't understand why we're accepting
On Mon, Apr 24, 2000 at 02:02:28PM -0500, Richard Wackerbarth wrote:
That is also partly why you are also lacking the respect and support of a
wider audience. If you act like FreeBSD is just a "developer's sandbox",
that's what it will be. If you want it to be something greater than that,
; Richard Wackerbarth;
[EMAIL PROTECTED]
Subject: Re: SMP changes and breaking kld object module compatibility
Gee, is that perhaps because FreeBSD keeps breaking the ABI
to modules
so every vendor that has ever tried to use them has been
bitten by the
fact that they have to maintain
So you guys (core) choose -- do you want 4.x to reap the benefits of
further SMP development or not?
I've read all the feedback on this thread and now feel that it would
be worthwhile to simply bring the SMP changes in on Wednesday. As others
have pointed out, we don't have enough 3rd
601 - 700 of 933 matches
Mail list logo
