On Wed, Mar 25, 2009 at 06:14:13PM +0900, Izumi Tsutsui wrote:
> dar...@netbsd.org wrote:
>
> > Added Files:
> > src/sys/lib/libkern: crc32.c crc32.h
> :
> > Adds the fast version of crc32 from zlib to libkern. This should be
> > generally
> > useful and provide a place to start normalizing
On Wed, Mar 25, 2009 at 11:15:16PM +0900, Izumi Tsutsui wrote:
> t...@rek.tjls.com wrote:
>
> > What was added to libkern is much simpler than what's in libz (not just
> > because the libz sources are stylistically gross). It's not only meant
> > for use by libz.
>
> Even if so, it should be han
On Wed, Sep 02, 2009 at 08:11:35PM +0200, Thomas Klausner wrote:
>
> > Log Message:
> > Add a direction argument to socket upcalls, so they can tell why they've
> > been called when, for example, they're waiting for space to write. From
> > Ritesh Agrawal at Coyote Point.
>
> Do you think this mi
Module Name:src
Committed By: tls
Date: Wed Feb 3 03:50:45 UTC 2010
Update of /cvsroot/src/external/bsd/liblzf/dist
In directory ivanova.netbsd.org:/tmp/cvs-serv22361
Log Message:
Import liblzf version 3.5 (2-clause BSD licensed by Marc Lehmann)
Status:
Vendor Tag: schmorpf
Module Name:src
Committed By: tls
Date: Wed Feb 3 03:55:38 UTC 2010
Modified Files:
src/external/bsd/liblzf/dist: lzf.h lzfP.h lzf_c.c lzf_d.c
Log Message:
Adjust liblzf to offer the LZF_STATE_ARG API, which is better for small-stack
environments (think bootblocks etc) an
On Wed, Feb 03, 2010 at 04:04:22PM +1100, matthew green wrote:
>
>Update of /cvsroot/src/external/bsd/liblzf/dist
>In directory ivanova.netbsd.org:/tmp/cvs-serv22361
>
>Log Message:
>Import liblzf version 3.5 (2-clause BSD licensed by Marc Lehmann)
>
>
> what's liblzf, and
Module Name:src
Committed By: tls
Date: Wed Feb 3 06:25:55 UTC 2010
Modified Files:
src/distrib/sets/lists/base: shl.elf shl.mi
src/distrib/sets/lists/comp: mi shl.mi
src/external/bsd: Makefile
Added Files:
src/external/bsd/liblzf: Makefile Makefile
On Wed, Feb 03, 2010 at 08:39:29AM +0100, Adam Hamsik wrote:
>
> Where was this change discussed ? Why were are importing sourcecode without
> any users in base system(look at Lua case). If time permits is quite
> vague, if you will not have a time who will plug this lib to base ?
I imported it b
On Wed, Feb 03, 2010 at 04:55:07PM +0100, Adam Hoka wrote:
> >
> > It's a tiny, very very fast compression library. ?Christos wants it
> > for bootblocks, among other things (or so he says -- ask him).
>
> U-boot and grub2 can boot lzma compressed images, and its also more
> efficient, what about
On Wed, Feb 03, 2010 at 04:33:59PM +0100, Joerg Sonnenberger wrote:
> On Wed, Feb 03, 2010 at 12:44:39AM -0500, Thor Lancelot Simon wrote:
> > It's a tiny, very very fast compression library. Christos wants it
> > for bootblocks, among other things (or so he says -- ask him).
On Wed, Feb 03, 2010 at 10:19:57PM +0100, Joerg Sonnenberger wrote:
>
> so that the size advantage of the decoder doesn't matter too much. I
> don't mind a fast compressor for streaming applications, but those
> should exist and named as such.
Well, certainly I named some of mine. I can't check
On Wed, Sep 01, 2010 at 06:01:23AM +1000, Simon Burge wrote:
> Thor Lancelot Simon wrote:
>
> > Module Name:src
> > Committed By: tls
> > Date: Mon Aug 30 19:23:26 UTC 2010
> >
> > Modified Files:
> >
> > src/s
On Wed, Nov 23, 2011 at 12:06:26PM +0100, Christoph Egger wrote:
> On 11/23/11 11:47, Thor Lancelot Simon wrote:
> >Module Name: src
> >Committed By:tls
> >Date:Wed Nov 23 10:47:50 UTC 2011
> >
> >Modified Files:
> > src/dis
On Tue, Nov 29, 2011 at 01:06:17AM -0800, John Nemeth wrote:
>
> Currently, a kmod is an ELF binary. However, I had a look at the
> code and I think without too much effort we can achieve what you want.
Already done, but thanks!
There's no point to loading entropy from modload; rndctl can
On Sun, Dec 04, 2011 at 04:24:13PM +, Chuck Silvers wrote:
> Module Name: src
> Committed By: chs
> Date: Sun Dec 4 16:24:13 UTC 2011
>
> Modified Files:
> src/sys/arch/amd64/amd64: locore.S machdep.c
> src/sys/arch/amd64/include: types.h
> src/sys/arch/x86/include:
On Thu, Dec 08, 2011 at 07:47:07AM -0800, Chuck Silvers wrote:
>
> I'd like to leave the direct-map stuff enabled for now so we can
> gather some more data on where it works and where it doesn't.
> if you (and anyone who sees this problem) could send me the output from
> dmesg and "cpuctl identify
Yes, this change broke the build. It's simple enough - does anyone
object if I revert until it's fixed?
Thor
On Tue, Oct 09, 2012 at 03:50:18PM +0200, Manuel Bouyer wrote:
> On Tue, Oct 09, 2012 at 01:36:07PM +, Manuel Bouyer wrote:
> > [...]
> > Log Message:
> > Support transfers of up to MACHINE_MAXPHYS in all pciide variants, and ahci.
> > wd(4) limits its maxphys depending on the drives's capabili
On Tue, Oct 09, 2012 at 05:21:17PM +0200, Manuel Bouyer wrote:
> On Tue, Oct 09, 2012 at 11:04:20AM -0400, Thor Lancelot Simon wrote:
> > Hm.
> >
> > This will be an attempt to transfer an entire file -- 139264 will be the
> > entire file size of something, probabl
On Tue, Oct 09, 2012 at 05:35:44PM +0200, Manuel Bouyer wrote:
> On Tue, Oct 09, 2012 at 11:24:13AM -0400, Thor Lancelot Simon wrote:
> > On Tue, Oct 09, 2012 at 05:21:17PM +0200, Manuel Bouyer wrote:
> > > On Tue, Oct 09, 2012 at 11:04:20AM -0400, Thor Lancelot Simon wro
On Tue, Oct 09, 2012 at 10:15:06PM +0200, Manuel Bouyer wrote:
>
> Now, iostat -x shows that sequential read of a large file (either with cat
> or dd bs=1m) is done in 32k transfers at the disk level. So I guess something
> is not working properly here ...
I saw that too, though I managed to get
On Wed, Oct 10, 2012 at 11:34:48AM +0200, Manuel Bouyer wrote:
>
> I'm not sure what the best way to handle this would be.
> If we assume that maxphys is a power of 2, we could use a maxphys-derived
> mask here. Otherwise, maybe we should compute and cache the largest power-of-2
> value below maxp
On Wed, Oct 10, 2012 at 11:34:48AM +0200, Manuel Bouyer wrote:
> On Tue, Oct 09, 2012 at 05:59:06PM -0700, Chuck Silvers wrote:
> > > [...]
> > > with a 'cat big_file > /dev/null'
> > > writes are still limited to 64k ...
> >
> > I would hope that cat'ing a file to /dev/null wouldn't result in any
On Tue, Oct 09, 2012 at 05:59:06PM -0700, Chuck Silvers wrote:
>
> if so, then the reason for the 64k writes would be this block of code in
> ffs_write():
>
> if (!async && oldoff >> 16 != uio->uio_offset >> 16) {
> mutex_enter(vp->v_interlock);
>
On Mon, Oct 15, 2012 at 04:24:54PM +0200, Manuel Bouyer wrote:
>
> I wonder if we could reuse bits from the read-ahead code for write-behind ?
I'm not sure the read-ahead code is working properly. When I read through
the filesystem with cat or dd bs=1024k, on a device (wd on ahcisata)
that can d
On Sat, Mar 23, 2013 at 12:12:49AM +0900, Joerg Sonnenberger wrote:
> On Fri, Mar 22, 2013 at 01:08:18PM +, Christos Zoulas wrote:
> > In article <20130322030831.ga10...@britannica.bec.de>,
> > Joerg Sonnenberger wrote:
> > >
> > >This is wrong and unnecessary as pointed out on the mailing li
On Tue, Aug 27, 2013 at 02:01:36PM +, Taylor R Campbell wrote:
>
> This is a stop-gap on a stop-gap on a stop-gap; we really ought to
> back out all of these stop-gaps, make bcm2835_rng call rnd_add_data
> asynchronously to work around the original symptom, and design a real
> solution when we
27 matches
Mail list logo
