On Sat, Feb 01, 2003 at 23:06:50 -0800, Kris Kennaway wrote:
FreeBSD's rand() implementation has been broken for the past 23
months, since the following commit:
i.e. the first value returned from rand() is correlated with the seed
given to srand(). This is a big problem unless your seed is
On Sat, Feb 01, 2003 at 06:30:45PM +0100, [EMAIL PROTECTED] wrote:
In message [EMAIL PROTECTED], Christoph Kuk
ulies writes:
I bought new hardware for a server today, an ASUS P4S8X with
an 1.8 GHZ P4 CPU, nothing fancy I would say, which has an
onboard RAID controller (Promise) but I'm not
On Sun, Feb 02, 2003 at 12:04:22PM +0300, Andrey A. Chernov wrote:
Yes, first value correlation is there, but old formulae have even worse
effect The random sequences do not vary much with the seed, as source
file comments and whole discussion about old RNG bad effects shown. I.e.
for
After reading src/UPDATING and attempting to follow the directions to
upgrade from 4.7-RELEASE to -CURRENT, I'm having some difficulty, after
successfully building world and building and installing the kernel, I
attempted to make install in src/sys/boot. I'm getting the following error:
On Sun, Feb 02, 2003 at 01:11:06 -0800, Kris Kennaway wrote:
Another problem (noticed by tjr) is that once the sequence hits '0' it
jumps to INT_MAX and stays there forever. For example, seeding with
srand(0) produces nothing but INT_MAX from rand().
It looks like a lot more validation of
In message [EMAIL PROTECTED], Andrey A. Chernov writes:
--SUOF0GtieIMvvwua
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sun, Feb 02, 2003 at 01:11:06 -0800, Kris Kennaway wrote:
=20
Another problem (noticed by tjr) is that
[EMAIL PROTECTED] writes:
BTW, note that new formulae also used in the kernel (by BSD developers)
and taken from there - libkern/random.c - so all you say is true there
too.
It should be nuked from the kernel, and arc4random() used instead.
I agree. If no-one objects, I'll do this?
M
--
On Sun, Feb 02, 2003 at 01:11:06 -0800, Kris Kennaway wrote:
Another problem (noticed by tjr) is that once the sequence hits '0' it
jumps to INT_MAX and stays there forever. For example, seeding with
srand(0) produces nothing but INT_MAX from rand().
It looks like a lot more validation of
On Thu, 30 Jan 2003 14:41:59 +0900, Hidetoshi Shimokawa wrote
Do you get timeout only for sbp0:0:0?
Is the other drive still working?
I have no problem with concurrent accesses with `iozone -s 102400m -r
1024k`.
...
try some of the following:
- fwcontorl -g 20
- sysctl
Thus spake Andrey A. Chernov [EMAIL PROTECTED]:
Yes, first value correlation is there, but old formulae have even worse
effect The random sequences do not vary much with the seed, as source
file comments and whole discussion about old RNG bad effects shown. I.e.
for different time+PID
--
Rebuilding the temporary build tree
--
stage 1: bootstrap tools
--
stage 2: cleaning up the object tree
At Sun, 2 Feb 2003 13:28:33 +0200,
mike wrote:
try some of the following:
- fwcontorl -g 20
- sysctl hw.firewire.sbp.max_speed=0
- change SBP_QUEUE_LEN in sbp.c to 1 and rebuld module.
- sysctl machdep.cpu_idle_hlt=0
- sysctl debug.sbp_debug=1 and send me a dmesg.
with
On Sun, Feb 02, 2003 at 03:48:17 -0800, David Schultz wrote:
Specifically, rand() isn't very interesting in the lower-order
bits, and it spectacularly fails nearly all of Marsaglia's
It seems that you speak about old formulae, we use new one (which
intended to fix low-ordered bits), see our
On Sun, Feb 02, 2003 at 13:26:21 +0300, Andrey A. Chernov wrote:
Workaround I find so far is something like that
#define MASK 123459876
I found nothing better. Here is fix for 0 problem I plan to commit:
--- stdlib/rand.c.old Sat Jan 4 20:39:19 2003
+++ stdlib/rand.c Sun Feb 2
On Sun, 2 Feb 2003, Andrey A. Chernov wrote:
On Sun, Feb 02, 2003 at 13:26:21 +0300, Andrey A. Chernov wrote:
Workaround I find so far is something like that
#define MASK 123459876
I found nothing better. Here is fix for 0 problem I plan to commit:
I think it's worthwhile to wait till
On Sun, Feb 02, 2003 at 04:38:53 -0800, Doug Barton wrote:
I think it's worthwhile to wait till we get a chance to try arc4random().
This is libc's rand/random, it can't be fixed with arc4random() as
designed.
Also, have you run the code you're proposing through the tests in the post
that
On Sun, Feb 02, 2003 at 03:30:35PM +0300, Andrey A. Chernov wrote:
On Sun, Feb 02, 2003 at 13:26:21 +0300, Andrey A. Chernov wrote:
Workaround I find so far is something like that
#define MASK 123459876
I found nothing better. Here is fix for 0 problem I plan to commit:
---
On Mon, Feb 03, 2003 at 00:17:35 +1100, Tim Robbins wrote:
I believe that this change just moves the bad seed to 123459876; after
calling srand() with that seed, each call to rand() returns 0.
Yes. Nothing better is possible for this formulae and this is documented
in algorithm, some value
In message: [EMAIL PROTECTED]
Oliver Brandmueller [EMAIL PROTECTED] writes:
: Hi,
:
: I'm currently experimenting with 5-CURRENT on my Notebook an have a
: question regarding the concept of devd.
:
: With 4-STABLE I had pccardd running. Whenever a pccard was inserted I
: had pccardd
In message: [EMAIL PROTECTED]
Kevin Oberman [EMAIL PROTECTED] writes:
: Date: Sat, 1 Feb 2003 19:20:12 +0100
: From: Oliver Brandmueller [EMAIL PROTECTED]
: Sender: [EMAIL PROTECTED]
:
: Hi,
:
: I'm currently experimenting with 5-CURRENT on my Notebook an have a
: question
On Sun, Feb 02, 2003 at 16:42:25 +0300, Andrey A. Chernov wrote:
On Mon, Feb 03, 2003 at 00:17:35 +1100, Tim Robbins wrote:
I believe that this change just moves the bad seed to 123459876; after
calling srand() with that seed, each call to rand() returns 0.
Yes. Nothing better is
On Sun, Feb 02, 2003 at 17:02:23 +0300, Andrey A. Chernov wrote:
I'll produce and send it a bit later.
Here it is.
--- stdlib/rand.c.old Sat Jan 4 20:39:19 2003
+++ stdlib/rand.c Sun Feb 2 17:06:08 2003
@@ -72,10 +72,13 @@
*/
long hi, lo, x;
+ /* Can't be
Hi Warner.
On Sun, Feb 02, 2003 at 06:47:07AM -0700, M. Warner Losh wrote:
devd works for me when I have devices in my machine at boot. It does
run the start script for me. I just confirmed this on my machine. I
put my wi card in, booted and it picked up a dhcp address.
What script are
So far, this is final variant for 0 problem fixing ready for committing.
Any objections?
--- stdlib/rand.c.old Sat Jan 4 20:39:19 2003
+++ stdlib/rand.c Sun Feb 2 17:34:34 2003
@@ -72,10 +72,13 @@
*/
long hi, lo, x;
+ /* Can't be initialized with 0, so use another
David Schultz [EMAIL PROTECTED] writes:
[2] http://stat.fsu.edu/~geo/diehard.html (you need ports/lang/f2c)
There's a native C version on Marsaglia's random number CD:
http://stat.fsu.edu/pub/diehard/cdrom/die.c/
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to
I'm not sure if this is a result of the recent sched_ule import, but
buildkernel is dying on a bunch of undefined symbols (that from what
I can see, are definitely present in both sched_(4bsd|ule)). I fol-
llowed a discussion on -arch about being able to nominate the prefe-
Jeroen C. van Gelderen writes:
Wouldn't it be a good idea to change the name at the same time? Or
should it be retained for compatibility reasons with other BSDs?
Currently the name needlessly exposes implementation detail. Callers
expect good, cheap, non-blocking randomness but don't give
On Sun, Feb 02, 2003 at 15:32:32 +, Mark Murray wrote:
Jeroen C. van Gelderen writes:
Wouldn't it be a good idea to change the name at the same time? Or
should it be retained for compatibility reasons with other BSDs?
Currently the name needlessly exposes implementation detail.
On Sun, Feb 02, 2003 at 03:35:00PM +, Trent Nelson wrote:
I'm not sure if this is a result of the recent sched_ule import, but
buildkernel is dying on a bunch of undefined symbols (that from what
I can see, are definitely present in both sched_(4bsd|ule)). I fol-
llowed a
Hi,
You _must_ add SCHED_4BSD (old scheduler) or SCHED_ULE (new scheduler) to your
config file.
-- Aurelien
On Sun, Feb 02, 2003 at 03:35:00PM +, Trent Nelson wrote:
I'm not sure if this is a result of the recent sched_ule import, but
buildkernel is dying on a bunch of undefined
Okay, so it seems either 'options SCHED_4BSD/SCHED_ULE' needs to be
added to your kernel config file. Considering that this is a comp-
letely new line, would it not be wise to update UPDATING? I'm not
sure if /sbin/config has been modified to complain if one of either
isn't
On 02-Feb-2003 Taylor Dondich wrote:
After reading src/UPDATING and attempting to follow the directions to
upgrade from 4.7-RELEASE to -CURRENT, I'm having some difficulty, after
successfully building world and building and installing the kernel, I
attempted to make install in
On Fri, 31 Jan 2003, Pascal Giannakakis wrote:
Nicolao Renè schrieb:
Hi I've just upgraded to FreeBSD-Stable, the UPDATING file says that
many debugging options are enabled. But how do I remove them? thanks.
One way would be to compile your own kernel:
Hi.
Sorry for answering my own mail now.
On Sun, Feb 02, 2003 at 03:19:24PM +0100, Oliver Brandmueller wrote:
action /usr/local/etc/netconf/bin/netconf $device-name start;
David Wolfskill gave a good pointer, that devd starts before all
non-root disks are mounted. I'm just trying to
On Sun, Feb 02, 2003 at 03:54:08PM +, Trent Nelson wrote:
Okay, so it seems either 'options SCHED_4BSD/SCHED_ULE' needs to be
added to your kernel config file. Considering that this is a comp-
letely new line, would it not be wise to update UPDATING? I'm not
Have you looked
HI,
I had the same unresolved symbols and it baffled me for a while. After
cvsupping several times to an avail, I deleted the new kernel build.
i.e. I deleted my kernel file and its directory (the one created when
you do config kernel), copied generic to a new kernel file, added my
own configs,
On Sun, 2 Feb 2003, Oliver Brandmueller wrote:
Sorry for answering my own mail now.
On Sun, Feb 02, 2003 at 03:19:24PM +0100, Oliver Brandmueller wrote:
action /usr/local/etc/netconf/bin/netconf $device-name start;
David Wolfskill gave a good pointer, that devd starts before all
Hi.
On Sun, Feb 02, 2003 at 12:19:26PM -0500, Robert Watson wrote:
I'll keep you informed 'bout my findings.
I ran into a similar problem, actually -- programs like dhclient rely on
being able to write to lease and pid files. It's almost as though we'd
like an additional set of events
Andrey A. Chernov writes:
On Sun, Feb 02, 2003 at 04:38:53 -0800, Doug Barton wrote:
I think it's worthwhile to wait till we get a chance to try arc4random().
This is libc's rand/random, it can't be fixed with arc4random() as
designed.
Why not? Arc4 is a) deterministic and b) good for
Andrey A. Chernov writes:
On Mon, Feb 03, 2003 at 00:17:35 +1100, Tim Robbins wrote:
I believe that this change just moves the bad seed to 123459876; after
calling srand() with that seed, each call to rand() returns 0.
Yes. Nothing better is possible for this formulae and this is
Andrey A. Chernov writes:
Objections?
We can't, simple because sequence must be repeated for the same seed
across the calls.
RC4 is repeatable.
M
--
Mark Murray
iumop ap!sdn w,I idlaH
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the
We had a system running 4.3-RELEASE that I used the sysinstall upgrade
mechanism to upgrade to 5.0-RELEASE. I installed compat4x to use our
existing 4.x binaries.
Immediately after rebooting, I noticed most old 4.x binaries were
complaining about _stdoutp being an undefined symbol. However,
On Sun, Feb 02, 2003 at 11:41:32AM -0600, Kevin Day wrote:
lrwxr-xr-x 1 root wheel 9 Feb 1 00:18 libc.so - libc.so.5
lrwxr-xr-x 1 root wheel 16 Jul 5 2002 libc.so.3 - /usr/lib/libc.so
^
This is seriously messed up. See below.
Hi,
With a fresh -CURRENT tree, I got:
cc -fno-merge-constants -mcpu=pentiumpro -Werror -Wall -Wno-format-y2k -Wno-unin
itialized -c /usr/src/lib/libdisk/rules.c -o rules.o
cc1: warnings being treated as errors
/usr/src/lib/libdisk/rules.c: In function `Check_Chunk':
At 11:42 AM 2/2/2003, Jacques A. Vidrine wrote:
On Sun, Feb 02, 2003 at 11:41:32AM -0600, Kevin Day wrote:
lrwxr-xr-x 1 root wheel 9 Feb 1 00:18 libc.so - libc.so.5
lrwxr-xr-x 1 root wheel 16 Jul 5 2002 libc.so.3 - /usr/lib/libc.so
On Sun, Feb 02, 2003 at 11:53:22AM -0600, Kevin Day wrote:
Ok, I admit, no matter how it happened, an application using the wrong libc
is a bad thing.
But, how are things supposed to work?
Apps that need the old libc.so.4 will find it in
/usr/lib/compat/libc.so.4 (or /usr/lib/libc.so.4 if
On Sun, Feb 02, 2003 at 11:41:32AM -0600, Kevin Day wrote:
lrwxr-xr-x 1 root wheel 9 Feb 1 00:18 libc.so - libc.so.5
lrwxr-xr-x 1 root wheel 16 Jul 5 2002 libc.so.3 - /usr/lib/libc.so
Delete this.
-r--r--r-- 1 root wheel 571480 Aug 5 13:45 libc.so.4
Delete this.
-r--r--r-- 1 root wheel
At 11:54 AM 2/2/2003, Jacques A. Vidrine wrote:
Ok, I admit, no matter how it happened, an application using the wrong
libc
is a bad thing.
But, how are things supposed to work?
Apps that need the old libc.so.4 will find it in
/usr/lib/compat/libc.so.4 (or /usr/lib/libc.so.4 if you didn't
On Sun, Feb 02, 2003 at 17:30:48 +, Mark Murray wrote:
Why not? Arc4 is a) deterministic and b) good for all bits.
If you mean arc4random() function - not, because it use true randomness,
if you mean RC4 algorithm, probably yes, but we should compare its
distribution with our current
On Sun, Feb 02, 2003 at 17:34:19 +, Mark Murray wrote:
Andrey A. Chernov writes:
Objections?
We can't, simple because sequence must be repeated for the same seed
across the calls.
RC4 is repeatable.
It seems we mean different things saying arc4random(), see my answer in
the
On Sun, Feb 02, 2003 at 21:20:09 +0300, Andrey A. Chernov wrote:
On Sun, Feb 02, 2003 at 17:30:48 +, Mark Murray wrote:
Why not? Arc4 is a) deterministic and b) good for all bits.
If you mean arc4random() function - not, because it use true randomness,
if you mean RC4 algorithm,
In message: [EMAIL PROTECTED]
Robert Watson [EMAIL PROTECTED] writes:
: I ran into a similar problem, actually -- programs like dhclient rely on
: being able to write to lease and pid files. It's almost as though we'd
: like an additional set of events when the system is more booted.
In message [EMAIL PROTECTED], Andrey A. Chernov writes:
On Sun, Feb 02, 2003 at 17:30:48 +, Mark Murray wrote:
Why not? Arc4 is a) deterministic and b) good for all bits.
If you mean arc4random() function - not, because it use true randomness,
if you mean RC4 algorithm, probably yes, but
On Sun, Feb 02, 2003 at 19:32:50 +0100, [EMAIL PROTECTED] wrote:
Anyway, last time we discussed this, I think we stuck with the rand()
we had because we feared that people were using it's repeatable well
documented sequence of random numbers in regression testing.
As documented, it must be
Andrey A. Chernov writes:
On Sun, Feb 02, 2003 at 17:30:48 +, Mark Murray wrote:
Why not? Arc4 is a) deterministic and b) good for all bits.
If you mean arc4random() function - not, because it use true randomness,
if you mean RC4 algorithm, probably yes, but we should compare its
In message [EMAIL PROTECTED], Andrey A. Chernov writes:
On Sun, Feb 02, 2003 at 19:32:50 +0100, [EMAIL PROTECTED] wrote:
Anyway, last time we discussed this, I think we stuck with the rand()
we had because we feared that people were using it's repeatable well
documented sequence of random
In message [EMAIL PROTECTED], Mark Murray wr
ites:
We have most of this, and RC4 can deliver. RC4's licence is
fine. Call it ArCFour and there is no problem. The code is
small, fast and repeatable, and meets conditions 1-4 above.
There are some concerns about RC4's strength and predictability.
Good point. We can re-implement random() internally with arc4rand().
Objections?
Guys, please realize that random() is also used in generating
simulation inputs (or timing or whatever). If you go change
the underlying algorithm or its parameters one can't generate
the same sequence from the
On Sun, Feb 02, 2003 at 19:43:44 +0100, [EMAIL PROTECTED] wrote:
Please surf the mail-archives to find the discussion, it contained
a lot of good arguments from both sides, arguments which should
be thought about before changing rand().
I remember well that we decide to allow it be changed
On Sun, Feb 02, 2003 at 19:47:12 +0100, [EMAIL PROTECTED] wrote:
In message [EMAIL PROTECTED], Mark Murray wr
ites:
We have most of this, and RC4 can deliver. RC4's licence is
fine. Call it ArCFour and there is no problem. The code is
small, fast and repeatable, and meets conditions 1-4
After doing a make in /usr/src/sys/boot/, I get this error and compile ends:
In file included from /usr/src/sys/boot/ficl/loader.c:40:
/usr/src/sys/boot/ficl/../common/bootstrap.h:254: syntax error before
'struct'
/usr/src/sys/boot/ficl/../common/bootstrap.h:254: warning: data
definition has no
[EMAIL PROTECTED] writes:
In message [EMAIL PROTECTED], Mark Murray
wr
ites:
We have most of this, and RC4 can deliver. RC4's licence is
fine. Call it ArCFour and there is no problem. The code is
small, fast and repeatable, and meets conditions 1-4 above.
There are some concerns about
As I said, I don't know how big a concern this is. But last time
it was enough of a concern to make us keep rand() as it was.
[I know you are talking about rand() but Mark Murray's
earlier email about wanting to re-implement random() really
concerned me so I want to make sure my point gets
Bakul Shah writes:
Good point. We can re-implement random() internally with arc4rand().
Objections?
Guys, please realize that random() is also used in generating
simulation inputs (or timing or whatever). If you go change
the underlying algorithm or its parameters one can't generate
Consider the following patch. Since you have custom configuration, it
might rely on other parts of the system being active before they will
work. This patch moves devd from starting 'first' to starting before
we have to mount the 'critical' remote disks. If you require critical
remote disks to
Bakul Shah writes:
Not changing random() was of real concern to me when I was
doing chip simulations. ASIC design verification folks won't
be happy if the rug is pulled out from under them. In
general crypto and simulation needs are different and I don't
trust the crypto guys to look out
In message: [EMAIL PROTECTED]
Oliver Brandmueller [EMAIL PROTECTED] writes:
: fine. Any ideas?
Thanks for the info! I've sent in a different message that I think
will fix this problem. The problem is that /usr/local isn't mounted
when devd starts, so
On Sun, Feb 02, 2003 at 07:08:47PM +, Mark Murray wrote:
RC4 is _utterly_ repeatable, given a particular seed/key.
I presume it also produces reasonably uniform output for most
seeds too.
The old 16 bit rand() was broken enough that it didn't matter
much (read: _I_ don't care) if its
On Sunday 02 February 2003 6:48 pm, Bakul Shah wrote:
Guys, please realize that random() is also used in generating
simulation inputs (or timing or whatever). If you go change
the underlying algorithm or its parameters one can't generate
the same sequence from the same seed when repeating a
David Malone writes:
On Sun, Feb 02, 2003 at 07:08:47PM +, Mark Murray wrote:
RC4 is _utterly_ repeatable, given a particular seed/key.
I presume it also produces reasonably uniform output for most
seeds too.
Yes. Modulo the requirement to burn a bit of output after a
reseed.
The
RC4 is _utterly_ repeatable, given a particular seed/key.
May be but it is not the same as the current random(). Also,
I know you will want to change it the next time some one
points out a problem with RC4.
Yes. And it breaks, and we have a complainant.
So create a new function! Or use a
I presume it also produces reasonably uniform output for most
seeds too.
Yes. Modulo the requirement to burn a bit of output after a
reseed.
I guess the crypto guys would have junked it otherwise ;-)
I thought the complaint was about rand, not random?
Erm, yes. Similar difference
Maybe I missed something, but why cannot you just rip random() from libc,
rename it to bakul_shah_random() and use that in your testing code? Then you
are safe from any changes to random(), and indeed have a portable RNG if your
host OS changes.
Yes, *I* can do it but I don't work at every
On Sunday 02 February 2003 8:06 pm, Bakul Shah wrote:
Maybe I missed something, but why cannot you just rip random() from libc,
rename it to bakul_shah_random() and use that in your testing code? Then
you are safe from any changes to random(), and indeed have a portable RNG
if your host
Bakul Shah writes:
RC4 is _utterly_ repeatable, given a particular seed/key.
May be but it is not the same as the current random(). Also,
I know you will want to change it the next time some one
points out a problem with RC4.
Yes. This is called fixing bugs. We (OS maintainers) reserve
Bakul Shah writes:
Yes, *I* can do it but I don't work at every place they do
simulation! If in the extreme you are suggesting that a
portable application shouldn't rely on any OS features, you
are of course right but that kind of makes mockery of any
claims of compatibility. The point of
On Sun, Feb 02, 2003 at 20:05:29 +, David Malone wrote:
I presume it also produces reasonably uniform output for most
seeds too.
Yes. Modulo the requirement to burn a bit of output after a
reseed.
I guess the crypto guys would have junked it otherwise ;-)
Notice that it will
Taylor,
May I ask why you're running this command? Are you trying to upgrade
4.X to 5.0-R/C? If so, make sure that you've followed all the steps listed
in /usr/src/UPDATING.
If your problems persist, try doing a fresh cvsup, clear out /usr/obj/ and
retry the steps listed in UPDATING.
Regards,
a restriction on the OS. If FreeBSD makes random2() using RC4 to avoid
changing rand() or random(), will people then start relying on random2()'s
behaviour, and when someone finds a problem in RC4, then the next will be
random3()?
What I am suggesting is to leave random() as it is and
On Sun, Feb 02, 2003 at 12:39:50 -0800, Bakul Shah wrote:
Note that it is rand() that is broken, not random() as can be
seen by modifying Kris Kennaways' test so I don't see why
Mark Murray was talking about changing it in the first place.
About correlation bug: it is srand() which is
On Sun, Feb 02, 2003 at 12:06:56PM -0800, Bakul Shah wrote:
Maybe I missed something, but why cannot you just rip random() from libc,
rename it to bakul_shah_random() and use that in your testing code? Then you
are safe from any changes to random(), and indeed have a portable RNG if your
On Sun, Feb 02, 2003 at 11:55:25AM -0800, Bakul Shah wrote:
RC4 is _utterly_ repeatable, given a particular seed/key.
May be but it is not the same as the current random(). Also,
I know you will want to change it the next time some one
points out a problem with RC4.
Since you keep talking
Would you prefer that we defined random() as
int
random(void)
{
static int retval = 0;
return retval++;
}
No because that would be a change from the exisiting random()
behavior :-)
As I indicated in my earlier email random() is not broken,
srand() is (as corrected by
$ pciconf -l
chip0@pci0:0:0: class=0x06 card=0x chip=0x07351039 rev=0x01 hdr=0x00
pcib2@pci0:1:0: class=0x060400 card=0x chip=0x00011039 rev=0x00 hdr=0x01
isab0@pci0:2:0: class=0x060100 card=0x chip=0x00081039 rev=0x00 hdr=0x00
ohci0@pci0:2:2: class=0x0c0310
Since you keep talking about random(), I must conclude you're
knee-jerking, since we're not discussing that function. Please stay
on-topic :-)
Read through the thread. In particular see Mark's message
[EMAIL PROTECTED] where he
says
Good point. We can re-implement random() internally
Bakul Shah writes:
Note that it is rand() that is broken, not random() as can be
seen by modifying Kris Kennaways' test so I don't see why
Mark Murray was talking about changing it in the first place.
rand(3) says:
STANDARDS
The rand() and srand() functions conform to ISO/IEC 9899:1990
On Sun, Feb 02, 2003 at 12:57:45PM -0800, Bakul Shah wrote:
Since you keep talking about random(), I must conclude you're
knee-jerking, since we're not discussing that function. Please stay
on-topic :-)
Read through the thread. In particular see Mark's message
[EMAIL PROTECTED] where
On Sun, Feb 02, 2003 at 06:10:49PM +0300, Andrey A. Chernov wrote:
So far, this is final variant for 0 problem fixing ready for committing.
Any objections?
What tests have you run on this code to ensure it doesn't still have
strange problems?
Kris
msg51583/pgp0.pgp
Description: PGP
Has anyone gotten gbde working with vnode md devices (file-based)?
I'm trying to create a gbde-managed device from a file, and I keep on
getting various ioctl() failures. See attached log file.
Thanks,
--
Darryl Okahata
[EMAIL PROTECTED]
DISCLAIMER: this message is
Bakul Shah writes:
random(3) also provides an initstate() call which presumably
allows you to change the amount of randomnes. So here is
another suggestion: why not fold your algorithm change in
that function? For example,
initstate(seed, RC4, 3);
changes the algorithm to RC4.
On Sun, 2 Feb 2003, Andrey A. Chernov wrote:
So far, this is final variant for 0 problem fixing ready for committing.
Any objections?
Several people, including myself have asked for A) Enough discussion to
reach a consensus, and B) Thorough testing of the agreed upon solution.
You have allowed
On Sunday 02 February 2003 8:39 pm, Bakul Shah wrote:
What I am suggesting is to leave random() as it is and
guarantee its behavior won't change and add cryto_random() or
whatever, and indicate it *may* change.
Where was it indicated that random() wouldn't change?
Note that it is rand() that
In message [EMAIL PROTECTED], Darryl Okahata writes
:
su-2.05b# gbde init /dev/md0 -L /tmp/foo.lock
Don't use the -L and -l arguments unless you have to.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since
On Sun, 2 Feb 2003, Bakul Shah wrote:
Yes, *I* can do it but I don't work at every place they do
simulation!
Well the code is still going to be available in cvs. It's not like we're
going to magically make it disappear. :)
If in the extreme you are suggesting that a
portable application
Bakul Shah writes:
Since you keep talking about random(), I must conclude you're
knee-jerking, since we're not discussing that function. Please stay
on-topic :-)
Read through the thread. In particular see Mark's message
[EMAIL PROTECTED] where he
says
Good point. We can
[EMAIL PROTECTED] wrote:
su-2.05b# gbde init /dev/md0 -L /tmp/foo.lock
Don't use the -L and -l arguments unless you have to.
Thanks, but that was what I originally tried, and I still got the
gbde: ioctl(GEOMCONFIGGEOM): Invalid argument error. In other words,
I get the same error
Sorry, I'm being forgetful: I'm getting these errors under
5.0-RELEASE.
--
Darryl Okahata
[EMAIL PROTECTED]
DISCLAIMER: this message is the author's personal opinion and does not
constitute the support, opinion, or policy of Agilent Technologies, or
of the little green men
In message [EMAIL PROTECTED], Darryl Okahata writes
:
[EMAIL PROTECTED] wrote:
su-2.05b# gbde init /dev/md0 -L /tmp/foo.lock
Don't use the -L and -l arguments unless you have to.
Thanks, but that was what I originally tried, and I still got the
gbde: ioctl(GEOMCONFIGGEOM): Invalid
[EMAIL PROTECTED] wrote:
Can you please try this:
mdconfig -a -t malloc -s 4m -u 75
gbde init /dev/md75
gbde attach md75
Nope, exact same error.
--
Darryl Okahata
[EMAIL PROTECTED]
DISCLAIMER: this message is the author's personal opinion and does
In message [EMAIL PROTECTED], Darryl Okahata writes
:
[EMAIL PROTECTED] wrote:
Can you please try this:
mdconfig -a -t malloc -s 4m -u 75
gbde init /dev/md75
gbde attach md75
Nope, exact same error.
That is weird, it works like a charm here.
syv# mdconfig -a
1 - 100 of 150 matches
Mail list logo
