On Tue, Apr 28, 2009 at 08:21, Shane McDonald <mcdonald.shane@xxxxxxxxx> wrote:
> On Mon, Apr 27, 2009 at 7:22 AM, Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
>> On 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.
>>
>> He needs the definition of struct squashfs_super_block to access the
>> .bytes_used
>> 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.
The only reason you need to know about the file system internals is to
find out the
size of the appended file system, right?
The way other platforms solve this is by e.g. letting the bootloader
pass the location
and size of the ramdisk to the kernel. This is file system agnostic.
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
