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 call to a two argument function at ~40ns on a 300MHz PII.
  
  I could improve this for some applications (including this one) by
  providing a mechanism for an application to cache the function pointer
  returned by the method lookup.
 
 Yes, this sounds interesting.  I can see that there are provisions for a
 cache in the code, and I can see from the sysctls that hits and misses
 are happening, but I can't see where the function pointers are entered
 into the cache.  Is this enabled by default?

This is enabled by default. The address of the cache entry is passed as
the second argument to kobj_lookup_method().

 
 It also might be possible to have default implementations that do
 "less than nothing", a special value could be entered in the cache that
 indicates don't call through the function pointer at all.  I don't know
 how an inline cache lookup would compare to an empty function call,
 but it might be a win when the locks are supposed to do nothing.

Thats an interesting thought. It would add a compare and branch to the
normal method dispatch case which might be too high a cost.

 
 Anyway, I've made a patch that uses Boris's suggestion of providing
 functions 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.

-- 
Doug Rabson Mail:  [EMAIL PROTECTED]
Nonlinear Systems Ltd.  Phone: +44 20 8442 9037





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-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 300MHz PII.
 
 I could improve this for some applications (including this one) by
 providing a mechanism for an application to cache the function pointer
 returned by the method lookup.

Yes, this sounds interesting.  I can see that there are provisions for a
cache in the code, and I can see from the sysctls that hits and misses
are happening, but I can't see where the function pointers are entered
into the cache.  Is this enabled by default?

It also might be possible to have default implementations that do
"less than nothing", a special value could be entered in the cache that
indicates don't call through the function pointer at all.  I don't know
how an inline cache lookup would compare to an empty function call,
but it might be a win when the locks are supposed to do nothing.

Anyway, I've made a patch that uses Boris's suggestion of providing
functions 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.

Jake





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

Andrzej Bialecki

//  [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 




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

True, depending on your setup you can do it ON your production machine :)

Or on your workstation etc..

---
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum


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

Usually you can buildworld on one production machine in advance
and then schedule downtime for when you want to installworld. Then
we usually use rdist or rsync to do keep the rest of our production
machines in sync with this master machine. This procedure has worked
quite well for us since 2.something.

It also has the advantage that if something goes pear shaped during
the upgrade, you have other machines with exact copies of all the
binaries so you can restore the machine back to it's old state
without resorting to tape.

David.


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

Or burning /usr/src/ and /usr/obj/ onto a CD after buildworld, and using
that for installworlds ...

/Jesper

-- 
Jesper Skriver, jesper(at)skriver(dot)dk  -  CCIE #5456
Work:Network manager @ AS3292 (Tele Danmark DataNetworks)
Private: Geek@ AS2109 (A much smaller network ;-)

One Unix to rule them all, One Resolver to find them,
One IP to bring them all and in the zone to bind them.


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-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 eloquently against his own decision; 
 the "real work" that actually depends heavily on this foundation is 
 almost certainly never going to come back to the 4.x branch.  Since these 
 changes don't actually bring any real improvements in and of themselves, 
  
 there's little point in merging them for their own sake.

I based my opinion on the belief that they did indeed bring in a performance
benefit (I think I remember the value of 7% being tossed around).  I took 
those numbers on face value, if correct I stand by my "decision".  I didn't 
run any
tests with code pre-Matts-changes, so I can't confirm or deny them.

My "decision" is also based purely on the technical merits of the exercise, I
have to admit I never thought much about the issues of stable ABI.  Coming 
from
where I do, I readily admit I am a poor judge of this issue...

For my post-Matts-changes tests check out:

http://www.freebsd.org/~fsmp/SMP/rbenches.html

--
Steve Passe | powered by 
[EMAIL PROTECTED] |Symmetric MultiProcessor FreeBSD




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-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 FreeBSD
 to take market share.  People are seeing the virtues of free, open
 source operating systems in the server farm and providing top notch SMP
 support in FreeBSD will help to see that we make further inroads that
 the Linux guys do.  If the BSDi code assists us in improving SMP
 performance and if the corporate backing helps our PR image, then we
 could be in for a fun ride.  This is the time to start thinking in terms
 of "What can we do better?" or we're going to lose the battle.  Sure,
 those changes could go into 5.x and be released when RELENG_5 is
 branched a year from now.  But in this business, a year is 6 months too
 late.  Think about that before you object to what appear to be vast
 improvements in the performance of the RELENG_4 branch while it is just
 getting off the ground.

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 and NT, I believe, is still behind of
Solaris for SMP. Actually, I don't know, because my Solaris 8 CD is
still on the way :(
-- 

Vallo Kallaste
[EMAIL PROTECTED]


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-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 and NT, I believe, is still behind of
 Solaris for SMP. Actually, I don't know, because my Solaris 8 CD is
 still on the way :(

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 effect around 22
cpus). Solaris has had this since at least 2.6 (when I last evaluated
this) with 2.[78] adding greater stability and more features.

-- 
Christopher Nielsen
(enkhyl|cnielsen)@pobox.com
Enkhyl on IRC



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-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 effect around 22
 cpus). Solaris has had this since at least 2.6 (when I last evaluated
 this) with 2.[78] adding greater stability and more features.

You are speaking about SPARC arhitecture, aren't you? Actually we can't
compare IA32 and 64-bit SPARC I think and after all I'm absolutely wrong
person to discuss about SPARC so I shut up now :-)
-- 

Vallo Kallaste
[EMAIL PROTECTED]


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-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
: interfering with the network stack because the network stack *already*
: caches route table lookups.
: 
:
:   might it be fair to summarize this as: you locks on data
:rather than locks on code.
:
:jmb

