[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.61.0609041832010.28823@yvahk01.tjqt.qr>
Date: Mon, 4 Sep 2006 18:35:41 +0200 (MEST)
From: Jan Engelhardt <jengelh@...ux01.gwdg.de>
To: Steven Whitehouse <swhiteho@...hat.com>
cc: linux-kernel@...r.kernel.org,
Russell Cattelan <cattelan@...hat.com>,
David Teigland <teigland@...hat.com>,
Ingo Molnar <mingo@...e.hu>, hch@...radead.org
Subject: Re: [PATCH 06/16] GFS2: dentry, export, super and vm operations
>> >+ switch (fh_type) {
>> >+ case 10:
>> >+ parent.no_formal_ino = ((uint64_t)be32_to_cpu(fh[4])) << 32;
>> >+ parent.no_formal_ino |= be32_to_cpu(fh[5]);
>> >+ parent.no_addr = ((uint64_t)be32_to_cpu(fh[6])) << 32;
>> >+ parent.no_addr |= be32_to_cpu(fh[7]);
>> >+ fh_obj.imode = be32_to_cpu(fh[8]);
>> >+ case 4:
>>
>> What do these constants specify? Would not it be better to have a #define or
>> enum{} for them somewhere?
>
>The sizes of the NFS file handles in units of sizeof(u32). I've added a
>couple of #defines as requested.
A #define/enum is only really useful if more than one place references it.
If this is the only one, just add a comment.
>> >+ if (IS_ERR(inode))
>> >+ return ERR_PTR(PTR_ERR(inode));
>>
>> Just return inode.
>
>The function returns a dentry, so it would need to be casted and I
>thought that would look "more odd" than this construction.
Yes, it is very odd indeed that you return an inode as a dentry at all. How is
the caller supposed to know whether it was an inode or dentry that was actually
returned?
Jan Engelhardt
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists