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
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 ge
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 2.
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 d
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 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 (/de
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 wheth
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.
> >
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
> R
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
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 ?
Shoul
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 fpathcon
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 sy
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
>
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 doprea
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.
>
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
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
sp
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 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 f
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; PO
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
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 ca
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 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 obvio
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-pr
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. -I
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 ?
> >
> >
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 i
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 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 certain
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() acc
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 FOR
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 tr
On Mon, Apr 04, 2005 at 11:43:21AM -0700, Matt wrote:
> I need some help understanding some C code.
>
> int (*if_ioctl)
>(struct ifnet *, int, caddr_t);
>
> int (*if_watchdog)
>(int);
>
> Can someone break down these declarations (if that's what they are)? Is
> this a
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
>
> Be
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 t
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
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 defi
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.
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 sta
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/lib
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 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 alr
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
h
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
--- /usr/src/lib/libc_r/uthread/p
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_p
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 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 _threa
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
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, pr
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 threshol
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
http://lists.freebsd.org/ma
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++.
>
>
> > 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
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
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/
On Wed, Nov 06, 2002 at 01:27:10PM -0700, John-David Childs wrote:
> On Sun, 2002-11-03 at 04:01, Bernd Walter wrote:
> >
> > 1T disks and bigger are not supported under -stable.
>
> Perhaps that should be > 1TB disks are not supported under stable...I
> have a 1TB RAID Array (Qlogic 2200 FC Copp
[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, sinc
> 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
..
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
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: src/sys/dev/m
> 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
> 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*..
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 f
65 matches
Mail list logo