In a nutshell, yes.   Functional data structure locking such that
things don't trip over each other with a typical heavy load.

For example, it may well be that it makes more sense to lock hash
table chains rather then the structures stored on those chains
in some instances.  vm_page_lookup(), for example, and tsleep().

In other cases it may make sense to lock the terminal structures.
For example: vnodes, processes, pmaps, VM objects.

And in still other cases we should be able to get away with no
locking at all (in the steady-state heavy load case).  Network 
interrupts, for example, can queue packets with fixed-length 
bidirectional FIFOs.

-Matt
Matthew Dillon 
[EMAIL PROTECTED]


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-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 functions reference simple_lock() if it is not defined away.

Bruce



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-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 to fix it only
  means that it is easy to fix IF I have the source code.
 
 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 preemptive bitching.


The trouble is, if you're running a production system then there will be
cases where you really must carry out an upgrade, because of a critical
bug fix, even though as the admin you really don't want to touch a live
system.

When you're running a "stable" code base you expect to be able to patch
in these bug fixes if they're required with relatively little pain.
However, if rebuilding your kernel to incorporate a critical bug fix 3
months down the line means that you're proprietary drivers no longer
work then you're stuck between a rock and a hard place.

Stable should mean stable and stability means not changing things unless
they're critical bug fixes. Development on the stable branches has
become far too fast and loose. It *is* affecting the perception of
FreeBSD by commercial users who really aren't interested in getting new
features on stable branch, in the main if you want new features you wait
for the next major release and you go through all the hassles of
regression testing your application on the new version. That's not
something done lightly or often and breaking the stable branch and
preventing the incorporation of genuine fixes, rather than enhancements,
is not helping the adoption of FreeBSD by serious commercial users.

Paul.


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-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 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 Linux SMP.  This is a tremendous opportunity for FreeBSD
 to take market share.  People are seeing the virtues of free, open
 source operating systems in the server farm and providing top notch SMP
 support in FreeBSD will help to see that we make further inroads that
 the Linux guys do.  If the BSDi code assists us in improving SMP
 performance and if the corporate backing helps our PR image, then we
 could be in for a fun ride.  This is the time to start thinking in terms
 of "What can we do better?" or we're going to lose the battle.  Sure,
 those changes could go into 5.x and be released when RELENG_5 is
 branched a year from now.  But in this business, a year is 6 months too
 late.  Think about that before you object to what appear to be vast
 improvements in the performance of the RELENG_4 branch while it is just
 getting off the ground.

I totally disagree, my experience is that commercial users upgrade not
more than once a year and they expect things to continue working on
their chosen branch for that year and to continue to receive bug fix
support on that branch (most places upgrade much less often than once a
year).

"a year is 6 months too late" is true for development branches but it is
not the case for production code. Having a happy user base will mean
that a FreeBSD 5 with improved SMP will be anticipated and widely
adopted when it is released sometime next year (I'd hope). The more we
piss off the production users with unnecessary incompatibilities in
stable branches the more entrenched they become with their existing
releases, regardless of the improvments in later versions, because they
don't trust the project to have a professional release strategy. I've
seen this happen already and early adopters of 4.0 are going to be
really pissed off to find that there is an ABI change in a stable
branch. Most commercial users are not developers, and have no interest
in anything relating to development. Professional sysadmins are
conservative creatures, they expect professional quality code to play by
the rules of the industry and those rules are widely accepted as meaning
that stable branches do no undergo ABI changes. Such changes are
reserved for major upgrades because of the consequences and risks
involved.



Paul.


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-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
 
 All of these functions reference simple_lock() if it is not defined away.
 
 Bruce

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 compiled
with null implementations for UP, or the 'lock'ed implementations for SMP.
The old functions would call through an instance of that class, automagically
finding the right method.  Eventually this could be a runtime abstraction,
with both up and smp classes compiled into the kernel, and objects initialized 
with the right method table at boot time.

I have diffs in the works if anyone is interested.

Jake.



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



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 able to prepare binary patches, which can
  be applied to a system in some (known) version. 

 Question: are MD5 checksums the same for each and every
 build (assuming static sources obviously) or is there some timestamp (or
 something like that) in the generated binary. If there is, one could only
 create binary patches relative to a -release.

Here your logic is wrong. When I make a binary patch, I don't HAVE to update 
anything that is not substantively changed. Think "make all" rather than 
"make world". From there, it is easy enough to generate a chain of patches 
just like CTM does for the sources. 
However, is it worth the effort? I don't know.


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



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 do this on production machines. STABLE
   is stable enough for us to be able to prepare binary patches, which can
   be applied to a system in some (known) version. 
 
  Question: are MD5 checksums the same for each and every
  build (assuming static sources obviously) or is there some timestamp (or
  something like that) in the generated binary. If there is, one could only
  create binary patches relative to a -release.
 
 Here your logic is wrong. When I make a binary patch, I don't HAVE to update 
 anything that is not substantively changed. Think "make all" rather than 

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 -release sourcetree will all the executables
have the same MD5 as the ones on the -release cdrom?

 "make world". From there, it is easy enough to generate a chain of patches 
 just like CTM does for the sources. 
 However, is it worth the effort? I don't know.

I assume it is worth it to some end-users. The question is if the project
can find someone to do it ;)
-- 
Wilko Bulte Powered by FreeBSD  http://www.freebsd.org
http://www.tcja.nl


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-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 professional quality code to play by
  the rules of the industry and those rules are widely accepted as meaning
  that stable branches do no undergo ABI changes. Such changes are
  reserved for major upgrades because of the consequences and risks
  involved.

 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 can be
 applied to a system in some (known) version. Especially security fixes,
 which are usually limited to specific programs.

 With such system present I'd be completely satisfied (as a production
 manager, not as a developer) if I could start with, let's say,
 3.4-RELEASE, and then apply binary patches one by one to track
 STABLE. Instead of putting the machine out-of-service for a couple of
 hours, it would be 10 minutes. Also, no need to keep the sources
 around. Of course, implementing such a system requires careful versioning
 of each file in the standard system, but I think it's possible - just
 having the MD5 checksums around, for each consecutive patch, should do for
 start.

