Re: To MFC or not to MFC, that is the question.
: :Really, then you have a short memory. Why don't we ask Jordan for a :clarification. : :How about if you let me review the patches in question and I'll render :a decision. : :If you, Matt, could put the SMP and linux stuff into -current first :and then give me a day or so to check it out, I'll submit my own :opinion on whether or not this is "immediate MFC" material. The linux patch is the only patch under discussion here in regards to the simultanious commit/MFC issue. The SMP work was committed to current almost a month ago so MFC'ing it now is not really an issue. (besides, if you remember our conversation back then both of us actually did all of our testing of the SMP patch under 4.x rather then 5.x). The linux scripting patch is available, as I already posted, at: http://www.backplane.com/FreeBSD4/ While it has not been committed to -current or -stable yet, it has been up for review for a while (3 weeks) and I have tested extensively while installing oracle and java under linux emulation. And it only effects linux emulation so it isn't as though MFC'ing it will suddenly break FreeBSD even under the worst possible assumptions. As DG said, the linux scripting patch is simply not this big a deal... I don't know what Poul is barking at. -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
: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: csh/nls problem causing make release failure
On Sun, Apr 23, 2000 at 11:20:46PM -0400, John W. DeBoskey wrote: As Poul-Henning has pointed out, make release is broken... No, he pointed to different problem, 'make distribute' Could the appropriate folks please take a look at this? I'll be more than happy to test any patchs. Try now, I just commit what is supposed to fix. -- Andrey A. Chernov [EMAIL PROTECTED] http://nagual.pp.ru/~ache/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
asm_pci.h,v Holy cow!
My cvsup appeared to be frozen, so I stopped it and looked.. src/sys/dev/isp/asm_pci.c,v is 13MB long! it was just taking a long time.. this seems a little excessive. anyone got any ideas. (13MB on a 40Kbit link is a long time) to make matters worse cvsup appears to be redownloading some very large percentage of this file whenerver there is a change to it. -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000 --- X_.---._/ presently in: Perth v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Linux emulation scripting fix to be committed to 5.x and 4.xwednesday
Hi Matt, I really like to see your fix committed to STABLE. It fixes also the bad designed Staroffice 5.2 installation for some part (/usr/sbin/test). Thank you for your work ! Martin Martin Blapp, [EMAIL PROTECTED] Improware AG, UNIX solution and service provider Zurlindenstrasse 29, 4133 Pratteln, Switzerland Phone: +41 79 370 26 05, Fax: +41 61 826 93 01 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
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: __func__ not declared for kernel build (5.0-CURRENT)
but, in all this, the bottom line is that compilers, until recently, barfed on __func__. to compile the kernel, I substituted the function name in the printf statement... no big deal, but not what was intended, which I presume was to guarantee the correct function name, even if the function name was changed or the code lifted and reused in another function. after a few words in the programmers' universal language and a quick RTFS exercise, the hack was in... on with the show and the new kernel ran just fine and buildworld has done its thing. attila out... -- No, I don't suffer from insanity - I enjoy every minute of it. On Sun, 23 Apr 2000, Matthew Dillon wrote: :Matthew Dillon [EMAIL PROTECTED] writes: : obviously missing __FUNCTION__ was added by GCC many years ago, but it was : a while before it's use in defines in header (.h) files was dealt with : properly. : :You mean outside a function? What's the proper way of dealing with that? : : I wish these stupid standards committees would just choose : something that people are already using rather then make up new names! : :The problem is that __func__ and __FUNCTION__ are not the same thing. :And thus it makes sense for them not the use same name. : :/assar __FUNCTION__ represents the name of the C procedure you are currently in, same as __func__ as far as I can tell. You can define macros that use __FUNCTION__ in header files and then use them in the C code. This works just fine, as of around 6 years ago (before then __FUNCTION__ in gnu C did not properly resolve when used in a macro in a header file). I use __FUNCTION__ all the time to implement ASSERT() macros. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Linux emulation scripting fix to be committed to 5.x and 4.xwednesday
On Sun, 23 Apr 2000, Matthew Dillon wrote: 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. This is something I would contemplate doing for 4.0-4.1, but not something I would consider for 4.1 onward. Even though 4.0 is the most stable .0 release we've ever had, it's still a .0. I wonder if it makes sense to add a release id to the module header and have the module loader refuse (unless forced) to load modules that are out-of-date with the kernel? This sounds quite reasonable. Perhaps you should commit the linux patch to -current right now and then merge it on Wednesday. That would give plenty of time for any teething problems to show up. -- 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
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: asm_pci.h,v Holy cow!
On Mon, 24 Apr 2000, Julian Elischer wrote: My cvsup appeared to be frozen, so I stopped it and looked.. src/sys/dev/isp/asm_pci.c,v is 13MB long! it was just taking a long time.. this seems a little excessive. I was annoyed by this a few months ago when the file was only 10MB. anyone got any ideas. (13MB on a 40Kbit link is a long time) Use CTM on slow links :-). to make matters worse cvsup appears to be redownloading some very large percentage of this file whenerver there is a change to it. This seems to be inherent in the file format. Binary data is expanded by a factor of 4 due to encoding it as a C array. Even tiny changes in the data ripple through the array and give huge diffs. Uuencoding the data would only expand it by a factor of 1.4 although it would have the same problem with the diffs. 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
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
Buildworld not working
I've been trying to do a buildworld since Friday, after doing a cvsup, and no matter how many times I try, I keep getting: === librsausa cp /usr/src/secure/lib/librsausa/../libcrypto/opensslconf-i386.h openssl/opensslconf.h mkdir: openssl: File exists *** Error code 1 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error Any ideas? Thanks Robert Small winmail.dat
Re: SMP changes and breaking kld object module compatibility
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
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: Buildworld not working
Robert: as root: # rm -rf /usr/include/openssl /usr/obj * Robert Small ([EMAIL PROTECTED]) [000424 10:08]: I've been trying to do a buildworld since Friday, after doing a cvsup, and no matter how many times I try, I keep getting: === librsausa cp /usr/src/secure/lib/librsausa/../libcrypto/opensslconf-i386.h openssl/opensslconf.h mkdir: openssl: File exists Any ideas? -- Hasan Diwan [[EMAIL PROTECTED]] :) Rensselaer Polytechnic Institute Computer Science Department http://hdwork.dhs.org/~hdiwan PGP signature
Re: SMP changes and breaking kld object module compatibility
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: Joystick has stopped working
On Mon, Apr 24, 2000 at 02:56:33PM +0800, Stephen Hocking scribbled:
# For sometime now, the analogue joy stick driver hasn't been working - it seems
# to persistently return totally wild deviations when being read. Also, trying
# to use it as a kld doersn't seem to work. Has anyone else had similar probs?
I have the exact same problem..both under 5.0-CURRENT and 3.3-RELEASE.. but
I've only got access to the -CURRENT machine now. An example of those evil
values that it returns can be had via the perl one-liner in the joy(4)
manpage..
www% perl -e 'open(JOY,"/dev/joy0")||die;while(1){sysread(JOY,$x,16);
@j=unpack("",$x);print "@j\n";sleep(1);}'
-2147483648 -2147483648 0 0
-2147483648 -2147483648 0 0
-2147483648 -2147483648 0 0
-2147483648 -2147483648 0 0
...
etc etc
The module even fails to load here, so I can't try that, and this happens
with and without a joystick attached.. if you get a solution to this problem,
please clue me in on it :)
- Jonathan Towne
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
"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
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
apsfilter doesn't work anymore under current for remote print jobs
Somehting must have changed with permissions in the last weeks. The owner of a print sessions control file are different when printing over network compared to a local print job. The lineprinter input filter doesn't have permissions to grep through the control file during runtime. Precise problem descr in the PR I submitted last recently. Sorry, didn't get a number back ... -- Andreas Klemm http://people.FreeBSD.ORG/~andreas http://www.freebsd.org/~fsmp/SMP/SMP.html powered by Symmetric MultiProcessor FreeBSD New APSFILTER 533 and songs from our band - http://people.freebsd.org/~andreas To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesdayy
Martin Blapp wrote: I really like to see your fix committed to STABLE. It fixes also the bad designed Staroffice 5.2 installation for some part (/usr/sbin/test). ...as well as the WordPerfect 2000 for Linux installation. Basically, it sounds like it makes Linux emulation really complete. Although I do agree that there should be a knob to turn this thing on and/or off. -- 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
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: asm_pci.h,v Holy cow!
Yes, this needs to be fixed. I have an open bug about this with respect to making the f/w a loadable module as well. I'll probably split it into several pieces so that each f/w update is smaller. I could probably make it binary and compress is (each f/w module is an array of 16 bit shorts), but that has it's onw problems. You should note, btw, that my link isn't all *that* faster than yours (I have 144Kbit DSL). Sorry about the large enchilada. On Mon, 24 Apr 2000, Julian Elischer wrote: My cvsup appeared to be frozen, so I stopped it and looked.. src/sys/dev/isp/asm_pci.c,v is 13MB long! it was just taking a long time.. this seems a little excessive. anyone got any ideas. (13MB on a 40Kbit link is a long time) to make matters worse cvsup appears to be redownloading some very large percentage of this file whenerver there is a change to it. -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000 --- X_.---._/ presently in: Perth v 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: asm_pci.h,v Holy cow!
Garrett Wollman wrote: On Mon, 24 Apr 2000 21:30:01 +1000 (EST), Bruce Evans [EMAIL PROTECTED] said: This seems to be inherent in the file format. Binary data is expanded by a factor of 4 due to encoding it as a C array. Even tiny changes in the data ripple through the array and give huge diffs. Uuencoding the data would only expand it by a factor of 1.4 although it would have the same problem with the diffs. I've been thinking about this recently myself. We want to maintain the ability to examine historical versions of the code, but actual diffs from one version to another are, in this context, meaningless. I'd like to suggest a new hierarchy /usr/firmware, which sits along-side /usr/src and /usr/ports in our distribution mechanism, but which does not use RCS files to store version information. Rather, the version information is encoded in the pathname, and files are stored and transferred as binary objects. It might look something like this: /usr/firmware/ gronk/ (this is the gronk driver) 3.57.OA.bin (where 3.57.OA is vendor's version) plugh/ 42.69/ model1.bin model2.bin model3.bin -GAWollman This seems well thought out and I certainly agree that we don't need DIFFs of firmware. I wonder if we can somehow "cheat time" and get that 13MB file out of the source tree and retro-actively tag the new scheme so that we don't have to carry it around forever :-) -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000 --- X_.---._/ presently in: Perth v 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
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
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
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
: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
: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
: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
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
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
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: Buildworld not working
On Mon, Apr 24, 2000 at 08:40:52AM -0500, Robert Small wrote: I've been trying to do a buildworld since Friday, after doing a cvsup, and no matter how many times I try, I keep getting: Please try: cd /usr/src make cleandir make cleandir and try again. Let me know the outcome -- good or bad. *If* the outcome is "good". Please do a second ``make buildworld'' w/o doing anything else. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: asm_pci.h,v Holy cow!
On Mon, 24 Apr 2000, Julian Elischer wrote: This seems well thought out and I certainly agree that we don't need DIFFs of firmware. I wonder if we can somehow "cheat time" and get that 13MB file out of the source tree and retro-actively tag the new scheme so that we don't have to carry it around forever :-) It looks like a port, Smells like a port, and tastes like a port. It must be a . merlot ? Seriously, perhaps we should consider putting optional pieces of the kernel (eventually much of it, I hope) into a ports style structure. This structure can already take care of most of the problems like this one because it has multiple mechanisms whereas the source tree has only one. 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
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: make buildworld failed...
On Sat, Apr 22, 2000 at 01:05:24AM +0400, Sergey Osokin wrote: Hello! After CVSup i tryed to rebuild my 5.0... Are you using "-j" with your makes? Please try: cd /usr/src make cleandir make cleandir and try again. Let me know the outcome -- good or bad. *If* the outcome is "good". Please do a second ``make buildworld'' w/o doing anything else. -- -- David([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
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: OpenSSL asm optimizations
On Fri, Apr 21, 2000 at 07:28:28PM -0700, Kris Kennaway wrote: patch to sys.mk which defined MACHINE_CPU ?= i386). Set MACHINE_CPU to "i586" or "i686" (both are actually identical at present) and rebuild. Please also support "k5" and "k6". -- -- David([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
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: asm_pci.h,v Holy cow!
On Mon, Apr 24, 2000 at 01:43:44PM -0500, Richard Wackerbarth wrote: On Mon, 24 Apr 2000, Julian Elischer wrote: This seems well thought out and I certainly agree that we don't need DIFFs of firmware. I wonder if we can somehow "cheat time" and get that 13MB file out of the source tree and retro-actively tag the new scheme so that we don't have to carry it around forever :-) It looks like a port, Smells like a port, and tastes like a port. It must be a . merlot ? Seriously, perhaps we should consider putting optional pieces of the kernel Firmware for a SCSI adapter is not optional. At least not on some of the Alpha machines that download out-of-date firmware from their SRMs so depend on the driver to load them with something up-to-date. -- 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: OpenSSL asm optimizations
On Mon, 24 Apr 2000, David O'Brien wrote: On Fri, Apr 21, 2000 at 07:28:28PM -0700, Kris Kennaway wrote: patch to sys.mk which defined MACHINE_CPU ?= i386). Set MACHINE_CPU to "i586" or "i686" (both are actually identical at present) and rebuild. Please also support "k5" and "k6". Actually it raises the question I was going to frame of how to specify the set of CPU revisions which are compatible. For example, k5 and k6 want i586 optimizations as a fallback (if no k5/6 native optimizations available), k6 wants k5, i586 wants i486 etc. The easiest way I can think of is to specify MACHINE_CPU as a list: e.g. for a k6 it might be "k6 k5 i586 i486 i386" specifying that any of those optimizations should be used. It would be best to make it an ordered list, i.e. in order of preference, but I'll have to think about the implementation implications. Kris In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe [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
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
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: asm_pci.h,v Holy cow!
On Mon, 24 Apr 2000, you wrote: Seriously, perhaps we should consider putting optional pieces of the kernel Firmware for a SCSI adapter is not optional. At least not on some of the Alpha machines that download out-of-date firmware from their SRMs so depend on the driver to load them with something up-to-date. Sure it is. I certainly have a fine system without any SCSI adapter. The whole move toward loadable modules is to make the kernel into a "cafeteria" rather than a "blue plate". That firmware is a required part of a particular driver is not in dispute. 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
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
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: asm_pci.h,v Holy cow!
On Mon, Apr 24, 2000 at 02:07:22PM -0500, Richard Wackerbarth wrote: On Mon, 24 Apr 2000, you wrote: Seriously, perhaps we should consider putting optional pieces of the kernel Firmware for a SCSI adapter is not optional. At least not on some of the Alpha machines that download out-of-date firmware from their SRMs so depend on the driver to load them with something up-to-date. Sure it is. I certainly have a fine system without any SCSI adapter. The whole move toward loadable modules is to make the kernel into a "cafeteria" rather than a "blue plate". That firmware is a required part of a particular driver is not in dispute. People were writing "port", not "module". For the isp firmware it is in some cases a mandatory part, in some cases a optional part of the driver. Matt can tell you more ;-) -- 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
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
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
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
rndcontrol with 16 interrupts
Are there any plans to allow rndcontrol to accept greater than 16 interrupts on SMP machines ? On my ASUS XG-DLS board, all the interesting interrupts that I want to use to stir the entropy pool are greater than 16. Examination of sys/i386/i386/mem.c on RELENG_3, RELENG_4 and HEAD all have this comment and code snippet: /* * XXX the data is 16-bit due to a historical botch, so we use * magic 16's instead of ICU_LEN and can't support 24 interrupts * under SMP. */ intr = *(int16_t *)data; if (cmd != MEM_RETURNIRQ (intr 0 || intr = 16)) return (EINVAL); I don't exactly understand what ICU_LEN refers to or if there are technical reasons that we can't support 24 interrupts, but the present situation leaves me with a powerful machine that can't take advantage of /dev/random at all (the pool has so little to feed off of that reads of even small amounts of data block). Can anyone shed some light ? TIA. -- j. James FitzGibbon [EMAIL PROTECTED] Targetnet.com Inc. Voice/Fax +1 416 306-0466/0452 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: asm_pci.h,v Holy cow!
Matt can tell you more ;-) People don't really want to know more. They just don't want what I provide support for to impact them. I'll bet if I sum up all the other kernel mathoms like netgraph, and so on, that *I* never use, it'd be less than this f/w...:-) But this isn't the point. The point is to cause less cvsup turbulence for all and sundry. I think I can do enough of this by just splitting the file apart to keep everyone happy. Or happy enough. -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
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
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
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
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
{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
tcsh bug
Not to create another argument but tcsh does not appear to be csh :-( With -current as of the weekend. I now have tcsh as the root shell. I noticed something "strange", my history only displays the time, for example dual# history 1 13:42 2 13:42 3 13:42 4 13:42 5 13:42 6 13:43 7 13:43 8 13:43 9 13:43 10 13:43 11 15:35 12 15:35 13 15:36 14 15:37 15 15:37 16 15:39 17 15:39 18 15:39 ... etc ... However, history does work with ! for example on the same machine right after the above history command: dual# !ech echo $SHELL /bin/csh dual# After I did a "make world" I also did a "make distribution" in /usr/src/etc to make sure I had default files. Here is the results of env: dual# env DISPLAY=770z.whistle.com:0.0 PRINTER=lp TERM=xterm PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin:/root/bin MAIL=/var/mail/root BLOCKSIZE=K FTP_PASSIVE_MODE=YES SHELL=/bin/csh HOME=/root LOGNAME=root USER=root HOSTTYPE=FreeBSD VENDOR=intel OSTYPE=FreeBSD MACHTYPE=i386 SHLVL=1 PWD=/root GROUP=wheel HOST=dual REMOTEHOST=192.168.1.30 EDITOR=vi PAGER=more dual# Here is the results from set: dual# set _ env addsuffix argv() cwd /root dirstack/root echo_style bsd edit filec gid 0 group wheel history 100 home/root loginsh mail/var/mail/root owd path(/sbin /bin /usr/sbin /usr/bin /usr/games /usr/local/sbin /usr/local/bin /usr/X11R6/bin /root/bin) prompt dual# prompt2 %R? prompt3 CORRECT%R (y|n|e|a)? shell /bin/csh shlvl 1 status 0 tcsh6.09.01 termxterm tty ttyp0 uid 0 userroot version tcsh 6.09.01 (Astron) 2000-01-14 (i386-intel-FreeBSD) options 8b,nls,dl,al,sm,rh,color dual# This is from the root login. Please help ... I have trouble remembering what I type and the way I use history is to cut'n'paste via X. It's works and I don't have to remember various things that change when I'm forced to change shell so please no philosophy lessons. Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
current status of pcm ??
Hi all, I've been unable to get audio (mp3 cdplay) to work on my desktop with a SBLive card or on my laptop (TP 600E). I would *really* like to have IPSec and a working audio cd player on my laptop. I this supposed to work, or am I swimming upstream. Thanks all. Kent To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Archive pruning
I want to bring up a suggestion. I just want a little bit of argument on it ... and if you're violently opposed, just say so, that's fine. I want to suggest that, once a year, we go thru the cvs archive, and prune away all history more than 3 (or maybe 2, maybe 4) years old. This could be done without too much pain, I think, in a script. The purpose is to put some kind of cap on growth of the FreeBSD source archive. While folks do sometimes go hunting for hugely old materials in the tree, I normally couldn't care less (when browsing) about history that old. Do we really need 5 year old history? Chuck Robey| Interests include C Java programming, FreeBSD, [EMAIL PROTECTED] | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMP changes and breaking kld object module compatibility
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: tcsh bug
On Mon, Apr 24, 2000 at 04:04:00PM -0700, Doug Ambrisko wrote: With -current as of the weekend. I now have tcsh as the root shell. I noticed something "strange", my history only displays the time, for example Known problem. Will be fixed in a few days. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Archive pruning
On Mon, 24 Apr 2000, Chuck Robey wrote: I want to bring up a suggestion. I just want a little bit of argument on it ... and if you're violently opposed, just say so, that's fine. I want to suggest that, once a year, we go thru the cvs archive, and prune away all history more than 3 (or maybe 2, maybe 4) years old. This could be done without too much pain, I think, in a script. The purpose is to put some kind of cap on growth of the FreeBSD source archive. While folks do sometimes go hunting for hugely old materials in the tree, I normally couldn't care less (when browsing) about history that old. Do we really need 5 year old history? Yes, to avoid Santayana's curse. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Archive pruning
On Mon, Apr 24, 2000 at 08:15:45PM -0400, Chuck Robey wrote: I want to bring up a suggestion. I just want a little bit of argument on it ... and if you're violently opposed, just say so, that's fine. I'm "violently opposed". :-) While folks do sometimes go hunting for hugely old materials in the tree, I've often traced files back to the begining of FreeBSD time (and then continued in the CSRG SCCS tree). I've done this numerious times, especially the contributed sources like GCC and GNU grep. Do we really need 5 year old history? Yes. -- -- David([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
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: Archive pruning
Chuck Robey wrote: I want to bring up a suggestion. I just want a little bit of argument on it ... and if you're violently opposed, just say so, that's fine. Okay: "so." :-) Do we really need 5 year old history? Well, unfortunately (and I speak from painful experience), yes. You never know what history is going to be needed to understand _this_ particular change introduced in _this_ six-year-old revision in code that hasn't been touched since, and that either needs to be changed to fit a new way of doing things or that has a bug in a path that has apparently never been taken, ever before. Hell, some of _my_ code (in my current project) is six years old, and I have only a dim memory of having written it, much less why I wrote it that way in the first place. (Somewhere floating around at a certain university is code I wrote long ago that would be approaching drinking age were it a human being. _It_ probably needs history, too, and doesn't have it. Fortunately, that's Not My Problem. :-) The more history, unfortunately for the disk space needs of all of us keeping copies of the repository, the better. -- 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: Archive pruning
On Mon, 24 Apr 2000, David O'Brien wrote: On Mon, Apr 24, 2000 at 08:15:45PM -0400, Chuck Robey wrote: I want to bring up a suggestion. I just want a little bit of argument on it ... and if you're violently opposed, just say so, that's fine. I'm "violently opposed". :-) While folks do sometimes go hunting for hugely old materials in the tree, I've often traced files back to the begining of FreeBSD time (and then continued in the CSRG SCCS tree). I've done this numerious times, especially the contributed sources like GCC and GNU grep. Do we really need 5 year old history? Yes. OK. Thanks, I wanted some opinions, and I guess I have enough to satisfy me. Chuck Robey| Interests include C Java programming, FreeBSD, [EMAIL PROTECTED] | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Archive pruning
* Chuck Robey [EMAIL PROTECTED] [000424 19:15] wrote: I want to bring up a suggestion. I just want a little bit of argument on it ... and if you're violently opposed, just say so, that's fine. I want to suggest that, once a year, we go thru the cvs archive, and prune away all history more than 3 (or maybe 2, maybe 4) years old. This could be done without too much pain, I think, in a script. The purpose is to put some kind of cap on growth of the FreeBSD source archive. While folks do sometimes go hunting for hugely old materials in the tree, I normally couldn't care less (when browsing) about history that old. Do we really need 5 year old history? Yes. However, I would really like to see a pruned REPO available that carried perhaps the last 3 years of history, perhaps one running off the freebsd cluster. If it became popular enough several of the cvsup mirrors could adopt it. -- -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: tcsh bug
David O'Brien writes: | On Mon, Apr 24, 2000 at 04:04:00PM -0700, Doug Ambrisko wrote: | With -current as of the weekend. I now have tcsh as the root shell. | I noticed something "strange", my history only displays the time, for example | | Known problem. Will be fixed in a few days. Thanks, let me know when it should be okay. Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: current status of pcm ??
On Mon, 24 Apr 2000, Kent Hauser wrote: Hi all, I've been unable to get audio (mp3 cdplay) to work on my desktop with a SBLive card or on my laptop (TP 600E). I would *really* like to have IPSec and a working audio cd player on my laptop. I this supposed to work, or am I swimming upstream. Thanks all. Kent Search the mailing list archives for "emu10k1" and you'll find a HOWTO for using the (experimental) emu10k1 drivers, which provide support for the SBLive card and others, with 4.0. Kelly -- Kelly Yancey - [EMAIL PROTECTED] - Belmont, CA System Administrator, eGroups.com http://www.egroups.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSDhttp://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Archive pruning
On Mon, 24 Apr 2000, Chuck Robey wrote: I want to bring up a suggestion. I just want a little bit of argument on it ... and if you're violently opposed, just say so, that's fine. I want to suggest that, once a year, we go thru the cvs archive, and prune away all history more than 3 (or maybe 2, maybe 4) years old. This could be done without too much pain, I think, in a script. The purpose is to put some kind of cap on growth of the FreeBSD source archive. While folks do sometimes go hunting for hugely old materials in the tree, I normally couldn't care less (when browsing) about history that old. Do we really need 5 year old history? a) yes, we need the history. b) do we need it "online everywhere"? I think the answer is "no". However the sandbox engineers think differently. c) I've brought this up more than once. Do "they" care? ??? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Archive pruning
On Mon, 24 Apr 2000, you wrote: On Mon, Apr 24, 2000 at 08:15:45PM -0400, Chuck Robey wrote: I want to bring up a suggestion. I just want a little bit of argument on it ... and if you're violently opposed, just say so, that's fine. I'm "violently opposed". :-) While folks do sometimes go hunting for hugely old materials in the tree, I've often traced files back to the begining of FreeBSD time (and then continued in the CSRG SCCS tree). I've done this numerious times, especially the contributed sources like GCC and GNU grep. Do we really need 5 year old history? Yes. I don't disagree that we need to maintain the history. I do, however, question the policy that REQUIRES EVERYONE to maintain that much history. The CPU's use L1, L2, MM, HD cache hierarchies. The public libraries have a few months issues of a periodical in each branch library. They also have years of them in the main archives. FreeBSD developers know a better way to manage information??? :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Archive pruning
On Mon, 24 Apr 2000 22:06:42 -0400 (EDT), Chuck Robey [EMAIL PROTECTED] said: OK. Thanks, I wanted some opinions, and I guess I have enough to satisfy me. I'd like to add that it can be particularly important when legal questions arise. Should some submarine patent cover parts of FreeBSD's practice, it will turn out to be extremely important to be able to document (through the revision history) precisely when the technique under question appeared. Similarly, when Berkeley was defending the USL suit, they needed to make use of the revision history to document their reimplementation process. -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: Archive pruning
On Mon, 24 Apr 2000, Chuck Robey wrote: Do we really need 5 year old history? Yes. -- | 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
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: Archive pruning
On Mon, Apr 24, 2000 at 08:59:46PM -0500, Richard Wackerbarth wrote: Do we really need 5 year old history? a) yes, we need the history. b) do we need it "online everywhere"? I think the answer is "no". However the sandbox engineers think differently. c) I've brought this up more than once. Do "they" care? Normally "we" stop caring when we see your name in the From: header. -- 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: Archive pruning
On Mon, 24 Apr 2000, you wrote: I'd like to add that it can be particularly important when legal questions arise. You confuse the argument for SOME complete repositories with the necessity that ALL (or at each most) repositories be so extensive. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Archive pruning
I want to bring up a suggestion. I just want a little bit of argument on it ... and if you're violently opposed, just say so, that's fine. I want to suggest that, once a year, we go thru the cvs archive, and prune away all history more than 3 (or maybe 2, maybe 4) years old. I'm violently opposed to removing it completely. The only thing I wouldn't be violently opposed to would be removing 'Attic' files (truly unused file), and having them stored away somewhere in the tree for archival purposes. As far as removing old revisions from files, I'm even more violently opposed to this. This could be done without too much pain, I think, in a script. The purpose is to put some kind of cap on growth of the FreeBSD source archive. While folks do sometimes go hunting for hugely old materials in the tree, I normally couldn't care less (when browsing) about history that old. I quite often browse the source code in the tree, in particular I look through the network code at how it's been modified over the years. Also, I often-times go through the history. Do we really need 5 year old history? Need? As far as needs go, we don't need anything but the most recent versions. This is how Linux was developed for years, and it's a nightmare. The revisions take up very little space, and anyone capable and willing to look through the history shouldn't mind having to see the history of the file. Heck, that's one of the big upsides to using source-code control. Nate 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
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: Archive pruning
Do we really need 5 year old history? That really depends on your point of view. "Those who cannot remember the past are condemned to repeat it" -- Santayana "The only thing we learn from history is that we learn nothing from history." -- Hegel I am with Hegel in the very long term but what is the rush about pruning? Set a cron job to ask this in the year 2037! In the short term it is valuable to trace back the genesis of various features/bugs. With cvs annotate you can even find out who put in a feature or bug and bug that person about it (as I was just this past week about something I had written over four years back). The networking code is so convoluted that having all the history (which we don't) can be very valuable in unravelling all the development strands. -- bakul PS: Of course, having a complete history is not the same as reading and remembering it all but at least you have a chance What is missing is a tool that to easily browse through old revisions (tkdiff is nice but not enough). If such a tool were available there would be many source code historians! PPS: We should have a complete history *somewhere*. You are of course free to extend cvsup to prune so that *you* don't have to keep it all. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Archive pruning
On Mon, 24 Apr 2000, Bakul Shah wrote: Do we really need 5 year old history? That really depends on your point of view. "Those who cannot remember the past are condemned to repeat it" -- Santayana "The only thing we learn from history is that we learn nothing from history." -- Hegel I am with Hegel in the very long term but what is the rush about pruning? Set a cron job to ask this in the year 2037! In the short term it is valuable to trace back the genesis of various features/bugs. With cvs annotate you can even find out who put in a feature or bug and bug that person about it (as I was just this past week about something I had written over four years back). The networking code is so convoluted that having all the history (which we don't) can be very valuable in unravelling all the development strands. Well, I wasn't talking about a harsh pruning, but I haven't seen much support for the idea, so maybe it better drop. The idea came when I was making room for vmware ... boy, I wish that the new generation of 18G Ultra160 disks would come out already ... the only reasonably priced one is the Seagate, but it could be aptly nicknamed the "data furnace" from just how hot it runs. I need more disk! Chuck Robey| Interests include C Java programming, FreeBSD, [EMAIL PROTECTED] | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Archive pruning
On Mon, 24 Apr 2000 22:09:14 -0500, Richard Wackerbarth [EMAIL PROTECTED] said: You confuse the argument for SOME complete repositories with the necessity that ALL (or at each most) repositories be so extensive. You're welcome to remove whatever history you like from your personal copy. It's not worth the effort to the project as a whole to save a small amount of disk space. The CVS tree is currently 843 Mbytes, complete. Storage cost (even if you buy SCSI disks) is about $16. With cheap disks, that's about $6. The time it took me to do the research for this paragraph is worth more than that! -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
apm halts my system during start up.
The message says it all - my system does the equivalent of a 'halt -p' upon launching `apm' during boot up - ... acd0: CD-RW HP CD-Writer+ 7200 at ata0-master using PIO3 acd1: CDROM FX4820T at ata0-slave using UDMA33 Waiting 2 seconds for SCSI devices to settle pass0 at ahc0 bus 0 target 6 lun 0 pass0: scanner 636EL 1.40 Fixed Scanner SCSI-2 device pass0: 3.300MB/s transfers Mounting root from ufs:/dev/ad0a ed0: starting DAD for fe80:0001::0240:05ff:fe59:30f0 ed0: DAD complete for fe80:0001::0240:05ff:fe59:30f0 - no duplicates found restarted Waiting (max 60 seconds) for system process `bufdaemon' to stop... stopped Waiting (max 60 seconds) for system process `syncer' to stop... ... Since I'm not using apm for anything in particular, I just took it out of the loop, so to speak. Here's a full startup (sans apm) - Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #0: Mon Apr 24 10:33:38 EDT 2000 atrens@churchill:/usr/local/src/cvs/sys/compile/CHURCHILL Timecounter "i8254" frequency 1193182 Hz CPU: AMD Athlon(tm) Processor (604.23-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x621 Stepping = 1 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR AMD Features=0xc040AMIE,DSP,3DNow! real memory = 201261056 (196544K bytes) avail memory = 191688704 (187196K bytes) Preloaded elf kernel "kernel" at 0xc03cf000. VESA: v3.0, 16384k memory, flags:0x1, mode table:0xc0352497 (1000117) VESA: 3dfx Interactive, Inc. Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface apm0: APM BIOS on motherboard apm: found APM BIOS v1.2, connected at v1.2 pcib0: AMD-751 host to PCI bridge on motherboard pci0: PCI bus on pcib0 pcib1: AMD-751 PCI-PCI (AGP) bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: 3Dfx Voodoo 3 graphics accelerator at 5.0 irq 11 isab0: VIA 82C686 PCI-ISA bridge at device 4.0 on pci0 isa0: ISA bus on isab0 atapci0: VIA 82C686 ATA66 controller port 0xffa0-0xffaf at device 4.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 chip1: VIA 82C686 ACPI interface at device 4.4 on pci0 atapci1: Promise ATA66 controller port 0xcc00-0xcc3f,0xd000-0xd003,0xd400-0xd407,0xd800-0xd803,0xdc00-0xdc07 mem 0xeffe-0xefff irq 11 at device 13.0 on pci0 ata2: at 0xdc00 on atapci1 ahc0: Adaptec 2910/15/20/30C SCSI adapter port 0xc400-0xc4ff mem 0xeffcf000-0xeffc irq 10 at device 14.0 on pci0 ahc0: aic7850 Single Channel A, SCSI Id=7, 3/255 SCBs ahc0: Host Adapter Bios disabled. Using default SCSI device parameters ed0: NE2000 PCI Ethernet (RealTek 8029) port 0xc000-0xc01f irq 9 at device 15.0 on pci0 ed0: supplying EUI64: 00:40:05:ff:fe:59:30:f0 ed0: address 00:40:05:59:30:f0, type NE2000 (16 bit) pcm0: AudioPCI ES1371 port 0xbc00-0xbc3f irq 5 at device 16.0 on pci0 fdc0: NEC 72065B or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5" drive on fdc0 drive 0 atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: System console on isa0 sc0: VGA 16 virtual consoles, flags=0x200 sio0 at port 0x3f8-0x3ff irq 4 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A ppc0: Parallel port at port 0x378-0x37f irq 5 on isa0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode lpt0: Printer on ppbus0 lpt0: Interrupt-driven port unknown0: PNP0c01 at iomem 0-0x9fbff,0x9fc00-0x9,0xf-0xf,0x10-0xbfe,0xbff-0xbff7fff,0xbff8000-0xbff,0x-0x on isa0 unknown: PNP can't assign resources unknown1: PNP0200 at port 0-0xf,0x80-0x90,0x94-0x9f,0xc0-0xde drq 4 on isa0 unknown2: PNP0100 at port 0x40-0x43 irq 0 on isa0 unknown3: PNP0b00 at port 0x70-0x71 irq 8 on isa0 unknown: PNP0303 can't assign resources unknown4: PNP0800 at port 0x61 on isa0 unknown5: PNP0c04 at port 0xf0-0xff irq 13 on isa0 unknown: PNP0501 can't assign resources unknown: PNP0501 can't assign resources unknown: PNP0400 can't assign resources unknown: PNP0700 can't assign resources unknown6: PNP0a03 at port 0x22,0x72-0x75,0x294-0x297,0x400-0x40f,0x4d0-0x4d1,0xcf8-0xcff,0x800-0x87f on isa0 unknown: PNP0f13 can't assign resources IPsec: Initialized Security Association Processing. ad0: 13072MB QUANTUM FIREBALLP KX13.6 [26559/16/63] at ata2-master using UDMA66 ad1: 8063MB QUANTUM FIREBALL CR8.4A [16383/16/63] at ata2-slave using UDMA66 acd0: CD-RW HP CD-Writer+ 7200 at ata0-master using PIO3 acd1: CDROM FX4820T at ata0-slave using UDMA33 Waiting 2 seconds for SCSI devices to settle pass0 at ahc0 bus 0 target 6 lun 0 pass0: scanner 636EL 1.40 Fixed Scanner SCSI-2 device pass0: 3.300MB/s transfers Mounting root from
Re: kernel build broken...
during the mkdep, I get: ../../kern/kern_linker.c:49: linker_if.h: No such file or directory ../../kern/link_aout.c:45: linker_if.h: No such file or directory ../../kern/link_elf.c:55: linker_if.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /usr/src/sys/compile/MONITOR. And the compile fails. I can't find linker_if.h anywhere. Hi, Eric. I noticed that too, but it's fixed now (for me anyway). I see this in the commit logs: obrien 2000/04/24 16:08:25 PDT Modified files: sys/conf files Log: Add linker_if.m to the mix. Revision ChangesPath 1.359 +2 -1 src/sys/conf/files -- Trevor Johnson http://jpj.net/~trevor/gpgkey.txt 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
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: Archive pruning
In message [EMAIL PROTECTED], Richard Wackerbarth wrote } Do we really need 5 year old history? } } Yes. } I don't disagree that we need to maintain the history. } } I do, however, question the policy that REQUIRES EVERYONE to maintain that } much history. I've been following this thread at some distance for a while, and I don't understand your definition of ``everyone''. Aside from developers, who do you feel is a good candidate to track the entire CVS repository, rather than using CVSUP or some other method to get only the tree they are interested in? I'm not trying to be snide; it's possible that I'm missing some element of your argument, but I think using the term ``everyone'' is overstating the case considerably. -- Jon Hamilton [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
buildworld broken
Hello, Cvsupped 2 hours ago: ... === sys/modules/syscons/fire @ - /usr/src/sys machine - /usr/src/sys/i386/include rm -f .depend mkdep -f .depend -a -nostdinc -I/usr/src/sys/modules/syscons/fire/.. -D_KERNEL -DKLD_MODULE -I- -I/usr/src/sys/modules/syscons/fire/.. -I. -I@ -I@/../include -I/usr/obj/usr/src/i386/usr/include /usr/src/sys/modules/syscons/fire/fire_saver.c /usr/src/sys/modules/syscons/fire/fire_saver.c:44: machine/random.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /usr/src/sys/modules/syscons/fire. *** Error code 1 Stop in /usr/src/sys/modules/syscons. *** Error code 1 Did this break it? : obrien 2000/04/24 10:30:08 PDT Modified files: sys/conf files files.i386 sys/dev/syscons syscons.c sys/i386/i386machdep.c mem.c sys/i386/isa/pcvtpcvt_hdr.h sys/i4b/layer2 i4b_tei.c sys/i4b/layer4 i4b_l4mgmt.c sys/kern kern_random.c sys/net if_spppsubr.c sys/netipx ipx_input.c Removed files: sys/i386/isa random_machdep.c sys/i386/include random.h Log: * Use sys/sys/random.h rather than a i386 specific one. * There was nothing that should be machine dependant about i386/isa/random_machdep.c, so it is now sys/kern/kern_random.c. -- lx To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Remote serial gdb is broken in -CURRENT.
On Sunday, 23 April 2000 at 10:07:38 +0100, Doug Rabson wrote: On Sun, 23 Apr 2000, Greg Lehey wrote: In the last few days, my remote serial gdb has almost completely stopped working. Previously I had (almost) no trouble at 38400 bps; now I can barely get a response at all at 9600 bps. Does anybody have an idea where this could be coming from? I noticed this too but I have no idea why. I also had to move back to 9600. I've found the problem and fixed it. It's been broken all along, but for some reason it got worse lately. Basically, what happened was that the getpacket function, which does polled I/O, wasn't locking out interrupts, and something was interrupting long enough for characters to get lost. Since sometimes several consecutive characters got lost, it seems likely that either something locks out interrupts for an inappropriately long time, or the sio interrupt routines steal them. Anyway, it works nicely at 115200 bps now. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Archive pruning
On Mon, 24 Apr 2000, Nate Williams wrote: I'm violently opposed to removing it completely. The only thing I wouldn't be violently opposed to would be removing 'Attic' files (truly unused file), and having them stored away somewhere in the tree for archival purposes. You realize that its possible to setup your local repo to drop these right? (Attic files that is.) -- | 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: buildworld broken
On Tue, 25 Apr 2000, Alexander Matey wrote: Cvsupped 2 hours ago: ... === sys/modules/syscons/fire @ - /usr/src/sys machine - /usr/src/sys/i386/include rm -f .depend mkdep -f .depend -a -nostdinc -I/usr/src/sys/modules/syscons/fire/.. -D_KERNEL -DKLD_MODULE -I- -I/usr/src/sys/modules/syscons/fire/.. -I. -I@ -I@/../include -I/usr/obj/usr/src/i386/usr/include /usr/src/sys/modules/syscons/fire/fire_saver.c /usr/src/sys/modules/syscons/fire/fire_saver.c:44: machine/random.h: No such file or directory mkdep: compile failed *** Error code 1 I've stepped on it too and fix is just committed. -- 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
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
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: buildworld broken
Hello, On Tue, Apr 25, 2000 at 12:11:58PM +0700, Boris Popov wrote: mkdep -f .depend -a -nostdinc -I/usr/src/sys/modules/syscons/fire/.. -D_KERNEL -DKLD_MODULE -I- -I/usr/src/sys/modules/syscons/fire/.. -I. -I@ -I@/../include -I/usr/obj/usr/src/i386/usr/include /usr/src/sys/modules/syscons/fire/fire_saver.c /usr/src/sys/modules/syscons/fire/fire_saver.c:44: machine/random.h: No such file or directory mkdep: compile failed *** Error code 1 I've stepped on it too and fix is just committed. Yeah, I saw your commit. Thanks. -- Boris Popov -- lx To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
