Not to jump down your throat, or anything, but you seem to be
perpetuating some incorrct assumptions about both effect and
proposed implementation details, and they must be stomped. 8-).
I was assuming that mandatory locking, in the context of this
discussion, does not mean automatic,
With the hacking I have been doing, looking at initial TCP sequence
numbers, I ran across the following:
/*
* Tcp initialization
*/
void
tcp_init()
{
int hashsize;
tcp_iss = random(); /* wrong, but better than a constant */
If you look at RFC793:
To avoid confusion we must
Hi folks,
I'm about to add a flag to mkfifo that allows you to specify creation
mode. NetBSD does this already.
However, there's a difference in the way our mkfifo and NetBSd's mkfifo
create files. We create with permissions 0777 modified by umask. NetBSD
creates with permissions 0666 modified
hi, there!
sorry for asking here, but got no replies on -questions
direct replies are not nessessary if you'll answer to -hackers
-- Forwarded message --
Date: Mon, 23 Aug 1999 17:54:32 +0700 (NSS)
From: Max Khon [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: dropped
On Thu, 26 Aug 1999, Max Khon wrote:
hi, there!
after upgrade to 3.2-STABLE from 2.2.8-STABLE we are experiencing problems
with closed telnet sessions. If a user drops connection (closes telnet
on his workstation without logging off) pdmenu, midnight commander and
other programs eat
ee does the same. The reason is that the program does not check for EOF
on stdin, it continuously loops. It's a bug in the program. The thing
that could have been changed is a signal from the shell that is no
longer sent or so.
The problem is the program, not the OS.
It might be wortwhile to
I'm working on getting linux/alpha compatability going in
FreeBSD/alpha I stumbled over some odd fork behaviour that I was
hoping somebody could shed some light on.
Specifically, when a linux/alpha process forks, the child's return
value is the parent's pid rather than zero. I tracked this
Hi everyone...
Back in June, at Usenix, Jordan and I talked about doing some more formalized
QA on FreeBSD releases. Unfortunately, this has yet to go really far, as I was
trying to complete some commitments, and have some infrastructure in place
before I started making this endeavor overly
I've posted 2 times asking for someone to review these diffs:
http://big.endian.org/~bright/freebsd/in_progress/vfs-fhsyscall.diff
Am I to take it that silence is accpetance? I'll be committing this
to -current tonight or tomorrow unless I get feedback.
See attached email for details.
thank
On Thu, 26 Aug 1999 08:28:29 GMT, Alfred Perlstein wrote:
Am I to take it that silence is accpetance? I'll be committing this
to -current tonight or tomorrow unless I get feedback.
Recent discussions with bde and eivind indicate that at least some of
the code you're about to touch has one
How would people feel about excluding procfs from the output of df?
--
Ben
UNIX Systems Engineer, Skunk Group
StarMedia Network, Inc.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Ben Rosengart wrote:
How would people feel about excluding procfs from the output of df?
df -t noprocfs
and voila no procfs in the output !
Cillian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
On Thu, 26 Aug 1999, Cillian Sharkey wrote:
df -t noprocfs
and voila no procfs in the output !
Well that works. Thanks.
(The man page seems to be in error, though, when it says that "sysctl
vfs" tells what kinds of filesystems are available.)
--
Ben
UNIX Systems Engineer, Skunk Group
Apparently, someone does love qsort.
Akira Wada wrote:
| I think it would be difficult, not impossible, to decide the threshold
| (Christopher Seiwald said, "# swaps = 1024", and Tim Vanderhoek suggested,
| "a ratio: #comparisons : # swaps") and to what point of qsort, to make
| isort bail
On Thu 1999-08-26 (12:15), Ben Rosengart wrote:
df -t noprocfs
and voila no procfs in the output !
Well that works. Thanks.
(The man page seems to be in error, though, when it says that "sysctl
vfs" tells what kinds of filesystems are available.)
lsvfs should give a good
On Thu, 26 Aug 1999, Neil Blakey-Milner wrote:
On Thu 1999-08-26 (12:15), Ben Rosengart wrote:
(The man page seems to be in error, though, when it says that "sysctl
vfs" tells what kinds of filesystems are available.)
lsvfs should give a good indication.
Should I submit a patch to
On Thu 1999-08-26 (12:33), Ben Rosengart wrote:
On Thu, 26 Aug 1999, Neil Blakey-Milner wrote:
On Thu 1999-08-26 (12:15), Ben Rosengart wrote:
(The man page seems to be in error, though, when it says that "sysctl
vfs" tells what kinds of filesystems are available.)
lsvfs
On Thu, 26 Aug 1999 18:21:43 +0200, Neil Blakey-Milner wrote:
(The man page seems to be in error, though, when it says that "sysctl
vfs" tells what kinds of filesystems are available.)
lsvfs should give a good indication.
My dog! You learn something new every day. :-)
Thanks,
Sheldon.
On Thu, 26 Aug 1999, Sheldon Hearn wrote:
Also, I'd suggest that it's a bad idea to say "if I get no feedback
before tonight, I'm committing". I think this applies even if it's not
the first time you've asked for review. Basically, timezones and stuff
make for a situation where such an
Just a few comments...
2) The casting of VFS ops to eopnotsupp() has been removed and
vfs_nop*() functions have been put into kern/vfs_default.c
This makes it more clear that certain VFS-ops are giving default
behavior, either returning automatic success or returning EOPNOTSUPP.
On Thu, 26 Aug 1999 11:45:47 -0400, Bill Fumerola wrote:
This would be post #3 of the same code and changes that no-one has
reponded to.
I hear you, and I was aware of that when I made my comments. Basically,
it's a waste of time saying such a thing, so either be prepared to wait
longer, or
:I've posted 2 times asking for someone to review these diffs:
:
:http://big.endian.org/~bright/freebsd/in_progress/vfs-fhsyscall.diff
:
:Am I to take it that silence is accpetance? I'll be committing this
:to -current tonight or tomorrow unless I get feedback.
:
:See attached email for details.
On Thu, 26 Aug 1999, Dmitrij Tejblum wrote:
Just a few comments...
2) The casting of VFS ops to eopnotsupp() has been removed and
vfs_nop*() functions have been put into kern/vfs_default.c
This makes it more clear that certain VFS-ops are giving default
behavior, either
Therefore, I'm asking people to put their minds to work, and talk
about valid tests that we could run to catch things that might slip
through the cracks. I'm hoping that some of the long-timers can point
out areas that have been missed before, and others to point out areas
where they have
On Thu, 26 Aug 1999, Matthew Dillon wrote:
:I've posted 2 times asking for someone to review these diffs:
:
:http://big.endian.org/~bright/freebsd/in_progress/vfs-fhsyscall.diff
:
:Am I to take it that silence is accpetance? I'll be committing this
:to -current tonight or tomorrow unless
I have at least one filesystem killer test.
And it is?... Like I mentioned, we're trying to collect tests/code that will
demonstrate bugs.
I'll try and figure out a good place to hang it in the source tree, but I
believe that it's usage is a mandatory "must use" for validating FFS
and VM
I have a filesystem stress tests that are worth incorporating. I also have
a raw disk pattern checker, but that's less of a test than analysis tool.
-matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
I have a filesystem stress tests that are worth incorporating. I also have
a raw disk pattern checker, but that's less of a test than analysis tool.
- -matt
Great. Bundle something up and send it along, and I'll take a look.
-Brian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with
However, dt suggested I make VFS_CHECKEXP a VOP instead of VFS, my only
gripe is that exportability is determined by the filesystem, _then_ the
vnode, making it more of a VFS op imo.
I think dt is right here; the issue is that the operation is performed
on a vnode, not on a filesystem, and
:
: I've done a quick once-over of your patch. From the point of view of
: the work I'm doing and the work Kirk will be doing later on, I do
: not think the patch will cause any problems since you are adding new
: VOPs for the most part rather then modifying (too many) existing
This was just posted to BUGTRAQ, are the FreeBSD developers aware of this yet?
-Emil
--
Reverse engineering, the most fun and usually the most effective way
to tackle a problem or learn something new.
Public PGP key: http://www.ecad.org/crypt0genic_pgp_key
Website:
Therefore, I'm asking people to put their minds to work, and talk
about valid tests that we could run to catch things that might slip
through the cracks. I'm hoping that some of the long-timers can point
out areas that have been missed before, and others to point out areas
where they have
On Thu, Aug 26, 1999 at 10:41:58AM -0700, Matthew Jacob wrote:
I have a filesystem stress tests that are worth incorporating. I also have
a raw disk pattern checker, but that's less of a test than analysis tool.
Does it check do things that should fail aswell as things that
should work? One
I have at least one filesystem killer test.
And it is?... Like I mentioned, we're trying to collect tests/code that will
demonstrate bugs.
I'll try and figure out a good place to hang it in the source tree, but I
believe that it's usage is a mandatory "must use" for validating FFS
Mmmm... No. _I_ (read: Not Cisco as a whole) am looking for tests that will
help locate bugs pre-release copies of the OS so that there is still time for
others to debug the code before Jordan cuts the release. Its more of a
"lets help the project by coordinating testing" thing
A
works as advertised for me...
quickest fix would be to make the core-dump routines not follow symlinks.
On Thu, 26 Aug 1999, crypt0genic wrote:
This was just posted to BUGTRAQ, are the FreeBSD developers aware of this yet?
-Emil
--
Reverse engineering, the most fun and usually the
PROBLEM:
Find core dumps with extreme long path names. See also
kern/12855
CAUSE:
fts.c does not handle realloc of buffer space correctly.
FIX:
Upgrade fts.c from OpenBSD version 1.9 to 1.20. The
fix for when fts_open is used with option FTS_NOCHDIR
the full path entry of type FTS_DP is
: Still too small a scope. How about "A regression test to make sure
: that the OS is not broken before Jordan inflicts it on the world" ?
:
:Athough it does not actively hunt down bugs, a NFS mounted,
:FreeBSD-routed build should stress enough of the system to disprove many
:serious problems.
:
(Since this will be one of my first commits, I'd like to pass it by
as many people as possible.)
This patch makes "vnconfig" like "ccdconfig" where you don't have
to specify "/dev/xxx": it will add "/dev/" for you. Same goes
for the "vntab" file.
Also includes "-Wall" cleanup.
[I already
The kernel (a hacked 3.2-RELEASE) dumps core (courtesy a panic),
and upon a subsequent boot, the following happens:
# cd /usr/src/sys/compile/FOOKERNEL
# gdb -k
GNU gdb 4.18
...
(kgdb) symbol-file kernel.debug
Reading symbols from kernel.debug...done.
(kgdb) exec-file
According to Sheldon Hearn:
I can't see why we use 0777. Would bad things happened if I changed this
to 0666 while I'm in there?
I don't think so. I don't see any need of allowing FIFO to be executable...
I'd say, go for it.
--
Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL
As Brian McGovern wrote ...
Mmmm... No. _I_ (read: Not Cisco as a whole) am looking for tests that will
help locate bugs pre-release copies of the OS so that there is still time for
others to debug the code before Jordan cuts the release. Its more of a
"lets help the project by
I was assuming that mandatory locking, in the context of this
discussion, does not mean automatic, forced exclusion on open, but
rather explicit locks, applied by calls similar to those used for
advisory locking, that are enforced by the kernel.
It's not mandatory, if it's not implicit. You
In message [EMAIL PROTECTED] Julian
Elischer writes:
: quickest fix would be to make the core-dump routines not follow symlinks.
An even quicker fix would be to disable coredumps in periodic, since
no reboot would be required. :-)
As has been noted in -security, the kernel fix has been
In message [EMAIL PROTECTED] Peter Holm writes:
: The patch is available at http://www.freebsd.org/~pho/fts.diff
You might want to work with Bruce Evens who has patches as well..
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the
Is there a way to make a web server (or any freebsd host for that matter)
negotiate a window of a specific size? Bandwidth management works better
with smaller windows...it would be interesting to be able to tum a server
(perhaps dynamically)
Dennis
To Unsubscribe: send mail to [EMAIL
- Forwarded message from Alexey Zelkin [EMAIL PROTECTED] -
Date: Thu, 26 Aug 1999 23:03:07 +0400
From: Alexey Zelkin [EMAIL PROTECTED]
To: Anders Andersson [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: ndc(8)
Message-ID: [EMAIL PROTECTED]
X-Mailer: Mutt 0.95.7i
hi,
On Thu, Aug
'stats Causes named to dump its statistics to /etc/namedb/named.stats'
This also applies for /var/tmp/named_dump.db, that one goes also in
/etc/namedb.
Guys, before we fix the manpage on this, could someone please follow
this up with -hackers? I was under the impression (but
On Fri, 27 Aug 1999, Anders Andersson wrote:
- Forwarded message from Nik Clayton [EMAIL PROTECTED] -
Date: Thu, 26 Aug 1999 21:20:16 +0100
From: Nik Clayton [EMAIL PROTECTED]
To: Anders Andersson [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: ndc(8)
Message-ID: [EMAIL
Looks good!
-Matt
Matthew Dillon
[EMAIL PROTECTED]
:(Since this will be one of my first commits, I'd like to pass it by
:as many people as possible.)
:
:
:This patch
On Thu, 26 Aug 1999, Brian McGovern wrote:
However, I'm now at the point where I'd like to start collecting materials to
do this. By "materials", I mean both test scenarios and code for performing
these tests.
I suggest going over all of the various stress-test scripts/code which
have been
On Thu, Aug 26, 1999 at 10:40:29AM -0400, Andrew Gallatin wrote:
[...]
Specifically, when a linux/alpha process forks, the child's return
value is the parent's pid rather than zero.
[...]
If I run the following code on FreeBSD/i386, I see:
parent's pid = 6730
I am the child, result = 0
I
Mark J. Taylor wrote:
+ dev = malloc(strlen(vnp-dev)+6);
+ (void)sprintf(dev, "/dev/%s", vnp-dev);
You should be checking that malloc() doesn't return NULL, before trying
to write into the allocated space.
--
Ben Smithurst| PGP: 0x99392F7D
[EMAIL
However, I'm now at the point where I'd like to start collecting materials to
do this. By "materials", I mean both test scenarios and code for performing
these tests.
While I now have your mind spinning, I'd like to lay down some
limits. Firstly, my current resources for testing is
ee does the same. The reason is that the program does not check for EOF
on stdin, it continuously loops. It's a bug in the program. The thing
that could have been changed is a signal from the shell that is no
longer sent or so.
The problem is the program, not the OS.
It might be
I'm working on getting linux/alpha compatability going in
FreeBSD/alpha I stumbled over some odd fork behaviour that I was
hoping somebody could shed some light on.
Specifically, when a linux/alpha process forks, the child's return
value is the parent's pid rather than zero. I tracked
I'm trying to build a stripped down version of FreeBSD and have run
across a few oddities in the startup scripts.
1. Should commands be wrapped in a check for their existance? For
example: swapon, adjkerntz, etc.
2. Should everything be wrapped in a "rc.conf" variable? For example,
the
On Fri, 27 Aug 1999 02:20:52 + (GMT)
Terry Lambert [EMAIL PROTECTED] wrote:
This is a bug.
...but it's a bug in fork(), too. Not just vfork().
For other bugs in vfork(), look at the fact that the vacation
program does not correctly deal with messages.
...fwiw, NetBSD fixed the
Lately i have seen a lot of speculation as to what will happen when the
Intel Merced comes out. Will people wait 12-18 months for a 64 bit
Windows (that's the amount of time I keep hearing it will take them to get
Win2000 running on it) or will they just buy it and pop Linux onto it
right away?
"Stephen J. Roznowski" wrote:
I'm trying to build a stripped down version of FreeBSD and have run
across a few oddities in the startup scripts.
Ok, first thing is, if you are going to hack up some custom stuff you're
pretty much in the driver's seat on issues like this. That's not to
4. What is the point of the "stty status '^T' at the top of the rc file?
Frankly, that one stumps me too. :) There are still plenty of "We've
always done it that way" items in the various rc files, that may be one of
them.
Without this, you cannot press ^T to see why the rc
The WaveLan card suddenly comes to mind...
Are the ethernet drivers time dependent? If I take a ethernet card
[ed(4)] and change the crystal for something slower, assuming I can
still get the card to work correctly (albiet slower) will it still
interact properly with the ed(4) driver, or do I
This has been fixed with the following commit:
luoqi 1999/05/24 12:31:19 PDT
Modified files:(Branch: RELENG_3)
gnu/usr.bin/binutils/gdb/i386 freebsd-nat.c kvm-fbsd.c
Log:
Back out changes don't belong to the 3.x branch.
Revision ChangesPath
1.21.2.2 +3 -1
Greetings,
As previously discussed, here is a first draft of the rc* script mods. I
consider the first step in this process to be Jordan's cleanup of the
variable syntax. This is step 2, which most notably converts test's dealing
with variables to case wherever possible. It also does the
Tonight while testing my rc file changes I decided to interrupt the splash
screen display I have to see the boot messages. I hit scroll lock to do
this, and it killed the splash screen, but when I went to log in the
keyboard on the console was pretty much fubar. Every key was mapped to a
On Thu, Aug 26, 1999, Doug wrote:
Greetings,
As previously discussed, here is a first draft of the rc* script mods. I
consider the first step in this process to be Jordan's cleanup of the
variable syntax. This is step 2, which most notably converts test's dealing
with variables to
Chris Costello wrote:
On Thu, Aug 26, 1999, Doug wrote:
Greetings,
As previously discussed, here is a first draft of the rc* script mods. I
consider the first step in this process to be Jordan's cleanup of the
variable syntax. This is step 2, which most notably converts test's
Not to jump down your throat, or anything, but you seem to be
perpetuating some incorrct assumptions about both effect and
proposed implementation details, and they must be stomped. 8-).
I was assuming that mandatory locking, in the context of this
discussion, does not mean automatic, forced
With the hacking I have been doing, looking at initial TCP sequence
numbers, I ran across the following:
/*
* Tcp initialization
*/
void
tcp_init()
{
int hashsize;
tcp_iss = random(); /* wrong, but better than a constant */
If you look at RFC793:
To avoid confusion we must prevent
Hi folks,
I'm about to add a flag to mkfifo that allows you to specify creation
mode. NetBSD does this already.
However, there's a difference in the way our mkfifo and NetBSd's mkfifo
create files. We create with permissions 0777 modified by umask. NetBSD
creates with permissions 0666 modified
hi, there!
sorry for asking here, but got no replies on -questions
direct replies are not nessessary if you'll answer to -hackers
-- Forwarded message --
Date: Mon, 23 Aug 1999 17:54:32 +0700 (NSS)
From: Max Khon f...@iclub.nsu.ru
To: questi...@freebsd.org
Subject: dropped
On Thu, 26 Aug 1999, Max Khon wrote:
hi, there!
after upgrade to 3.2-STABLE from 2.2.8-STABLE we are experiencing problems
with closed telnet sessions. If a user drops connection (closes telnet
on his workstation without logging off) pdmenu, midnight commander and
other programs eat up
ee does the same. The reason is that the program does not check for EOF
on stdin, it continuously loops. It's a bug in the program. The thing
that could have been changed is a signal from the shell that is no
longer sent or so.
The problem is the program, not the OS.
It might be wortwhile to
I'm working on getting linux/alpha compatability going in
FreeBSD/alpha I stumbled over some odd fork behaviour that I was
hoping somebody could shed some light on.
Specifically, when a linux/alpha process forks, the child's return
value is the parent's pid rather than zero. I tracked this
Hi everyone...
Back in June, at Usenix, Jordan and I talked about doing some more formalized
QA on FreeBSD releases. Unfortunately, this has yet to go really far, as I was
trying to complete some commitments, and have some infrastructure in place
before I started making this endeavor overly
I've posted 2 times asking for someone to review these diffs:
http://big.endian.org/~bright/freebsd/in_progress/vfs-fhsyscall.diff
Am I to take it that silence is accpetance? I'll be committing this
to -current tonight or tomorrow unless I get feedback.
See attached email for details.
thank
On Thu, 26 Aug 1999 08:28:29 GMT, Alfred Perlstein wrote:
Am I to take it that silence is accpetance? I'll be committing this
to -current tonight or tomorrow unless I get feedback.
Recent discussions with bde and eivind indicate that at least some of
the code you're about to touch has one
How would people feel about excluding procfs from the output of df?
--
Ben
UNIX Systems Engineer, Skunk Group
StarMedia Network, Inc.
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Ben Rosengart wrote:
How would people feel about excluding procfs from the output of df?
df -t noprocfs
and voila no procfs in the output !
Cillian
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
On Thu, 26 Aug 1999, Cillian Sharkey wrote:
df -t noprocfs
and voila no procfs in the output !
Well that works. Thanks.
(The man page seems to be in error, though, when it says that sysctl
vfs tells what kinds of filesystems are available.)
--
Ben
UNIX Systems Engineer, Skunk Group
Apparently, someone does love qsort.
Akira Wada wrote:
| I think it would be difficult, not impossible, to decide the threshold
| (Christopher Seiwald said, # swaps = 1024, and Tim Vanderhoek suggested,
| a ratio: #comparisons : # swaps) and to what point of qsort, to make
| isort bail back,
On Thu 1999-08-26 (12:15), Ben Rosengart wrote:
df -t noprocfs
and voila no procfs in the output !
Well that works. Thanks.
(The man page seems to be in error, though, when it says that sysctl
vfs tells what kinds of filesystems are available.)
lsvfs should give a good indication.
On Thu, 26 Aug 1999, Neil Blakey-Milner wrote:
On Thu 1999-08-26 (12:15), Ben Rosengart wrote:
(The man page seems to be in error, though, when it says that sysctl
vfs tells what kinds of filesystems are available.)
lsvfs should give a good indication.
Should I submit a patch to the
On Thu 1999-08-26 (12:33), Ben Rosengart wrote:
On Thu, 26 Aug 1999, Neil Blakey-Milner wrote:
On Thu 1999-08-26 (12:15), Ben Rosengart wrote:
(The man page seems to be in error, though, when it says that sysctl
vfs tells what kinds of filesystems are available.)
lsvfs should
On Thu, 26 Aug 1999 18:21:43 +0200, Neil Blakey-Milner wrote:
(The man page seems to be in error, though, when it says that sysctl
vfs tells what kinds of filesystems are available.)
lsvfs should give a good indication.
My dog! You learn something new every day. :-)
Thanks,
Sheldon.
On Thu, 26 Aug 1999, Sheldon Hearn wrote:
Also, I'd suggest that it's a bad idea to say if I get no feedback
before tonight, I'm committing. I think this applies even if it's not
the first time you've asked for review. Basically, timezones and stuff
make for a situation where such an e-mail
Just a few comments...
2) The casting of VFS ops to eopnotsupp() has been removed and
vfs_nop*() functions have been put into kern/vfs_default.c
This makes it more clear that certain VFS-ops are giving default
behavior, either returning automatic success or returning EOPNOTSUPP.
On Thu, 26 Aug 1999 11:45:47 -0400, Bill Fumerola wrote:
This would be post #3 of the same code and changes that no-one has
reponded to.
I hear you, and I was aware of that when I made my comments. Basically,
it's a waste of time saying such a thing, so either be prepared to wait
longer, or
:I've posted 2 times asking for someone to review these diffs:
:
:http://big.endian.org/~bright/freebsd/in_progress/vfs-fhsyscall.diff
:
:Am I to take it that silence is accpetance? I'll be committing this
:to -current tonight or tomorrow unless I get feedback.
:
:See attached email for details.
On Thu, 26 Aug 1999, Dmitrij Tejblum wrote:
Just a few comments...
2) The casting of VFS ops to eopnotsupp() has been removed and
vfs_nop*() functions have been put into kern/vfs_default.c
This makes it more clear that certain VFS-ops are giving default
behavior, either
Therefore, I'm asking people to put their minds to work, and talk
about valid tests that we could run to catch things that might slip
through the cracks. I'm hoping that some of the long-timers can point
out areas that have been missed before, and others to point out areas
where they have
On Thu, 26 Aug 1999, Matthew Dillon wrote:
:I've posted 2 times asking for someone to review these diffs:
:
:http://big.endian.org/~bright/freebsd/in_progress/vfs-fhsyscall.diff
:
:Am I to take it that silence is accpetance? I'll be committing this
:to -current tonight or tomorrow unless
I have at least one filesystem killer test.
And it is?... Like I mentioned, we're trying to collect tests/code that will
demonstrate bugs.
I'll try and figure out a good place to hang it in the source tree, but I
believe that it's usage is a mandatory must use for validating FFS
and VM code.
I have a filesystem stress tests that are worth incorporating. I also have
a raw disk pattern checker, but that's less of a test than analysis tool.
-matt
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
I have a filesystem stress tests that are worth incorporating. I also have
a raw disk pattern checker, but that's less of a test than analysis tool.
- -matt
Great. Bundle something up and send it along, and I'll take a look.
-Brian
To Unsubscribe: send mail to majord...@freebsd.org
However, dt suggested I make VFS_CHECKEXP a VOP instead of VFS, my only
gripe is that exportability is determined by the filesystem, _then_ the
vnode, making it more of a VFS op imo.
I think dt is right here; the issue is that the operation is performed
on a vnode, not on a filesystem, and
:
: I've done a quick once-over of your patch. From the point of view of
: the work I'm doing and the work Kirk will be doing later on, I do
: not think the patch will cause any problems since you are adding new
: VOPs for the most part rather then modifying (too many) existing
This was just posted to BUGTRAQ, are the FreeBSD developers aware of this yet?
-Emil
--
Reverse engineering, the most fun and usually the most effective way
to tackle a problem or learn something new.
Public PGP key: http://www.ecad.org/crypt0genic_pgp_key
Website:
Therefore, I'm asking people to put their minds to work, and talk
about valid tests that we could run to catch things that might slip
through the cracks. I'm hoping that some of the long-timers can point
out areas that have been missed before, and others to point out areas
where they have
On Thu, Aug 26, 1999 at 10:41:58AM -0700, Matthew Jacob wrote:
I have a filesystem stress tests that are worth incorporating. I also have
a raw disk pattern checker, but that's less of a test than analysis tool.
Does it check do things that should fail aswell as things that
should work? One
1 - 100 of 136 matches
Mail list logo
