Hi,
this adds a 32bit version field after the magic. I choose 200709061 as a starting version, where the last 1 is a counter ranging to 9, thus there can be 9 different version per day (lol).
It is not going to try any backward compatibility or workaround based on version, just bail out or skip when a different version than we are running is encountered.
It might be a better idea grouping len and offset fields after or before version field, and make then fixed by design, so we can do correct skipping instead the 16-byte aligned walking.
Note: the "/* NOTE -- This and the user-mode lar.h are NOT IN SYNC. Be careful. */" message (which is present both in include/lar.h and utils/lar/lar.h) is not valid anymore. -- Alex
hi, we rejected this idea, right? I am trying to catch up on un-acked patches.
ron
On 9/5/07, Alex Beregszaszi alex@rtfs.hu wrote:
Hi,
this adds a 32bit version field after the magic. I choose 200709061 as a starting version, where the last 1 is a counter ranging to 9, thus there can be 9 different version per day (lol).
It is not going to try any backward compatibility or workaround based on version, just bail out or skip when a different version than we are running is encountered.
It might be a better idea grouping len and offset fields after or before version field, and make then fixed by design, so we can do correct skipping instead the 16-byte aligned walking.
Note: the "/* NOTE -- This and the user-mode lar.h are NOT IN SYNC. Be careful. */" message (which is present both in include/lar.h and utils/lar/lar.h) is not valid anymore.
Alex
-- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Hi,
On Sat, 2007-09-08 at 10:39 -0700, ron minnich wrote:
hi, we rejected this idea, right? I am trying to catch up on un-acked patches.
What about adding then a version string (to a fixed position) in stage1? For user-space tools to handle multiple versions.
-- Alex
On 12.09.2007 21:41, Alex Beregszaszi wrote:
Hi,
On Sat, 2007-09-08 at 10:39 -0700, ron minnich wrote:
hi, we rejected this idea, right? I am trying to catch up on un-acked patches.
What about adding then a version string (to a fixed position) in stage1? For user-space tools to handle multiple versions.
I still like the versioning idea. Can we discuss it again since there was no final rejection?
Regards, Carl-Daniel
On Sat, Sep 22, 2007 at 10:19:40PM +0200, Carl-Daniel Hailfinger wrote:
On 12.09.2007 21:41, Alex Beregszaszi wrote:
Hi,
On Sat, 2007-09-08 at 10:39 -0700, ron minnich wrote:
hi, we rejected this idea, right? I am trying to catch up on un-acked patches.
What about adding then a version string (to a fixed position) in stage1? For user-space tools to handle multiple versions.
I still like the versioning idea. Can we discuss it again since there was no final rejection?
Yes. I'd also like a version field. I really think it's needed.
Uwe.
On 22/09/07 22:19 +0200, Carl-Daniel Hailfinger wrote:
On 12.09.2007 21:41, Alex Beregszaszi wrote:
Hi,
On Sat, 2007-09-08 at 10:39 -0700, ron minnich wrote:
hi, we rejected this idea, right? I am trying to catch up on un-acked patches.
What about adding then a version string (to a fixed position) in stage1? For user-space tools to handle multiple versions.
I still like the versioning idea. Can we discuss it again since there was no final rejection?
I still like it. I don't mind putting the version in the header at all - we don't need an 8 character magic value - we can truncate it and put the header in there - we probably only need two characters anyway - how many header versions do we think we're going to have? :)
Jordan
* Alex Beregszaszi alex@rtfs.hu [070906 02:59]:
Hi,
this adds a 32bit version field after the magic. I choose 200709061 as a starting version, where the last 1 is a counter ranging to 9, thus there can be 9 different version per day (lol).
It is not going to try any backward compatibility or workaround based on version, just bail out or skip when a different version than we are running is encountered.
It might be a better idea grouping len and offset fields after or before version field, and make then fixed by design, so we can do correct skipping instead the 16-byte aligned walking.
Note: the "/* NOTE -- This and the user-mode lar.h are NOT IN SYNC. Be careful. */" message (which is present both in include/lar.h and utils/lar/lar.h) is not valid anymore.
Alex
Signed-off-by: Alex Beregszaszi alex@rtfs.hu
Acked-by: Stefan Reinauer stepan@coresystems.de
Please commit.
On Wed, 2007-10-17 at 13:07 +0200, Stefan Reinauer wrote:
- Alex Beregszaszi alex@rtfs.hu [070906 02:59]:
Hi,
this adds a 32bit version field after the magic. I choose 200709061 as a starting version, where the last 1 is a counter ranging to 9, thus there can be 9 different version per day (lol).
It is not going to try any backward compatibility or workaround based on version, just bail out or skip when a different version than we are running is encountered.
It might be a better idea grouping len and offset fields after or before version field, and make then fixed by design, so we can do correct skipping instead the 16-byte aligned walking.
Note: the "/* NOTE -- This and the user-mode lar.h are NOT IN SYNC. Be careful. */" message (which is present both in include/lar.h and utils/lar/lar.h) is not valid anymore.
Alex
Signed-off-by: Alex Beregszaszi alex@rtfs.hu
Acked-by: Stefan Reinauer stepan@coresystems.de
Please commit.
Are we still in favor of this? If yes I will commit it tomorrow.
-- Alex
On Thu, Nov 29, 2007 at 02:30:14AM +0100, Alex Beregszaszi wrote:
this adds a 32bit version field after the magic.
Signed-off-by: Alex Beregszaszi alex@rtfs.hu
Acked-by: Stefan Reinauer stepan@coresystems.de
Please commit.
Are we still in favor of this? If yes I will commit it tomorrow.
If there are no NAKs go for it!
Please include the new rev in the final message in the patch thread for better traceability.
//Peter
* Alex Beregszaszi alex@rtfs.hu [071129 02:30]:
Signed-off-by: Alex Beregszaszi alex@rtfs.hu
Acked-by: Stefan Reinauer stepan@coresystems.de
Please commit.
Are we still in favor of this? If yes I will commit it tomorrow.
I think we are. While it is probably hard to make old and new versions of lar work well together, we'll at least have an indicator why something might go wrong with that version.
Stefan
On 29.11.2007 09:57, Stefan Reinauer wrote:
- Alex Beregszaszi alex@rtfs.hu [071129 02:30]:
Signed-off-by: Alex Beregszaszi alex@rtfs.hu
Acked-by: Stefan Reinauer stepan@coresystems.de
Please commit.
Are we still in favor of this? If yes I will commit it tomorrow.
I think we are. While it is probably hard to make old and new versions of lar work well together, we'll at least have an indicator why something might go wrong with that version.
Alex, can you repost an updated patch? I want to verify that patch against a suggestion of Peter Stuge from
Date: Thu, 30 Aug 2007 00:06:50 +0200
Message-ID: 20070829220650.9669.qmail@stuge.se
Regards, Carl-Daniel
* Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net [071129 14:32]:
Alex, can you repost an updated patch? I want to verify that patch against a suggestion of Peter Stuge from
Date: Thu, 30 Aug 2007 00:06:50 +0200
Message-ID: 20070829220650.9669.qmail@stuge.se
What is that suggestion?
On Thu, Nov 29, 2007 at 05:41:52PM +0100, Stefan Reinauer wrote:
Alex, can you repost an updated patch? I want to verify that patch against a suggestion of Peter Stuge from
Date: Thu, 30 Aug 2007 00:06:50 +0200
Message-ID: 20070829220650.9669.qmail@stuge.se
What is that suggestion?
http://marc.info/?l=linuxbios&m=118842524813075&w=2
Feature flags.
//Peter
On 29.11.2007 18:13, Peter Stuge wrote:
On Thu, Nov 29, 2007 at 05:41:52PM +0100, Stefan Reinauer wrote:
Alex, can you repost an updated patch? I want to verify that patch against a suggestion of Peter Stuge from
Date: Thu, 30 Aug 2007 00:06:50 +0200
Message-ID: 20070829220650.9669.qmail@stuge.se
What is that suggestion?
http://marc.info/?l=linuxbios&m=118842524813075&w=2
Feature flags.
Together with reserving space at the end of the header. I think especially the space reservation is important because it allows use of feature flags without having to horrible re-definition/out-of-place-information hacks.
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
Together with reserving space at the end of the header. I think especially the space reservation is important because it allows use of feature flags without having to horrible re-definition/out-of-place-information hacks.
Space reservation? What is this about?
On 30.11.2007 00:43, Stefan Reinauer wrote:
Carl-Daniel Hailfinger wrote:
Together with reserving space at the end of the header. I think especially the space reservation is important because it allows use of feature flags without having to horrible re-definition/out-of-place-information hacks.
Space reservation? What is this about?
That way we can introduce new header fields and still have old LAR code parse new archives without any problems. Together with feature flags, we can have future LAR utility versions generate archives which are still readable by old LAR library versions. I can come up with an example if you need one.
Regards, Carl-Daniel
* Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net [071130 01:19]:
That way we can introduce new header fields and still have old LAR code parse new archives without any problems.
What about just adding a field with the header size for that. Adding space for empty "reserved fields" just smells like a broken concept.
Stefan
On Fri, Nov 30, 2007 at 12:43:51AM +0100, Stefan Reinauer wrote:
Together with reserving space at the end of the header.
Space reservation? What is this about?
Some extra bytes for future use, the more bytes the longer before we need to change the format. I think 64 would be more than enough. No-one will ever need more than 64 bytes.
//Peter
* Peter Stuge peter@stuge.se [071130 01:25]:
On Fri, Nov 30, 2007 at 12:43:51AM +0100, Stefan Reinauer wrote:
Together with reserving space at the end of the header.
Space reservation? What is this about?
Some extra bytes for future use, the more bytes the longer before we need to change the format. I think 64 would be more than enough. No-one will ever need more than 64 bytes.
I disagree. If we start using unused bytes, we changed the format already. There are clean ways that do not require "padding" to stay compatible. If we add a field "header size" we know how many bytes we have to skip without the need to know how to parse all of the header.
Please don't add reserved fields. thats really ugly and lack of design.
On Fri, Nov 30, 2007 at 02:55:30AM +0100, Stefan Reinauer wrote:
Space reservation? What is this about?
No-one will ever need more than 64 bytes.
If we add a field "header size" we know how many bytes we have to skip without the need to know how to parse all of the header.
Yep, this is good.
Please don't add reserved fields. thats really ugly and lack of design.
Fair enough.
//Peter
On 30.11.2007 02:55, Stefan Reinauer wrote:
- Peter Stuge peter@stuge.se [071130 01:25]:
On Fri, Nov 30, 2007 at 12:43:51AM +0100, Stefan Reinauer wrote:
Together with reserving space at the end of the header.
Space reservation? What is this about?
Some extra bytes for future use, the more bytes the longer before we need to change the format. I think 64 would be more than enough. No-one will ever need more than 64 bytes.
I disagree. If we start using unused bytes, we changed the format already. There are clean ways that do not require "padding" to stay compatible. If we add a field "header size" we know how many bytes we have to skip without the need to know how to parse all of the header.
The field "header size" needs space. That space could be used in a future version for something real if we reserved it.
Please don't add reserved fields. thats really ugly and lack of design.
Design is always in the eye of the beholder.
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
On 30.11.2007 02:55, Stefan Reinauer wrote:
- Peter Stuge peter@stuge.se [071130 01:25]:
On Fri, Nov 30, 2007 at 12:43:51AM +0100, Stefan Reinauer wrote:
Together with reserving space at the end of the header.
Space reservation? What is this about?
Some extra bytes for future use, the more bytes the longer before we need to change the format. I think 64 would be more than enough. No-one will ever need more than 64 bytes.
I disagree. If we start using unused bytes, we changed the format already. There are clean ways that do not require "padding" to stay compatible. If we add a field "header size" we know how many bytes we have to skip without the need to know how to parse all of the header.
The field "header size" needs space. That space could be used in a future version for something real if we reserved it.
reserving space does not solve a real problem. It just adds another static dependency and makes the code more fragile.
Postponing the problem is a bad solution. Especially if you want to argue for 2-4 bytes while wasting them in a "reserved" field.
Please don't add reserved fields. thats really ugly and lack of design.
Design is always in the eye of the beholder.
Not in this case, sorry.
On 30.11.2007 22:59, Stefan Reinauer wrote:
Carl-Daniel Hailfinger wrote:
On 30.11.2007 02:55, Stefan Reinauer wrote:
I disagree. If we start using unused bytes, we changed the format already. There are clean ways that do not require "padding" to stay compatible. If we add a field "header size" we know how many bytes we have to skip without the need to know how to parse all of the header.
The field "header size" needs space. That space could be used in a future version for something real if we reserved it.
reserving space does not solve a real problem. It just adds another static dependency and makes the code more fragile.
Postponing the problem is a bad solution. Especially if you want to argue for 2-4 bytes while wasting them in a "reserved" field.
OK, can we then agree on a good solution? Where do we want to add the header size field and where do we want to add the flags field without breaking alignment? 8 bits for header size, 24 bits for flags?
Regards, Carl-Daniel
-
Alex Beregszaszi -
Carl-Daniel Hailfinger -
Jordan Crouse -
Peter Stuge -
ron minnich -
Stefan Reinauer -
Uwe Hermann