From: "Jörn Engel" <joern@logfs.org>
To: Phillip Lougher <phillip@lougher.demon.co.uk>
Cc: akpm@linux-foundation.org, linux-embedded@vger.kernel.org,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
tim.bird@am.sony.com
Subject: Re: Subject: [PATCH 01/16] Squashfs: inode operations
Date: Fri, 17 Oct 2008 18:53:00 +0200 [thread overview]
Message-ID: <20081017165300.GA8076@logfs.org> (raw)
In-Reply-To: <E1KqrTW-0001xC-9M@dylan>
None of the comments below are a reason against mainline inclusion, imo.
They should get handled, but whether that happens before or after a
merge doesn't really matter.
On Fri, 17 October 2008 16:42:50 +0100, Phillip Lougher wrote:
>
> +#include <linux/squashfs_fs.h>
> +#include <linux/squashfs_fs_sb.h>
> +#include <linux/squashfs_fs_i.h>
Current verdict seems to be that these files should live in fs/squashfs/,
not include/linux/. No kernel code beside squashfs needs the headers
and userspace tools should have a private copy.
> +static int squashfs_new_inode(struct super_block *s, struct inode *i,
> + struct squashfs_base_inode *inodeb)
> +{
> + if (squashfs_get_id(s, le16_to_cpu(inodeb->uid), &i->i_uid) == 0)
> + goto out;
> + if (squashfs_get_id(s, le16_to_cpu(inodeb->guid), &i->i_gid) == 0)
> + goto out;
> +
> + i->i_ino = le32_to_cpu(inodeb->inode_number);
> + i->i_mtime.tv_sec = le32_to_cpu(inodeb->mtime);
> + i->i_atime.tv_sec = i->i_mtime.tv_sec;
> + i->i_ctime.tv_sec = i->i_mtime.tv_sec;
> + i->i_mode = le16_to_cpu(inodeb->mode);
> + i->i_size = 0;
> +
> + return 1;
> +
> +out:
> + return 0;
> +}
Most code uses "sb" and "inode", which I consider easier to read - if
only for consistency.
> +int squashfs_read_inode(struct inode *i, long long inode)
Is your "long long inode" what most filesystems call "inode->i_ino"? It
seems to be.
> + if (squashfs_new_inode(s, i, inodeb) == 0)
> + goto failed_read;
Most linux functions return 0 on success and -ESOMETHING on error. You
return 0 on error and 1 on success. That makes it likely for someone
else to do something like
err = squashfs_foo(bar);
if (err)
goto fail;
Oops.
Jörn
--
Measure. Don't tune for speed until you've measured, and even then
don't unless one part of the code overwhelms the rest.
-- Rob Pike
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: "Jörn Engel" <joern@logfs.org>
To: Phillip Lougher <phillip@lougher.demon.co.uk>
Cc: akpm@linux-foundation.org, linux-embedded@vger.kernel.org,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
tim.bird@am.sony.com
Subject: Re: Subject: [PATCH 01/16] Squashfs: inode operations
Date: Fri, 17 Oct 2008 18:53:00 +0200 [thread overview]
Message-ID: <20081017165300.GA8076@logfs.org> (raw)
In-Reply-To: <E1KqrTW-0001xC-9M@dylan>
None of the comments below are a reason against mainline inclusion, imo.
They should get handled, but whether that happens before or after a
merge doesn't really matter.
On Fri, 17 October 2008 16:42:50 +0100, Phillip Lougher wrote:
>
> +#include <linux/squashfs_fs.h>
> +#include <linux/squashfs_fs_sb.h>
> +#include <linux/squashfs_fs_i.h>
Current verdict seems to be that these files should live in fs/squashfs/,
not include/linux/. No kernel code beside squashfs needs the headers
and userspace tools should have a private copy.
> +static int squashfs_new_inode(struct super_block *s, struct inode *i,
> + struct squashfs_base_inode *inodeb)
> +{
> + if (squashfs_get_id(s, le16_to_cpu(inodeb->uid), &i->i_uid) == 0)
> + goto out;
> + if (squashfs_get_id(s, le16_to_cpu(inodeb->guid), &i->i_gid) == 0)
> + goto out;
> +
> + i->i_ino = le32_to_cpu(inodeb->inode_number);
> + i->i_mtime.tv_sec = le32_to_cpu(inodeb->mtime);
> + i->i_atime.tv_sec = i->i_mtime.tv_sec;
> + i->i_ctime.tv_sec = i->i_mtime.tv_sec;
> + i->i_mode = le16_to_cpu(inodeb->mode);
> + i->i_size = 0;
> +
> + return 1;
> +
> +out:
> + return 0;
> +}
Most code uses "sb" and "inode", which I consider easier to read - if
only for consistency.
> +int squashfs_read_inode(struct inode *i, long long inode)
Is your "long long inode" what most filesystems call "inode->i_ino"? It
seems to be.
> + if (squashfs_new_inode(s, i, inodeb) == 0)
> + goto failed_read;
Most linux functions return 0 on success and -ESOMETHING on error. You
return 0 on error and 1 on success. That makes it likely for someone
else to do something like
err = squashfs_foo(bar);
if (err)
goto fail;
Oops.
Jörn
--
Measure. Don't tune for speed until you've measured, and even then
don't unless one part of the code overwhelms the rest.
-- Rob Pike
WARNING: multiple messages have this Message-ID (diff)
From: "Jörn Engel" <joern@logfs.org>
To: Phillip Lougher <phillip@lougher.demon.co.uk>
Cc: akpm@linux-foundation.org, linux-embedded@vger.kernel.org,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
tim.bird@am.sony.com
Subject: Re: Subject: [PATCH 01/16] Squashfs: inode operations
Date: Fri, 17 Oct 2008 18:53:00 +0200 [thread overview]
Message-ID: <20081017165300.GA8076@logfs.org> (raw)
In-Reply-To: <E1KqrTW-0001xC-9M@dylan>
None of the comments below are a reason against mainline inclusion, imo.
They should get handled, but whether that happens before or after a
merge doesn't really matter.
On Fri, 17 October 2008 16:42:50 +0100, Phillip Lougher wrote:
>
> +#include <linux/squashfs_fs.h>
> +#include <linux/squashfs_fs_sb.h>
> +#include <linux/squashfs_fs_i.h>
Current verdict seems to be that these files should live in fs/squashfs/,
not include/linux/. No kernel code beside squashfs needs the headers
and userspace tools should have a private copy.
> +static int squashfs_new_inode(struct super_block *s, struct inode *i,
> + struct squashfs_base_inode *inodeb)
> +{
> + if (squashfs_get_id(s, le16_to_cpu(inodeb->uid), &i->i_uid) == 0)
> + goto out;
> + if (squashfs_get_id(s, le16_to_cpu(inodeb->guid), &i->i_gid) == 0)
> + goto out;
> +
> + i->i_ino = le32_to_cpu(inodeb->inode_number);
> + i->i_mtime.tv_sec = le32_to_cpu(inodeb->mtime);
> + i->i_atime.tv_sec = i->i_mtime.tv_sec;
> + i->i_ctime.tv_sec = i->i_mtime.tv_sec;
> + i->i_mode = le16_to_cpu(inodeb->mode);
> + i->i_size = 0;
> +
> + return 1;
> +
> +out:
> + return 0;
> +}
Most code uses "sb" and "inode", which I consider easier to read - if
only for consistency.
> +int squashfs_read_inode(struct inode *i, long long inode)
Is your "long long inode" what most filesystems call "inode->i_ino"? It
seems to be.
> + if (squashfs_new_inode(s, i, inodeb) == 0)
> + goto failed_read;
Most linux functions return 0 on success and -ESOMETHING on error. You
return 0 on error and 1 on success. That makes it likely for someone
else to do something like
err = squashfs_foo(bar);
if (err)
goto fail;
Oops.
Jörn
--
Measure. Don't tune for speed until you've measured, and even then
don't unless one part of the code overwhelms the rest.
-- Rob Pike
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2008-10-17 16:53 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-17 15:42 Subject: [PATCH 01/16] Squashfs: inode operations Phillip Lougher
2008-10-17 16:53 ` Jörn Engel [this message]
2008-10-17 16:53 ` Jörn Engel
2008-10-17 16:53 ` Jörn Engel
2008-10-21 0:32 ` Phillip Lougher
2008-10-21 0:32 ` Phillip Lougher
2008-10-21 16:14 ` David P. Quigley
2008-10-21 16:14 ` David P. Quigley
2008-10-21 18:03 ` Jörn Engel
2008-10-21 18:03 ` Jörn Engel
2008-10-22 8:48 ` Christoph Hellwig
2008-10-22 16:32 ` Geert Uytterhoeven
2008-10-22 17:13 ` Geert Uytterhoeven
2008-10-23 8:42 ` Phillip Lougher
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=20081017165300.GA8076@logfs.org \
--to=joern@logfs.org \
--cc=akpm@linux-foundation.org \
--cc=linux-embedded@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=phillip@lougher.demon.co.uk \
--cc=tim.bird@am.sony.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.