:
: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
:I'm sure that something can be done for the kld compatibility issues
:so that you can have your SMP cake and eat it too. Just give it a bit
:more thought. :)
:
:- Jordan
Thought I have. Time I don't. While I don't particularly see a
problem staying compatible with KLD modules that do
On 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
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
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
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.
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
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
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
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.
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
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
On Mon, 24 Apr 2000, Jeroen C. van Gelderen wrote:
I don't think it was ever recommended that you upgrade your kernel
without upgrading and rebuilding the modules (better still, world) at
the same time. So this wouldn't really have an adverse effect, would it?
Such a policy is totally
Richard Wackerbarth wrote:
On Mon, 24 Apr 2000, Matthew Dillon wrote:
: However, I consider your SMP changes VERY destablizing; they BREAK
: lots of modules :-(
Huh? No they don't. They simply require recompiling the modules. If
they actually broke the modules I
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
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
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
"Brandon D. Valentine" wrote:
On Mon, 24 Apr 2000, Alok K. Dhir wrote:
Totally off topic question that I've wondered for some time now - what
does MFC stand for?
According to the FAQ section located on the web @
http://www.freebsd.org/FAQ/misc.html#AEN3908
Q: What does 'MFC' mean?
On Mon, Apr 24, 2000 at 09:27:04AM -0500, Richard Wackerbarth wrote:
On a released system, I may not have the sources to recompile the module.
It might be a proprietary module that I got with the hardware, for example.
How real is this? What modules are we talking about? The last time
I
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
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.
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
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
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
Richard Wackerbarth wrote:
On a released system, I may not have the sources to recompile the module.
It might be a proprietary module that I got with the hardware, for example.
That is why STABLE INTERFACES are so IMPORTANT to USERS.
"Current" is a sandbox. Lower expectations are part of
On Mon, Apr 24, 2000 at 09:27:04AM -0500, Richard Wackerbarth wrote:
On a released system, I may not have the sources to recompile the module.
It might be a proprietary module that I got with the hardware, for example.
How real is this? What modules are we talking about? The last time
On the _other_ hand:
1. 4.0 hasn't been out long enough for there to be any significant support
for it in proprietary systems. It takes more lead time than this.
Unfortunately, many vendors will simply install from the 4.0-RELEASE CD
and build their modules there.
3. Any proprietary
:On Mon, Apr 24, 2000 at 09:27:04AM -0500, Richard Wackerbarth wrote:
: On a released system, I may not have the sources to recompile the module.
: It might be a proprietary module that I got with the hardware, for example.
:
:How real is this? What modules are we talking about? The last time
:Because if we do not provide a STABLE ABI, we WON'T get third-party
:(binary only) kernel modules.
:
:I'm very divided in this issue. 4.x has just started, and would be
:seriously impaired if no further improvements to it's SMP get in. On
:the other hand, if we can't garantee third party
:As the original author of the cil/cml code I can say I was glad to see that
:Matt
:had finally put it to rest. It was a desperate hack made in an attempt to pinch
:a little more performance out of the paradigm without dealing with the whole
:spl() problem set. I would have done it myself if
On Mon, 24 Apr 2000, Frank Mayhar wrote:
1. 4.0 hasn't been out long enough for there to be any significant support
for it in proprietary systems. It takes more lead time than this.
So make the change and release it as FreeBSD5. Save the big changes for
something called FreeBSd6 or
After further review I don't think there are any compatibility problems
with the spl*() mechanisms.
But I must still caution that due to the extensive nature of the
cleanup, despite being mostly internal to the kernel, there could
very well be other things that we have
On Mon, 24 Apr 2000, Alfred Perlstein wrote:
I think as a whole we need to evaluate the use of macros, they're
one of the major problems with changes like this and several people
have come forward over time with strong numbers showing that the
code bloat causes that comes with overuse of
On Mon, Apr 24, 2000 at 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 --
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
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
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".
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
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
Gee, is that perhaps because FreeBSD keeps breaking the ABI to modules
so every vendor that has ever tried to use them has been bitten by the
fact that they have to maintain N version for each branch of FreeBSD???
Can you list some specific examples? I'm not trying to be a wise-ass,
I'm
On Mon, 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
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".
On Mon, 24 Apr 2000, you wrote:
On Mon, Apr 24, 2000 at 04:46:43AM -0500, Richard Wackerbarth wrote:
From the USER's perspective, anything that requires me to as much as
reload
a module/program that I have already installed "breaks" it.
The fact that it is only necessary to recompile
No-one forces you to upgrade you systems. Partial upgrades
are something that are
nice when they work, but understood when they don't.
We don't accept bug reports (typically) when a person hasn't
upgraded their world,
kernel, and modules. I don't understand why we're accepting
On Mon, 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
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,
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;
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
So you guys (core) choose -- do you want 4.x to reap the benefits of
further SMP development or not?
I've read all the feedback on this thread and now feel that it would
be worthwhile to simply bring the SMP changes in on Wednesday. As others
have pointed out, we don't have enough 3rd
Jordan K. Hubbard writes:
So you guys (core) choose -- do you want 4.x to reap the benefits of
further SMP development or not?
I've read all the feedback on this thread and now feel that it would
be worthwhile to simply bring the SMP changes in on Wednesday. As others
Are there any 3rd party NIC klds yet?
NTMK.
- Jordan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
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
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
Gee, is that perhaps because FreeBSD keeps breaking the ABI to modules
so every vendor that has ever tried to use them has been bitten by the
fact that they have to maintain N version for each branch of FreeBSD???
Can you list some specific examples? I'm not trying to be a wise-ass,
On Mon, Apr 24, 2000 at 02:02:28PM -0500, Richard Wackerbarth wrote:
That is also partly why you are also lacking the respect and support of a
wider audience. If you act like FreeBSD is just a "developer's sandbox",
that's what it will be. If you want it to be something greater than
On Mon, 24 Apr 2000, you wrote:
On Mon, Apr 24, 2000 at 02:02:28PM -0500, Richard Wackerbarth wrote:
That is also partly why you are also lacking the respect and support of
a wider audience. If you act like FreeBSD is just a "developer's
sandbox", that's what it will be. If you want it
On Mon, Apr 24, 2000 at 02:14:50PM -0700, Rodney W. Grimes wrote:
Developers and early adopters are the ones tracking -STABLE. Users are
installing binary snapshots and releases.
Some users do install snapshots and/or releases. Snap shots occur on a
regular basis and are affected by
{First one bounced by hub with ``out of memory'' error... second attempt}
Are there any 3rd party NIC klds yet?
NTMK.
It's not quite a kld, but ET Inc's modules are distributed as a .o.
Also I know of work underway to support some of the fancier SDL WanNic
cards that would have to be kld's
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
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
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
The network stack is equally easy to make MP-safe. In this case we
have a shared lock to lookup sockets for host/port combinations and
then fine-grained exclusive locks within those sockets. Route table
and other high level operations could in fact remain BGL'd without
On Mon, 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])
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
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
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
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
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
* 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
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.
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
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
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
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
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 |
On Mon, 24 Apr 2000, Kenneth Wayne Culver wrote:
I believe that it depends on what changes were made since the last
recompile, although it is good practice to at least recompile the modules
when the kernel is recompiled.
In my opinion the best way to handle things like this is to add a
modules
On 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.
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
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
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,
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
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
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
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
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
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
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
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
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.
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
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-
On Tue, 25 Apr 2000, Bruce Evans wrote:
Given that this is a change in splxxx() I suspect that it breaks
most modules, but probably not all modules. A quick grep -l spl * | wc
Given that this is a change in the splxxx() implementation, it breaks
zero modules.
splxxx() was changed
Personally, I don't think that's a bad idea, I never had trouble going to
/usr/src/sys/modules and doing a make depend then make then make install,
but I guess it'd be nicer if everything just compiled when I built my
kernel, and better yet, it would be nice to have it make the
"modules.old"
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
94 matches
Mail list logo
