EXT4
PATCH 1/1 EXT4
Slowly getting the hang of github and u-boot. I took a fork of u-boot 20120520, and merged in the EXT4 patched.
In addition to Samsung's work;
* Fix minor string ext2->ext4
* 'unsigned' sectors for volumes over 1TB
* changed to fit with current u-boot compile env
https://github.com/lundman/u-boot/compare/upstream...upstream-ext4
There is a new limit of 2TB with 512 byte blocks. To go beyond that would require "disk_partition_t" to go bigger than 32bit. I think that is outside of my access permissions.
Signature · 4 lines
Jorgen Lundman | <[email protected]> Unix Administrator | +81 (0)3 -5456-2687 ext 1017 (work) Shibuya-ku, Tokyo | +81 (0)90-5578-8500 (cell) Japan | +81 (0)3 -3375-1767 (home)
PATCH 1/1 EXT4
Hi Jorgen
Quoted 11 lines · Jorgen Lundman
Slowly getting the hang of github and u-boot. I took a fork of u-boot 20120520, and merged in the EXT4 patched.
In addition to Samsung's work;
?* Fix minor string
ext2->ext4
?* 'unsigned' sectors for volumes over 1TB
?* changed to fit with current u-boot compile envhttps://github.com/lundman/u-boot/compare/upstream...upstream-ext4
These patches will likely not get reviewed and definitely will not get merged unless that are posted to the mailing list
Quoted 3 lines
There is a new limit of 2TB with 512 byte blocks. To go beyond that would require "
disk_partition_t" to go bigger than 32bit. I think that is outside of my access permissions.
What do you mean by this?
Regards,
Graeme
PATCH 1/1 EXT4
Quoted 2 lines
These patches will likely not get reviewed and definitely will not get merged unless that are posted to the mailing list
Ok, is it better if I use "git format-patch" and send them on the list?
Quoted 7 lines
Quoted 4 lines
There is a new limit of 2TB with 512 byte blocks. To go beyond that would require "
disk_partition_t" to go bigger than 32bit. I think that is outside of my access permissions.What do you mean by this?
I just assumed that I, new to the use of u-boot, should not tinker with core structs, and core API functionality. I merely wish to mention the issue in case it has already been addressed by the gurus.
It could very well be that u-boot developers don't want to go larger. (presumably, majority of u-boot devices aren't booting from > 2TB devices..)
Or, it has already been discussed and I just missed it.
Signature · 4 lines
Jorgen Lundman | <[email protected]> Unix Administrator | +81 (0)3 -5456-2687 ext 1017 (work) Shibuya-ku, Tokyo | +81 (0)90-5578-8500 (cell) Japan | +81 (0)3 -3375-1767 (home)
PATCH 1/1 EXT4
Hi Jorgen,
Quoted 5 lines · Jorgen Lundman
Quoted 2 lines
These patches will likely not get reviewed and definitely will not get merged unless that are posted to the mailing list
Ok, is it better if I use "git format-patch" and send them on the list?
Yes, that is exactly what you should do.
But before you post them, make sure you run them through checkpatch.pl first and resolve/explain any errors or warnings
Quoted 6 lines
Quoted 6 lines
Quoted 4 lines
There is a new limit of 2TB with 512 byte blocks. To go beyond that would require "
disk_partition_t" to go bigger than 32bit. I think that is outside
of my access permissions.
Quoted 6 lines
Quoted 2 lines
What do you mean by this?
I just assumed that I, new to the use of u-boot, should not tinker with core structs, and core API functionality. I merely wish to mention the issue in case it has already been addressed by the gurus.
Anyone can post patches to the mailing list that tinker with core structs, APIs, functionality etc. There are no 'permission' levels here :)
Whatever you post will get reviewed by the community at large and if the feeling is that you proposed 'tinkering' is not suitable for inclusion in U-Boot then comments to that effect will be made. You will then have the opportunity to either a) argue your position or b) submit revised patches which address the comments made
Quoted 2 lines
It could very well be that u-boot developers don't want to go larger. (presumably, majority of u-boot devices aren't booting from > 2TB devices..)
Well you could port U-Boot to a NAS with >> 2TB storage :)
Quoted 1 line
Or, it has already been discussed and I just missed it.
Not that I am aware
Regards,
Graeme
PATCH 1/1 EXT4
Quoted 4 lines
Yes, that is exactly what you should do.
But before you post them, make sure you run them through checkpatch.pl first and resolve/explain any errors or warnings
Wow, ohhweee this will take a little while.
How set in stone is the output of checkpatch.pl ? Specifically;
ERROR: do not initialise globals to 0 or NULL
#596: FILE: fs/zfs/zfs.c:33:
+block_dev_desc_t *zfs_dev_desc = NULL;
That strikes me as dangerous. One lets you fail gracefully (Sorry, X has not been initialised) and the other is just a plain crash. I find crashes to be very ugly, even if it is only reachable by other developers.
WARNING: do not add new typedefs
#728: FILE: fs/zfs/zfs.c:165:
+typedef struct decomp_entry
I'm seriously not allowed to make new typedefs? ouch.
So yeah, should it always pass without a single problem, or may I employ some measure of moderation?
Signature · 4 lines
Jorgen Lundman | <[email protected]> Unix Administrator | +81 (0)3 -5456-2687 ext 1017 (work) Shibuya-ku, Tokyo | +81 (0)90-5578-8500 (cell) Japan | +81 (0)3 -3375-1767 (home)
PATCH 1/1 EXT4
Quoted 10 lines · Jorgen Lundman
ERROR: do not initialise globals to 0 or NULL
#596: FILE:fs/zfs/zfs.c:33:
+block_dev_desc_t*zfs_dev_desc= NULL;That strikes me as dangerous. One lets you fail gracefully (Sorry, X has not been initialised) and the other is just a plain crash. I find crashes to be very ugly, even if it is only reachable by other developers.
Globals are per se initialised to 0,
so there is no need to explicitly initialise them.
As a consequence, it is neither dangerous to omit the initialisation.
Stefan
PATCH 1/1 EXT4
In reply to Jorgen LundmanHi Jorgen,
Quoted 10 lines · Jorgen Lundman
Quoted 4 lines
Yes, that is exactly what you should do.
But before you post them, make sure you run them through checkpatch.pl first and resolve/explain any errors or warnings
Wow, ohhweee this will take a little while.
How set in stone is the output of checkpatch.pl ? Specifically;
Quoted 7 lines
ERROR: do not initialise globals to 0 or NULL
#596: FILE:fs/zfs/zfs.c:33:
+block_dev_desc_t*zfs_dev_desc= NULL;That strikes me as dangerous. One lets you fail gracefully (Sorry, X has not been initialised) and the other is just a plain crash. I find crashes to be very ugly, even if it is only reachable by other developers.
Uninitialized global and static variables reside in .bss and are set to zero during relocation. Initialised globals and static variables go into .data
Does a global/static initialised to zero belong in .bss or .data?
By not initialising them, the compiler/linker is forced into putting them into .bss where they are guaranteed to be zero when first accessed
Quoted 5 lines
WARNING: do not add new typedefs
#728: FILE:fs/zfs/zfs.c:165:
+typedef structdecomp_entryI'm seriously not allowed to make new typedefs? ouch.
If the code is copied verbatim from an existing external repository, the rules can be relaxed - Just make sure you provide a clear and concise reference (like a git commit ID or tag)
Oh and remember, just because you can find a prior art in the U-Boot code does not mean it will be allowed to be used as a backing argument ;)
Quoted 2 lines
So yeah, should it always pass without a single problem, or may I employ some measure of moderation?
Only one way to find out ;) But try to make it as clean as you believe reasonable and explain what's left
Regards,
Graeme
PATCH 1/1 EXT4
Quoted 5 lines
Uninitialized global and static variables reside in .bss and are set to zero during relocation. Initialised globals and static variables go into .data
Alas, I know from experience that Microsoft's C compiler does not initialise global variables (to make it faster one assumes) which has led to hours of debugging.
If u-boot has decided that going without Microsoft compiling support is A-OK, then that is A-OK with me too. :)
Quoted 3 lines
Oh and remember, just because you can find a prior art in the U-Boot code does not mean it will be allowed to be used as a backing argument ;)
This I understand. Even if what came in from legacy has yet to be cleaned, there is no reason to allow more filth in :)
Quoted 4 lines
Only one way to find out ;) But try to make it as clean as you believe reasonable and explain what's left
Understood, clean enough to eat of is the goal.
Lund
Signature · 4 lines
Jorgen Lundman | <[email protected]> Unix Administrator | +81 (0)3 -5456-2687 ext 1017 (work) Shibuya-ku, Tokyo | +81 (0)90-5578-8500 (cell) Japan | +81 (0)3 -3375-1767 (home)
PATCH 1/1 EXT4
Hi Jorgen,
Quoted 10 lines · Jorgen Lundman
Quoted 5 lines
Uninitialized global and static variables reside in .bss and are set to zero during relocation. Initialised globals and static variables go into .data
Alas, I know from experience that Microsoft's C compiler does not initialise global variables (to make it faster one assumes) which has led to hours of debugging.
Well actually, it's not the compiler/linker that initialised .bss - it's the dynamic loader. In the case of U-Boot, it's the Flash->RAM relocation code.
Quoted 2 lines
If u-boot has decided that going without Microsoft compiling support is A-OK, then that is A-OK with me too. :)
I don't know of anyone that has even tried, let alone succeeded in compiling U-Boot with a Microsoft compiler. I've heard of cygwin attempts (that from memory have also failed miserably)
Generally speaking, gnu based tools are your best bet. Speaking of which, we really should have a list of 'supported tools' which are known to successfully build U-Boot...
Regards,
Graeme
PATCH 1/1 EXT4
In reply to Jorgen LundmanDear Jorgen Lundman,
Quoted 4 lines · In message <[email protected]> you wrote:
Alas, I know from experience that Microsoft's C compiler does not initialise global variables (to make it faster one assumes) which has led to hours of debugging.
That would be a violation of existing C standards.
Quoted 2 lines
If u-boot has decided that going without Microsoft compiling support is A-OK, then that is A-OK with me too. :)
We really don't care about broken, standard-violating crap.
Best regards,
Wolfgang Denk
Signature · 5 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Honest error is to be pitied, not ridiculed.
-- Philip Earl of ChesterfieldPATCH 1/1 EXT4
In reply to Jorgen LundmanDear Jorgen Lundman,
Quoted 4 lines · In message <[email protected]> you wrote:
Quoted 2 lines
These patches will likely not get reviewed and definitely will not get merged unless that are posted to the mailing list
Ok, is it better if I use "git format-patch" and send them on the list?
Please read the docs. Start at http://www.denx.de/wiki/U-Boot/Patches
Best regards,
Wolfgang Denk
Signature · 5 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de "Out of register space (ugh)" - vi