> Op 15 apr. 2014 om 13:13 heeft Kenneth Westerback het
> volgende geschreven:
>
>> On 15 April 2014 08:34, Otto Moerbeek wrote:
>>> On Mon, Apr 14, 2014 at 09:32:43PM -0400, sven falempin wrote:
>>>
>>> so i got gdb back to the machine because
ufs_stat,ufs_readdir},
> > + { ufs2_open,ufs2_close,ufs2_read,ufs2_write,
> > ufs2_seek,
> > + ufs2_stat,ufs2_readdir},
> > #ifdef notdef
> > { fat_open,fat_close,fat_read,fat_write,
On Wed, Apr 16, 2014 at 11:16:00PM -0700, Philip Guenther wrote:
> On Thursday, April 17, 2014, Otto Moerbeek wrote:
> ...
>
> > But bear in mind that ffs2 has more overhead in terms of metadata.
> > IMO, making it the default is not a good idea.
> >
>
> You
that long to newfs the 10 kvm's I plan on
> >using ;)
> >>>
> >>> On Thu, Apr 17, 2014 at 5:09 AM, Otto Moerbeek
> >wrote:
> >>>> On Wed, Apr 16, 2014 at 11:16:00PM -0700, Philip Guenther wrote:
> >>>>
> >>>>> O
On Tue, Apr 22, 2014 at 12:45:25AM -0400, Peter Malone wrote:
> Hi,
>
> malloc & memset can be replaced with calloc in ping.c. Please see below for
> patch details:
Better rework this to get rid of fdmasks.
-Otto
>
> Index: ping.c
>
fdmaskp, 0, fdmasks);
> FD_SET(s, fdmaskp);
> if (select(s + 1, (fd_set *)fdmaskp, (fd_set *)NULL,
> (fd_set *)NULL, &timeout) < 1)
>
>
> Quoting Otto Moerbeek :
>
> >On Tue, Apr 2
On Tue, Apr 22, 2014 at 09:49:42PM -0400, Ted Unangst wrote:
> On Mon, Apr 14, 2014 at 12:12, Otto Moerbeek wrote:
> > On Sun, Apr 13, 2014 at 06:34:17PM -0400, Ted Unangst wrote:
> >
> >> I took another look at the way junk works in malloc, and there's a few
>
On Tue, Apr 29, 2014 at 10:04:35AM -0400, Simon Perreault wrote:
> Le 2014-04-29 09:55, Henning Brauer a ?crit :
> >> Wouldn't it be better if libasr would run A and requests in
> >> parallel? Whichever response arrives first "wins".
> > no, since that gives extremely unpredictable results.
>
On Tue, Apr 29, 2014 at 04:57:28PM +, Christian Weisgerber wrote:
> On 2014-04-29, Mark Kettenis wrote:
>
> >> Google's data [1] shows a few third-world countries where what you say
> >> is true, plus Japan because of a single particularly broken ISP [2].
> >
> > Isn't there a correlation be
On Tue, Apr 05, 2011 at 01:47:52PM +0200, Antoine Jacoutot wrote:
> On Tue, 5 Apr 2011, Piotr Sikora wrote:
>
> > Hello,
> > $daemon_flags are sanitized using echo and tr, but the input isn't quoted,
> > which makes it indistinguishable from echo's options. Effect of this is that
> > when $daemon
On Tue, Apr 05, 2011 at 02:08:57PM +0200, Otto Moerbeek wrote:
> On Tue, Apr 05, 2011 at 01:47:52PM +0200, Antoine Jacoutot wrote:
>
> > On Tue, 5 Apr 2011, Piotr Sikora wrote:
> >
> > > Hello,
> > > $daemon_flags are sanitized using echo and tr, but the inpu
On Tue, Apr 05, 2011 at 04:44:27AM -0700, Philip Guenther wrote:
> On Tue, Apr 5, 2011 at 4:07 AM, Piotr Sikora wrote:
> > $daemon_flags are sanitized using echo and tr, but the input isn't quoted,
> > which makes it indistinguishable from echo's options. Effect of this is that
> > when $daemon_f
Hi,
I got little feedeback on this diff posed in a rather long thread, so
I am posting it again.
Please test this, it makes fsck_ffs much faster (especially with -p)
and less memory hungry in a lot of cases.
Note that to force a check with -p you need to unmount the filesystem,
mosty practical i
On Thu, Apr 07, 2011 at 02:34:27PM +0200, Benny Lofgren wrote:
> On 2011-04-07 11.08, Otto Moerbeek wrote:
> > Hi,
> >
> > I got little feedeback on this diff posed in a rather long thread, so
> > I am posting it again.
> >
> > Please test this, it makes f
On Thu, Apr 07, 2011 at 04:28:25PM +0200, Benny Lofgren wrote:
> On 2011-04-07 15.06, Otto Moerbeek wrote:
> > On Thu, Apr 07, 2011 at 02:34:27PM +0200, Benny Lofgren wrote:
> >
> >> On 2011-04-07 11.08, Otto Moerbeek wrote:
> >>> Hi,
> >>>
>
On Thu, Apr 07, 2011 at 11:05:42AM -0500, Amit Kulkarni wrote:
> >> Also, depending on the usage patterns, you might have a fs where high
> >> numbered inodes are used, while the fs itself is pretty empty. Filling
> >> up a fs with lots of files and them removing a lot of them is an
> >> example t
Please remove this diff from your tree for the moment.
I have found a bug.
More to follow soon.
-Otto
On Mon, Apr 11, 2011 at 01:42:29PM +0200, Otto Moerbeek wrote:
> Please remove this diff from your tree for the moment.
>
> I have found a bug.
>
> More to follow soon.
>
> -Otto
So here's the new version. You might notice it's the same as the
original d
Hi,
this removes the support to check and convert (very) old incarnations
of ffs. This old code makes diffing to fsck_ffs in freebsd harder.
We use and old filesystem in one place (the vax boot image), but that
image does not need checking, and even Miod is not sure it's actually
needed for the
On Wed, Mar 23, 2011 at 02:22:58PM +0100, David Coppa wrote:
> On Tue, 18 Jan 2011, Vadim Zhukov wrote:
>
> > Hello all (again).
> >
> > So here is a bit reworked patch, taking into account suggestions from
> > tedu@, halex@ and jmc@. Particularily, there is no more huge phrase
> > "This value i
On Wed, Mar 23, 2011 at 02:22:58PM +0100, David Coppa wrote:
> On Tue, 18 Jan 2011, Vadim Zhukov wrote:
>
> > Hello all (again).
> >
> > So here is a bit reworked patch, taking into account suggestions from
> > tedu@, halex@ and jmc@. Particularily, there is no more huge phrase
> > "This value i
Little feedback on this,
If you have good reasons to keep the ability to convert and/or check
(very) old ffs on-disk formats, speak up now.
-Otto
On Mon, Apr 18, 2011 at 12:03:38PM +0200, Otto Moerbeek wrote:
> Hi,
>
> this removes the support to check and convert (
Hi,
This diff implements a tradeoff to gain speed at the cost of reducing
the randomness of chunk allocation in malloc slightly.
The idea is only to randomize the first half of chunks in a page. The
second half of chunks will fill in the gaps in-order. The
effectiveness of the current randomizat
On Tue, Apr 26, 2011 at 10:09:23AM -0400, Ted Unangst wrote:
> On Tue, Apr 26, 2011 at 9:33 AM, Otto Moerbeek wrote:
> > This diff implements a tradeoff to gain speed at the cost of reducing
> > the randomness of chunk allocation in malloc slightly.
> >
> > The id
On Tue, Apr 26, 2011 at 03:09:57PM -0500, Amit Kulkarni wrote:
> > > > This diff implements a tradeoff to gain speed at the cost of reducing
> > > > the randomness of chunk allocation in malloc slightly.
> > > >
> > > > The idea is only to randomize the first half of chunks in a page. The
> > > >
On Tue, Apr 26, 2011 at 09:13:47PM +0200, Otto Moerbeek wrote:
> On Tue, Apr 26, 2011 at 10:09:23AM -0400, Ted Unangst wrote:
>
> > On Tue, Apr 26, 2011 at 9:33 AM, Otto Moerbeek wrote:
> > > This diff implements a tradeoff to gain speed at the cost of reducing
> >
> On Tue, Apr 26, 2011 at 09:13:47PM +0200, Otto Moerbeek wrote:
>
> Second version of diff. This is a conservative one, i.e. it does not
> change randomization in any way. The diff achieves a speedup by:
>
> - Move from long units to short, making the test for a complete no
Hi,
Currently, malloc scans the bits of the chunk bitmap from position
zero, skipping a random number (n) of free slots and then picking the
next free one. This slows things down, especially if the number of
full slots diminishes.
This diff changes the scannning to start at a random position in
On Mon, May 02, 2011 at 10:09:29AM +0200, Otto Moerbeek wrote:
> Hi,
>
> Currently, malloc scans the bits of the chunk bitmap from position
> zero, skipping a random number (n) of free slots and then picking the
> next free one. This slows things down, especially if the number
On Mon, May 02, 2011 at 10:09:29AM +0200, Otto Moerbeek wrote:
> Hi,
>
> Currently, malloc scans the bits of the chunk bitmap from position
> zero, skipping a random number (n) of free slots and then picking the
> next free one. This slows things down, especially if the number
On Wed, May 04, 2011 at 11:56:58PM -0500, Amit Kulkarni wrote:
> > The random number is derived from a global, which is incremented by a
> > few bits every time a chunk is needed (with a small optimization if
> > only one free slot is left).
> >
>
> I have no feedback on this diff but a question
On Thu, May 05, 2011 at 07:43:58AM +0200, Otto Moerbeek wrote:
> On Wed, May 04, 2011 at 11:56:58PM -0500, Amit Kulkarni wrote:
>
> > > The random number is derived from a global, which is incremented by a
> > > few bits every time a chunk is needed (with a small optimi
Hi,
Now that the latest chunk scan optimization diff is committed, it's
time to present a malloc feature diff.
This diff adds instrumentation to a MALLOC_STATS enabled malloc.c to
detect and report memory leaks, including the address of the code that
allocated memory that was not freed. With the
On Thu, May 05, 2011 at 02:29:39PM +0200, Otto Moerbeek wrote:
> Hi,
>
> Now that the latest chunk scan optimization diff is committed, it's
> time to present a malloc feature diff.
>
> This diff adds instrumentation to a MALLOC_STATS enabled malloc.c to
> dete
On Thu, May 05, 2011 at 08:21:25PM +0200, Otto Moerbeek wrote:
> On Thu, May 05, 2011 at 02:29:39PM +0200, Otto Moerbeek wrote:
>
> > Hi,
> >
> > Now that the latest chunk scan optimization diff is committed, it's
> > time to present a malloc fea
On Fri, May 06, 2011 at 05:15:34PM +0200, David Coppa wrote:
> On Fri, May 6, 2011 at 1:55 PM, Jasper Lievisse Adriaanse
> wrote:
>
> > sparc64 and loongson here, no issues.
>
> Works for me as well, amd64 and i386.
>
> ciao,
> David
asmatthieu@ found out hppa does not work. I can fonfirm tha
On Fri, May 06, 2011 at 09:34:56PM +0200, Otto Moerbeek wrote:
> On Fri, May 06, 2011 at 05:15:34PM +0200, David Coppa wrote:
>
> > On Fri, May 6, 2011 at 1:55 PM, Jasper Lievisse Adriaanse
> > wrote:
> >
> > > sparc64 and loongson here, no issues.
> >
&
On Fri, May 06, 2011 at 07:53:01AM +0200, Otto Moerbeek wrote:
> On Thu, May 05, 2011 at 08:21:25PM +0200, Otto Moerbeek wrote:
>
> > On Thu, May 05, 2011 at 02:29:39PM +0200, Otto Moerbeek wrote:
> >
> > > Hi,
> > >
> > > Now that the latest ch
On Mon, May 09, 2011 at 08:51:01PM -0400, Lawrence Teo wrote:
> In the load_entry() function in cron's entry.c, calloc() is called
> but its return value is never checked to see if it is NULL,
> potentially causing a NULL pointer dereference. Since crontab(1)
> shares code with cron, it is affecte
On Fri, May 13, 2011 at 11:39:01AM +0200, Mike Belopuhov wrote:
> On Fri, May 13, 2011 at 11:26 AM, Mark Kettenis
> wrote:
> >> From: Vadim Zhukov
> >> Date: Fri, 13 May 2011 13:10:10 +0400
> >>
> >> Hello all.
> >>
> >> Looks like there is a typo in ioctl number...
> >
> > What makes you think
On Fri, May 13, 2011 at 11:57:37AM +0200, Mike Belopuhov wrote:
> On Fri, May 13, 2011 at 11:50 AM, Otto Moerbeek wrote:
> > On Fri, May 13, 2011 at 11:39:01AM +0200, Mike Belopuhov wrote:
> >
> >> On Fri, May 13, 2011 at 11:26 AM, Mark Kettenis
> wrote:
> >>
On Fri, May 13, 2011 at 12:29:22PM +0200, Mark Kettenis wrote:
> > On Fri, May 13, 2011 at 11:39:01AM +0200, Mike Belopuhov wrote:
> >
> > > On Fri, May 13, 2011 at 11:26 AM, Mark Kettenis
> > > wrote:
> > > >> From: Vadim Zhukov
> > > >> Date: Fri, 13 May 2011 13:10:10 +0400
> > > >>
> > > >>
On Sat, May 14, 2011 at 03:43:23AM -0500, Abel Abraham Camarillo Ojeda wrote:
> > (( If you read this far, have a cookie
> >and wonder with me about that quick extraction...
> >The system this drive is in has the same board,
> >but everything else is slower and not idle when meassured
On Sat, May 14, 2011 at 04:15:51AM -0500, Abel Abraham Camarillo Ojeda wrote:
> On Sat, May 14, 2011 at 4:08 AM, David Gwynne wrote:
> >
> >
> > i have had a look at querying disks for their physical and logical block
> alignments and offsets, but the the WD??EARS-00? drives dont report this info
Hi,
define MALLOC_MAXSHIFT and related stuff more consistently. Also, zap
region_bits, it is not used.
Comments, ok?
-Otto
Index: malloc.c
===
RCS file: /cvs/src/lib/libc/stdlib/malloc.c,v
retrieving revision 1.134
diff -u
On Sun, May 15, 2011 at 06:42:06PM +0200, Otto Moerbeek wrote:
> Hi,
>
> define MALLOC_MAXSHIFT and related stuff more consistently. Also, zap
> region_bits, it is not used.
>
> Comments, ok?
No feedback... :-(
Come on, guys. This is a relatively simple diff, and so brings a
On Wed, May 18, 2011 at 10:27:43AM +1000, Damien Miller wrote:
> On Sun, 15 May 2011, Otto Moerbeek wrote:
>
> > Hi,
> >
> > define MALLOC_MAXSHIFT and related stuff more consistently. Also, zap
> > region_bits, it is not used.
>
> looks ok. some que
Hi,
it is already possible to resize auto alloctaed labels using the R
command in disklabel. But a problem quite a few persons mentioned is
that the R command only takes a relative size currently. This changes
that to allow for both absolute and relative size changes.
An example session to get t
On Sat, May 21, 2011 at 09:57:54PM -0400, Kenneth R Westerback wrote:
> I like this a lot. Can we use stronum() and avoid the manual
> operator processing?
Don't think so. Fractions like 0.5g would break.
-Otto
>
> Ken
>
> On Sat, May 21, 2011 at 10:01:01
On Sun, May 22, 2011 at 02:59:32PM +0200, Mark Kettenis wrote:
> > Date: Sun, 22 May 2011 13:41:56 +0100
> > From: Stuart Henderson
> >
> > nice, I like this :-) OK sthen@.
> >
> > > (One thing that's needed is a smarter rounding to 4k boundaries, if
> > > you work in units of M or G this work
On Sun, May 22, 2011 at 03:02:09PM +0200, Otto Moerbeek wrote:
> On Sun, May 22, 2011 at 02:59:32PM +0200, Mark Kettenis wrote:
>
> > > Date: Sun, 22 May 2011 13:41:56 +0100
> > > From: Stuart Henderson
> > >
> > > nice, I like this :-) OK sthen@.
&g
On Mon, May 23, 2011 at 02:05:53PM +0100, Stuart Henderson wrote:
> On 2011/05/21 00:19, Ariane van der Steldt wrote:
> > I suspect that the PF state table is mostly lookups, therefor AVL would
> > improve performance there. That said without having looked at the code
> > though.
>
> Lots of writ
Hi,
adding editline caused a regrssion in the handling of ^C.
Originally (and I mean the days of AT&T) bc used ^C as an abort line.
With editline, while appearing to work, the characters typed so far
remain in the input buffer. Try this: 1+^C2
Editline has no signal safe facility to accomodate t
On Thu, May 26, 2011 at 07:02:55AM +0200, Otto Moerbeek wrote:
> Hi,
>
> adding editline caused a regrssion in the handling of ^C.
>
> Originally (and I mean the days of AT&T) bc used ^C as an abort line.
> With editline, while appearing to work, the characters typed
On Mon, May 30, 2011 at 10:09:59AM +0200, Rainer Orth wrote:
> Richard Sandiford writes:
>
> > Index: gcc/config.gcc
> > ===
> > --- gcc/config.gcc 2011-05-28 09:00:32.0 +0100
> > +++ gcc/config.gcc 2011-05-28 09:00:45.000
On Thu, May 26, 2011 at 05:57:18PM +0200, Otto Moerbeek wrote:
> On Thu, May 26, 2011 at 07:02:55AM +0200, Otto Moerbeek wrote:
>
> > Hi,
> >
> > adding editline caused a regrssion in the handling of ^C.
> >
> > Originally (and I mean the days of AT&
Hi,
When quitting bc with EOF, it's unpleasing to see the ^D echoed by
editline. Additionaly, after a ^C we want ^D to work as expected: only
at the start of line. So take into account the position of the cursor
and skipchars.
ok?
-Otto
Index: bc.y
=
On Wed, Jun 01, 2011 at 10:54:05AM +0200, Rafael Sadowski wrote:
> Hello @tech,
>
> I hope anybody can help my with my yacc rules/grammer. I can't find bugs
> in my grammer. I think the problem is in the lexer but I have no idea,
> how debug it. GDB tells me: "No Source Available" for yyparse ().
Looks good, any other ok?
-0tto
On Mon, Jun 06, 2011 at 01:32:57AM -0300, pablo caballero wrote:
> "if (!*argv || *ep)" should be "if (!**argv || *ep)" but !**argv is
> already granted by !isdigit(**argv)
>
> Index: kill.c
> ==
On Sat, Jun 11, 2011 at 07:33:51PM -0700, Philip Guenther wrote:
> On Sat, Jun 11, 2011 at 7:19 PM, Ted Unangst wrote:
> > Funny enough, when pkill was first added I added an option to confirm
> > each kill. Guess what letter it used? That's right, -i, modeled
> > after rm.
>
> "Confirm each k
Hi,
ktrace is a wonderful tool, but interpreting arguments of syscalls is
a pain sometimes.
This is code (mostly taken from FreeBSD) makes this task more simple.
e.g. showing pieces of a diff between current kdump and with this diff:
- 24666 ssh CALL fcntl(0x3,0x4,0x6)
+ 24666 ssh CA
On Sat, Jun 18, 2011 at 08:16:05PM -0600, Ingo Schwarze wrote:
> When a regular expression has zero-length matches in a string,
> both sed(1) global replacement (/g) and replacement of numbered
> instances (e.g. /2) are broken. This is not even limited to sed -E.
> Both Otto's patch and my own re
On Fri, Jun 17, 2011 at 11:31:46AM +0200, Otto Moerbeek wrote:
> Hi,
>
> ktrace is a wonderful tool, but interpreting arguments of syscalls is
> a pain sometimes.
>
> This is code (mostly taken from FreeBSD) makes this task more simple.
>
> e.g. showing pieces of a di
Hi,
with kdump, file offsets are printed as two ints on 32-bit systems.
This diff should fix that and print a single long long.
Tested on vax and hppa. Strange things is that hppa prints a trailing
int for lseek(2). Have to dig into that. This has nothing to do with
fancy mode, since it is also
On Wed, Jun 22, 2011 at 09:37:58AM +0200, Stefan Rinkes wrote:
> On Tue, Jun 21, 2011 at 9:42 PM, Tobias Weingartner
> wrote:
> > On Tue, Jun 21, 2011 at 11:52 AM, Stefan Rinkes
> > wrote:
> >>
> >> while playing around with carp and pfsync I spotted
> >> two minor bugs.
> >>
> >> 1. Not all pfs
On Sat, Jun 18, 2011 at 08:16:05PM -0600, Ingo Schwarze wrote:
> When a regular expression has zero-length matches in a string,
> both sed(1) global replacement (/g) and replacement of numbered
> instances (e.g. /2) are broken. This is not even limited to sed -E.
> Both Otto's patch and my own re
On Tue, Jun 21, 2011 at 11:49:37AM +0200, Otto Moerbeek wrote:
> Hi,
>
> with kdump, file offsets are printed as two ints on 32-bit systems.
> This diff should fix that and print a single long long.
>
> Tested on vax and hppa. Strange things is that hppa prints a trailing
On Mon, Jun 27, 2011 at 08:39:19AM +0200, Otto Moerbeek wrote:
> On Tue, Jun 21, 2011 at 11:49:37AM +0200, Otto Moerbeek wrote:
>
> > Hi,
> >
> > with kdump, file offsets are printed as two ints on 32-bit systems.
> > This diff should fix that and print a single
Hi,
this adds decoding of some interesting structs to kdump. Mostly from
FreeBSD, but adapted to our tree.
an example of output:
7054 nc CALL connect(0x3,0x58f482b0,0x10)
7054 nc STRU struct sockaddr { AF_INET, 10.0.1.20: }
7054 nc RET connect -1 errno 61 Connect
On Tue, Jul 05, 2011 at 12:08:26PM -0400, Ted Unangst wrote:
> On Tue, Jul 05, 2011, Otto Moerbeek wrote:
> > Hi,
> >
> > this adds decoding of some interesting structs to kdump. Mostly from
> > FreeBSD, but adapted to our tree.
>
> very cool, just a one comm
On Tue, Jul 05, 2011 at 06:17:53PM +0200, Otto Moerbeek wrote:
> On Tue, Jul 05, 2011 at 12:08:26PM -0400, Ted Unangst wrote:
>
> > On Tue, Jul 05, 2011, Otto Moerbeek wrote:
> > > Hi,
> > >
> > > this adds decoding of some interesting structs to kdump. Mo
On Tue, Jul 05, 2011 at 07:09:38PM +0200, Otto Moerbeek wrote:
> On Tue, Jul 05, 2011 at 06:17:53PM +0200, Otto Moerbeek wrote:
>
> > On Tue, Jul 05, 2011 at 12:08:26PM -0400, Ted Unangst wrote:
> >
> > > On Tue, Jul 05, 2011, Otto Moerbeek wrote:
> > > >
On Fri, Jul 08, 2011 at 07:43:04PM +0300, Paul Irofti wrote:
>
> /usr/src/usr.bin/ktrace/ktrace.c: In function 'main':
> /usr/src/usr.bin/ktrace/ktrace.c:66: error: 'KTRFAC_STRUCT' undeclared
> (first use in this function)
> /usr/src/usr.bin/ktrace/ktrace.c:66: error: (Each undeclared identifier
On Sat, Jul 09, 2011 at 12:56:12AM -0400, Ted Unangst wrote:
> Top said I didn't have much memory free. Where did it all go?
>
> Oh, here it is:
>
> Memory: Real: 391M/2730M act/tot Free: 178M Cache: 1711M Swap: 0K/4097M
I like the idea, but I think "Cache" is ot the ricght name. How about
BCa
Hi,
kdump -m 0 does not do what you'd expect. Fix that, and do not print
"" for empty strings.
-Otto
Index: kdump.c
===
RCS file: /cvs/src/usr.bin/kdump/kdump.c,v
retrieving revision 1.57
diff -u -p -r1.57 kdump.c
--- kdump.
On Sat, Jul 09, 2011 at 09:49:47AM +0200, Otto Moerbeek wrote:
> Hi,
>
> kdump -m 0 does not do what you'd expect. Fix that, and do not print
> "" for empty strings.
>
> -Otto
On second thought I think this diff is better. It'll still print
Hi,
at the cost of some speed, reduce the malloc cache size to 0 with
flag 'S'. This means that pages that become free will be unmapped asap.
This detects more use-after-free bugs. The slowdown is because of more
unmap/mmap calls.
ok?
-Otto
Index: malloc.c
Hi,
The diff below implements utrace(2), a syscall to introduce data into
a ktrace stream from a userland program.
The interface is taken from netbsd, freebsd also has a utrace(2)
syscall, but lacks the label argument.
You could uise this as a debugging aid, to get tarce information
intermixed
On Tue, Jul 12, 2011 at 08:24:34PM +0200, Ariane van der Steldt wrote:
> On Tue, Jul 12, 2011 at 01:23:52PM +0200, Otto Moerbeek wrote:
> > at the cost of some speed, reduce the malloc cache size to 0 with
> > flag 'S'. This means that pages that become free will b
On Sun, Jul 17, 2011 at 11:20:28AM +0200, Alexander Schrijver wrote:
> This fixes an integer overflow with very long lines.
>
> OK?
Hmm, changing from a signed to an unsigned type might lead to
surprises. I think regoff_t is better.
-Otto
>
> Index: util.c
> =
On Sun, Jul 17, 2011 at 12:15:50PM +0200, Alexander Schrijver wrote:
> On Sun, Jul 17, 2011 at 11:32:27AM +0200, Otto Moerbeek wrote:
> > On Sun, Jul 17, 2011 at 11:20:28AM +0200, Alexander Schrijver wrote:
> >
> > > This fixes an integer overflow with very lon
On Sun, Jul 17, 2011 at 09:12:29AM -0400, Ted Unangst wrote:
> On Sun, Jul 17, 2011, Alexander Schrijver wrote:
> >> nope, only ssize_t is guaranteed.
> >
> > This is the only way i could think off.
>
> I don't think you will ever be able to get a string longer than
> SSIZE_MAX into memory, but
On Tue, Jul 12, 2011 at 05:52:09PM +0200, Otto Moerbeek wrote:
> Hi,
>
> The diff below implements utrace(2), a syscall to introduce data into
> a ktrace stream from a userland program.
>
> The interface is taken from netbsd, freebsd also has a utrace(2)
> syscall, but lac
On Mon, Jul 18, 2011 at 11:35:42AM +0200, Otto Moerbeek wrote:
> On Tue, Jul 12, 2011 at 05:52:09PM +0200, Otto Moerbeek wrote:
>
> > Hi,
> >
> > The diff below implements utrace(2), a syscall to introduce data into
> > a ktrace stream from a userland program.
&
Hi,
This diff (original version from nicm@) adds resolving of systcl
numbers to names. e.g.:
914 sysctl CALL __sysctl(hw.pagesize,0x8443e4,0x7f7bb8b8,0,0)
914 sysctl RET __sysctl 0
utrace(2) wil not make release due to ABI/API lock. But this can make
if I get reviews and ok's,
On Wed, Jul 27, 2011 at 10:58:22AM -0400, Ted Unangst wrote:
> On Wed, Jul 27, 2011, Otto Moerbeek wrote:
>
> > +#define SETNAME(name) do { names = (name); limit = nitems(name); } while
> > (0)
>
> userland is not supposed to use nitems I think? But it keeps sneaking
Hi,
if you are using a shell in cooked mode (e.g. csh) ^Z did not reset
the terminal to the proper state.
This should fix that. It's a pity libedit only has a all or nothing
function for signal handling...
Please test (with all shells!) and review, I want this to make
release,
-Otto
On Tue, Sep 06, 2011 at 02:19:09PM +0200, Stefan Rinkes wrote:
> Hi,
>
> During some testing in a Carp-HA setup, we noticed that the PROMISC flag
> on carpdevs never was removed when we destroyed the carp interface.
>
> Some investigation showed that a counter, which values defines if the
> ifpr
Hi,
This makes struct chunk_info a variable sized struct, wasting less
space for meta data, by only allocating space actually needed for the
bitmap (modulo alignment requirements).
I have been runing this on amd64 and loongson for a while.
Please review this and test on as many platforms as you
On Wed, Sep 07, 2011 at 03:56:18PM +0200, Steffen Wendzel wrote:
> Good idea, thx.
>
> @OpenBSD-tech: here is the new diff.
Obviously not correct.
-Otto
>
> -Steffen
>
> cvs server: Diffing .
> Index: pf_norm.c
> ===
On Wed, Sep 07, 2011 at 08:53:02AM +0200, Otto Moerbeek wrote:
> Hi,
>
> This makes struct chunk_info a variable sized struct, wasting less
> space for meta data, by only allocating space actually needed for the
> bitmap (modulo alignment requirements).
>
> I have been run
On Wed, Oct 10, 2012 at 03:39:39PM +0200, Jasper Lievisse Adriaanse wrote:
> On Wed, Oct 10, 2012 at 03:31:30PM +0200, Mark Kettenis wrote:
> > > Date: Wed, 10 Oct 2012 15:12:59 +0200
> > > From: Jasper Lievisse Adriaanse
> > >
> > > Currently the statusline in mg shows the line and column numbe
On Mon, Oct 15, 2012 at 04:01:29PM +0100, Stuart Henderson wrote:
> On 2012/10/15 16:18, David Coppa wrote:
> > On Sun, Oct 14, 2012 at 4:53 PM, Gregor Best wrote:
> > > On Sun, Oct 14, 2012 at 11:05:36AM +0200, David Coppa wrote:
> > >> On Tue, Oct 9, 2012 at 6:21 PM, Gregor Best wrote:
> > >>
Op 16 okt. 2012 om 22:56 heeft Jason McIntyre het volgende
geschreven:
> On Sat, Oct 06, 2012 at 09:40:23PM +0200, Dawe wrote:
>> I think this information is already given in the sentences before.
>>
>> Index: mmap.2
>> ===
>> RCS fi
On Wed, Oct 17, 2012 at 03:14:14PM +0100, Jason McIntyre wrote:
> On Wed, Oct 17, 2012 at 09:06:23AM +0200, Otto Moerbeek wrote:
> >
> > Op 16 okt. 2012 om 22:56 heeft Jason McIntyre het
> > volgende geschreven:
> >
> > > On Sat, Oct 06, 2012 at 09:40:23
Hi,
And here's a diff to repair ^, whcih now produces correct results for
things like
(dc)0.1 _1 ^p
or
(bc)0.1 ^ -1
The diff is against very current, so beware.
Please test. I have some regress test updates for dc as well. t9 turns
out to be a wrong test (computation of 2.1 ^ 500). Th
On Tue, Nov 06, 2012 at 04:57:20PM -0430, Andres Perera wrote:
> On Tue, Nov 6, 2012 at 3:27 PM, Otto Moerbeek wrote:
> > Hi,
> >
> > And here's a diff to repair ^, whcih now produces correct results for
> > things like
> >
> > (dc)0.1 _1 ^p
>
On Tue, Nov 13, 2012 at 03:14:06PM +0100, Alexander Hall wrote:
> On 11/13/12 13:49, Christian Weisgerber wrote:
> >Alexander Hall wrote:
> >
> >>Since I switched to SMTPD I noticed a few cron emails being marked as
> >>spam by spamassassin, largely caused by the From: and To: headers not
> >>con
On Mon, Dec 03, 2012 at 08:48:46PM +0200, Arto Jonsson wrote:
> Hi,
>
> noticed this on -current (dated Dec 2) amd64:
>
> $ who | rs
> Segmentation fault (core dumped)
>
> $ jot -r 100 | rs 10 10
> Segmentation fault (core dumped)
>
> I traced it to v1.10 of rs.c:
> http://www.
On Sun, Dec 09, 2012 at 12:26:35AM +0100, Ariane van der Steldt wrote:
> On 11/09/12 08:56, Gerhard Roth wrote:
> >On Thu, 08 Nov 2012 16:22:41 -0500
> >Ted Unangst wrote:
> >>On Thu, Nov 08, 2012 at 13:34, Ilya Bakulin wrote:
> >>
> >>>The problem seems to be in uvm_map_pageable_all() function
>
701 - 800 of 927 matches
Mail list logo
