On Thu, 27 Apr 2000, Poul-Henning Kamp wrote:
> ===
> SUMMARY
> ===
> World
> ***didn't compile***
> 3 Warnings
> Kernel LINT
> compiled
> 147 Warnings
LINT has been broken for a long time by depenencies on o
In message <[EMAIL PROTECTED]>, Will Andrews writes:
>On Fri, Apr 28, 2000 at 07:45:36AM +0200, Poul-Henning Kamp wrote:
>> I agree too, but nobody has written *that* code yet.
>
>Instead of trying to find these yourself, why not invest this time in
>writing said script? :)
I already wrote src/to
On Fri, Apr 28, 2000 at 07:45:36AM +0200, Poul-Henning Kamp wrote:
> I agree too, but nobody has written *that* code yet.
Instead of trying to find these yourself, why not invest this time in
writing said script? :)
(I'm not volunteering for this.. ;-)
--
Will Andrews <[EMAIL PROTECTED]>
GCS/E
In message <[EMAIL PROTECTED]>, Donn Miller writes:
>Will Andrews wrote:
>>
>> On Wed, Apr 26, 2000 at 11:50:11AM +0200, Poul-Henning Kamp wrote:
>
>> > Comments, tests and reviews please.
>>
>> Just write a script to check all #include's against their prototypes and
>> have it autogen diffs.
>
Will Andrews wrote:
>
> On Wed, Apr 26, 2000 at 11:50:11AM +0200, Poul-Henning Kamp wrote:
> > Comments, tests and reviews please.
>
> Just write a script to check all #include's against their prototypes and
> have it autogen diffs.
I agree. I like the automated method better. What happens i
On Wed, Apr 26, 2000 at 11:50:11AM +0200, Poul-Henning Kamp wrote:
> New patch at: http://phk.freebsd.dk/misc/sys_kernel_h.patch
>
> This patch removes 67 unneeded instances of #include
>
> Comments, tests and reviews please.
Just write a script to check all #include's against their prototypes
> I don't see the purpose of having a firmware image permanently
> resident (especially given their sizes). Getting the boot loader to
> directly load the firmware into the device seems a much nicer
> solution. If this is impractical, treating the firmware as a kld and
> unloading it after downl
Hi
At Tue, 28 Mar 2000 06:46:27 -0500 (EST),
John Baldwin <[EMAIL PROTECTED]> wrote:
> >> Looks good to me, but I need to test it to make sure. I will also look
> >> at seeing if I can squeeze the int 13 extension installation check into
> >> boot1 and boot0 so that they will use packet mode au
:Hi Matthew,
:
:On Thu, 27 Apr 2000, Matthew Dillon wrote:
:
:> I can't imagine why MFS would perform better... it shouldn't, every
:> block is stored in system memory *TWICE* (once in the VM cache, and
:> once in the mfs process's address space). If you have enough system
:
:I've b
Hi Matthew,
On Thu, 27 Apr 2000, Matthew Dillon wrote:
> I can't imagine why MFS would perform better... it shouldn't, every
> block is stored in system memory *TWICE* (once in the VM cache, and
> once in the mfs process's address space). If you have enough system
I've been runni
< said:
> How do you suggest such files get distributed?
cvsup and/or rsync. This does leave CTM-users the odd men out
> As Matt pointed out, CVS provides us with a good mechanism for
> ensuring that I can identify what version of the firmware I am using
> - and be reasonably certain it ma
Sorry not to have details at hand but anyways:
Current cvsupped today.
I have 2 parallel ports in use.
I have had no problems with kernels dated 2 weeks or older, but since a few
days ago, the system crashes at boot while probing the parallel ports. "Page
fault while in supervisor mode", (I see
Ilya Naumov wrote:
> Hello,
>
> make release fails with the following diagnosis:
>
> ===> bin/csh/nls
> ===> bin/csh/nls/finnish
> install -c -o root -g wheel -m 444 tcsh.cat
>/R/stage/trees/bin/../usr/share/nls/fi_FI.ISO_8859-1/tcsh.cat
> *** Error code 71
>
I just finished one a couple of ho
On Thu, Apr 27, 2000 at 01:06:16AM -0500, Michael C . Wu wrote:
> On Thu, Apr 27, 2000 at 01:14:02AM +0400, Andrey A. Chernov scribbled:
> | I often notice processes hanging forever on exit's ttywait when TCP
> | connection dropped. Here is a patch I plan to commit which restrict
> | waiting for o
On Tue, Apr 25, 2000 at 03:27:38AM +1000, Garrett Wollman wrote:
>The fact that said directory is under CVS control, which is what I'm
>suggesting we get away from.
How do you suggest such files get distributed? Everything else is
in the CVS repository and most (if not all) of our build process
On Fri, 21 Apr 2000, Kris Kennaway wrote:
> OpenSSL includes asm code for several platforms to speed up various
> operations. Currently we don't build any of this - the attached patch
> turns on asm code for Pentiums and above (it relies on an uncommitted
> patch to sys.mk which defined MACHINE_CP
On Tue, Apr 25, 2000 at 09:48:18PM +1000, Sheldon Hearn wrote:
>If that's the _only_ point, then Garrett Wollman's idea should work
>perfectly. Stick the files under CVS, just agree that they should
>never be revised, but rather that new versions should be imported in a
>different directory and t
On Wed, Apr 26, 2000 at 08:53:52AM -0700, Frank Mayhar wrote:
> "Frankly, my dear, I don't give a damn."
Richard, for the record, I'd like to point out that the person who said
this is not a developer and therefore the backlashing you're getting is not
solely from developers. Other people are sic
...snip...
>
> Its nice to see someone actually using kobj so soon. There is a possible
> performance problem though - kobj method calls are roughly 20% slower than
> direct function calls. Having said that, this isn't that slow - I timed a
> method call to a two argument function at ~40ns on a 3
Hello,
make release fails with the following diagnosis:
===> bin/csh/nls
===> bin/csh/nls/finnish
install -c -o root -g wheel -m 444 tcsh.cat
/R/stage/trees/bin/../usr/share/nls/fi_FI.ISO_8859-1/tcsh.cat
*** Error code 71
--
Best regards,
Ilya mailto:[EMAIL PROTE
At 10:16 AM -0700 2000/4/27, Mike Smith wrote:
> I would consider 4.0, several (three or four) strings of LVD disks and
> either a Mylex eXtremeRAID 1100 (64MB or more) or an AMI MegaRAID
> Enterprise 1500. (The 1600 should probably work too, but I haven't seen
> one yet so I can't be sure.)
===
SUMMARY
===
World
***didn't compile***
3 Warnings
Kernel LINT
compiled
147 Warnings
Kernel GENERIC
compiled
58 Warnings
Kernel GENERIC98
***didn't compile***
63 Warn
-On [2427 07:05], Stephen Hocking-Senior Programmer PGS SPS Perth
([EMAIL PROTECTED]) wrote:
>Haven't seen any discussion for quite some time. The Linux people seem to be
>getting into a lather about it as well. Rehashing the issues like device
>persistence, et cetera
< said:
> Was this not ``make buildworld'' tested, or is there a change to
> gnu/usr.bin/gperf/Makefile you forgot to commit?
I am obviously *way* out of date with the state of the build
system I was trying to quickly get things back working again for
upgrade builds, and ended up breaking e
On Thu, Apr 27, 2000 at 12:46:43PM -0400, Garrett Wollman wrote:
> I got caught out by gperf version skew. gperf is now a build-tool (as
> it should always have been) so this problem should be fixed in your
> next update.
cc -pipe -O -DSHELL -I. -I/FBSD/src/bin/sh -Wall -Wformat-static
mksy
On Thu, Apr 27, 2000 at 12:46:43PM -0400, Garrett Wollman wrote:
> I got caught out by gperf version skew. gperf is now a build-tool (as
> it should always have been) so this problem should be fixed in your
> next update.
Was this not ``make buildworld'' tested, or is there a change to
gnu/usr.b
> I'm seriously contemplating getting a Dell PowerEdge 2450 with
> five internal 10kRPM/18GB disks, 2GB of RAM, two of the fastest
> processors they've got, perhaps a pair of Intel EtherExpress Pro 100+
> NICs, and giving this another go with FreeBSD 4.0-STABLE.
I would consider 4.0, sev
:
: Do you have any thoughts on this subject? Is 3.2-RELEASE old and
:non-optimized enough that it really could stand replacing?
3.2 is certainly old. The question is whether or not the performance
issue that caught you under 3.2 is fixed under 4.0. Not knowing what
was caus
At 9:34 AM -0700 2000/4/27, Matthew Dillon wrote:
> I can't imagine why MFS would perform better... it shouldn't, every
> block is stored in system memory *TWICE* (once in the VM cache, and
> once in the mfs process's address space). If you have enough system
> memory to crea
< said:
> Compiling 5.0-CURRENT on 4.0-STABLE generates problems in getconf:
I got caught out by gperf version skew. gperf is now a build-tool (as
it should always have been) so this problem should be fixed in your
next update.
-GAWollman
To Unsubscribe: send mail to [EMAIL PROTECTED]
with
: I use a mfs for storing the Diablo history file on our news
:peering server. Yes, I know the front part of the file is mmap()'ed
:and effectively kept completely in memory anyway, but I've seen
:periods of time when we received over 160,000 articles in a single
:hour (an average of ab
Compiling 5.0-CURRENT on 4.0-STABLE generates problems in getconf:
===> usr.bin/getconf
gperf -t -L ANSI-C -C -k 1,2,7-10,21,'$'
/usr/current/src/usr.bin/getconf/confstr.gperf >confstr.c
/* starting time is 11:48:16 */
gperf: unrecognized option `-L'
usage: gperf
[-acCdDef[num]gGhHijkKlnNoprsStTv
At 1:02 PM +0800 2000/4/27, Stephen Hocking-Senior Programmer PGS SPS
Perth wrote:
> Haven't seen any discussion for quite some time. The Linux people seem to be
> getting into a lather about it as well. Rehashing the issues like device
> persistence, et cetera.
Yeah, there's a reall
In message <[EMAIL PROTECTED]>, Brian Somers writes:
>> Yes, the src/tools/tools/kerninclude script first renames the include
>> and if the source file still compiles it declares a "no-read" and
>> leaves the #include intact.
>
>The thing that's screwed me up the most doing this sort of thing is
> In message <[EMAIL PROTECTED]>, Greg Lehey writes:
> >On Wednesday, 26 April 2000 at 11:50:11 +0200, Poul-Henning Kamp wrote:
> >>
> >> New patch at: http://phk.freebsd.dk/misc/sys_kernel_h.patch
> >>
> >> This patch removes 67 unneeded instances of #include
> >>
> >> Comments, tests and review
At 11:05 PM -0700 2000/4/26, Matthew Dillon wrote:
> You should be able to create a large virtual VN device. man
> vnconfig for more information - you have the choice of making it
> file-backed, swap-backed, or swap-backed with the swap pre-reserved.
> file-backed VN devices
36 matches
Mail list logo