Number 1 problem that I see here is the amount of resources it needs to 
do this. It appears this is hardly the kind of work somebody would want to
volunteer for. Question: are MD5 checksums the same for each and every build
(assuming static sources obviously) or is there some timestamp (or something
like that) in the generated binary. If there is, one could only create
binary patches relative to a -release.

-- 
Wilko Bulte Powered by FreeBSD  http://www.freebsd.org
http://www.tcja.nl


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



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 PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



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 cdrom?
 
 No.

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.

-- 
Wilko Bulte Powered by FreeBSD  http://www.freebsd.org
http://www.tcja.nl


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



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 are right.  Doing so would still require resolving the
full dependency graph, so that programs affected by a library change
could all be identified.

-GAWollman

--
Garrett A. Wollman   | O Siem / We are all family / O Siem / We're all the same
[EMAIL PROTECTED]  | O Siem / The fires of freedom 
Opinions not those of| Dance in the burning flame
MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick


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



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 have created your own "imposters", you cannot expect to 
patch them.


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-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
  msdosfs
  nfs
  ntfs
  nwfs
  vinum
  
  All of these functions reference simple_lock() if it is not defined away.
  
  Bruce
 
 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 compiled
 with null implementations for UP, or the 'lock'ed implementations for SMP.
 The old functions would call through an instance of that class, automagically
 finding the right method.  Eventually this could be a runtime abstraction,
 with both up and smp classes compiled into the kernel, and objects initialized 
 with the right method table at boot time.
 
 I have diffs in the works if anyone is interested.

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 300MHz PII.

I could improve this for some applications (including this one) by
providing a mechanism for an application to cache the function pointer
returned by the method lookup.

-- 
Doug Rabson Mail:  [EMAIL PROTECTED]
Nonlinear Systems Ltd.  Phone: +44 20 8442 9037




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-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 can
  be
  applied to a system in some (known) version. Especially security fixes,
  which are usually limited to specific programs.

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.

---
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum


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-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 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-body functions will be more efficient in this case.

--
Boris Popov



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 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 spl*() calls,
It's several day's worth of additional work when we go through
the whole review / test / test-again process.  I've already gone
through this process for what was committed to -current and I have
already tested the patches under 4.x.  I do not have time to go 
through it yet again due to having to make additional difficult-to-test
changes.

If this is an issue I suppose core can vote on whether the SMP 
cleanup should be MFC'd to 4.x.  I've already laid out all the 
reasons why I think it's a good idea to do.  I don't have the 40 
man-hours it will take to guarentee compatibility with existing kld's
(even if most are probably already compatible) so if you make that
a requirement, the result will be no MFC at all.

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

-Matt
Matthew Dillon 
[EMAIL PROTECTED]


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

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 it is easy to fix IF I have the source code.


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 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
 problem staying compatible with KLD modules that do spl*() calls,
 It's several day's worth of additional work when we go through
 the whole review / test / test-again process.  I've already gone
 through this process for what was committed to -current and I have
 already tested the patches under 4.x.  I do not have time to go 
 through it yet again due to having to make additional difficult-to-test
 changes.
 
 If this is an issue I suppose core can vote on whether the SMP 
 cleanup should be MFC'd to 4.x.  I've already laid out all the 
 reasons why I think it's a good idea to do.  I don't have the 40 
 man-hours it will take to guarentee compatibility with existing kld's
 (even if most are probably already compatible) so if you make that
 a requirement, the result will be no MFC at all.
 
 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
 much.  

Personally (i.e. not speaking for core), I really want to preserve both
the API and ABI for as many kernel interfaces as possible in the 4.x
branch. This does restrict the kinds of work which can be done on 4.x but
I'm convinced that this will improve both the percieved ("I recompiled my
kernel and now it panics on boot - this sucks") and actual stability of
the system.

-- 
Doug Rabson Mail:  [EMAIL PROTECTED]
Nonlinear Systems Ltd.  Phone: +44 20 8442 9037




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 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 be trying to MFC it to
  -stable.
 
 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 it is easy to fix IF I have the source code.

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?

Cheers,
Jeroen


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 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 unacceptable for "released" systems.
Pre-release, I can accept it because the interfaces are still being tested 
and redesigned as needed.

However, once a system is released, the users MUST have the ability to
upgrade parts of the system without rebuilding everything.
In fact, the user may be unable to rebuild parts of the system because
he lacks the resources, be they hardware or source code.

In particular, I, as a user, need to be able to purchase proprietary code
and expect to be able to run it on a system. I further expect to be able to
upgrade the kernel or shared libraries within the same release series 
and still use the same binary of the proprietary program.

If this were not the case, we could argue that there is no need for the 
"linux compatability modes. Every Linux binary could just be recompiled
into the FreeBSD format.


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 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 wouldn't be trying to MFC it to
   -stable.
  
  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 it is easy to fix IF I have the source code.
 
 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 what changes were made since the last
recompile, although it is good practice to at least recompile the modules
when the kernel is recompiled.


