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 c
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 t
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
d
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 f
On Fri, 27 Aug 1999, Chris Costello wrote:
> On Thu, Aug 26, 1999, Doug wrote:
> > > > 2. value ) instead of value) for case statements
> > >
> > >Why? What's wrong with `value)'?
> >
> > Nothing functionally, but I find case statements much easier to read with
> > the extra whitespace.
>
On Thu, Aug 26, 1999, Doug wrote:
> > > 2. value ) instead of value) for case statements
> >
> >Why? What's wrong with `value)'?
>
> Nothing functionally, but I find case statements much easier to read with
> the extra whitespace.
Would that not cause problems?
[A-Z]* )
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 s
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 conve
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
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
d
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
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 need
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
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 nee
> > 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
"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 t
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? I
> > 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
"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
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?
On Fri, 27 Aug 1999 02:20:52 + (GMT)
Terry Lambert 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 vacation(1) bug an
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 sect
> 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 track
> 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 w
> 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 re
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
b...@scie
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 th
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 sec
> 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 trac
> 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
> 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 r
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 P
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
>
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
Looks good!
-Matt
Matthew Dillon
:(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 "
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
>
On Fri, 27 Aug 1999, Anders Andersson wrote:
> - Forwarded message from Nik Clayton -
>
> Date: Thu, 26 Aug 1999 21:20:16 +0100
> From: Nik Clayton
> To: Anders Andersson
> Cc: freebsd-...@freebsd.org
> Subject: Re: ndc(8)
> Message-ID: <19990826212016.d86...@catkin.nothing-going-on.or
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
> > '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
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 mak
- Forwarded message from Alexey Zelkin -
Date: Thu, 26 Aug 1999 23:03:07 +0400
From: Alexey Zelkin
To: Anders Andersson
Cc: freebsd-...@freebsd.org
Subject: Re: ndc(8)
Message-ID: <19990826230307.a1...@scorpion.crimea.ua>
X-Mailer: Mutt 0.95.7i
hi,
On Thu, Aug 26, 1999 at 01:56:50PM +
- Forwarded message from Nik Clayton -
Date: Thu, 26 Aug 1999 21:20:16 +0100
From: Nik Clayton
To: Anders Andersson
Cc: freebsd-...@freebsd.org
Subject: Re: ndc(8)
Message-ID: <19990826212016.d86...@catkin.nothing-going-on.org>
X-Mailer: Mutt 0.95.4i
Organization: FreeBSD Project http:/
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 majord...@freebsd
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-I
In message <37c5a7d5.9a7f4...@freebsd.org> 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 majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the bo
In message
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 committed.
Warner
To Un
In message <19990826184654.a...@ecad.org> crypt0genic writes:
: This was just posted to BUGTRAQ, are the FreeBSD developers aware of this yet?
Yes. We are and have been working to correct the problem. In fact,
there is a kernel patch that has been committed. A quick and dirty
workaround has bee
> > '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 impressio
> 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. Y
- 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
- 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 PROTECTED]>
X-Mailer: Mutt 0.95.4i
Organization: Fr
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 proj
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 PROTECTED
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! -=- robe...@kel
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 messa
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 commit
In message <[EMAIL PROTECTED]> crypt0genic writes:
: This was just posted to BUGTRAQ, are the FreeBSD developers aware of this yet?
Yes. We are and have been working to correct the problem. In fact,
there is a kernel patch that has been committed. A quick and dirty
workaround has been posted t
> 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.
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 b
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 PRO
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 /var/crash
(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 know
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 /var/cras
(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 kno
:> 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.
:
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 retur
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 usuall
> 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.
Inflict
>> 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
>
>
> 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 regr
this is Playerbigdaddy,
I forgot the password to my old e-mail address and i can't get in.
Can you help me even reply and let me know how to do it so i can try or get in
for me and reply to me and let me know what the password is .
playerb
> >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
> 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
>
:> 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.
:
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
>> 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
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:http:/
:>
:> 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) existi
>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, a
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 retu
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 usual
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 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 c
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 un
> 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.
Inflic
> 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, 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
> >behavi
: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.
:
>> 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
>
> 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 reg
this is Playerbigdaddy,
I
forgot the password to my old e-mail address and i can't get in. Can you help
me even reply and let me know how to do it so i can try or get in for
me and reply to me and let me know what the password is .
[E
> >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 validatin
> 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
>
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? On
>> 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 the
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:http:
:>
:> 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) exist
>
> 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,
>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]
wit
1 - 100 of 147 matches
Mail list logo
