Hello there,
I have some sources developed on non-FreeBSD systems (the sources of
the run-time system for the Glasgow Haskell Compiler [1]) which try to
#include signal.h to use siginterrupt() and stdio.h to use
vsnprintf(). The problem is that they #define (or not) some constants
which makes the
On Wednesday 19 May 2010 6:52:04 am Gabor PALI wrote:
> Hello there,
>
> I have some sources developed on non-FreeBSD systems (the sources of
> the run-time system for the Glasgow Haskell Compiler [1]) which try to
> #include signal.h to use siginterrupt() and stdio.h to use
> vsnprintf(). The pr
On Wed, 19 May 2010 12:52:04 +0200
Gabor PALI wrote:
> Hello there,
>
> I have some sources developed on non-FreeBSD systems (the sources of
> the run-time system for the Glasgow Haskell Compiler [1]) which try to
> #include signal.h to use siginterrupt() and stdio.h to use
> vsnprintf(). The p
Thanks for all the great suggestions!
It looks like the kevent system call is the closest to what I need.
However, I didn't mention this, but I would like the process being
traced to be stopped on entrance to fork, exec, etc. This would be
similar to Linux's ptrace interface which sends a SIGTRAP
[Topic moved away from freebsd-current as the problem doesn't seem to be
-CURRENT-specific, and I think there's a larger crowd here :).]
This may give a hint. The following patch resolves the 60-second idling
issue.
--- bgfuck 2010-05-19 20:23:50.0 +0200
+++ bgfsck 2010-05-19
On 05/19/10 12:09, deeptec...@gmail.com wrote:
[Topic moved away from freebsd-current as the problem doesn't seem to be
-CURRENT-specific, and I think there's a larger crowd here :).]
This may give a hint. The following patch resolves the 60-second idling
issue.
--- bgfuck 2010-05-19 20:23:50.00
Doug Barton wrote:
On 05/19/10 12:09, deeptec...@gmail.com wrote:
[Topic moved away from freebsd-current as the problem doesn't seem to be
-CURRENT-specific, and I think there's a larger crowd here :).]
This may give a hint. The following patch resolves the 60-second idling
issue.
--- bgfuck 20
* Dan McNulty [100519 07:13] wrote:
> Thanks for all the great suggestions!
>
> It looks like the kevent system call is the closest to what I need.
> However, I didn't mention this, but I would like the process being
> traced to be stopped on entrance to fork, exec, etc. This would be
> similar t
Hi all
I'll be developing the Distributed Audit Project for TrustedBSD/FreeBSD,
here's the abstract:
The shipping daemon will deliver the audit trails generated through the
network to a master system, that will admin the trails to have the
auditing centralized, ease to admin and practical
9 matches
Mail list logo