=
| Kenneth Culver  | FreeBSD: The best OS around.|
| Unix Systems Administrator  | ICQ #: 24767726 |
| and student at The  | AIM: muythaibxr |
| The University of Maryland, | Website: (Under Construction)   |
| College Park.   | http://www.wam.umd.edu/~culverk/|
=



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 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 what changes were made since the last
 recompile, although it is good practice to at least recompile the modules
 when the kernel is recompiled.

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 that game.
But released systems are stone houses, not sandcastles.


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 Alok Dhir


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

If recompiling bothers you so much, we can have make a tarball distribution
of the new module binaries. There - problem solved.

People are going to have to recompile their kernels also, in order to get
the SMP changes.  Why is it such a stretch to require recompiling the kernel
modules as well?

My 2 cents...

 -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 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.
 
 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 it is easy to fix IF I have the source code.
 
 
 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 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?
 
 A: MFC is an acronym for 'Merged From -CURRENT.' It's used in the CVS
 logs to denote when a change was migrated from the CURRENT to the STABLE
 branches.
 
 A quick search for MFC right from the freebsd.org main page would have
 returned this information.

And me, all this time thinking it was Mitigate Freaking Cronies! ;-)

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

GPL certainly doesn't meet Janis Joplin's definition of freedom:
"Freedom is just another word for nothing left to lose."


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 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 queried on `-stable' for users of third-party modules, only one was
revealed.

Are all modules effected, or only those that use certain interfaces?

 That is why STABLE INTERFACES are so IMPORTANT to USERS.

Agreed.
-- 
Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED]


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 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).
 
 If recompiling bothers you so much, we can have make a tarball distribution
 of the new module binaries. There - problem solved.
 
 People are going to have to recompile their kernels also, in order to get
 the SMP changes.  Why is it such a stretch to require recompiling the kernel
 modules as well?

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 vendors a stable ABI,
we won't get third party vendors.

Alas... Dillon, how much of SMP improvements will be getting back-ported
without further breaks in ABI, specially as BSDI code starts to trickle
in?

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

GPL certainly doesn't meet Janis Joplin's definition of freedom:
"Freedom is just another word for nothing left to lose."


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

Yeah, I understand that. I was talking about -current.


=
| Kenneth Culver  | FreeBSD: The best OS around.|
| Unix Systems Administrator  | ICQ #: 24767726 |
| and student at The  | AIM: muythaibxr |
| The University of Maryland, | Website: (Under Construction)   |
| College Park.   | http://www.wam.umd.edu/~culverk/|
=



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

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 life hadn't taken me down a 
path where I have too little time for these things...

I've been playing with test buildworlds on my server and have concluded that
we are currently kernel (big giant lock?) bound.  In my tests 3 CPUs actually
complete buildworld faster than 4.  The major solutions 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 should be based on its merits alone.  I would
agree that they in themselves are worthy of MFCing.  Lets just not kid 
ourselves about major future improvements of SMP in 4.0, the biggies I
enumerate above just won't happen there.

--
Steve Passe | powered by 
[EMAIL PROTECTED] |Symmetric MultiProcessor FreeBSD




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 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 that game.
 But released systems are stone houses, not sandcastles.

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.
2. Significant enhancements are often worth the price 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-butter system will need to be
   rebuilt.
3. Any proprietary module that depends so heavily upon kernel internals is,
   IMNSHO, broken by definition.  If one is writing a proprietary module,
   particularly for an open-source system, one should write to the lowest
   common denominator and _not_ to internal interfaces that could change
   out from under you at any moment.
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.
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
   previous message on the subject), is a set of _external_ interfaces, not
   internal ones.

Number six is probably better unsaid.
-- 
Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/


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

 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 queried on `-stable' for users of third-party modules, only one was
 revealed.

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

 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 modules.  A quick grep -l spl * | wc
vs ls | wc shows 77 out of 100, not exact due to probable false hits on
spl, but it gets us the ball park, significant is what is says.


-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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 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 module that depends so heavily upon kernel internals is,
IMNSHO, broken by definition.  If one is writing a proprietary module,
particularly for an open-source system, one should write to the lowest
common denominator and _not_ to internal interfaces that could change
out from under 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
previous message on the subject), is a set of _external_ interfaces, not
internal ones.

See above.

Steve Passe actually argued quite eloquently against his own decision; 
the "real work" that actually depends heavily on this foundation is 
almost certainly never going to come back to the 4.x branch.  Since these 
changes don't actually bring any real improvements in and of themselves, 
there's little point in merging them for their own sake.

The _only_ reason to bring these changes back is if we're contemplating 
massive changes in 4.x's SMP support, and if we're willing to live with 
the significant compatibility churn this is going to cause.  Nobody yet 
has suggested that this is the case, and I do not believe that it is.

