On Mon, 7 May 2001 10:18:38 -0700
[EMAIL PROTECTED] wrote:
Lets try another realistic example:
cp -uvp ab* cde*.f* g? h/*.i? j/kl /m
What's the find | cpio invocation for that? When you come up with it, it
echo ab* cde*.f* g? h/*.i? j/kl /m | cpio ...
Messy -
There's a strange interaction between su, pam znd zsh.
If you su to an account that has zsh as its shell and then hit ctrl-c it
will kill the shell that you invoked su from.
If you recompile su with -DNOPAM then the problems go away and this doesn't
seem to happen with any other shells either.
On Wed, 09 May 2001 19:20:07 +0900,
Seigo Tanimura tanimura said:
Seigo That does not, however, necessarily imply that we can scan file
Seigo descriptors with holding a process lock. Another process can release a
Seigo reference to a file descriptor via closef() during polling the
Seigo
On Tue, 08 May 2001 08:21:55 -0700 (PDT),
John Baldwin [EMAIL PROTECTED] said:
John On 08-May-01 Seigo Tanimura wrote:
Here is another issue. PROC_LOCK may block to acquire a process lock,
during which an event of interest may occur or the remaining time of
select(2)/poll(2) may run out.
On 09-May-01 Robert Watson wrote:
On Tue, 8 May 2001, John Baldwin wrote:
That's easy enough. Well, it used to be at least. You can use 'ps' to
find the address of the struct proc (first pointer in the display) and
then do 'call psignal(addr, 9)' to send SIGKILL to the process. Then
On 09-May-01 Seigo Tanimura wrote:
On Tue, 08 May 2001 08:21:55 -0700 (PDT),
John Baldwin [EMAIL PROTECTED] said:
John On 08-May-01 Seigo Tanimura wrote:
Here is another issue. PROC_LOCK may block to acquire a process lock,
during which an event of interest may occur or the remaining
On 3 Mai, An: [EMAIL PROTECTED] wrote:
Hi,
/sys from cvsup around 2pm CEST from cvsup3.de.freebsd.org (contains
npx.c fix).
CVSUP from May 7, ~1pm CEST.
I made some progress. As you see in my last message I have parts of the
kernel loaded as modules. The mfs module was responsible for the
On Wed, 9 May 2001, John Baldwin wrote:
I am more worried about the fact that you can deadlock the debugger.
What does the debugger do if another process hold the proc lock on the
process you want to kill? Cute, eh? The debugger is an extra special
environment. Most of the time you've
There are several issues here:
* The process's descriptor table
* The struct file's referenced by that descriptor table
* The object underlying a struct file.
A process's descriptor table is not protected by the proc lock, because
the descriptor table can be shared
On Tue, 8 May 2001 23:31:51 -0400 (EDT), Robert Watson [EMAIL PROTECTED] said:
I followed everything here fine until you asserted that the debugger
shouldn't need any locks.
When the debugger is running, everything else should have been
forcibly halted.
-GAWollman
To Unsubscribe: send mail
[ -stable dropped from cc list ]
John Baldwin [EMAIL PROTECTED] writes:
On 09-May-01 Robert Watson wrote:
On Tue, 8 May 2001, John Baldwin wrote:
That's easy enough. Well, it used to be at least. You can use 'ps' to
find the address of the struct proc (first pointer in the
On Wed, 9 May 2001 13:33:54 -0700 (PDT),
Matt Dillon [EMAIL PROTECTED] said:
Matt * The process's descriptor table
Matt * The struct file's referenced by that descriptor table
Those are in my TODO list, and I have already started working on them.
--
Seigo Tanimura [EMAIL PROTECTED]
On Wed, 09 May 2001 09:21:09 -0700 (PDT),
John Baldwin [EMAIL PROTECTED] said:
Now the problem is whether it is easy or difficult to free a file
descriptor with holding a process lock. At the level of the file
descriptor layer, we can convert the memory allocator of a file
descriptor from
cvsup'd 5-9-2001 around 0600 PST
You must be tired of hearing about things that are broken, so
I thought I'd let you know things went well.
Running i686 (single), ide/dma66 x two disks, no isa cards, no scsi,
two ethernet cards, softupdates, devfs. A very basic box.
And ssh 2.9 seems OK as
For anyone who writes their own FORTH in the loader scripts:
ficl 2.05 (imported on 28th April by dcs) changes `base' from an
lvalue to an rvalue. This will break any code that currently
uses base. In particular, code to temporarily change the base
will corrupt low memory. For example:
Peter Jeremy wrote:
For anyone who writes their own FORTH in the loader scripts:
ficl 2.05 (imported on 28th April by dcs) changes `base' from an
lvalue to an rvalue. This will break any code that currently
uses base. In particular, code to temporarily change the base
will corrupt low
Salvo Bartolotta wrote:
[ resending, with a subject ]
OK, I;ve looked and looked and can't seem to figure out how to set
hw.ata.wc to enabled. I've put and a few other things in
/etc/sysctl.conf, the others get set, hw.ata.wc doesn't. You can't
change it by hand either as sysctl tells
Daniel C. Sobral wrote:
I have no idea why this change was made - it breaks FORTH compatibility.
I can't find anything in ficl.sourceforge.net (except that someone has
helpfully stripped all the CR's off ficl205.tar before it was gzip'd -
which upsets tar quite a bit).
John Sadler is
18 matches
Mail list logo
