Re: SMP changes and breaking kld object module compatibility

2000-04-28 Thread Doug Rabson
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

Re: SMP changes and breaking kld object module compatibility

2000-04-27 Thread Jake Burkholder
...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

Re: SMP changes and breaking kld object module compatibility

2000-04-26 Thread Andrzej Bialecki
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

Re: SMP changes and breaking kld object module compatibility

2000-04-26 Thread Daniel O'Connor
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.

Re: SMP changes and breaking kld object module compatibility

2000-04-26 Thread David Malone
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

Re: SMP changes and breaking kld object module compatibility

2000-04-26 Thread Jesper Skriver
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

Re: SMP changes and breaking kld object module compatibility

2000-04-25 Thread Steve Passe
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

Re: SMP changes and breaking kld object module compatibility

2000-04-25 Thread Vallo Kallaste
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

Re: SMP changes and breaking kld object module compatibility

2000-04-25 Thread Christopher Nielsen
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

Re: SMP changes and breaking kld object module compatibility

2000-04-25 Thread Vallo Kallaste
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

Re: SMP changes and breaking kld object module compatibility

2000-04-25 Thread Matthew Dillon
: 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

Re: SMP changes and breaking kld object module compatibility

2000-04-25 Thread Bruce Evans
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

Re: SMP changes and breaking kld object module compatibility

2000-04-25 Thread Paul Richards
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

Re: SMP changes and breaking kld object module compatibility

2000-04-25 Thread Paul Richards
"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

Re: SMP changes and breaking kld object module compatibility

2000-04-25 Thread Jake Burkholder
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

Patchkits: Was :Re: SMP changes and breaking kld object module compatibility

2000-04-25 Thread Richard Wackerbarth
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

Re: Patchkits: Was :Re: SMP changes and breaking kld object module compatibility

2000-04-25 Thread Wilko Bulte
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

Re: SMP changes and breaking kld object module compatibility

2000-04-25 Thread Wilko Bulte
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

Re: Patchkits: Was :Re: SMP changes and breaking kld object module compatibility

2000-04-25 Thread Garrett Wollman
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

Re: Patchkits: Was :Re: SMP changes and breaking kld object module compatibility

2000-04-25 Thread Wilko Bulte
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

Re: Patchkits: Was :Re: SMP changes and breaking kld object module compatibility

2000-04-25 Thread Garrett Wollman
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

Re: Patchkits: Was :Re: SMP changes and breaking kld object module compatibility

2000-04-25 Thread Richard Wackerbarth
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

Re: SMP changes and breaking kld object module compatibility

2000-04-25 Thread Doug Rabson
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

Re: SMP changes and breaking kld object module compatibility

2000-04-25 Thread Daniel O'Connor
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

Re: SMP changes and breaking kld object module compatibility

2000-04-25 Thread Boris Popov
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

Re: SMP changes and breaking kld object module compatibility

2000-04-24 Thread Matthew Dillon
: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

Re: SMP changes and breaking kld object module compatibility

2000-04-24 Thread Richard Wackerbarth
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.

Re: SMP changes and breaking kld object module compatibility

2000-04-24 Thread Doug Rabson
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

Re: SMP changes and breaking kld object module compatibility

2000-04-24 Thread Jeroen C. van Gelderen
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

Re: SMP changes and breaking kld object module compatibility

2000-04-24 Thread Richard Wackerbarth
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

Re: SMP changes and breaking kld object module compatibility

2000-04-24 Thread Kenneth Wayne Culver
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

Re: SMP changes and breaking kld object module compatibility

2000-04-24 Thread Richard Wackerbarth
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

RE: SMP changes and breaking kld object module compatibility

2000-04-24 Thread Alok Dhir
... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Richard Wackerbarth Sent: Monday, April 24, 2000 5:47 AM To: Matthew Dillon Cc: [EMAIL PROTECTED] Subject: Re: SMP changes and breaking kld object module compatibility On Mon, 24 Apr 2000, Matthew Dillon

Re: SMP changes and breaking kld object module compatibility

2000-04-24 Thread Daniel C. Sobral
"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?

Re: SMP changes and breaking kld object module compatibility

2000-04-24 Thread Jacques A . Vidrine
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

Re: SMP changes and breaking kld object module compatibility

2000-04-24 Thread Daniel C. Sobral
Alok Dhir wrote: SMP is a significant area of weakness for 4.0 and begs for improvement. I for one am thrilled at the progress Matt's made in this area and am itching to incorporate the changes into my 4.0 development servers (my production servers are still at 3.4-STABLE pending 4.1).

Re: SMP changes and breaking kld object module compatibility

2000-04-24 Thread Kenneth Wayne Culver
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