-- 
\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
\\ Tell him he should learn how to fish himself,  \\  [EMAIL PROTECTED]
\\ and he'll hate you for a lifetime. \\  [EMAIL PROTECTED]




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 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
:I queried on `-stable' for users of third-party modules, only one was
:revealed.
:
:Are all modules effected, or only those that use certain interfaces?
:
: That is why STABLE INTERFACES are so IMPORTANT to USERS.
:
:Agreed.
:-- 
:Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED]

Many kernel interfaces are macros.  So while the API stays the same,
the actual implementation winds up buried in the module code.  If the 
implementation has to change (even though the API does not), those
modules must be recompiled.  This is an unfortunate fact of life
when it comes to kernel loadable modules and is true of both Linux
and FreeBSD.

I've done a quick audit of the spl code and I think I'm actually 
wrong there... it looks like the SPL code is in fact implemented as
a procedure ( I remembered it being a macro but it actually isn't from
the point of view of modules that use it). 

So I think we're safe in this particular case.

-Matt
Matthew Dillon 
[EMAIL PROTECTED]


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 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 vendors a stable ABI,
:we won't get third party vendors.
:
:Alas... Dillon, how much of SMP improvements will be getting back-ported
:without further breaks in ABI, specially as BSDI code starts to trickle
:in?
:
:-- 
:Daniel C. Sobral   (8-DCS)

Most of the SMP innards are invisible to the user and even invisible
(for the most part) to KLD's.  For example, making the VM subsystem and
network stack MP-safe can probably be done without any external 
visibility.

-Matt
Matthew Dillon 
[EMAIL PROTECTED]


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 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 life hadn't taken me down a 
:path where I have too little time for these things...
:
:I've been playing with test buildworlds on my server and have concluded that
:we are currently kernel (big giant lock?) bound.  In my tests 3 CPUs actually
:complete buildworld faster than 4.  The major solutions 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 should be based on its merits alone.  I would
:agree that they in themselves are worthy of MFCing.  Lets just not kid 
:ourselves about major future improvements of SMP in 4.0, the biggies I
:enumerate above just won't happen there.
:
:--
:Steve Passe| powered by 
:[EMAIL PROTECTED]|Symmetric MultiProcessor FreeBSD

This is my feeling too.  I think there is a very good chance that we
would be able to MFC SMP work for the Network stack and VM subsystem,
for example.  The SMP work under 4.x and 5.x wound up getting stalled in 
part because there were three or four different versions of each core
assembly module in #ifdef's to handle all the different options 
combinations, and it got to the point where I think only three or four 
people really knew what was going on in there.

From an algorithmic and testing point of view, what the cml and cil
changes taught us is that segregating the spin locks doesn't improve
performance because programs tend to repeat the use of a particular
entry point over and over again (like calling read() or write()), and
thus wind up competing for the same spin lock anyway.  Basically it
told us that region-based locks don't produce significant performance
improvements and we have to get rid of the high level locks entirely to 
make things reasonably efficient.

The network stack and VM system are a particularly good fit to this
because locking can occur at a much finer grain.  vm_page_t/vm_object
lookups can almost run MP-safe now with only the addition of a 
shared lock at the vm_object and VM page cache level to allow lookups.
Pages are already individually locked and that mechanism need not
change.  There are a bunch of areas where the VM system is running at
splvm() in order to be able to lookup pages without busying them which
would have to change, but that isn't a huge deal.

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
interfering with the network stack because the network stack *already*
caches route table lookups.

The KISS principle applies to SMP big-time.

-Matt
Matthew Dillon 
[EMAIL PROTECTED]



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 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 FreeBSD2000, or ...
The vendors can simply say "we don't support" FreeBSD4.
The confusion factor for users is real. This module works with FreeBSD4 
kernels, but only those after April 26, 2000 just doesn't "sell".

 2. Significant enhancements are often worth the price
I'm not against "progress". It's just how it gets packaged.

 3. Any proprietary module that depends so heavily upon kernel internals is,
IMNSHO, broken by definition.  If one is writing a proprietary module,
particularly for an open-source system, one should write to the lowest
common denominator and _not_ to internal interfaces that could change
out from under you at any moment.
As I understand it, it's not a fundamental change to the interface that 
"bites". A simple recompile will "fix" most modules. Every module that 
exchanges information with the kernel depends 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 about changing interfaces after a 
release.

 5. The SMP stuff is about _internal_ interfaces, not external ones.
Internal vs External is administrative. Any time one organization provides
one piece and another provides the other, the interface is, by definition, 
external. Loadable kernel modules can come for multiple sources. Therefore 
the interface to them is external.


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 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 overlooked which might still cause
problems with third party modules that aren't recompiled.  The real answer
has changed from "There will be problems" to "There may be problems".

-Matt



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 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 kernel, there could
 very well be other things that we have overlooked which might still cause
 problems with third party modules that aren't recompiled.  The real answer
 has changed from "There will be problems" to "There may be problems".

If spl is actually a function and not a macro we should be fine.

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 macros causes problems
with the I cache where inlining really doesn't pay off.  Most archs
nowadays have pretty good support for leaf functions or have cheap
calls instructions.

Just food for thought.

-- 
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
"I have the heart of a child; I keep it in a jar on my desk."


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 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 macros causes problems
 with the I cache where inlining really doesn't pay off.  Most archs
 nowadays have pretty good support for leaf functions or have cheap
 calls instructions.

Macros CAN generate function calls :-)


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 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 it is easy to fix IF I have the source code.

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

-- 
Bill Fumerola - Network Architect
Computer Horizons Corp - CVM
e-mail: [EMAIL PROTECTED] / [EMAIL PROTECTED]
Office: 800-252-2421 x128 / Cell: 248-761-7272





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 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 will have diverged too
 much.

I think that we can find a middle ground on this issue. Jordan made an
excellent point in that this ".0" release has had more early adopters
than any previous first release on a new branch. Therefore we want to
take extra care to maintain the "-stable" perception of the 4.0-Stable
branch. At the same time, Matt is correct in saying that the base of the
SMP improvements needs to go into 4.0 now. The PR ramifications alone
would be disastrous if the only place the SMP improvements were
available was 5.0-Current. That would simply reinforce the perception
that FreeBSD is nothing more than a toy for the developers. 

On the third hand (so to speak) is the fact that we really would like
to be able to present a stable external interface to encourage third
party developers to develop to the 4.x branch. So, my suggested
compromise is this. Do the MFC now, with the caveat that this will be
the only external interface change in 4.x-Stable. Architect out whatever
changes have to happen, and make sure that the best guess as to what the
interface should be gets committed, then stick to it, no matter how
painful it is. It's still early enough to get away with this, but we can
only "sell it" once, so let's get it right this time.

I've got a fleet of SMP boxes at work, and given the coming instability
of -Current I'd really like to stick with 4.0-Stable if I can, and in
fact I've already made plans that relied on the work Matt's already done
being MFC'ed as previously announced. I could probably justify the
development time to track -Current if the performance gains were large
enough, and in fact I'll probably put a machine or two on it to try and
make a contribution to testing, etc. But speaking as a sysadmin the
advantages of being able to rely on well tested changes that get MFC'ed
on a regular basis for the majority of my machines would be a huge win.

Doug
-- 
Excess on occasion is exhilarating.  It prevents moderation from
acquiring the deadening effect of a habit.
-- W. Somerset Maugham


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 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 trying to figure out which vendors are using KLDs in general since
I've still yet to actually bump into a real-life example of this kind
of breakage in the field.  I'm not saying that it's never happened,
I'm simply saying that I've not seen it and would like some details on
such incidents - company name and module type will do fine.

- 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 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 it in order to fix it
  only means that it is easy to fix IF I have the source code.

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

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, you
must consider what you are doing to third party developers and end users.


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

Very well said.



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 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, you
 must consider what you are doing to third party developers and end users.

Developers and early adopters are the ones tracking -STABLE. Users are installing
binary snapshots and releases.

No-one in their right mind would release a module for "4.0-STABLE sometime between
april and may". They release for 4.0-RELEASE or 4.1-RELEASE, this would not cause
problems for those people.

-- 
Bill Fumerola - Network Architect
Computer Horizons Corp - CVM
e-mail: [EMAIL PROTECTED] / [EMAIL PROTECTED]
Office: 800-252-2421 x128 / Cell: 248-761-7272





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 Alok Dhir

One (relatively minor) example is Open Sound System...

http://www.opensound.com/freebsd.html

Al

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]]On Behalf Of Jordan 
 K. Hubbard
 Sent: Monday, April 24, 2000 2:58 PM
 To: Rodney W. Grimes
 Cc: Jacques A . Vidrine; 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 N version for each branch 
 of FreeBSD???
 
 Can you list some specific examples?  I'm not trying to be a wise-ass,
 I'm trying to figure out which vendors are using KLDs in general since
 I've still yet to actually bump into a real-life example of this kind
 of breakage in the field.  I'm not saying that it's never happened,
 I'm simply saying that I've not seen it and would like some details on
 such incidents - company name and module type will do fine.
 
 - Jordan
 
 
 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 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 party 4.0 klds yet (I'd have
a hard time even saying "any") to make this a real problem so let's
just go for it.

- 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 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
  have pointed out, we don't have enough 3rd party 4.0 klds yet (I'd have
  a hard time even saying "any") to make this a real problem so let's
  just go for it.

Are there any 3rd party NIC klds yet?

If we're going to be having a module flag day, I'm thinking that it
might be a good time to MFC Jonathan Lemon's checksum offloading code.
Doing this would require changing MSIZE to 256, which in turn would
require recompiling any module using mbufs (all NICs, network
filesystems, etc).

Cheers,

Drew

--
Andrew Gallatin, Sr Systems Programmer  http://www.cs.duke.edu/~gallatin
Duke University Email: [EMAIL PROTECTED]
Department of Computer Science  Phone: (919) 660-6590





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 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,
 I'm trying to figure out which vendors are using KLDs in general since
 I've still yet to actually bump into a real-life example of this kind
 of breakage in the field.  I'm not saying that it's never happened,
 I'm simply saying that I've not seen it and would like some details on
 such incidents - company name and module type will do fine.

I have never been able to keep our ET Inc based routers any where near
up to date as far as kernels go, no, they don't use kld's, they use .o's,
but it is caused by the same set of problems.

I do know from interacting with Dennis at ET Inc that the changes
in the interfaces of the FreeBSD kernel have kept him from even trying to
be very up to date with driver code.

I also have a kld from a source I can't say, to support hardware I can't tell
about...  (No, this is not a straw man, it's called NDA red tape :-().

-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

 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, you
  must consider what you are doing to third party developers and end users.
 
 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 this change in API.

 No-one in their right mind would release a module for "4.0-STABLE sometime
 between april and may". They release for 4.0-RELEASE or 4.1-RELEASE,
 this would not cause problems for those people.

Ahh.. the problem occurs with user Z running snap 4.0-stable 4/30 when trying
to use vendor X module for 4.0-release.  Get it??

-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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 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 to be something
   greater than that, you must consider what you are doing to third party
   developers and end users.
 
  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 this change in API.

  No-one in their right mind would release a module for "4.0-STABLE
  sometime between april and may". They release for 4.0-RELEASE or
  4.1-RELEASE, this would not cause problems for those people.

 Ahh.. the problem occurs with user Z running snap 4.0-stable 4/30 when
 trying to use vendor X module for 4.0-release.  Get it??
I certainly do. Your "attribute deamon" left out one level of identification.

There are two problems here:

1) How often do the interfaces change?
IMHO, too often. These sandboxers have no concept of third party issues.

2) How do we identify the version of the interface?
Even if we ignore the number of "different interfaces", being able to readily
recognize which one a customer has is important.

Maybe the developers need to be sentenced to a tour on the customer service 
lines. It might open their eyes.


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 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 this change in API.

If they use the module from the same snapshot/release, it's not a problem.

  No-one in their right mind would release a module for "4.0-STABLE sometime
  between april and may". They release for 4.0-RELEASE or 4.1-RELEASE,
  this would not cause problems for those people.
 
 Ahh.. the problem occurs with user Z running snap 4.0-stable 4/30 when trying
 to use vendor X module for 4.0-release.  Get it??

When the requirements for software are "FooBaz Version 1.2" that means "FooBaz Version
1.2".

If the vendor markets software as "FreeBSD version 4.0 or later", that's their problem.

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

If they have 3rd party modules, they need to understand that those modules may not
work if you're tracking changes. That's life. I don't expect my 3rd party voodoo 3000
drivers for Win98 to work in Win2000 either.

-- 
Bill Fumerola - Network Architect
Computer Horizons Corp - CVM
e-mail: [EMAIL PROTECTED] / [EMAIL PROTECTED]
Office: 800-252-2421 x128 / Cell: 248-761-7272





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

{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 or .o's as well, due to NDA on parts
of the code used to develope them.



-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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 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
 interfering with the network stack because the network stack *already*
 caches route table lookups.
 

might it be fair to summarize this as: you locks on data
rather than locks on code.

jmb


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

More to the point, until the module versioning and dependency stuff hits
the tree, KLD modules remain a useful novelty.  I wouldn't consider them
to be at all appropriate for production systems right now.  The only
reliable way to insure that a given module works with a given kernel is to
build them from the same source tree at the same time. /strong opinion

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter | This Space For Rent  | ISO8802.5 4ever |



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 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 target to the kernel Makefile which would call
src/sys/modules/Makefile and allow users who would perhaps never venture
into src/sys except when heading straight for src/sys/i386/conf to
easily update their modules.  It makes little sense to have modules
under src/sys and in the src-sys collection if the only time they are
routinely rebuilt is through a complete make world.  Isn't the idea of
having a seperate Makefile for src/sys so that *all* kernel level code
can be recompiled and/or updated without the user having to possess all
of src or knowledge of the world process?  I know I'm not the first
person to raise the issue, but I don't think I should be the last
either.  I think it's a sound architectual decision and 100% inline with
FreeBSD's commitment to accomodate users of all skill levels.
 
Brandon D. Valentine
-- 
[EMAIL PROTECTED] Illegitimi non carborundum.



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 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, 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 Linux SMP.  This is a tremendous opportunity for FreeBSD
to take market share.  People are seeing the virtues of free, open
source operating systems in the server farm and providing top notch SMP
support in FreeBSD will help to see that we make further inroads that
the Linux guys do.  If the BSDi code assists us in improving SMP
performance and if the corporate backing helps our PR image, then we
could be in for a fun ride.  This is the time to start thinking in terms
of "What can we do better?" or we're going to lose the battle.  Sure,
those changes could go into 5.x and be released when RELENG_5 is
branched a year from now.  But in this business, a year is 6 months too
late.  Think about that before you object to what appear to be vast
improvements in the performance of the RELENG_4 branch while it is just
getting off the ground.

Brandon D. Valentine
-- 
[EMAIL PROTECTED] Illegitimi non carborundum.



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 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 modules.  A quick grep -l spl * | wc

Given that this is a change in the splxxx() implementation, it breaks
zero modules.

splxxx() was changed from an inline function to an ordinary function
when SMP development started, to give the same ABI for the SMP case as
for the non-SMP case.  This gives the same ABI for different SMP
implementations as a side effect.

I've thought of bringing back some of the spl inlines.  The module ABI
problem can be handled in the same way as in machine/atomic.h -- use
ordinary functions for modules.

Bruce



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 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 from an inline function to an ordinary function
 when SMP development started, to give the same ABI for the SMP case as
 for the non-SMP case.  This gives the same ABI for different SMP
 implementations as a side effect.

simple_lock* functions has breakage too. They defined as macros
for non-SMP case and as functions for SMP.

--
Boris Popov



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 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" directory somewhere.


=
| Kenneth Culver  | FreeBSD: The best OS around.|
| Unix Systems Administrator  | ICQ #: 24767726 |
| and student at The  | AIM: muythaibxr |
| The University of Maryland, | Website: (Under Construction)   |
| College Park.   | http://www.wam.umd.edu/~culverk/|
=

On Mon, 24 Apr 2000, Brandon D. Valentine wrote:

 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 target to the kernel Makefile which would call
 src/sys/modules/Makefile and allow users who would perhaps never venture
 into src/sys except when heading straight for src/sys/i386/conf to
 easily update their modules.  It makes little sense to have modules
 under src/sys and in the src-sys collection if the only time they are
 routinely rebuilt is through a complete make world.  Isn't the idea of
 having a seperate Makefile for src/sys so that *all* kernel level code
 can be recompiled and/or updated without the user having to possess all
 of src or knowledge of the world process?  I know I'm not the first
 person to raise the issue, but I don't think I should be the last
 either.  I think it's a sound architectual decision and 100% inline with
 FreeBSD's commitment to accomodate users of all skill levels.
  
 Brandon D. Valentine
 -- 
 [EMAIL PROTECTED] Illegitimi non carborundum.
 
 



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-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 PROTECTED]

 This is a legitimate topic for discussion.

 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.
 We should be allowed to break kernel module loader compatibility
 in between a .0 and a .1 release if it is deemed necessary, but that
 it should be avoided (as much as possible) after the .1 release.

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.


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-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)  
: : [EMAIL PROTECTED]
:
: This is a legitimate topic for discussion.
:
: 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.
: We should be allowed to break kernel module loader compatibility
: in between a .0 and a .1 release if it is deemed necessary, but that
: it should be avoided (as much as possible) after the .1 release.
:
: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 we've
ever had, and I am confident that the 4.x series of releases will be
the best in FreeBSD's history probably until 5.1 or 5.2.

5.x is going to be seriously torn up.  Maybe not as bad as people thought,
but still seriously torn up.  It's already being torn up.  I don't think
there is any chance of making 4.x a short-lived branch nor do I think
we want to.  We should bask in the light of finallly having a good stable,
high performance set of 4.x releases.

What we have is a war between the customer's need for stability,
other customer's need for speed, and the realities that developers 
face in not wanting to have to rewrite patches in order to MFC them,
and wanting to have the opportunity to MFC improvements and bug fixes
in the first place.  The SMP patch falls somewhere in the middle, and 
I am aiming it towards the MFC side to make #3 easier.

-Matt
Matthew Dillon 
[EMAIL PROTECTED]


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-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 we've
 ever had, and I am confident that the 4.x series of releases will be
 the best in FreeBSD's history probably until 5.1 or 5.2.

It's all in the name. I don't disagree with your assesment of the code bases.
However, I consider your SMP changes VERY destablizing; they BREAK
lots of modules :-(
I'm sure that we will get over it and have something that settles into a 
quite solid product.

However, we COULD branch FreeBSD5 off of the FreeBSD4 branch rather than
the head and call the head branch something else which would get released as 
FreeBSD6 or FreeBSD 2000 or ...


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-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. 
: 
: The SMP patchset, in fact, requires that all kernel modules be 
: recompiled due to the locks that were removed from the spl*() macros.

   I wonder if they really must be recompiled. It sounds like that would
improve performance, but is seems like gratuitous locking in this area
wouldn't necessarily cause things to break.

-DG

David Greenman
Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org
Creator of high-performance Internet servers - http://www.terasolutions.com
Pave the road of life with opportunities.


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

I want it treated as a full -stable branch, not some weaker derivative,
and I don't think we'll win [m]any friends in the new-4.0 convert camp
if we try to shake things up there, even with it in .0 status and the
BSDi situation.

The reasoning is quite simple:  4.0 turned out to have, in certain production
environments, far less stability problems than 3.4 and that is partially
Matt's fault for fixing things like NFS. :-)

That in turn led to a lot more early-adoption of 4.0 than expected,
and now 4.0 is being treated (and is behaving) like a full-blown
-stable release with lots of good reasons to switch to it.  The whole
dot-zero conservativeness thing was our traditional attempt to put a
happy face on situations that sucked (a .0 release being frail and
buggy) rather than having that be an actual goal.  Now that we've
finally managed to shake off the .0 curse in many respects, I'm firmly
behind the concept of treating it like any other release.

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


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-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. 
:: 
:: The SMP patchset, in fact, requires that all kernel modules be 
:: recompiled due to the locks that were removed from the spl*() macros.
:
:   I wonder if they really must be recompiled. It sounds like that would
:improve performance, but is seems like gratuitous locking in this area
:wouldn't necessarily cause things to break.
:
:-DG
:
:David Greenman
:Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org

The cpl, cml, and interrupt lock variables and initialization of such
is gone, Kapoof.  And the semantics have changed for a few things as well.

I haven't actually tested it to see if old modules still load and
operate properly because doing the testing properly would take more time
then I have to spend.  If a KLD doesn't use spl*() calls at all it may
be ok.  I think we should resign ourselves to recompiling the KLD's,
though.

-Matt
Matthew Dillon 
[EMAIL PROTECTED]


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


Totally off topic question that I've wondered for some time now - what
does MFC stand for?

Thanks for humoring my ignorance, and thanks for all your hard work on
FreeBSD...

:)

On Sun, 23 Apr 2000, Matthew Dillon wrote:

 Date: Sun, 23 Apr 2000 13:31:34 -0700 (PDT)
 From: Matthew Dillon [EMAIL 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 kernel modules in object format only that
 : :are working now, which this would break :-(.
 : :
 : :Rod Grimes - KD7CAX @ CN85sl - (RWG25)  
 : : [EMAIL PROTECTED]
 :
 : This is a legitimate topic for discussion.
 :
 : 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.
 : We should be allowed to break kernel module loader compatibility
 : in between a .0 and a .1 release if it is deemed necessary, but that
 : it should be avoided (as much as possible) after the .1 release.
 :
 :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 we've
 ever had, and I am confident that the 4.x series of releases will be
 the best in FreeBSD's history probably until 5.1 or 5.2.
 
 5.x is going to be seriously torn up.  Maybe not as bad as people thought,
 but still seriously torn up.  It's already being torn up.  I don't think
 there is any chance of making 4.x a short-lived branch nor do I think
 we want to.  We should bask in the light of finallly having a good stable,
 high performance set of 4.x releases.
 
 What we have is a war between the customer's need for stability,
 other customer's need for speed, and the realities that developers 
 face in not wanting to have to rewrite patches in order to MFC them,
 and wanting to have the opportunity to MFC improvements and bug fixes
 in the first place.  The SMP patch falls somewhere in the middle, and 
 I am aiming it towards the MFC side to make #3 easier.
 
   -Matt
   Matthew Dillon 
   [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 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+ PE++ Y+ PGP t++ 5 X++ R+ tv+ b++ DI+++ D+ 
G+ e- h! r--+++ y?


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-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 -CURRENT.' It's used in the CVS
logs to denote when a change was migrated from the CURRENT to the STABLE
branches. 

A quick search for MFC right from the freebsd.org main page would have
returned this information.

Brandon D. Valentine
-- 
[EMAIL PROTECTED] Illegitimi non carborundum.



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