Re: [PATCH] add romfs_get_size()

[Yasushi SHOJI]

Hi Greg,

At Thu, 08 Sep 2005 17:07:42 +1000,
Greg Ungerer wrote:
> 
> Yasushi SHOJI wrote:
> > At Wed, 7 Sep 2005 16:04:39 +0100,
> > Christoph Hellwig wrote:
> > 
> >>On Wed, Sep 07, 2005 at 11:31:36PM +0900, Yasushi SHOJI wrote:
> >>
> >>>>On Wed, Sep 07, 2005 at 11:22:19PM +0900, Yasushi SHOJI wrote:
> >>>>
> >>>>>Many embedded linux products have been using romfs and it's still
> >>>>>growing.  most, if not all, of them implement thier own way to check
> >>>>>its romfs size.
> >>>>>
> >>>>>this patch provides this commonly used function.
> >>>>
> >>>>Used where.  Please come back as soon as you have a caller in-tree
> >>>>which makes sense..
> >>>
> >>>i don't know this one make sense but the biggest user is uclinux mtd
> >>>map. in uclinux_mtd_init():
> >>
> >>I don't quite see the corelation.  Anyway, please submit a patch series
> >>that converts whatever wrong variant to the new one, describing each
> >>patch in detail, and adding proper ROMFS depencies to the places using
> >>it.
> > 
> > 
> > I don't have most of platform to test. sure it's easy to just convert
> > them using romfs_get_size() but I don't wanna submit any patch that I
> > can't test.
> > 
> > So, if the patch is not that bad, it'd be much easier to just tell all
> > platform maintainer that the infra. is in place and they can start
> > converting their code to use new function.
> > 
> > Anyway I just converted uclinux.c to use romfs_get_size(). Greg, would
> > you kindly comment on the attached patch?
> 
> I don't see any problem with it.

great.

> The uclinux.c code as it stands is probably a little sloppy.
> It doesn't do any checks for a valid ROMfs first - it should at
> least check the magic number.

Yeah that's right. At least with romfs_get_size(), we can check the
return val to see it ok or not. it might be better if we have

    mapp->size = PAGE_ALIGN(romfs_get_size((struct romfs_super_block *)&_ebss));
    if (mapp->size != -1)

kind of code. what we can do once we detected mismatched magic number
is deferment story, though. ;)

regards,
--
         yashi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/