On Sun, Mar 21, 2004 at 07:45:43PM +1100, Peter Jeremy wrote:
But (IMHO) this is a lot less clear than the former code (thought I admit
I'm guilty of doing this quite a lot in my code). Note that a modern C
compiler is free to convert
strcpy(elemcopy, :) == 0
into
elemcopy[0] == ':'
On Thu, Jan 22, 2004 at 11:16:41AM +0100, Marc Olzheim wrote:
Daniel Eischen proposed a simpler patch, which does the same trick...
Could this be committed in -STABLE by someone ? Or must this wait until
after 4.10 ?
(CURRENT: pthread_private.h -r 1.82 -r 1.81)
Marc
--- /usr/src/lib/libc_r
On Wed, Apr 28, 2004 at 09:36:50AM -1000, Clifton Royston wrote:
BSD/OS long had a very nice rotate shell script for log files as
part of their standard distro, with a hook to trigger a daemon restart
or log reopens as needed, but unfortunately I don't know its license
and copyright status.
On Mon, Mar 14, 2005 at 09:43:52PM +0100, Marco Molteni wrote:
On Mon, 14 Mar 2005 [EMAIL PROTECTED] wrote:
Hi, I am trying to debug a memory leak in executing gzipped binaries
^^
when the parameter list is too long. The
On Tue, Mar 15, 2005 at 12:15:11PM -0800, [EMAIL PROTECTED] wrote:
Thanks. Could someone generate the patch as I dont have the latest
FreeBSD source checked out.
Hmm, there seem to be more possible leaks, as the code has been
literally copied from /usr/src/gnu/usr.bin/gzip/, including the
On Tue, Mar 15, 2005 at 09:42:07PM +0100, Marc Olzheim wrote:
Thanks. Could someone generate the patch as I dont have the latest
FreeBSD source checked out.
Hmm, there seem to be more possible leaks, as the code has been
literally copied from /usr/src/gnu/usr.bin/gzip/, including
Hi.
When programming, I'd like to be able to make sure that what I think
what the code that I type does, is what I want it to do. Who doesn't?
Anyway, since I'm already compiling with most warnings on and I'm
linting my code, I'm trying my best to be more sure of it.
There where I find problems
On Wed, Mar 30, 2005 at 08:12:08PM +0200, Marc Olzheim wrote:
Please have a look at it and tell me whether this could be useful for
FreeBSD or whether that's a bridge too far...
The patch is at
http://www.stack.nl/~marcolz/FreeBSD/gcc-printf.patch.txt
Besides that, you'll need to include
On Tue, Apr 12, 2005 at 06:46:45PM +0200, Dag-Erling Smrgrav wrote:
There is no large process detection. The first process that tries
to fault in a new page after the system runs out of swap gets killed.
Which sucks when a process like X tries to free and realloc things when
possible and tries
On Tue, Apr 12, 2005 at 06:46:45PM +0200, Dag-Erling Smrgrav wrote:
There is no large process detection. The first process that tries
to fault in a new page after the system runs out of swap gets killed.
Are you suggesting that vm_pageout_pmap_collect() is no longer in use ?
That has a
On Tue, Apr 12, 2005 at 11:37:52AM -0700, ALeine wrote:
Are you suggesting that vm_pageout_pmap_collect() is no longer in
use ?
That has a FOREACH_PROC_IN_SYSTEM(p) ... find biggest unlocked
...
kill-kill-kill...
The largest process gets killed in vm_pageout_scan() according to the
On Tue, Apr 12, 2005 at 06:40:50PM -0400, David Schultz wrote:
Using madvise doesn't require changes per app, since MADV_PROTECT
is inherited across exec. You just have to write a wrapper, much
in the spirit of nice(1), to execute a protected version of X.
Hmm, that's new to me, but certainly
On Fri, Apr 15, 2005 at 01:08:21AM -0400, Brian Fundakowski Feldman wrote:
I'll spare a lengthy write-up because I think the patch documents it well
enough. It certainly appears to fix things here when doing very large
block-sized writes, but it also reduces the throughput with those block
On Fri, Apr 15, 2005 at 11:07:08AM -0400, Brian Fundakowski Feldman wrote:
Is this supposed to fix kern/79208 ?
Yes, it does; would you like to try a more recent version of the patch?
It's actually against -STABLE, but it needs to be tested in -CURRENT if
it's going ot try to make it into
On Mon, Apr 18, 2005 at 10:33:21PM +0200, Marc Olzheim wrote:
On Mon, Apr 18, 2005 at 04:22:13PM -0400, Brian Fundakowski Feldman wrote:
http://green.homeunix.org/~green/nfs_client.deadlock.patch
Hmm, could you change it into a diff -u ?
I replaced the patch with one with -u for you
On Tue, Apr 19, 2005 at 11:18:00AM -0400, Brian Fundakowski Feldman wrote:
Does this work for you?
...
cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions
-std=c99 -g -nostdinc -I- -I.
On Tue, Apr 19, 2005 at 06:02:58PM +0200, Marc Olzheim wrote:
On Tue, Apr 19, 2005 at 11:18:00AM -0400, Brian Fundakowski Feldman wrote:
Does this work for you?
...
cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith
On Tue, Apr 19, 2005 at 09:52:07AM +0200, Emmanuel Chriqui wrote:
Hi,
I'm trying to make very big MD_ROOT (300MB) sent using PXEBOOT+TFTPBOOT. No
NFS.
Any reasons for not using NFS ?
I use i386/5.4RC2/TFTPD/PXEBOOT+TFTPBOOT .
(same pb with a 5.3).
Am I missing something obvious?
On Tue, Apr 19, 2005 at 09:31:10PM +0200, Emmanuel Chriqui wrote:
This is roughly how it works under our linux servers, webservers, etc... I
was hoping to avoid that approach (less work.. less maintenance..).
Am I the only one on earth to need a big MFSROOT ???
:)
Hmm, I guess so. :-P
On Tue, Apr 19, 2005 at 04:47:23PM -0400, Brian Fundakowski Feldman wrote:
This compiles.
It does and it seems to work. The NFS performance drops considerably
though, from 8/9 MByte/s to 3/4 on sequential reads for instance.
kern/79208 is fixed by this indeed, in that I get short writes (in
On Wed, Apr 20, 2005 at 10:24:48AM -0400, Brian Fundakowski Feldman wrote:
It does and it seems to work. The NFS performance drops considerably
though, from 8/9 MByte/s to 3/4 on sequential reads for instance.
kern/79208 is fixed by this indeed, in that I get short writes (in case
of
On Wed, Apr 20, 2005 at 11:20:38AM -0400, Brian Fundakowski Feldman wrote:
Reads should be totally unaffected...
The server was misbehaving. Fixed. :-)
Btw.: I'm not sure write(),writev() and pwrite() are allowed to do short
writes on regular files... ?
Our manpage is incorrect; POSIX
On Wed, Apr 20, 2005 at 01:28:39PM -0400, Brian Fundakowski Feldman wrote:
It is ok to return partial success if the first chunk of a large write
succeeded and a later chunk failed persistently, but not if it cannot be
performed as a single NFS transaction.
What is your rationale for
Are there plans on implementing preadv() and pwritev() ? I kind of miss
the functionality and I saw NetBSD had it already...
Are there any issues with it that I'm not aware of ?
Marc
pgpMrCgB7FChi.pgp
Description: PGP signature
On Mon, Apr 25, 2005 at 02:50:45PM +0100, Bruce M Simpson wrote:
I don't do enough thread-based programming at the moment to make this worth
my while, though, but I'm happy to look at a patch.
Ok, something like this ?
I'm a bit puzzled by the coding style in the file, but I think I got the
On Mon, Apr 25, 2005 at 05:23:14PM +0200, Marc Olzheim wrote:
int
kern_readv(struct thread *td, int fd, struct uio *auio)
{
+ return (preadv(td, fd, auio, (off_t)-1, 0));
+}
-dopreadv()
Hit the send button too quickly, I'll submit a new one after testing.
Marc
pgpoFklMqNhu2.pgp
On Mon, Apr 25, 2005 at 05:23:14PM +0200, Marc Olzheim wrote:
On Mon, Apr 25, 2005 at 02:50:45PM +0100, Bruce M Simpson wrote:
I don't do enough thread-based programming at the moment to make this worth
my while, though, but I'm happy to look at a patch.
Ok, something like this ?
I'm
On Mon, Apr 25, 2005 at 08:29:49PM +0100, Bruce M Simpson wrote:
More like this then...
Yep, something like that! Thanks, though I may not have time to commit
this at the moment. :-(
Then should I file a PR after someone tells me what kind of naming
scheme they'd rather have than dopreadv()
On Mon, Apr 25, 2005 at 06:50:41PM +0200, Marc Olzheim wrote:
On Mon, Apr 25, 2005 at 05:23:14PM +0200, Marc Olzheim wrote:
On Mon, Apr 25, 2005 at 02:50:45PM +0100, Bruce M Simpson wrote:
I don't do enough thread-based programming at the moment to make this
worth
my while, though
On Tue, Apr 26, 2005 at 03:31:15PM +0200, Marc Olzheim wrote:
Ok, I cleaned up the patch, got the freebsd32-compat working and filed a
PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/80362
Thanks to some people commenting, I've fixed a typo and added the off_t
typedef in sys/uio.h, so
And a man page link fix to top it off...
Marc
--- src/lib/libc/sys/Makefile.inc Wed Apr 7 11:07:47 2004
+++ src/lib/libc/sys/Makefile.inc Wed Apr 27 11:02:02 2005
@@ -127,7 +127,7 @@
MLINKS+=modnext.2 modfnext.2
MLINKS+=mount.2 nmount.2 mount.2 unmount.2
MLINKS+=pathconf.2
On Mon, Jul 21, 2003 at 11:24:43AM -0700, Tim Kientzle wrote:
Chad David wrote:
I assumed it was obvious that you could copy the data, but I believe
the intent of the original question was to find an alternative. As
far as I know there isn't one. A const is a const, except in C++.
Yes,
On Thu, Oct 23, 2003 at 09:55:21PM +1000, Q wrote:
I beg to differ. It might show linear growth, but the OpenBSD graph is
definitely not O(n).
Err... How would you define O(n) then ?
Zlo
___
[EMAIL PROTECTED] mailing list
On Thu, Oct 23, 2003 at 09:55:21PM +1000, Q wrote:
I beg to differ. It might show linear growth, but the OpenBSD graph is
definitely not O(n).
Hmm, it looks like that when it hits the next threshold, it's O(n),
but O(1) otherwise. But contrary to the blurry Linux 2.4 fork() graph,
the
Hi.
Is there a reason why in the case that a thread is not done yet,
pthread_join() does not call _thread_kern_sig_undefer() ?
We have a program where one thread consumes all CPU it can get for
blocks of data.
A status thread is spawned as soon as the main thread starts working on
a new block,
On Wed, Dec 31, 2003 at 12:16:42PM +0100, Marc Olzheim wrote:
Hi.
Is there a reason why in the case that a thread is not done yet,
pthread_join() does not call _thread_kern_sig_undefer() ?
Hmm, it isn't FreeBSD specific... OpenBSD does the same...
Zlo
On Wed, Dec 31, 2003 at 08:47:03AM -0500, Daniel Eischen wrote:
Is there a reason why in the case that a thread is not done yet,
pthread_join() does not call _thread_kern_sig_undefer() ?
[snip]
No, it looks like you found a bug. Committed, thanks!
Hmm, ok ;-) But then why is
On Wed, Dec 31, 2003 at 09:22:14AM -0500, Daniel Eischen wrote:
Hmm, ok ;-) But then why is _thread_kern_sig_undefer() called within
every if-case, instead of just below the if ? It looked like it was
contructed this way to be able to omit _thread_kern_sig_undefer() in
that specific
On Wed, Dec 31, 2003 at 03:30:15PM +0100, Marc Olzheim wrote:
So I noticed. But it seems to me as if the undefers could be removed
from within the if-else-blocks and collapsed into a single undefer just
beneath the if-else-blocks, right before the
_thread_leave_cancellation_point();
Hmm
For debugging purposes would like to propose the following patch. The
only thing besides from not knowing anything about other architectures
than i386, is that I don't know exactly what happens when compiling with
-fomit-frame-pointer
Could someone tell me ?
Marc
---
On Wed, Jan 21, 2004 at 10:13:44PM +0100, Marc Olzheim wrote:
Could someone tell me ?
Erhm... For some clue what this is about:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg44893.html
Marc
___
[EMAIL PROTECTED] mailing list
http
On Wed, Jan 21, 2004 at 11:09:16PM +0100, Marc Olzheim wrote:
On Wed, Jan 21, 2004 at 10:13:44PM +0100, Marc Olzheim wrote:
Could someone tell me ?
Erhm... For some clue what this is about:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg44893.html
Found it out already, shouldn't
Now that 5.4-release has settled, who is willing to commit the preadv()
patch at http://www.stack.nl/~marcolz/FreeBSD/ ?
Btw: Why are the files generated by 'make syscalls.c' in
/usr/src/sys/kern and 'make sysent' in /usr/src/sys/compat/freebsd32 in
CVS and not just generated at build time ?
On Tue, May 31, 2005 at 03:41:15PM +0100, Steve Roome wrote:
# Check that SNAPFILE can be created/deleted
mksnap_ffs $MOUNT $SNAPFILE MD_DEV=`mdconfig -a -t vnode -f $SNAPFILE`
mount -o ro,noatime /dev/$MD_DEV /${SNAPMOUNT}
Perhaps a mdconfig option '-o readonly' might help...
Zlo
On Wed, Jul 20, 2005 at 11:42:57AM +0300, zkan KIRIK wrote:
Hi,
i am trying to measure free memory and real memory.
but values at dmesg.boot and sysctl are diffrent.
# cat /var/run/dmesg.boot | grep real
real memory = 268435456 (256 MB)
# sysctl vm.vmtotal | grep Real
Real
On Wed, Jul 20, 2005 at 10:56:58AM +0200, Marc Olzheim wrote:
On Wed, Jul 20, 2005 at 11:42:57AM +0300, zkan KIRIK wrote:
Hi,
i am trying to measure free memory and real memory.
but values at dmesg.boot and sysctl are diffrent.
# cat /var/run/dmesg.boot | grep real
real memory
On Mon, Aug 01, 2005 at 02:42:21PM +0300, victor cruceru wrote:
Hi all,
I'm just wondering if it's OK for an open syscall on such a device (i.e.
/dev/acd0 or /dev/da1 with a CF reader attached) to block till the media is
ready or a timeout occurs.
I'd say that depends completely on whether
On Mon, Aug 01, 2005 at 04:33:23PM +0300, victor cruceru wrote:
Hi Marc,
Thanks for the info. Here it is one my situation. I have a CF reader (fully
detected by the USB subsystem) with two slots
(one with a media and one without any media). An open with O_NONBLOCK on the
empty slot
On Mon, Aug 01, 2005 at 03:35:46PM +0200, Marc Olzheim wrote:
Hmm, it seems not. Perhaps is trying to do its magic first. What's the
^
Insert 'GEOM' here | :-/
wchan of the process doing the open() ?
Marc
pgpSWtOHC8JdB.pgp
Description: PGP signature
On Fri, Oct 18, 2002 at 04:42:01PM -0700, David Yeske wrote:
MD_ROOT_SIZE is only needed for write_mfs_in_kernel. When write_mfs_in_kernel was
removed the
code that used it was not though. I don't think it is still being used though. A
couple of files
still reference it:
..
if ((nd = parse_char_class(++nd)) == NULL) {
..
Hmmm... is this legal ?
http://www.eskimo.com/~scs/C-faq/q3.1.html seems to tell otherwise...
Zlo
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
If it were nd++, yes. However, it is ++nd, thus, the increment
happens first, then the call to parse_char_class(), then the assignment
to nd.
Ah right, sorry, my mistake...
Zlo
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
[snip interesting piece of compiler history]
In any case, your fears are unfounded, for the most part, since
the FAQ entry you are referencing is not analogous to the construct
you are trying to apply it to, anyway, and the FAQ fails to deal
with many of these portability issues, too, since
Whoops, hit the 'send' too fast...
With some minor modifications to disklabel, you can label a 2 Tb disk.
We've done it with a 1.4Tb disk:
Filesystem Size Used Avail Capacity Mounted on
/dev/da20a 669G 246G 370G40%/rapraid0
/dev/da20e
On Wed, Nov 06, 2002 at 05:14:54PM -0800, Nate Lawson wrote:
On Thu, 7 Nov 2002, Marc Olzheim wrote:
With some minor modifications to disklabel, you can label a 2 Tb disk.
We've done it with a 1.4Tb disk:
Filesystem Size Used Avail Capacity Mounted on
/dev/da20a
Um, why did you reimplement strtoll(3)?
Hmmm, not necessary indeed...
Zlo
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Hi.
While working on tha FreePascal FreeBSD port, we found a bug in the
kernel source, that has been fixed in -CURRENT...
Any reason why pathes 1.137 and 1.148 of kern_sig.c have not yet been
committed to RELENG_4 ?
Marc Marco
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe
Are these really the revisions you mean? 1.137 is completely harmless,
and 1.48 is limited to the case where you define the undocumented
option COMPAT_SUNOS.
I just ran in to 1.148 and 1.137 seemed to do some harm, but didn't; in C
it just works out fine, because of the union...
*bwerk*...
If I want to install FBSD 4.5 on dozens of identical boxes, what is the best
way?
I don't want to take the disks out and dup/mirror them, not dozens of them.
The hardware supports pxe and I had half a hope that I could set up a master
system with bootpd, let each target system boot by
On Tue, Apr 08, 2008 at 10:02:03AM -0700, LI Xin wrote:
Aryeh M. Friedman wrote:
Is it possible via sysctl or some other method to allow non-superusers
to set any priority they want. The specific question is I often want
to set idprio 31 on stuff but don't want to switch to root to do it
On Tue, May 06, 2008 at 03:11:35PM +0200, Lukasz Jaroszewski wrote:
just by curiosity, why #define UT_HOSTSIZE is 16, not 256, like in
OtherBSDs and some unix-like-like OSes? :)
Probably historical reasons. It's very much possible to change it
though. We've defined it to 64 since FreeBSD
On Wed, Oct 08, 2008 at 10:20:00PM +0200, Ivan Voras wrote:
I'm trying to use the %c formatter in strftime(3), documented as:
%cis replaced by national representation of time and date.
... which looks useful, except that in code in which WFORMAT is defined
as 1 I get this
On Wed, Feb 03, 2010 at 10:23:50AM -0300, Daniel Molina Wegener wrote:
I'm having trouble looking this function up in the source tree, the trail
seems to end at __sys_read which has a bunch of prototypes but i can't find
the actual function code.
Well, you can try cscope --- IMO the
63 matches
Mail list logo
