On Monday 27 June 2011, 18:16:21 sf...@users.sourceforge.net wrote:
> "Hans-Peter Jansen":
> > The patch didn't apply cleanly to aufs2-31 (standalone), but I
> > applied the attached patch (build service refuses to apply patches
> > with fuzz). Build is triggered.
> >
> > Unfortunately, it bails out with:
> >
> > usr/src/packages/BUILD/aufs2-standalone.tree-31-20100823/obj/defaul
> >t/fs/aufs/f_op.c: In function 'aufs_mmap':
> > /usr/src/packages/BUILD/aufs2-standalone.tree-31-20100823/obj/defau
> >lt/fs/aufs/f_op.c:671: error: implicit declaration of function
> > 'xip_file_mmap'
> >
> > I wasn't able to locate the xip_file_mmap function anywhere in the
> > source. Probably it's introduced in a later version?
>
> The function should exist in mm/filemap_xip.c, and its declartion is
> in include/linux/fs.h.
> But the function is available when CONFIG_FS_XIP is enabled. So the
> patch should be like this.
>
> > - err = generic_file_mmap(file, vma);
>
> #ifdef CONFIG_FS_XIP
>
> > + if (!file->f_mapping->a_ops->get_xip_mem)
> > + err = generic_file_mmap(file, vma);
> > + else
> > + err = xip_file_mmap(file, vma);
> > + AuTraceErr(err);
>
> #else
> err = generic_file_mmap(file, vma);
> #endif
Okay, done that now. Given that CONFIG_FS_XIP isn't enabled, which would
render this patch rather useless, I reconfigured the kernel with
CONFIG_FS_XIP enabled (for the desktop flavor only).
Unfortunately, this results in a crash on boot:
ftp://urpla.net/resized_img_1349.jpg
After reverting your last patch, the system boots again. Do you think,
that the first hunk is important enough to do one more test with
CONFIG_FS_XIP disabled again?
Pete
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
