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-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd
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
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 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
Le jeudi 28 mars 2013 11:05:58 Daniel O'Connor a écrit :
> On 27/03/2013, at 18:43, David Demelier wrote:
> > Yesterday I had a panic on my laptop. Unfortunately the SU+J was not
> > able to recovery the file system, the error was something like :
> >
> > Unknown error: Help!
> > Could not find d
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.
On Wed, Mar 27, 2013 at 10:39:16PM -0700, Unga wrote:
> > I think you may be reading too much into the malloc manpage.? When it
> > mentions the use of per-thread small-object caches to avoid locking it's
> > talking about performance, not thread safety.? Allocations of all sizes
> > are thread-saf
14 matches
Mail list logo
