From: Matthew Wilcox <matthew@wil.cx>
To: "Qingye Jiang (John)" <John.Jiang@Sun.COM>
Cc: linux-fsdevel@vger.kernel.org
Subject: Re: Newbie Question -- error: implicit declaration of function 'iget'
Date: Thu, 27 Nov 2008 05:18:11 -0700 [thread overview]
Message-ID: <20081127121811.GK25548@parisc-linux.org> (raw)
In-Reply-To: <492E1C14.2000509@Sun.Com>
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@redhat.com>
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@redhat.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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."
prev parent reply other threads:[~2008-11-27 12:18 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-27 4:03 Newbie Question -- error: implicit declaration of function 'iget' Qingye Jiang (John)
2008-11-27 12:18 ` Matthew Wilcox [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20081127121811.GK25548@parisc-linux.org \
--to=matthew@wil.cx \
--cc=John.Jiang@Sun.COM \
--cc=linux-fsdevel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).