grep exit *.o
in /usr/lib doesn't find me that label.
What am I missing?
Try this instead:
nm /usr/lib/libc.a | grep exit
I'm aware of that! That is libc which I'm trying to avoid here!
(see man gcc, search for -nostdlib)
I was referering to excuting gcc with -nostdlib with
Zhihui Zhang [EMAIL PROTECTED] writes:
If the daemon can somehow reside entirely inside the kernel, like
NFS daemon, we can save those crossings.
Yes, but the whole point of having the daemon in userspace is that
it's *so* much easier to maintain. If you want to work on performance,
I suggest
I've been advised by someone to try to use 'ntop', an network
analysis tool. Found it in the FreeBSD ports
collection.
While building it I found that configure said:
...
checking whether time.h and sys/time.h may both be included... yes
checking for lsof... no
WARNING: unable to locate lsof.
Look at /usr/ports/sysutils/lsof
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
(This is pobably inapproprate for -hackers. Reply to me alone or move it
to -questions, I guess)
On Mon, Feb 07, 2000 at 01:29:33PM +0100, Christoph Kukulies wrote:
[ntop]
While building it I found that configure said:
...
checking whether time.h and sys/time.h may both be included...
On 7 Feb 2000, Johan Danielsson wrote:
Zhihui Zhang [EMAIL PROTECTED] writes:
If the daemon can somehow reside entirely inside the kernel, like
NFS daemon, we can save those crossings.
Yes, but the whole point of having the daemon in userspace is that
it's *so* much easier to
Zhihui Zhang [EMAIL PROTECTED] writes:
The RX part seems to deal with RPC. I do not see the reason why it
can improve performance.
Eh, what do you think is moving the bits to and from your fileserver?
For cached (non-network) accesses, arla is just slighly slower than
FFS.
/Johan
To
Hi, there.
I'm planning to work on enhancing pkg_install tools following
after NetBSD's effort. Seems they've been making some remarkable
improvements over FreeBSD's original work since 1997. For example:
- pkg_add/pkg_info to speak HTTP as well as FTP
- pkg_info/pkg_delete
In article [EMAIL PROTECTED],
Marco van de Voort [EMAIL PROTECTED] wrote:
I finished the syscalls, so now I moved on the initialisation code.
To test that I try to create an empty binary, which doesn't link to libc:
I've put in an hour effort, and wrote the following C file:
int main
I'm planning to work on enhancing pkg_install tools following
after NetBSD's effort. Seems they've been making some remarkable
improvements over FreeBSD's original work since 1997. For example:
As the author of these tools, I would welcome those sorts of enhancements.
- Jordan
To
Is it possible to submit several offsets of a file to be synced
rather than calling fsync or mmap'ing over the file and calling
msync()?
The only way I can think of doing this is queuing write requests
backed by a O_FSYNC fd to an aiod.
Even then the desired result isn't really achived as
I suspect that "gcc" isn't the standard FreeBSD C compiler in your
case. Try "which gcc" and find out. It works fine for me on both
-stable and -current with "cc":
It is an older one indeed.
blake$ cc -v -nostdlib hello.c
Using builtin specs.
gcc version 2.95.2 19991024 (release)
:Is it possible to submit several offsets of a file to be synced
:rather than calling fsync or mmap'ing over the file and calling
:msync()?
:
:The only way I can think of doing this is queuing write requests
:backed by a O_FSYNC fd to an aiod.
:
:Even then the desired result isn't really achived
* Matthew Dillon [EMAIL PROTECTED] [000207 12:05] wrote:
:Is it possible to submit several offsets of a file to be synced
:rather than calling fsync or mmap'ing over the file and calling
:msync()?
:
:The only way I can think of doing this is queuing write requests
:backed by a O_FSYNC fd
:I think two kinds of behavior are needed, ordered range fsync and
:unordered async fsync.
:
:The ordered range could be taken care of easily by your implementation,
:however for maximum effectiveness you'd want to allow for unordered
:async fsync and notification.
:
:The simplest way I can think
Alfred Perlstein wrote:
I asked this question because of a problem that Postgresql has,
basically multiple processes will be updating a file, they may do
scattered IO to multiple offsets into the file, at the end of a
transaction they want to sync the data... fsync(). ow. This causes
* Wes Peters [EMAIL PROTECTED] [000207 15:02] wrote:
Alfred Perlstein wrote:
I asked this question because of a problem that Postgresql has,
basically multiple processes will be updating a file, they may do
scattered IO to multiple offsets into the file, at the end of a
transaction
Hmmm. Judging from the last CVS log entry for route.c (See r1.59), this
problem can manifest itself in -current as well. I´m cross posting on the
initial send, but please, when replying, redirect to [single, truly]
appropriate list.
It *appears* that rtfree() is puking because the rnh
[CC: to peter, could you MFC this??]
[Charset X-UNKNOWN unsupported, skipping...]
ARGHH
Hmmm. Judging from the last CVS log entry for route.c (See r1.59), this
problem can manifest itself in -current as well. I´m cross posting on the
initial send, but please, when replying, redirect
:No, this problem was fixed in -current with this commit (you looked at
:the wrong file, fix was in route.h):
:
:revision 1.30
:date: 1999/06/30 23:11:15; author: msmith; state: Exp; lines: +2 -3
:Increase the size of the route reference count from 15 bits to 31 bits.
:
:This doesn't change
20 matches
Mail list logo
