* Carl-Daniel Hailfinger [EMAIL PROTECTED] [080111 03:07]:
Hopefully that's the worst case. Still horrible if we use 1 MByte ROMs -
5 seconds for reading the whole ROM is unacceptable.
We will have to bear with that if we plan to check the rom checksum at
some point. This feature should
* ron minnich [EMAIL PROTECTED] [080107 17:40]:
I still find the explicit termination marker very interesting, esp.
since it is flash rewrite friendly.
With a 100k average possible erase cycles per flash block, I never
managed to exceed the life time for a flash chip, before they would die
* Carl-Daniel Hailfinger [EMAIL PROTECTED] [080107 14:37]:
2. Explicit free space covering lar member is fine, but to add any new
file to the archive, you have to erase the part covered by the exlusive
space.
I don't think this is such a bit problem. Lar could remove this entry
On Sat, Jan 05, 2008 at 08:52:49PM -0800, ron minnich wrote:
On Jan 5, 2008 5:11 PM, Peter Stuge [EMAIL PROTECTED] wrote:
On Sat, Jan 05, 2008 at 02:44:55PM -0800, ron minnich wrote:
NOT finding a file should be efficient.
Yes.
Where do the delay come from? Can anyone measure the
On Jan 10, 2008 5:38 PM, Peter Stuge [EMAIL PROTECTED] wrote:
I think the runtime-created index is much more fun.
It also keeps the lar format very clean.
Since I suffered the pain on a certain project for wasting
milliseconds, I would rather not
waste milliseconds. In this case, though, we're
On 11.01.2008 02:38, Peter Stuge wrote:
On Sat, Jan 05, 2008 at 08:52:49PM -0800, ron minnich wrote:
On Jan 5, 2008 5:11 PM, Peter Stuge [EMAIL PROTECTED] wrote:
On Sat, Jan 05, 2008 at 02:44:55PM -0800, ron minnich wrote:
NOT finding a file should be efficient.
On Fri, Jan 11, 2008 at 03:07:11AM +0100, Carl-Daniel Hailfinger wrote:
In practice, the marker is the most efficient method, but it is a
bit of an abomination IMO. :p
Big question: Is v3 a matter of pride or speed or userfriendliness?
I haven't decided yet. ;-)
All of the above, to me at
On 06.01.2008 20:29, ron minnich wrote:
On Jan 6, 2008 3:29 AM, Stefan Reinauer [EMAIL PROTECTED] wrote:
And we can't cache the ROM because of CAR?
yes.
Well, we can't use CPU cache, but we can abuse CAR memory as cache
(ironic, isn't it? I'll call it CARAC.) for the first few
Carl-Daniel,
thanks for bringing this up.
* Carl-Daniel Hailfinger [EMAIL PROTECTED] [080107 10:40]:
The bootblock will always be the last member of the lar. We also try to
fill the lar from the bottom up. That means unless the lar is completely
full, we will walk an empty are in 16 byte
On 07.01.2008 14:01, Stefan Reinauer wrote:
Carl-Daniel,
thanks for bringing this up.
You're welcome.
* Carl-Daniel Hailfinger [EMAIL PROTECTED] [080107 10:40]:
The bootblock will always be the last member of the lar. We also try to
fill the lar from the bottom up. That means
On Jan 7, 2008 1:40 AM, Carl-Daniel Hailfinger
[EMAIL PROTECTED] wrote:
Well, we can't use CPU cache, but we can abuse CAR memory as cache
(ironic, isn't it? I'll call it CARAC.) for the first few (or all)
members in the LAR. The cost estimate would be 8-32 bytes per LAR
member, depending on
On 07.01.2008 17:40, ron minnich wrote:
On Jan 7, 2008 1:40 AM, Carl-Daniel Hailfinger
[EMAIL PROTECTED] wrote:
Well, we can't use CPU cache, but we can abuse CAR memory as cache
(ironic, isn't it? I'll call it CARAC.) for the first few (or all)
members in the LAR. The cost estimate
* ron minnich [EMAIL PROTECTED] [080105 23:23]:
OK, I'm back. Stefan, we don't really need this for correctness. But
on the alix1c I am observing huge delays at startup while find_file
iterates through 512KB of empty FLASH looking
for entries that are not there. So the goal here is to have a
On 06.01.2008 05:52, ron minnich wrote:
On Jan 5, 2008 5:11 PM, Peter Stuge [EMAIL PROTECTED] wrote:
On Sat, Jan 05, 2008 at 02:44:55PM -0800, ron minnich wrote:
NOT finding a file should be efficient.
Yes.
Where do the delay come from? Can anyone measure the LPC?
I
On Jan 6, 2008 3:29 AM, Stefan Reinauer [EMAIL PROTECTED] wrote:
And we can't cache the ROM because of CAR?
yes.
I am not convinced that failing to find files has to be a performance
critical path - While I generally agree it must not take several
seconds, something's wrong with our logic
Carl-Daniel Hailfinger wrote:
Check for a terminating LAR member which tells us that no further LAR
member except the bootblock will be found after this member.
The LAR member has a normal MAGIC, but all other parts of struct
lar_header are 0xff. That way, adding a new member in place of the
On Jan 5, 2008 2:13 PM, Stefan Reinauer [EMAIL PROTECTED] wrote:
Carl-Daniel Hailfinger wrote:
Check for a terminating LAR member which tells us that no further LAR
member except the bootblock will be found after this member.
The LAR member has a normal MAGIC, but all other parts of struct
ron minnich wrote:
On Jan 5, 2008 2:13 PM, Stefan Reinauer [EMAIL PROTECTED] wrote:
I don't see a gain in this. Since we know the position and size of the
lar archive anyways, we know nothing will come after the bootblock.
There should not be any headers that do not belong to real files in
On Jan 5, 2008 2:27 PM, Stefan Reinauer [EMAIL PROTECTED] wrote:
Many seconds, though just scanning for an 8 byte signature at a 16byte
aligned address?
it's depressing, but yes. It's also surprising.
That's a max of 32k string compares for every file that is _not_ found.
Otherwise the
ron minnich wrote:
On Jan 5, 2008 2:27 PM, Stefan Reinauer [EMAIL PROTECTED] wrote:
Many seconds, though just scanning for an 8 byte signature at a 16byte
aligned address?
it's depressing, but yes. It's also surprising.
That's a max of 32k string compares for every file that is
On Sat, Jan 05, 2008 at 02:44:55PM -0800, ron minnich wrote:
NOT finding a file should be efficient.
Yes.
Where do the delay come from? Can anyone measure the LPC?
//Peter
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
On Jan 5, 2008 5:11 PM, Peter Stuge [EMAIL PROTECTED] wrote:
On Sat, Jan 05, 2008 at 02:44:55PM -0800, ron minnich wrote:
NOT finding a file should be efficient.
Yes.
Where do the delay come from? Can anyone measure the LPC?
I will try to measure for you but remember it is running
Check for a terminating LAR member which tells us that no further LAR
member except the bootblock will be found after this member.
The LAR member has a normal MAGIC, but all other parts of struct
lar_header are 0xff. That way, adding a new member in place of the
terminating member will not need an
23 matches
Mail list logo
