[microblaze-uclinux] Re: Patch for CRAMFS rootfs

[John Williams <john.williams@xxxxxxxxxxxxx>]

Hi Steve,

> Both arch/microblaze/kernel/setup.c and drivers/mtd/maps/uclinux.c need
> the ability to determine the length of the root filesystem. I think the
> best solution locates the code to do this in uclinux.c, where it would be
> available to architectures (such as microblaze) that need it, rather than
> having each architecture replicate the code.
>
> I would be surprised if a patch to uclinux.c coming from me would make it
> into 2.6.30 at this stage of the cycle. So I propose doing this in 3
> parts:

Maybe, although making existing code endian-safe is hardly a new
feature, you could argue it's a pretty unobtrusive and necessary thing
to do.

> 1. Patch the existing code in arch/microblaze/kernel/setup.c. This would
> make that code correct, but not useful, because changes to uclinux.c (and
> arch/microblaze/mm/init.c) are also needed in order to boot a Petalinux-
> style cramfs.
>
> 2. Submit a patch to uclinux.c that ports a modified version of the
> get_romfs_len() function in the Petalinux variant of the kernel. I
> believe this would go to David Woodhouse.

The issue as I see it is that it would require a subsystem driver (or
indeed, a sub-subsystem driver) to export a symbol into the global
kernel namespace.

That is, somewhere we'd need a header file that declares this
get_romfs_len() function, which is then defined in uclinux.c

I think that will raise objections, and probably rightly so.  If any
subsystem should be exporting such a function, it should be the
filesystem itself, not some hacky MTD driver.

To get to mainline with this sort of thing we maybe have to stay under
the radar and just have the seperate implementations of get_romfs_len,
one in the arch code and one in the MTD driver, or look to some more
generic and useful way of exporting it from the filesystem layer
itself.  This may be more trouble than it's worth, as any
get_XXX_len() hook would have to push all the way up from the
individual FS implementations and through the VFS (I think?)

> I believe the word "hack" was used at one point in our recent cramfs
> discussion...if (2) is likely to re-ignite some religious war between
> uCLinux folks and the rest of the kernel community, I'd rather not waste
> my time attempting it.

See my comment above :)

Maybe instead of second-guessing the LKML response, you can just put
it out there and see what comes back?  Who knows, maybe there's an
elegant solution that we've missed?

John
-- 
John Williams, PhD, B.Eng, B.IT
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com  p: +61-7-30090663  f: +61-7-30090663
___________________________
microblaze-uclinux mailing list
microblaze-uclinux@xxxxxxxxxxxxxx
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/