> > Uh, well, "foolproof" != "calling ps and awk and grep and looking for
> > processes". For ANY definition of foolproof.
> >
> > And it is certainly foolproof from the point of view that there's no way
> > in hell for the session not to be terminated, unlike some ps garbage I've
> > seen.
>
>
> > Why not just kill their controlling shell?
>
> I believe that what I'm doing...the "controlling shell" would be the
> session leader. The question is how to get its PID.
Grovel the tty structure using libkvm.
You want to look for:
(struct tty *)->t_pgrp->pg_id
Which is the process ID of t
> Ahh.. yes, I know. I'm a filesystem expert :-) However, that said, I
> will tell you quite frankly that virtually *nobody* depends on holes
> for efficient storage. There are only a few problems where it's
> practical some forms of executables, and sparse matrixes. That's
:
:> Ahh.. yes, I know. I'm a filesystem expert :-) However, that said, I
:> will tell you quite frankly that virtually *nobody* depends on holes
:> for efficient storage. There are only a few problems where it's
:> practical some forms of executables, and sparse matrixes.
> > The difference is that if you are iterating and comparing in
> > user space, you will get a failure, but if you are doing an
> > explicit VOP_LOOKUP in kernel space, the case folding will work.
>
> Hmm, why ?
UNIX globbing occurs in user space. Windows globbing, like VMS
globbing, hap
Woo.. Trimmed the CC list on this one. Didn't catch the last
one. Sorry! :-)
Jose M. Alcaide wrote to Sean Lutner and [EMAIL PROTECTED]:
> Sean Lutner wrote:
> >
> > I may just be being naive here, which is why I took this off the list. I
> > don't understand how a directory that is a-x wil
Jose M. Alcaide wrote to Warner Losh:
> Speaking of ls(1)...
>
> $ mkdir Arghh
> $ touch Arghh/{one,two,three}
> $ ls Arghh
> one three two
> $ chmod a-x Arghh
> $ ls Arghh && echo SUCCESS
> SUCCESS
> $ ls -l Arghh && echo SUCCESS
> SUCCESS
>
> ARH :-)
>
> This is not the expect
> Hi,
> Here's a patch that fixes the problem for me. can someone review and
> possibly commit it?
>
> Here's my understanding:
>
> The data returned by VOP_READDIR is not neccessarily the same as that
> consumed from the directory vnode.
>
> linux_getdents fills in a "doff" field in the linux_
Hello,
>
> With all these ppp can participate in MS VPN.
>
Euh. Right now I'm running ppp over pptpclient to connect to my ISP over an
ADSL modem. Using your patch, can I ditch pptpclient?
Kees Jan
You are only young once,
but you can
Ryan Thompson wrote:
>
> "Search" (i.e., execute) permission on a directory implies that the
> directory can be included as part of a directory search. In other words,
> mapping to inodes is provided, but obtaining a list of files in the
> directory is NOT. This is used by system administrators
> ... Sparse matrixes are the big math problem
> that benefit, but only because the solution to a sparse matrix problem
> is not even close to random so the sparse matrix winds up still being
> sparse all the way to the end of the solution.
I use them for bus simulations, which a
On Tue, 31 Oct 2000, you wrote:
> On Tue, Oct 31, 2000 at 01:40:32PM +0100, Thierry Besancon thus spoke:
> > Dixit Bill Vermillion <[EMAIL PROTECTED]> (le Tue, 31 Oct 2000 07:22:55 -0500) :
> >
> > » > % ps -aux | grep username
> > »
> > » > username 1637 1.3 0.7 1340 868 p1 Ds 11.36AM
> I use them for bus simulations, which also are permanently sparse.
> It would be nice to free up the regions when I "remove" a virtual
> board, but in a check through POSIX I could find nothing defined to
> behave that way either for mapped files or mapped memory objects.
SVR4 defined F_FREESP;
> > I use them for bus simulations, which also are permanently sparse.
> > It would be nice to free up the regions when I "remove" a virtual
> > board, but in a check through POSIX I could find nothing defined to
> > behave that way either for mapped files or mapped memory objects.
>
(...)
>
>
:to hold a write lock on the range you didn't want rewritten; so
:long as it honors the advisory locks, there'd be no chance of it
:screwing up, unless you got bit by the stupid POSIX lock close
:semantics. Stupid POSIX; that's the other one I'd put in: the
:ability to:
:
: int i = 1;
:
:In my case I'd be better off with shared memory objects that aren't
:persistent but appear in the name space so that I don't accidentally
:start copying a virtual bus file when the programs exit improperly.
:In the sparse matrix calculations with no checkpointing or need to appear
:in a name spac
Hiho,
maybe somebody ob hackers has a clue to this problem... :-/
Thanks in advance,
Daniel
--
IRCnet: Mr-Spock - ceterum censeo Microsoftinem esse delendam -
*Daniel Lang * [EMAIL PROTECTED] * +49 89 289 25735 * http://www.leo.org/~dl/*
Dear Folks,
I have some boxes, that use ma
What determines the runtime memory footprint of a process? I have small
daemons that occupy 25K on disk, don't malloc anything to speak of, but
are 440K to 1024K in memory, according to top and ps. For that matter,
just about nothing in my "ps" display is under 400K. The daemons are
dynamically
On Tue, Oct 31, 2000 at 11:17:22AM -0700, Les Biffle wrote:
> What determines the runtime memory footprint of a process? I have small
> daemons that occupy 25K on disk, don't malloc anything to speak of, but
> are 440K to 1024K in memory, according to top and ps. For that matter,
> just about no
:What determines the runtime memory footprint of a process? I have small
:daemons that occupy 25K on disk, don't malloc anything to speak of, but
:are 440K to 1024K in memory, according to top and ps. For that matter,
:just about nothing in my "ps" display is under 400K. The daemons are
:dynami
Can you assist me with a Free BSD problem. One of
my customers had a College kid mess with his Unix Kernal.
Now they can no longer access thier E-mail
???
Could he have turned off Email somehow, when he
messed around with the Unix kernal???
Thank You.
Ron MacPherson.
Tel 1/800-632-6327 or My
If there's any truth to this assumption, there's probably a much bigger
problem at hand, such as all of their networking is borked. It's kind of
hard to determine what's going on with such a general statement.
> Can you assist me with a Free BSD problem. One of my customers had a College kid
>me
I just went out & bought a D-Link 10/100 switch. There was another 16 port
10/100 switch on sale by netgear, for twice the price. Now I've established
that they're both switches (as opposed to hubs) and the three machines I
current have connected to it have sucessfully negotiated 100Mbs full-du
I guess you are talking about the kernel. As far as I know there's nothing in the
kernel, which could specifically influence
email. What about loading the GENERIC kernel or the kernel you have used before. But
please go into more detail with
your problem description.
On Tue, 31 Oct 2000 11:3
Quick question:
During a system call inside the kernel, can I safely assume that curproc
points to the process that issued the call? For example, will looking at
curproc in ip_output() tell me which process is responsible for generating
the packet?
Thanks,
Lars
--
Lars Eggert <[EMAIL PROTECTED]
On Tue, 31 Oct 2000, Ron MacPherson wrote:
> Can you assist me with a Free BSD problem. One of my customers had a College kid
>mess with his Unix Kernal.
> Now they can no longer access thier E-mail ???
> Could he have turned off Email somehow, when he messed around with the Unix kernal???
> Quick question:
>
> During a system call inside the kernel, can I safely assume that curproc
> points to the process that issued the call? For example, will looking at
> curproc in ip_output() tell me which process is responsible for generating
> the packet?
No.
--
... every activity meets w
Mike Smith wrote:
> > During a system call inside the kernel, can I safely assume that curproc
> > points to the process that issued the call? For example, will looking at
> > curproc in ip_output() tell me which process is responsible for generating
> > the packet?
>
> No.
Too bad. In which cas
> Mike Smith wrote:
> > > During a system call inside the kernel, can I safely assume that curproc
> > > points to the process that issued the call? For example, will looking at
> > > curproc in ip_output() tell me which process is responsible for generating
> > > the packet?
> >
> > No.
>
> Too
> > :> actually being used, while providing instant lookups.
> > :>
> > :> The single file would be about 96G addressable bytes... But the actual
> > :> block count would be much lower. I suppose I will have to create a seri
> es
> > :> of these files and divide the problem into < 4GB chunks, b
On Tue, 31 Oct 2000, Stephen Hocking wrote:
:I just went out & bought a D-Link 10/100 switch. There was another 16 port
:10/100 switch on sale by netgear, for twice the price. Now I've established
:that they're both switches (as opposed to hubs) and the three machines I
:current have connected
31 matches
Mail list logo