Re: SMP changes and breaking kld object module compatibility

2000-04-24 Thread Steve Passe
Hi, 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 will have diverged too

Re: SMP changes and breaking kld object module compatibility

2000-04-24 Thread Frank Mayhar
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

Re: SMP changes and breaking kld object module compatibility

2000-04-24 Thread Rodney W. Grimes
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

Re: SMP changes and breaking kld object module compatibility

2000-04-24 Thread Mike Smith
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

Re: SMP changes and breaking kld object module compatibility

2000-04-24 Thread Matthew Dillon
: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

Re: SMP changes and breaking kld object module compatibility

2000-04-24 Thread Matthew Dillon
: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

Re: SMP changes and breaking kld object module compatibility

2000-04-24 Thread Matthew Dillon
: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

Re: SMP changes and breaking kld object module compatibility

2000-04-24 Thread Richard Wackerbarth
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

Re: SMP changes and breaking kld object module compatibility

2000-04-24 Thread Matthew Dillon
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

Re: SMP changes and breaking kld object module compatibility

2000-04-24 Thread Alfred Perlstein
* Matthew Dillon [EMAIL PROTECTED] [000424 11:15] wrote: 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

Re: SMP changes and breaking kld object module compatibility

2000-04-24 Thread Richard Wackerbarth
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

Re: SMP changes and breaking kld object module compatibility

2000-04-24 Thread Bill Fumerola
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

Re: SMP changes and breaking kld object module compatibility

2000-04-24 Thread Doug Barton
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

Re: SMP changes and breaking kld object module compatibility

2000-04-24 Thread Jordan K. Hubbard
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

Re: SMP changes and breaking kld object module compatibility

2000-04-24 Thread Richard Wackerbarth
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

RE: SMP changes and breaking kld object module compatibility

2000-04-24 Thread Alok Dhir
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

Re: SMP changes and breaking kld object module compatibility

2000-04-24 Thread Bill Fumerola
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,

RE: SMP changes and breaking kld object module compatibility

2000-04-24 Thread Alok Dhir
; 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

Re: SMP changes and breaking kld object module compatibility

2000-04-24 Thread Jordan K. Hubbard
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

Re: SMP changes and breaking kld object module compatibility

2000-04-24 Thread Andrew Gallatin
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

Re: SMP changes and breaking kld object module compatibility

2000-04-24 Thread Jordan K. Hubbard
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

Re: SMP changes and breaking kld object module compatibility

2000-04-24 Thread Rodney W. Grimes
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,

Re: SMP changes and breaking kld object module compatibility

2000-04-24 Thread Rodney W. Grimes
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

Re: SMP changes and breaking kld object module compatibility

2000-04-24 Thread Richard Wackerbarth
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

Re: SMP changes and breaking kld object module compatibility

2000-04-24 Thread Bill Fumerola
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

Re: SMP changes and breaking kld object module compatibility

2000-04-24 Thread Rodney W. Grimes
{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

Re: SMP changes and breaking kld object module compatibility

2000-04-24 Thread Jonathan M. Bresler
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

Re: SMP changes and breaking kld object module compatibility

2000-04-24 Thread Matthew N. Dodd
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

Re: SMP changes and breaking kld object module compatibility

2000-04-24 Thread Brandon D. Valentine
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

Re: SMP changes and breaking kld object module compatibility

2000-04-24 Thread Brandon D. Valentine
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,

Re: SMP changes and breaking kld object module compatibility

2000-04-24 Thread Bruce Evans
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

Re: SMP changes and breaking kld object module compatibility

2000-04-24 Thread Boris Popov
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

Re: SMP changes and breaking kld object module compatibility

2000-04-24 Thread Kenneth Wayne Culver
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"

Re: SMP changes and breaking kld object module compatibility

2000-04-23 Thread Richard Wackerbarth
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

Re: SMP changes and breaking kld object module compatibility

2000-04-23 Thread Matthew Dillon
: :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) : :

Re: SMP changes and breaking kld object module compatibility

2000-04-23 Thread Richard Wackerbarth
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

Re: SMP changes and breaking kld object module compatibility

2000-04-23 Thread David Greenman
: 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. : :

Re: SMP changes and breaking kld object module compatibility

2000-04-23 Thread Jordan K. Hubbard
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

Re: SMP changes and breaking kld object module compatibility

2000-04-23 Thread Matthew Dillon
: :: 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.

Re: SMP changes and breaking kld object module compatibility

2000-04-23 Thread Alok K. Dhir
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

Re: SMP changes and breaking kld object module compatibility

2000-04-23 Thread Will Andrews
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+

Re: SMP changes and breaking kld object module compatibility

2000-04-23 Thread Brandon D. Valentine
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