Re: Newbie Question -- error: implicit declaration of function 'iget'

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Nov 27, 2008 at 12:03:32PM +0800, Qingye Jiang (John) wrote:
> I have finished the day1 example, and get stuck at the day2 example.
> When compiling the day2 example, I get the following error message:
> 
> qyjohn@qyjohn-laptop:/usr/src/linux-source-2.6.27$ sudo make
> M=~/samplefs/day2
> [sudo] password for qyjohn:
> CC [M] /home/qyjohn/samplefs/day2/super.o
> /home/qyjohn/samplefs/day2/super.c: In function 'samplefs_fill_super':
> /home/qyjohn/samplefs/day2/super.c:112: error: implicit declaration of
> function 'iget'
> /home/qyjohn/samplefs/day2/super.c:112: warning: assignment makes
> pointer from integer without a cast
> make[1]: *** [/home/qyjohn/samplefs/day2/super.o] Error 1
> make: *** [_module_/home/qyjohn/samplefs/day2] Error 2
> 
> I looked at linux/fs.h, and found that the declaration of the __iget()
> function is different from what is being used in super.c.

To find the answer, I used git-log include/linux/fs.h and searched for
'iget'.  I found this commit:

commit 12debc4248a4a7f1873e47cda2cdd7faca80b099
Author: David Howells <dhowells@xxxxxxxxxx>
Date:   Thu Feb 7 00:15:52 2008 -0800

    iget: remove iget() and the read_inode() super op as being obsolete
    
    Remove the old iget() call and the read_inode() superblock operation it uses
    as these are really obsolete, and the use of read_inode() does not produce
    proper error handling (no distinction between ENOMEM and EIO when marking an
    inode bad).
    
    Furthermore, this removes the temptation to use iget() to find an inode by
    number in a filesystem from code outside that filesystem.
    
    iget_locked() should be used instead.  A new function is added in an earlier
    patch (iget_failed) that is to be called to mark an inode as bad, unlock it
    and release it should the get routine fail.  Mark iget() and read_inode() as
    being obsolete and remove references to them from the documentation.
    
    Typically a filesystem will be modified such that the read_inode function
    becomes an internal iget function, for example the following:
    
        void thingyfs_read_inode(struct inode *inode)
        {
                ...
        }
    
    would be changed into something like:
    
        struct inode *thingyfs_iget(struct super_block *sp, unsigned long ino)
        {
                struct inode *inode;
                int ret;
    
                inode = iget_locked(sb, ino);
                if (!inode)
                        return ERR_PTR(-ENOMEM);
                if (!(inode->i_state & I_NEW))
                        return inode;
    
                ...
                unlock_new_inode(inode);
                return inode;
        error:
                iget_failed(inode);
                return ERR_PTR(ret);
        }
    
    and then thingyfs_iget() would be called rather than iget(), for example:
    
        ret = -EINVAL;
        inode = iget(sb, ino);
        if (!inode || is_bad_inode(inode))
                goto error;
    
    becomes:
    
        inode = thingyfs_iget(sb, ino);
        if (IS_ERR(inode)) {
                ret = PTR_ERR(inode);
                goto error;
        }
    
    Note that is_bad_inode() does not need to be called.  The error returned by
    thingyfs_iget() should render it unnecessary.
    
    Signed-off-by: David Howells <dhowells@xxxxxxxxxx>
    Acked-by: Christoph Hellwig <hch@xxxxxx>
    Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
    Signed-off-by: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>


I think this should answer your question, and help you find the answer
to questions like this in the future.

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux