This seems reasonable. MAP_UNINITIALIZE definitely needs adding to the
general list so that the MMU folks don't steal the bit. I would also call it
MAP_UNINITIALIZED (well, actually, I'd call it MAP_UNINITIALISED:-), otherwise
it looks like you're asking mmap() to uninitialise the memory for
Mike Frysinger vap...@gentoo.org wrote:
+ bool Allow mmaped anonymous memory to be un-initialized
Can you change that to be 'mmapped' and 'uninitialized'?
Other than that, it looks good.
David
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
From: Jie Zhang jie.zh...@analog.com
The NOMMU code currently clears all anonymous mmapped memory. While this
is what we want in the default case, all memory allocation from userspace
under NOMMU has to go through this interface, including malloc() which is
allowed to return uninitialized
Mike Frysinger wrote:
From: Jie Zhang jie.zh...@analog.com
The NOMMU code currently clears all anonymous mmapped memory. While this
is what we want in the default case, all memory allocation from userspace
under NOMMU has to go through this interface, including malloc() which is
allowed to
Hi all, I'm trying to write a hush script with expr command and cat
command but it doesn't work.
I posted my script:
#!/bin/hush
A= `cat /proc/driver/typeboard/BoardAddr`
C= expr $A \* 2
D= expr $B -1
this is the optput
hush: cannot exec '`cat': No such file or directory
expr: syntax error
I mean to ask, is there any advantage in using NOR-ECC flash agains
regular NOR flash. Does the linux mtd driver/jffs2 differentiate it?
On Sat, Oct 17, 2009 at 4:01 PM, Keith Mund (AZ) keithm...@cox.net wrote:
On Friday, October 16, 2009 5:04 PM, Prasad wrote:
Got it. Is there any difference in
from Prasad - Monday, October 19, 2009 10:53 AM:
I mean to ask, is there any advantage in using NOR-ECC flash agains
regular NOR flash. Does the linux mtd driver/jffs2 differentiate it?
The advantage part depends on the needs of each system. Some benefits of
ECC are that it helps overcome
Interesting..till now i was thinking there is still some kind of
buffering mechanism in case of NOR flash. So if there is a process
that opens a file writes one byte at a time (write() or fwrite() on
jffs2 partitioned file system), this will kind of wear out the flash
pretty right?. May be a
for NOR flash, the number of erase cycles on each sector is limited, not
the number of writes. For the flash lifetime, it doesn't make a
difference if you write one byte at a time or a complete sector at once.
-Erwin
Am Montag, den 19.10.2009, 16:43 -0700 schrieb Prasad:
Interesting..till now i
For the NOR flash, when the write( , , 1) routine is called, the file
system(jffs2 in this case) has to read back the whole sector, modify
that byte, erase the sector and then write back the whole sector (in
order to write a single byte). Is it not so..So it does affect the
flash-lifetime right?
I don't know about the jffs2 internals in detail, but I'm pretty sure
that it doesn't work in the way you described. That would be the worst
approach for a flash filesystem that one can think of.
-Erwin
Am Montag, den 19.10.2009, 17:28 -0700 schrieb Prasad:
For the NOR flash, when the write( ,
On Oct 19, 2009, at 8:28 PM, Prasad wrote:
For the NOR flash, when the write( , , 1) routine is called, the file
system(jffs2 in this case) has to read back the whole sector, modify
that byte, erase the sector and then write back the whole sector (in
order to write a single byte). Is it not
12 matches
Mail list logo
