nd I think we can safely say "impossible".
>I think we first need to figure out the security implications.
I think the security implications of having no entropy are much
worse than having entropy which a truly superhuman *maybe* could
guess *some* of the bits in, are far worse.
--
P
In message <[EMAIL PROTECTED]>, "Steve O'Hara-Smith" writes
:
>
>On 17-Jul-00 Poul-Henning Kamp wrote:
>> NTP is the perfect way to gather entropy at bootup!
>
>Only if in reach of an NTP server ?
Obviously :-)
--
Poul-Henning Kamp | UNIX
In message <[EMAIL PROTECTED]>, Alexander Langer writ
es:
>Thus spake Poul-Henning Kamp ([EMAIL PROTECTED]):
>
>> I have thought about adding a entropy server to my array of weird
>> servers in my lab. Something like a Geiger counter and a smokedetector
>> could
to people in need.
I have thought about adding a entropy server to my array of weird
servers in my lab. Something like a Geiger counter and a smokedetector
could do wonders.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam memb
about that btw, the output from getnanotime()
is not very random at all, unless you dive into the timecounter
code to find out what the parameters are.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-t
having
No, not "fixing the problems", "obscuring the problems".
The tintin++ code contains errors, and you should fix them.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-taho
In message <[EMAIL PROTECTED]>, "Thomas D. Dean" writes:
>I turned off the malloc AJ flags, via malloc.conf. It improved 'make
>world' by something like 17% == mean_aj/mean_AJ.
Make sense, make world is dominated by gcc/cc1 which is doing a
lot of malloc/free o
it if you want to run benchmarks:
ln -sf aj /etc/malloc.conf
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompete
g all of the devices, but before the install menu came up.
That has been fixed.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by
.
Somebody enable the 'A' option of phkmalloc and examine the core.
ln -sf A /etc/malloc.conf
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice wh
dkuug; they're not sure they should host that domain.
>Phoneing cybercity: You don't own that domain? I can't help you...
>
>I wouldn't mind hosting the DNS if needed.
>
>Leif
>
>
>
>
>
>
>
>To Unsubscribe: send mail to [EMAIL PROTECTED
In message <[EMAIL PROTECTED]>, Kri
s Kennaway writes:
>I intend to MFC this stuff in 4 or 5 days assuming it doesn't present any
>problems,
I'm sorry, but isn't that a tad fast, considering the scope of these
changes ?
--
Poul-Henning Kamp | UNIX since Zilog
they should live. Vs. where there would be consistency in the /sys tree.
In fact, I belive there actually was a consensus for moving filesystems
under /sys/fs but not for moving net*. The reason for the difference
in concensus is probably that net* is a systematic prefix.
--
Poul-Henning Kamp | U
;t match executable version (5.00503) at Config.p
m line 18.
*** Error code 255
Stop in /syv/src/gnu/usr.bin/perl/perl.
*** Error code 1
Stop in /syv/src/gnu/usr.bin/perl.
*** Error code 1
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
In message <[EMAIL PROTECTED]>, Matthew Dillon writes:
>:
>:Right, but if mounting with -osoftdep, does what a "tunefs -n enable"
>:does (and vice versa) fsck will have that knowledge and the tunefs
>:step would be un-needed.
>:
>:--
>:Poul-Henning Ka
o. When it is next mounted, then update it to the new state.
Right, but if mounting with -osoftdep, does what a "tunefs -n enable"
does (and vice versa) fsck will have that knowledge and the tunefs
step would be un-needed.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAI
e re-ordering (or at least the write semantics that
>softupdates expects).
This one was a misunderstanding, in fact vinum/raid5 works more
reliably with softupdates than without I belive.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
F
zing the
>meeting, and Matt Dillon's webpage gives a pretty good summary of
>the work too (at http://apollo.backplane.com/FreeBSDSmp/)
But we're not looking for a summary of the meeting, we're looking
for all the gory details...
--
Poul-Henning Kamp | UNIX since Zilog Z
In message <[EMAIL PROTECTED]>, Brian Somers writes:
>What about doing the changes on a branch with the understanding that
>the branch will *replace* HEAD when it stabilises ?
"CVS branches suck" is the reason I belive.
--
Poul-Henning Kamp | UNIX since Zilog Zeus
In message <[EMAIL PROTECTED]>, Warner Losh writes:
>In message <[EMAIL PROTECTED]> Poul-Henning Kamp writes:
>: I think core has approved in principle, and several core members
>: were present at the meeting (at least peter, dg, gibbs, dfr), that
>: being said, I think
en too much taboo for us
to bother, and it would (as far as we know) not work with cvsup.
I'm not sure now is the time to do it either.
So: No I don't like -current being toast anymore than you do, but
I don't think there is a viable alternative.
--
Poul-Henning Kamp |
Am I the only person who miss a brief document which tells what
the outcome of the meeting was ?
Can we get to see the slides ?
Audio ?
Video ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3
ber '94.
>
>Are there any arguments against changing the filesystem type name to
>'ffs' in the kernel and in the userland? If not, I'll volunteer to
>find all kernel/userland uses I can and provide a diff.
The correct way to do this is to make it accept both for some
r or all the weird versions of write
only or "write here - read there" I/O registers in existence.
Obviously the video driver will need to send a signal or clue to the
Xserver saying "you own the device, you'd better do something"
--
Poul-Henning Kamp | UNIX since
ur problem if we change every bwrite() into a VOP_BWRITE()?
Well, I'm not sure it is correct to go the detour around Vnodes,
if we do, we need to add VOP_BAWRITE, VOP_BDWRITE and all those
other operations as well.
But what vnode would you use for a buffer associated with a freeblock
bitmap ?
In message <[EMAIL PROTECTED]>, "Daniel O'Connor" write
s:
>
>On 15-Jun-00 Poul-Henning Kamp wrote:
>>Remove the "wd" compatibility name from the "ad" driver.
>>
>>WARNING: If you have not updated to use /dev/wd* in yo
--- Forwarded Message
Message-Id: <[EMAIL PROTECTED]>
From: Poul-Henning Kamp <[EMAIL PROTECTED]>
Date: Thu, 15 Jun 2000 13:30:53 -0700 (PDT)
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: cvs commit: src/sys/dev/ata ata-disk.c src/sys/i386/i386
autoconf.c
mp; B_DEFERRED) == 0 &&
- bioops.io_countdeps && (*bioops.io_countdeps)(bp, 0)) {
+ buf_countdeps(bp, 0)) {
bp->b_flags |= B_DEFERRED;
continue;
}
@@ -278,5 +278,8 @@
}
he magic-config-version-number.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAI
ut definitely not a good enough argument to support
>the massive breakage this otherwise entails.
I have yet to see any signs of "massive breakage".
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BS
doing the next update & make world..
>
>We've had our 24 hours, and the responses I've seen so far have been
>universally negative. I'm going to ask Jake to back this out.
I'm for.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP sin
\
> ^
>
>I objected to a recent commit hiding the fact that this is
>"(elm)->field.sle_next". Anyway, curelm must be a pointer to a struct.
>Not just any struct; the struct must contain a "field" declared usin
return FOO;
>}
>
>and reduce that to
>
>/* Stuff */
>
>On the grounds that my routine will never see the other crap?
>If so, way cool!
yes, enjoy :-)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
Free
() for this).
>
>How does this work for all the routines? When you register the
>"new" minor number, can you be specifying new read/write/poll/ioctl/etc
>routines?
>
>I ask, as my RNG is a kld, and I want it to be as separate as possible
>without getting ridiculous.
;it.
Please go ahead, I'll review and test your patches.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
in src/bin/csh a make clean tries to delete csh.1 this fails if
src is mounted Read-Only.
Why is this file checked in in the first place if make clean wants
to remove it ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam
ection closed
>>
>> I don't recall ever running into this before.
>
>Which host are you pilling from? I am slurping things out of
>cvsup.uk.freebsd.org and see the same messages. I thought it was crappy
>modem connection.
Try to disable the newreno stuff.
--
Poul-
_remove
>> will not.
>
>Is it correct to assume that destroy_dev() still isn't working correctly?
>(disk_destroy certainly isn't).
disk_destroy is different from destroy_dev, and I'll get to it real soon.
>Also, while you still can, that should be dev_destroy(
It sounds like a useful feature to me.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send
sw_remove, so any later uses
>of dev_t's get an error because the device has gone away.
destroy_dev will clear the necessary fields in a dev_t, cdevsw_remove
will not.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD c
uired.
I actually think you could still do it with real floppies up until
the point where we went to two-floppy install...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute
27;t work. da0a works fine and I got rid of all the da0s1a,b,e,f,g ones ?
In all likelyhood /dev/da0s1a is the one you should use.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribut
d you try to update your bootblocks with the disklabel
program and see if that stops the warning Manfred ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can a
s that NewReno cause very high packet loss somehow?
I can reproduce the problem when I cvsup over a lossy line, goes
away when newreno is disabled.
Who wants packet traces to look at ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD co
In message <[EMAIL PROTECTED]>, Dan Nelson writes:
>In the last episode (May 08), Poul-Henning Kamp said:
>> In message <[EMAIL PROTECTED]>, Erik de Zeeuw writes:
>> >
>> >I installed FreeBSD 5.0-2506-CURRENT on an AMD K6-2, 64Mb, 4Gb, and
>> >
couple of causes of this, but I
will try to reproduce it as you describe it with some debugging added.
Thanks for the hint!
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute t
er BSD
>traditionalists I think this would be great.
Make it
MAKEDEV -
and there will be no ambiguity.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice
rom /usr/src/usr.bin/systat/iostat.c:68:
>/usr/src/usr.bin/systat/../../sys/sys/buf.h:91: field `b_io' has incomplete type
>*** Error code 1
>
>Stop in /usr/src/usr.bin/systat.
>
>
>
>
>
>To Unsubscribe: send mail to [EMAIL PROTECTED]
>with "unsubscri
tored in a db file for instance.
Poul-Henning
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscrib
o interest in maintaining the older
version we use.
> Out of curiosity, is there a public list of all the people who
>have commit access to FreeBSD?
Yes, it's in the CVS tree in the file CVSROOT/access and in the
Handbook as well.
--
Poul-Henning Kamp | UNIX since Zilog Zeus
re undefined references to `bufwait' follow
>*** Error code 1
>
>Stop in /usr/src/sys/compile/GENERIC.
>
>
>To Unsubscribe: send mail to [EMAIL PROTECTED]
>with "unsubscribe freebsd-current" in the body of the message
>
--
Poul-Henning Kamp | UNIX si
ccd.patch (Requires biodone.patch)
Convert CCD to struct bio.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by
In message <[EMAIL PROTECTED]>, Bruce Ev
ans writes:
>On Thu, 27 Apr 2000, Poul-Henning Kamp wrote:
>
>> ===
>> SUMMARY
>> ===
>> World
>> ***didn't compile***
>> 3
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?
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 aga
===
SUMMARY
===
World
***didn't compile***
3 Warnings
Kernel LINT
compiled
147 Warnings
Kernel GENERIC
compiled
58 Warnings
Kernel GENERIC98
***didn't compile***
63 Warn
& without and ensure that the resulting object is the same modulo
>embedded compile dates.
If the MD5 over the generated object file changes after substituting an
empty file for the include, I consider it "used" by default, so that
case should be covered as well.
--
Poul-Henning Kamp
Removes 43 unneeded #include includes.
Comments, tests and reviews please
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by
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
>>
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.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since
iled
>> 149 Warnings
>> 0 Errors
>> Kernel GENERIC
>> compiled
>> 59 Warnings
>> 0 Errors
>> Kernel GENERIC98
>> ***didn't compile***
>> 54 Warnings
>> 0 Errors
>
>This doesn't lo
In message <[EMAIL PROTECTED]>, Andrzej Bialecki
writes:
>On Tue, 25 Apr 2000, Poul-Henning Kamp wrote:
>
>>
>> ===
>> SUMMARY
>> ===
>
>[27kB long list of errors deleted..]
>
>I th
===
SUMMARY
===
World
compiled
637 Warnings
45 Errors
Kernel LINT
compiled
149 Warnings
0 Errors
Kernel GENERIC
compiled
59 Warnings
0 Errors
Kernel GENERIC98
you are talking about for 4.x/5.x.
4.x-stable is a -stable tree and shall be treated as such.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately
Matt,
I will say it this last time:
Your patch does not qualify for immediate MFC.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately
qualify for immediate MFC status unless
the security officer says so.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompe
st the way it is Matt. Get used to it.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail
t enough to justify an immediate
MFC.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to
an immediate MFC in this patch. Please
allow the normal waiting period to elapse before you MFC.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequatel
an towards a sysctl which prevents bdevs
from being opened starting 2000-06-01.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incomp
:
>> crw-r- 1 root operator 13, 0x00020001 Dec 12 21:09 /dev/da0s1b
>> crw-r- 1 root operator 13, 0x00020001 Dec 12 21:09 /dev/rda0s1b
>>
>> Regards
>> Dirk
>
>--
>Brian <[EMAIL PROTECTED]>
> <http://www.Aw
AHsAOLO0GwMG7gAAAeUAAAOMrBACAbyrx8nrVwMFvKvHyerb
>Ddi8q8fJ61cDBbyryAnpCUiuiUkBOT32DQBaWgDgsFVWAwBgl6o62wgARRAATOnG
>AABAETSnrBACAawQAgIAewB7ADhA+hwCBuwAAAAC8X9/AQG8q8fiS0k4WLyryAnpCUiu
>vKvICeoOMES8q8gJ6iDujbpJATntswsASgAAAEoA4LBVVgMAYJeqOtsIAEUQADzpx0AA
>QAa65awQAgHM
lease/../usr/share/nls/fi_FI.ISO_8859-1/tcsh.cat: No such file or
directory
*** Error code 71
Stop in /syv/src/bin/csh/nls/finnish.
*** Error code 1
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3
===> bin/csh/nls
cd /usr/src/bin/csh/nls ; make afterdistribute DESTDIR=/R/stage/trees/bin
===> bin/csh/nls/finnish
make: don't know how to make distribute. Stop
*** Error code 2
Stop in /usr/src/bin/csh/nls.
*** Error code 1
--
Poul-Henning Kamp | UNIX since Zilog Zeus
was in the
>stream --nope. pulled a 'glimpse' of 'current' list but
>found no reference.
This file is generated on the fly in the compile directory
I belive.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
Fr
In message <[EMAIL PROTECTED]>, Warner Losh writes:
>In message <[EMAIL PROTECTED]> Poul-Henning Kamp writes:
>: In message <[EMAIL PROTECTED]>, Warner Losh writes:
>: >In message <[EMAIL PROTECTED]> Poul-Henning Kamp writes:
>: >: At what time does th
In message <[EMAIL PROTECTED]>, Warner Losh writes:
>In message <[EMAIL PROTECTED]> Poul-Henning Kamp writes:
>: At what time does the message come relative to the mounting of the
>: root filesystem ? Before or after ?
>
>I get mine when nfs starts up.
Any chance yo
nd{AOL mode}
Hmm, that sounds weird...
At what time does the message come relative to the mounting of the
root filesystem ? Before or after ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
In message <[EMAIL PROTECTED]>, Alan Clegg writes:
>Out of the ether, Poul-Henning Kamp spewed forth the following bitstream:
>
>> >> I'd like to recommend the following patches. Adding the option
>> >> "CLK_USE_TSC_ANYWAY" allows my laptop to
ot be set by default.
>
>I saw the same kind of patches and my laptop has this w/o any problems
>for long time.
>I'd like to commit submitted patch 2 or 3 days later if no objections.
It would be nice to have some kind of understanding why the tsc is
better than the i8254 before
agreement here, and that was also what the core decision said:
only visible to processed run under the linuxolator.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what
n, we are talking about an email which is shorter than the
list of open PRs, and if people actually *DO* something about it
it will get shorter fast
The only reason it is a long report right now is that people are sloppy!
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED]
In message <[EMAIL PROTECTED]>, Nar
vi writes:
>The summary of summaries would roughly look like this:
>
> Subject: -current build report
>
> Success: world, generic
> Fail: lint
The First part of the email is a summary just like that.
--
Poul-H
, and by sending it to -current
maybe a new junior hacker or two could be ferret out :-)
>Think a bit bigger-picture also; theoretically, we should have these
>reports for -current and the RELENG_3 and RELENG_4 branches. The
>machine-resources are available for it, we just haven't organiz
;t build.
If it reports, it includes the errors which from the non-building
components and "New warnings in *" delta lists relative to the
previous report.
I've sorted the report so that the most interesting things are
at the top.
Other ideas welcome.
--
Poul-Henning Kamp
..
It is to be left there to catch people who use functions which are
not in the kernel, but which gcc implements as built-ins :-)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribu
In message <[EMAIL PROTECTED]>, Warner Losh writes:
>In message <[EMAIL PROTECTED]> Poul-Henning Kamp writes:
>: awi.o(.text+0x3b4): undefined reference to `memcmp'
>: awi.o(.text+0x3cf): undefined reference to `memset'
>
>What I want to know is why I d
e they would shrink to
zero if we annoyed people enough with them.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsu
I have a machine which isn't doing much right now, so I have decided
to set it up as an automatic "FreeBSD Build checker".
Once per day the machine cvsups, checks out a virgin source tree,
tries to build GENERIC, GENERIC98, LINT and world. If any of these
builds fail it will send a report like
ther as a general tool or as a kernel targeted tool
under src/tools. And the faster the better :-)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately
correct. The problem you're talking about I blamed
>elsewhere, not specifically CAM. To quote from
>http://www.lemis.com/vinum/bugs.html:
OK, sorry, I havn't heard about it since FreeBSDcon and back then
CAM was in the spotlight.
--
Poul-Henning Kamp | UNIX since Zilog Ze
t least FreeBSDcon and indications seems to be that
it is actually a malloc/free gottcha in vinum.
I have nothing to do with that, apart from being releived that
we don't seem to have a random stack-smasher bug in the system.
Poul-Henning
--
Poul-Henning Kamp FreeBSD coreteam mem
right sensible to me, and I suggest you do
that.
--
Poul-Henning Kamp FreeBSD coreteam member
[EMAIL PROTECTED] "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!
To Unsubscribe: send mail to [EMAIL
um/bio problem is atrocious timing.
Actually, it is the other way around, Greg finally started to look for
the bug in vinum in the middle of my commits.
How dare he do that ?
:-)
--
Poul-Henning Kamp FreeBSD coreteam member
[EMAIL PROTECTED] "Real hackers run -
In message <[EMAIL PROTECTED]>, Hellmuth Michaelis writes
:
>>From the keyboard of Poul-Henning Kamp:
>
>> We need to be frugal about the kernel stack, for a lot of reasons,
>> that's just the way it is, and as far as I know it is the way
>> it will cont
http://phk.freebsd.dk/misc
I belive the patch is now fundamentally ready for commit, I'm running
it here myself, and the delta in kernel warnings have been analyzed
and deemed mostly harmless.
Some componenents are still not converted and use a cast from bio to
buf, prominently vinum an
at's just the way it is, and as far as I know it is the way
it will continue to be.
Get used to it.
--
Poul-Henning Kamp FreeBSD coreteam member
[EMAIL PROTECTED] "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progres
el code.. I only have one machine here.)
>
>
>On Fri, 31 Mar 2000, Poul-Henning Kamp wrote:
>> >run 4000 copies or so of linux under VMWare on FreeBSD :-)
>
>Unfortunatly you can only run one vmware at a time under BSD.
>
>> >
>> >Once we fix the d
as a goal something at least as comparable as what IBM did
>with one of their mainframes. Oh, say, lets shoot for being able to
>run 4000 copies or so of linux under VMWare on FreeBSD :-)
>
>Once we fix the deadlocks, that is.
We don't need VMWare really, we
In message <[EMAIL PROTECTED]>, Jesper Skriver writes:
>On the box below, a relative new dual PIII box, with a Intel
>motherboard, does it use the i8254 or the PIIX timecounter ?
>
>[...]
>Timecounter "PIIX" frequency 3579545 Hz
You're using the PIIX.
--
P
1201 - 1300 of 1791 matches
Mail list logo
