On Mon, Apr 27, 2009 at 7:22 AM, Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote:
I am not sure how to proceed here. My main purpose in providing this patch was to get the msp71xx platform compiling again, but I stumbled into some pre-existing code ugliness, which I must confess I was ultimately responsible for.
As Geert said, I need to reach deep into the squashfs internals to access the bytes_used field of struct squashfs_super_block; the code just previous to this line works similar for the cramfs filesystem, where it accesses the size field of the struct cramfs_super field. The cramfs code doesn't look as bad, because its superblock structure is defined in an easier-to-access file (linux/cramfs_fs.h).
I can see a number of possible paths here:
1. Fix up the existing patch with le{32,64}_to_cpu() as Geert suggested, and leave everything else as-is.
2. Approach the squashfs maintainers to move the squashfs_fs.h file to a more public location, and still do 1.
3. Pull the squashfs code entirely.
4. Remove the entire get_ramroot() code, both squashfs and cramfs, as Christoph has suggested. I am hesitant to do this as it also affects code in the MTD subsystem (file maps/pmcmsp-ramroot.c), and it also loses some functionality on the PMC boards (putting the rootfs in RAM immediately following the kernel). Perhaps there's a better way to handle this?
I am open to suggestions on how to proceed.
Shane
He needs the definition of struct squashfs_super_block to access the .bytes_usedOn Mon, Apr 27, 2009 at 15:09, Ralf Baechle <ralf@xxxxxxxxxxxxxx> wrote:
> On Mon, Apr 27, 2009 at 06:59:17AM -0600, Shane McDonald wrote:
>
>> There have been a number of compile problems with the msp71xx
>> configuration ever since it was included in the linux-mips.org
>> repository. This patch resolves these problems:
>> - proper files are included when using a squashfs rootfs
>> - resetting the board no longer uses non-existent GPIO routines
>> - create the required plat_timer_setup function
>>
>> This patch has been compile-tested against the current HEAD.
>>
>> Signed-off-by: Shane McDonald <mcdonald.shane@xxxxxxxxx>
>> ---
>> arch/mips/pmc-sierra/msp71xx/msp_prom.c | 3 ++-
>> arch/mips/pmc-sierra/msp71xx/msp_setup.c | 8 ++------
>> arch/mips/pmc-sierra/msp71xx/msp_time.c | 7 ++-----
>> 3 files changed, 6 insertions(+), 12 deletions(-)
>>
>> diff --git a/arch/mips/pmc-sierra/msp71xx/msp_prom.c b/arch/mips/pmc-sierra/msp71xx/msp_prom.c
>> index e5bd548..1e2d984 100644
>> --- a/arch/mips/pmc-sierra/msp71xx/msp_prom.c
>> +++ b/arch/mips/pmc-sierra/msp71xx/msp_prom.c
>> @@ -44,7 +44,8 @@
>> #include <linux/cramfs_fs.h>
>> #endif
>> #ifdef CONFIG_SQUASHFS
>> -#include <linux/squashfs_fs.h>
>> +#include <linux/magic.h>
>> +#include "../../../../fs/squashfs/squashfs_fs.h"
>
> No way. You're reaching deep into the internals of squashfs for no good
> reason. The only use of anything from squashfs_fs.h is a cast and casting
> to void * would work just as well.
field. Alternatively, the offset of that field must be hardcoded.
BTW, the magic is __le32, and bytes_used is __le64, so there are some
le{32,64}_to_cpu()
missing.
I am not sure how to proceed here. My main purpose in providing this patch was to get the msp71xx platform compiling again, but I stumbled into some pre-existing code ugliness, which I must confess I was ultimately responsible for.
As Geert said, I need to reach deep into the squashfs internals to access the bytes_used field of struct squashfs_super_block; the code just previous to this line works similar for the cramfs filesystem, where it accesses the size field of the struct cramfs_super field. The cramfs code doesn't look as bad, because its superblock structure is defined in an easier-to-access file (linux/cramfs_fs.h).
I can see a number of possible paths here:
1. Fix up the existing patch with le{32,64}_to_cpu() as Geert suggested, and leave everything else as-is.
2. Approach the squashfs maintainers to move the squashfs_fs.h file to a more public location, and still do 1.
3. Pull the squashfs code entirely.
4. Remove the entire get_ramroot() code, both squashfs and cramfs, as Christoph has suggested. I am hesitant to do this as it also affects code in the MTD subsystem (file maps/pmcmsp-ramroot.c), and it also loses some functionality on the PMC boards (putting the rootfs in RAM immediately following the kernel). Perhaps there's a better way to handle this?
I am open to suggestions on how to proceed.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Shane
