On Thu, 27 Apr 2000, Jake Burkholder wrote:
...snip...
Its nice to see someone actually using kobj so soon. There is a possible
performance problem though - kobj method calls are roughly 20% slower than
direct function calls. Having said that, this isn't that slow - I timed a
method
...snip...
Its nice to see someone actually using kobj so soon. There is a possible
performance problem though - kobj method calls are roughly 20% slower than
direct function calls. Having said that, this isn't that slow - I timed a
method call to a two argument function at ~40ns on a
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 opportunity for
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 of these
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
"Brandon D. Valentine" wrote:
On Tue, 25 Apr 2000, Daniel C. Sobral wrote:
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
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, 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 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
On Tue, 25 Apr 2000, Jake Burkholder wrote:
Has anyone thought about using kobj(9) for this?
For example, it should be possible to make simple_lock and lockmgr locks
safe for use from modules by introducing a lock_if.h, which has
abstract version of all the lock routines. A class would be
: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 a
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
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.
That is why STABLE INTERFACES are so IMPORTANT to USERS.
"Current" is a sandbox. Lower expectations are part of
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
On the _other_ hand:
1. 4.0 hasn't been out long enough for there to be any significant support
for it in proprietary systems. It takes more lead time than this.
Unfortunately, many vendors will simply install from the 4.0-RELEASE CD
and build their modules there.
3. Any proprietary
: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
:As the original author of the cil/cml code I can say I was glad to see that
:Matt
:had finally put it to rest. It was a desperate hack made in an attempt to pinch
:a little more performance out of the paradigm without dealing with the whole
:spl() problem set. I would have done it myself if
On Mon, 24 Apr 2000, Frank Mayhar wrote:
1. 4.0 hasn't been out long enough for there to be any significant support
for it in proprietary systems. It takes more lead time than this.
So make the change and release it as FreeBSD5. Save the big changes for
something called FreeBSd6 or
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. It
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
Jordan K. Hubbard writes:
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
Are there any 3rd party NIC klds yet?
NTMK.
- Jordan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
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,
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
On Mon, 24 Apr 2000, you wrote:
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
On Mon, Apr 24, 2000 at 02:14:50PM -0700, Rodney W. Grimes wrote:
Developers and early adopters are the ones tracking -STABLE. Users are
installing binary snapshots and releases.
Some users do install snapshots and/or releases. Snap shots occur on a
regular basis and are affected by
{First one bounced by hub with ``out of memory'' error... second attempt}
Are there any 3rd party NIC klds yet?
NTMK.
It's not quite a kld, but ET Inc's modules are distributed as a .o.
Also I know of work underway to support some of the fancier SDL WanNic
cards that would have to be kld's
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 Mon, 24 Apr 2000, Bill Fumerola wrote:
The entire point is that somewhere the user has decided to upgrade
their system, and they need to know what the consequences are before
taking the plunge. If they upgrade their system half-ass (kernel, but
not modules) they are digging their own
On Mon, 24 Apr 2000, Kenneth Wayne Culver wrote:
I believe that it depends on what changes were made since the last
recompile, although it is good practice to at least recompile the modules
when the kernel is recompiled.
In my opinion the best way to handle things like this is to add a
modules
On Tue, 25 Apr 2000, Daniel C. Sobral wrote:
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,
On Mon, 24 Apr 2000, Rodney W. Grimes wrote:
On Mon, Apr 24, 2000 at 09:27:04AM -0500, Richard Wackerbarth wrote:
Are all modules effected, or only those that use certain interfaces?
Given that this is a change in splxxx() I suspect that it breaks
most modules, but probably not all
On Tue, 25 Apr 2000, Bruce Evans wrote:
Given that this is a change in splxxx() I suspect that it breaks
most modules, but probably not all modules. A quick grep -l spl * | wc
Given that this is a change in the splxxx() implementation, it breaks
zero modules.
splxxx() was changed
Personally, I don't think that's a bad idea, I never had trouble going to
/usr/src/sys/modules and doing a make depend then make then make install,
but I guess it'd be nicer if everything just compiled when I built my
kernel, and better yet, it would be nice to have it make the
"modules.old"
On Sun, 23 Apr 2000, Matthew Dillon wrote:
:In that case I have a strong objection to the SMP patchset being
:merged to 4.0. I have kernel modules in object format only that
:are working now, which this would break :-(.
:
:Rod Grimes - KD7CAX @ CN85sl - (RWG25)
: [EMAIL
On Sun, 23 Apr 2000, Matthew Dillon wrote:
:Rather than break the FreeBSD4 modules over which you have no control,
:perhaps your arguments should be used to accelerate the 5.0 release
:and make 4.x a short lived branch.
I don't think this is possible. 4.0 is the most stable release
: There's another good reason to MFC the linux patch on wednesday...
: that is, to do it at the same time the SMP cleanup is MFC'd, and that
: is because both patch sets require the linux kernel module to be
: recompiled and I'd rather not force people to do that twice.
:
:
In general I agree with the concept but I think .0 releases have to
have a bit more flexibility, and that 4.0 in particular (due to the
rules change made for the BSDI merger) has to be even more flexible.
And this is something I can render an opinion on right away: I
:
:: There's another good reason to MFC the linux patch on wednesday...
:: that is, to do it at the same time the SMP cleanup is MFC'd, and that
:: is because both patch sets require the linux kernel module to be
:: recompiled and I'd rather not force people to do that twice.
:
: There's another good reason to MFC the linux patch on wednesday...
: that is, to do it at the same time the SMP cleanup is MFC'd, and that
: is because both patch sets require the linux kernel module to be
: recompiled and I'd rather not force people to do that twice.
:
:
PROTECTED]
To: Richard Wackerbarth [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: SMP changes and breaking kld object module compatibility
:
:On Sun, 23 Apr 2000, Matthew Dillon wrote:
:
: :In that case I have a strong objection to the SMP patchset being
: :merged to 4.0. I have
On Mon, Apr 24, 2000 at 12:36:45AM -0400, Alok K. Dhir wrote:
Totally off topic question that I've wondered for some time now - what
does MFC stand for?
Merge From CURRENT.
--
Will Andrews [EMAIL PROTECTED]
GCS/E/S @d- s+:++:- a---+++ C++ UB P+ L- E--- W+++ !N !o ?K w---
?O M+ V-- PS+
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?
A: MFC is an acronym for 'Merged From
75 matches
Mail list logo
