On Sat, Mar 23, 2013 at 5:13 PM, hiren panchasara
wrote:
> On Sat, Mar 23, 2013 at 8:58 AM, hiren panchasara
> wrote:
>>
>> On Mar 22, 2013 10:48 PM, "Jim Harris" wrote:
>>>
>>>
>>>
>>> On Friday, March 22, 2013, hiren panchasara wrote:
On Thu, Jan 31, 2013 at 6:26 PM, hiren panchasara
TB --- 2013-03-29 02:48:53 - tinderbox 2.10 running on freebsd-current.sentex.ca
TB --- 2013-03-29 02:48:53 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE
FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64
TB --- 2013
... you guys should think about writing an aio_sendfile() function for FreeBSD.
Just saying.
Adrian
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre
On 28 March 2013 10:26, Poul-Henning Kamp wrote:
> Isn't there some kernel compile-time option to eliminate the huge
> tables used for errormessages etc ?
Yup. It doesn't save all that much in the grand scheme of things.
Doubly so since my secondary size constraint is an 896k partition that
I lz
On Thu, 28 Mar 2013, Ian Lepore wrote:
On Thu, 2013-03-28 at 09:17 +0200, Alexander Motin wrote:
On 28.03.2013 02:43, Adrian Chadd wrote:
My main concern with the new stuff is that it requires CAM and that's
reasonably big compared to the standalone ATA code.
It'd be nice if we could slim dow
In message
, Adrian
Chadd wri
tes:
>On 28 March 2013 09:05, Lev Serebryakov wrote:
>adrian@freefall:~/public_html/ath$ cat AP121-nodebug.txt | egrep
>'(cam_|umass|scsi_)' | awk '{a+=$4} END {print a}'
>190904
>
>It doesn't seem like a lot, but it does add up..
Isn't there some kernel compile-t
.. and before you ask - yes, there are embedded boards with limited
RAM that also have ATA ports. :-)
Adrian
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freeb
On 28 March 2013 09:05, Lev Serebryakov wrote:
> Yes: USB UMASS. It uses CAM too, and useful for very small systems,
> like 4MiB FLASH and 16MiB RAM (yes, whole system image, kernel and
> all, should be packed to 4MiB).
>
> Please note, Adrian speaks about CAM, not only CAM + ATA.
And I
On Thu, Mar 28, 2013 at 12:52 AM, Konstantin Belousov
wrote:
>> i would like to get some reviews, opinions and/or comments on the patch
>> below.
>>
>> a little bit background, as far as i understand, cluster_read() can
>> initiate two disk i/o's: one for exact amount of data being requested
>>
Hello, Aleksandr.
You wrote 28 марта 2013 г., 18:09:53:
>> It'd be nice if we could slim down the CAM stack a bit first; it makes
>> embedding it on the smaller devices really freaking painful.
AR> /me never seen embedded devices with ATA/SATA and less than 64MB of RAM.
AR> (i386/i486 old machine
On 3/28/2013 8:27 AM, Scott Long wrote:
On Mar 27, 2013, at 4:13 PM, Matthew Jacob wrote:
On 3/27/2013 2:22 PM, Alexander Motin wrote:
Hi.
Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA stack,
using only some controller drivers of old ata(4) by having `options ATA_CA
On Mar 27, 2013, at 4:13 PM, Matthew Jacob wrote:
> On 3/27/2013 2:22 PM, Alexander Motin wrote:
>> Hi.
>>
>> Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA
>> stack, using only some controller drivers of old ata(4) by having `options
>> ATA_CAM` enabled in all kernels
On Mar 28, 2013, at 8:00 AM, Ian Lepore wrote:
> On Thu, 2013-03-28 at 09:17 +0200, Alexander Motin wrote:
>> On 28.03.2013 02:43, Adrian Chadd wrote:
>>> My main concern with the new stuff is that it requires CAM and that's
>>> reasonably big compared to the standalone ATA code.
>>>
>>> It'd b
On Mar 27, 2013, at 6:43 PM, Adrian Chadd wrote:
> My main concern with the new stuff is that it requires CAM and that's
> reasonably big compared to the standalone ATA code.
>
>From a code execution standpoint? No, it's not.
> It'd be nice if we could slim down the CAM stack a bit first; it
On Wed, 27 Mar 2013 17:43:07 -0700
Adrian Chadd wrote:
> My main concern with the new stuff is that it requires CAM and that's
> reasonably big compared to the standalone ATA code.
>
> It'd be nice if we could slim down the CAM stack a bit first; it makes
> embedding it on the smaller devices re
On Thu, 2013-03-28 at 09:17 +0200, Alexander Motin wrote:
> On 28.03.2013 02:43, Adrian Chadd wrote:
> > My main concern with the new stuff is that it requires CAM and that's
> > reasonably big compared to the standalone ATA code.
> >
> > It'd be nice if we could slim down the CAM stack a bit first
On 27.03.2013 23:07, J.R. Oldroyd wrote:
> I've built a dtrace kernel per the instructions in the handbook and
> on the DTrace wiki page. I would now like to do this:
>
> boot system
> kldload dtraceall
> kldload drm2
> dtrace -o dtrace.log -s script.d
> (the
on 25/03/2013 22:44 Andriy Gapon said the following:
>
> Would like to ask for opinions on this topic...
> Please read this PR for context:
> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/122838
> Especially Jaakko's insightful description of the problem.
So I would like to commit the following
On Wed, Mar 27, 2013 at 01:43:32PM -0700, Maksim Yevmenkin wrote:
> Hello,
>
> i would like to get some reviews, opinions and/or comments on the patch below.
>
> a little bit background, as far as i understand, cluster_read() can
> initiate two disk i/o's: one for exact amount of data being reque
Alexander Motin wrote this message on Thu, Mar 28, 2013 at 09:17 +0200:
> On 28.03.2013 02:43, Adrian Chadd wrote:
> >My main concern with the new stuff is that it requires CAM and that's
> >reasonably big compared to the standalone ATA code.
> >
> >It'd be nice if we could slim down the CAM stack
On 28.03.2013 02:43, Adrian Chadd wrote:
My main concern with the new stuff is that it requires CAM and that's
reasonably big compared to the standalone ATA code.
It'd be nice if we could slim down the CAM stack a bit first; it makes
embedding it on the smaller devices really freaking painful.
21 matches
Mail list logo