lkml.org 
[lkml]   [2011]   [Apr]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: linux-next: Tree for April 1 [BROKEN ubifs when CONFIG_DEBUG_SECTION_MISMATCH=y]s
From
On Mon, Apr 4, 2011 at 12:47 AM, Jens Axboe <jaxboe@fusionio.com> wrote:
> On 2011-04-04 00:38, Sedat Dilek wrote:
>> On Mon, Apr 4, 2011 at 12:36 AM, Jens Axboe <jaxboe@fusionio.com> wrote:
>>> On 2011-04-04 00:33, Sedat Dilek wrote:
>>>> On Mon, Apr 4, 2011 at 12:21 AM, Jens Axboe <jaxboe@fusionio.com> wrote:
>>>>> On 2011-04-04 00:19, Sedat Dilek wrote:
>>>>>> On Mon, Apr 4, 2011 at 12:16 AM, Jens Axboe <jaxboe@fusionio.com> wrote:
>>>>>>> On 2011-04-02 13:02, Sedat Dilek wrote:
>>>>>>>> On Sat, Apr 2, 2011 at 12:14 PM, Sedat Dilek <sedat.dilek@googlemail.com> wrote:
>>>>>>>>> On Sat, Apr 2, 2011 at 2:20 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>>>>>>>>> cc'ing Jens ...
>>>>>>>>>>
>>>>>>>>>> On Fri, 1 Apr 2011 20:22:41 +0200 Sedat Dilek <sedat.dilek@googlemail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Apr 1, 2011 at 7:02 PM, Artem Bityutskiy <dedekind1@gmail.com> wrote:
>>>>>>>>>>>> On Fri, 2011-04-01 at 18:10 +0200, Sedat Dilek wrote:
>>>>>>>>>>>>> On Fri, Apr 1, 2011 at 6:06 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>>>>>>>>>>>>> Cc'ing Artem,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Fri, 1 Apr 2011 17:55:52 +0200 Sedat Dilek <sedat.dilek@googlemail.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> With CONFIG_DEBUG_SECTION_MISMATCH=y set, I see in my build.log:
>>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>> MODPOST 2742 modules
>>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>> ERROR: "empty_aops" [fs/ubifs/ubifs.ko] undefined!
>>>>>>>>>>>>>>> make[5]: *** [__modpost] Error 1
>>>>>>>>>>>>>>> make[4]: *** [modules] Error 2
>>>>>>>>>>>>>>> make[3]: *** [sub-make] Error 2
>>>>>>>>>>>>>>> make[2]: *** [all] Error 2
>>>>>>>>>>>>>>> make[2]: Leaving directory
>>>>>>>>>>>>>>> `/home/sd/src/linux-2.6/linux-2.6.39-rc1/debian/build/build_i386_none_686-iniza'
>>>>>>>>>>>>>>>
>>>>>>>> [...]
>>>>>>>>> Just FYI:
>>>>>>>>> I contacted Jens last night and he refreshed his for-linus GIT branch.
>>>>>>>>> Adding missing include <linux/fs.h> did not fix the issue.
>>>>>>>>> I am trying with the attached one.
>>>>>>>>>
>>>>>>>>> - Sedat -
>>>>>>>>>
>>>>>>>>
>>>>>>>> I have split the single patch into two, first reflects ther build-error.
>>>>>>>> The second considers {inode,file}_operations have also undefined
>>>>>>>> functions by using "unified" empty_{iops,fops} as used in other fs/*
>>>>>>>> files.
>>>>>>>
>>>>>>> What are these patches against? Not for-next nor my for-linus.
>>>>>>>
>>>>>>
>>>>>> I tested with linux-next (next-20110401) as base and pulled-in your
>>>>>> for-linus GIT branch.
>>>>>
>>>>> Then perhaps there was some merge error. There's no empty_aops defined
>>>>> in my tree in nilfs_mapping_init(), for instance.
>>>>>
>>>>> Are you using an old for-linus?
>>>>>
>>>>
>>>> I dropped the idea of exporting empty_aops via include/linux/fs.h (&
>>>> changes in fs/inode.c) as it did not work as intended.
>>>> As an alternative I used empty_{aops,iops,fops} only in
>>>> fs/nilfs2/page.c and fs/ubifs/xattr.c where it is only needed (for
>>>> example for aops: static const struct address_space_operations
>>>> empty_aops {}; etc.)
>>>
>>> I'm asking one thing, you are replying with something else. The patches
>>> you sent do NOT apply to for-linus.
>>>
>>
>> Oh, I am sorry. I checkout your tree and adapt.
>
> I believe that you need is this, plain and simple.
>
> diff --git a/fs/inode.c b/fs/inode.c
> index b818730..33c963d 100644
> --- a/fs/inode.c
> +++ b/fs/inode.c
> @@ -130,6 +130,7 @@ static DECLARE_RWSEM(iprune_sem);
>  */
>  const struct address_space_operations empty_aops = {
>  };
> +EXPORT_SYMBOL(empty_aops);
>
>  /*
>  * Statistics gathering..
>

As you like....
To have a unified variable nomenclature/usage I would like to see in
fs/ubifs/xattr.c:
s/none_inode_operations/empty_iops
s/none_file_operations/empty_fops

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

\
 
 \ /
  Last update: 2011-04-04 01:17    [W:0.034 / U:0.212 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site